EMC VNX Series: Introduction to SMB 3.0 Support

Transcription

1 White Paper EMC VNX Series: Introduction to SMB 3.0 Support Abstract This white paper introduces the Server Message Block (SMB) 3.0 support available on the EMC VNX and the advantages gained over the previous SMB versions. A VNX system can be implemented in a Microsoft Windows environment (with Microsoft Windows 8 and Windows Server 2012) to leverage the enhancements in the SMB 3.0 protocol. March 2015

2 Copyright 2015 EMC Corporation. All Rights Reserved. EMC believes the information in this publication is accurate as of its publication date. The information is subject to change without notice. The information in this publication is provided as is. EMC Corporation makes no representations or warranties of any kind with respect to the information in this publication, and specifically disclaims implied warranties of merchantability or fitness for a particular purpose. Use, copying, and distribution of any EMC software described in this publication requires an applicable software license. For the most up-to-date listing of EMC product names, see EMC Corporation Trademarks on EMC.com. VMware is a registered trademark of VMware, Inc. in the United States and/or other jurisdictions. All other trademarks used herein are the property of their respective owners. Part Number H

3 Table of Contents Executive summary... 4 Audience... 5 Terminology... 5 Concepts... 6 SMB version and negotiation... 6 SMB 3.0 on VNX... 6 Continuous Availability (CA)... 7 Server failover... 7 Client failover... 9 Enabling Continuous Availability Multichannel Directory Lease Offload Copy BranchCache V SMB Encryption Encryption settings Encryption keys Enabling encryption Remote Volume Shadow Copy Service Large IO Conclusion References

4 Executive summary EMC VNX has incorporated the Server Message Block (SMB) protocol as an open standard for network file service. SMB is a file access protocol designed for the internet and is based on the Common Internet File System (CIFS) protocol that the Microsoft Windows operating system uses for distributing file sharing, printing, and communication services from a server over a network. SMB 3.0 is supported with Microsoft Windows 8 and Microsoft Windows Server 2012 systems and has significant improvements over the previous SMB versions. For VNX File Operating Environment (OE) version and later, the SMB 3.0 protocol is supported on VNX. VNX supports SMB 1.0, SMB 2.x, and SMB 3.0 protocol communications between client and server. VNX supports SMB 3.0 enhancements that include: Continuous Availability (CA) Continuous Availability enables applications to be less impacted during a Data Mover or cluster failover. With CA enabled on a share, if the failover period does not exceed the application timeout, application access to all open files that were present prior to the failover is re-established and the failover is transparent to end users. Multichannel - Multiple TCP connections can now be associated with a single SMB 3.0 session and a client application can use several connections to transfer I/O on a CIFS share. This optimizes bandwidth and enables failover and load balancing with multiple NICs. Directory Lease SMB 2 introduced a directory cache that allowed clients to cache a directory listing to save network bandwidth but would not see new updates. SMB 3 introduces a directory lease and the client is now automatically aware of changes made in a cached directory. Offload Copy - Copying data within the same Data Mover can now be offloaded to the storage, which reduces the workload on the client and network. SMB Encryption - Provides secure access to the on CIFS shares, protects data on untrusted networks, and provides end-to-end encryption of data in- flight. Remote Volume Shadow Copy Service (RVSS) With RVSS, point-in-time snapshots can be taken across multiple CIFS shares, providing improved performance in backup and restore. Organizations with geographically dispersed sites must uphold data availability without sacrificing security. Furthermore, performance implications need to be considered, especially when operations are distributed among remote sites. Administrators responsible for managing a Windows environment in their company can leverage VNX support for SMB 3.0 in their IT infrastructure implementations to alleviate these concerns. 4

5 Audience This white paper is intended for EMC customers, partners, and employees who want to understand the SMB 3.0 protocol support of VNX. Readers of this document should be familiar with VNX CIFS shares and Windows Operating System. For additional information about VNX CIFS shares, refer to Configuring and Managing CIFS on VNX on EMC Online Support. Terminology BranchCache A WAN optimization protocol which enables content from file servers on a wide area network (WAN) to be cached on computers at a local branch office. CIFS Server A logical server that uses the CIFS protocol to transfer files. A Data Mover can host many instances of a CIFS server. Each instance is referred to as a CIFS server. Common Internet File System (CIFS) A file-sharing protocol based on Microsoft Server Message Block (SMB). It enables users to share file systems over the Internet and intranets. Data Mover (DM) In VNX for File, a cabinet component that is running its own operating system that retrieves data from a storage device and makes it available to a network client. This is also referred to as a blade. Shadow Copy Point-in-time copy created through Microsoft Volume Shadow Copy Service (VSS). VSS identifies each shadow copy by a 16-byte GUID (Globally Unique Identifier). Share Directory on a file system or that is made available to CIFS users on the network. Also, the process of making a file system, directory, or service available to CIFS users on the network. Storage Processor (SP) Storage processor on VNX for Block. On VNX for Block, a circuit board with memory modules and control logic that manages the system I/O between the hosts Fibre Channel adapter and the disk modules. Unisphere A web-based management environment for creating storage resources, configuring and scheduling protection for stored data, and managing and monitoring other storage operations. Volume Shadow Copy Service (VSS) A Windows service and architecture that coordinates various components to create consistent point-in-time copies of data called shadow copies. 5

6 Concepts SMB version and negotiation The SMB protocol follows the client-server model; the protocol level is negotiated by the client request and server response when establishing a new SMB connection. CIFS Windows NT 4.0 SMB 1.0 Windows 2000, Windows XP, Windows Server 2003, and Windows Server 2003 R2 SMB 2.0 Windows Vista (SP1 or later) and Windows Server 2008 SMB 2.1 Windows 7and Windows Server 2008 R2 SMB 3.0 Windows 8 and Windows Server 2012 SMB 3.02 Windows 8.1 and Windows Server 2012 R2 Before establishing a session between the client and server, a common SMB dialect must be negotiated. As shown in Table 1, the common dialect depends on the SMB version supported by both the client and DM. Table 1 SMB dialect used between Client and DM Client / DM SMB 3.0 SMB 2.1 SMB 2.0 SMB 3.02 SMB 3.0 SMB 2.1 SMB 2.0 SMB 3.0 SMB 3.0 SMB 2.1 SMB 2.0 SMB 2.1 SMB 2.1 SMB 2.1 SMB 2.0 SMB 2.0 SMB 2.0 SMB 2.0 SMB 2.0 SMB 1.0 SMB 1.0 SMB 1.0 SMB 1.0 Note: SMB 3.0 leverages the SMB 2 protocol and the same SMB 2 packet formats are utilized by SMB 3.0. SMB 3.0 was originally known as SMB 2.2. For more information on SMB 2.x versions and negotiations, refer to the Microsoft TechNet Website at SMB 3.0 on VNX Beginning with VNX File Operating Environment (OE) version , the SMB 3.0 protocol is now enabled by default on VNX. Note that VNX uses SMB 3.0 when negotiating with SMB 3.02 clients. To check if SMB 3.0 is enabled on your DM, use the server_cifs command to check the Max Protocol as shown in Figure 1. 6

7 Figure 1 Check SMB 3.0 If SMB 3.0 is not enabled on your DM, you can enable it using the server_cifs command as shown in Figure 2. Figure 2 Enable SMB 3.0 Continuous Availability (CA) In a client or CIFS server failure, the Continuous Availability (CA) feature allows Windows-based clients to persistently access CIFS shares without the loss of the session state. You can leverage this feature when planning with storage availability in mind for business-critical applications such as Microsoft SQL Server, IIS, and Hyper-V. Server failover For a CIFS server to recover client content in a Data Mover failover, persistent handles are introduced in SMB 3.0. When CA is enabled on a share, persistent handles enable a CIFS server to save specific metadata associated to an open file handle on disk. When a Data Mover failover occurs, the new primary Data Mover reads the metadata from disk before starting the CIFS service. The client will re-establish its session to the Data Mover and attempt to re-open its files and the Data Mover will return the persistent handle to the client. The end result is no impact to the application accessing the open files, if the failover time does not exceed the application timeout. It is important to note that whether CA works in a Data Mover failover or failback situation is dependent on the timeout of the application. As long as the Data Mover failover or failback period does not exceed the timeout of the application, the application can remain online. 7

8 Figure 3 Server Continuous Availability Figure 3 shows the sequence of events for a Data Mover failover with CA enabled: 1. The client requests a persistent handle by opening a file with associated leases and locks on a CIFS share. 2. The CIFS server saves the open state and persistent handle on disk. 3. The primary Data Mover is failed over to the standby Data Mover. 4. The Data Mover reads and restores the persistent open state from the disk before starting the CIFS service. 5. Using the persistent handle, the client re-establishes the connection to the same CIFS server and recovers the same context associated with the open file as before the failover occurred. CA enables SMB clients to transparently reconnect to the peer Data Mover without affecting clients accessing files on the shares. 8

9 A persistent open requires the metadata of the file be committed to the back-end storage before a request is completed, which includes: All file data All namespaces changes Security descriptor File size File dos attributes File timestamps on explicit setinfo or create If a failover of a Data Mover occurs, the server will preserve the state of the persistent handle. This means that any new open state conflicting with the share mode or new range lock requests will be denied. Furthermore, any new open state involving a lease break will be suspended. Before enabling the CA feature, keep in mind that: With CA enabled, you can achieve a transparent server failover for implementations where the failover time is no longer than the application timeout. In such implementations, hosts can continue to access a CIFS resource without the loss of a CIFS session state following a failover event Enabling CA will make all I/O going to that share be performed in synchronous or write-through mode. Performance may be affected and the impact will be similar to enabling the uncached mount option on a file system CA is designed for applications, such as Microsoft Hyper-V or SQL Server, where the file open/close operations are limited. It is not recommended to use CA in scenarios where the impact of storing the open states is not negligible such as Home Directory implementations Client failover A common approach to mitigate data unavailability at the client level is to configure Windows clients in a cluster. In the previous SMB 2.x implementation, the problem with this scenario was that the server kept the handles of the clients with associated locks. Since the peer cluster node (to which the application had failed over) is not the same as the original node, a conflict occurred when the application tried to re-open the file and set the same locks. The server did not realize that this was the same application trying to re-open its file. To address this issue, SMB 3.0 introduces the concept of an instance ID. The instance ID is a 16-byte unique identifier assigned by the application, such as SQL Server 2012, on a file handle and is maintained for the lifetime of the handle. Using this, the application will not conflict with the session established prior to the failover because it can now be identified by the instance ID. The assumptions are that Windows Server 9

10 2012 cluster logic ensures the same instance ID is not used by multiple applications at the same time, and only a single instance of an application can be running at any time. Figure 4 Client Continuous Availability Figure 4 describes the basic sequence of events when a node in a Windows cluster fails over: 1. The application opens a file on the CIFS share and sets locks. 2. Node 1 fails and the Windows cluster moves the application from node 1 to node The application re-opens its content on the CIFS share from node 2. Applications accessing the data stored on the CIFS share are not interrupted. 10

11 Enabling Continuous Availability The Continuous Availability (CA) feature is disabled by default. To enable CA, the file system must first be mounted with the smbca mount option as shown in Figure 5 Enabling CA on the file system. This is a CLI only procedure. Figure 5 Enabling CA on the file system Then the CIFS share must be exported with the type=ca option as shown in Figure 6. This is a CLI only procedure. Figure 6 Enabling CA on a CIFS share Multichannel SMB 3.0 introduces Multichannel where multiple TCP connections can be associated with a single SMB session. A restriction in the previous versions of SMB was that only one TCP connection could be established per SMB session. Now, if one TCP connection is broken, the user session can continue using the remaining, active TCP connections. The connection to the CIFS server on the Data Mover remains established until the last TCP connection is terminated. Multichannel provides several benefits, including: Increased bandwidth Transparent network interface failover Load balancing When establishing the SMB session, the CIFS server must send the response on the same TCP connection the request arrived on. Once the session has been established, the client sends a request to retrieve the list of interfaces available from the DM and uses the best interface available for I/O. If multiple interfaces are available, the client will open new connections on an as-needed basis. For example, when the pending I/O queue begins growing, the client will open additional connections to improve bandwidth. If the network interface controller (NIC) supports Receive Side Scaling (RSS), multiple TCP connections can be opened on the same NIC and be load balanced across multiple CPU cores. Multiple RSS NICs can be used to support multiple TCP 11

12 connections on each NIC for a single SMB session. You can run the netstat command on a client to check the number of open TCP connections. As shown in Figure 7, there are two TCP connections on two NICs associated with the SMB session. Figure 7 Multiple TCP connections Directory Lease In SMB 2.0, Microsoft developed a directory content cache that resided on the client. This increased performance by reducing the amount of directory list requests transmitted over the network. However, a disadvantage of this feature is that when a client modifies files or folders, clients with a cached listing would not be aware of the changes even when the directory listing is refreshed by the user. SMB 3.0 improves the directory content cache with the concept of a directory lease. By setting a lease on a directory, the Windows client is automatically aware of a content change made in an open directory. If the content is created, modified, or deleted in the directory, the directory lease is broken. The next directory list request will be serviced by the CIFS server, instead of from the directory cache, with the latest changes. 12

13 There are three types of leases: Read-caching lease (R) enables a client to cache reads, and can be granted to multiple clients Write-caching lease (W) enables a client to cache writes A handle-caching lease (H) enables a client to cache open handles, and can be granted to multiple clients Client B Client A Figure 8 Directory Lease Figure 8 describes the sequence of events when a directory lease is broken: 1. Client A opens a directory and caches the listing. 2. Client B changes a file or folder in the same directory. By making this change, the directory lease is broken. 3. Client A is notified that its cached directory content is no longer up-to-date, and sends a query to update that directory. 13

14 Offload Copy SPB SPA 2 7 Command Data Data Mover 3 Data Mover Client Figure 9 Pre-SMB 3.0 data copy Figure 9 shows the sequence of events required for a pre-smb 3.0 copy: 1. The client requests data to be copied. 2. The Data Mover requests data from the Storage Processor. 3. The Storage Processor sends data to the Data Mover. 4. The Data Mover sends data to the client over the network. 5. The client sends back the same data to the Data Mover over the network. 6. The Data Mover sends back the same data to the Storage Processor to be written. 7. The Storage Processor acknowledges the Data Mover. 8. The Data Mover acknowledges the client. 14

15 Transferring data to the client and back results in wasted resources and adds additional overhead. Offload copy is designed to improve efficiency by allowing the Data Mover to do the copy instead of sending data to the host and back again. It is a token-based copy method where a 512-byte token is used to represent up to 256MB of actual data. SPB SPA 4 Command Data Token Data Mover 3 Data Mover Figure 10 Offload Copy Figure 10 describes the sequence of events for an Offload Copy: 1. The client submits a copy request for a file. 2. The Data Mover builds a token and sends it to the client. 3. The client uses the token to generate the write request. 4. The Data Mover performs the copy. 5. The Data Mover acknowledges the client. 15

16 The main benefit of Offload Copy is the elimination of reading and writing data across the network. The host CPU usage and network bandwidth required is reduced. Offload copy is only used for files that are greater than 512 KB as the token overhead would make it impractical for smaller files. Note that if the data that is represented by the token is modified, the token is invalidated and an error is returned. The client then reverts back to the old copy method using a standard read and write. BranchCache V2 BranchCache is a Microsoft feature that was originally introduced in the Windows 7 and Windows Server 2008 R2 operating systems. It is designed to optimize wide area network (WAN) bandwidth when one or more remote branch offices need to connect to the main office to retrieve data. This had several disadvantages including poor application responsiveness, high WAN link utilization, and WAN bandwidth is expensive. When BranchCache is enabled, it creates a cache of the content from the DM, locally within a branch office. A client from the same network can request the file and download it from the local cache, instead of downloading it from the wide area network. BranchCache optimizes the local link utilization and the responsiveness of applications, and reduces the WAN bandwidth consumption. When a file is requested from the DM in the main office, a hash of the file is sent to the client instead of the file itself. The hash, known as the signature, is much smaller than the file itself and the client uses it to search the branch office for the file. If a match is found at the branch office, the client will retrieve the file using the LAN. If no match is found, the client retrieves the file through the WAN and caches it for other clients at the branch. An update to BranchCache was released in Windows 8 and Windows Server 2012 called BranchCache V2. In the original BranchCache, files were divided into 32 MB segments and each segment was divided into 65KB blocks. Each block was hashed using SHA256 to generate the signature. In BranchCache V2, a simpler format was introduced to increase the likelihood of finding signature matches. The concept of blocks has been dropped. Files are divided into segments and each segment is hashed using SHA256 to generate the signature. VNX uses a fixed segment size of 128KB. SMB Encryption SMB encryption provides secure access to data over untrusted networks by providing end-to-end encryption between the client and VNX. It does not require specialized hardware, IPSec, or WAN accelerators. Scenarios where SMB encryption can be utilized include Remote Office Branch Office (ROBO) over WAN networks and application workloads over unsecured networks. 16

17 Encryption at the share-level is enabled on the particular share, and encryption is enforced when that share is accessed. Optionally, encryption can be enforced at the system-level (where encryption is set in the registry of the CIFS server), and all share access would require encryption. There is no configuration needed at the client-level. SMB encryption is not the same as Data at Rest Encryption (DARE) and will not encrypt data on disk. SMB encryption only encrypts data during transmission over the network. Once the data arrives at the destination, it is decrypted before it is saved to disk. Encryption settings To support the SMB 3.0 protocol, VNX has two new values added to the registry of the CIFS server: EncryptData and RejectUnencryptedAccess. Setting the EncryptData value enables encryption on all shares on the CIFS server. By default, the EncryptData value is disabled. Setting the RejectUnencryptedAccess value prevents clients that do not support encryption from establishing a session to the share. Instead, the client receives an ACCESS_DENIED message after the failed attempt. Disabling the RejectUnencryptedAccess value gives pre-smb 3.0 clients the ability to access encrypted shares. By default, the RejectUnencryptedAccess value is enabled. To configure these parameters on the registry of the CIFS server, do the following steps: 1. Open the Registry Editor (regedit.exe) on a computer. 2. Select File > Connect Network Registry. 3. Type the hostname or IP Address of the CIFS server and click Check Names. When the server is recognized, click OK to close the window. 4. You can edit the parameters under HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanmanServer\Pa rameters as shown in Figure

18 Figure 11 Location of SMB Encryption values in the Registry On VNX, encryption can also be enabled at the share-level by using the type=encrypted export option. Once encryption is enabled, the SMB payload is encrypted only when an encrypted share is accessed. You can also use the RejectUnencryptedAccess value with the type=encrypted export option to control the behavior when a pre-smb 3.0 client attempts to access it. Encryption keys Incoming and outgoing traffic are encrypted using two different secret keys. Both are computed once the user is authenticated successfully. The encryption and decryption 16-byte keys are generated using the KDF algorithm in Counter Mode. SMB messages on the network are encrypted between the client and server using the AES128-CCM cryptographic algorithm, as described in RFC4309 and RFC3610. The format of the encrypted messages consists of an SMB 2 TRANSFORM_HEADER header followed by the payload. Any SMB 2 message can be encrypted, except SMB 2_NEGOTIATE and SMB 2_SESSION_SETUP. Enabling encryption To enable encryption on a share, export it with the type=encrypted export option as shown in Figure 12. This is a CLI only procedure. 18

19 Figure 12 Enabling Encryption on a Share It is important to note that there is a performance impact associated with enabling encryption. Data is encrypted at either the client or VNX before it is sent across the network and decrypted at the destination as it is received. CPU resources are required on both client and VNX for these operations. Remote Volume Shadow Copy Service Volume Shadow Copy Service (VSS) infrastructure enables file systems to be backed up while applications continue to write to these volumes and enables creation of snapshots (called shadow copies for Microsoft VSS). Prior to SMB 3.0, VSS could only create and manage snapshots of data stored on local volumes. With Windows Server 2012, Microsoft has extended this feature with Remote Volume Shadow Copy Service (RVSS). RVSS supports application backup across multiple file servers and shares. Backup applications that are VSS-aware can now perform snapshots of server applications that store data on the VNX CIFS shares. Hyper-V has the ability to store virtual machine files on CIFS shares. RVSS can be leveraged to take point-in time copies of the contents of the share. The application can create a writeable snap to leverage RVSS and then perform a resynchronize operation before the backup is started. Figure 13 shows a simple deployment of a single Hyper-V server utilizing VNX to store virtual machines and user data. 19

20 Data Mover 3 Data Mover 2 Marketing Share Sales Share Marketing VM Sales VM Figure 13 Backup Hyper-V VMs on CIFS shares Two Hyper-V CIFS shares are provisioned on VNX: one for the Marketing team and the other for the Sales team. Each member of these teams has an assigned virtual machine and accesses files via their group s respective shares. The Marketing VM stores the virtual machine files on the Marketing share whereas Sales VM stores the virtual machine files on both the Marketing and Sales shares. When the backup application performs a snapshot of Marketing VM, VNX takes a snapshot of the Marketing file system. A snapshot of the Sales file system is not taken since only the Marketing share is used by the Marketing VM. The snapshot data can then be made available to the backup application to perform a backup of the data. When a snapshot of Sales VM is taken, both the Marketing and Sales file systems are included in the snapshot taken by VNX. 20

21 Large IO The SMB 3.0 protocol, by default, enables large IO sizes for reads and writes. The maximum I/O size is now 1 MB, which improves performance for large data copies by limiting the number of SMB commands on the network. Conclusion Data availability, performance, and security are factors that you must consider in your organization s IT infrastructure. This is especially important when organizations have remote offices across different regions of the world. You can utilize the VNX support of the SMB 3.0 protocol, along with Microsoft Windows 8 and Windows Server 2012, to address some common concerns. Continuous Availability and Multichannel are features that maintain data availability in a failure at the client, server, or network level. Offload Copy enables efficient data consolidation or migration of content stored on CIFS shares. BranchCache V2 optimizes the local link utilization and the responsiveness of applications, and reduces the WAN bandwidth consumption. In terms of security, SMB Encryption enforces protection when data is exchanged between Windows clients and VNX over untrusted networks, and enables administrators to decide which Windows clients are granted access to this data. Leveraging RVSS, point-in-time snapshots of the CIFS shares can be taken across multiple shares and provide improved performance for backup and restore. References Configuring and Managing CIFS on VNX Configuring BranchCache on VNX Microsoft TechNet at 21