This is quite a unique aspect of VSAN, and plays directly into what I believe to be one of the crucial factors of software defined storage. Its probably easier to use an example to explain the concept of how being able to change storage policies on the fly is such a cool feature. Let’s take a scenario where an administrator has deployed a VM with the default VM storage policy, which is that the VM Storage objects should have no disk striping and should tolerate one failure.The layout of the VM could look something like this: The admin then notices…
In this next post, I will examine some failure scenarios. I will concentrate of ESXi host failures, but suffice to say that a disk or network failure can also have consequences for virtual machines running on VSAN. There are two host failure scenarios highlighted below which can impact a virtual machine running on VSAN: An ESXi host, on which the VM is not running but has some of its storage objects, suffers a failure An ESXi host, on which the VM is running, suffers a failure Let’s look at these failures in more detail.
I will start with a caveat. The plan is to support both Solid State Disks and PCIe flash devices on VSAN. However, for the purposes of this post, I will refer to this flash resource as an SSD for simplicity. SSDs serve two purposes in VSAN. They act as both a read cache and a write buffer. This dramatically improves the performance of virtual machines running on the vsanDatastore. In some respects VSAN can be compared to a number of ‘hybrid’ storage solutions in the market, which also use a combination of SSD & HDD to boost the performance of…
In this post, the VSAN capabilities are examined in detail. These capabilities, which are surfaced by the VASA storage provider when the cluster is configured successfully, are used to set the availability, capacity & performance policies on a per VM basis when that VM is deployed on the vsanDatastore. There are 5 capabilities in the initial release of VSAN, as shown below. I will also try to highlight where you should use a non-default value for these capabilities.
The creation of a VSAN cluster is identical in many respects to how a vSphere administrator might create a DRS or vSphere HA cluster. A cluster object is created in the vCenter inventory, and one can either choose to enable the VSAN cluster functionality and then add in the hosts to the cluster, or add the hosts first, and then enable VSAN. When you enable the VSAN functionality on the cluster, a single option is displayed asking the administrator to choose a manual or automatic (default) cluster. This simply refers to whether the vSphere administrator would like VSAN to discover…
VASA, originally introduced in vSphere 5.0, are an extension of the vSphere Storage APIs. VASA is shorthand for vSphere Storage APIs for Storage Awareness. It initially allowed storage arrays to integrate with vCenter for management functionality via server-side plug-ins or Vendor Providers. The storage provider exists on either the storage array service processor or it may also be a standalone host – this is at the discretion of the vendor. In the case of VSAN, it also uses VASA, but interestingly the storage provider is now placed on the ESXi host. Read on to learn more.
One of the most important concepts to understand in VSAN, in my opinion, is the notion of storage objects and components. Virtual Machines deployed on a vsanDatastore on VSAN 5.5 may have 4 different kinds of storage objects associated with it: The Virtual Machine home or “namespace directory” A swap object (if the virtual machine is powered on) Virtual disks/VMDKs Delta-disks created for snapshots. Each delta-disk is an object. [Update: Additional objects types were introduced in later versions of VSAN, but these were the objects in VSAN 5.5]