[THIN] Re: DR project dumped on me
- From: "Jeff Bolton" <Jeff.Bolton@xxxxxxxxxxx>
- To: <thin@xxxxxxxxxxxxx>
- Date: Tue, 8 Dec 2009 11:48:30 -0500
Not usually, but it depends on how the replication was set up.
Essentially the SAN takes a PIT snapshot of the protected LUN and then
replicates the delta's to the remote site. The replication cycle is
usually based on the defined RPO, so it could be anywhere between
real-time to days.
________________________________
From: thin-bounce@xxxxxxxxxxxxx [mailto:thin-bounce@xxxxxxxxxxxxx] On
Behalf Of Joe Shonk
Sent: Tuesday, December 08, 2009 10:54 AM
To: thin@xxxxxxxxxxxxx
Subject: [THIN] Re: DR project dumped on me
If replication is done at the block level, is the VM quiesced before
replication begins? How often does replication occur?
Joe
From: thin-bounce@xxxxxxxxxxxxx [mailto:thin-bounce@xxxxxxxxxxxxx] On
Behalf Of Jeff Bolton
Sent: Tuesday, December 08, 2009 8:47 AM
To: thin@xxxxxxxxxxxxx
Subject: [THIN] Re: DR project dumped on me
If they are using Site Recovery Manager for VMware, the replication to
the DR site will be very easy. SRM basically assists in creating a
complete DR plan for virtual environments. It works in conjunction with
the SAN. Basically the SAN is set up to replicate a particular LUN or
set of LUNs, SRM then allows you to re-IP the virtual machines on the
fly (if necessary) at the destination site. The destination machines
remain powered off, until a DR or test DR event is triggered within SRM,
it then severs the replication and powers up the DR VMs.
Because replication is done at the block level for the protected LUN(s),
there is no need for any additional data replication between the two
sites.
If they're not using SRM with VMware, it gets a little more
complicated...
Hope this helps...
Cheers
Jeff
_____
From: Webster <webster@xxxxxxxxxxxxxxx>
To: thin@xxxxxxxxxxxxx
Sent: Tue, December 8, 2009 9:44:32 AM
Subject: [THIN] DR project dumped on me
Two days before "go live" I have had a DR project dumped in my lap. The
original consultant is "no longer available". I was not involved in the
planning, project scope, design, recommendations or purchasing of
anything involved in this project. Customer has a main site and is
implementing a DR site. They are using ESX 3.5 on HP C class blades
with a 30MB pipe between the sites.
For what I am responsible for, the main site consists of VMs for:
SQL 2005 for data store
License server
2 CSG3.1/WI4.6 in NLB
2 32-bit PS4.5 servers (Office 2007 and Acrobat Pro)
1 64-bit test XA5/FP2 on 2003 server
They want me to help them finish testing the 64-bit XA server and if
approved, migrate all users to the 64-bit farm and rebuild the 32-bit
servers as 64-bit servers. Then they want all of this duplicated in the
DR site.
I am not familiar with ESX and what it uses to move VMs between host
servers. All hardware is identical between the two sites.
They will be using some VMware/EMC utility to replicate VMs and data
between the two sites.
My question, if ESX has a utility that replicates the VMs between the
two sites and the DR site VMs will NEVER be "on" when the main site is
functional, what else needs to be done. If the VMs in the DR site will
have the exact same IP addresses, computer names and configurations as
the VMs in the main site, all that should need to be done in a DR
scenario is to point the users to the new public IP of the CSG at the DR
site? Correct?
Does the SQL data store need to have the Publisher/Subscriber
replication setup? Wouldn't think so in this case.
What other info do you need to help me wrap my head around this since I
am supposed to start on this Thursday (and I will be at Ctx HQ all next
week)?
Thanks
Webster
________________________________
The information contained in this e-mail message may be privileged and
confidential information and is intended only for the use of the
individual and/or entity identified in the address of this message. If
the reader of this message is not the intended recipient, or an employee
or agent responsible to deliver it to the intended recipient, you are
hereby requested not to distribute or copy this communication. If you
have received this communication in error, please notify us immediately
by return e-mail. In this circumstance, we request that you delete the
original message from your system.
Other related posts:
