Two TeamSite servers

Hi,

We're having 2 TeamSite servers - Production & DR. In case of any problem with Production server, we wanna switch it immediately to DR.

How can we have these 2 servers' contents to be in sync? Or is there any other way where we can have DR server to have the same contents as Production?

Both installed on Solaris SPARC, TS version 7.3.1.

Thanks.

Find more posts tagged with

Comments

RonaldV

Well,

the simple solution would be a DR plan in which you would, in case of a problem, shutdown the PROD server and start the DR machine 'mounted' with the PROD backing-store. With the current hardware/virtualisation this should be no problem and would not require to copy the store from one server to another.

The more complex solution would be to sync your store somehow, f.i. a raid-like (?) solution.

Migrateduser

You should ensure the custom code of TeamSite and OpenDeploy are copied to both PROD and DR environments during code enhancements/releases.

Also, if you're adding TS users and groups frequently, you should copy tsusers and tsgroups files from PROD to DR environment during failover or have some script to keep this in sync.

jihan

Thanks for your feedback.

Was doing some browsing and came across this link:
http://www.unix.com/unix-advanced-expert-users/150162-how-sync-two-servers.html

Suggested to use rsync. Can this be used in my situation also? Is it a recommended solution?

Thanks.

Migrateduser

I guess, rsync can be used if your PROD content stores are frozen. Hope you are getting recommendation from Autonomy support too.

mart2001

Since you are on 7.3.1, if your content store is on a SAN/NAS, you can do backups without having to freeze/stop the content store.

Adam Stoller

Since you are on 7.3.1, if your content store is on a SAN/NAS, you can do backups without having to freeze/stop the content store.

The ideal situation is to have a NAS box (or two) configured with snapshot functionality and to use that as the basis for your backing store - then you want to do a bunch of customizations to get as much stuff configured to be on the NAS rather than on the local disk so that the process of failing over or switching servers for disaster recovery requires much less synchronization (one server gets turned off [non-gracefully - it's a disaster, right], another server gets started up). One of the tricks though is that you have to remove the TSRunning file from the backing store in order to bring the second server up (only do this if the other server is down and went down un-gracefully)

It is possible to configure log files, db files, and a whole bunch of other things to be in non-traditional locations, on the NAS, so as to avoid having to worry about constantly syncing them (and thus no need to deal with OD, rsync, etc.)

If you are dealing with multiple NAS boxes - presumably one in each of the datacenters - there are ways to have NAS boxes sync with each other using NAS's own technology - so again, you don't have to worry about doing all the synchronizing yourself.

You want to sit down with someone who knows a lot about NAS, someone who knows a lot about the OS, and someone who knows a lot about obscure configuration settings for TeamSite and OpenDeploy to plan this all out.

You may need to have a number of back-and-forths with Support to ferret out those obscure settings....

jihan

Thank you all for your input.

Sean_Hanck

The most success I've had with this type of thing is to virtualize the whole thing, then if the hardware goes down, the VM gets moved to HW that is up. In my opinion having a DR plan that requires TS to be up immediately is expensive and if every actually tested won't work. There are too many single point of failures in a solution for it to actually work smoothly. If there is a catastrophic event in your data center kiss TS good bye, the DB cluster will be down or the LDAP repository will be fried, or some other forseen integration point will fail.

Having tried to do this in the past, I would recommend having a more realistic DR plan (when they say "immediate" ask how much they want to spend) with various levels of "disaster" clearly defined and which you are planning for (if the UPS fails and servers get fried, I'll stick around and help - if someone drives a bus into the server room, I'm going home), not being able to publish content for 6 hours is a pain but not the end of the world. And the faster the failover the more expensive its going to be, with alot of the costs not being TS related.

Run_BIRT_Report.jpg

jihan

Thanks for the explanation.

Would like to know if this architecture applies for Windows installation as well?
I tried to change Y: drive to storage server, but was not successful. Seems like it's still reading iw-store from it's own local disk.