Disaster Recovery site

digitalfallout

Active Member
Anyone implemented a Disaster recovery site in JDE
If yes had some questions.

1. What do you replicate from site A to site B

Thanks
 
Yes.

Data.

(!)

This is quite a confusing question on a very large subject. In effect, production data is replicated between your production system and the remote system - the question is how often and when to replicate. Obviously snapshot technology allows for a snapshot "copy" of the data to be replicated to a remote site - ensuring that performance isn't impacted on the production database - but it is important to come up with a method of replicating as close to production as possible.

Objects only need to be transferred "occasionally" - maybe once a week in a production environment. Ideally, your production objects do not change substantially after your go-live - though that isn't necessarily true for many companies. DEV/TEST/CRP data never needs to be replicated. System tables DO need to be included - but there are many tables in OneWorld that are relatively "static".
 
Thanks Jon,

Thats exactly what we had proposed. But just wanted to
confirm with the jde community, I appreciate the reply.
 
All - I am also involved with this disaster recovery site and here's the major issue. For purposes of discussion the we'll call the original enterprise/JAS server ES-01 and the original deployment server DS-01. They want the 2nd site to have its own DIFFERENTlY named Enterprise server, ES-02. I'm just bringing up a 2nd deployment server, DS-02. Here's the issues I see. While we can replicate various \folders and also the production biz and code tables (Oracle on Linux) the problem for me is simply this - if I bring up the differently named failover Enterprise server, ES-02, many of the key values in the replicated system tables will continue to point to ES-01 server. I didn't really want to have to go in and hack those tables. Here are 2 approaches.
Approach 1. My associated suggested a clean install on DS-01 pointing to a NEW JDE812 system database that we intentionally would NOT replicate. We would ONLY share the actual production biz data and central objects code databases.

Approach 2. In the planner session on DS-01, identify both the new deployment server, DS-02, as well as the new enterprise server ES-02. Install the JDE DS software on DS-02. The failover would consist in telling the system files, from DS-02 that ES-02 was now the system files security server and the main JDE system server. I don't think that this woule be enough and we'd STILL have to hack system tables on the replicated database to point the system from ES-01 over to ES-02.

Question. It looks like the client is NOT willling to change the machine name of ES-02 back to ES-01 in the event of a failover. Is there any less complicated way to approach this? Which Approach makes the most sense?
 
ok - if the customer is not willing to change the name - then that does complicate things somewhat.

However, if you install the second enterprise server in the existing architecture as a secondary Database server - then it really isn't too big of a problem - the clients just need to point their ODBC or OCI connections to the second datasource - OR create a second environment for "failover" requirements. A "false" dns name would also work in this case - ie, the IP address changes between the primary and the secondary - but the users hosts file changes to reflect the different IP for the same DNS name.

Database server failover isn't a big issue here - but hopefully you have a set of application servers in front of the database server as opposed to a single big honking box. It is harder to achieve what you want in the latter case.

So, no, you certainly don't NEED to keep the database server names the same - instead you just have to direct the environment to the correct set of ODBC mappings (or OCI mappings) for the secondary database. The issue is then stopping users from logging into that second environment after everything fails back !!!!!
 
Back
Top