Over the past month or so, I’ve been looking at disaster recovery of some of the vCloud Suite components. My experiences of using vSphere Replication and Site Recovery Manager to protect and recover vCenter Operations Manager in the event of a disaster can be found here and here. Now it was time to look at vCenter Orchestrator (vCO) to see if that could be protected and recovered.
In this configuration, I deployed vCO in HA mode, meaning that there were two vCenter Orchestrator servers, one running and one in standby mode. The database for vCO was an external SQL Server database, running in its own VM. So there were three VMs to protect in this setup.
I have been doing a bunch of stuff around disaster recovery (DR) recently, and my storage of choice at both the production site and the recovery site has been VSAN, VMware Virtual SAN. I have already done a number of tests already with products like vCenter Server, vCenter Operations Manager and NSX, our network virtualization product. Next up was VCO, our vCenter Orchestrator product. I set up vSphere Replication for my vCO servers (I deployed them in a HA configuration) and their associated SQL DB VM on Friday, but when I got in Monday morning, I could not log onto my vCenter. The problem was that my vCenter was running on VSAN (a bit of a chicken and egg type situation), so how do I troubleshoot this situation without my vCenter. And what was the actual problem? Was it a VSAN issue? This is what had to be done to resolve it.
I’ve been working on some Disaster Recovery (DR) scenarios recently with my good pal Paudie. Last month we looked at how we might be able to protect vCenter Operation Manager, by using a vApp construct and also using IP customization. After VMworld, we turned our attention to NSX, and how we might be able to implement a DR solution for NSX. This is still a work in progress, but we did learn some very useful NSX troubleshooting commands that I thought would be worth sharing with you.
Yesterday saw the release of vCloud Suite 5.8. While there are quite a few new enhancements to the VMware product line in this release, what really jumped out at me were the new PowerCLI cmdlets for Storage Policy Based Management (SPBM). SPBM is a critical component of VIrtual SAN (VSAN), and will play a major role in the Virtual Volumes (VVols) feature which has been tech previewed at VMworld 2014. VVols will enable our storage array partners to implement out Software Defined Storage vision – you can read more about there. So what are the new cmdlets for PowerCLI in the 5.8 release?
A short note to clarify something that has come up a number of times in recent weeks here at VMware. There have been a number of discussions about whether or not we support NFS over IPv6 on vSphere 5.x, and again, on whether or not we support the VAAI-NAS primitives in the same context.
VAAI is an API for offloading tasks to the storage array, but for offloading tasks to NAS arrays, storage vendors need to create their own plugins for the ESXi hosts to achieve this. You can learn more about VAAI-NAS by clicking here. So what about IPv6 support and NFS? And VAAI-NAS?
I guess the next big tech preview at this year’s VMworld was around Virtual Volumes. Yes, we’ve done this before, but this year there were so many vendors showing demos of their VVol implementation, and so many presentations/sessions on the topic that I believe folks are beginning to realize that we are very close indeed to finally having this feature ready. It’s hard to believe that this was first discussed at VMworld 2011, and I alluded to this when I presented a VVol session that I co-delivered with the folks from Nimble Storage at this year’s VMworld.
This topic is going to be huge, and it is going to change the way storage is designed for virtualization environments. And I think almost every storage partner I spoke to at the show is on-board. In fact, “The Register” asked the question last month if there was ANY storage vendor that wasn’t doing a VVol implementation?
I’m not going to get into any technical details of Virtual Volumes in this post – there will be lots of time for this later. Instead, I’m going to share how we believe VVols will now enable Software Defined Storage (SDS) for SAN & NAS arrays, similar to how we have achieved this already with VSAN.
Yesterday was my first day at VMworld 2014. As usual with this event, there are simply so many interesting announcements that it is hard to keep track. However, for me, there were a few things which stood out in the storage space worth calling out. These are specifically VMware focused products and features. I know that many of our partners have also made announcements in the storage space, but for today I concentrated solely on VMware. There are the two that really caught my attention.