Disaster Site Replication

[Spazmatic]

Hi Everyone,

Today I have been asked to come up with a solution for a Disaster Recovery Site.

They have a live site in place with the following services.

Active Directory
Exchange
SQL
Windows Storage Server

I am not mentioning hardware as new hardware will be purchased based on this solution.

They would like to have a second site, across town, that will house a duplication of their live site. In the event that the primary site burns down they can send users to the DR site.

Has anyone ever had experience with this type of setup.

I was thinking of adding a second domain controller to the live domain, placing the second domain controller in the DR site, use replication.

Adding an exchange server to the second site, use third party software for replication.

Second SQL server, using replication again.

And the file server is an easy one, replication.

But something tells me it's not that simple.

So if anyone has had experience in this area, I would love to here your ideas.

Later

 

[The_Unbeliever]

Yeah.

How will you connect the two sites?

Wireless? Wired? Fiber? This will have an impact on the amount of data to be mirrored.

 

[Spazmatic]

They havent given me the location of the remote site yet, the guys have dropped this in my lap last minute.

But lets say worst case scenario we had a 4MB line.

What would you recommend.

Alternatively if we could utilise a 40MB Wireless connection, obviously things would change, but it is unlikely that we would have that available.

Thanks for the reply

 

[Spazmatic]

If I was to use VMWare ESXi 4.0 and install a virtual box at each site to run the servers, would it be possible to just replicate the Vmware installations.

Sorry but i've never implemented anything like this so my curiosity is taking over.

 

[Nod]

What is classified as a disaster? (building gone, 20% swine flu infection, etc)
What they can work without? (some documents, HR, email or portions of it)
How much space would you need for mission critical stuff? (will depend on that they absolutely need to survive)
Replication or restore from backups? (replication more expensive, backups slower recovery and days data loss, maybe)
Replication every day/hours/hour/real-time? (will depend on size of data, and how critical the data is)

A DR site is not normally the same size as the live site, as it costs too much to maintain. If it is smaller, what percentage of people will work at the DR site, and how many will have to work remotely?

The biggest problem, is that DR can get very detailed, so the first step would be to get clarity on what scenario you are planning for.

 

[Spazmatic]

Currently their main site consists of 30 users, in the event of the building being "destroyed" they need at least 5 users to be able to move to the remote site in order to continue work.

Ideally they will need all data available (as per clients requirements), we can look at implementing quotas to minimise the current storage.

They can afford to lose up to 4 hours data loss, so a 4 hour replication schedule should be fine.

They are estimating a growth of approximatly 30-40GB's per month.

We will be looking at using a virtual server to host all the servers at the DR site, in order to cut down on hardware expenses as the DR site requirements will be less.

 

[Spazmatic]

Sorry I think "They are estimating a growth of approximatly 30-40GB's per month." in my previous post was incorrectly stated,

it should rather read.

"Thay are estimating a change in data of approximetly 30-40GB's per month."

The initial Data can be replicated immidiately, so the only new data that will be replicated over the WAN link will be the changed data.

I hope that helps.

 

[Conradl]

DR is normally a business decision based on the following, also business continuity:

1. Which systems are required to be up
2. When the systems have to up
3. Amount of data that can be lost on each system

e.g.

SQL is critical, must be highly available and you must not loose a single record.
CRM is less-critical, no more than 24 hours downtime, and you can loose 1 business day's worth of data
Internet is not critical

For SQL you will need to mirror your databases so that they replicate between the two sites in real time. CRM you would need to keep an image at the remote site to be started when you move there.

There are also cost implications, a redundant solution of SQL for example, requires two SQL licenses, a highly available solution only requires one. Also there are normally two phases to DR, restoring systems, and restoring data.

My advice is to use Citrix XenServer, free, and create a host at the live site. You can then do regular system backups of the servers (images) and manually ship them to the DR site, or you can copy them to tape/HDD etc. You can then do regular backups of the data to be stored offsite and restored in the event of a DR.

If your primary site has a problem, you then move to the DR site, start your servers, import your data and carry on working.

The primary consideration is cost; the higher the availability, the higher the cost:

A cold standby solution is the cheapest and requires that you have a copy of all your systems at the DR site which are manually started.
A highly available solution requires software that will automate a system recovery process, and thus minimise downtime (unlike the cold standby solution which requires manual intervention).
A fully redundant highly-available solution costs the most (by far), and is required if you want to configure your system so that a meteor can take out one site, and users will only notice a slight pause....

Virtualisation (Xen Server/VMware ESXi), will be a huge help in being able to rapidly restore your base systems....

 

[Spazmatic]

Hi Conrad,

Thanks a mil for the reply, I think that will be the best solution. We will just need to virtualise the primary site.

the only downtime will be powering up the remote site and loading the virtual machines.

 

[Conradl]

Hi Everyone,

Active Directory
Exchange
SQL
Windows Storage Server

Later

Active Directory
Simply install a virtual host, and create a DC at the DR site. Enable replication.

Exchange
Same (almost) concept as SQL

SQL
Not so easy. You mirror your database, which would require a fast WAN link or your system will slow down (as mentioned, each transaction is committed to each node). You could do log shipping; every hour or so, the logs are copied to the DR server in case something goes wrong. You could also just do regular differential backups. The first two require two SQL licenses, the third solution only one.

Windows Storage Server
Clustering - requires two Windows licenses
Backups - requires only one.

Just remember, that any realtime options above, except AD cause the data is minimal, require fast, reliable WAN connections....

 

[Conradl]

Hi Conrad,

Thanks a mil for the reply, I think that will be the best solution. We will just need to virtualise the primary site.

the only downtime will be powering up the remote site and loading the virtual machines.

You're welcome, Virtualising the primary site is easy and should be relatively simple. The only problem that you will have is with the 4hour data replication. If it were 8 hours, then you could simply restore the previous days data from tape at the DR site. Its going to be a pain, and a huge cost, to get half a days changes to the DR site....