As part of the design of a vCloud Director platform with vSAN, the architect needs to address the location of the organization catalogs, and the type and tier of storage on which it is hosted.

A catalog provides vCloud consumers with a library of content, such as ISO media and vApp templates. Public catalogs allow multiple organizations to share specific catalog items with authorized users and developers having the ability to upload and publish their content to these public catalogs.

Catalog media files and other content do not require the disk performance of active systems, and can therefore typically be located on a much lower tier of storage, with the primary design consideration being based on capacity, and ideally thin provisioned disk. NFS storage is well suited to meet this requirement, and the use of third-party independent software vendor (ISV) solutions such as NexentaConnect, can be employed to provide a NFS layer of storage offered by a virtual appliance running on top of vSAN.

In general, VMware does not recommend utilizing vSAN storage for catalogs. The reason behind this recommendation is that all catalog media images, such as ISO files, are uploaded by vCloud Director as file objects into a directory structure under a single folder. Therefore, assuming the same storage policy is used for different catalogs, the catalogs will all share one VM Home Namespace object, with a maximum size of 256 GB. For this reason, third-party virtual storage appliances, which consume vSAN storage and provide NFS file services, are better for providing catalogs across clusters, proving the ability to scale beyond this 256 GB imposed limit.

In addition, another design consideration is that a vCloud Director server group, that is a deployment made up of multiple cells, requires the use of a shared volume, which is referred to as the transfer server storage. The storage employed for the transfer server storage must be available to all vCloud Director cells in the server group, and while any type of shared storage, such as iSCSI, is possible, because NFS storage is easier to set up and more flexible than other shared storage file system types, NFS is typically the preferred choice to meet this requirement.

 

When employing NFS for the transfer server storage, a number of configuration settings must be set so that each vCloud Director cell in the vCloud Director server group can mount and use the NFS-based transfer server storage. The ability for each cell to mount the NFS-based location and use it as the transfer server storage is related to the user and group permissions settings that vCloud Director employs.

Another design consideration that supports the use of NFS is the inclusion of maintenance storage. For instance, it is common for all local disks on a host to be allocated to vSAN disk groups and, therefore, the deployment of the ESXi hypervisor is onto USB or SD devices. However, if you allocate local storage to vSAN, you will not have local disks to deploy a local datastore, which is required for persistent logging. The reason for this is because of the I/O sensitivity of USB and SD devices and the hypervisor behavior, which means the installer will not create a scratch partition on these devices. When installing on USB or SD devices, the installer attempts to allocate a scratch region on an available local disk or datastore. If no local disk or datastore is found, /scratch is placed on the ramdisk. After the installation, reconfigure /scratch to use a persistent datastore.

Therefore, an additional design option to maintain logs and vSAN trace files is to redirect them to an NFS datastore, which can be employed as a centralized maintenance location. For instance, the vSAN trace files can be redirected by employing the esxcli vsan trace set command: vsantraces -> /vmfs/volumes/NFS-Extent/.