No, no, FBI is not in the storage business and there are no witnesses to protect.
However, SMB 3.0 has introduced a RPC-based mechanism to inform the clients of any state change in the SMB servers. Microsoft calls it Service Witness Protocol [SWP], and its objective is provide a much faster notification service allow the SMB 3.0 clients to do a failover. In previous SMB 1.0 and even in SMB 2.x, the SMB clients rely on time-out services. The time-out services, either SMB or TCP, could take up as much as 30-45 seconds, and this creates a high latency that is disruptive to enterprise applications.
SMB 3.0, as mentioned in my previous post, had a total revamp, and is now enterprise ready. In what Microsoft calls “Continuously Available” File Service, the SMB 3.0 supports clustered or scale-out file servers. The SMB shares must be shared as “Continuously Available” shares and mapped to SMB 3.0 clients. As shown in the diagram below (provided by SNIA’s webinar),
Client A mapping to Server 1 share (\\srv1\CAshr). Client A has a share “handle” that establishes a connection with a corresponding state of the session. The state of the session is synchronously kept consistent with a corresponding state in Server 2.
The Service Witness Protocol is not responsible for the synchronization of the states in the SMB file server cluster. Microsoft has left the HA/cluster/scale-out capability to the proprietary technology method of the NAS vendor. However, SWP regularly observes the status of all services under its watch.
If there is any latency or disruption of the SMB service in any one of the SMB servers, SWP will inform the SMB 3.0 clients that there is latency or disruption in the SMB service. The affected SMB client will pause the uncommitted I/Os to the server, release the share “handle” from its connected of the failed server and then re-establish a new connection with the same share “handle” to a designated takeover SMB server. The new connection auto-recovers the SMB session, continues where it left off, and the client continues seamlessly and transparently.
The beauty of this is SWP can perform the notification to the SMB clients under 5 seconds, and without relying on SMB or TCP timeouts which could take up as much as 30-40 seconds. This is crucial in ensure little disruption to latency-sensitive enterprise applications such as databases or other index- or journaled-based services.
SWP and SMB are mutually exclusive protocols and they run independently with the Continuously Available architecture. However, in order for the SMB 3.0 clients to participate to use the Service Witness Protocol, the clients must be registered with the Service Witness Protocol. This is inherently built into SMB 3.0 CA services. The diagram below shows how a client interacts and registers with SWP.
Once the clients have registered with SWP, the SMB 3.0 clients will just wait for notification changes via RPC from the SWP which is monitoring the SMB services in the HA cluster.
The registered SMB clients are informed of candidate(s) SMB servers they are interact with if their primary SMB service fails.
While SWP is only a small piece in the entire SMB Continuously Available setup, it is no doubt a crucial piece to enable a enterprise-ready architecture. Microsoft have already announced that SMB 3.0 works with MS SQL Server, Sharepoint and MS Exchange.
And now my joke does not work anymore. 🙁
