An NFS Tutorial – Part 3: Caching the ANX Way By Andrew Zillman On June 2, 2011
In the first two installments of our NFS tutorial—The Metadata Challenge and NFS READs, WRITEs and Why Caching Matters—we focused on some of the basic functionality of the NFS protocol and why, in certain situations, mixes of data can negatively impact the performance of NFS across the network. Additionally, some simple NFS operations (READ, WRITE) were briefly detailed and we drew a link between our old friend metadata and its implications on NFS reads.
With all that now behind us, let us remember two, key takeaways from the previous two installments that make caching relevant: lots of metadata greatly impacts the “speed” at which multiple pieces of data can be successfully read, and the frequency of that data being read ultimately contributes to pain points on the user or administrative side of the equation. That said, we can now look at the ANX 1500 NFS Throughput Acceleration Appliance and how Alacritech addresses NFS data acceleration The following diagram shows a general overview of the ANX 1500’s hardware and software components. This blog will focus on three key hardware components including:
- Solid-State Drives (SSD)
- DRAM
- Alacritech 10GbE Accelerators featuring TCP Offload and NFS Acceleration
| In its simplest form, the ANX 1500 can be thought of as a device that retrieves data from the network and makes that data available to users. A network administrator configures the ANX 1500 to export various NFS file systems to which clients connect. As a client requests data, he or she now fetches that data from the ANX 1500 rather than a traditional, backend NAS appliance. Upon first request, data is transferred directly into DRAM via one or both 10Gb Ethernet adapter(s). At this point, the data is considered “cached”, meaning the data is now available to be accessed directly from the ANX 1500 without the client having to traverse all the way to the NAS appliance. It is important to note that the ANX has two levels of cache: DRAM and SSD. The most recent data reside in DRAM, while less frequently accessed data are moved to and from SSDs on a case-by-case basis. As data continue to flow to and from the ANX, the data are categorized into a series of buckets, or cases, each of which is handled differently by the ANX. Full detail regarding each case is described in ANX 1500 Caching Architecture Overview. |
 |
- Case 1: Inactive “Cold” Data – Data that has not yet passed through the ANX
- Case 2: Active “Hot” Data – Data resides in the ANX’s DRAM
- Case 3: Active “Warm” Data – Data resides in the ANX’s SSD
- Case 4: Committed Data – Data is passed to the backend NAS appliance
In this post, we have briefly looked at the ANX 1500’s hardware components and how the appliance handles data under the most common scenarios. For a more in-depth look at the ANX architecture, refer to the ANX 1500 Caching Architecture Overview.
Related posts:
Leave a Reply