White Papers

Additional resources
12 Dell EMC SC Series: Disaster Recovery for Microsoft SQL Server Using VMware Site Recovery Manager | CML1018
3 Storage infrastructure
Storage is required by vSphere to maintain encapsulated virtual machines and the data each of the VMs
contain. vSphere-certified storage is presented to a cluster of vSphere hosts and abstracted by vSphere in a
few different ways in order to meet the needs of the VMs. Outside of the disaster recovery context, storage
plays major roles in availability, performance, and capacity. However, if and when disaster strikes, storage is
needed immediately at the recovery site to recover applications and resume business operations. This section
will discuss the storage options available for SQL Server running on a vSphere and SRM infrastructure.
3.1 vSphere storage types
Virtual machines are typically located on one or more types of shared storage which are abstracted as VMFS
datastores or in some cases, RDMs. In its current release, VMware SRM supports many of the same storage
protocols and storage vendors found on the vSphere HCL including Fibre Channel (FC), iSCSI, and NFS. The
key requirement from storage vendors is a VMware-certified SRA. The list of SRA-certified storage vendors
and storage types can be found in the
VMware Compatibility Guide.
This document focuses on Microsoft SQL Server virtual machines on SC Series which natively supports block
storage protocols such as FC, FCoE, and iSCSI.
3.2 Virtual machine disk types
Virtual disks represent drive letters or mount points in the guest operating system and can be presented to a
virtual machine in a few different ways. In the majority of use cases, traditional virtual machine disks will be
used and each disk is represented by a corresponding .vmdk file on a VMFS datastore. In Windows Disk
Management, each .vmdk is abstracted as the physical disk type, VMware Virtual disk SCSI Disk Device.
Traditional .vmdk virtual disk types are recommended throughout an environment unless a specific
requirement or design decision dictates otherwise.
An RDM is the other virtual machine disk type and there are two varieties of RDM: virtual and physical,
notated as vRDM and pRDM, respectively. An RDM presents an entire SC volume to a virtual machine as a
disk. Outside of in-guest clustering use cases, RDMs are only presented to a single virtual machine as
opposed to being shared by multiple virtual machines. An RDM is also formatted by the guest operating
system using a native file system as opposed to the vSphere VMFS file system.
Since traditional virtual disks and RDMs are abstracted as physical disks, either disk type may be carved up
into one or more partitions inside the guest operating system to logically isolate data by drive letter or mount
point. In addition, all disk types may be expanded or grown, providing the guest operating system supports
the feature. Because of abstraction and virtualization, the guest operating system is not aware of its virtual
disk type, whether it is a .vmdk or an RDM. From a vSphere perspective, the major difference between a
.vmdk and an RDM has already been identified in how an SC volume is presented and abstracted. When
comparing the two available RDM types, virtual and physical, the differentiator from an operational
perspective is that a vRDM can be included in a vSphere snapshot while a pRDM cannot. This is important to
take into consideration if vSphere snapshots are intended to be leveraged as part of an application- or data-
consistent data protection and recovery mechanism.
One additional type of storage available for a virtual machine would be SAN or NAS mapped directly to the
guest operating system itself instead of being presented through the vSphere storage stack. An example of
this would be in-guest iSCSI where an SC volume is presented directly to the IQN of the operating system
built-in software ISCSI initiator. While this storage configuration would function, there is very little hypervisor