Dan Anderson, a Principal Architect for VMware, spoke about the infrastructure behind VMworld 2010.  This was a very entertaining session and Dan was fun to listen to.  There are 3 datacenter locations used to power VMworld, one is here at Moscone, another at Terremark in Miami, FL and the third is at Verizon in Ashburn, VA.  All sites connect over the public internet through IPsec VPN connections.  Having some of the equipment onsite made this a ‘hybrid cloud’ deployment.  Since VMware says the cloud is the future of computing they decided to practice what they preach and deploy it in a cloud.  All lab stations are PCoIP zero clients and the room is divided into 8 sections.  Of those 8 sections 3 connect locally, 2.5 go to Verizon and the other 2.5 go to Terremark.  One of the problems during setup was moving data around, and Dan mentioned as an industry we need to figure out an effective way for moving data between clouds.

Networking:

10 Gbe core

2 x DS3 links at Moscone

Redundant 100 Mb connection at Terremark and Verizon

All connections go over public internet through IPsec VPN

Storage:

329TB Raw

244TB Usable

Compute:

352 ESX hosts

736 CPU sockets

3072 CPU Cores

7.5 THz Clock cycles

Memory:

14.6 TB

Clients:

480 PCoIP enabled zero clients

The two other locations were picked on the east coast because they will also be used for VMworld Europe which is coming up soon, Moscone equipment will be moved and the others will remain in place.

Lab Stats:

30 labs

44 hours of lab time over 4 days

480 seats

22070 lab hours

Also mentioned was that 4000 virtual machines are built and destroyed every hour!

Larry Touchette from NetApp and Arturo Fagundo from VMware presented this session on using SRM with NetApp.

SRM allows you to do non-disruptive DR testing.  In order to do this you group VMs you want into protection groups.  Protection groups are the minimum level you can failover.  Once you have created your protection groups you build a recovery plan – a recovery plan is similar to an electronic runbook.  Site Recovery manager handles failing over the storage for you, promoting a replica image at the recovery site, registering the VMs at the DR site from the replicate storage and powering them on.  There are two different mods for SRM: Test and Failover.  When using test mode, it won’t affect your production virtual machines and it will create a separate, isolated network in the recovery site to bring the VMs up for testing.  Another thing to be aware of, SRM supports bi-direction protection since a lot of customers would be running production out of both locations.

SRM leverages array replication technology and requires the use of a Storage Resource Adapter (SRA) that is provided by the vendor (NetApp, EMC, etc)

You must have a vCenter at each site, since its likely the two environments are not identical you configure inventory mappings with SRM to map resource pools, networks, folders from one site to another.  The protection groups correspond 1:1 to datastore groups but it is not configured by datastores, rather it is configured by virtual machines.  The recovery plan contains protection groups.

When performing a test recovery, SRM will request a temporary copy of the storage which in this case is a Flexclone and then add the LUNs to igroups or create NFS exports AND the SnapMirror replication will still continue.  The next release of Site Recovery Manager will optionally allow requesting synchronization of replicated devices – what this will give you is if you are the Virtualization admin you wouldn’t need to contact the storage admin to have them update the SnapMirror if you wanted to do a DR test with the very latest data.

A recovery workflow is similar to a test but it actually breaks the SnapMirror and then promotes the destination volume to be read/write.  If using LUNs it adds them to the appropriate igroups and if using NFS it creates the exports with appropriate permissions for ESX hosts.

The latest version (as of this post) of the NetApp SRA is 1.4.3 which is a unified adapter, it works for either SAN or NAS (meaning the VM can have a system VMDK on NFS and an RDM device via iSCSI – this is common when using SnapManager products within VMware).  Some of the new features in 1.4.3 are:

• Unified Adapter
• Fully thin provision the DR test environment
• Multistore vfilers as storage arrays
• Non-quiesced SMVI snapshot recovery

If you are upgrading to the unified adapter you should be aware of the following:  If you are currently a SAN only environment it requires no SRM reconfig, the ONTAP version on the NetApp should be 7.2.4 or newer and you would simply need to uninstall 1.4.2 SAN and install 1.4.3.  If you are currently in a NAS environment you need to delete the protection groups and array managers prior to uninstalling the 1.4.2 adapter, then after you install 1.4.3 you must re-create your protection groups.

The next version of SRM will have a new re-protect workflow to reverse replication and synchronize storage in the opposite direction.  Any changes made at the DR site would be populated back to the original primary site.  If the storage itself wasn’t destroyed in the disaster it will only transfer the delta changes (as it will find a common storage snapshot and transfer changes made since then).  More details on that were available in BC8372 – SRM Futures: Failback and more.  The next major version of SRM should be released in the second half of 2011.

Also see NetApp’s Technical Report on using VMware Site Recovery Manager with NetApp storage: http://media.netapp.com/documents/tr-3671.pdf

Also, just as note at the end – one mentioned use case for SRM (other then the obvious) was for testing Application/Windows Updates:  You can run a DR test and apply all the updates or make the configuration changes, do your testing and then once it’s been validated make the changes to your production systems as well.