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

Should IT be Cloud?

A while back I was asked to write an article about Cloud Computing for my company’s blog site…… which they decided to publish during my snowboarding trip to Serre Chevalier! (Hence the late publication on my blog).

http://www.mtibytes.com/post/Should-IT-be-Cloud

Have a read and feel free to let me know your thoughts, whether you agree or disagree on my points. =)

In the mean time….. here’s a quick picture of my snowboarding trip…. ;oP

Day 2:
20150211_102334
Final day white out!
20150214_101039

vCloud Air Tutorials

Want to know more about the VMware vCloud Air services? Well pop along to the tutorial page in the vCloud portal! =)

http://vcloud.vmware.com/uk/using-vcloud-air/tutorials

Excellent material for how to use the vCloud Air services, how to setup and deploy VMs if you purchase a Dedicated or Virtual Private Cloud….. and most importantly how the vCloud Air Disaster Recovery works (which was what I was after).

We’ve had a huge number of customers interested in DRaaS and vCloud Air DR seems a very viable solution!

MTI Webinar Series – VMworld Update Session

As you all know, VMworld took place in Barcelona last month. During this event, VMware made a series of announcements regarding its three strategic initiatives – software defined datacentre (SDDC), hybrid cloud, and end-user computing (EUC).

My company is currently holding a series of webinars in November covering VMware and complementary parter offerings, and I’ve been asked to kick-start the series with a VMworld update session on SDDC and Hybrid Cloud.

The first webinar, The software-defined datacentre & hybrid cloud, will take place on Tuesday 25th November 2014 at 11am. During this session, I will be discussing what’s new in vSphere 6.0, Virtual Volumes (vVol), EVO:Rail, vRealize Suite and vCloud Air.

If you wish to attend the webinar then feel free to register here:
https://attendee.gotowebinar.com/register/1836954438946370306

…. I ask that if you do join not to heckle….. =P

(The other webinars this month will cover VMware’s EUC offering; discussing agentless security for the software-defined datacentre with Trend Micro; and EMC’s portfolio around data protection and availability – specifically RecoverPoint for VM and VPLEX virtual edition)

Upgrading vCenter Operations Manager to 5.7

So….. the penultimate piece of upgrade work planned for the DR environment is the upgrade of vCenter Operations Manager from 5.6 to 5.7.

The great thing about vCOPs is the ease of upgrading the appliance. Simply navigate to the administration page (https://vcops-ip/admin) and browse to the upgrade zip bundle! =)

1. Navigate to the admin page of vCenter Operations Manager and click on the Update tab. Click Browse and locate the vCOPs zipped upgrade bundle.
vcops1

2. Wait for the file to unpack and upload.
vcops2

3. Click Update to start the update process.vcops3

4. Click OK to proceed with the update.
vcops4

5. Watch the update, or grab a cup of tea!
vcops5 vcops6

6. Once complete, reboot the appliance.
vcops7

7. You may find that the registration of vCOPs to the linked vCenter Server will require updating. To do this browse to the Registration tab and click Update under vCenter Server Registration.
vcops7a

8. Enter the vCenter Server details and click Test Connection. If successful, click Apply.
vcops8

9. Accept the security alert that moans about the SSL certificate not being trusted – this is the new SSL certificate that was generated when I upgraded my vCenter Server Appliance.
vcops9

10. Reboot the appliance and Bob’s your uncle….. it should be up and running the latest version!

 

Simples…… *squeak*

 

 

Updating VMware vCenter Site Recovery Manager to 5.5

So after updating my vCenter Server Appliance to 5.5, the next obvious choice was to update Site Recovery Manager and the vSphere Replication Appliance.

Note: the way I’m upgrading my demo environment is not according to best practice…. it’s merely a quick way to document and try out the upgrade process!

If you’re planning an upgrade of your production environment, then there is a recommended order for the upgrades:

  1. Upgrade vCenter Server on the protected site.
  2. Upgrade SRM Server on the protected site.
  3. Upgrade the storage replication adapters (SRA) on the protected site.
  4. Upgrade the vSphere Replication appliance on the protected site.
  5. Upgrade any additional vSphere Replication server instances on the protected site.
  6. Upgrade vCenter Server on the recovery site.
  7. Upgrade SRM Server on the recovery site.
  8. Upgrade the storage replication adapters (SRA) on the recovery site.
  9. Upgrade the vSphere Replication appliance on the recovery site.
  10. Upgrade any additional vSphere Replication server instances on the recovery site.
  11. Configure the connection between the SRM sites and vSphere Replication appliances.
  12. Verify that your protection groups and recovery plans are still valid.
  13. Upgrade ESXi Server on the recovery site.
  14. Upgrade ESXi Server on the protected site.
  15. Upgrade the virtual hardware and VMware Tools on the virtual machines on the ESXi hosts.

When you upgrade Site Recovery Manager, there’s no real need to do anything to your database as the upgrade preserves all information in the current SRM DB (so basically preserving your protection groups, inventory mappings and recovery plans, plan run history, etc).
However, if you’re not running 5.1 or later then you will need to create a 64bit ODBC system DSN (SRM 5.0.x used a 32bit ODBC DSN). Any deployment of SRM earlier than 5.0 will require a two-step upgrade, first to 5.0.x then to 5.5.
(Note: Don’t upgrade vCenter Server directly from 4.1.x to 5.5, as this will cause the upgrade of SRM to fail when moving from 4.1.x to 5.0.x… this is because SRM 5.0.x cannot connect to vCenter Server 5.5)

Fortunately I’m going to step through an upgrade from SRM 5.1, so my ODBC is already in place!

1. On the SRM server, start the installer.
SRM1

2. Choose where you wish to install the new version of SRM.
SRM2

3. Choose to install vSphere Replication if you’re using it (Which I am).SRM3

4. Enter the vCenter Server credentials (the installer will notice SRM is already installed and pick up the IP address of the vCenter Server).
SRM4

5. Accept the SSL certificate warning.
SRM5

6. Once the installer connects to your vCenter Server, it will identify that you already have a registered extension for SRM. Click Yes to overwrite the old extension.
SRM6

7. Select the type of authentication to be used (in my case I’m letting SRM auto-generate a self-signed certificate).
SRM7

8. Enter the Organisation and OU in order for SRM to generate the certificate.
SRM8

9. Enter an administrator’s email address in order to obtain SRM generated alerts.
SRM9

10. The installer will pick up the ODBC connection and request you to enter the existing SRM DB user information.
SRM10

11. Select Use existing database, choosing the other option will wipe everything from your existing SRM deployment!
SRM11

12. Click Install to kick off the upgrade.
SRM12

13. Once installation is complete, you will need to upgrade the vSphere Client Plug-in for SRM. You will need to uninstall the old SRM plug-in from within Windows Control Panel->Programs.
SRM13

14. Once complete. Fire up vSphere Client and install the new plug-in via Plugins->Manage Plug-ins
SRM14

 

Job done…… now to upgrade the existing vSphere Replication Appliance…. You can upgrade the vRA either using vSphere Update Manager, via the online repository, or via an offline repository (like an ISO image).
Unfortunately like the VCA, I couldn’t find an 5.5 update using the online repository so had to mount the vRA 5.5 ISO image to the vRA and update via CDROM.

1. Log into the vRA management console (https://vra-IP:5480 or http://vra-IP:8080 if its vRA 5.0.x) and select the Update tab. Select Settings and then choose Use CDROM Updates and click Save Settings.
vra1

2. Click on Status and it should display any update files it has found in the mounted ISO image. Click Install Updates.
 vra2

3. Once update is complete, you will need to reboot the vRA…. don’t forget to unmount the ISO image…..
vra3 

 

Voila….. it’s as easy as that!

Upgrading vCenter Server Appliance to 5.5

Given that I’ve not touched vSphere 5.5 yet, I thought I would try and upgrade some of the VMware components within my company’s solution centre…. and the easiest component to upgrade first would be the VCA that I deployed to run as my test DR environment.

Anyways, so my old VCA was running 5.1a and I wanted to do an upgrade of it to 5.5.

Fired up a browser to the management page – http://vca-ip:5480 – and tried to do an update via the VMware.com repository….. unfortunately there wasn’t an upgrade option available to go to 5.5 (only to upgrade to 5.1b)…… pants…..
So I navigated over to the VMware product download pages to try the get hold of the zip bundled update…. only to find there wasn’t one available… double pants….

So the only option I had was to deploy a brand new version of VCA and then go through the upgrade wizard from within the new VCA. Having never done this before, I thought it would be a messy process….. strangely enough it was very easy!

Although the issue about having to take this path is the requirement to have enough storage space for a second VCA and also another spare IP address which could be used temporarily until the upgrade wizard completes the sync of the old config. Fortunately I have DHCP running so the new VCA picked up an IP without me having to go into the console and configure the network! =)

1. After deploying the new VCA, the wizard allows you to select “Upgrade from previous version”. What this does is connect the new VCA to your old one, and pull over all the old configuration details (like Network)… it looks as if the wizard also pulls over stats and logs as post deployment I can still see all the old tasks and event.
(If this wizard doesn’t start, then click on the Summary tab and under Utilities launch the Setup Wizard)
vca01

2. In order to setup the connection between the two VCAs, you need to configure the SSL certs so that they trust each other. Copy the key from the new VCA.
vca02

3. Open up the management console of the old VCA, browse to the Upgrade tab and paste the new VCA key into the window and click “Import key and stop vCenter Server”. Once the import is successful, the old VCA will generate its own SSL key which you need to cut and paste into the new VCA.
vca03

4. Paste the key generated by the old VCA into the second field and click Next.vca04

5. The setup performs a check on the SSL certificate of the old VCA. If problems are found, the Setup wizard explains the problem and provides an option to generate a new self-signed certificate for the new VCA. Since I’m not using a CA-signed certificate, I’m quite happy to replace the old cert with a new self-signed one.
vca05

6. One of the big changes with SSO is the administrator account has changed. Whereas previously this was admin@System-Domain it now becomes administrator@vsphere.local.
vca06

7. Review the list of hosts managed by the old VCA and ensure you select the hosts you want to be managed by the new VCA.
vca07

8. Upgrade Checker will run automatically and generate a report with any errors it detects.vca08

9. Click Start and sit back, relax and count some chickens as you wait for the upgrade to complete. It took about 15mins for my upgrade to complete, but that could be due to the small environment being managed by the VCA.
vca09

Next up, an upgrade to SRM 5.5…….

Link

vCloud Director Convergence and Transition Plan

Very good blog post regarding how vCD will be integrated with vSphere and vCAC…..

So it seems vCD is being phased out of Enterprise customers with vSphere handling the cloud infrastructure and vCAC the automation and cloud management.

It sounds like vCD will become a VSPP product specifically aimed at service providers…..

Link

VMworld 2013 announcements – vCloud Suite

So there are times when a blogger becomes just pure lazy (ie this is one of those times), so rather than regurgitate everything I’ve been reading today that came out of the first 2 days of VMworld, I thought it would just be far easier to link to a blog that pretty much sums up what has been announced.

http://www.wooditwork.com – Justin Wood’s Blog

Troubleshooting a vCloud Director Installation

The problem about working full time is it’s really hard to find time to blog, and also to find topics to blog about! =)

One of the great things about my job is we have a solution centre in the office which allows me to play around with kit! =)
Our solution centre is based around an EMC VSPEX architecture….. so EMC VNX storage, Cisco UCS blades and VMware virtualisation!!

I’ve been busy the last week or so putting together a vCloud solution for some of the engineers to play around with, as well as finally completing the detailed installation guide for deploying the vCloud Suite (one of these days I promise I will post it up).

Anyways, so I ended up installing two RHEL 6.2 VMs as my vCD cells on a MS SQL 2008 R2 DB, load-balanced using a vCNS edge….. but when I tried to start the vCD services on my linux VMs, they would say they’ve started (simple service vmware-vcd status command) but wouldn’t give me the vCD web console/UI….. all I got was a Blank Grey Webpage and after a while it would error out saying it couldn’t connect to the website!! Hmmmm……

Anyways, this gave me a good opportunity to test out my troubleshooting skills and offer a topic for my blog! =)

So here goes……

Troubleshooting vCD….

The Log files for vCloud Director are located at /opt/vmware/vcloud-director/logs. There are three main files to look at (well there’s more than 3 but these are the ones I usually use and 99% of the time I can work out what’s wrong):

1. cell.log

This log file provides information on the status of the vCloud Director cell services and the application as it starts up.
Use tail -f cell.log to view the live status when starting a vCloud Director Cell.
A successful start up will allow you to access the vCD web-console/UI and will display a started status for each service, plus 100% for Application Initialization.
Image

Usually if there is an issue with accessing the web-front end UI then it is more than likely that the services are still waiting to complete, as below:

Image

If you’re seeing lots of services showing a “WAITING” status, then check the other logs to determine what could be causing this issue.

2. vmware-vcd-watchdog.log

This log file shows any alerts, errors or information that the vCloud Director cell services maybe experiencing. A healthy vmware-vcd-watchdog.log looks similar to the below:

Image

If there’s an issue, then you could get an ‘Alert’ entry, similar to the one below:

Image

I believe vCloud Director will automatically try to re-start the services as I didn’t see a time stamp for an entry when I manually restarted the service. Also this log looks very similar to what you would get if you typed in ‘service vmware-vcd status‘ as that command reports on both the vmware-vcd-watchdog and vmware-vcd-cell services.

3. vcloud-container-info.log

This log file shows the status of the initial installation of vCloud Director and will log how the application is currently functioning. If you have any errors or failures during installation, this log file will provide you with the details required to troubleshoot the cause of the failure.
In addition, this log will also provide information on any errors that may cause the vCloud Director services to fail to start.
In my case, after doing a cat vcloud-container-info.log | more I discovered the following error:

Image

Turns out that the error shows that the vCloud Director cell could not resolve its hostname in DNS.

When I went through the pre-reqs before installation, I realised that I had only put in DNS entries for the two IPs used for the HTTP and the Remote Console access….. I forgot to put an entry into DNS that resolved the hostname of the Linux VM to the HTTP IP address.
A quick edit to DNS and then a restart of the vCD services fixed the problem I experienced.

4. vcloud-container-debug.log

This log file shows the debugging information. The detail in this log file will be dependant upon the level of debugging set. I didn’t actually end up looking at this log as the error was discovered in the -info.log…. However, it’s another port of call if you can’t work out what’s causing your vCD services to fail.

Rights….. blog entry over…… I’m off to eat my dinner! =)