I just learnt this morning that the paper edition of the Essential Virtual SAN (VSAN) book that I wrote with my colleague and good pal Duncan Epping is now available. The e-book and kindle versions were available a couple of weeks ago, but its great to see the paper edition hit the shelves. The book will hopefully have all you need to get you up and running with VSAN, including architecture details and design considerations. We tried to include everything that someone involved in VSAN administration would need.
I can now appreciate the time and effort that authors put into writing books. This is my first book, and although I had written a number of white papers and presentations in the past, this was something very new for me. Thanks again to Duncan for his help with getting this project up and running, to Christos and Paudie for reviewing the content, and of course to VMware Press for agreeing to publish it. I hope you find the book useful. Go VSAN!
I was involved in an interesting thread recently with one of our VSAN partners regarding disk sizes used in VSAN, and what impact smaller drives may have. In an earlier post, I discussed reasons why VSAN would stripe a VMDK storage object even though a stripe width was not requested in the VM Storage Policy – Why is my Storage Object striped?
In that post, I highlighted the fact that if the VMDK storage object is too big to fit onto the free space of a single hard disk, then it will automatically be striped across multiple hard disks. However there is another VSAN object that disks size may also impact – the VM Home Namespace.
In this next test of vSphere Data Protection (VDP) interoperability, I wanted to see if a restored vCenter Server appliance would still be able to work with pre-configured vCloud Suite products such as vCenter Operations (vCops), vCloud Automation Center (vCAC), vSphere Orchestrator VCO and Network Virtualization (NSX). All of these products were running to some extent in my environment; vCAC had a simple blueprint for VM deployment, VCO had a simple workflow for renaming a VM and NSX included an Edge device providing a DHCP service. If all of this functionality was still in place post restore, then the backup and restore will have worked. Testing was done with vCenter Server appliance version 5.5U1 and VDP version 18.104.22.168.
In this third article in the series of backing up the vCloud Suite, we turn our attentions to NSX, VMware’s Network Virtualization product. Before starting, I should point out that NSX has a recommended way of backing up and restoring configuration information via the use of an FTP server, which you need to configure in your infrastructure to hold this exported metadata. However this exercise looks at how you might be able to use VDP to back up and restore an NSX configuration using image level backups. Once again, I wanted to see whether I could restore the NSX environment to a particular point in time, in-place and also by restoring to a new location. This is the same infrastructure that I used for backing up and restoring vCops and backing up and restoring vCAC and VCO. On this occasion, I was using NSX version 6.0.4, vCenter 5.5U1 and VDP version 22.214.171.124.
This post is a follow on to a previous post I did on vCops and VDP interop. In this scenario, I am going to try to use vSphere Data Protection (VDP), which is VMware’s Backup/Restore product, to back up and restore a vCloud Automation Center (vCAC) v6.0.1. and vCenter Orchestration (VCO) v5.5 deployment.
In this particular scenario, there are nine virtual machines making up my vCAC and VCO deployment. VCO has been deployed in a HA configuration, which accounts for two VMs. The others make up the DEM, Manager, Web, vCAC, SSO and various databases for vCloud Automation Center.
I was in a conversation with one of my pals over at Tintri last week (Fintan), and he observed some strange behaviour when provisioning VMs from a catalog in vCloud Director (vCD). When he disabled Fast Provisioning, he expected that provisioning further VMs from the catalog would still be offloaded via the VAAI-NAS plugin. All the ESXi hosts have the VAAI-NAS plugin from Tintri installed. However, it seems that the provisioning/cloning operation was not being offloaded to the array, and the ESXi hosts resources were being used for the operation instead. Deployments of VMs from the catalogs were taking minutes rather than seconds. What was going on?
I’m a bit late in bringing this to your attention, but there is a potential issue with VASA storage providers disconnecting from vCenter resulting in no VSAN capabilities being visible when you try to create a VM Storage Policy. These storage providers (there is one on each ESXi host participating in the VSAN Cluster) provide out-of-band information about the underlying storage system, in this case VSAN. If there isn’t at least one of these providers on the ESXi hosts communicating to the SMS (Storage Monitoring Service) on vCenter, then vCenter will not be able to display any of the capabilities of the VSAN datastore, which means you will be unable to build any further storage policies for virtual machine deployments (currently deployed VMs already using VM Storage Policies are unaffected). Even a resynchronization operation fails to reconnect the storage providers to vCenter. This seems to be predominantly related to vCenter servers which were upgraded to vCenter 5.5U1 and not newly installed vCenter servers.