SMB1 and SMB2 are remote file access protocols that form the basis for Windows file sharing. Each time you browse or access files on a Windows server using Windows Explorer, the SMB protocols are used to transport information (files or directory information) back and forth between your computer and the server you are accessing.
In addition to file sharing, SMB is also used as a transport protocol for various higher level Microsoft communications protocols, as well as for network printing, resource location services, remote management/administration, network authentication (secure establishment services), and RPC (Remote Procedure Calls). SMB operates very poorly over a high latency WAN link because by design SMB sends a large number of back and forth transactions to complete a request.
The primary goal of Exinda SMB acceleration is to reduce the overall accumulated latency introduced by the chattiness of the SMB protocol. Each Exinda appliance can act on behalf of an SMB client and server to make the interaction between the two computers more efficient. Exinda maintains a state machine and database of SMB behaviors that it relies upon to optimize future SMB related transactions. When Exinda determines that a certain SMB transaction is likely to occur, it pre-fetches data and temporarily stores it in the appliance memory for future reference. Once the pre-fetched data is referenced, the data is deleted from the memory. See figure below.
SMB acceleration works seamlessly TCP Acceleration, WAN Memory, and Compression and benefits from the ability of the WAN memory to reduce data traversing the WAN, just as with other applications such as FTP, HTTP, or email.
To deal with the inefficiencies of the SMB protocol Exinda has developed several optimizations to improve the performance of applications using this protocol. Each version of SMB handles file transfer optimizations in different ways, and may include reading ahead of the data stream, writing behind the data stream, and caching meta data about files and folders. In addition to this, the Exinda appliance ensures that data is efficiently compressed and de-duplicated.
With SMB1 there are several opportunities to provide optimizations: object caching, read ahead and write behind of data, and meta-data caching.
Object Cache
This refers to the saving of files to an internal file storage area on the appliance. When a client reads a file, it is cached on both the client side and server side appliances. This significantly improves response time for successive reads of the same file as it occurs at LAN speed instead of WAN speed. When a client writes a file, the object cache is updated which allows successive reads of the file to be served as efficiently as possible without having to use the WAN.
Read Ahead
Reading ahead of the data stream is an optimization by which the appliance pre-fetches the contents of a file ahead of the client that is attempting to read it. When the Exinda appliance detects a client attempting to perform a sequential bulk read of a file, the appliance fabricates read requests to the server on behalf of the client. The end result is that the appliance is effectively sending the reads to the server and pre-populating both the client side and server side cache. Since SMB1 clients perform reads serially, this dramatically improves cold pass read performance and helps to populate the object cache quickly.
Write Behind
Writing behind the data stream is an optimization by which the Exinda appliance immediately responds to the client when it is trying to write a file. When the appliance detects a client attempting to perform a bulk write to a file, it immediately responds to the client from the client side appliance. The end result is that the Exinda appliance is effectively sending the write requests to the server so the conversation between the client and client side appliance is occurring at LAN speed. Since SMB1 clients perform writes serially, the immediate response by the appliance allows the client write requests to fill the connection, making it appear to be asynchronous and significantly improving write performance.
Meta-data Caching
Meta-data caching is an optimization by which the Exinda appliance caches the properties related to files and folders on both the client side and server side appliances. When a client queries the properties of a file or folder, it is served from cache which eliminates the need to go across the WAN. This occurs quite frequently when browsing a file share location that has a larger number of file and folder entries. Similar to the object cache, change notifications are registered to ensure that the meta-data cache does not serve stale information.
With the addition of SMB2, most of the optimizations that were implemented for SMB1 no longer apply. Below is a rationale for each of these and why they are no longer needed.
Read Ahead and Write Behind
In SMB2, read ahead and write behind requests are built in to the client, effectively stacking the requests one on top of the other in an asynchronous manner without any gaps between them. As a result, there is no accumulation of latency and therefore no need for the appliance to attempt to perform any sort of read prefetching or immediate write response.
Meta-data Caching
In SMB2, meta-data caching is performed by the client. This eliminates the need for the appliance to do any caching in the middle as the client very quickly caches its own copy of the file and folder meta-data locally and uses that for the duration of the session.
Aside from the protocol specific optimizations that are provided by the appliance, the Exinda SMB acceleration framework also provides some significant downstream optimization benefits, primarily in the areas of compression and de-duplication. The SMB acceleration framework is reconstructing the SMB messages in their entirety before processing them. This means that for large data centric operations like reading and writing a file, the appliance is actually operating on large blocks of data as opposed to individual packets of fragmented data. In doing so, Exinda passes off these large blocks of data to our WAN memory framework. This allows the WAN memory framework to heavily optimize for compression and de-duplication.
|
|
|