vSAN performance diagnostics reports: “One or more disk(s) are not in active use”

October 3, 2017 tapasmahanta1241 Comment

This issue means that one or more vSAN backend capacity disks do not see any IOs. This issue is delivered only for all-flash vSAN clusters and for benchmarks that have some read IO activity. While some capacity disks may not see read IOs for some intervals of time, the best performance is usually achieved when read IOs are spread evenly across all backend capacity disks.

Here is a list of possible remedies:

1: If you are running a 100% read workload, such as 100% sequential read or 100% random read, then it is possible that the contents of the capacity disk are cached in the write buffer of the cache tier. In this case, the reads are serviced from the cache tier and do not hit the capacity tier. Depending on the specifications of your cache tier and capacity tier storage, and the number of capacity tier disks in your disk group, it may be possible to get better read bandwidth if some read content is in the capacity tier. In this case, please increase the size of the virtual machine disks (VMDKs) to have more than a 400GB working set per disk group. In general, for an all-flash vSAN cluster, the performance of a 100% read workload is better with large working sets.

2: If your benchmark has some write IO component, you may increase the number of VMDKs so that all backend capacity disks have some object components. We recommend that any benchmark should create one VMDK for each capacity disk on the system, and concurrently drive IO to each of these VMDKs. A safe rule of thumb is to create two VMs for every disk group on your system, and create eight VMDKs for each virtual machine. Size VMDKs according to the available size of cache tier across all disk groups

3: Alternatively, it is possible that your benchmark is not issuing IOs to all the VMDKs that were created. Please check if that is the case, and correct it so that IOs are targeted to all VMDKs.

4:If you do not want to increase the number of virtual machines or the number of VMDKs, you may increase the “Number of disk stripes per object” (the default value is 1), in the vSAN storage policy with which the VMDKs were created. This number refers to the number of capacity disks across which each replica of a storage object is striped. You may choose to apply the policy to existing virtual machines, in which case all existing VMDKs will be reconfigured, and you must wait for the reconfiguration traffic to end. Alternatively, you can apply the policy manually to existing or new virtual machines/VMDKs.

vSAN performance diagnostics reports: “One or more disk group(s) are not in active use”

October 3, 2017 tapasmahanta1241 Comment

This issue means that the specified disk groups do not have IOs during some period of the evaluated time duration, which limits the maximum possible performance on the vSAN cluster. The goals of Max IOPS and Max Throughput require IO activity from each disk group.

Here is a list of possible solutions:

1:If you are running a benchmark, you may increase the number of virtual machines or the number of VMDKs per virtual machine so that all disk groups have some object components.

2:Alternatively, it is possible that your benchmark is not issuing IOs to all the VMDKs that were created.

3:If you do not want to increase the number of virtual machines or the number of VMDKs, you may increase the “Number of disk stripes per object” (the default value is 1) in the Virtual SAN Storage Policy with which the VMDKs were created.

4:You can apply the policy manually to existing or new virtual machines and VMDKs.

Understanding vSAN memory consumption in ESXi 6.5.0d/ 6.0 U3

October 3, 2017 tapasmahanta1241 Comment

To calculate vSAN memory consumption in these releases, use this equation:

BaseConsumption + (NumDiskGroups * (DiskGroupBaseConsumption + (SSDMemOverheadPerGB * SSDSize))) +(NumCapacityDisks * CapacityDiskBaseConsumption)

Where: BaseConsumption: is the fixed amount of memory consumed by vSAN per ESXi host. NumDiskGroups: is the number of disk groups in the host, this value should range from 1 to 5. DiskGroupBaseConsumption: is the fixed amount of memory allocated to each individual disk group in the host. This is mainly used to allocate resources used to support inflight operations on a per disk group level. SSDMemOverheadPerGB: is the amount of memory allocated per GB of SSD. SSDSize: is the size of the SSD disk in GB. NumCapacityDisks: is the number of capacity disks in the host (across all the diskgroups). CapacityDiskBaseConsumption: is the amount of memory allocated per capacity disk.

Constants: BaseConsumption = 5426 MB DiskGroupBaseConsumption = 636 MB SSDMemOverheadPerGB (hydrid) = 8 MB SSDMemOverheadPerGB (allflash) = 14 MB CapacityDiskBaseConsumption= 70 MB

Note: In these releases, encryption and deduplication features have no impact on memory consumption.

Example: One disk group per host, all flash configuration:

BaseConsumption + 
(NumDiskGroups * (DiskGroupBaseConsumption + (SSDMemOverheadPerGB * SSDSize))) +
(NumCapacityDisks * CapacityDiskBaseConsumption)
=
5426 MB + (1 * (636 MB + (14MB * 600))) + (3 * 70 MB)
=
14672 MB

NEW FEATURES IN VSAN 6.6.1

October 3, 2017 tapasmahanta1241 Comment

Integration with VUM, VMware Update Manager

vSAN 6.6.1 is fully integrated with VUM to provide a powerful new update process that makes sure your vSAN cluster is up to date.

vSAN Performance Diagnostics:

The feature offers advice such as increasing a stripe width, adding more VMs or bringing more disk groups into use to improve performance. The feature needs the Customer Experience Improvement Program (CEIP) to be enabled, as well as the vSAN Performance Service. Once these have been configured, and the diagnostic information has been gathered for approx. 1 hour, benchmark results can then be examined to see if the maximum number of IOPS, maximum throughtput or minimum latency has been achieved. If not, guidance is provided on how best to achieve these objectives in a benchmark run.



Improved vCenter and unicast behaviour for cluster membership:

If vCenter is down and changes are then made to the cluster, when vCenter recovers, it may reset those cluster changes(UUID ). In vSAN 6.6.1, there is a new property for vSAN called “configuration generation”. This addresses the issue of tracking vSAN membership and will avoid the issue.

New health checks for Update Manager (VUM)
 

The health check has been updated to include checks for new features, such as VUM.

Understanding VVols

August 24, 2017 tapasmahanta124Leave a comment

Virtual Volumes (VVols) is a new integration and management framework that virtualizes SAN/NAS arrays, enabling a more efficient operational model that is optimized for virtualized environments and centered on the application instead of the infrastructure. Virtual Volumes simplifies operations through policy-driven automation that enables more agile storage consumption for virtual machines and dynamic adjustments in real time, when they are needed. It simplifies the delivery of storage service levels to individual applications by providing finer control of hardware resources and native array-based data services that can be instantiated with virtual machine granularity.

With Virtual Volumes (VVols), VMware offers a new paradigm in which an individual virtual machine and its disks, rather than a LUN, becomes a unit of storage management for a storage system.Virtual volumes encapsulate virtual disks and other virtual machine files, and natively store the files on the storage system.

Overview:
++++++++++++++

Virtual Volumes (VVols) are VMDK granular storage entities exported by storage arrays. Virtual volumes are exported to the ESXi host through a small set of protocol end-points (PE). Protocol Endpoints are part of the physical storage fabric, and they establish a data path from virtual machines to their respective virtual volumes on demand. Storage systems enables data services on virtual volumes. The results of these data services are newer virtual volumes. Data services, configuration and management of virtual volume systems is exclusively done out-of-band with respect to the data path. Virtual volumes can be grouped into logicaly and are called storage containers (SC) for management purposes.

Virtual volumes (VVols) and Storage Containers (SC) form the virtual storage fabric. Protocol Endpoints (PE) are part of the physical storage fabric.

By using a special set of APIs called vSphere APIs for Storage Awareness (VASA), the storage system becomes aware of the virtual volumes and their associations with the relevant virtual machines. Through VASA, vSphere and the underlying storage system establishes a two-way out-of-band communication to perform data services and offload certain virtual machine operations to the storage system. For example, operations such as snapshots and clones can be offloaded.

For in-band communication with Virtual Volumes storage systems, vSphere continues to use standard SCSI and NFS protocols. This results in support with Virtual Volumes for any type of storage that includes iSCSI, Fibre Channel, Fibre Channel over Ethernet (FCoE), and NFS.

- Virtual Volumes represent virtual disks of a virtual machine as abstract objects identified by 128-bit GUID, managed entirely by Storage hardware.
- Model changes from managing space inside datastores to managing abstract storage objects handled by storage arrays.
- Storage hardware gains complete control over virtual disk content, layout and management.

WORKFLOW:

Important Things to be noted:

+++++++++++++++++++++++

Storage provider (SP): The storage provider acts as the interface between the hypervisor and the external array. It is implemented out-of-band (it is not data path) and uses the existing VASA (vSphere APIs for Storage Awareness) API protocol. The storage provider also consists of information, such as details on VVOLs and storage containers. VVOLs requires the support of VASA 2.0, released with vSphere 6.

Storage container (SC): This is configured on the external storage appliance. The specific implementation of the storage container will vary between storage Vendors, although most of the vendors allow physical storage to be aggregated into pools from which logical volumes can be created.

Protocol endpoint (PE): It acts as a middle man between VVOLs and hypervisor and is implemented as a traditional LUN on block-based systems, although it stores no actual data (dummy LUN). The protocol endpoint has also been described as an I/O de-multiplexer, because it is a pass-through mechanism that allows access to VVOLs bound to it. For example the gate keeper LUN in EMC VMAX array.ESXi hosts have no direct access to virtual volumes on the storage side. Instead, ESXi hosts use a logical I/O proxy, called the Protocol Endpoint (PE), to communicate with virtual volumes and virtual disk files that virtual volumes encapsulate.
VVols Objects:

+++++++++++++

A virtual datastore represents a storage container in vCenter Server and the vSphere Web Client. Virtual volumes are encapsulations of virtual machine files, virtual disks, and their derivatives.

- - Virtual machine objects stored natively on the array storage containers.
  - There are five different types of recognized Virtual Volumes:

Config-VVol – Metadata
Data-VVol – VMDKs
Mem-VVol – Snapshots
Swap-VVol – Swap files
Other-VVol – Vendor solution specific

Follow these guidelines when using Virtual Volumes:

Because the Virtual Volumes environment requires the vCenter Server, you cannot use Virtual Volumes with a standalone ESXi host.
Virtual Volumes does not support Raw Device Mappings (RDMs).
A Virtual Volumes storage container cannot span across different physical arrays.
Host profiles that contain virtual datastores are vCenter Server specific. After you extract this type of host profile, you can attach it only to hosts and clusters managed by the same vCenter Server as the reference host.

Key benefits of Virtual Volumes:

++++++++++++++++++++++++++

Operational transformation with Virtual Volumes when data services are enabled at the application level
Improved storage utilization with granular level provisioning
Common management using Policy Based Management

Basic Commands for VSAN

August 24, 2017 tapasmahanta124Leave a comment

VSAN is one of the best Products available from VMware. vSAN is a core building block for the Software-Defined Data Center.

Let us understand the different terminologies used in VSAN :

CMMDS – Cluster Monitoring, Membership, and Directory Service
CLOMD – Cluster Level Object Manager Daemon
OSFSD – Object Storage File System Daemon
CLOM – Cluster Level Object Manager
OSFS – Object Storage File System
UUID – Universally unique identifier
VSANVP – Virtual SAN Vendor Provider
SPBM – Storage Policy-Based Management
VSA – Virtual Storage Appliance
MD – Magnetic disk
SSD – Solid-State Drive
RVC – Ruby vSphere Console
RDT – Reliable Datagram Transport

Let us get into details for each one of them :

1: CMMDS

ESXi Shell, there is a VSAN utility called cmmds-tool which stands for Clustering Monitoring, Membership and Directory Services. This tool allows you to perform a variety of operations and queries against the VSAN nodes and their associated objects.

Few examples of cmmds command:

cmmds-tool find -u uuid -f json |less

Find command Example

cmmds-tool find –t HOSTNAME

cmmds-tool find -t DISK | grep “DISK” | wc –l