| This is the highest-level picture of the SNIA Shared Storage Model. It has three main components within its scope: The file/record layer, which includes databases and file systems. The block layer, which includes both low-level storage devices and block-based aggregation. A services subsystem, which provides functions such as the management of the other components. Note that applications lie outside the scope of the model they are viewed as "clients" of the storage domain, in the broadest sense. Storage system components The SNIA Shared Storage Model supports the following kinds of components: Interconnection network the network infrastructure that connects the elements of the shared storage environment. This network may be a network that is primarily used for storage access, or one that is also shared with other uses. The important requirement is that it provides an appropriately rich, high-performance, scalable connectivity upon which a shared storage environment can be based.
Figure E-2. 
The physical-layer network technologies that are used (or have been used) for this function include Fibre Channel, Fast-and Gigabit-Ethernet, Myrinet, the VAX CI network, and ServerNet. Network protocols that are used at higher layers of the protocol stack also cover a wide range, including SCSI FCP, TCP/IP, VI, CIFS, and NFS. Redundancy in the storage network allows communication to continue despite the failure of various components; different forms of redundancy protect against different sorts of failures. Redundant connections within an interconnect may enable it to continue to provide service by directing traffic around a failed component. Redundant connections to hosts and/or storage enable the use of multi-path I/O to tolerate interface and connection failures; multi-path I/O imple mentations may also provide load balancing among alternate paths to storage. An important topology for multi-path I/O uses two completely separate networks to ensure that any failure in one network cannot directly affect the other. Host computer a computer system that has some or all of its storage needs supplied by the shared storage environment. In the past, such hosts were often viewed as external to the shared storage environment, but we take the opposite view, and will show examples of function mappings that place key components in such hosts. A host typically attaches to a storage network with a host bus adapter (HBA) or network interface card (NIC). These are typically supported by associated drivers and related software; both hard ware and software may be considered part of the shared storage environment. The hosts attached to a shared storage environment may be largely unaware of each other, or they may explicitly cooperate in order to exploit shared storage environment resources. Most commonly this occurs across subsets of the hosts ("clusters"). One of the advantages of separating hosts from their storage devices in a shared storage world is that the hosts may be of arbitrary and differing hardware architecture and run different versions and types of operating system software. Physical storage resource a non-host element that is part of the shared storage environment, and attached to the storage network. Examples include disk drives, disk arrays, storage con trollers, array controllers, tape drives and tape libraries, and a wide range of storage appliances. (Hosts are not physical storage resources.) Physical storage resources often have a high degree of redundancy, including multiple network connections, replicated functions, and data redundancy via RAID and other techniques all to provide a highly available service. Storage device a special kind of physical-storage resource that persistently retains data. Logical storage resource a service or abstraction made available to the shared storage environment by physical storage resources, storage management applications, or combination thereof. Examples include volumes, files, and data movers. Storage management functions that observe, control, report, or implement logical storage resources. Typically these functions are implemented by software that executes in a physical storage resource or host. The layering scheme of the SNIA Shared Storage Model The SNIA Shared Storage Model is a layered one. The figure shows a picture of the stack with a numbering scheme for the layers. Roman numerals are used to avoid confusion with the ISO and IETF networking stack numbers. The layers are as follows:
Figure E-3. 
We will now describe each of these layers, from the topmost layer downwards. The file/record layer This layer packs small things such as files (byte vectors) and database tuples (records) into larger entities such as block-level volumes and storage device logical units. The two commonest implementations seen at this level are database management systems and file systems. Both provide mechanisms for naming or indexing files or records, enforcing access controls, performing space allocation and clustering, and caching data for rapid access. In both cases, the file/record layer sits on top of one or more volumes: large block vector stores or byte vectors provided by an underlying block store or (sometimes) file system. That is, database management systems typically offer mappings (or packings) of: tuples or records  tables volumes Sometimes additional intermediate mapping layers are introduced, such as a grouping of tables together into a "table space" that sits atop one or more external volumes. This is usually done to make it easier to manipulate such mappings from inside the database management system in an environment-independent fashion.
Figure E-4. 
File systems typically do mappings from: bytes files volumes Because a byte vector can be used to emulate a block vector, the volumes that a database is mapped to can sometimes be files. This is most often done for small database systems where the performance penalties of the two levels of mapping it entails are outweighed by the simpler management that results from exploiting the naming and access control mechanisms offered by the file system. Secondary functionality provided by this layer may include content indexing, aggressive prefetching and write-behind techniques to improve performance, hierarchy management, and providing coherency across multiple copies in distributed systems. In the future, we expect to see new implementations at this layer, such as file systems explicitly designed for replaying isochronous streams against multimedia objects (e.g., videos). Indeed, an http web cache might be considered a new kind of distributed file system. |
