Virtual SAN introduces specific terms and definitions that are important to understand.
Before you get started with Virtual SAN, review the key Virtual SAN terms and definitions.
Disk group
A disk group is a unit of physical storage capacity on a host and a group of physical devices that provide performance and capacity to the Virtual SAN cluster. On each ESXi host that contributes its local devices to a Virtual SAN cluster, devices are organized into disk groups.
Each disk group must have one flash cache device and one or multiple capacity devices. The devices used for caching cannot be shared across disk groups, and cannot be used for other purposes. A single caching device must be dedicated to a single disk group. In hybrid clusters, flash devices are used for the cache layer and magnetic disks are used for the storage capacity layer. In an all-flash cluster, flash devices are used for both cache and capacity. For information about creating and managing disk groups, see Device Management in a Virtual SAN Cluster.
Consumed capacity
Consumed capacity is the amount of physical capacity consumed by one or more virtual machines at any point. Consumed capacity is determined by many factors, including the consumed size of your VMDKs, protection replicas, and so on. When calculating for cache sizing, do not consider the capacity used for protection replicas.
Object-based storage
Virtual SAN stores and manages data in the form of flexible data containers called objects. An object is a logical volume that has its data and metadata distributed across the cluster. For example, every VMDK is an object, as is every snapshot. When you provision a virtual machine on a Virtual SAN datastore, Virtual SAN creates a set of objects comprised of multiple components for each virtual disk. It also creates the VM home namespace, which is a container object that stores all metadata files of your virtual machine. Based on the assigned virtual machine storage policy, Virtual SAN provisions and manages each object individually, which might also involve creating a RAID configuration for every object.
- Virtual SAN verifies that the virtual disk requirements are applied according to the specified virtual machine storage policy settings.
- Virtual SAN verifies that the correct cluster resources are utilized at the time of provisioning. For example, based on the protection policy, Virtual SAN determines how many replicas to create. The performance policy determines the amount of flash read cache allocated for each replica and how many stripes to create for each replica and where to place them in the cluster.
- Virtual SAN continually monitors and reports the policy compliance status of the virtual disk. If you find any noncompliant policy status, you must troubleshoot and resolve the underlying problem.
Note: When required, you can edit VM storage policy settings. Changing the storage policy settings does not affect virtual machine access. Virtual SAN actively throttles the storage and network resources used for reconfiguration to minimize the impact of object reconfiguration to normal workloads. When you change VM storage policy settings, Virtual SAN might initiate an object recreation process and subsequent resynchronization. See About Virtual SAN Cluster Resynchronization.
- Virtual SAN verifies that the required protection components, such as mirrors and witnesses, are placed on separate hosts or fault domains. For example, to rebuild components during failure, Virtual SAN looks for ESXi hosts that satisfy the placement rules where protection components of virtual machine objects must be placed on two different hosts (not on the same host), or across different fault domains.
Virtual SAN datastore
After you enable Virtual SAN on a cluster, a single Virtual SAN datastore is created. It appears as another type of datastore in the list of datastores that might be available, including Virtual Volume, VMFS, and NFS. A single Virtual SAN datastore can provide different service levels for each virtual machine or each virtual disk. In vCenter Server®, storage characteristics of the Virtual SAN datastore appear as a set of capabilities. You can reference these capabilities when defining a storage policy for virtual machines. When you later deploy virtual machines, Virtual SAN uses this policy to place virtual machines in the optimal manner based on the requirements of each virtual machine. For general information about using storage policies, see the vSphere Storage documentation.
- Virtual SAN provides a single Virtual SAN datastore accessible to all hosts in the cluster, whether or not they contribute storage to the cluster. Each host can also mount any other datastores, including Virtual Volumes, VMFS, or NFS.
- You can use Storage vMotion to move virtual machines between the Virtual SAN datastores, NFS and VMFS datastores.
- Only magnetic disks and flash devices used for capacity can contribute to the datastore capacity. The devices used for flash cache are not counted as part of the datastore.
Objects and components
Each object is composed of a set of components, determined by capabilities that are in use in the VM Storage Policy. For example, when the Primary level of failures to tolerate policy configured to one, Virtual SAN ensures that the protection components, such as replicas and witnesses of the object are placed on separate hosts in the Virtual SAN cluster, where each replica is an object component. In addition, in the same policy, if the Number of disk stripes per object configured to two or more, Virtual SAN also stripes the object across multiple capacity devices and each stripe is considered a component of the specified object. When needed, Virtual SAN might also break large objects into multiple components.
A Virtual SAN datastore contains the following object types:
- VM Home Namespace
- The virtual machine home directory where all virtual machine configuration files are stored, such as .vmx, log files, vmdks, snapshot delta description files, and so on.
- VMDK
- A virtual machine disk or .vmdk file that stores the contents of the virtual machine's hard disk drive.
- VM Swap Object
- Created when a virtual machine is powered on.
- Snapshot Delta VMDKs
- Created when virtual machine snapshots are taken.
- Memory object
- Created when the snapshot memory option is selected when creating or suspending a virtual machine.
Virtual Machine Compliance Status: Compliant and Noncompliant
A virtual machine is considered noncompliant when one or more of its objects fail to meet the requirements of its assigned storage policy. For example, the status might become noncompliant when one of the mirror copies is inaccessible. If your virtual machines are in compliance with the requirements defined in the storage policy, the status of your virtual machines is compliant. From the Physical Disk Placement tab on the Virtual Disks page, you can verify the virtual machine object compliance status. For information about troubleshooting a Virtual SAN cluster, see Handling Failures in Virtual SAN.
Component State: Degraded and Absent states
- Degraded. A component is Degraded when Virtual SAN detects a permanent component failure and determines that the failed component will never recover to its original working state. As a result, Virtual SAN starts to rebuild the degraded components immediately. This state might occur when a component is on a failed device.
- Absent. A component is Absent when Virtual SAN detects a temporary component failure where components, including all its data, might recover and return Virtual SAN to its original state. This state might occur when you are restarting hosts or if you unplug a device from a Virtual SAN host. Virtual SAN starts to rebuild the components in absent status after waiting for 60 minutes.
Object State: Healthy and Unhealthy
- Healthy. When at least one full RAID 1 mirror is available, or the minimum required number of data segments are available, the object is considered healthy.
- Unhealthy. When no full mirror is available or the minimum required number of data segments are unavailable for RAID 5 or RAID 6 objects; or fewer than 50 percent of an object’s votes are available. This may be due to multiple failures in the cluster. When the operational status of an object is considered unhealthy, it impacts the availability of the associated VM.
Witness
A witness is a component that contains only metadata and does not contain any actual application data. It serves as a tiebreaker when a decision needs to be made regarding the availability of the surviving datastore components, after a potential failure. A witness consumes approximately 2 MB of space for metadata on the Virtual SAN datastore when using on-disk format 1.0 and 4 MB for on-disk format for version 2.0 and later.
Virtual SAN 6.0 and later maintains quorum with an asymmetrical voting system where each component might have more than one vote to decide the availability of objects. Greater than 50 percent of the votes that make up a VM’s storage object must be accessible at all times for the object to be considered available. When 50 percent or fewer votes are accessible to all hosts, the object is no longer available to the Virtual SAN datastore. This impacts the availability of the associated VM.
Storage Policy-Based Management (SPBM)
When you use Virtual SAN, you can define virtual machine storage requirements, such as performance and availability, in the form of a policy. Virtual SAN ensures that the virtual machines deployed to Virtual SAN datastores are assigned at least one virtual machine storage policy. When you know the storage requirements of your virtual machines, you can define storage policies and assign the policies to your virtual machines. If you do not apply a storage policy when deploying virtual machines, Virtual SAN automatically assigns a default Virtual SAN policy with Primary level of failures to tolerate configured to one, a single disk stripe for each object, and thin provisioned virtual disk. For best results, you should define your own virtual machine storage policies, even if the requirements of your policies are the same as those defined in the default storage policy. For information about working with Virtual SAN storage policies, see Using Virtual SAN Policies.
Ruby vSphere Console (RVC)
The Ruby vSphere Console (RVC) provides a command-line interface used for managing and troubleshooting the Virtual SAN cluster. RVC gives you a cluster-wide view, instead of the host-centric view offered by esxcli. RVC is bundled with vCenter Server Appliance and vCenter Server for Windows, so you do not need to install it separately. For information about the RVC commands, see the RVC Command Reference Guide.
vSphere PowerCLI
VMware vSphere PowerCLI adds command-line scripting support for Virtual SAN, to help you automate configuration and management tasks. vSphere PowerCLI provides a Windows PowerShell interface to the vSphere API. PowerCLI includes cmdlets for administering Virtual SAN components. For information about using vSphere PowerCLI, see vSphere PowerCLI Documentation.
Virtual SAN Observer
The VMware Virtual SAN Observer is a Web-based tool that runs on RVC and is used for in-depth performance analysis and monitoring of the Virtual SAN cluster. Use Virtual SAN Observer for information about the performance statistics of the capacity layer, detailed statistical information about physical disk groups, current CPU usage, consumption of Virtual SAN memory pools, and physical and in-memory object distribution across Virtual SAN clusters.
For information about configuring, launching, and using RVC and the Virtual SAN Observer, see the Virtual SAN Troubleshooting Reference Manual.
