2.2 The SCSI Architecture

The SCSI protocol was developed to provide efficient transport of data between computers and peripheral devices such as disks, printers, scanners, and other resources. SCSI sits below the file/record layer in the SNIA Shared Storage Model and receives requests to send or retrieve blocks of data from a peripheral device. Suppose, for example, that an application initiates a write request to the operating system to store data. For the SCSI protocol layer, this write request is interpreted as a command to write a certain number of data blocks to a specified location. As a mediator between the operating system and storage, SCSI is not responsible for how the blocks are assembled for transport or how they are actually placed on disk. As SCSI sends blocks to a destination, the target may be a single physical drive or a RAID controller that will stripe the blocks over multiple physical drives. The responsibility of the SCSI protocol is simply to ensure that the write task is completed and to report success to the operating system, no matter how the physical storage is configured.

SCSI targets are identified by the operating system in a three-part bus/ target/LUN descriptor. The bus designator is one of several SCSI interfaces installed on a host system. A traditional parallel SCSI adapter card may represent a single bus, with that bus supporting multiple daisy chained disks. Alternatively, a Fibre Channel host bus adapter (HBA) or iSCSI network interface may be viewed by the operating system as a SCSI bus. Multiple installed cards would be seen as multiple bus numbers. The target represents a single storage resource on a bus daisy chain, whereas the LUN (logical unit number) designation identifies the SCSI client within the target. A single physical disk, for example, may have one logical unit and consequently one logical unit number. A RAID controller attached to a bus may represent a single target but have multiple logical units and multiple LUNs assigned.

For configuration and management purposes, the operating system represents SCSI targets in the bus/target/LUN triad nomenclature, but what the user and user application see are logical identifiers, such as "E:" drive. Thus, the mapping between the bus/target/LUN designation and the logical drive identifier provides the portal between physical devices and the upper-layer file system.

The bus/target/LUN identifier may be further mapped to the addressing requirements of a specific transport. The Fibre Channel Protocol, for example, maps bus/target/LUN to a device ID/LUN pair. Consequently, the representation of physical storage has two components. One, directed at the operating system, establishes a familiar addressable entity based on the SCSI triad. The other, directed at the specific storage transport, accommodates the addressing requirements of that topology.

The relationship between SCSI initiators and targets is defined in the SCSI Architectural Model (SAM-2) shown in Figure 2-4. For networked storage, additional standards documents further define serial SCSI implementations. Serial SCSI implementations such as Fibre Channel and iSCSI are a component of the SAM-2 definitions for SCSI-3 commands.

Figure 2-4. SAM-2 SCSI-3 standards functional layers

graphics/02fig04.gif

The SCSI architecture defines the relationship between initiators (hosts) and targets (for example, disks) as a client/server exchange. The SCSI-3 application client resides in the host and represents the upper-layer application, file system, and operating system I/O requests. The SCSI-3 device server sits in the target device, responding to requests. The client/server requests and responses are exchanged across some form of underlying transport, which is governed by the appropriate SCSI-3 service delivery protocol for that transport, such as the FCP protocol or iSCSI for gigabit serial links. Thus, the SCSI-3 commands that serve I/O requests from the host application are differentiated from the SCSI-3 transport protocols that actually move data via the service delivery subsystem.

An initiator may have multiple requests pending to a target. The client/ server model must therefore accommodate concurrent request-response exchanges and track the status of each. As shown in Figure 2-5, multiple requests generate multiple instances of the application client and multiple transactions for the device server. Status and diagnostic functions can be supervised through task management between the two entities.

Figure 2-5. SCSI client/server model. The delivery subsystem could be parallel cabling, FCP, or iSCSI

graphics/02fig05.gif

On the initiator, juggling multiple transactions to one or more targets requires context switching: the ability to quickly switch from one job to another as SCSI responses are processed. An initiator such as a server, for example, could issue a write request to a target. As the server waits for the target to prepare its buffers to receive data, it may switch contexts to another pending task and so maximize throughput. If SCSI tasks were performed only consecutively, time would be wasted waiting for each individual write or read to complete.

The failure to handle multiple threads concurrently may result in additional overhead in the form of retries or SCSI timeouts. The SAM-2 architecture does not define how this is to be implemented but indicates it must be addressed. Typically, context switching is performed by the host adapter card, whether it is parallel SCSI, Fibre Channel, or iSCSI.

The SCSI-3 Architectural Model is structured so that the I/O requests from the host system can be served without regard to the underlying service delivery subsystem. A single file server could therefore conduct I/O operations against a variety of target types. A server could, for example, have direct-attached SCSI targets as well as serial SCSI targets over a gigabit interface.

Reads and writes of data between SCSI initiators and targets are performed with a series of SCSI commands, delivery requests, delivery actions, and responses. SCSI commands and parameters are specified in the command descriptor block (CDB). The CDB is part of a command frame sent from initiator to target. For improved performance on write operations, the frame may also contain data to be written to the media. Serial SCSI transport protocols such as Fibre Channel and iSCSI simply encapsulate CDBs as their payload. The CDB is encapsulated within the Fibre Channel Protocol information units (IUs), whereas in iSCSI it is carried in the iSCSI protocol data unit (PDU).

The first byte of a CDB is an opcode that specifies the type of operation the target is to perform. A SCSI write to disk, for example, triggers the creation of an application client on the initiator (such as HBA), which in turn issues a SCSI command request to the target to prepare its buffers for data reception. The target device server issues a delivery action response when its buffers are ready. The initiator responds by sending blocks. Depending on the lower-layer delivery subsystem, the blocks may be transported as bytes in parallel such as LVD SCSI cabling) or segmented into frames for serial transport (such as Fibre Channel or iSCSI).

From the standpoint of the application or operating system, the write was conducted as a single transaction. In reality, a single write may cause multiple delivery requests and delivery action exchanges before all data is finally sent to the target, as shown in Figure 2-6.

Figure 2-6. A SCSI write operation with multiple data delivery actions to complete a single command/response pair

graphics/02fig06.gif

In a read operation, the SCSI command block reverses the sequence of data delivery requests and acknowledgments, although it is assumed that because the initiator issued the read command, its buffers are ready to receive the first set of data blocks. The number of blocks sent in a single phase of write or read transactions is negotiated between the initiator and target and is based on the buffering capacity of each. High-performance disk arrays, for example, typically provide large buffers to accommodate larger transfers and thus increase productivity.



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