| The functions provided by the file/record layer can be implemented in several different places: Solely in the host: these are the traditional host-based file systems and databases (the left-hand column in the figure shown here). In such systems, the implementation of the file system or database resides completely in the host, and the interface to the storage device is at the block-vector level. In both client and server: these are the standard "network" file systems such as NFS, CIFS, etc. (The right-hand column of the figure.) Such implementations split their functions between the client (host) and the server system. (Note that this split happens inside the file system layer in the SNIA Shared Storage Model.) The client side always resides in a host computer. The server side, however, can reside in a: file server (sometimes database server) typically a host computer with local attached block storage devices that may be dedicated to this function.
Figure E-5. 
NAS head a dedicated-function computer acting as a file server and relying on external block storage devices connected through a storage network. storage device such as a disk array or "smart disk." The block layer The block layer provides low-level storage to higher layers, typically with an access interface that supports one or more linear vectors of fixed-size blocks. In SCSI, these logical address spaces are called logical units (LUs); a single SCSI storage device may support several such logical units. Ultimately, data is stored on "native" storage devices such as disk drives, solid-state disks, and tape drives. These devices can be used directly, or the storage they provide can be aggregated into one or more block vectors to increase or decrease their size, or provide redundancy. This aggregation can occur in many places more on this below.
Figure E-6. 
Secondary responsibilities of the block layer include a simple form of naming, such as SCSI logical unit names (LUNs), caching (and, in particular, non-volatile caches for write-behind data), and (increasingly) simple access control. Block aggregation Block aggregation comprises a powerful set of techniques that are used to serve many purposes. These include: Space management: constructing a large block vector by assem bling several smaller ones, or packing many small block vectors into one large one, or both. (This "slicing and dicing" has historically been one of the most important functions of host-based logical volume managers.) Striping: apportioning load across several lower-level block vectors and the systems that provide them. The typical reason for doing this is to increase throughput by increasing the amount of parallelism available; a valuable secondary benefit may be the reduction in average latency that can result as a side effect. Providing redundancy for increasing availability in the face of storage device failures. This can be full redundancy (e.g., local and remote mirroring, RAID-1, -10…); or partial redundancy (RAID-3, -4, -5,…). Additional features like point-in-time copy (various versions of this are sometimes called "snapshot") can be provided, which can be used to increase the effective redundancy level of a system, and to help recover from other kinds of failures. In practice, several of these functions are often combined together. For example, a system that can handle striping is often also capable of performing mirroring (a combination sometimes referred to as RAID-10). The block aggregation functions can be performed at several of the storage components described in the model. Indeed, it is common to find more than one being used. Host-side, such as in logical volume managers, device drivers, and host bus adapters (HBAs). In components of the storage network itself, such as specialized "SN 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. Modern disk drive controllers provide some level of this functionality too, such as a logical-to-physical block mapping for supporting sparing. How is it done? The figure shown here offers a simple, visual model of how block aggregation operates. It also illustrates the reason that block-based aggregation functions at different components can be composed together.
Figure E-7. 
You can think of each kind of aggregation function as a building block that imports (uses) one or more block vectors from "below," and exports to its clients one or more block vectors at its upper interface that are constructed (i.e., "aggregated" or "virtualized") from those imported ones. The construction can embody any or all of the functions described above. Because the interfaces to both imported and exported block vectors are the same, these building blocks can often be stacked on top of one another: for example, mirroring across two disk arrays could be performed in a host logical volume manager, and RAID 5 redundancy applied within each of the disk arrays. Each layer could in theory also be internally constructed in this same way. Sample architectures This illustration shows the first application of the model to a number of different block-based storage architectures.
Figure E-8. 
direct-attach: the leftmost column illustrates this. A host is connected to some private, non-shared storage devices (e.g., disk drives attached by a local SCSI cable). In the figure, the host is shown running a logical volume manager (LVM) perhaps capable of providing a software RAID function to provide protection against disk failure. storage-network attach: the second and third hosts, plus the storage network and disk array in the second column, illustrate this. This scheme introduces a storage network (the pale blue cloud) connecting one or more hosts perhaps still running LVM software to a disk array that is providing a further set of block aggregation functions. The disk array resources can now be shared between multiple hosts. storage-network aggregation: the final example embeds a block-aggregation function into the storage network in an aggregation appliance that might be providing access control and (say) striping aggregation functions. Putting it all together combining the block and file/record layers This picture puts together both block-based and file-based storage architectures.
Figure E-9. 
direct-attach: the leftmost column shows local, private storage directly connected to a single host. storage-network attach: the second column shows a representative host connected to a (shared) disk array through a storage network (SN). NAS head: the third column illustrates a dedicated-function "NAS head" (file server controller) interposed between the lower-level, block-based storage network and its clients, which are connected to it through a second network (generically an arbitrary second storage network, but shown here as a LAN, as that is the most common form), and operate using client/server file system protocols. Note that block-aggregation functions can be used to support several NAS heads, as well as regular block-level hosts. NAS server: this is shown in the right-most (fourth) column and logically consists of a combined NAS head and its own local, private storage. Access paths An access path is the list of components (hardware and software) that are traversed by read and write requests to the storage system and their responses. If we restrict ourselves to avoid cycles, there are eight possible paths from the application layer to the lowest storage layer through the elements of the SNIA Shared Storage Model.
Figure E-10. 
Five examples of common paths are shown in the figure here, reading from right to left: direct to the storage device (e.g., disk drive or disk array) via a file system 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 via a database Caching Caching is designed to shorten access paths for frequently referenced items, and so improve the performance of the overall storage system. Most elements of a storage system can provide a cache, and so such caches can be performed at the block or file/record layer or both. Indeed, it is common to see several caches in operation simultaneously. For example: a read cache in a file system, coupled with a write-back cache in a disk array, and a read-ahead cache in a disk drive.
Figure E-11. 
The figure here illustrates this: almost any of the components in the system can be augmented with a cache. The figure also introduces a new component: a dedicated caching appliance, added to the storage network solely to provide caching functions. Ideally, all that adding caching does is speed things up, but making this true for shared storage networks requires taking account of a multitude of detailed issues that occur in distributed systems, such as maintaining the coherency of multiple copies of data or metadata (data about data), and tolerating partial failures of the system. In particular, cache management (deciding which cache should or does hold what) is significantly more complicated when data may be cached in several places. Access control A shared storage environment bestows the benefit of hosts being able to access their storage devices directly. But the existence of an access path should not be taken as equivalent to permission to exercise it. Access control is the set of techniques that enforce the decisions that encapsulate these permissions. There are many different kinds of unwanted accesses possible, and the protection used against them has perforce to trade off the degree of protection against efficiency, and the complexity of enforcement. The basic goals are to provide: authentication ("proof that I am who I say I am"), authorization ("proof that I am allowed to do this"), and privacy ("proof that I am allowed to see the contents"). Historically, storage systems have provided little or no support for any of these, other than via simple physical security locking up the storage devices and the hosts that access them. This is likely to change significantly in the storage network world because the number of different threat types is so much larger. Ultimately, all approaches to access control rely on some form of secure channel being established between the provider of data (or operations on that data) and its destination. The least secure, but also easiest to implement, solution imposes simple, coarse-grained accessor checks (of the form "is this host permitted to send requests to this storage device?"); at the other extreme lie cryptographic protection mechanisms that are resistant to a wide variety of impersonation, monitoring, and replay attacks, and capable even of securely storing data on storage devices that cannot be trusted not to divulge (or lose) their contents. Preventing unwanted accesses can be performed in several places: At the host: this offers convenience of implementation, easy scalability, low execution cost, and potentially fine-grained control, but it must be pervasively deployed, and the enforcement mechanism should be resistant to tampering. With support from their host operating systems, file systems and databases commonly enforce access controls on data, and similar kinds of solutions are appearing at the block vector layer. Networking stacks in the host can also use encryption to provide secure channels across various forms of network (e.g., IPsec). The performance of software versions of these schemes means today that they are best suited to use on relatively low speed network links (such as a wide area network), but this is likely to change with the deployment of hardware accelerators. In the storage network: today, this is largely restricted to relatively low-level approaches that offer the illusion of private, dedicated sub-networks that permit a set of host and storage device ports access only to one another, hiding any other ports. (These are usually called zones in Fibre Channel, or VLANs in the Ethernet world.) Because they operate on whole ports, such solutions are quite coarse-grained. But, by analogy with the migration of functions such as load balancing into traditional IP networking components, it is reasonable to expect finer-grained controls appearing in storage network switches, such as the ability to enforce such virtual networks on per-logical-unit (LU) boundaries. At the storage devices: ultimately, storage devices will probably have to accept as much responsibility for enforcing access controls as the hosts do: they are, after all, the primary shared resource that storage networking is trying to make available. This has long been true of servers at the file/record layer such as file servers and NAS heads; and now solutions are appearing that perform a simple form of "LU masking" at the block layer, where only certain hosts (or host ports) are allowed access to a particular LU. As storage networks span ever-greater numbers of devices, and encompass greater heterogeneity of host types, host software, and distances, the importance of this issue will greatly increase. |
