Virtual SAN Datastore Characteristics

Virtual SAN simplifies storage configuration because there is only a single datastore for VMs. Virtual SAN uses the concept of objects and components for storage of virtual machine data. An object consists of multiple components, which are distributed across a Virtual SAN cluster, based on the assigned policy for the object.

There are currently four different types of objects:

VM home – Location for VM configuration and log files.

Swap – Created for the VM Swap file (only created when the VM powered on).

VMDK – Stores the data which is on a disk.

Delta/snapshot – Created for use when a VM has a snapshot created on it.

Each object can be up to a maximum of 255 GB in size. If objects are larger, they are split into multiple components. Currently, Virtual SAN in vSphere 6.0 can store a maximum of 9000 components per host, which can be a limiting factor as to how far the environment can be scaled. More components will be required for larger and more redundant VMs.

For example, 1 VM with a 500 GB disk (and no snapshots) will always consume:

2 for VM home (failures-to-tolerate always = 1)

2 for VM swap (assuming that there is less than 255 GB of RAM in the machine)

2 for the VM disks (assuming no mirroring and no failures to tolerate)

As a result, sizing the environment appropriately can avoid reaching limits on the configuration. The following sections discuss how to size the datastore and also describe the different considerations to keep in mind:

Disk Group SSD-to-HDD ratios

Failures-to-tolerate policy

Datastore sizing

Finalized cluster and disk group design

Disk Group SDD-to-HDD Ratios

Virtual SAN configuration requires a decision to be made about the appropriate SDD-to-HDD ratio to use. Virtual SAN supports one SSD and a maximum of seven HDDs per disk group. It also allows a maximum of five disk groups per host. Thus, the total amount of space in the configuration can be quite significant.

The more SSD-to-HDD capacity that is configured, the more cache is available for virtual machines. However, this leads to additional costs due to the one SSD per disk group limit. Multiple disk groups will have to be created to accommodate the limit of one SSD per disk group.

Failures-to-Tolerate Policy

The number of failures-to-tolerate policy setting is one of the core availability mechanisms used by Virtual SAN. The policy controls the number of replicas (mirrors) of a virtual machine component. This policy can be applied to all virtual machines or individual VMDKs. This policy is important when planning and sizing storage capacity because it directly relates to the virtual machine’s storage consumption. It can lead to many times greater storage utilization than is actually configured, because of the replicas created. They also consume additional components.

For example, if the number of failures-to-tolerate is set to 1, the VM or disk has two replica mirror copies of components created across the cluster. If the number is set to 2, three mirror copies are created, and so on. If a failure occurs, the mirrored copies are used.

This setting should be configured based on the availability requirements of the virtual machine or disk. These requirements are then defined in a storage policy and applied to the appropriate workloads.

Datastore Sizing

Sizing the Virtual SAN volume can be approached in several ways, depending on the factors that are most important to the environment. All the different policy settings can impact the available space in the cluster. Also, the resultant sizing can mean additional hardware is required or that disk groups must be configured in a specific way.

You can learn more about this sizing task using either the VMware Virtual SAN Sizing Tool (http://virtualsansizing.vmware.com/) or the manual sizing formulas.

Virtual SAN Sizing Tool

To reduce complexities when estimating the size of the Virtual SAN configuration, VMware released the VMware Virtual SAN Sizing Tool (http://virtualsansizing.vmware.com/). To use the tool, simply enter the parameters relevant to a particular site or environment. The calculator will then generate an optimal configuration for you to test and validate.

Manual Sizing Formulas

Determining size manually is a difficult task that consists of using formulas to figure out whether the configuration will support the environment based on the given parameters. Sizing is based on the following:

Cluster capacity

Objects and components

Swap space

Usable capacity

Raw Cluster Capacity

Start by calculating the cluster capacity for the hosts that will be a part of the Virtual SAN cluster.

To calculate raw storage capacity calculations, use the following formula:

Hst x NumDskGrpPerHst x NumDskPerDskGrp x SzHDD = RawClusterCapacity

For example:

8 x 5 x 7 x 4,000GB = 1,120,000 GB = 1,120 TB

Objects and Components

Calculating the number of objects and components that can be stored on a datastore helps to determine the scalability of the Virtual SAN datastore. Calculations should be used to determine that the configuration will not be limited by the size of the environment. The number of objects is based on the virtual machine files, which include the virtual machine home, virtual machine swap file, VMDKs, and snapshots.

To calculate the number of objects, use the following formula:

VMs x [VMnamespace + vmSnap + NumOfVMDK] = NumObjects

For example:

800 x [1 + 1 + 1] = 2,400 Objects

After the number of objects is calculated, you can verify that the scalability performance and availability requirements can be met. The policies dictate the number of components that will be created. Virtual SAN currently supports a maximum of 3,000 components per host.

To calculate the number of components per virtual machine, use the following formula. It accounts for the replicas and witnesses created based on the failures-to-tolerate setting.

NumObject x [ft x 2 + 1] = y

For example:

2,400 x (1 x 2 + 1) = 7,200 components = average 900 components per host

As long as the resulting Virtual SAN datastore does not exceed the limits for Virtual SAN scalability, the configuration is valid. It is often easy to increase the number of components available just by adding hosts to a cluster, if possible.

Swap

In addition to used space for the virtual machine and its corresponding disks, capacity will be consumed by virtual machine swap space. Swap space is not unique to Virtual SAN. It is used for all VMs, and is equal to the amount of RAM that a VM has, subtracting any reservations for memory. Virtual SAN always stores swap space with two replicas, regardless of the Failures to Tolerate setting.

To calculate the disk capacity after swap file consumption, use the following formula:

ClusterCapacity – (VMs x vmSwp x 2) = DiskCapacity

For example:

1,120,000GB – (800 x 10GB x 2) = 1,120,000 – 16,000 = 1,104,000 GB Disk Capacity

Usable Capacity

Finally, the Virtual SAN usable capacity is the amount of capacity that can be used to store the VMDK files of virtual machines. The usable capacity is determined by subtracting the Virtual SAN overhead from the disk capacity and then dividing the remaining amount by the number of failures-to-tolerate plus 1.

The formula is as follows:

(DiskCapacity – DskGrp x DskPerDskGrp x Hst x VSANoverhead ) / (ftt + 1)

For example:

(1,104,000GB – 280GB) / (ftt + 1) = 1,103,720GB / (2) = 551,860 GB Usable Capacity

In this example, out of approximately 1,120 GB of raw capacity, users can create VMDKs that, in total, consume 551 GB. The remainder is consumed primarily by replicas created for availability and by virtual machine swap space.

In practice, no more than 80 percent of this capacity should be allocated to virtual machines, to allow for other factors, such as snapshots and working space. Also, the total number of components must remain within the limit of 3,000 per host. In this case, there are 900 components per host, but an increase in the number of disks per virtual machine, stripes per object, or snapshots will contribute to a higher component count.

| | The calculation should be repeated for different configurations as appropriate. This assumes a uniform configuration for all VMs. However, in reality, often many different sizes are used in the environment. | | --- | --- |