Replication Question

[jorelb]

Please help me resolve a Replication question:

Can I enable replication between 2 different TM1 Application Servers within 1 physical server?

Thank you

[Alan Kirk]

Please help me resolve a Replication question:

Can I enable replication between 2 different TM1 Application Servers within 1 physical server?

Not sure I understand the question; that's what replication does. It replicates data between two application servers, and the question of whether they're on the same physical server box doesn't enter into it. (Though it may be faster if they're on the one box.)

[jorelb]

Alan,

Thank you for clarifying that specific question. I implemented replication between 2 TM1 application servers that reside in the same physical box and I noticed some issues. I thought I may have violated a TM1 replication rule mentioned in the TM1 Operations Guide which states “Remote servers – You can replicate cubes that reside on remote servers only. You cannot replicate cubes that reside on local servers.” I guess they were referring to “local server” as in application servers not run as a service – my mistake.

However, I hope you can help me figure out some issues I am encountering with replication, which are:
1. I set up replication between Server A (Source) and Server B (Target). The replicated cubes are suppose to be reference cubes and as such, I set up cube security as READ only. Works fine, except ADMIN folks can override the restriction because they have ADMIN access (I have users that are also ADMINS - they have different log on ids for ADMIN purposes though). I understand that there is no way to override the Bi-directional replication but I have read that a way to make it uni-directional is to turn off logging in the Target server. Will this approach work?

2. I am also starting get concerned because I have noticed 2 instances where Target cubes were not updated. I set up a chore to do nightly replication updates and it seemed that intermittently cubes were not updated. However, when I ran the chore manually it updated. Any thoughts?

Thanks in advance

[Alan Kirk]

Alan,

Thank you for clarifying that specific question. I implemented replication between 2 TM1 application servers that reside in the same physical box and I noticed some issues. I thought I may have violated a TM1 replication rule mentioned in the TM1 Operations Guide which states “Remote servers – You can replicate cubes that reside on remote servers only. You cannot replicate cubes that reside on local servers.” I guess they were referring to “local server” as in application servers not run as a service – my mistake.

I'll have to either let someone else answer your two specific questions or come back to them later as I'm pressed for time, but just a quick note on that one...

A local server is when you're running the full version of Perspectives. You can point the Local Server Data Directory option to a folder and select "Start Local Server" from the File menu of Server Explorer. This will load the cubes etc of that folder into the memory of your own computer just as if it was a normal server, with two provisos:
(a) You're the only one who can see that server. No one else can. No one else can connect to it.
(b) The local server bypasses the tm1s.cfg file, so it may not behave quite the same way as a normal "remote" server.

A "remote" server can be either an application or a service, and it can run on either your own machine or a remote machine; it's only called "remote" because it usually will be, not because it has to be.

You can have multiple "remote" servers running on a single box (including a PC) or multiple boxes.

The principal difference comes back to the fact that the "local" server is something that is a "personal" TM1 session which is why you can't replicate from it. "Real" servers can't even see the thing; only your Perspectives session can.

Oh, and as many other regulars will warn you... replication can be tempramental and flaky.

[Steve Vincent]

1. I set up replication between Server A (Source) and Server B (Target). The replicated cubes are suppose to be reference cubes and as such, I set up cube security as READ only. Works fine, except ADMIN folks can override the restriction because they have ADMIN access (I have users that are also ADMINS - they have different log on ids for ADMIN purposes though). I understand that there is no way to override the Bi-directional replication but I have read that a way to make it uni-directional is to turn off logging in the Target server. Will this approach work?

2. I am also starting get concerned because I have noticed 2 instances where Target cubes were not updated. I set up a chore to do nightly replication updates and it seemed that intermittently cubes were not updated. However, when I ran the chore manually it updated. Any thoughts?

Thanks in advance

1. Yes. Replication only ever works (after its initial setup) by checking when it last ran then looking for any logged transactions after that date. No logs = no replication, so ensuring the target is not logged will mean the effect is from A to B only.

2. I have not noticed this situation on my replications other than when changes were not logged. Long shot but could it be date / time related? If the chore is run quite soon after changes were made but the server has not yet saved data to disk i'm not sure it would pick the logged entries up. All my replications are done manually and the guides for doing so clearly state to manually save data on the source server before running the replication. The servers also have a chore set to run every 2 hrs to do a save data as well.

[tomok]

Back in the days before TM1 Web, (and in my corporate days) I had a pretty big replication setup. We had a central planning server (Star) and around 15 or so planet servers in most of the major cities in the southern US. Here were some "facts" I discovered about replication during those days:

1) Don't use replication unless you absolutely have to. It will suck up your support time as I can almost guarantee you that you will have issues every so often.
2) Devise yourself some really good reconciliation spreadsheets that pull data from all the replicated servers. The last thing you want is your users to find an outage before you do.
3) If you do use replication DO NOT REPLICATE DIMENSIONS AND RULES. You are just asking for trouble here. It will greatly slow down the replication process. If you can, just have duplicate dimension maintenance processes on the planets.
4) Do not do two way replication if you can get away with it. One-way (by turning off logging) will be much more reliable.
5) Do not let the system times on your servers get out of synch. If the system time on the star and planet are more than a few minutes apart replication will not happen and you will have no clue why.
6) If you load bulk data to the star, do your best to devise a scheme that will not include replicating that to the planets. For example, let's say this is a planning system and you are loading actuals each day for comparative purposes. If the ODBC source is available to the planets, have a TI process that runs on each planet instead of loading to star and replicatiing.

The bottom line, IMO, is that replication is best suited to a planning system where you have a bunch of users entering planning data in their server (planet) and you need those inputs moved up to corporate (star) on a regular basis. The only problem with that is that TM1 Web will take care of that for you with no need for all those planet servers. The only reason you should need planet servers is if you absolutely have to use Excel and then in that case you can always deploy Citrix or some other remote desktop solution. IBM knows this and because of that I don't believe they have done anything, nor plan to do anything, to improve the reliability of replication. I wouldn't be surprised to see it disappear in a future release.

[jorelb]

Alan, Steve and Tomok

Based on your feedbacks and what I have actually observed (missing data in the Target cubes), I decided not to go with Replication to transfer data between TM1 Servers. My users tend to assume that TM1 is “always correct” and have a tendency not to validate system generated numbers.

Instead, I opted to export/import cma files.

Thanks all for your inputs.

[Steve Vincent]

3) If you do use replication DO NOT REPLICATE DIMENSIONS AND RULES. You are just asking for trouble here. It will greatly slow down the replication process. If you can, just have duplicate dimension maintenance processes on the planets.

No argument with most of that but i do replicate dims as TI sucks when it comes to recreating them from a source dim if it has anything other than one structure to it. It ends up more hassle than the replication, although all my servers are on the same LAN so speed issues don't hit me like they would most people. TM1 is great because it's so flexible, but as a result what works / doesn't work for one might not translate to another. Always good to learn from other people tho

[normanbobo]

Regarding the question of how to make the replication one way, the 9.5.1 operations guide on page 100 has the following:

-----
TM1 does the following with updates you make to the mirror cube:

* Writes the updates back to the source cube, if the updates were made by users with Reserve access to the source cube.

* Does not write the updates back to the source cube, if the updates were made by users with Read or Write access to the source cube.
-----

I am assuming that the "users with Reserve access" must mean the user id on the source system which is entered when the replication is set up on the target system.

Anyone ever try this? Any feedback on it?