260 likes | 271 Views
Flexibility, Manageability and Performance in a Grid Storage Appliance. John Bent, Venkateshwaran Venkataramani, Nick Leroy, Alain Roy, Joseph Stanley, Andrea Arpaci-Dusseau, Remzi Arpaci-Dusseau, and Miron Livny University of Wisconsin. Two trends. D a t a s e t s P e r f o rm a n c e.
E N D
Flexibility, Manageability and Performance in a Grid Storage Appliance John Bent, Venkateshwaran Venkataramani, Nick Leroy, Alain Roy, Joseph Stanley, Andrea Arpaci-Dusseau, Remzi Arpaci-Dusseau, and Miron Livny University of Wisconsin
Two trends • Datasets • Performance • Storage appliances address both trends.
Storage Appliances: + and - • Storage Appliances: Great for basic file service • Easy to manage: Plug in and it works • Good performance: Specialized just for I/O • Reliable and available too • Storage Appliances for the Grid: Mismatch? • Inflexible: Few, specific protocols (e.g., NFS) • Costly: 10x the cost of PC + a few disks • Difficult to integrate: Just one piece of the puzzle
A Solution: NeST • NeST: A Storage Appliance for the Grid • Flexible: Multiple simultaneous protocols • Virtual protocol layer • Low-cost: Use commodity machines • Dynamic adaptation • Grid-aware: Integrate w/ higher-level systems • Design specifically for the Grid
Outline • Introduction • General architecture • Design goals • Flexibility • Low-cost • Grid-aware features • NeST in the Grid example • Conclusions
Chirp HTTP Grid FTP NFS Common protocol layer Control flow Datal flow Concurrency Models NeST: Protocol layer • Virtualizes different protocols • Mediates access to network Physical network layer Dispatcher Storage Mgr Transfer Mgr Physical storage layer
Chirp HTTP Grid FTP NFS Common protocol layer Control flow Datal flow Concurrency Models NeST: Dispatcher • Mediates interaction between other components • Gathers information, advertises Physical network layer Dispatcher Storage Mgr Transfer Mgr Physical storage layer
Chirp HTTP Grid FTP NFS Common protocol layer Control flow Datal flow Concurrency Models NeST: Storage manager • Space management • Access control • Virtualizes physical storage Physical network layer Dispatcher Storage Mgr Transfer Mgr Physical storage layer
Chirp HTTP Grid FTP NFS Common protocol layer Control flow Datal flow Concurrency Models NeST: Transfer manager • Implementsscheduling policies • Chooses concurrency model Physical network layer Dispatcher Storage Mgr Transfer Mgr Physical storage layer
Outline • Introduction • General architecture • Design goals • Flexibility • Low-cost • Grid-aware features • NeST in the Grid example • Conclusions
Flexibility: Multiple protocols • Problem: How to support multiple protocols? • One approach: Just a Bunch of Servers (JBOS) • Problems with JBOS • Lack of control (scheduling) • Painful administration • No shared code • Larger memory footprint wu-ftpd nfsd httpd JBOS Server
NeST: Flexibility By Design • NeST: Integrate protocols and gain advantage • Implementation like VFS • Integration introduces new challenges • Different protocols allow different auth models • More expensive to add a new protocol • Less fault isolation
NeST vs JBOS Linux cluster - Dual PIII - 1 GB Ram - linux 2.2.19 Each protocol - 4 clients - 10 MB files 35 35 30 30 25 25 20 20 Server bandwidth (MB/s) 15 15 10 10 linux nfsd Apache wu-ftpd 5 5 0 0 NFS HTTP Total Chirp GridFTP • For each protocol, NeST is comparable to JBOS server.
Exerting scheduling control • Different scheduling policies • FCFS • Cache-aware [USENIX ‘02] • Proportional share • Proportional share scheduling • Allows administrators to set protocol proportions • e.g. favor NFS • Very difficult in JBOS
Proportional share 35 30 25 Linux cluster - Dual PIII - 1 GB Ram - linux 2.2.19 Each protocol - 4 clients - 10 MB files 20 Server bandwidth (MB/s) 15 10 5 0 FCFS 1:1:1:1 1:2:1:1 1:1:1:4 Scheduling configuration • In most cases, achieves Jain’s metric of fairness > 0.98 (1 is “fair”).
Outline • Introduction • General architecture • Design goals • Flexibility • Low-cost • Grid-aware features • NeST in the Grid example • Conclusions
Low-Cost: New challenges • Desire: Run on arbitrary OS on arbitrary PC • Software-only, user-level storage appliance • Currently on Linux (release 0.9) and Solaris (beta) • Problem: Portable performance • Performance under load is platform / workload dependent • Threads or processes on some systems, events on others • May also be workload dependent (e.g. whether in cache) • NeST approach: Dynamic adaptivity • Simultaneously support multiple concurrency models • Monitor performance using each model • Bias towards better model over time
Adaptive Adaptive • Dynamic adaptation approaches “ideal” without static information. Adaptive Concurrency Linux: 10 MB files Solaris: 1K files 1.5 3 1 2 Ave time per request (ms) Ave time per request (sec) 0.5 1 0 0 Events Events Threads Threads
Outline • Introduction • General architecture • Design goals • Flexibility • Low-cost • Grid-aware features • NeST in the Grid example • Conclusions
Grid-Aware Mechanisms • Basic functionality • Users and groups: Dynamic creation/deletion • does not need administrative intervention • Access control: Generic AFS-style ACLs • Advanced functionality • QoS: Preferential scheduling • Advertises into global scheduling systems • Flexible protocol and authentication mechanisms • Self-cleaning storage guarantees: Lots
Storage guarantees: Lots • Characteristics of Lots: • Capacity: Total amount of data lot can store • Duration: Time for which data is guaranteed to exist • Set of files: Multiple files may co-exist within lot • Self-cleaning • Expired lots become “best-effort” lots • Lot management • Either default set created by administrator, ORuse resource management protocol to create before usage • Implementation: File system quotas • Advantage: Integrates cleanly with local access methods • Disadvantage: Performance hit for large writes
Outline • Introduction • General architecture • Design goals • Flexibility • Low-cost • Grid-aware features • NeST in the Grid example • Conclusions
Advertisement Condor Tribune NeST in the Grid Global Execution Manager Linux NeST Solaris NeST compute node compute node compute node compute node Home Remote
Global Execution Mgr 1) Home submits jobs 2) Global reserves space 3) Global coordinates xfer 6) 1) 2) 3) 4) Global starts jobs N N GridFTP 5) Global coordinates xfer 5) NFS 4) 6) Global terminates space Home Remote NeST in the Grid
Conclusions • NeST: A storage appliance for the Grid • Gain manageability • Without sacrificing performance • Design goals: • Flexibility: Virtual protocol architecture • Low-cost: Adaptation mechanisms • Grid-aware: Space management • Current status: release 0.9 available • Future work • Hot deployable NeSTs, lot management extensions
Questions? http://www.cs.wisc.edu/condor/nest