Configuring shares on Nutanix Files

Nutanix Files is one of the Nutanix solutions that is easiest to explain to customers, and I’m finding myself implementing its features in quite a few environments.

Although it may look easy to set it up and publish your shares in just a few clicks, it pays to make some choices carefully and to set certain configurations in the best possible way.

To begin with, network shares can be configured as one of two types: Standard or Distributed

It’s important to understand the pros and cons of both modes, because the choice can’t always be changed later on.

The two modes differ in one fundamental way: Standard shares are served by only one FSVM at a time (although the data is still replicated within the cluster)

So, by creating Standard shares, we could end up in a situation like this:

As you can see, the way the Shares are spread across the various FSVMs may not follow a linear logic, but in any case the high availability of the data would be guaranteed by the product, at “the price” of a timeout of about ten seconds during a failover event. In that case Nutanix Files would move the serving of the shares affected by the failure to other FSVMs in the cluster, making the Shares available again in a short time (with no data loss).

The key difference is that Distributed shares, unlike Standard ones, are served by all the FSVMs in parallel (increasing the available IOPS).

Reading what I’ve just written, it would seem obvious to configure every share in Distributed mode, but in reality that isn’t necessarily the best choice.

Why might it not be the best choice? Because when we configure a share in Distributed mode, Nutanix Files distributes the folders contained in the share roughly like this:

As you can see, the share isn’t fully distributed across the three FSVMs in parallel; instead, the folders it contains are served by different FSVMs. The downside is that to manage the folders you need to use the MMC console provided by Nutanix, and you won’t be able to delete a folder without first deleting its contents.

As mentioned above, a Standard share, on the other hand, would work just like a perfectly ordinary Windows network folder, but with the guarantee of HA in case of problems; in other words, during normal operation the share will be served by a single FSVM, which is however part of a Nutanix Files cluster (assuming at least 3 nodes) that guarantees its resilience and availability even if that FSVM fails.

So when is it better to use one mode rather than the other? My team and I came to these conclusions (by studying the Nutanix documentation and running lab tests):
– Standard shares are suitable for any classic workload, i.e. general-purpose document sharing;
– Distributed shares are ideal for serving network folders that hold user profiles (Citrix, FSLogix, user folder redirection, etc…), whether they are Shared Folders (holding the users’ Desktop, Downloads, Documents, etc…) or dedicated to serving container-based profiles (VHDX);

That said, there are still settings that could further shape your choices; if the Distributed network share is used to serve profile VHDX files (Citrix, FSLogix, etc…), it might make sense to consider configuring it with a particular feature enabled, called Continuous Availability (CA):

This feature allows Nutanix Files to guarantee continuous availability of the files it serves, without even the slightest service interruption. In this case, the result of a failover is that the end user wouldn’t notice a thing, even though the serving of their user profile will have been moved from one FSVM to another during a potential failure event.

As you can see in the image, Nutanix advises against enabling this feature on all Distributed network shares, because if it’s enabled on folders that serve general-purpose shares, it could cause performance problems.

What happens if we don’t enable it? If an FSVM fails, Nutanix Files would still move the serving of the user folder to another FSVM, but the failover would take about 10 seconds. With CA enabled, the migration happens immediately, without any disruption.

How do you check that the share really has CA enabled? Connect to an FSVM via SSH and run the command afs share.list

There are also other settings worth paying attention to:

Enable Self Service Restore is a feature that, thanks to Nutanix snapshots, lets authorized users recover copies of files from earlier points in time, in Self Service mode (without the system administrators having to step in). This feature requires specific licensing, so it might not be available to everyone;

Enable Compression enables compression of the share’s content; in this case it’s recommended to enable compression only on folders whose files are read infrequently.

Blocked File Types lets you define file extensions that aren’t allowed, so you can block certain types of files from being written.

Enable WORM enables protection of the share’s content, preventing data from being modified once it has been written.

Enable Access Based Enumeration (ABE) shows users only the folders they have access to, making browsing a centralized file server less “chaotic”.

Allow Long Names for Files and Folders solves the problem of storing folders, subfolders and files that make up paths longer than 256 characters, raising the limit to 1023 characters. Of course, enabling this feature does solve the problem on the share, but it could still cause problems when backing up the content stored on it (using third-party software).

Encrypt SMB3 Messages lets you enable encryption of SMB3 messages, ensuring that data is encrypted in transit.

As you can see, although creating shares may seem easy, you need to configure them in the best way based on what each share is going to serve.

Even after the shares have been created, it’s a good idea to keep monitoring their performance, so you can take any action needed to keep the environment running smoothly.

Thanks to Athos, the colleague who dug into these configurations more than anyone else and helped me understand them inside out!!

Read next