Additional topics

This section pulls together some additional areas that the model touches on that don't readily or conveniently fit into the layered structure identified above.

Clustering

In addition to the simple block aggregation that the model has described so far, many components of the model are amenable to a form of "service aggregation" or clustering to improve scalability, failure tolerance, and ease of management. It is particularly prevalent in solutions to the distributed cache management problem mentioned above, although database systems that support it tend to emphasize the increased availability that can result.


Figure E-13.

graphics/efig13.gif


In the context of a file system, this approach is often called a "cluster file system," or "distributed file system." The idea is spreading: logical volume managers are appearing with similar clustering properties.

Data versus storage

One of the issues that often arise in discussions about storage models is of the form "what's the difference between data and storage?" The approach taken in the SNIA Shared Storage Model 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.

For example:

User:

data ("learning my preferences")

Application:

container ("user keystroke history")

Application:

data ("user keystroke history file")

File system:

container ("byte vector")

File system:

data ("a named file")

Volume system:

container ("blocks in volume")

Volume system:

data ("replicated, striped layout")

Disk array:

container ("blocks in LU")

Sharing of resources and data

With host-attached storage, storage resources are accessible, managed, and organized solely by the host to which they are directly connected. No other hosts can access, manage, or organize these storage resources except through the host to which they are directly connected.

This difficulty can be alleviated in a shared storage environment: storage resources can be directly accessible by many hosts, and can be considered a common pool of storage resources. While this capability offers many benefits, e.g., in the area of flexibility, it also creates the requirement that access be controlled.

To further explore this topic, a distinction must be made between resource sharing and data sharing.

Resource sharing

Resource sharing is the shared use of just the storage system resources those portions of the storage system that provide its containers not the containers themselves or their contents.

Shared resources commonly include the network and physical storage resources such as storage controllers, disk arrays, tape libraries, disk drives, tape drives, etc., attached to it. A simple example is an array controller that provides a logical unit (LU) to one host and a different LU to a second host. The network, the array controller and possibly even the array's disk drives are shared resources, but the LUs are not shared in any way.

Resource sharing is present, at least in principle, in every shared storage environment, since the storage devices and the storage network are examples of shared resources. It is much more common than data sharing because it avoids difficult issues such as multi-copy data coherence and data format translation.

Data sharing

Data sharing is the sharing of contents: two or more client entities (hosts) access and interpret the same data. (It is sometimes called "logical sharing," or "content sharing.") Data sharing requires attention to difficult issues such as coherence and data format translation. As a result, it is relatively uncommon at the block level, but much more prevalent at the file/record level.

In the most primitive form of data sharing, multiple hosts may be given read-only access to the same logical unit (or logical volume). Some logical volume systems can handle a single writer with multiple readers but the real difficulties occur in the file/record level, where caching is done. Most often, such block-based data sharing is supported only within the context of cluster file systems or distributed databases on a set of clustered host systems.

However, file/record-based data sharing is quite common for the case of a single, shared server providing a client/server file access interface such as NFS or CIFS. Here, the protocols required to allow multiple hosts to access the same target file system are reasonably well embedded in the client side of distributed file system implementations although there is still room for improvement in cases where there are multiple writers for the same file.


Figure E-14.

graphics/efig14.gif


Modular systems

The ability to compose larger systems from modules (components) offers many benefits.

  • Systems can be built using interchangeable components from different vendors. This makes competitive development by multiple suppliers possible, driving quality up and prices down for customers.

  • Modules can be upgraded or enhanced independently (e.g., one module at a time rather than a complete system replacement), as long as the interface rules are adhered to. This can protect invest ments, reduce obsolescence, and support smooth improvements in functionality over time.

  • System scale can be increased by adding or enhancing components, allowing smooth incremental growth. In turn, this minimizes dis ruptions to the system's users, lowers the initial system cost, and lets customers take advantage of cost reductions in components over time.

Achieving all this requires that modules can be composed into larger systems and replaced individually. In turn, this requires module interfaces that have well defined functions (what they do), interface protocols (data formats), and access protocols (system call, RPC, flow control, etc.).


Figure E-15.

graphics/efig15.gif


Three examples of physical interfaces that can be used are shown here:

  • A binary programmatic interface, or API;

  • A bus e.g., the SCSI parallel bus;

  • A network e.g., Fibre Channel, Ethernet, etc.

The illustration shows how a logically layered system may be designed by stacking functional modules (shown in blue) with different interfaces (shown in orange).

Interfaces may be proprietary or open. Proprietary interfaces deliver some of the same advantages as open interfaces, but the vendor choice is likely to be more limited and new developers may not have ready access to the technical specifications required for interoperability.


Figure E-16.

graphics/efig16.gif


It is the position of the SNIA that the full benefits of modular systems are only likely to be realized through the development of common, open interfaces that see wide adoption. As a result, SNIA promotes the development of open, industry-standard interfaces that have well-understood, well-documented specifications. It is also important that the specifications be published (which includes open discussion of changes under formal revision control), and are supported by multiple products. Industry standards processes are an important way of achieving these goals, which is why SNIA is active in supporting them.

Storage networks

The SNIA Shared Storage Model does not explicitly include details of the storage network, such as whether or not to use network switches or a par ticular kind of interconnection technology. This is intentional: the model is network- and transport-neutral: although it relies only on the existence of storage networks and module interfaces to achieve the functional decompositions that it describes, it is not particular about the precise details of those networks or interfaces.

For example, much has been made of the merits of switched networks, and their importance to the shared storage environment. But in the context of the SNIA Shared Storage Model, it is worth emphasizing that this arises primarily because of their good networking properties, rather than anything specific to storage systems: smooth scalability, fault-tolerance through supporting redundant paths, support for heterogeneity in end-node types, access at a distance, and reasonable cost for high aggregate performance.

To date, most shared storage networks for the block level have been built on Fibre Channel, and most shared file/record-level networks on Ethernet. In the future, the range is likely to become broader (e.g., encompassing Sonet and InfiniBand), and it seems likely that IP-based storage transport protocols will come into being for block-level storage traffic.

"SAN" versus "NAS"?

While the SNIA Shared Storage Model uses functional decomposition to show what could be built, many product vendors have taken vertical and horizontal slices of the model, explicitly specified the protocols and interconnect, and positioned the resulting products in broadly generalized categories. SAN (Storage Area Network) and NAS (Network Attached Storage) are two such categories.

We have deliberately avoided using the terms "SAN" and "NAS" until now, because the potential preconceptions carried with these terms detract from the implementation neutral nature of the Shared Storage Model. This section encourages the user to look beyond the labels attached to implementations, consider the usage models, and apply informed best judgment.

For example, it is frequently the case that network implementation choices are presented as either/or decisions: Fibre Channel or Ethernet or InfiniBand at the hardware level? FCP or TCP/IP transport protocols? Block-level or file/record-level access protocols?

In reality, of course, a combination of the appropriate choices from this space is the best response, rather than slavish adherence to one choice for all purposes. Each has their place; each has their advantages and disadvantages.

For the purposes of the SNIA Shared Storage Model, we define a storage network (SN) as any (mostly) dedicated network, that is installed (mostly) for storage traffic, whatever the hardware, API, or protocol. For example, far from being direct competitors, the "SAN" and "NAS" models actually address different functional layers of the Shared Storage Model, and thus may be implemented in a complementary manner.

As technologies change, generalized terms become more difficult to rationalize. Is iSCSI (running the block system over TCP/IP over an Ethernet network) still a SAN? Is running a file system such as DAFS (Direct Attach File System) over VI over Fibre Channel a NAS?

These distinctions become less relevant in the presence of the transport neutrality of the SNIA Shared Storage Model. In turn, this allows decisions to focus on the consequences of each design choice, rather than adherence to simplistic "slogans." Thus, we encourage the end users of storage networking technology to return to the Shared Storage Model with a focus on the problem to be solved, rather than the terminology used to describe the solution. In this way, unnecessary semantic battles can be avoided.

A challenge

Many of the standards or solutions needed to make the promise of shared storage a reality do not yet exist, or exist only in primitive or proprietary forms. Simply put, most operating systems and volume managers still expect a wire, not a complex, intelligent interconnect, between them and their storage devices.

Some of the issues that need to be solved by standardization in the storage networking industry include initialization, discovery, end-to-end binding, address mapping, address distribution and management, name services, and event management. Many of these problems will need to be solved multiple times, because although the Shared Storage Model is transport neutral, the simple act of selecting a particular transport means buying into a particular set of support mechanisms (or services) that may be incomplete.

Future work by the SNIA Technical Council and Technical Working groups will focus on the "services subsystem" part of the Shared Storage Model, where many of these issues reside.



Designing Storage Area Networks(c) A Practical Reference for Implementing Fibre Channel and IP SANs
Designing Storage Area Networks: A Practical Reference for Implementing Fibre Channel and IP SANs (2nd Edition)
ISBN: 0321136500
EAN: 2147483647
Year: 2003
Pages: 171
Authors: Tom Clark

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net