by M. Eshel et al., FAST 2010.
Abstract:
Cloud computing promises large-scale and seamless ac- cess to vast quantities of data across the globe. Appli- cations will demand the reliability, consistency, and per- formance of a traditional cluster file system regardless of the physical distance between data centers.
Panache is a scalable, high-performance, clustered file system cache for parallel data-intensive applications that require wide area file access. Panache is the first file system cache to exploit parallelism in every aspect of its design—parallel applications can access and update the cache from multiple nodes while data and metadata is pulled into and pushed out of the cache in parallel. Data is cached and updated using pNFS, which performs parallel I/O between clients and servers, eliminating the single-server bottleneck of vanilla client-server file ac- cess protocols. Furthermore, Panache shields applica- tions from fluctuating WAN latencies and outages and is easy to deploy as it relies on open standards for high- performance file serving and does not require any propri- etary hardware or software to be installed at the remote cluster.
In this paper, we present the overall design and imple- mentation of Panache and evaluate its key features with multiple workloads across local and wide area networks.
Link to the full paper:
http://www.cse.buffalo.edu/faculty/tkosar/cse710_spring13/papers/panache.pdf
Cloud computing promises large-scale and seamless ac- cess to vast quantities of data across the globe. Appli- cations will demand the reliability, consistency, and per- formance of a traditional cluster file system regardless of the physical distance between data centers.
Panache is a scalable, high-performance, clustered file system cache for parallel data-intensive applications that require wide area file access. Panache is the first file system cache to exploit parallelism in every aspect of its design—parallel applications can access and update the cache from multiple nodes while data and metadata is pulled into and pushed out of the cache in parallel. Data is cached and updated using pNFS, which performs parallel I/O between clients and servers, eliminating the single-server bottleneck of vanilla client-server file ac- cess protocols. Furthermore, Panache shields applica- tions from fluctuating WAN latencies and outages and is easy to deploy as it relies on open standards for high- performance file serving and does not require any propri- etary hardware or software to be installed at the remote cluster.
In this paper, we present the overall design and imple- mentation of Panache and evaluate its key features with multiple workloads across local and wide area networks.
Link to the full paper:
http://www.cse.buffalo.edu/faculty/tkosar/cse710_spring13/papers/panache.pdf
The gateway node doesn't update the remote cluster immediately after it performs the write operation at the remote cluster upon receiving a message from application node. Isn't there a possibility of a conflict?
ReplyDeletePanache specifically utilizes asynchronous date writeback strategy to allow the data and metadata updates at local speeds and also masks remote cluster failures and network outages. The paper says one such optimization is for grouping all the write requests to match the optimal GPFS and NFS buffer sizes. Besides, before execution the queued requests are evaluated to eliminate temporary data updates.
DeleteHow the cache is updated? The File Handle and inode remains same for the file, so how Panache handles the outdated file handles in the cache, for the files that are deleted?
ReplyDeleteI think the Panache will update the metadata information of the deleted file with the remote cluster. The file will be empty in the local cache cluster. Next time upon the data read request, the application node will send request to the gateway node for data fetching.
DeletePanache scales I/O performance by using multiple gateway nodes to read chunks of a single file in parallel from the multiple nodes over NFS/pNFS.
ReplyDeleteHow to assure the order of the chunks?
If the chunks have been changed during the transmission, how to detect and how to deal with it
The paper says one of the gateway nodes will become the coordinator for the file to be read during parallel reading. I suppose this coordinator node should keep the information of all other gateway nodes that read chunks of the same file, i.e., the size of the file chunk, the offset, etc. It should be responsible to maintain the file consistency after parallel reading by multiple gateway nodes.
ReplyDeleteNot sure about the change during the file transmission. But the inode in the cache cluster stores the local modification time. If the file is accessed after the revalidation timeout expires, gateway node will get the remote file's attributes and compare them with the stored values.