Improvements to vCloud Air Disaster Recovery as a Service (DRaaS)

When DRaaS was launched by VMware the backend of last year, everyone was pretty excited about the ability to ‘get rid’ off their secondary/DR site and offload it all into the cloud – A subscription based DR solution which would allow customers to decrease their Capex and offset it with an Opex model.

It kind of boils down to the old accounting argument regarding whether Capex or Opex is a better spending model for IT Infrastructure. Now I’m not an accountant, nor am I pretending to understand the ins-and-outs of tax-deductible benefits, but from my understanding an Opex model is more tax efficient – especially on the P&L balance sheet. (Obviously correct me if I’m wrong!)

Usually a Capex model means:

  1. You require a large amount of cash outlay to purchase all the goods
  2. You have to make an ‘educated’ guess to estimate future capacity needs
  3. Once you’ve purchased the goods, you’re pretty much stuck with it, despite advancements in technology of company growth

However, some CFOs still think that Opex is more expensive as they only consider the cost of the physical server required for the applications.
Whenever you have to do any sort of capex/opex comparison, you have to take the direct costs such as power, cooling, floor space, storage and IT resources to manage the physical hardware.
Plus then there’s all the indirect costs – network and storage, procurement and accounting costs, transportation/logistics, etc. Once all these other costs that accompany the physical tin are considered, it becomes a different argument!

Anyways, I digress…..

So When VMware launched vCloud Air DR, I thought it would become a viable solution for customers looking to get rid of their DR site….. but upon closer inspection there were some flaws in the solution – namely trying to automate your DR (like SRM) and the process of failback once your primary site comes back online (the vCloud Connector process was clunky and required VMs to be powered off before a full data copy occurs back to the primary site – not a viable solution as who would switch off their VMs in order to copy them back over? And we’re talking hours offline if you’re copying a 100GB VM over a 100Mb link!!).

Quick overview of the benefits:

  • RPO configured on individual VMs from 15mins to 24hrs.
  • DR protection is per VM (allowing individual VMs to be failed over)
  • Secure asynchronous replication of VMs (using vSphere replication)
  • Self-service DR testing of VMs (up to 2 tests per 12mth period with a 7 day testing period)
  • Guaranteed resource availability (especially during DR failover)
  • Monitoring and management via Web Client
  • Integrates seamlessly with vSphere environments
  • VMs can run for up to 30 days in a failover scenario without incurring additional costs
  • Ability to transition out of the DRaaS into vCloud Air Private or Dedicated Cloud
  • SLA of 4hrs or less

DRaaS

I’m happy to say that the current release now offers Native Failback using vSphere Replication to reverse the replication from vCloud Air DR into your on-premise environment. Unlike vCloud Connector, this does not require the VMs to be powered off during the reverse replication. It can also be managed from your Web Client – similar to how you originally setup the replication process to vCloud Air.

In addition to this, VMware are now offering Multiple Point-in-Time Recovery using the ability of vSphere replication to retain multiple recovery points, up to a total of 24! Great if you need to recover to an earlier point in time if the latest replication set is corrupt or the VM experiences errors.

Finally, Automation is now possible with full integration with vRealize Orchestrator via a plug-in. This will allow you to create multiple VM recovery plans and automate the failover process – similar to what SRM can do.

For more information about the new version of vCloud Air DR, head along to VMware’s blog announcement: What’s new with vCloud Air DR?

For more information about the vCloud Air offerings, point your browsers here: vCloud Air

vCenter Server (Windows) to vCenter Server Appliance Converter

A couple of days ago, the clever bods at VMware Labs released a new fling that allows you to migrate from a Windows-based vCenter Server to the vCenter Server Appliance: https://labs.vmware.com/flings/vcs-to-vcva-converter

This is a great Fling idea as a lot of end-users are now considering the vCSA given the enhancements made to it in 5.5! (BTW, vCSA has been further enhanced in vSphere 6.0!!!)
Check out my previous blog article on the subject……

Anyways, one of the problems in the past was how would a customer go about migrating data from their old Windows-based vCenter Server onto the new Linux-based vCenter Server Appliance!
Previously I’ve had to ensure that the customer was aware that moving to the appliance means they can’t migrate over their vCenter Server data – and the majority of the time they’re happy to bite the bullet and do a fresh install!

Having used the Fling to migrate my lab vCenter Server to the appliance, I can say that it works pretty well! The Fling migrates the vCenter database, roles, permissions, privileges, certificates and inventory service… It even migrates events/tasks lists, folders, vApp settings and pretty much anything that’s stored in the VCDB! The only thing it didn’t do was migrate the SSO configurations which has to be setup manually (pretty simple to re-do).

There are some limitations though (this is not the full list):

  • The new vCSA needs to have the same hostname and IP address of the old vCenter Server.
  • Both vCenters have to be running the same version.
  • Old vCenter Server must have all components installed on the same server.
  • SQL Server database must be on a separate server to the vCenter Server and can’t be the integrated SQL Express.
  • 3rd party plugins will not be migrated and may need to be re-configured.

Diagram to visualise the migration process:
vcs1

TBH, the one thing the documentation doesn’t mention is whether it migrates Distributed vSwitches, and having played around and used the Fling, I’m happy to say that it looks like it does as I could view and manage the dvSwitch on the vCSA after migration (although if I’m honest I haven’t delved into all the nitty-gritty configs you can do with a dVS).

I found the process pretty simple to follow, deploy a vCSA, ensure it is configured with the same IP and hostname as the old vCenter Server, fire up the migration appliance and follow the wizard!

The only issue I encountered was when trying to configure the Active Directory settings during the vCSA configuration wizard and I got the following error:

Failed to execute '/usr/sbin/vpxd_servicecfg 'ad' 'write' CENSORED 'xxxxxxx.com'':
 VC_CFG_RESULT=302 (Error: Enabling Active Directory failed.)

This was easily rectified by changing the hostname of the vCSA to the FQDN and checking the DNS entry is correct as outlined in this VMware KB: http://kb.vmware.com/kb/2062610

Once this was sorted, the migration was quite pain-free……. this is one great Fling, and I hope they continue to work on it and enhance it!! Well done VMware engineers!!

vcs

Need to know what version of VMware product relates to what build number?

So I’m always trying to correlate versions of ESXi or vCenter Server to the build numbers…. mainly when I’m running a health check and I need to determine what version of VM hardware or VMware Tools should be deployed for the version the customer is running.

Anyways, I thought I’d share the webpages that I always refer back to.

For VMware ESXi Release and Build numbers, visit: http://www.virten.net/vmware/esxi-release-build-number-history/

For vCenter Server Release and Build numbers, visit: http://www.virten.net/vmware/vcenter-release-and-build-number-history/

To determine what version of VMware Tools you should be running against the version of ESXi you have deployed, visit: http://packages.vmware.com/tools/versions

And finally, to determine what version of VM Hardware against the version of ESXi, visit: http://kb.vmware.com/kb/1003746

VCP5 Delta Exam Extended Again……

I can’t believe after all the rush to get re-certified last year (original deadline was 30th Nov 2014) VMware are extending the deadline yet again…….

New deadline for taking the delta exam and re-certifying as a VCP5-DCV is now 8th May 2015.

Since my most popular blog entry was how to study for the Delta exam, you can find all the goodness on what to study for here.

At least they’re rewarding all the people who took the exam early by giving them a 65% discount on the VCP6 migration exam!! Yay…!

More info here: http://blogs.vmware.com/education/2015/03/vcp-recertification-deadline-extended.html