Dell VNX5800 VNX Series: Introduction to SMB 3.0 Support - Page 9

Client failover, A common approach to mitigate data unavailability at the client level is to con

Page 9 highlights

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 EMC VNX Series: Introduction to SMB 3.0 Support 9

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23

9
EMC VNX Series: Introduction to SMB 3.0 Support
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