Scale-Out File Server (SOFS) shares are intended for storage of Hyper-V
virtual hard disks and SQL databases. Using SOFS for information worker
workloads including shares for end user file shares, containing unstructured
data such as home folders, spreadsheets, or PDFs requires some additional
considerations. Information worker workloads require metadata changes
(file open, close, rename, delete) typically from hundreds of users
at once. Scale-Out File Server shares are continuously available,
which requires all nodes to synchronize metadata changes, which in
the case of information worker workloads result in a potential performance
overhead for these shares because of the large number of metadata
changes. Based on the information worker workload, the performance
impact may vary and in some cases be negligible, such as information
worker workloads with newer versions of Microsoft Office. Finally,
many features, which are available on a general use file shares may
not work on scale-out file shares – such as DFS-R and quotas.
There are three options for providing file shares to
information workers on SOFS:
Option 1: Create a
SOFS on the SOFS cluster and host the information worker workload
directly on the share. As long as the clients accessing the shares
are using Windows 8 or later, they will receive all the benefits of
using a SOFS – single namespace, load balancing, and more. Workloads
on the share may experience some performance overhead because of metadata
changes. Also, the scale-out file shares may not support all the features
a general use file server provides like DFS-R and quotas.
Option 2: Create a new VM running Windows Server 2012
R2 and store it on a SOFS file share. Install the File Server role
and configure it as a File Server for general use. Allocate the disk
space (size) of the VHDX file on the basis of worker data you plan
to save. Create all information worker file shares inside the VM.
After the information worker workloads are run inside of a VHDX, there
will be no performance overhead because of SOFS metadata changes.
Also, general use file shares have the full capabilities such as DFS-R
and quotas. However, because clients access general use file shares
they will not receive all the benefits of accessing a SOFS. When the
VM running the general-use file server is highly available on the
SOFS cluster, the general use file shares running inside the VM will
not be. More tasks such as clustering the guest OS may be require
to provide continuously available file shares to clients.
Option 3: Create a new SMB file share on the SOFS, but
modify the share after you create it by clearing the
Enable
continuous availability
check box. By disabling the ‘continuous
availability’ feature, the file share will not have performance overhead
because of SOFS metadata changes. However, after the file share is
not continuously available, then if access to a node in the cluster
hosting the share is lost, there may be momentary loss of connectivity
to the workload during the failover of the file share. In many cases,
information worker workloads, such as Microsoft applications, cache
data locally and a brief outage during the failover may be transparent
to the user. Third-party applications may not offer the same level
of data consistency, and should be evaluated on a case by case basis.
Also, as long as the clients accessing the shares are using Windows
8 or later, they receive all the benefits of using a SOFS—single namespace,
load balancing, and more. But, after the information worker workload
is being hosted on SOFS it will not support all the features a general
use file server provides such as Distributed File System Replication
(DFS-R) and quotas.