SMB Witness Protection Program

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),

SMB 3.0 CA Shares

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.

SWP client registration

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.

SMB SWP protocol diagram

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. 🙁

About cfheoh

I am a technology blogger with 20+ years of IT experience. I write heavily on technologies related to storage networking and data management because that is my area of interest and expertise. I introduce technologies with the objectives to get readers to *know the facts*, and use that knowledge to cut through the marketing hypes, FUD (fear, uncertainty and doubt) and other fancy stuff. Only then, there will be progress. I am involved in SNIA (Storage Networking Industry Association) and as of October 2013, I have been appointed as SNIA South Asia & SNIA Malaysia non-voting representation to SNIA Technical Council. I was previously the Chairman of SNIA Malaysia until Dec 2012. As of August 2015, I am returning to NetApp to be the Country Manager of Malaysia & Brunei. Given my present position, I am not obligated to write about my employer and its technology, but I am indeed subjected to Social Media Guidelines of the company. Therefore, I would like to make a disclaimer that what I write is my personal opinion, and mine alone. Therefore, I am responsible for what I say and write and this statement indemnify my employer from any damages.
Tagged , , , , , , , , . Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *