In a previous post related to multiple failures in a vSAN stretched cluster, we showed that if a failure caused the data components to be out of sync, the most recent copy of the data needs to recover before the object becomes accessible again. This is true even if there are a majority of objects available (e.g. old data copy and witness). This is to ensure that we do not recover the “STALE” copy of the data which might have out of date information. To briefly revisit the previous post, the accessibility of the object when there are multiple failures…
Sometime back I wrote an article that described what happens when an object deployed on a vSAN datastore has a policy of Number of Failures to Tolerate set to 1 (FTT=1), and multiple failures are introduced. For simplicity, lets label the three components that make up our object with FTT=1 as A, B and W. A and B are data components and W is the witness component. Let’s now assume that we lose access to component A. Components B & W are still available, and the object (e.g. a VMDK) is still available. The state of these two components (B…
There have been a number of queries around Virtual Volumes (VVols) and replication, especially since the release of KB article 2112039 which details all the interoperability aspects of VVols. In Q1 of the KB, the question is asked “Which VMware Products are interoperable with Virtual Volumes (VVols)?” The response includes “VMware vSphere Replication 6.0.x”. In Q2 of the KB, the question is asked “Which VMware Products are currently NOT interoperable with Virtual Volumes (VVols)?” The response includes “VMware Site Recovery Manager (SRM) 5.x to 6.0.x” In Q4 of the KB, the question is asked “Which VMware vSphere 6.0.x features are…
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…
Earlier this week I spoke about our efforts to failover vCenter Operations Manager (vCops) between two sites. In that article I stated that we used vApp containers at DR site, and added vApp variables to the Analytics and UI VMs at the recovery site. While this was painstaking to set up initially, it did provide us with the ability to failover vCops seamlessly to the DR site, with the vApp VMs inheriting their network settings via the vApp construct. At the end of that post, I mentioned a KB article, 2031891, which discusses the DR of vCops using IP Customization…
I just spent a very useful week looking at how our customers might be able to protect vCenter Operations Manager (vCops) with VMware’s vSphere Replication (vR) and Site Recovery Manager (SRM) products. It was quite tricky to get this to work, if I’m perfectly honest, but that was the whole point of the exercise. What we learnt is being fed back to the various business units within VMware, to see if we can make this more intuitive and less complex to achieve, but if you are interested in knowing how to configure your DR infrastructure to protect vCops, please read…