Nache Design and Implementation of a Caching Proxy

Nache: Design and Implementation of a Caching Proxy for NFSv 4 Bo Zhao Computer Science and Engineering The Pennsylvania State University

Motivation & Challenge n n Enterprises are moving toward distributed operations n Sharing files across office location in wide area Sharing data n In a uniform, secure, and consistent manner n Across the global enterprise n Reasonably good performance.

Related Work n n n NFS and CIFS - work for a LAN n Low latency and high bandwidth AFS and DCE/DFS – work for a WAN n Uniting disparate file servers into a single logical file system. n Deployment expense – not widely adopted GPFS or Lustre - high performance & strong consistency n Expensive or difficult to deploy and administer

Cache Consistency n n NFS – close-to-open consistency n When opening a regular file, n the client validates cached data for that file. The client queries the server to determine if the file has changed. Using this information, the client determines if the data cache for the file should be kept or flushed. n When the file is closed, n the client writes any modified data to the server. n No distributed cache coherency or concurrent write management AFS – rely on client-side caching for performance n Callback to notify the client of updates n Close – changes become visible at the server

New features of NFS v 4 COMPOUND RPC n n COMPOUND RPC n Many NFS operations in a single RPC call n Lower overall network delay Example: n RPC in NFS Versions 2 and 3 => OPEN “home/data” <= OPEN OK => READ at 0 for 32768 <= READ OK (32768 bytes) COMPOUND RPC => OPEN “home/data” READ at 0 for 32768 <= OPEN OK READ OK (32768 bytes) n

New features of NFS v 4 – Client redirection n Client can be redirected to another server n Build servers in distributed wide Area

New features of NFS v 4 – OPEN delegations n n close-to-open consistency OPEN delegations n Eliminates: the need for the client to periodically check with the server for cache consistency. n when a file is only being referenced by a single client, responsibility for handling most operations (OPEN & CLOSE) is delegated to the client by the server.

Read Delegation n n OPEN, CLOSE and READ requests n Handled locally. All READs n without sending GETATTRs to check cache validity All LOCK requests n sent to the server Callback path is established for recalling a delegation n On a conflicting access to a file such as an OPEN for write, RENAME, and REMOVE. After a delegation has been recalled n the client falls back to traditional attribute checking before reading cached data.

Performance of Read Delegation

Write Delegation n All OPEN, READ, WRITE, CLOSE, LOCK, GETATTR, SETATTR requests n Handled locally On a conflicting OPEN by another client n The server recalls the delegation n Client commits all dirty data and return the delegation. The conflicting OPEN is delayed until the delegation recall is complete.

Performance of Write Delegation

Nache vs Redirection n In federated system n Data on different geographically distributed physical locations Two models for data access n Client redirection n Data shipping Reduce frequent WAN access

Nache Architecture

Performance of Read and Write Delegations

Benefits of Nache

Effect of Proxy on response time over a WAN