An NFS Tutorial – Part 2: NFS READs, WRITEs and Why Caching Matters By Andrew Zillman On April 25, 2011
The last installment of our NFS tutorial introduced the concept of metadata: those little bits of data about data that can bring even the mightiest of NFS installments to a slow crawl. With the metadata piece of the puzzle identified, let’s now examine some very rudimentary NFS operations: READ and WRITE.
Most, if not all, NFS operations are transparent to the user. In fact, many clients take these operations for granted. For example, each time a client requests a design file or puts finishing touches on a layer of that file, a host of network activity occurs that the user never notices. What the user does notice, however, is the time it takes to pull up that file or save it back up to the network; and, this can be so noticeable, that they become frustrated by a seemingly simple task. This frustration comes in the form of latency, the time taken from a user’s request to the time that user receives a response. The diagram below details a simple example of what happens when a client READs blocks of a file. As indicated, many operations are required before a client is able to read the requested block(s) of data.
While this is an oversimplified view of NFS reality, the model serves its purpose: even a seemingly innocuous operation such as READing a file results in a large number of operations across the network, which can bring the network to a slow crawl. NFS WRITEs are inherently different in the way data is handled, but work in a similar manner in the number of operations necessary to commit a block of data. Keep in mind that the above diagram represents a single request from a single user on the network. Now multiply that request by thousands of users accessing hundreds of the same files all day long. You get the picture…and the bog down isn’t pretty.
To solidify this example, let’s take a look at a real-world application that is exceedingly data-intensive: digital animation and design. In the animation space, many clients operate simultaneously to create digital images, often times working on individual “layers” of a greater image rather than editing the entire image itself. In an attempt to distribute the workload of an otherwise resource-intensive task, multiple clients work on (i.e., READ and WRITE) separate portions of the digital rendering simultaneously. This poses a problem in that multiple clients need to know the current status of the image before committing any changes. Through NFS metadata, clients are able to determine if their local copy of the image is still the most recent copy of the image on the server. As you might have guessed, staying current means READing statuses, which creates a lot of network chatter that not only ties up the back-end NAS server, but also slows down the WRITE functionality, ultimately leading to that noticeably sluggish response time mentioned earlier.
Now, consider an alternative that includes a cache design. What if a network device was designed to mitigate these types of headaches? The ANX 1500 is designed to do just that. Let’s revisit our example with the ANX now in place. Suppose Client 1 wants to read blocks 1, 2 and 3 from a given image. An NFS request is initiated to retrieve the data. With the ANX 1500 installed (we’ll assume Client 1 previously READ these blocks and as a result they reside in cache), this request can be facilitated with the data served back to Client 1 without the back-end NAS being involved. Simply stated, the ANX steps in and acts as a proxy for the NAS, offloading its responsibility of satisfying any READ requests that may come along and only WRITE requests are passed on to the back-end, quieting all that network chatter and improving response times for the user. In the end, the added benefits of caching translate into cost reduction for many, revenue enhancement for business units and reduced storage administration headaches. The how and the why will be detailed in the next NFS Tutorial installment…
Next on deck: Caching the ANX 1500 Way
Related posts:
Leave a Reply