Dell Unity also includes tight integration with VMware vSphere that benefits file storage administrators and virtualization administrators alike. In addition to traditional SMB and NFS file systems, Dell Unity allows users to create a special NFS file system type optimized for VMware use. In Unisphere, this can be accomplished by creating a VMware NFS datastore from the VMware Storage page. When giving access to an ESXi host previously discovered from the VMware Access page, the VMware NFS datastore will be automatically detected and mounted as a datastore on the ESXi host with no manual intervention necessary.

In addition, Dell Unity NFS VMware datastores give administrators the unique ability to select the underlying file system block size to best match the host I/O size of the intended application. A file system block size is the smallest guaranteed physical mapping within a file system, which is set at 8 KB for Dell Unity SMB and NFS file systems. However, because NFS datastores are often intended for specific application workloads, Dell Unity provides the ability to set this block size to 8 KB, 16 KB, 32 KB, or 64 KB during datastore configuration to best accommodate the I/O size typically used by particular applications. Because administrators may not always be aware of the host I/O size of their intended application, Dell Unity maintains an internal mapping of application to I/O size for popular applications, which allows users to specify the intended application instead. Dell Unity will then configure the backend file system block size to match the I/O size used by this application. Applications with predefined host I/O sizes include:

• Exchange 2007
• Exchange 2010
• Exchange 2013
• Oracle
• SQL Server
• VMware Horizon VDI
• SharePoint
• SAP

Figure 9.   Host IO Size

This approach of allowing administrators to specify the file system block size has two advantages over a single fixed block size. An 8 KB block size is unnecessarily granular for applications that address storage in larger increments such as 64 KB, so it is more performance-efficient to match the file system block size to the application I/O size. Also, from a recovery perspective, fewer larger blocks reduce file system check (FSCK) times considerably when compared to more numerous smaller blocks. This is especially important for scaling purposes to avoid long FSCK times in the presence of the very large file systems supported on Dell Unity. While this feature provides potential benefits, it is important to be sure of the correct application or I/O size setting when changing the default of 8 KB. Choosing an incorrect IO size can be detrimental to the performance of the file system, impose unnecessary flash wear penalties, and increase space consumption on small files when the configured IO size is larger than the actual IO size of the application. Because of this, it is recommended to leave the default and minimum IO size of 8 KB for general purpose VMware datastores or for those where the intended application of host IO size is unknown.

As an additional point of integration, Dell Unity file systems support VMware vSphere Storage APIs Array Integration (VAAI) through a VAAI plug-in, allowing for hardware acceleration and offloading through access to supported file primitives including FAST clone, snap-of-snap, extended statistics, and reserve space. Because of Dell Unity’s scalable 64-bit file system architecture, up to 256 levels of VM snapshots are possible with VAAI. With this capability, administrators can provision multiple levels of snapshots (also called fast clones) from a single golden image. In the figure below, a base VM is used as a source or golden copy for a snapshot to be taken. Similarly, a snapshot can then be taken of this snapshot. This process can then continue to create additional levels of hierarchical snapshots as necessary.

Figure 10.    VAAI snap-of-snap

This functionality can be useful in many different cases, such as virtual desktop infrastructure or test and development. For example, these types of hierarchical snapshots can be leveraged as part of a software development environment where developers need to test out incremental changes to a base version of an operating system. As updates of minor software patches are installed, the test environment virtual machine could be snapped at every level to test the impact of each level of incremental software changes. This incremental testing and protection can continue until a final production version of the software is developed.