VM /ETC

Posts Tagged ‘fail over’

Too many companies try to implement replication to a DR VI without upgrading the bandwidth between the primary and secondary sites. Let’s look at a simple example that can illustrate what could go wrong with inadequate bandwidth.

A company has 5 VMs that each use 20 GB virtual disks. The data is not too dynamic and data change only averages about 1o% per business day or roughly 1 GB per hr. This data change could be common activity like Active Directory replication, files saved to user home folders, application databases, and email. This is common to a small to medium sized business.

Using the Data Replication Minimum Bandwidth Requirements chart provided by NSI, makers of Double-Take, You can see that the 100 GB falls into the LAN 10Mb/s bandwidth category (in the 10% column). Click the thumbnail image to the left for a better view of the chart. We’ve already proved that this company needs better than a T1, but it’s close enough not to convince those that think their data change will be lower than 10%.

The real “gotcha” is that companies never consider how long it will take to replicate the data. Read the rest of this entry »

Vizioncore: vRanger Pro P2V-DR Module

Vizioncore’s new P2V-DR module adds the ability to create backups of running physical servers on centralized Windows storage.

“The P2V-DR Module in vRanger Pro leverages the robust conversion engine of Vizioncore’s vConverter software. The cloning method employed by vConverter is executed at the “block-level” as opposed to “file-level” which results in extremely fast & reliable conversions with superior completion rates and no data loss.”

Unlike Ghost or other products that allow you capture an image of a server for bare metal restores, Vizioncore’s new module captures the server image while the server is live, and those images are converted for restoring the image to a VM. This sounds similiar to Platespin’s P2I (physical to image) conversions.

Read the rest of this entry »

Every time I have to work with a customer’s networking engineers, or even my own Cisco consultants, I get funny looks when I have to tell them that there is not much to the nic teaming configuration on an ESX server.

Once a vSwitch is created it’s just a matter of assigning multiple physical NICs, creating port groups with the assigned VLANs, and setting the right policy. To the disbelief of the network guys, that can be done without adding any driver utilities or third party management software. After that ESX will load balance traffic headed out of the ESX host to the physical switch and provide redundancy for NIC fail over. Up to this point no changes to the switch are even needed.

On the physical switch side it does require more involved set up to provide inbound load balancing and setting up an ether channel. There are many guides already available on how to do this. Here are a few for reference:

ESX Server, NIC Teaming, and VLAN Trunking – blog.scottlowe.org

VMware ESX Server 3 802.1Q VLAN Solutions