- Software-Defined Datacenter
- Software-Defined Storage
- Hyper-Convergence/Server SAN Solutions
- Introducing Virtual SAN
- What Is Virtual SAN?
- What Does VSAN Look Like to an Administrator?
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
What Does VSAN Look Like to an Administrator?
When VSAN is enabled, a single shared datastore is presented to all hosts that are part of the VSAN-enabled cluster. This is the strength of VSAN; it is presented as a datastore. Just like any other storage solution out there, this datastore can be used as a destination for VMs and all associated components, such as virtual disks, swap files, and VM configuration files. When you deploy a new VM, you will see the familiar interface and a list of available datastores, including your VSAN-based datastore, as shown in Figure 1-4.
)
Figure 1-4 Just a normal datastore
This VSAN datastore is formed out of host local storage resources. Typically, all hosts within a VSAN-enabled cluster will contribute performance (flash) and capacity (magnetic disks) to this shared datastore. This means that when your cluster grows, your datastore will grow with it. VSAN is what is called a scale-out storage system (adding hosts to a cluster), but also allows scaling up (adding resources to a host).
Each host that wants to contribute storage capacity to the VSAN cluster will require at least one flash device and one magnetic disk. At a minimum, VSAN requires three hosts in your cluster to contribute storage; other hosts in your cluster could leverage these storage resources without contributing storage resources to the cluster itself. Figure 1-5 shows a cluster that has four hosts, of which three (esxi-01, esxi-02, and esxi-03) contribute storage and a fourth does not contribute but only consumes storage resources. Although it is technically possible to have a nonuniform cluster and have a host not contributing storage, we do highly recommend creating a uniform cluster and having all hosts contributing storage for overall better utilization, performance, and availability.
)
Figure 1-5 Nonuniform VSAN cluster example
Today’s boundary for VSAN in terms of both size and connectivity is a vSphere cluster. This means that at most 32 hosts can be connected to a VSAN datastore. Each host can run a supported maximum of 100 VMs, allowing for a total combined of 3,200 VMs within a 32-host VSAN cluster, of which 2,048 VMs can be protected by vSphere HA.
As you can imagine, with just regular magnetic disks it would be difficult to provide a good user experience when it comes to performance. To provide optimal user experience, VSAN relies on flash. Flash resources are used for read caching and write buffering. Every write I/O will go to flash first, and eventually will be destaged to magnetic disks. For read I/O it will depend, although in a perfect world all read I/O will come from flash. Chapter 5, “Architectural Details,” describes the caching and buffering mechanisms in much greater detail.
To ensure VMs can be deployed with certain characteristics, VSAN enables you to set policies on a per-virtual disk or a per-VM basis. These policies help you meet the defined service level objectives (SLOs) for your workload. These can be performance-related characteristics such as read caching or disk striping, but can also be availability-related characteristics that ensure strategic replica placement of your VM’s disks (and other important files).
If you have worked with VM storage policies in the past, you might now wonder whether all VMs stored on the same VSAN datastore will need to have the same VM storage policy assigned. The answer is no. VSAN allows you to have different policies for VMs provisioned to the same datastore and even different policies for disks from the same VM.
As stated earlier, by leveraging policies, the level of resiliency can be configured on a per-virtual disk granular level. How many hosts and disks a mirror copy will reside on depends on the selected policy. Because VSAN uses mirror copies defined by policy to provide resiliency, it does not require a local RAID set. In other words, hosts contributing to VSAN storage capacity should simply provide a set of disks to VSAN.
Whether you have defined a policy to tolerate a single host failure or, for instance, a policy that will tolerate up to three hosts failing, VSAN will ensure that enough replicas of your objects are created. The following example illustrates how this is an important aspect of VSAN and one of the major differentiators between VSAN and most other virtual storage solutions out there.
EXAMPLE: We have configured a policy that can tolerate one failure and created a new virtual disk. This means that VSAN will create two identical storage objects and a witness. The witness is a component tied to the VM that allows VSAN to determine who should win ownership in the case of a failure. If you are familiar with clustering technologies, think of the witness as a quorum object that will arbitrate ownership in the event of a failure. Figure 1-6 may help clarify these sometimes-difficult-to-understand concepts. This figure illustrates what it would look like on a high level for a VM with a virtual disk that can tolerate one failure. This can be the failure of a host, NICs, disk, or flash device, for instance.
)
Figure 1-6 VSAN failures to tolerate
In Figure 1-6, the VM’s compute resides on the first host (esxi-01) and its virtual disks reside on the other hosts (esxi-02 and esxi-03) in the cluster. In this scenario, the VSAN network is used for storage I/O, allowing for the VM to freely move around the cluster without the need for storage components to be migrated with the compute. This does, however, result in the first requirement to implement VSAN. VSAN requires at a minimum one dedicated 1Gbps NIC port, but VMware recommends a 10GbE for the VSAN network.
Yes, this might still sound complex, but in all fairness, VSAN masks away all the complexity, as you will learn as you progress through the various chapters in this book.