Tuesday, January 10, 2017

vSAN Availability Part 10 - Stretched Cluster Preferred and Secondary Fault Domains

A vSAN stretched cluster consists of exactly three sites or, more accurately, three fault domains: The Preferred fault domain, the Secondary fault domain, and the Witness fault domain. This short article explains the difference between the Preferred and Secondary fault domains and how this difference affects recovery based on the type of failure.

Wednesday, December 14, 2016

vSphere Data Protection (VDP) - SSO server could not be found

I ran into the following error while working with VDP: The SSO server could not be found. Please make sure the SSO configuration on the VDP appliance is correct. There is a KB article on this: http://kb.vmware.com/kb/2072033. After reading through the article and checking those items, the issue was still not resolved.

Monday, December 12, 2016

OVF Choices When Deploying vSphere Replication 6.5

VMware vSphere Replication 6.5 is the latest version of vSphere Replication (VR) released with vSphere 6.5, vCenter Server 6.5, and Site Recovery Manager (SRM) 6.5. VR is a host-based virtual machine (VM) replication solution that works with nearly any storage type supported by vSphere. VR is deployed as a virtual appliance using an Open Virtualization Format (OVF) specification found on the VR ISO that is downloaded from vmware.com. While more general information on VR can be found here, this article focuses on the various OVFs that are found on the VR ISO and what the use cases are for each.

Monday, December 5, 2016

vSAN Availability Part 9 - Configuring a Stretched Cluster

A vSAN stretched cluster configuration provides a simple solution for extending a vSAN cluster across geographically disbursed locations. These locations could be opposite sides of a data center with separate power feeds or two different cities. Stretched clusters enable rapid recovery from site failure with no data loss. They also provide an excellent option for migrating workloads between locations with zero downtime if maintenance at one site or the other is needed. For more of an introduction to vSAN stretched clusters, take a look at the previous article (Part 8) in this blog series.

This article covers the simplicity of configuring a vSAN stretched cluster complete with a video demo. Before we get to the video, let's take a moment to cover the main prerequisites that must be in place prior to configuring the stretched cluster. For starters, note that stretched clusters are supported with vSAN versions 6.1 and higher and vSAN Enterprise licensing is required for this feature.

Monday, November 7, 2016

vSphere Replication Target Storage Consumption

How Much Space Will Be Consumed?

vSphere Replication is an asynchronous, host-based replication feature that is included with vSphere Essentials Plus Kit and higher editions. It can be used as a standalone solution for simple, storage-agnostic, cost-effective virtual machine replication. vSphere Replication also serves as a replication component for VMware Site Recovery Manager (SRM) and VMware vCloud Air Disaster Recovery. When replication is configured for a powered on virtual machine, vSphere Replication starts replicating the files that make up the virtual machine from the source location to the target location. A question that comes up sometimes is “How much storage will be consumed by the virtual machine at the target location?” As with many questions like this, the short answer is “It depends.”   🙂

Friday, November 4, 2016

vSAN Availability Part 8 - Intro to vSAN Stretched Clusters

First, Virtual SAN's New Name: vSAN

The previous seven blog articles are titled "Virtual SAN Availability..." and this article starts with "vSAN". Why the name change you ask? Duncan Epping discusses it in this blog article: Virtual SAN >> vSAN, and grown to 5500 customers.

Now that the name change is out of the way, let's get back to the topic of vSAN availability. Earlier posts discussed availability within a single site. The next few articles will cover resiliency across sites using a vSAN stretched cluster. We will begin with a short introduction to this vSAN feature.

Monday, October 10, 2016

Virtual SAN Availability Part 7 - Degraded Disk Handling (DDH)

Degraded Disk Handling (DDH)

While this blog series focuses on availability, performance is certainly worth mentioning. In many cases, a poorly performing application or platform can be the equivalent of offline. For example, excessive latency (network, disk, etc.) can cause a database query to take much longer than normal. If an end-user expects query results in 30 seconds and suddenly it takes 10 minutes, it is likely the end-user will stop using the application and report the issue to IT - same result as the database being offline altogether.

A cache or capacity device that is constantly producing errors and/or high latencies can have a similar negative effect on a Virtual SAN (VSAN) cluster. This can impact multiple workloads in the cluster. Prior to VSAN 6.1, a badly behaving disk caused issues in a hand-full of cases, which led to another VSAN availability feature. It is commonly called Dying Disk Handling, Degraded Disk Handling, or simply "DDH".

Virtual SAN (VSAN) 6.1 and newer versions monitor cache and capacity devices for issues such as excessive latency and errors. These symptoms can be indicative of an imminent drive failure. Monitoring these conditions enables VSAN to be proactive in correcting conditions such as excessive latencies, which negatively affects performance and availability. Depending on the version of VSAN you are running, you might see varying responses to disks that are behaving badly.