PR to DR synchronization of Data

[late.vaibhav]

Hi,
I need to keep Production and data recovery(DR) server in sync. To solve this i have two options:
1.crated TI processes in The DR server which will load data from Production with the help of ODBO and run these TI in CHORE.
2. Create replication in DR server and synchronize data.

Kindly suggest which is the best method and if there is any other way kindly suggest me.

Regards,
Vaibhav Late

[MSidat]

I am assuming you do not need an almost Real Time sync and you would be content with possibly a nightly or a 4 hourly sync. I would suggest a 3rd possibly more simple option of just executing a script to copy your TM1 data folders over from one server to the next, once you have done the appropriate "Save Data" on your main instance.

[babytiger]

I am assuming you do not need an almost Real Time sync and you would be content with possibly a nightly or a 4 hourly sync. I would suggest a 3rd possibly more simple option of just executing a script to copy your TM1 data folders over from one server to the next, once you have done the appropriate "Save Data" on your main instance.

That's what I would do too. Just keep in mind and take note of the cross environment differences, such as websheet, system control parameters, etc. Depending on how your environments are setup.

[late.vaibhav]

Thanks for the quick reply.

I have implemented this option to take backup of the server.
But if we implement this we have to start the backup server, but in my case i need both the servers up and running so in case production server(Hardware) get crashed we will link to DR server with minimum efforts and less data loss.

Kindly suggest for this.

[babytiger]

Depending how big is your TM1 server instance.

My personal opinion is, taking the entire data folder to DR would minimise the risk of missing data for certain objects. If you server instance is large (taking a long time to start), then the chances are it will take a long time to sync your data across as well. TM1 is not DB, can not easily identify data changes over time (unless you use the logs).

Also, I wouldn't expect the DR is required to be up 24/7. But I don't know what is your SLA.

[David Usherwood]

You could consider using rsync (probably the Windows implementation Deltacopy) to reduce transfer time compared to copying the whole folder. Rsync transfers changed content only and is clever enough to detect what parts of a file have changed. It won't address the issue of running up the DR server, but if you are using persistent feeders, this shouldn't be too long, depending of course on your application.

[tomok]

The answer here, of course, is that there is no perfect solution. Replication is NOT the answer simply because it relies on the TM1 log file to operate. What this means is that you have to log everything in order for this to work, meaning you have to turn on logging in all your TI processes. If you've got any decent sized loads, like from Oracle or SAP GL then they're' going to slow down significantly and your log file will balloon in size. The synchronization process will be extremely slow and tie up BOTH your servers while it is executing. The only real viable option is an automated process to copy the object files from PROD to DR on a regular basis and once PROD goes down you start up DR. If you are using persistent feeders it shouldn't take too long to come up. If your company needs a hot backup for TM1, meaning it must be up immediately after PROD goes down then you've chosen the wrong tool.

[paulsimon]

Hi

If you have a reporting only systems, another approach is to simply run load processes and dim builds from the same common set of data on both the Production and DR servers. In that way if one goes down, the other carries on as normal. It is just a matter of re-routing queries to the DR server which can be done with a router switch. Any changes to the processes, rules, etc, just need to be promoted to both servers. In fact, if you are doing that, then really you have two Production systems so it is just a matter of re-routing users from one server to the other. A load balancer will do that automatically.

If the system has data entry, eg planning, forecasting, etc, with users directly inputting data directly into the Production system, then you will need to use one of the other methods. A downside of copying files is that the .cub files are only updated when you do a save data or at least a cube save data. If the data is still in memory and not yet saved to disk, there is nothing to copy.

A possible work around is a hybrid approach whereby any cube into which users enter data, only has data entered and nothing loaded. Any bulk loads, where you would typically turn off logging go to another cube. Data is periodically transferred from the input cube by a chore and merged into the loaded cube. Use of a 'source' dimension with elements of Entry and elements for the various source systems, eg GL, HR, can make it easy to keep the data separate, and in particular to clear the data in the Entry element when data has to be transferred across for the Input cube.

You would keep logging turned on, on the Input cube, and use Synchronisation to update the copy of that cube on the DR server. However, I would still suggest that if you have an overnight or weekend window, when at least the DR server can be shutdown that you then do a save data on the Production server and copy the files across to the DR server.

However, you would need a fairly critical system to make all this worthwhile. For example, if you have a DR system up and running as opposed to the service being shutdown, and guaranteed only to be up when the Production system is down, then you will need another set of licenses which is costly. It might be cheaper and easier to leave the DR system down, and to adopt one of the file copy methods suggested earlier.

I don't know what the underlying problem might be. Is it that the server takes a long time to come up? If so then perhaps look at reducing feeders or using persistent feeders.

Is it that the system is frequently going down? If so then I would raise that with IBM support.

However, overall TM1 servers don't really crash that often these days and hardware failure is rare. It typically takes 20 minutes to start up a TM1 server. The users are typically finance departments rather than city traders, so if the system is down for 20 minutes or so, this doesn't really have that serious an impact on closing month end. However, your system might be much more critical and might have good reasons why it takes much longer to restart. Although I can't think of too many reasons why it would go down more than normal.

As with any DR solution you need to weigh up the cost of the solution vs the losses incurred by each outage times frequency of outages.

Regards

Paul Simon