CMOD (Windows) - DR scenarios?

[Shannan]

As my id shows, I'm a newbie - we are preparing to install OD  in our production environment.  We are currently running CM 8.3 and have a secondary library server (hadr), resource manager (replicated), and 2 eclient servers.  One of each server type is at a one of two locations, and if one server or site goes down we can switch to the the 'spare'.  So for OnDemand, is there a best practice of how to handle DR or redundancy of servers?  I understand the nightly backup, etc...  but is there a good way of maintaining a replicated server with OD? 

[Justin Derrick]

Hi Shannan.

With CMOD, there's no simple way to provide DR, as there is in CM.

Most customers I work with choose to go with two production servers in geographically diverse areas, and keep them synced by loading the same data into both sites.

It seems that most server hardware is robust enough to not fail, even after years of service -- for example, I'm scheduled to do an upgrade from an RS/6000 H80 this year -- that's hardware that's 10 years old, and is still dutifully serving users!

What seems to cause the most incidents and downtime now is the human element.  In your CM system with a HADR configuration, if a DBA accidentally drops a table, or a user deletes some documents, that change would be replicated to the remote system -- completely eliminating the benefit of using HADR.

With the dual-hot scenario, you can have two servers up and running, ready to serve your users individually, or in a load-balanced scenario.

You would normally switch between the servers with DNS (if you're using the thick client) or build some sort of 'switch' into your web app if you're using ODWEK or the Java API to serve users.

Hope this helps!

-JD.

[Alessandro Perucchi]

Hello Shannan,

There are so many scenarios! Here are a couple, I've seen by customer:

1) Just have a backup of the library server database, and on the TSM side, to have a copy of data in another location. In case of crash, restore of the library server, and point it to the backup tsm, and there you go! Ok, you might have less data in the library server than in the TSM server, but at least you are back to business. You might need to reload documents.

2) HACMP. 1 box is in standby (cold/hot), and the other is the productive box in another location. The TSM is a DR550, which is replicated to another DR550 in another location. Then in case of crash HACMP takes care of renaming the hostname, putting back all the resources where they belongs, and you're set!

3) One productive Library server, but every filesystems are in a SAN replicated in two locations, same story with TSM. If one location is destroyed, then you restore the basic system in a new server, attached it back to the SAN, TSM, and there you go.

...

What you need to ensure in any scenario you might find is that you have a correct situation between Index (Library Server), Cache and Data (TSM).
Cache and Library Server must be syncronized.
Library Server and TSM could not be syncronized, but only in the case you have more data in TSM than in the library server. In that case, you will loose disk space on the TSM side, but you won't have an index without document behind.

In case you don't know this redbook (http://www.redbooks.ibm.com/abstracts/SG246444.html), it gives you some good hints on what you should be careful, and there are some scenarios, which can help you.

Best regards,
Alessandro