Objective Topics:
- Explain VSAN and VVOL architectural components
- Determine the role of storage providers in VSAN
- Determine the role of storage providers in VVOLs
- Explain VSAN failure domains functionality
- Configure/Manage VMware Virtual SAN
- Create/Modify VMware Virtual Volumes (VVOLs)
- Configure Storage Policies
- Enable/Disable Virtual SAN Fault Domains
- Create Virtual Volumes given the workload and availability requirements
- Collect VSAN Observer output
- Create storage policies appropriate for given workloads and availability requirements
- Configure VVOLs Protocol Endpoints
Explain VSAN and VVOL Architectural Components
TBD
Determine the role of Storage Providers in vSAN
The Virtual SAN storage providers report a set of underlying storage capabilities to vCenter Server. They also communicate with the Virtual SAN layer to report the storage requirements of the virtual machines.
Virtual SAN registers a separate storage provider for each host in the Virtual SAN cluster, using the following URL: http://host_ip:8080/version.xml where host_ip is the actual IP of the host. Verify that the storage providers are registered.
Virtual SAN storage providers are built-in software components that communicate storage capabilities of the datastore to vCenter Server.
Source: vSAN Administration Guide 6.0 (page 79)
Determine the role of storage providers in VVOLs (VASA Providers)
A Virtual Volumes storage provider, also called a VASA provider, is a software component that acts as a storage awareness service for vSphere. The provider mediates out-of-band communication between vCenter Server and ESXi hosts on one side and a storage system on the other.
The storage provider is implemented through VMware APIs for Storage Awareness (VASA) and is used to manage all aspects of Virtual Volumes storage. The storage provider integrates with the Storage Monitoring Service (SMS), shipped with vSphere, to communicate with vCenter Server and ESXi hosts.
The storage provider delivers information from the underlying storage, or storage container in the case of Virtual Volumes, so that storage container capabilities can appear in vCenter Server and the vSphere Web Client. Then, in turn, the storage provider communicates virtual machine storage requirements, which you can define in the form of a storage policy, to the storage layer. This integration process ensures that a virtual volume created in the storage layer meets the requirements outlined in the policy.
Explain VSAN failure domains functionality
A fault domain consists of one or more Virtual SAN hosts grouped together according to their physical location in the data center. When configured, fault domains enable Virtual SAN to tolerate failures of entire physical racks as well as failures of a single host, capacity device, network link or a network switch dedicated to a fault domain.
Fault Domain Best Practices:
- Minimum of 3 fault domains in the vSAN Cluster
- A host not included in any fault domain is considered to reside in its own single-host fault domain.
- Not every vSAN cluster needs to be assigned to a fault domain. But if so, create equal sized fault domains.
- When moved to another cluster, vSAN hosts retain their fault domain assignments
- When designing fault domain, recommended to configure fault domains with uniform number of hosts.
- You can add any number of hosts to a fault domain. Each fault domain must contain at least 1 host.
Configure/Manage VMware Virtual SAN
I’m going to use a vDS switch for my vSAN Network. I’ll create it the same way I created my others in previous posts.
I’ll add 2 additional virtual disks to my nested ESXi hosts in VM Workstation. I just added small disks for proof of concept.
I rebooted by hosts, but you can simply rescan the disks to get the disks to show up.
Turn off HA if enabled. Then enable vSAN on the cluster.
I chose disk claiming ‘manual’.
Looks like we’re good to go from here.
Turn HA back on, if you’d like.