mopdf.com

SMB design considerations and common practicesFor detail information about how to configure MTU, refer to the white paper PowerScale Network DesignConsiderations.1.2.2Link aggregationLink aggregation protocol provides methods to combine multiple Ethernet interfaces, forming a single linklayer interface, specific to a switch or server. It balances the network traffic leaving the aggregated interfaces.It is imperative to understand that link aggregation is not a substitute for a higher bandwidth link. Although linkaggregation combines multiple interfaces, applying it to multiply bandwidth by the number of interfaces for asingle session is incorrect. Link aggregation distributes traffic across links. However, a single session onlyutilizes a single physical link to ensure packets are delivered in order without duplication of frames. Thus, thebandwidth for a single client is not increased, but the aggregate bandwidth of all clients increases in anactive/active configuration.Here are some considerations for using link aggregation: 1.2.3SMB2 will benefit from link aggregation as a failover mechanism between client network interfacecards (NICs).No link aggregation configuration is required or desired for SMB3. SMB3 multichannel willautomatically detect and use multiple network connections if a proper configuration is identified. Formore detail about SMB multichannel, refer to the SMB Multichannel section.Link aggregation is only per PowerScale node, not across PowerScale nodes. Because OneFS is aclustered file system, each node of the cluster is an independent unit with its own operating system.Link aggregation across more than one node is not available or supported.SmartConnectSmartConnect enables client connection load balancing and dynamic failover and failback of clientconnections across storage nodes to provide optimal utilization of the cluster resources. SmartConnecteliminates the need to install client-side drivers, enabling the IT administrator to easily manage large numbersof clients with confidence. And in the event of a system failure, file system stability and availability aremaintained. For more detail information about SmartConnect, refer to the white paper PowerScale NetworkDesign Considerations.Here are some considerations for using SmartConnect with SMB: H17463.1Do not use the Dynamic IP Allocation method for SMB clients. There is a server state associated withan SMB connection. An IP failover in a dynamic pool does not replicate that state. Users may counterincorrect behavior and possible file corruption if the application does not handle the server stateproperly. For failover consideration, it is recommended to use SMB Continuous Availability withPowerScale. For more detail information about SMB Continuous Availability, refer to SMB continuousavailability and witness section.With SmartConnect, if a node that has established client connections goes offline, the behavior isprotocol-specific. For SMB workload, the SMB protocols are stateful. When a node that hasestablished client connections goes offline, the SMB connection is broken because the state is lost.If a customer has a mixed workload with both SMB and NFS connections to the same PowerScalecluster, it is recommended to have a different SmartConnect zone and separate IP address pool foreach workload. The NFS clients can be put in a dedicated SmartConnect zone that will facilitatefailover while the SMB clients are put into another SmartConnect zone that will not participate infailover. This will ensure the SMB clients mount to the “Static node IPs” which do not failover.

SMB design considerations and common practices1.3Access zonesAccess zones provide a method to logically partition cluster access and allocate resources to self-containedunits, thereby providing a shared tenant, or multi-tenant, environment. Access zones support configurationsettings for authentication and identity management services on a cluster, so you can configure authenticationproviders and provision protocol directories such as SMB shares on a zone-by-zone basis. As a generalcommon practice, reserve the System zone for configuration access, and create additional zones for dataaccess. In the following sections, we will focus on the consideration for directory services, access zoneseparation and Kerberos authentication.1.3.1Directory serviceAn access zone can authenticate users with only one Active Directory domain. Although you can add morethan one of the other directory services to a zone, a common practice is to limit each zone to no more thanone of each of the directory services. For example, your access zone could contain one Active Directory, oneLDAP and one File provider.Refer to Configure an Active Directory provider for more details of the configuration steps.1.3.2Access zones separationOneFS supports overlapping data between access zones for cases where your workflows require shared datafor consolidation consideration; however, this adds complexity to the access zone configuration that mightlead to future issues with client access. As a general guideline, overlapping access zones should only occur ifdata must be shared between zones. If sharing data, it is recommended that the access zones share thesame authentication providers. Shared providers ensure that users will have consistent identity informationwhen accessing the same data through different access zones.In case you cannot configure the same authentication providers for access zones with shared data, Dell EMCrecommends the following common practices: 1.3.3Select Active Directory as the authentication provider in each access zone. This causes files to storeglobally unique SIDs as the on-disk identity, eliminating the chance of users from different zonesgaining access to each other's data.Set the on-disk identity to native, or preferably, to sid. When user mappings exist between ActiveDirectory and UNIX users, OneFS stores SIDs as the on-disk identity instead of UIDs. For example,the NFS export in Access Zone A uses LDAP as the authentication provider, meanwhile the SMBshare in Access Zone B uses NTLM as the authentication provider. The NFS exports and the SMBshare in this example shares the same root data path. In this case, select native or sid as on-diskidentity.Kerberos authenticationKerberos is a network authentication provider that works on the basis of tickets to allow communication over anon-secure network to prove their identity to one another in a secure manner. OneFS supports two kinds ofKerberos implementation on PowerScale clusters H17463.1Microsoft Kerberos/Active Directory Kerberos/Microsoft Windows KDCMIT Kerberos/MIT KDC

SMB design considerations and common practicesIf you configure an Active Directory provider, support for Microsoft Kerberos authentication is providedautomatically. If your workflow requires using the SMB protocol, use Microsoft Kerberos.For using Microsoft KDC/Kerberos with AD users and PowerScale, several considerations andrecommendations are listed below: It is recommended to authenticate all users with Kerberos because it is a highly secure protocol andthe performance is much better than NTLM.If you are authenticating users with Kerberos, make sure that both your PowerScale cluster as well asyour clients use Active Directory and the same NTP server as their time source.Make sure you do not have duplicated SPN’s created for the PowerScale cluster. This can causeauthentication issue. For details, refer to Duplicate SPN’s with PowerScale AD Kerberos andHortonworks prevents services from starting.Refer to Kerberos Authentication and white paper Integrating OneFS with Kerberos Environment for Protocolsfor more details of how to configure Kerberos on PowerScale.1.4Multi-protocol access1.4.1OverviewTo provide multi-protocol access, access tokens are generated through the following steps:1. User identity lookup2. ID mapping3. User mapping4. On-disk identity calculationThe following sections focus on the considerations and common practices of step 2 through 4 and at the endwill discuss some options in ACL policy settings.1.4.2ID mappingThe ID mapping service’s role is designed to map Windows SIDs to UNIX UIDs and GIDs and vice versa inorder to associate a user’s identity across different directory services.The followings are some considerations and recommendations for ID mapping:Use Active Directory with RFC 2307Use Microsoft Active Directory with RFC 2307 attributes to manage Linux, UNIX, and Windows systems andmake sure your domain controllers are running Windows Server 2003R2 or later. Integrating UNIX and Linuxsystems with Active Directory centralizes identity management and eases interoperability.If you use Microsoft Active Directory with RFC 2307 attributes to manage Linux, UNIX and Windows systems,the following fields are required in Active Directory: H17463.1uiduidNumbergidNumberloginShell

SMB design considerations and common practices UNIXHomeDirectoryFor the detailed configuration steps, refer to OneFS: How to configure OneFS and Active Directory forRFC2307 compliance.Do not use overlapping ID rangesIn networks with multiple identity sources, such as LDAP and Active Directory with RFC 2307 attributes, youshould ensure that UID and GID ranges do not overlap. It is also important that the range from which OneFSautomatically allocates UIDs and GIDs does not overlap with any other ID range. OneFS automaticallyallocates UIDs and GIDs from the range 1,000,000-2,000,000 which is configurable. If UIDs and GIDs overlapmultiple directory services, some users might gain access to other users’ directories and files. A typicalscenario is when LDAP provides extended AD attributes with a 1000,000 UID or GID, and this overlap withthe one generated on OneFS.Refer to ID mapping ranges for more information on how to configure ID ranges.Avoid common UIDs and GIDsDo not include commonly used UIDs and GIDs in your ID ranges. For example, UIDs and GIDs below 1,000are reserved for system accounts; do not assign them to users or groups.1.4.3User mappingThe user mapping service combines access tokens from different directory services into a single token. Whenthe names of an account in different directory services match exactly, OneFS automatically combines theiraccess tokens into a single token. On the other hand, you can set rule to modify the user mapping behavior.You can also test the user mapping rule. For more details, refer to Test a user-mapping rule.The followings are some considerations and recommendations for user mapping:Employ a consistent username strategyIn an environment with two or more identity management systems, the simplest configuration is naming usersconsistently, so that each UNIX user corresponds to a similarly named Windows user. Before assigning a UIDand GID, OneFS searches its other authentication providers, such as LDAP, for other identities with the samename. If OneFS finds a match, the mapping service by default selects the associated UID and groupmemberships. Naming users consistently also allows user mapping rules with wildcards to match names andmap them without explicitly specifying each pair of accounts.Avoid using UPNs in mapping rulesYou cannot use a User Principal Name (UPN) in a user mapping rule. A UPN is an Active Directory domainand username that are combined into an Internet-style name with an @ symbol, such as an email address:jane@example. If you include a UPN in a rule, the mapping service ignores it and may return an error.Instead, specify names in the format DOMAIN\user.com.Native on-disk identityThe native identity option is likely to be the best for a network with UNIX and Windows systems and this isthe default setting. In native mode, OneFS favors setting the UID as the on-disk identity because doing soimproves NFS performance. OneFS stores only one type of identifier—either a UID and a GID or a SID—onH17463.1

SMB design considerations and common practicesdisk at a time. As a common practice, if you change the on-disk identity, you should

Windows Server 2003 Windows Server 2003 R2 SMB 2.0 (or SMB2) Windows Vista (SP1 or later) Windows Server 2008 SMB 2.1 (or SMB2.1) Windows 7 Windows Server 2008 R2 SMB 3.0 (or SMB3) Windows 8 Windows Server 2012 SMB 3.02 (or SMB3) Windows 8.1 Windows Server