Server virtualization and LUNs: Configuring Storage for VMware

Allocating storage in a physical environment requires the storage System administrator to match the LUN storage partition based on the performance and availability requirements of each server.

However, with the advent of server virtualization, everything has changed.

Instead, in a virtualized environment, storage resources are abstracted through the hypervisor, not just broken into LUNs (logical unit numbers). LUNs still exist, but typically as a single large storage pool, virtual storage in the storage pool is assigned to a separate client.

Pooled processing means that storage and virtualization administrators need additional planning and design to ensure that storage resources are delivered in a timely and efficient manner.

Hypervisor Emulation storage Device

In a virtualized server environment, the physical storage is abstracted to form a generic SCSI device that is presented to the client.

When using VMware, these were initially buslogic and lsilogic simulations of parallel SCSI devices, and later included a faster SAS version. Hyper-V provides storage to clients by using a similar IDE driver and supports the use of SCSI devices for non-bootable disks. Although the underlying storage uses the hypervisor, the host is still seeing an emulation IDE, SCSI, or SAS device connected to a controller.

Device emulation means that the physical data of a virtual machine can be migrated inside the storage system without impacting the host, but there are some limitations. First, there is a limit on the size of a single disk volume, and the second emulation device supports only standard SCSI commands.

This is a problem for servers that require access to array-controlled devices. In this case, the disk can be connected directly without emulation. In VMware environments, these devices are referred to as rdm--primitive device mappings. The latest version of Hyper-V provides a new feature that allows Fibre Channel devices to connect directly to the client without device emulation.

Virtual Disk--VMDK and VHDs

The hypervisor saves the virtual disk drive as a file and has a file for each client volume. For vsphere, this type of file is Vmds (virtual machine disk), which is stored as a vhd--virtual hard disk for Hyper-V.

Within Vsphere, a vmdk can be stored on an NFS share or on a block device (Fibre Channel or iSCSI) that is formatted as a VMware file system--vmfs.

A single VMDK size limit is 2tb-512b, which means that there is a 2TB limit on all customer volumes. When a customer volume needs more than 2TB of space, the storage needs to be rendered by means of a multi-logical volume.

For Hyper-V, the size limit for the VHD format is also 2TB. Microsoft recently introduced the new format VHDX, which is also part of WindowsServer 2012, allowing a single virtual disk capacity to scale to 64TB.

The storage used to hold the virtual disk can be either a block device or a NAS device. VMware supports iSCSI, Fibre Channel, FCoE, and NFS. Hyper-V supports Fibre Channel, iSCSI, and SMB, which in the past is commonly referred to as CIFS.

The type of storage used is transparent to the customer, because multipath exists. Multipathing is implemented at the hypervisor layer, enabling access to multiple redundant paths to physical storage.

Matching VMS and storage

Hyper-V and vsphere store virtual machines in a larger "container."

Hyper-V uses a local NTFS volume or smb/cifs file system. Vsphere uses NFS to share or format a Vmfs lun, which is commonly referred to as data storage (datastore).

In versions prior to vsphere 5, a vmfsdatastore block size range was from 1MB to 8MB, while representing the limit of the size of VMFS capacity. Vmfsdatastore with a maximum support of 2TB requires a block size of 8MB, which results in a minimum of 8MB of incremental space allocated to the virtual customer. VMFS 5 (released with VSPHERE5) provides a consistent 1MB increment, regardless of the block size of the datastore. For Hyper-V, the block increment is 2MB, regardless of the underlying NTFS file system specific format.

On two hypervisor platforms, the container used to store virtual machines represents the physical storage-to-hypervisor representation, meaning that all virtual customers on a container have the same level of performance and availability. Therefore, vsphere datastore and Hyper-V volumes should be grouped by virtual machine type. For example, product vs. test/development customer or to provide high-performance storage (such as Level 1 or SSD).

The network situation of physical storage and the effect of network on performance are needed to be considered. For example, in a fibre Channel environment, the benefits are achieved by assigning Fibre Channel HBA cards (host bus adapters) to high-performance storage. This can reduce the impact of low-performance virtual machine competition in a mixed environment.

Thin Provisioning

Both vsphere and Hyper-V provide automated, thin-provisioned virtual machines. That is, the entire space of the virtual machine is physically reserved, based on the growth requirements of the virtual machine instead of being created. Vsphere has two formats for "pre-allocated" customer volumes; Zeroedthick (0 pre-allocation)--Use this format to preserve the storage space when it is created, and to clear 0 or delete operations when the host writes data to a block in the reserved physical storage ; Eagerzeroedthick (immediate 0 pre-allocation)-using this format, the reserved storage space is zeroed when it is created. Both formats provide the tradeoff between performance and security, because Zeroedthick can cause old data to still exist on the VMFS. Hyper-V provides pre-allocated VHDs or dynamically amplified VHDs for "pre-allocation."

As with thin provisioning in traditional environments, there is a positive and negative side to using the technology in a virtual environment. Thin provisioning in the hypervisor means more virtual machines are on disk, and thin provisioning is especially important when future growth demands exceed the size of the virtual machine automatically allocated. Of course, the downside of on-demand expansion is that the storage of a single virtual customer is scattered.

With the expansion of each client space on the datastore or volume, when any particular virtual machine requests the next block, there is no predictable allocation of blocks of size 1MB or 2MB. This causes the storage layout of a single client to be random and fragmented. This is especially common in virtualized desktop environments where a large number of random I/O produce performance problems when many virtual desktops are started at the same time.

One obvious question with thin provisioning is whether thin provisioning techniques are implemented on both the hypervisor and the storage. There is no reason not to streamline configuration in both places; the only advice is to ensure that reporting and monitoring are timely and reliable to manage growing data.

This article from "Knowledge change destiny!!" "blog, declined reprint!"

Server virtualization and LUNs: Configuring Storage for VMware