Go Premium for a chance to win a PS4. Enter to Win

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 590
  • Last Modified:

vmware DR site

Hi guys,

OK, we are currently doing DR testing and we will perform a DR test with our production environment unaffected. We have SAN mirroring to our DR site and we plan to break that mirror and put the DR SAN in read/write. I have made a powerCLI script to add my desired VM's to the DR inventory, however I am concerned that the replicated data(VM files) on the DR san may be in some state not allowing me to "add to inventory" on the DR site.
This is because we do not shut down the production enviroment before stopping the SAN mirror. There will be no LAN or SAN connectivity between the production and test environment during this testing, and as long as I am able to add the VM's to the DR inventory I will be good to go.

Does anyone have any experience with this? Ask if something is unclear.

Thank you.
0
synackrst
Asked:
synackrst
  • 5
  • 3
  • 3
2 Solutions
 
Andrew Hancock (VMware vExpert / EE MVE^2)VMware and Virtualization ConsultantCommented:
Yes, this is exactly the process we do with many clients.

We have no issues in adding "Mirrored" Virtual Machines to the Inventory.

Depending upon how the virtual machines have been SAN Mirrored, you will be restoring crash consistent Virtual Machines. Which for us and our clients works with no issue.
0
 
synackrstAuthor Commented:
Thanks for the feedback hanccocka. we got about 50-60 critical servers that should be up during a DR situation so I wanted to be sure that this didnt spoil the test. The SAN mirror should be synchronous.

If you had any troubles at all with bringing up the "replica" of the production environment, what was it?

0
 
Andrew Hancock (VMware vExpert / EE MVE^2)VMware and Virtualization ConsultantCommented:
None, we developed scripts, to break the mirror and mount the LUN, add LUN to ESX servers and then add VM to Inventory.

DR for a single VM takes less than 5 seconds.
0
Cyber Threats to Small Businesses (Part 1)

This past May, Webroot surveyed more than 600 IT decision-makers at medium-sized companies to see how these small businesses perceived new threats facing their organizations.  Read what Webroot CISO, Gary Hayslip, has to say about the survey in part 1 of this 2-part blog series.

 
Paul SolovyovskyCommented:
Keep in mind, unless you're quiescing the VMs during the snapshot/replication process your VMs may not work correctly at the DR.  This is mostly for SQL and the like where the DB may need to be put in read mode while the local backup/snapshot takes place.
0
 
synackrstAuthor Commented:
Paulsolov, the replication is done at the SAN level so that might not be applicable? We are basically just mounting the mirrored SAN disks to the DR environment. where all the same VLANS/subnets etc reside.
We have a seperate vCenter and mostly physical SQL clusters with a standby node on the DR site.

Afaik we only have 1 virtual SQL server.

Anyways I appreciate your information.

Hanccocka, are you using powerCLI to do most of your automation?
0
 
Paul SolovyovskyCommented:
This is still applicable.  For instance, Netapp and other vendors have tools to quiesce the databases before doign snapshots/replication.

What type of SAN hardware do you have and what type of servers are you replicating?
0
 
synackrstAuthor Commented:
We have HP EVA and the Production SAN and DR SAN are replicating synchronous. So the DR san is always "up to date". I don't have all the data in my head at the moment, but linux servers with roles: web and app with their database on a physical node. and other windows 2k3/2k8 application servers. Maybe 1-2 virtual SQL servers.
0
 
Andrew Hancock (VMware vExpert / EE MVE^2)VMware and Virtualization ConsultantCommented:
Also note that there is a fault also within VMware, that can also occurs that the "stun" cycle of applying the VM Snapshot function to a heavily loaded VM (database) can corrupt the running Production Machine. This fault can occur with Active Directory Domain Controllers, SQL, Oracle Databses, Virtual Centre ADAM, so you may want to test the benefits of the "quiece" production and break production machines versus having a correctly "quieced" DR VM. Also even on not heavily loaded VMs, the issue can occur.

All our scripts were developed in PERL, because it enables us to commuincate easily with SAN and also ESX servers.

So, I would TEST TEST TEST and TEST your DR, and when you think you've finished TEST again. Also most of our clients, run FULL DR TESTs every month, or a leat every quarter.
0
 
synackrstAuthor Commented:
Thanks, yes - I will try to find a good way to test our DR,  and hopefully 2-4 times a year.

Also thanks for the ideas, I'm gonna do some thinking and should I have any questions I will get back to you.
0
 
Paul SolovyovskyCommented:
For the EVA (I have tested this specifically with the 6400) you can schedule to create a snapshot (BC), as part of the script you can run to quiesce the database and or application before doing a snapshot.  Once the snapshot is taken you can take it out of read only mode.  Afterwards the DB/App is quiesced properly.  

I am not saying that straight replication will not work but if you want to do this more effectively you may want to look into this.

With VMWare it's a little bit different, if the snapshot knows about the virtual environment it can run VSS and queue up data while the snapshot takes place but this is only for Microsoft aware apps and would work with something like Netapp Snapmanager for VI.  I am not sure that EVA Business Copy will do this..same for Oracle.
0
 
synackrstAuthor Commented:
Will see how it goes this month and from that I will start tweaking the solution. Thanks again.
0

Featured Post

Free Tool: IP Lookup

Get more info about an IP address or domain name, such as organization, abuse contacts and geolocation.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

  • 5
  • 3
  • 3
Tackle projects and never again get stuck behind a technical roadblock.
Join Now