Copyright © 2000,2003, Storage Networking Industry Association

321 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
321
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
2
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • The Storage Networking Industry Association (SNIA) hereby grants permission to use this document solely as set forth below, provided that the user complies with and agrees to the terms and conditions set forth below: 1.       The user may reproduce, distribute, or display publicly this document (in its entirety). In any reproduction, distribution, or display, the user must not remove any copyright or other proprietary notices or these terms and conditions from this document. 2.       The user may also incorporate this document, and/or portions of this document, into other documents or works of authorship, including without limitation articles and books. For any such use, the user must include a reasonably prominent copyright notice acknowledging the SNIA’s copyright in any content in this document and a reasonably prominent acknowledgment crediting the SNIA for granting permission for the use of this document. The user must not assert any claims of ownership or proprietary rights, including without limitation seeking copyright registration, of or in any content in this document; and the user must not otherwise seek to limit or restrict others’ ability to use this document subject to these terms and conditions. 3.       In any use of this document whatsoever, the user may not alter, change, or otherwise modify any of the content in this document. However, in using a diagram from this document, the user may make certain limited changes to the diagram: (a) solely as reasonably necessary to show the placement or interaction of a product (including a planned or hypothetical product) with or relative to the components shown in the diagram; (b) that are text annotations superimposed upon a diagram, solely as reasonably necessary to comment on or explain the diagram, the Shared Storage Model, or other related proposals, research, or analysis; or (c) that are simple graphical annotations (such as arrows, circles, or other geometric figures) to show interaction, relations, groupings, or subsets, solely as reasonably necessary to comment on or explain the diagram, the Shared Storage Model, or other related proposals, research, or analysis. 4.       When making any such changes to a diagram permitted under Section 3, above, the user must include a reasonably proximate and prominent notice both of the changes and that any such changes are the sole responsibility of the user (in addition to any notices required by Section 2, above). 5.       Notwithstanding anything to the contrary, the user must not make any change to any diagram that: (a) changes the SNIA Shared Storage Model itself (as described in this document); (b) extends the SNIA Shared Storage Model to cover products or applications for which it was not intended (as described in this document); or (c) misrepresents the SNIA Shared Storage Model (as described in this document) in any way, for example, by omitting significant portions of a diagram. 6.       Furthermore, the user may make no use of this document that might in any way suggest the SNIA endorses, sponsors, or is affiliated with the user or any products, services, or content provided by the user. The user may not use the names “Storage Networking Industry Association” or “SNIA” to endorse or promote any product, service, or content provided by the user incorporating, based on, or otherwise derived from this document, without prior, express, written permission. However, nothing in these terms and conditions precludes a member of the SNIA from noting it is a member of the SNIA. THIS DOCUMENT IS PROVIDED “AS IS,” WITHOUT REPRESENTATION OR WARRANTY OF ANY KIND; AND the SNIA EXPRESSLY DISCLAIMS ANY AND ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING WITHOUT LIMITATION ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE, OR NON-INFRINGEMENT, AND/OR ANY IMPLIED WARRANTY ARISING OUT OF A COURSE OF PERFORMANCE, DEALING, OR TRADE USAGE. UNDER NO CIRCUMSTANCES SHALL THE SNIA, OR ANY OF ITS MEMBERS, OR ANY AUTHOR OF OR CONTRIBUTOR TO THIS DOCUMENT, BE LIABLE TO THE USER FOR DIRECT, INDIRECT, INCIDENTAL, CONSEQUENTIAL, SPECIAL, EXEMPLARY, PUNITIVE, OR OTHER FORM OF DAMAGES (EVEN IF SUCH DAMAGES ARE FORESEEABLE OR THERE HAS BEEN NOTICE OR KNOWLEDGE OF THE POSSIBILITY OF SUCH DAMAGES) ARISING FROM THE USE OF THIS DOCUMENT, REGARDLESS OF WHETHER ANY CLAIM TO SUCH DAMAGES IS BASED IN CONTRACT, WARRANTY, TORT (INCLUDING NEGLIGENCE AND STRICT LIABILITY), PRODUCT LIABILITY, OR OTHER THEORY OF LIABILITY. YOU HEREBY AGREE TO INDEMNIFY, DEFEND, AND HOLD HARMLESS THE SNIA, OR ANY OF ITS MEMBERS, OR ANY AUTHOR OF OR CONTRIBUTOR TO THIS DOCUMENT, FROM ANY AND ALL THIRD-PARTY CLAIMS OR OTHER LIABILITIES, INCLUDING WITHOUT LIMITATION REASONABLE ATTORNEYS’ FEES, COSTS, AND EXPENSES, ARISING OUT OF OR IN ANY WAY RELATED TO YOUR USE OF THIS DOCUMENT. Any person’s or company’s retention and/or use of this document manifests his, her, or its assent to the above terms and conditions and agreement not to make any use of this document except as expressly provided above. All rights not explicitly granted are expressly reserved to the SNIA. Permission to use this document in ways or for purposes not allowed above, or clarifications on permissible changes to diagrams, may be requested by e-mailing snia-td@snia.org; please include the identity of the requesting individual and/or company and a brief description of the purpose, nature, and scope of the requested use.
  • Copyright Storage Networking Industry Association. (See previous page for copyright date.) Authors: John Wilkes (Hewlett-Packard Labs) and Harald Skardal (NetApps), with assistance from the rest of the SNIA Technical Council.
  • The four portions here provide: (Hopefully) motivating material, plus an explanation of the context, and scope of this document and the model itself. The model itself. Samples of applying the model to a number of different existing systems. This is primarily there to help explain how the model is used. A review of the model, plus an upbeat summary.
  • The purpose of this document is to present the SNIA shared storage model. The model describes storage network architectures . An architecture is a functional partitioning of services across the physical and logical resources in storage networks. In use, an architecture is used to develop a design , which includes things like the quantity and size of the resources (and possibly choices of suppliers, versions, etc). The design (eventually) contains enough information to allow construction of a real system that conforms to it. (Note that designs typically evolve over time, both as they change, and as they become filled out from the initial architectural specification.) The model is deliberately simple: the purpose is to make it easy to use, yet rich enough to cover a wide range of storage networks that are being – and could be – deployed. To make this easier, the model is primarily described in a graphical form, and applications of the model are expected to result in pictures. A major intent of the model is to expose, for each storage network architecture that it describes: The services that the architecture provides Interoperability issues between the components used in the architecture. This includes both places where interactions take place between architecture modules (and hence interoperability is required), and what kinds of interoperability occur – and where. At some future date, we may extend the write-up of the model to offer opinions (or collected wisdom, if you prefer) on the relative effectiveness of the storage network architectures covered by the model. Of course, the model doesn’t explicitly cover all possible architectures – especially those that represent combinations of other ones. Instead, the intent is that the user of the model can use it to develop and describe their own particular mix of architectural elements and choices.
  • The benefits from a model of this form is that it can: Provide a common vocabulary that people comparing and designing architectures can use to communicate with one another, and make their outputs more precise. (The analogy here is with the “definitions of terms” that are such a vital part of the IETF and other standards bodies.) Provide a common way of recording network storage architectures, so that these architectures can be compared and contrasted with one another – to identify both similarities and differences. Make it easier for customers to compare different architectures and proposals Make it easier for vendors to explain their offerings to customers. Overall, the hope is that this common “vocabulary” will help to align the storage industry for mutual benefit.
  • The model describes architectures, but it is not an architecture itself. You cannot buy it, or a system that it describes by specifying it in a bid, or a request for a bid. You cannot “build it”. It does not (yet) represent any value judgments between the architectures it describes.
  • All too often, this is the current state of the world. Every vendor, every system designer, and every customer tries to describe what they want – or what they have got – using ad hoc language. There are a great many network storage components, with many slight differences between them. Designs that are actually the same are described in different ways. This results in many problems: it’s often not obvious what is being proposed or described; tradeoffs between alternatives are harder to identify than they could – or should – be; and it’s harder for everybody to make high quality decisions.
  • This is the highest-level picture of the SNIA shared storage model. Note that applications lie outside the scope of the model – they are viewed here as “clients” (in the broadest sense) of the storage domain. There are three main components within the scope (each shows up on the animation): The file/record layer (databases and file systems). The block layer (starting from the low-level storage devices, and extending up to block-based aggregation). Services, including management of the other components. In what follows,each of these will be examined in more detail.
  • The file/record layer: this is the level that packages small things (files and database records) into larger things. The primary responsibility at this layer is that of packing many smaller things into a few larger ones. This typically entails additional value in mechanisms for fine-grain naming and space allocation. The two commonest items here are databases and file systems; as time goes on, we’ll continue to see improvements and specialization at this level. Sometimes, these components are layered – for example, small database systems are often implemented on top of file systems to make them easier to manage. Secondary responsibilities include caching for performance, and providing coherency across cached copies in distributed systems. The upper interfaces to things at this level is typically a byte vector; the lower interface is to a block-store.
  • The primary responsibility of this layer is to provides low-level storage to higher layers. It includes: Storage devices for storing data (disk drives, tape drives, solid-state disks, …) Various forms of block aggregation (a kind of block address-to-block address mapping) in-Storage Network (SN) aggregation, or “virtualization” slicing & dicing, concatenation, striping local & remote mirroring, RAID Some examples of the components at this layer include volume managers, disk array LUs, and storage directors. Secondary responsibilities include caching.
  • The model has the notion of an access path, which routes an application request for data down to the physical storage devices. (Caching,which would shorten a path, is ignored for the moment.) There are eight possible paths (if we restrict ourselves to avoid cycles!). Five of the most common ones are shown here: Direct to the storage device Via a file system Via a database Via a file system that sits on top of a block aggregation function Via a database on top of a file system on top of a block aggregation function
  • The next set of slides talk about the block layer.
  • The functions provided by this layer (“ what can be done”): Space management: constructing a large store by assembling several smaller ones, or packing many small stores into one large one, or both. (This has historically been one of the most important functions of host-based logical volume manager, for example.) Striping: apportioning the load across several lower-level block systems. The typical reason for doing this is to increase throughput by increasing the amount of parallelism available; a valuable secondary benefit may be load balancing, which can also benefit latency. Providing redundancy for increasing availability. This can be full redundancy (e.g., local & remote mirroring, RAID-1, -10, …); or partial redundancy (RAID-3, -4, -5, …). Additional features like point-in-time copy can be provided in this layer. In practice, several of these functions are often combined together.
  • The functions can be done in several different places (“ where it can be done”): Host-side, such as in logical volume managers, device drivers, and HBAs In components of the storage network itself, such as specialized “S[A]N appliances”. In addition, some HBAs are better thought of as part of the storage network. And, very commonly, in the storage devices themselves: disk array controllers (e.g., RAID) are classic examples of this. Most disk controllers provide some level of this functionality too (e.g., logical-to-physical block mappings for supporting sparing).
  • And, finally, how these functions are provided. This is a simple model of how block-based aggregation works. You can visualize the aggregation functions as a set of building blocks that export one or more block-vectors, constructed (“virtualized”) from a set of imported lower-level block-vectors. Because the interfaces to both imported and exported block vectors are the same, these building blocks can usually be stacked quite easily. It’s this that makes it easy to develop the 3-layer model described here; each layer could in theory also be internally constructed this way.
  • This slide shows the first application of the model to a number of different block-based storage architectures. The one with the smallest number of physical components is a host system with some locally-connected disk drives (e.g., ones attached by a local SCSI cable). In the figure, the host is shown running a logical volume manager (LVM) – maybe even including a software RAID function to provide protection against disk failure. The next example introduces a storage network (the pale blue cloud) connecting a host – still running an LVM – to a disk array that is providing a further set of block aggregation functions. And the final example embeds a block-aggregation function into the storage network in an aggregation appliance. A couple of notes on the graphics: The colors used are used consistently throughout the model. The vertical placement is also important: particularly in the block layer.
  • The next set of slides talk about the file/record layer, following a similar format.
  • This is the set of functions that are handled at this layer. Database management systems typically offer mappings (which represent different kinds of packings) of: tuples  tables tables  table-spaces (e.g., in Oracle; other dbms systems have functionally similar mechanisms) table-spaces  volume File systems similarly do mappings from files  volumes. In the future, we may see new types of functionality at this layer. For example, distributed http caches could perhaps be thought of as a new kind of distributed file system.
  • The functions can be done in several different places (“ where it can be done”): Host-side: these are the traditional file systems and databases (the left hand column). The standard client-server “network” file systems, (such as NFS, CIFS, etc.) split the functions between the client and the server – this split happens inside the file system layer in the SNIA shared storage model. Physically, the server side of this split function can reside in: A “file server” – typically a host computer with local attached block storage devices A “NAS head” – a file server with remotely attached block storage devices Inside a storage device
  • This picture puts together most of the previous examples.
  • The SNIA shared storage model is a layered one. Here’s the stack – and a numbering scheme for it.
  • A very important part of the model is the set of services that lie “off to one side” of the critical data path accesses that are the focus of most of this document. The list provided here is not meant to be exhaustive, but to give the flavor of the things that get handled here.
  • These services are typically manifested – and distinguishable from – the critical path by being off it. The list is quite long. It’ll get longer. Many of them are thought of as “management” tasks. Although these services are vital for the successful, these are not further discussed here: this version of the model has focused on the data-access portion alone, in order to get something concrete out for discussion and use. We believe they represent a major opportunity for the SNIA community to contribute clarity to the rather confused world in the services area. Many of the storage-related services need to be tied into larger system-wide service management.
  • This figure just shows that pretty much all of the components in the system can be augmented with a cache. Ideally, all this does is speed things up .. But making this true needs to take account of coherency issues, failure tolerance, and many other issues.
  • Similarly, many components of the model are susceptible to “service aggregation”, or clustering, or inter-box aggregation. The rationales for this includes scalability, failure tolerance, and ease of management. In the context of a file system, this approach is often called a “cluster file system”, or “distributed file system”. Logical volume managers are appearing with similar clustering properties.
  • One of the issues that often arises in discussions about storage models is of the form “what’s the difference between data and storage?” The approach taken here is that the data (content) is the stuff put into storage entities (the containers). A similar distinction can be applied to “information” (the meaning of data) and “data” (the stored bytes). These definitions are recursive: every time there is a mapping, this rule can be applied.
  • We can now discuss the kinds of sharing that commonly occur in storage systems. “Data sharing”, or “logical sharing” typically means that two or more client entities access and interpret the same data. In a distributed system, it requires attention to difficult issues such as coherence and handling data format translation. (Container sharing is essentially indistinguishable from content sharing in this scheme.) It is relatively uncommon. Much more common is the other kind of sharing avoids these issues by sharing the resources that are used to provide containers. For example, physical access paths, disk array controllers, back-end disk drives split up into LUs. Both the content and the containers are disjoint in this approach.
  • As this picture shows, the right answer is that both types of sharing are possible.
  • A few short notes on the importance of interfaces and networks in storage systems. (Even though this is from the Storage Network Industry Association, it’s worth understanding why that network component is so important.) Interfaces come in several forms: three are shown here. a binary programmatic interface, or API; a bus – e.g., the SCSI parallel bus; and an arbitrary network. The important point about these interfaces is that they supply opportunities to replace modules.
  • Module independence: multiple suppliers incremental component upgrades obsolescence protection Networks can add: nearly arbitrary system scale smooth, incremental growth
  • For pure NAS: No interoperability requirement behind the “access method” (FS) layer SN technology is used, but in private/ embedded form Virtualization, Logical Aggregation layers either not implemented, or hidden Everything exposed through FS+ I/f Security service: Corp. user directory All services are internal to the NAS system. Vendor selects and tunes complete solution Overall performance depends upon network performance.
  • Copyright © 2000,2003, Storage Networking Industry Association

    1. 1. Obligatory rubric <ul><li>Copyright © 2000,2003 Storage Networking Industry Association (SNIA). </li></ul><ul><li>SNIA-TC members may use this material freely; all others must conform to usage notes in the speaker noted for this slide. </li></ul><ul><li>See SNIA-SSM-colors.ppt for printing and color/graphics conventions. </li></ul>
    2. 2. SNIA shared-storage model A work in progress … An architectural overview This revision: • 2001-06-05 last content update • 2003-04-13 last graphics update
    3. 3. Contents <ul><li>Purpose </li></ul><ul><li>The SNIA storage model </li></ul><ul><ul><li>Layers, functions, and services </li></ul></ul><ul><ul><li>Networks and interfaces </li></ul></ul><ul><li>Applying the SNIA storage model </li></ul><ul><ul><li>Common storage architectures </li></ul></ul><ul><li>Conclusions </li></ul>
    4. 4. Purpose <ul><li>Present a simple model for shared storage architectures </li></ul><ul><li>Use it to describe common examples graphically </li></ul><ul><li>Expose, for each one: </li></ul><ul><ul><li>What services are provided, where </li></ul></ul><ul><ul><li>Where interoperability is required </li></ul></ul><ul><ul><li>[future] Pros and cons of the architecture </li></ul></ul>
    5. 5. Benefits <ul><li>A common “architecture vocabulary” </li></ul><ul><li>Reference comparisons between common solutions </li></ul><ul><li>Help to align the industry </li></ul><ul><ul><li>Customers can better structure their choices </li></ul></ul><ul><ul><li>Vendors can better explain their differences </li></ul></ul>
    6. 6. What the model is and is not <ul><li>It is not: </li></ul><ul><ul><li>A specification, an architecture, a design, a product, a recommendation, or an installation </li></ul></ul><ul><li>It is: </li></ul><ul><ul><li>A framework that captures the functional layers and properties of a storage system </li></ul></ul>
    7. 7. Classic storage model Application Storage domain: “ anything goes!” Network? Appliance? Data mover? Array? NAS? JBOD?
    8. 8. The SNIA shared storage model File/record layer Block layer Storage devices (disks, …) Storage domain Services Application Database (dbms) File system (FS) Network Host Device Block aggregation
    9. 9. The SNIA storage model: File/record layer File/record layer Database (dbms) File system (FS)
    10. 10. The SNIA storage model: File/record layer — functions <ul><li>Aka “access methods” </li></ul><ul><ul><li>File system, database </li></ul></ul><ul><li>Primary responsibility: packing many smaller things into a few larger ones </li></ul><ul><ul><li>Fine-grain naming, space allocation </li></ul></ul><ul><li>Secondary responsibilities </li></ul><ul><ul><li>Caching for performance </li></ul></ul><ul><ul><li>Coherency in distributed systems </li></ul></ul>
    11. 11. The SNIA storage model: Block layer Block layer Storage devices (disks, …) Block aggregation
    12. 12. The SNIA storage model: Block layer — functions <ul><li>Storage devices – storing data </li></ul><ul><ul><li>disk drives, tape drives, solid-state disks, … </li></ul></ul><ul><li>Block aggregation – address mapping </li></ul><ul><ul><li>in-SN aggregation, or “virtualization” </li></ul></ul><ul><ul><li>slicing & concatenation, striping </li></ul></ul><ul><ul><li>local & remote mirroring, RAID-n </li></ul></ul><ul><li>Examples </li></ul><ul><ul><li>volume managers </li></ul></ul><ul><ul><li>disk array LUs </li></ul></ul><ul><li>Secondary responsibilities </li></ul><ul><ul><li>caching </li></ul></ul>
    13. 13. The SNIA storage model: Access path examples File/record layer Block layer Storage devices (disks, …) Block aggregation Application Database (dbms) File system (FS) Note: all 8 possible paths can be used!
    14. 14. Block layer <ul><li>Block-mapping functions: what can be done </li></ul><ul><li>Functional decomposition: where it can be done </li></ul><ul><li>Sample architectures </li></ul>Block layer Storage devices (disks, …) Block aggregation
    15. 15. Block layer What can be done <ul><li>Space management </li></ul><ul><ul><li>making a large store from many small ones </li></ul></ul><ul><ul><li>packing many small stores into one large one </li></ul></ul><ul><li>Striping </li></ul><ul><ul><li>for performance (load balancing, throughput) </li></ul></ul><ul><li>Redundancy </li></ul><ul><ul><li>full (local & remote mirroring, RAID-1, -10, …) </li></ul></ul><ul><ul><li>partial (RAID-3, -4, -5, …) </li></ul></ul><ul><ul><li>point-in-time copy </li></ul></ul>
    16. 16. Block layer Where it can be done <ul><li>Host-side </li></ul><ul><ul><li>logical volume managers </li></ul></ul><ul><ul><li>device drivers, HBAs </li></ul></ul><ul><li>SN-based </li></ul><ul><ul><li>HBAs, specialized SN appliances </li></ul></ul><ul><li>Device-based </li></ul><ul><ul><li>array controllers (e.g., RAID) </li></ul></ul><ul><ul><li>disk controllers (e.g., sparing) </li></ul></ul>Storage devices Block aggregation Network Host Device
    17. 17. Block layer How it is done <ul><li>Building blocks </li></ul><ul><ul><li>input: vector of blocks </li></ul></ul><ul><ul><li>output: vector of blocks </li></ul></ul><ul><li>Result: building blocks can be stacked </li></ul><ul><ul><li>enables the 3 layer model for the block layer </li></ul></ul><ul><ul><li>layers can be nested on one another </li></ul></ul><ul><ul><li>could be extended to more layers </li></ul></ul>… … Block aggregation …
    18. 18. Block layer Sample architectures Application File/record layer Block layer Device block-aggregation Network block-aggregation Host block-aggregation Host. with LVM (+ software RAID?) 1. Direct-attach Disk array SN Host with LVM 2. SN-attach 3. SN aggregation Aggregation appliance Host, no LVM Storage devices
    19. 19. File/record layer <ul><li>Byte-mapping functions: what can be done </li></ul><ul><li>Functional decomposition: where it can be done </li></ul><ul><li>Sample architectures </li></ul>File/record layer Database (dbms) File system (fs)
    20. 20. File/record layer What can be done <ul><li>Database management systems </li></ul><ul><ul><li>tuples  tables </li></ul></ul><ul><ul><li>tables  table-spaces </li></ul></ul><ul><ul><li>table-spaces  volume </li></ul></ul><ul><li>File systems </li></ul><ul><ul><li>files  volume </li></ul></ul><ul><li>New types </li></ul><ul><ul><li>http caches: a kind of distributed file system? </li></ul></ul>
    21. 21. File/record layer Where it can be done <ul><li>Host-side </li></ul><ul><ul><li>file systems and databases </li></ul></ul><ul><ul><li>NFS, CIFS, etc. are client-server splits inside the file system </li></ul></ul><ul><li>SN-based </li></ul><ul><ul><li>NAS head </li></ul></ul><ul><li>Device-based </li></ul><ul><ul><li>NAS functions in array box </li></ul></ul>device NAS Host with NFS/CIFS client Host with local FS/dbms
    22. 22. File/record layer Host. with LVM and software RAID 1. Direct-attach File/record layer Block layer Host. with LVM Disk array 2. SN-attach Application SN Device block-aggregation Network block-aggregation Host block-aggregation NAS server 4. NAS server Host 3. NAS head NAS head Host LAN
    23. 23. The SNIA storage model A layered view <ul><li>IV. Application </li></ul><ul><li>III. File/record layer </li></ul><ul><ul><li>IIIa. Database </li></ul></ul><ul><ul><li>IIIb. File system </li></ul></ul><ul><li>II. Block aggregation </li></ul><ul><ul><li>IIa. Host </li></ul></ul><ul><ul><li>IIb. Network </li></ul></ul><ul><ul><li>IIc. Device </li></ul></ul><ul><li>I. Storage devices </li></ul>File/record layer Database (dbms) File system (fs) Storage devices Block aggregation Application Network Host Device IV III IIc IIb IIa I
    24. 24. The SNIA storage model Services subsystem Storage domain File/record layer Block layer Application Storage devices (disks, …) Block aggregation Services Discovery, monitoring Resource mgmt, configuration Security, billing Redundancy mgmt (backup, …) High availability (fail-over, …) Capacity planning Database (dbms) File system (fs)
    25. 25. Services <ul><li>Operations off the critical path </li></ul><ul><ul><li>naming, discovery, monitoring, configuration, security, billing, redundancy management (backup, …), high availability management (fail-over, …), capacity planning, … </li></ul></ul><ul><ul><li>strong ties into system-wide management services </li></ul></ul><ul><li>Vital for successful operation </li></ul><ul><ul><li>and a major opportunity for SNIA … </li></ul></ul><ul><ul><li>… but not discussed further in this presentation </li></ul></ul>
    26. 26. Caching … can be added to almost any layer Host. with LVM and software RAID File/record layer Block layer Host NAS head Host Host. with LVM NAS head LAN Ideally, caching only affects performance. But: coherency implications do affect management (protocols, interfaces) Application Device block-aggregation Network block-aggregation Host block-aggregation Disk array SN Cache Cache Cache Cache Cache appliance Cache
    27. 27. Clustering Inter-box aggregation Host. with LVM and software RAID File/record layer Block layer Host NAS head Host Host. with LVM Disk array SN NAS head LAN Cluster FS Multi-node LVM <ul><li>Purposes: </li></ul><ul><li>load spreading across peers (scalability) </li></ul><ul><li>alternate paths (high availability, scalability) </li></ul>Application Device block-aggregation Network block-aggregation Host block-aggregation
    28. 28. Q: Data versus storage? A: Putting information into containers <ul><ul><li>user: data (“learning my preferences”) application: container (“user keystroke history”) </li></ul></ul><ul><ul><li>application: data (“user keystroke history file”) file system: container (“byte vector”) </li></ul></ul><ul><ul><li>file system: data (“a named file”) volume system: container (“blocks in volume”) </li></ul></ul><ul><ul><li>volume system: data (“replicated, striped layout”) disk array: container (“blocks in LU”) </li></ul></ul>
    29. 29. Sharing Content sharing or resource sharing? <ul><li>Content sharing (“logical”, “data”) </li></ul><ul><ul><li>contents accessed and understood by multiple clients </li></ul></ul><ul><ul><ul><li>e.g., file system, Oracle Parallel Server dbms </li></ul></ul></ul><ul><ul><li>some of the hard issues: </li></ul></ul><ul><ul><ul><li>coherency </li></ul></ul></ul><ul><ul><ul><li>heterogeneous data formats </li></ul></ul></ul><ul><li>Resource sharing (“container”, “physical”) </li></ul><ul><ul><li>e.g., disk array where hosts access disjoint LUs </li></ul></ul>
    30. 30. Sharing Content sharing and resource sharing Host with LVM File/record layer Block layer Host with LVM SN NAS system Host Host LAN Application Resource sharing Array is shared, but LUs are disjoint Data sharing NAS system is shared – and so are the files Device block-aggregation Network block-aggregation Host block-aggregation
    31. 31. Networks and interfaces are pervasive in the model Storage device Block layer File layer Operating System Application Network or interface Full benefits come only from common, open interfaces Network Bus API
    32. 32. Networks and interfaces Composition and scaling Network or interface Network or interface Network or interface Network or interface Open interfaces allow: 1. vertical composition 2. horizontal scaling 3. supplier independence Network Bus API API Network Bus API
    33. 33. Networks and interfaces Open interfaces require … <ul><li>Well defined: </li></ul><ul><ul><li>functions (what they do) </li></ul></ul><ul><ul><li>interface protocols (data formats) </li></ul></ul><ul><ul><li>access protocols (system call, RPC, flow control, …) </li></ul></ul><ul><li>That are: </li></ul><ul><ul><li>published </li></ul></ul><ul><ul><li>supported by multiple products </li></ul></ul><ul><ul><li>=> standards (which is where SNIA comes in) </li></ul></ul>Network Bus API
    34. 34. Q: “SAN” versus “NAS”? A: a poorly-formed question <ul><li>Q: hardware : FibreChannel vs Ethernet vs InfiniBand? </li></ul><ul><li>Q: API : blocks vs files (aka “NAS”) vs objects (OSD)? </li></ul><ul><li>Q: protocol : FCP vs TCP/IP vs … ? </li></ul><ul><li>A: (to all the above) it depends … </li></ul><ul><li>Storage network ( SN ): </li></ul><ul><ul><li>any (mostly) dedicated network, installed (mostly) for storage traffic </li></ul></ul><ul><ul><li>whatever the hardware, API, or protocol </li></ul></ul>? NAS “ SAN” FC E’net iSCSI Files Blocks FC E’net Files Blocks FS/block combo
    35. 35. Some common storage architectures Mapping the SNIA model onto some current implementations
    36. 36. Direct-attach block storage Host, no LVM File/record layer Block layer Host. with LVM and software RAID Host with LVM Application <ul><li>Direct-attach </li></ul><ul><li>Multi-attach box </li></ul><ul><li>E.g., SCSI </li></ul>Device block-aggregation Network block-aggregation Host block-aggregation Disk array
    37. 37. SN-attached block storage Disk array Host, no LVM File/record layer Block layer SN “ SN” = any network used for storage access. E.g., Fibre Channel, Ethernet, … Host with LVM Application Device block-aggregation Network block-aggregation Host block-aggregation
    38. 38. SN-attached block storage with metadata server Disk array Host with LVM File/record layer Block layer SN Block-aggregation metadata server Host, no LVM Aggregation map (metadata) is supplied by an external server Application Device block-aggregation Network block-aggregation Host block-aggregation
    39. 39. Block storage aggregation in a storage network appliance Disk array File/record layer Block layer Aggregation appliance Host with LVM Host, no LVM Application aka “SN virtualization” Functions: LVM, caching Device block-aggregation Network block-aggregation Host block-aggregation SN
    40. 40. Multi-site block storage Disk array Aggregation appliance Host. with LVM Application Host. with LVM Application Functions: point-in-time copy, caching, local & remote mirroring, … File/record layer Block layer Device block-aggregation Network block-aggregation Host block-aggregation SN Disk array Aggregation appliance SN appliance WAN WAN Host-to-host WAN Device-to-device
    41. 41. File server NAS system Host Host File/record layer Block layer LAN-attached “NAS” system May do SN/block aggregation, etc. inside in the NAS system box Application LAN Device block-aggregation Network block-aggregation Host block-aggregation private SN?
    42. 42. File server controller (“NAS head”) NAS head File/record layer Block layer No storage in the file server controller box Host Host LAN Application Device block-aggregation Network block-aggregation Host block-aggregation Disk array SN
    43. 43. NAS/file server metadata manager (“asymmetric”) Disk array File/record layer Block layer Hosts get file meta- data from FS/NAS controller, then access the data directly Host. with LVM File metadata Block accesses Application File system metadata Device block-aggregation Network block-aggregation Host block-aggregation FS controller can also be NAS server Host LAN SN
    44. 44. Object-based Storage Device (OSD), CMU NASD OSD device File/record layer Block layer Object metadata Application LAN Security metadata File metadata Device block-aggregation Network block-aggregation Host block-aggregation Host Host
    45. 45. Summary & conclusions
    46. 46. The SNIA shared storage model File/record layer Storage domain Block layer Storage devices (disks, …) Application Database (dbms) File system (FS) Services Discovery, monitoring Resource mgmt, configuration Security, billing Redundancy mgmt (backup, …) High availability (fail-over, …) Capacity planning Network Host Device Block aggregation
    47. 47. Block layer Sample architectures File/record layer Block layer Application Device block-aggregation Network block-aggregation Host block-aggregation Host. with LVM and software RAID 1. Direct-attach SN Host. with LVM Disk array 2. SN-attach 3. SN aggregation Aggregation appliance Host, no LVM
    48. 48. File/record layer Sample architectures 1. Direct-attach File/record layer Block layer Host 3. NAS head NAS head Host LAN 2. SN-attach Application Device block-aggregation Network block-aggregation Host block-aggregation Host. with LVM and software RAID NAS server 4. NAS server Host. with LVM Disk array SN
    49. 49. Uses for the model <ul><li>Vendors </li></ul><ul><ul><li>place products in the space of architectures </li></ul></ul><ul><ul><li>clarify product differences </li></ul></ul><ul><li>Customers </li></ul><ul><ul><li>understand vendor offerings better </li></ul></ul><ul><li>The industry </li></ul><ul><ul><li>basis for common definitions, communication, understanding, interoperability </li></ul></ul>
    50. 50. Conclusions <ul><li>The SNIA shared storage model is both simple and useful </li></ul><ul><ul><li>to highlight similarities and differences </li></ul></ul><ul><ul><li>as a basis for comparisons </li></ul></ul><ul><li>Still a work in progress </li></ul><ul><ul><li>data movers, tape drives, … </li></ul></ul><ul><ul><li>better comparisons … </li></ul></ul><ul><ul><li>suggestions? </li></ul></ul><ul><li>The SNIA-TC welcomes input: </li></ul><ul><ul><li><snia-tc@snia.org> </li></ul></ul>
    51. 51. Authors <ul><li>John Wilkes, Hewlett-Packard (project lead) </li></ul><ul><li>Harald Skardal, NetApps </li></ul><ul><li>David Black, EMC </li></ul><ul><li>Wayne Rickard (SNIA TC chairperson), Gadzoox </li></ul><ul><li>Co-conspirators: the rest of the SNIA Technical Council </li></ul><ul><ul><li>Dave Anderson, Seagate Technology </li></ul></ul><ul><ul><li>Jim Carlson, IBM </li></ul></ul><ul><ul><li>Garth Gibson, CMU/Panasas </li></ul></ul><ul><ul><li>Kevin Phaup, HighGround Systems </li></ul></ul><ul><ul><li>David Thiel, Compaq </li></ul></ul>

    ×