Objective 2.1 – Provide a High-Level description of vSAN

VMware vSAN is enterprise-class storage for hyper-converged infrastructure (HCI). Native to the
VMware vSphere hypervisor, vSAN delivers flash-optimized, secure storage. It utilizes commodity x86 server components to lower costs up to 50% versus traditional server and storage array architectures.

Additionally, vSAN is built right into the vSphere hyperviser. vSAN enables customers to have a single pane of glass management, breaking down IT silo’s, while maintaining and increasing performance, security, scale-ability, efficiency and cost savings across the datacenter.

Objective 2.2 – Describe vSAN Requirements

Requirements to enable and run VMware vSAN depend on a lot of different variables but we will break down the most common and obvious requirements.

vSphere version Requirements: Verify vSphere/vSAN software versions and compatibility.

Hardware Requirements: All hardware used in a vSAN deployment must be on the VMware HCL (Compatibility Guide)

Cluster Requirements:

• Minimum of three ESXi 6.0 hosts contributing local storage (differs in 2 node clusters)
• All hosts must be managed by vCenter Server
• ESXi hosts can’t be apart of any other cluster

Memory Requirements: Minimum of 32GB’s of RAM per host to accommodate maximum disk groups and devices

Networking Requirements: 

• Hybrid configurations – each host must have a minimum single 1GB NIC dedicated (not shared) for vSAN traffic.
• All-Flash configurations – each host must have a minimum single 10GB NIC dedicated (not shared) for vSAN traffic.
• Layer 2 multicast must be enabled on the physical switch(es) connecting all vSAN hosts.
• Each host must have a vmkernel port. Regardless if it’s contributing local storage or not.

Licensing Requirements: Great Guide on vSAN Licensing Requirements

Storage Requirements: 

For caching:

• At least 1 SAS/SATA SSD, or a PCIe flash disk

For VM data storage:

• Hosts running in hybrid cluster must have 1 SAS, NL-SAS or SATA magnetic disk
• Hosts running in all-flash cluster must have at least 1 SSD or PCIe flash disk
• A SAS or SATA HBA or RAID controller that is setup in non-RAID (pass-through) or RAID 0 mode.
• Flash boot devices must be larger than 4GB.

Objective 2.3 – Understand how vSAN Stores & Protects Data

vSAN Protects data in many different forms. We will discuss these in brief.

Storage Policy-Based Management

Storage Policy-Based Management (SPBM) from VMware enables precise control of storage services.
Like other storage solutions, vSAN provides services such as availability levels, capacity consumption,
and stripe widths for performance. A storage policy contains one or more rules that define service
levels.

Storage policies are created and managed using the vSphere Web Client. Policies can be assigned to
virtual machines and individual objects such as a virtual disk. Storage policies are easily changed or
reassigned if application requirements change. These modifications are performed with no downtime
and without the need to migrate virtual machines from one datastore to another. SPBM makes it
possible to assign and modify service levels with precision on a per-virtual machine basis.

 

Failures To Tolerance (FTT): Defines how many failures an object can tolerate before it becomes
unavailable.

Fault Domains: “Fault domain” is a term that comes up often in availability discussions. In IT, a fault domain usually
refers to a group of servers, storage, and/or networking components that would be impacted
collectively by an outage. A common example of this is a server rack. If a top-of-rack switch or the
power distribution unit for a server rack would fail, it would take all the servers in that rack offline even
though the server hardware is functioning properly. That server rack is considered a fault domain.

Each host in a vSAN cluster is an implicit fault domain. vSAN automatically distributes components of
a vSAN object across fault domains in a cluster based on the Number of Failures to Tolerate rule in the
assigned storage policy. The following diagram shows a simple example of component distribution
across hosts (fault domains). The two larger components are mirrored copies of the object and the
smaller component represents the witness component.

vSAN Rack Awareness:

The failure of a disk or entire host can be tolerated in the previous example scenario. However, this
does not protect against the failure of larger fault domains such as an entire server rack. Consider out
next example, which is a 12-node vSAN cluster. It is possible that multiple components that make up
an object could reside in the same server rack. If there is a rack failure, the object would be offline.

To mitigate this risk, place the servers in a vSAN cluster across server racks and configure a fault
domain for each rack in the vSAN UI. This instructs vSAN to distribute components across server racks
to eliminate the risk of a rack failure taking multiple objects offline. This feature is commonly referred
to as “Rack Awareness”. The diagram below shows component placement when three servers in each
rack are configured as separate vSAN fault domains

Specific to vSAN 6.6,

It is possible to configure a secondary level of failures to tolerate. This feature
enables resiliency within a site, as well as, across sites. For example, RAID-5 erasure coding protects
objects within the same site while RAID-1 mirroring protects these same objects across sites.

Rebuild and Re-synchronize:

vSAN achieves high availability and extreme performance through the distribution of data across
multiple hosts in a cluster. Data is transmitted between hosts using the vSAN network. There are cases
where a significant amount of data must be copied across the vSAN network. One example is when
you change the fault tolerance method in a storage policy from RAID-1 mirroring to RAID-5 erasure
coding. vSAN copies or “resynchronizes” the mirrored components to a new set of striped
components.