Posts Tagged ‘dr’
VIRTUMANIA Episode 2: Virtulization Makes DR Easy
The VIRTUMANIA continues with Episode 2! Rick Vanover joins Marc and I again along with very special guest Jason Boche, the Virtualization Evangelist, for a recorded discussion about DR options in virtualized environments. The following is the podcast summary:
VIRTUMANIA Podcast Episode 2 – Virtulization Makes DR Easy. Rich Brambley (@rbrambley) of VMETC and Marc Farley (@3parfarley) of 3Par and StorageRap.com with guests and Rick Vanover (@rickvanover) of RickVanover.com and Jason Boche (@jasonboche) of Boche.net/blog. This week’s episode includes discussion about how virtualization has changed disaster recovery and site failover, explores various virtual machine backup and replication products, compares storage mirroring to purely physical solutions in the past, and thinks about DR technologies in the future. Thanks to Greg Knieriemen (@knieriemen) of Chi Corporation for this Infosmack Production.
Before, between, and after the important stuff we also have some fun with Virtumania Bucks, the ongoing danger of nipples in the data center (yes, we go there again!), and a new nickname for Greg Knieriemen.
Listen to the podcast with the embedded player or subscribe to get a weekly copy so you can listen when convenient.
Check out the VM /ETC VIRTUMANIA Page to listen to past episodes as well as episodes of Infosmack.
The following links offer more information on some of the VM Backup and DR products mentioned in VIRTUMANIA Episode 2:
Simply Automating Virtual Machine IP Addressing For Disaster Recovery Sites (without scripting)
If you are looking at various options to automate virtual machine (VM) ip address reconfiguration when failing over virtual machines to a disaster recovery (DR) site, this post explains an option so simple it is beautiful. To give full credit, the Vizioncore vReplicator 2.5 Best Practices document enlightened me to the strategy of using a local only VMware vSwitch and an extra virtual NIC (vNIC) in each VM. It’s been a long time since I had a “ton of bricks” moment, but this concept crashed down on me with the realization of a configuration that works in any version of ESX, doesn’t require extra software or hardware, and better yet, doesn’t have to be scripted! Just configure some extra virtual networking and forget about it!
Here is a general outline for automating the DR ip addressing with this method:
At the Primary Site
- For these instructions assume the production vSwitch at the primary site has a Portgroup named VM Network
- Build a new vSwitch and do not attach any physical NICs (local only isolated switch). Create a Portgroup named DR Network
- For each VM you need to fail over to a DR site, add an extra vNIC and attach it to the DR Network Portgroup
At the DR Site
- Create your DR site production vSwitch, attach physical NICs and add a Portgroup named DR Network.
- Create another vSwitch and do not attach any physical NICs (local only isolated switch). Create a Portgroup named VM Network
All you have to do for this to work is
Help Evaluating VMware Virtual Machine Backup Options
It has to be the most common question for those implementing a new virtual infrastructure (VI) – “how do we back up our virtual machines?” There are certainly plenty of choices. A company could stay with the (most commonly found in physical environments) system of agent based tape backups, implement VMware Consolidated Backup (VCB), implement a third party disk to disk product, or rely on SAN array snapshots. Most likely they will end up with a hybrid solution involving many of these choices. There is not an easy and consistent answer. It’s a company by company decision.
Luckily several posts have recently been published on TechTarget.com sites SearchDataBackup and SearchVMware that tackle the topic of comparing the software based VMware VM backup alternatives and offer a lot of information for those evaluating the choices. I thought I would summarize these links since they have caught my attention over the last several weeks. Finally I link to a post about the unique advantages of SAN array backups for a hardware based backup comparison.
Readers should be aware that VMware’s Data Recovery (vDR) product has been updated since the posts linked in this summary were written. Although there are some new features introduced, the implementation requirements have not changed and therefore the content of these posts remain relevant.
Although I’ve covered what VI admins need to know about VCB in the past, I am not covering the product in this post. Check some of my other VCB posts for more information. Read the rest of this entry »
What backup admins need to know about VCB
I wrote a tip for TechTarget.com’s new SearchDataBackup site. Five things backup administrators should know about VMware Consolidated Backup (VCB) walks through some high level planning details for backup administrators considering new options for data and server protection for systems running on virtual infrastructure. The tip talks about why VCB is not the entire backup solution, provides VCB storage and server requirements, discusses the VCB Holding Tank’s role, explains why you still need third party backup agents, and provides and overview for the process of restoring virtual machines and files with VCB.
Check out the whole tip at the link above, and while you are there sign up with SearchDataBackup for great information about data protection and disaster recovery options for both physical and virtual servers.
Enterprise-class High Availability and Disaster Recovery and Management for VMware ESX Environments #BC2370
I attended this VMworld 2008 session on Wednesday 09.18 at 9:00 AM. The presenter was Sunder Parameswaran who is a Senior Product Manager at Symantec. The session was about using Veritas Cluster Server (VCS) in VMware virtual infrastructure (VI) to overcome application high availability and disaster recovery (DR) challenges.
My main interest in this session was on the topic of Geo Clustering with VCS. Also known as Metro Clustering, this is the ability to have one node of the cluster at your primary data center location and the second node at a separate physical location like a disaster recovery site.
Sunder began by outlining various VI challenges.














