Server Message Block (SMB), also known as Common Internet File System, is Microsoft’s application-layer network protocol for Windows file sharing. While SMB1 is rarely used these days, OneFS also supports SMB2 and SMB3, including features such as continuous availability (CA) for transparent failover, encryption, and multichannel for increased application throughput.
Best practices for the SMB protocol on OneFS include:
- Static pools are recommended for connecting SMB workloads, including SMB CA.
- The recommendation is to use either SMB2 or SMB3 Windows clients. Where possible, avoid using SMB1.
- Create no more than 80,000 SMB shares per cluster and keep share names below 80 characters.
- For SMB 2 & 3, do not exceed 3,000 active sessions and 27,000 idle connections per node. For SMB1, the recommended limit is 1000 connections per node.
- SMB read and write performance improvements can often be achieved by setting the data-access pattern to Streaming.
- An access zone can authenticate users with only one Active Directory domain. Although you can add more than one of the other directory services to a zone, a best practice is to limit each zone to no more than one of each of the directory services. User mapping rules apply only in the access zone in which you created them.
- As a best practice, if you create access zones, make sure that the directory paths for each zone under /ifs do not overlap. Instead, you should designate separate directory trees for each zone.
- In general, a best practice is to use Microsoft Active Directory with Windows Services for UNIX and RFC 2307 attributes to manage Linux, UNIX, and Windows systems. In some versions of Microsoft Windows, Windows Services for UNIX is also known as Identity Management for UNIX (IDMU). Integrating UNIX and Linux systems with Active Directory centralizes identity management and eases interoperability. Make sure your domain controllers are running Windows Server 2003 R2 or later.
- Where possible, a best practice is to authenticate all users with Kerberos because it is a highly secure protocol. If you are authenticating users with Kerberos, ensure that both the cluster and clients use either Active Directory or the same NTP server as their time source.
- In an environment with two or more identity management systems, the simplest configurations name users consistently so that each UNIX user corresponds to a similarly named Windows user. Before assigning a UID and GID, OneFS searches its other authentication providers, such as LDAP, for other identities with the same name. If OneFS finds a match, the mapping service by default selects the associated UID and group memberships. Naming users consistently also allows user mapping rules with wildcards to match names and map them without explicitly specifying each pair of accounts.
- The native identity option is likely to be the best for a network with UNIX and Windows systems. In native mode, OneFS favors setting the UID as the on-disk identity because doing so improves NFS performance. OneFS stores only one type of identifier—either a UID and a GID or a SID—on disk at a time. As a best practice, if you change the on-disk identity, you should run the repair permissions job; see the OneFS Administration Guide.