Discussions
Categories
Groups
Community Home
Categories
INTERNAL ENABLEMENT
POPULAR
PUBLIC CLOUD
PRIVATE CLOUD
Quick Links
MY LINKS
HELPFUL TIPS
Back to website
Home
Web CMS (TeamSite)
best practices for maintaining DR content using OD
xlhAlex
We are using OpenDeploy 6.1.1 and Teamsite 6.7.1. We are setting up a Disaster Recovery environmment and are planning to use OpenDeploy to sync our web content. I am trying to solve the issue of synchronizing content to the DR servers. I’m considering using OpenDeploy to deploy content from the TeamSite server to the DR servers. I don’t necessarily want this to run real-time (deploy to DR at the same time as deploy to prod). I’m thinking that it would be best to run some sort of workflow or script which runs once a day to call OD and push content to the DR servers without any human intervention.
We want to do this as a delayed approach that would be an automated process which the content contributors would not be aware of. To clarify, we need our DR site to be close to an exact copy of our live production site. Currently, when a content contributor sends a file thru the workflow, it deploys the file to QA server and then production server based upon workflow rules. We need to include deploying the file to the DR servers. I was considering 2 options; either deploying the files from the TeamSite server to DR servers or deploying files from the production servers to the DR servers. Either approach would use some kind of automated deploy process.
We have 2 production web servers and 2 DR web servers. The DR environment will exactly replicate the production environment with the exception of the Interwoven tier. We have 2 disaster scenarios:
1 - the entire production location goes down, in which case we loose all Interwoven applications and the web sites themsleves. In this case, the DR will take over, but we will have only the web sites up and will have lost the ability to create and deploy new content.
2 - only the production web environment goes down, in which case we still have the Interwoven applications. In this case, we will still be able to create new content and will want some type of deployment process. How that deployment is handled should not change from the standard approach. It will run the same as it would have if the production servers are still up, realizing that content is not going to the production web servers and when they are back on line we will have to sync new content with the DR servers.
I would appreciate and and all guidance on this.
Thank You,
Alex
Find more posts tagged with
Comments
Trey
In your scenario (which sounds ok) I don't see the value in delaying the deployment to your dr severs unless there is a latency issue to get to them. Why not just do a fan out deployment to the dr servers at the same time as prod? This keeps them in sync real time.
If you really want to go your route the only thing I see is that your prod server(s) will need a full opendeploy base installed ($$) and do you really want your servers in production handling the load of doing a deployment while also serving up content?
Another thing you could do to separate them with workflow. After the deploy to prod is done you could deploy the same content to dr region if you need to keep these deployments in silos form each other for some reason, but that depends on your requirement of course.