
Transcription
Technical White PaperDell EMC PowerScale: Solution Design andConsiderations for SMB EnvironmentsAbstractThis white paper provides technical details on the design considerations of DellEMC PowerScale storage and the OneFS operating system with Microsoft Server Message Block (SMB) workloads.June 2020H17463.1
SMB design considerations and common practicesRevisionsDateDescriptionDecember 2018Initial releaseApril 2019Updated with new template; added content about SMB performance datasetmonitoring introduced on OneFS 8.2.0December 2019Updated content about performance dataset monitoring on OneFS 8.2.2June 2020PowerScale rebrandingAcknowledgmentsThis paper was produced by the following members of Dell EMC:Author: Frances Hu, Vincent Shen, Lieven LinDell EMC and the authors of this document welcome your feedback and any recommendations for improvingthis document.The information in this publication is provided “as is.” Dell Inc. makes no representations or warranties of any kind with respect to the information in thispublication, and specifically disclaims implied warranties of merchantability or fitness for a particular purpose.Use, copying, and distribution of any software described in this publication requires an applicable software license.This document may contain certain words that are not consistent with Dell's current language guidelines. Dell plans to update the document oversubsequent future releases to revise these words accordingly.This document may contain language from third party content that is not under Dell's control and is not consistent with Dell's current guidelines for Dell'sown content. When such third party content is updated by the relevant third parties, this document will be revised accordingly.Copyright 2018--2020 Dell Inc. or its subsidiaries. All Rights Reserved. Dell Technologies, Dell, EMC, Dell EMC and other trademarks are trademarksof Dell Inc. or its subsidiaries. Other trademarks may be trademarks of their respective owners. [1/30/2021] [Technical White Paper] [H17463.1]H17463.1
SMB design considerations and common practicesTable of contentsRevisions.2Acknowledgments .2Table of contents .3Executive summary .5Audience .51SMB design considerations and common practices .61.1SMB protocol introduction .61.2Networking .71.2.1 Jumbo frames .71.2.2 Link aggregation .81.2.3 SmartConnect .81.3Access zones.91.3.1 Directory service .91.3.2 Access zones separation .91.3.3 Kerberos authentication .91.4Multi-protocol access .101.4.1 Overview .101.4.2 ID mapping .101.4.3 User mapping .111.4.4 ACL policies .121.5SMB share creation .141.5.1 Overlapping SMB share .141.5.2 Existing ACL or Windows default ACL .141.5.3 Opportunistic lock (oplock) and lease.151.5.4 Access Based Enumeration (ABE) .171.6SMB administration .171.6.1 /ifs lockdown .171.6.2 Role-Based Access Control .171.6.3 SMB signing.181.6.4 Audits .181.6.5 Antivirus .181.6.6 Impact of upgrades .201.7Performance .211.7.1 Overview .21H17463.1
SMB design considerations and common practices1.7.2 PowerScale performance management .211.7.3 isi statistics .241.7.4 Client OS performance management .312SMB feature considerations and common practices .322.1SMB continuous availability and witness .322.1.1 Feature introduction .322.1.2 How SMB continuous availability works .322.1.3 Considerations .342.2SMB multichannel .352.2.1 Feature introduction .352.2.2 Considerations .362.3SMB server-side copy .362.3.1 Feature introduction .362.3.2 Considerations .362.4SMB encryption .372.4.1 Feature introduction .372.4.2 Considerations .392.5SMB symbolic links .392.5.1 Feature introduction .392.5.2 Considerations .402.6SMB file filtering .422.6.1 Feature introduction .422.6.2 Considerations .42ATechnical support and resources .44A.1H17463.1Related resources.44
SMB design considerations and common practicesExecutive summaryThis white paper provides considerations and common practices to help network and storage architects andadministrators plan, configure, monitor, and manage Microsoft Server Message Block (SMB) configurationand design with Dell EMC PowerScale products. This document covers the following topics: SMB management design and considerations on the PowerScale clusterSMB networking design and considerations on the PowerScale clusterSMB security and access control configurations on the PowerScale clusterSMB performance tuning and troubleshooting on the PowerScale clusterSMB feature introduction, considerations, and performance test resultsAudienceThe guide is intended for experienced system and storage administrators who are familiar with file servicesand network storage administration.The guide assumes the reader has a working knowledge of the following: Network-attached storage (NAS) systemsThe SMB storage protocolThe PowerScale scale-out storage architecture and the PowerScale OneFS operating systemFile-system management concepts including provision and permissionIntegration practices for connecting and establishing authentication relationships with Microsoft ActiveDirectoryFor more information on the topics discussed in this paper, Dell EMC recommends reviewing the followingpublications: H17463.1Dell EMC PowerScale OneFS: A Technical OverviewPowerScale OneFS Web Administration GuidePowerScale OneFS CLI Administration GuideCurrent PowerScale Software ReleasesOneFS Security Configuration Guide
SMB design considerations and common practices1SMB design considerations and common practices1.1SMB protocol introductionThe SMB protocol is a network file sharing protocol, and as implemented in Microsoft Windows is known asthe Microsoft SMB protocol. The set of message packets that defines a particular version of the protocol iscalled a dialect. The Common Internet File System (CIFS) protocol is a dialect of SMB. Both SMB and CIFSare also available on virtual machines, and several versions of UNIX and Windows operating systems.The Microsoft SMB protocol is a client-server implementation and consists of a set of data packets, eachcontaining a request sent by the client or a response sent by the server. These packets can be broadlyclassified as follows: Session control packets: Establishes and discontinues a connection to shared server resources.File access packets: Accesses and manipulates files and directories on the remote server.General message packets: Sends data to print queues, mailslots, and named pipes, and providesdata about the status of print queues.For more detailed information on the SMB protocol, refer to the Microsoft TechNet article Microsoft SMBProtocol and CIFS Protocol Overview.Table 1 lists different versions of SMB supported by Windows operating systems. Table 2 lists SMB featuressupported by PowerScale OneFS versions.SMB version supported by Windows Operation SystemH17463.1VersionSupported Windows operating systemsSMB 1.0 (or SMB1) SMB 2.0 (or SMB2) Windows Vista (SP1 or later) Windows Server 2008SMB 2.1 (or SMB2.1) Windows 7 Windows Server 2008 R2SMB 3.0 (or SMB3) Windows 8 Windows Server 2012SMB 3.02 (or SMB3) Windows 8.1 Windows Server 2012R2SMB 3.1.1 (or SMB3) Windows 10 Windows Server 2016Windows 2000Windows XPWindows Server 2003Windows Server 2003 R2
SMB design considerations and common practicesSMB features supported by PowerScale OneFS versions1.2SMB featureSupported OneFS versionsSection in this documentSMB multichannelPowerScale OneFS 7.1.1 and SMB multichannellaterSMB symbolic linksPowerScale OneFS 7.1.1 and SMB symbolic linkslaterSMB server-side copyPowerScale OneFS 8.0 andlaterSMB server-side copySMB file filteringPowerScale OneFS 8.0 andlaterSMB file filteringSMB continuous availabilityPowerScale OneFS 8.0 andlaterSMB continuous availability andwitnessSMB continuous availability andwitnessSMB encryptionPowerScale OneFS 8.1.1 and SMB encryptionlaterNetworkingIn a scale-out NAS environment, the overall network architecture must be configured to maximize the userexperience. Many factors contribute to overall network performance. The following sections list someconsiderations of jumbo frames, link aggregation, and SmartConnect that benefit the user experience onPowerScale systems. For other general design consideration, refer to the white paper PowerScale NetworkDesign Considerations.1.2.1Jumbo framesJumbo frames are Ethernet frames where the maximum transmission unit (MTU) is greater than the standard1500 bytes and could be up to 9000 bytes. The larger MTU size provides greater efficiency as less overheadand fewer acknowledgments are sent across devices, drastically reducing interrupt load on endpoints.However, this is not applicable to all workloads.To take advantage of the greater efficiencies, jumbo frames must be enabled end-to-end on all hops betweenendpoints. Otherwise, the MTU could be lowered through Path MTU Discovery (PMTUD) or packets could befragmented. The fragmentation and reassembly impacts the CPU performance of each hop, which impactsthe overall latency.Here are some general considerations for MTU settings with different scenarios. While the generalassumption is that jumbo frames provide performance advantages for all workloads, it is important to measureresults in a lab environment simulating a specific workload to ensure performance enhancements. H17463.1Generally speaking, MTU with default value (1500 bytes) often provides adequate performance.If a customer uses a 10 GbE network configuration, general guideline is to set 4500 or 9000 bytes forperformance advantages and must be enabled end-to end on all hops between endpoints.If a customer uses 40 GbE network configuration, general guideline is to set 9000 bytes forperformance advantages and must be enabled end-to-end on all hops to ensure the performance.
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:[email protected]. 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