Why a model for shared storage?

This document presents the SNIA Shared Storage Model, which describes a set of practical, possible storage network architectures.

Such an architecture describes a particular functional partitioning of services across the physical and logical resources in a shared storage environment. In use, an architecture is used to develop a storage system design, which includes things like the quantity and size of the resources, and possibly choices of suppliers, versions, etc. A completed design contains enough information to allow construction of a real system that conforms to it.

The SNIA Shared Storage Model is deliberately simple on the surface: the goal is to make it easy to use, yet rich enough to cover a wide range of storage networks that are being or could be deployed. To make this easier, the model is primarily described in a graphical form, supported by a concise terminology that supports the key concepts.

A major intent of the model is to highlight the fundamental structures of a storage system that have the largest effect on the system's value proposition. These include, but are not limited to:

• The functions or services that a storage network architecture can support.

• The division of functional responsibility among the components of the system.

• Relationships between control and data flows.

• Boundary conditions where interoperability is likely to be an issue. This includes both places where interactions take place between architecture modules (and hence interoperability is required) and what kinds of interoperability must occur there.

• The implications of interface abstraction on technology evolution and marketplace competition.

Of course, the model doesn't explicitly cover all possible architectures. Instead, the intent is that the user of the model can use it to develop and describe his or her own particular mix of architectural elements and choices. Nonetheless, our experience with it to date has been that it is capable of covering a wide variety of different architectures and designs. It is likely, therefore, that the model does cover a new situation although perhaps not in the most immediately obvious way.

Benefits of the model

The benefits from a model of this form are that it can:

• Provide a common vocabulary that people comparing and designing architectures can use to communicate with one another, and make their design efforts and documentation more precise. (The analogy here is with the "definitions of terms" that are an important deliverable from the IETF and standards bodies.) This will also make it easier for vendors to explain their offerings to customers.

• Provide a common way of recording network storage architectures, so that these architectures can be compared and contrasted with one another, making it easier for customers to compare different architectures and proposals.

Overall, the hope is that this common "vocabulary" will help to align the storage industry for the mutual benefit of all of its participants and customers.

Note that although the model describes architectures, it is not itself an architecture. 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." The model does not represent any value judgments between the architectures it describes. Instead, the model makes it possible to compare architectures, and to communicate about them in a common vocabulary.

A note on the graphical conventions used in the model

Throughout the model, we have tried to be consistent about the following graphical conventions:

• 3D objects represent physical entities (hosts, switches, etc.)

• 2D objects with drop shadows represent functional entities

• Orange/ochre represents storage devices

• Dark blue represents host computer systems

• Pale blue represents storage networks

• Green represents file-level entities

• Yellow is used for caches

• Thick lines represent the major data transfer paths; thinner lines with arrowheads represent paths over which metadata flows

• Diagonal stripes indicate metadata managers

• The vertical placement is also important: particularly in the block subsystem layer

• The classic storage model

All too often, the picture shown here represents the current state of conversations about storage networking: vendors, system designers, and customers try to describe what they want or what they have using a set of inconsistent, ad hoc, languages.

Things are made worse by there being a great many network storage components, with relatively small differences between them. This causes designs that are actually the same to be described in different ways, and different designs to be described sometimes using identical forms of words. This is clearly undesirable, and 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.

These confusions are not accidental: the wide variety of the range of system architectures that have been developed exhibit a great deal of complexity because they are trying to accommodate a great deal of information, and cover many different elements and functions. Some of those elements are physical boxes, wires, computers and it is often the case that architectures are presented by describing the physical components in some detail, coupled with an explanation of what functions they perform. That is, the traditional approach focuses first on the physical partitioning that a particular vendor has selected, rather than on the range of options that may be possible. And because this is "box-centric" rather than "function-centric" it is all too easy to misunderstand precisely what has been included.

Figure E-1.

The SNIA Shared Storage Model is an approach to removing these difficulties. It does so by taking a slightly different approach: it first identifies the functions that can be provided, and then describes a range of different architectural choices for placing those on physical resources. As a result, the SNIA Shared Storage Model makes it easier to compare alternative architectures and designs, it lets architects think about functions independently of implementations, and it makes it simpler to anticipate new implementations or combinations of architectures, designs, and implementations.