Administering VMware Virtual SAN
VMware vSphere 6.5
vSAN 6.6
This document supports the version of each product listed and
supports all subsequent versions until the document is
replaced by a new edition. To check for more recent editions of
this document, see http://www.vmware.com/support/pubs.
EN-002503-01
Administering VMware Virtual SAN
You can find the most up-to-date technical documentation on the VMware Web site at:
hp://www.vmware.com/support/
The VMware Web site also provides the latest product updates.
If you have comments about this documentation, submit your feedback to:
docfeedback@vmware.com
Copyright © 2017 VMware, Inc. All rights reserved. Copyright and trademark information.
VMware, Inc.
3401 Hillview Ave.
Palo Alto, CA 94304
www.vmware.com
2 VMware, Inc.
Contents
About VMware Virtual SAN 7
Updated Information 9
1
Introduction to Virtual SAN 11
2
Virtual SAN Concepts 11
Virtual SAN Terms and Denitions 13
Virtual SAN and Traditional Storage 16
Building a Virtual SAN Cluster 17
Integrating with Other VMware Software 17
Limitations of Virtual SAN 18
Requirements for Enabling Virtual SAN 19
3
Hardware Requirements for vSAN 19
Cluster Requirements for Virtual SAN 20
Software Requirements for Virtual SAN 20
Networking Requirements for Virtual SAN 21
License Requirements 21
Designing and Sizing a Virtual SAN Cluster 23
4
Designing and Sizing Virtual SAN Storage Components 23
Designing and Sizing vSAN Hosts 29
Design Considerations for a Virtual SAN Cluster 31
Designing the Virtual SAN Network 32
Best Practices for Virtual SAN Networking 34
Designing and Sizing Virtual SAN Fault Domains 34
Using Boot Devices and vSAN 35
Persistent Logging in a Virtual SAN Cluster 35
VMware, Inc.
Preparing a New or Existing Cluster for Virtual SAN 37
5
Selecting or Verifying the Compatibility of Storage Devices 37
Preparing Storage 38
Providing Memory for Virtual SAN 41
Preparing Your Hosts for Virtual SAN 42
Virtual SAN and vCenter Server Compatibility 42
Preparing Storage Controllers 42
Conguring Virtual SAN Network 43
Considerations about the Virtual SAN License 44
Creating a Virtual SAN Cluster 45
6
Characteristics of a Virtual SAN Cluster 45
3
Administering VMware Virtual SAN
Before Creating a Virtual SAN Cluster 46
Enabling Virtual SAN 47
Using Virtual SAN Conguration Assist and Updates 56
Extending a Datastore Across Two Sites with Stretched Clusters 61
7
Introduction to Stretched Clusters 61
Stretched Cluster Design Considerations 63
Best Practices for Working with Stretched Clusters 64
Network Design for Stretched Clusters 64
Congure Virtual SAN Stretched Cluster 65
Change the Preferred Fault Domain 66
Change the Witness Host 66
Deploying a Virtual SAN Witness Appliance 66
Congure Network Interface for Witness Trac 67
Convert a Stretched Cluster to a Standard Virtual SAN Cluster 69
Increasing Space Eciency in a Virtual SAN Cluster 71
8
Introduction to Virtual SAN Space Eciency 71
Using Deduplication and Compression 71
Using RAID 5 or RAID 6 Erasure Coding 76
RAID 5 or RAID 6 Design Considerations 76
Using Encryption on a Virtual SAN Cluster 77
9
How Virtual SAN Encryption Works 77
Design Considerations for Virtual SAN Encryption 78
Set Up the KMS Cluster 78
Enable Encryption on a New Virtual SAN Cluster 83
Generate New Encryption Keys 83
Enable Virtual SAN Encryption on Existing Virtual SAN Cluster 84
Virtual SAN Encryption and Core Dumps 85
Upgrading the Virtual SAN Cluster 89
10
Before You Upgrade Virtual SAN 89
Upgrade the vCenter Server 91
Upgrade the ESXi Hosts 91
About the Virtual SAN Disk Format 93
Verify the Virtual SAN Cluster Upgrade 97
Using the RVC Upgrade Command Options 98
Device Management in a Virtual SAN Cluster 99
11
Managing Disk Groups And Devices 99
Working with Individual Devices 101
Expanding and Managing a Virtual SAN Cluster 107
12
Expanding a Virtual SAN Cluster 107
Working with Maintenance Mode 111
Managing Fault Domains in Virtual SAN Clusters 113
Using the Virtual SAN iSCSI Target Service 117
4 VMware, Inc.
Migrate a Hybrid Virtual SAN Cluster to an All-Flash Cluster 120
Power o a Virtual SAN Cluster 121
Contents
Using Virtual SAN Policies 123
13
About Virtual SAN Policies 123
View Virtual SAN Storage Providers 126
About the Virtual SAN Default Storage Policy 127
Assign a Default Storage Policy to Virtual SAN Datastores 128
Dene a Virtual Machine Storage Policy for Virtual SAN 129
Monitoring Virtual SAN 131
14
Monitor the Virtual SAN Cluster 131
Monitor Virtual SAN Capacity 132
Monitor Virtual Devices in the Virtual SAN Cluster 133
About Virtual SAN Cluster Resynchronization 133
Monitor Devices that Participate in Virtual SAN Datastores 135
Monitoring Virtual SAN Health 135
Monitoring Virtual SAN Performance 138
About Virtual SAN Cluster Rebalancing 142
Using the Virtual SAN Default Alarms 143
Using the VMkernel Observations for Creating Alarms 145
Handling Failures and Troubleshooting Virtual SAN 147
15
Using esxcli Commands with Virtual SAN 147
Virtual SAN Conguration on an ESXi Host Might Fail 150
Not Compliant Virtual Machine Objects Do Not Become Compliant Instantly 150
Virtual SAN Cluster Conguration Issues 151
Handling Failures in Virtual SAN 152
Shuing Down the Virtual SAN Cluster 164
Index 167
VMware, Inc. 5
Administering VMware Virtual SAN
6 VMware, Inc.
About VMware Virtual SAN
Administering VMware Virtual SAN describes how to congure, manage, and monitor a VMware Virtual SAN
(vSAN) cluster in a VMware vSphere® environment. In addition, Administering VMware Virtual SAN explains
how to organize the local physical storage resources that serve as storage capacity devices in a Virtual SAN
cluster, dene storage policies for virtual machines deployed to Virtual SAN datastores, and manage
failures in a Virtual SAN cluster.
Intended Audience
This information is for experienced virtualization administrators who are familiar with virtualization
technology, day-to-day data center operations, and Virtual SAN concepts.
vSphere Client HTML5 for Virtual SAN
The vSphere Client is a new HTML5-based client that ships with vCenter Server alongside the
vSphere Web Client. The new vSphere Client uses many of the same interface terminologies, topologies, and
workows as the vSphere Web Client. However, the vSphere Client does not support Virtual SAN. Users of
Virtual SAN should continue to use the vSphere Web Client for those processes.
N Not all functionality in the vSphere Web Client has been implemented for the vSphere Client in the
vSphere 6.5 release. For an up-to-date list of unsupported functionality, see Functionality Updates for the
vSphere Client Guide at hp://www.vmware.com/info?id=1413.
VMware, Inc.
7
Administering VMware Virtual SAN
8 VMware, Inc.
Updated Information 1
Administering VMware Virtual SAN is updated with each release of the product or when necessary.
This table provides the update history of Administering VMware Virtual SAN.
Revision Description
EN-002503-01
EN-002503-00 Initial release.
The topic “Congure Network Interface for Witness Trac,” on page 67 was updated to correct the
n
syntax of a command in the procedure.
Additional minor revisions.
n
VMware, Inc. 9
Administering VMware Virtual SAN
10 VMware, Inc.
Introduction to Virtual SAN 2
VMware Virtual SAN (vSAN) is a distributed layer of software that runs natively as a part of the ESXi
hypervisor. Virtual SAN aggregates local or direct-aached capacity devices of a host cluster and creates a
single storage pool shared across all hosts in the Virtual SAN cluster.
While supporting VMware features that require shared storage, such as HA, vMotion, and DRS, Virtual
SAN eliminates the need for external shared storage and simplies storage conguration and virtual
machine provisioning activities.
This chapter includes the following topics:
“Virtual SAN Concepts,” on page 11
n
“Virtual SAN Terms and Denitions,” on page 13
n
“Virtual SAN and Traditional Storage,” on page 16
n
“Building a Virtual SAN Cluster,” on page 17
n
“Integrating with Other VMware Software,” on page 17
n
“Limitations of Virtual SAN,” on page 18
n
Virtual SAN Concepts
VMware, Inc.
VMware Virtual SAN uses a software-dened approach that creates shared storage for virtual machines. It
virtualizes the local physical storage resources of ESXi hosts and turns them into pools of storage that can be
divided and assigned to virtual machines and applications according to their quality of service
requirements. Virtual SAN is implemented directly in the ESXi hypervisor.
You can congure Virtual SAN to work as either a hybrid or all-ash cluster. In hybrid clusters, ash devices
are used for the cache layer and magnetic disks are used for the storage capacity layer. In all-ash clusters,
ash devices are used for both cache and capacity.
You can activate Virtual SAN on your existing host clusters and when you create new clusters. Virtual SAN
aggregates all local capacity devices into a single datastore shared by all hosts in the Virtual SAN cluster.
You can expand the datastore by adding capacity devices or hosts with capacity devices to the cluster.
VMware recommends that the ESXi hosts in the cluster share similar or identical congurations across all
cluster members, including similar or identical storage congurations. This ensures balanced virtual
machine storage components across all devices and hosts in the cluster. Hosts without any local devices also
can participate and run their virtual machines on the Virtual SAN datastore.
If a host contributes its local storage devices to the Virtual SAN datastore, it must provide at least one device
for ash cache and at least one device for capacity, also called a data disk.
11
Administering VMware Virtual SAN
The devices on the contributing host form one or more disk groups. Each disk group contains one ash
cache device, and one or multiple capacity devices for persistent storage. Each host can be congured to use
multiple disk groups.
For best practices, capacity considerations, and general recommendations about designing and sizing a
Virtual SAN cluster, see the VMware Virtual SAN Design and Sizing Guide.
Characteristics of Virtual SAN
This topic summarizes characteristics that apply to Virtual SAN, as well as its clusters and datastores.
Virtual SAN provides numerous benets to your environment.
Table 2‑1. Virtual SAN Features
Supported Features Description
Shared storage support Virtual SAN supports VMware features that require shared storage,
Just a Bunch Of Disks (JBOD) Virtual SAN supports JBOD for use in a blade server environment.
On-disk format Virtual SAN 6.6 supports on-disk virtual le format 5.0, that
All-ash and hybrid congurations Virtual SAN can be congured for all-ash or hybrid cluster.
Fault domains Virtual SAN supports conguring fault domains to protect hosts
Stretched cluster Virtual SAN supports stretched clusters that span across two
Virtual SAN health service Virtual SAN health service includes precongured health check
Virtual SAN performance service Virtual SAN performance service includes statistical charts used to
Integration with vSphere storage features Virtual SAN integrates with vSphere data management features
Virtual Machine Storage Policies Virtual SAN works with VM storage policies to support a VM-
Rapid provisioning Virtual SAN enables rapid provisioning of storage in the vCenter
such as HA, vMotion, and DRS. For example, if a host becomes
overloaded, DRS can migrate virtual machines to other hosts in the
cluster.
If your cluster contains blade servers, you can extend the capacity
of the datastore with JBOD storage that is connected to the blade
servers.
provides highly scalable snapshot and clone management support
per Virtual SAN cluster. For information about the number of
virtual machine snapshots and clones supported per Virtual SAN
cluster, see the Conguration Maximums documentation.
from rack or chassis failure when the Virtual SAN cluster spans
across multiple racks or blade server chassis in a data center.
geographic locations.
tests to monitor, troubleshoot, diagnose the cause of cluster
component problems, and identify any potential risk.
monitor IOPS, throughput, latency, and congestion. You can
monitor performance of a Virtual SAN cluster, host, disk group,
disk, and VMs.
traditionally used with VMFS and NFS storage. These features
include snapshots, linked clones, vSphere Replication, and vSphere
APIs for Data Protection.
centric approach to storage management.
If you do not assign a storage policy to the virtual machine during
deployment, the Virtual SAN Default Storage Policy is
automatically assigned to the VM.
Server® during virtual machine creation and deployment
operations.
12 VMware, Inc.
Virtual SAN Terms and Definitions
Virtual SAN introduces specic terms and denitions that are important to understand.
Before you get started with Virtual SAN, review the key Virtual SAN terms and denitions.
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 ash 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, ash devices are used for the cache layer
and magnetic disks are used for the storage capacity layer. In an all-ash cluster, ash devices are used for
both cache and capacity. For information about creating and managing disk groups, see Chapter 11, “Device
Management in a Virtual SAN Cluster,” on page 99.
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.
Chapter 2 Introduction to Virtual SAN
Object-based storage
Virtual SAN stores and manages data in the form of exible 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 les 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 conguration for every object.
When Virtual SAN creates an object for a virtual disk and determines how to distribute the object in the
cluster, it considers the following factors:
Virtual SAN veries that the virtual disk requirements are applied according to the specied virtual
n
machine storage policy seings.
Virtual SAN veries that the correct cluster resources are utilized at the time of provisioning. For
n
example, based on the protection policy, Virtual SAN determines how many replicas to create. The
performance policy determines the amount of ash 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
n
nd any noncompliant policy status, you must troubleshoot and resolve the underlying problem.
N When required, you can edit VM storage policy seings. Changing the storage policy seings
does not aect virtual machine access. Virtual SAN actively throles the storage and network resources
used for reconguration to minimize the impact of object reconguration to normal workloads. When
you change VM storage policy seings, Virtual SAN might initiate an object recreation process and
subsequent resynchronization. See “About Virtual SAN Cluster Resynchronization,” on page 133.
VMware, Inc. 13
Administering VMware Virtual SAN
Virtual SAN veries that the required protection components, such as mirrors and witnesses, are placed
n
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 dierent hosts (not on the same host), or across dierent 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 dierent 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 dening 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.
A Virtual SAN datastore has specic characteristics to consider.
Virtual SAN provides a single Virtual SAN datastore accessible to all hosts in the cluster, whether or not
n
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
n
VMFS datastores.
Only magnetic disks and ash devices used for capacity can contribute to the datastore capacity. The
n
devices used for ash 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 congured 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 congured to two or more, Virtual SAN also stripes the object
across multiple capacity devices and each stripe is considered a component of the specied 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
VMDK
VM Swap Object
Snapshot Delta VMDKs
Memory object
The virtual machine home directory where all virtual machine conguration
les are stored, such as .vmx, log les, vmdks, snapshot delta description
les, and so on.
A virtual machine disk or .vmdk le that stores the contents of the virtual
machine's hard disk drive.
Created when a virtual machine is powered on.
Created when virtual machine snapshots are taken.
Created when the snapshot memory option is selected when creating or
suspending a virtual machine.
14 VMware, Inc.
Chapter 2 Introduction to Virtual SAN
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 dened 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,” on page 152.
Component State: Degraded and Absent states
Virtual SAN acknowledges the following failure states for components:
Degraded. A component is Degraded when Virtual SAN detects a permanent component failure and
n
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
n
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
Depending on the type and number of failures in the cluster, an object might be in one of the following
states:
Healthy. When at least one full RAID 1 mirror is available, or the minimum required number of data
n
segments are available, the object is considered healthy.
Unhealthy. When no full mirror is available or the minimum required number of data segments are
n
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 dene 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 dene 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 congured to one, a single
VMware, Inc. 15
Administering VMware Virtual SAN
disk stripe for each object, and thin provisioned virtual disk. For best results, you should dene your own
virtual machine storage policies, even if the requirements of your policies are the same as those dened in
the default storage policy. For information about working with Virtual SAN storage policies, see Chapter 13,
“Using Virtual SAN Policies,” on page 123.
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
oered 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
conguration 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 conguring, launching, and using RVC and the Virtual SAN Observer, see the Virtual
SAN Troubleshooting Reference Manual.
Virtual SAN and Traditional Storage
Although Virtual SAN shares many characteristics with traditional storage arrays, the overall behavior and
function of Virtual SAN is dierent. For example, Virtual SAN can manage and work only with ESXi hosts
and a single Virtual SAN instance can support only one cluster.
Virtual SAN and traditional storage also dier in the following key ways:
Virtual SAN does not require external networked storage for storing virtual machine les remotely,
n
such as on a Fibre Channel (FC) or Storage Area Network (SAN).
Using traditional storage, the storage administrator preallocates storage space on dierent storage
n
systems. Virtual SAN automatically turns the local physical storage resources of the ESXi hosts into a
single pool of storage. These pools can be divided and assigned to virtual machines and applications
according to their quality of service requirements.
Virtual SAN has no concept of traditional storage volumes based on LUNs or NFS shares, although the
n
iSCSI target service uses LUNs to enable an initiator on a remote host to transport block-level data to a
storage device in the Virtual SAN cluster.
Some standard storage protocols, such as FCP, do not apply to Virtual SAN.
n
Virtual SAN is highly integrated with vSphere. You do not need dedicated plug-ins or a storage console
n
for Virtual SAN, compared to traditional storage. You can deploy, manage, and monitor Virtual SAN by
using the vSphere Web Client.
A dedicated storage administrator does not need to manage Virtual SAN. Instead a vSphere
n
administrator can manage a Virtual SAN environment.
16 VMware, Inc.
With Virtual SAN usage, VM storage policies are automatically assigned when you deploy new VMs.
n
The storage policies can be changed dynamically as needed.
Building a Virtual SAN Cluster
If you are considering Virtual SAN, you can choose from more than one conguration solution for
deploying a Virtual SAN cluster.
Depending on your requirement, you can deploy Virtual SAN in one of the following ways.
Virtual SAN Ready Node
The Virtual SAN Ready Node is a precongured solution of the Virtual SAN software provided by VMware
partners, such as Cisco, Dell, Fujitsu, IBM, and Supermicro. This solution includes validated server
conguration in a tested, certied hardware form factor for Virtual SAN deployment that is recommended
by the server OEM and VMware. For information about the Virtual SAN Ready Node solution for a specic
partner, visit the VMware Partner web site.
User-Defined Virtual SAN Cluster
You can build a Virtual SAN cluster by selecting individual software and hardware components, such as
drivers, rmware, and storage I/O controllers that are listed in the Virtual SAN Compatibility Guide (VCG)
web site at hp://www.vmware.com/resources/compatibility/search.php. You can choose any servers,
storage I/O controllers, capacity and ash cache devices, memory, any number of cores you must have per
CPU, and so on that are certied and listed on the VCG Web site. Review the compatibility information on
the VCG Web site before choosing software and hardware components, drivers, rmware, and storage I/O
controllers that are supported by Virtual SAN. When designing a Virtual SAN cluster, use only devices,
rmware, and drivers that are listed on the VCG Web site. Using software and hardware versions that are
not listed in the VCG might cause cluster failure or unexpected data loss. For information about designing a
Virtual SAN cluster, see Chapter 4, “Designing and Sizing a Virtual SAN Cluster,” on page 23.
Chapter 2 Introduction to Virtual SAN
Integrating with Other VMware Software
After you have Virtual SAN up and running, it is integrated with the rest of the VMware software stack. You
can do most of what you can do with traditional storage by using vSphere components and features
including vSphere vMotion, snapshots, clones, Distributed Resource Scheduler (DRS), vSphere High
Availability, vCenter Site Recovery Manager, and more.
Integrating with vSphere HA
You can enable vSphere HA and Virtual SAN on the same cluster. As with traditional datastores,
vSphere HA provides the same level of protection for virtual machines on Virtual SAN datastores. This level
of protection imposes specic restrictions when vSphere HA and Virtual SAN interact. For specic
considerations about integrating vSphere HA and Virtual SAN, see “Using Virtual SAN and vSphere HA,”
on page 54.
Integrating with VMware Horizon View
You can integrate Virtual SAN with VMware Horizon View. When integrated, Virtual SAN provides the
following benets to virtual desktop environments:
High-performance storage with automatic caching
n
Storage policy-based management, for automatic remediation
n
For information about integrating Virtual SAN with VMware Horizon, see the VMware Horizon with View
documentation. For designing and sizing VMware Horizon View for Virtual SAN, see the Designing and
Sizing Guide for Horizon View.
VMware, Inc. 17
Administering VMware Virtual SAN
Limitations of Virtual SAN
This topic discusses the limitations of Virtual SAN.
When working with Virtual SAN, consider the following limitations:
Virtual SAN does not support hosts participating in multiple Virtual SAN clusters. However, a Virtual
n
SAN host can access other external storage resources that are shared across clusters.
Virtual SAN does not support vSphere DPM and Storage I/O Control.
n
Virtual SAN does not support SCSI reservations.
n
Virtual SAN does not support RDM, VMFS, diagnostic partition, and other device access features.
n
18 VMware, Inc.
Requirements for Enabling Virtual
SAN 3
Before you activate Virtual SAN, verify that your environment meets all requirements.
This chapter includes the following topics:
“Hardware Requirements for vSAN,” on page 19
n
“Cluster Requirements for Virtual SAN,” on page 20
n
“Software Requirements for Virtual SAN,” on page 20
n
“Networking Requirements for Virtual SAN,” on page 21
n
“License Requirements,” on page 21
n
Hardware Requirements for vSAN
Verify that the ESXi hosts in your organization meet the vSAN hardware requirements.
Storage Device Requirements
All capacity devices, drivers, and rmware versions in your Virtual SAN conguration must be certied and
listed in the Virtual SAN section of the VMware Compatibility Guide.
Table 3‑1. Storage Device Requirements for vSAN Hosts
Storage Component Requirements
Cache
Virtual machine data storage
Storage controllers One SAS or SATA host bus adapter (HBA), or a RAID controller that
VMware, Inc. 19
One SAS or SATA solid-state disk (SSD) or PCIe ash device.
n
Before calculating the Primary level of failures to tolerate,
n
check the size of the ash caching device in each disk group.
Verify that it provides at least 10 percent of the anticipated
storage consumed on the capacity devices, not including
replicas such as mirrors.
vSphere Flash Read Cache must not use any of the ash devices
n
reserved for vSAN cache.
The cache ash devices must not be formaed with VMFS or
n
another le system.
For hybrid group conguration, make sure that at least one SAS,
n
NL-SAS, or SATA magnetic disk is available.
For all-ash disk group conguration, make sure at least one
n
SAS, or SATA solid-state disk (SSD), or PCIe ash device.
is in passthrough mode or RAID 0 mode.
Administering VMware Virtual SAN
Memory
The memory requirements for vSAN depend on the number of disk groups and devices that the ESXi
hypervisor must manage. Each host must contain a minimum of 32 GB of memory to accommodate the
maximum number of disk groups (5) and maximum number of capacity devices per disk group (7).
Flash Boot Devices
During installation, the ESXi installer creates a coredump partition on the boot device. The default size of
the coredump partition satises most installation requirements.
If the memory of the ESXi host has 512 GB of memory or less, you can boot the host from a USB, SD, or
n
SATADOM device. When you boot a vSAN host from a USB device or SD card, the size of the boot
device must be at least 4 GB.
If the memory of the ESXi host has more than 512 GB, you must boot the host from a SATADOM or disk
n
device. When you boot a vSAN host from a SATADOM device, you must use single-level cell (SLC)
device. The size of the boot device must be at least 16 GB.
N vSAN 6.5 and later enables you to resize an existing coredump partition on an ESXi host in a vSAN
cluster, so you can boot from USB/SD devices. For more information, see the VMware knowledge base
article at hp://kb.vmware.com/kb/2147881.
When you boot an ESXi 6.0 or later host from USB device or from SD card, vSAN trace logs are wrien to
RAMDisk. These logs are automatically ooaded to persistent media during shutdown or system crash
(panic). This is the only support method for handling vSAN traces when booting an ESXi from a USB stick
or SD card. If a power failure occurs, vSAN trace logs are not preserved.
When you boot an ESXi 6.0 or later host from a SATADOM device, vSAN trace logs are wrien directly to
the SATADOM device. Therefore it is important that the SATADOM device meets the specications outlined
in this guide.
Cluster Requirements for Virtual SAN
Verify that a host cluster meets the requirements for enabling Virtual SAN.
All capacity devices, drivers, and rmware versions in your Virtual SAN conguration must be certied
n
and listed in the Virtual SAN section of the VMware Compatibility Guide.
A Virtual SAN cluster must contain a minimum of three hosts that contribute capacity to the cluster. For
n
information about the considerations for a three-host cluster, see “Design Considerations for a Virtual
SAN Cluster,” on page 31.
A host that resides in a Virtual SAN cluster must not participate in other clusters.
n
Software Requirements for Virtual SAN
Verify that the vSphere components in your environment meet the software version requirements for using
Virtual SAN.
To use the full set of Virtual SAN capabilities, the ESXi hosts that participate in Virtual SAN clusters must be
version 6.5 or later. During the Virtual SAN upgrade from previous versions, you can keep the current ondisk format version, but you cannot use many of the new features. Virtual SAN 6.6 and later software
supports all on-disk formats.
20 VMware, Inc.
Networking Requirements for Virtual SAN
Verify that the network infrastructure and the networking conguration on the ESXi hosts meet the
minimum networking requirements for Virtual SAN.
Table 3‑2. Networking Requirements for Virtual SAN
Networking Component Requirement
Host Bandwidth Each host must have minimum bandwidth dedicated to Virtual SAN.
Dedicated 1 Gbps for hybrid congurations
n
Dedicated or shared 10 Gbps for all-ash congurations
n
For information about networking considerations in Virtual SAN, see
“Designing the Virtual SAN Network,” on page 32.
Connection between hosts Each host in the Virtual SAN cluster, regardless of whether it
contributes capacity, must have a VMkernel network adapter for
Virtual SAN trac. See “Set Up a VMkernel Network for Virtual
SAN,” on page 47.
Host network All hosts in your Virtual SAN cluster must be connected to a Virtual
SAN Layer 2 or Layer 3 network.
IPv4 and IPv6 support The Virtual SAN network supports both IPv4 and IPv6.
Chapter 3 Requirements for Enabling Virtual SAN
License Requirements
Verify that you have a valid license for Virtual SAN.
Using Virtual SAN in production environments requires a special license that you assign to the Virtual SAN
clusters.
You can assign a standard Virtual SAN license to the cluster, or a license that covers advanced functions.
Advanced features include RAID 5/6 erasure coding, and deduplication and compression. An enterprise
license is required for IOPS limits and stretched clusters. For information about assigning licenses, see
“Congure License Seings for a Virtual SAN Cluster,” on page 52.
The capacity of the license must cover the total number of CPUs in the cluster.
VMware, Inc. 21
Administering VMware Virtual SAN
22 VMware, Inc.
Designing and Sizing a Virtual SAN
Cluster 4
For best performance and use, plan the capabilities and conguration of your hosts and their storage devices
before you deploy Virtual SAN in a vSphere environment. Carefully consider certain host and networking
congurations within the Virtual SAN cluster.
The Administering VMware vSAN documentation examines the key points about designing and sizing a
Virtual SAN cluster. For detailed instructions about designing and sizing a Virtual SAN cluster, see VMware
Virtual SAN Design and Sizing Guide.
This chapter includes the following topics:
“Designing and Sizing Virtual SAN Storage Components,” on page 23
n
“Designing and Sizing vSAN Hosts,” on page 29
n
“Design Considerations for a Virtual SAN Cluster,” on page 31
n
“Designing the Virtual SAN Network,” on page 32
n
“Best Practices for Virtual SAN Networking,” on page 34
n
“Designing and Sizing Virtual SAN Fault Domains,” on page 34
n
“Using Boot Devices and vSAN,” on page 35
n
“Persistent Logging in a Virtual SAN Cluster,” on page 35
n
Designing and Sizing Virtual SAN Storage Components
Plan capacity and cache based on the expected consumption. Consider the requirements for availability and
endurance.
Planning Capacity in Virtual SAN on page 24
n
You can size the capacity of a Virtual SAN datastore to accommodate the virtual machines (VMs) les
in the cluster and to handle failures and maintenance operations.
Design Considerations for Flash Caching Devices in Virtual SAN on page 26
n
Plan the conguration of ash devices for Virtual SAN cache and all-ash capacity to provide high
performance and required storage space, and to accommodate future growth.
Design Considerations for Flash Capacity Devices in Virtual SAN on page 27
n
Plan the conguration of ash capacity devices for Virtual SAN all-ash congurations to provide
high performance and required storage space, and to accommodate future growth.
Design Considerations for Magnetic Disks in Virtual SAN on page 28
n
Plan the size and number of magnetic disks for capacity in hybrid congurations by following the
requirements for storage space and performance.
VMware, Inc.
23
Administering VMware Virtual SAN
Design Considerations for Storage Controllers in Virtual SAN on page 29
n
Include storage controllers on the hosts of a Virtual SAN cluster that best satisfy the requirements for
performance and availability.
Planning Capacity in Virtual SAN
You can size the capacity of a Virtual SAN datastore to accommodate the virtual machines (VMs) les in the
cluster and to handle failures and maintenance operations.
Raw Capacity
To determine the raw capacity of a Virtual SAN datastore, multiply the total number of disk groups in the
cluster by the size of the capacity devices in those disk groups, and subtract the overhead required by the
Virtual SAN on-disk format.
Primary level of Failures to Tolerate
When you plan the capacity of the Virtual SAN datastore, not including the number of virtual machines and
the size of their VMDK les, you must consider the Primary level of failures to tolerate and the Failure
tolerance method aributes of the virtual machine storage policies for the cluster.
The Primary level of failures to tolerate has an important role when you plan and size storage capacity for
Virtual SAN. Based on the availability requirements of a virtual machine, the seing might result in doubled
consumption or more, compared with the consumption of a virtual machine and its individual devices.
For example, if the Failure tolerance method is set to RAID-1 (Mirroring) - Performance and the Primary
level of failures to tolerate (PFTT) is set to 1, virtual machines can use about 50 percent of the raw capacity.
If the PFTT is set to 2, the usable capacity is about 33 percent. If the PFTT is set to 3, the usable capacity is
about 25 percent.
But if the Failure tolerance method is set to RAID-5/6 (Erasure Coding) - Capacity and the PFTT is set to 1,
virtual machines can use about 75 percent of the raw capacity. If the PFTT is set to 2, the usable capacity is
about 67 percent. For more information about RAID 5/6, see “Using RAID 5 or RAID 6 Erasure Coding,” on
page 76.
For information about the aributes in a Virtual SAN storage policy, see Chapter 13, “Using Virtual SAN
Policies,” on page 123.
Calculating Required Capacity
Plan the capacity required for the virtual machines in a cluster with RAID 1 mirroring based on the
following criteria:
1 Calculate the storage space that the virtual machines in the Virtual SAN cluster are expected to
consume.
expected overall consumption = number of VMs in the cluster * expected percentage of
consumption per VMDK
2 Consider the Primary level of failures to tolerate aribute congured in the storage policies for the
virtual machines in the cluster. This aribute directly impacts the number of replicas of a VMDK le on
hosts in the cluster.
datastore capacity = expected overall consumption * (PFTT + 1)
3 Estimate the overhead requirement of the Virtual SAN on-disk format.
On-disk format version 3.0 and later adds an additional overhead, typically no more than 1-2
n
percent capacity per device. Deduplication and compression with software checksum enabled
require additional overhead of approximately 6.2 percent capacity per device.
24 VMware, Inc.
Chapter 4 Designing and Sizing a Virtual SAN Cluster
On-disk format version 2.0 adds an additional overhead, typically no more than 1-2 percent
n
capacity per device.
On-disk format version 1.0 adds an additional overhead of approximately 1 GB per capacity device.
n
Capacity Sizing Guidelines
Keep at least 30 percent unused space to prevent Virtual SAN from rebalancing the storage load. Virtual
n
SAN rebalances the components across the cluster whenever the consumption on a single capacity
device reaches 80 percent or more. The rebalance operation might impact the performance of
applications. To avoid these issues, keep storage consumption to less than 70 percent.
Plan extra capacity to handle potential failure or replacement of capacity devices, disk groups, and
n
hosts. When a capacity device is not reachable, Virtual SAN recovers the components from another
device in the cluster. When a ash cache device fails or is removed, Virtual SAN recovers the
components from the entire disk group.
Reserve extra capacity to make sure that Virtual SAN recovers components after a host failure or when
n
a host enters maintenance mode. For example, provision hosts with enough capacity so that you have
sucient free capacity left for components to successfully rebuild after a host failure or during
maintenance. This is important when you have more than three hosts, so you have sucient free
capacity to rebuild the failed components. If a host fails, the rebuilding takes place on the storage
available on another host, so that another failure can be tolerated. However, in a three-host cluster,
Virtual SAN will not perform the rebuild operation if the Primary level of failures to tolerate is set to 1
because when one host fails, only two hosts remain in the cluster. To tolerate a rebuild after a failure,
you must have at least three hosts.
Provide enough temporary storage space for changes in the Virtual SAN VM storage policy. When you
n
dynamically change a VM storage policy, Virtual SAN might create a layout of the replicas that make
up an object. When Virtual SAN instantiates and synchronizes those replicas with the original replica,
the cluster must temporarily provide additional space.
If you plan to use advanced features, such as software checksum or deduplication and compression,
n
reserve additional capacity to handle the operational overhead.
Considerations for Virtual Machine Objects
When you plan the storage capacity in the Virtual SAN datastore, consider the space required in the
datastore for the VM home namespace objects, snapshots, and swap les.
VM Home Namespace. You can assign a storage policy specically to the home namespace object for a
n
virtual machine. To prevent unnecessary allocation of capacity and cache storage, Virtual SAN applies
only the Primary level of failures to tolerate and the Force provisioning seings from the policy on the
VM home namespace. Plan storage space to meet the requirements for a storage policy assigned to a
VM Home Namespace whose Primary level of failures to tolerate is greater than 0.
Snapshots. Delta devices inherit the policy of the base VMDK le. Plan additional space according to
n
the expected size and number of snapshots, and to the seings in the Virtual SAN storage policies.
The space that is required might be dierent. Its size depends on how often the virtual machine changes
data and how long a snapshot is aached to the virtual machine.
Swap les. Virtual SAN uses an individual storage policy for the swap les of virtual machines. The
n
policy tolerates a single failure, denes no striping and read cache reservation, and enables force
provisioning.
VMware, Inc. 25
Administering VMware Virtual SAN
Design Considerations for Flash Caching Devices in Virtual SAN
Plan the conguration of ash devices for Virtual SAN cache and all-ash capacity to provide high
performance and required storage space, and to accommodate future growth.
Choosing Between PCIe or SSD Flash Devices
Choose PCIe or SSD ash devices according to the requirements for performance, capacity, write endurance,
and cost of the Virtual SAN storage.
Compatibility. The model of the PCIe or SSD devices must be listed in the Virtual SAN section of the
n
VMware Compatibility Guide.
Performance. PCIe devices generally have faster performance than SSD devices.
n
Capacity. The maximum capacity that is available for PCIe devices is generally greater than the
n
maximum capacity that is currently listed for SSD devices for Virtual SAN in the VMware Compatibility
Guide.
Write endurance. The write endurance of the PCIe or SSD devices must meet the requirements for
n
capacity or for cache in all-ash congurations, and for cache in hybrid congurations.
For information about the write endurance requirements for all-ash and hybrid congurations, see the
VMware Virtual SAN Design and Sizing Guide. For information about the write endurance class of PCIe
and SSD devices, see the Virtual SAN section of the VMware Compatibility Guide.
Cost. PCIe devices generally have higher cost than SSD devices.
n
Flash Devices as Virtual SAN Cache
Design the conguration of ash cache for Virtual SAN for write endurance, performance, and potential
growth based on these considerations.
26 VMware, Inc.
Chapter 4 Designing and Sizing a Virtual SAN Cluster
Table 4‑1. Sizing Virtual SAN Cache
Storage Configuration Considerations
All-ash and hybrid congurations
All-ash congurations In all-ash congurations, Virtual SAN uses the cache layer for write
Hybrid congurations If the read cache reservation is congured in the active VM storage
The ash caching device must provide at least 10 percent of the
n
anticipated storage that virtual machines are expected to consume,
not including replicas such as mirrors.
The Primary level of failures to tolerate aribute from the VM
storage policy does not impact the size of the cache.
A higher cache-to-capacity ratio eases future capacity growth.
n
Oversizing cache enables you to easily add more capacity to an
existing disk group without the need to increase the size of the
cache.
Flash caching devices must have high write endurance.
n
When a ash caching device is at the end of its life, replacing it is
n
more complicated than replacing a capacity device because such an
operation impacts the entire disk group.
If you add more ash devices to increase the size of the cache, you
n
must create more disk groups. The ratio between ash cache
devices and disk groups is always 1:1.
A conguration of multiple disk groups provides the following
advantages:
Reduced risk of failure because fewer capacity devices are
n
aected if a single caching device fails
Potentially improved performance if you deploy multiple disk
n
groups that contain smaller ash caching devices.
However, when you congure multiple disk groups, the memory
consumption of the hosts increases.
caching only. The write cache must be able to handle very high write
activities. This approach extends the life of capacity ash that might be
less expensive and might have lower write endurance.
policy for performance reasons, the hosts in the Virtual SAN cluster
must have sucient cache to satisfy the reservation during a postfailure rebuild or maintenance operation.
If the available read cache is not sucient to satisfy the reservation, the
rebuild or maintenance operation fails. Use read cache reservation only
if you must meet a specic, known performance requirement for a
particular workload.
The use of snapshots consumes cache resources. If you plan to use
several snapshots, consider dedicating more cache than the
conventional 10 percent cache-to-consumed-capacity ratio.
Design Considerations for Flash Capacity Devices in Virtual SAN
Plan the conguration of ash capacity devices for Virtual SAN all-ash congurations to provide high
performance and required storage space, and to accommodate future growth.
Choosing Between PCIe or SSD Flash Devices
Choose PCIe or SSD ash devices according to the requirements for performance, capacity, write endurance,
and cost of the Virtual SAN storage.
Compatibility. The model of the PCIe or SSD devices must be listed in the Virtual SAN section of the
n
VMware Compatibility Guide.
Performance. PCIe devices generally have faster performance than SSD devices.
n
VMware, Inc. 27
Administering VMware Virtual SAN
Capacity. The maximum capacity that is available for PCIe devices is generally greater than the
n
maximum capacity that is currently listed for SSD devices for Virtual SAN in the VMware Compatibility
Guide.
Write endurance. The write endurance of the PCIe or SSD devices must meet the requirements for
n
capacity or for cache in all-ash congurations, and for cache in hybrid congurations.
For information about the write endurance requirements for all-ash and hybrid congurations, see the
VMware Virtual SAN Design and Sizing Guide. For information about the write endurance class of PCIe
and SSD devices, see the Virtual SAN section of the VMware Compatibility Guide.
Cost. PCIe devices generally have higher cost than SSD devices.
n
Flash Devices as Virtual SAN Capacity
In all-ash congurations, Virtual SAN does not use cache for read operations and does not apply the readcache reservation seing from the VM storage policy. For cache, you can use a small amount of more
expensive ash that has high write endurance. For capacity, you can use ash that is less expensive and has
lower write endurance.
Plan a conguration of ash capacity devices by following these guidelines:
For beer performance of Virtual SAN, use more disk groups of smaller ash capacity devices.
n
For balanced performance and predictable behavior, use the same type and model of ash capacity
n
devices.
Design Considerations for Magnetic Disks in Virtual SAN
Plan the size and number of magnetic disks for capacity in hybrid congurations by following the
requirements for storage space and performance.
SAS, NL-SAS, and SATA Magnetic Devices
Use SAS, NL-SAS, or SATA magnetic devices by following the requirements for performance, capacity, and
cost of the Virtual SAN storage.
Compatibility. The model of the magnetic disk must be certied and listed in the Virtual SAN section of
n
the VMware Compatibility Guide.
Performance. SAS and NL-SAS devices have faster performance than SATA disks.
n
Capacity. The capacity of SAS, NL-SAS, and SATA magnetic disks for Virtual SAN is available in the
n
Virtual SAN section of the VMware Compatibility Guide. Consider using a larger number of smaller
devices instead of a smaller number of larger devices.
Cost. SAS and NL-SAS devices are more expensive than SATA disks.
n
Using SATA disks instead of SAS and NL-SAS devices is justiable in environments where capacity and
reduced cost have higher priority than performance.
Magnetic Disks as Virtual SAN Capacity
Plan a magnetic disk conguration by following these guidelines:
For beer performance of Virtual SAN, use many magnetic disks that have smaller capacity.
n
You must have enough magnetic disks that provide adequate aggregated performance for transferring
data between cache and capacity. Using more small devices provides beer performance than using
fewer large devices. Using multiple magnetic disk spindles can speed up the destaging process.
28 VMware, Inc.
Chapter 4 Designing and Sizing a Virtual SAN Cluster
In environments that contain many virtual machines, the number of magnetic disks is also important
for read operations when data is not available in the read cache and Virtual SAN reads it from the
magnetic disk. In environments that contain a small number of virtual machines, the disk number
impacts read operations if the Number of disk stripes per object in the active VM storage policy is
greater than one.
For balanced performance and predictable behavior, use the same type and model of magnetic disks in
n
a Virtual SAN datastore.
Dedicate a high enough number of magnetic disks to satisfy the value of the Primary level of failures
n
to tolerate and the Number of disk stripes per object aributes in the dened storage policies. For
information about the VM storage policies for Virtual SAN, see Chapter 13, “Using Virtual SAN
Policies,” on page 123.
Design Considerations for Storage Controllers in Virtual SAN
Include storage controllers on the hosts of a Virtual SAN cluster that best satisfy the requirements for
performance and availability.
Use storage controller models, and driver and rmware versions that are listed in the VMware
n
Compatibility Guide. Search for Virtual SAN in the VMware Compatibility Guide.
Use multiple storage controllers, if possible, to improve performance and to isolate a potential
n
controller failure to only a subset of disk groups.
Use storage controllers that have the highest queue depths in the VMware Compatibility Guide. Using
n
controllers with high queue depth improves performance. For example, when Virtual SAN is rebuilding
components after a failure or when a host enters maintenance mode.
Use storage controllers in passthrough mode for best performance of Virtual SAN. Storage controllers
n
in RAID 0 mode require higher conguration and maintenance eorts compared to storage controllers
in passthrough mode.
Designing and Sizing vSAN Hosts
Plan the conguration of the hosts in the vSAN cluster for best performance and availability.
Memory and CPU
Size the memory and the CPU of the hosts in the vSAN cluster based on the following considerations.
VMware, Inc. 29
Administering VMware Virtual SAN
Table 4‑2. Sizing Memory and CPU of vSAN Hosts
Compute Resource Considerations
Memory
CPU
Host Networking
Memory per virtual machine
n
Memory per host, based on the expected number of
n
virtual machines
At least 32-GB memory for fully operational vSAN
n
with 5 disk groups per host and 7 capacity devices per
disk group
Hosts that have 512-GB memory or less can boot from a
USB, SD, or SATADOM device. If the memory of the host is
greater than 512 GB, boot the host from a SATADOM or
disk device.
Sockets per host
n
Cores per socket
n
Number of vCPUs based on the expected number of
n
virtual machines
vCPU-to-core ratio
n
10% CPU overhead for vSAN
n
Provide more bandwidth for vSAN trac to improve performance.
If you plan to use hosts that have 1-GbE adapters, dedicate adapters for vSAN only. For all-ash
n
congurations, plan hosts that have dedicated or shared 10-GbE adapters.
If you plan to use 10-GbE adapters, they can be shared with other trac types for both hybrid and all-
n
ash congurations.
If a 10-GbE adapter is shared with other trac types, use a vSphere Distributed Switch for vSAN trac
n
to isolate the trac by using Network I/O Control and VLANs.
Create a team of physical adapters for vSAN trac for redundancy.
n
Multiple Disk Groups
If the ash cache or storage controller stops responding, an entire disk group can fail. As a result, vSAN
rebuilds all components for the failed disk group from another location in the cluster.
Use of multiple disk groups, with each disk group providing less capacity, provides the following benets
and disadvantages:
Benets
n
Performance is improved because the datastore has more aggregated cache, and I/O operations are
n
faster.
Risk of failure is spread among multiple disk groups.
n
If a disk group fails, vSAN rebuilds fewer components, so performance is improved.
n
Disadvantages
n
Costs are increased because two or more caching devices are required.
n
More memory is required to handle more disk groups.
n
Multiple storage controllers are required to reduce the risk of a single point of failure.
n
Drive Bays
For easy maintenance, consider hosts whose drive bays and PCIe slots are at the front of the server body.
30 VMware, Inc.
Loading...