KNOW MORE ON THE SNIA SHARED STORAGE MODEL ,THE LAYERS AND THE MODEL 317

KNOW  MORE ON THE SNIA SHARED STORAGE MODEL ,THE LAYERS AND THE MODEL 317

The SNIA Shared Storage Model defines four layers (Figure 10.2):

I. Storage devices

II. Block aggregation layer

III. File/record layer

IIIb. Database

IIIa. File system

IV Applications

Applications are viewed as users of the model and are thus not described in the model. They are, however, implemented as a layer in order to illustrate the point in the model to which they are linked. In the following we'll consider the file/record layer (Section 10.1.6), the block layer (Section 10.1.7) and the combination of both (Section 10.1.8) in detail.

10.1.6 The file/record layer

The file/record layer maps database records and files on the block-oriented volume of the storage devices. Files are made up of several bytes and are therefore viewed as byte vectors in the SNIA model. Typically, file systems or database management systems take over these functions. They operate directories of the files or records, check the access, allocate storage space and cache the data (Chapter 4). The file/record layer thus works on volumes that are provided to it from the block layer below. Volumes themselves consist of several arranged blocks, so-called block vectors. Database systems map one or more records, so-called tuple of records, onto volumes via tables and table spaces:

Tuple of records −→ tables −→ table spaces −→ volumes

In the same way, file systems map bytes onto volumes by means of files:

Bytes −→ files −→ volumes

Some database systems can also work with files, i.e. byte vectors. In this case, bloc vectors are grouped into byte vectors by means of a file system – an additional abstraction level. Since an additional abstraction level costs performance, only smaller databases word in a file-oriented manner. In large databases the additional mapping layer of byte to bloc vectors is dispensed with for performance reasons. The functions of the file/record layers can be implemented at various points (Figure 10.3 Section 5.6):

• Exclusively on the host In this case, the file/record layer is implemented entirely on the host. Databases an the host-based file systems work in this way.

• Both in the client and also on a server component The file/record layer can also be implemented in a distributed manner. In this case th

functions are distributed over a client and a server component. The client component is realized on a host computer, whereas the server component can be realized on th following devices:

• NAS/file server A NAS/file server is a specialized host computer usually with a locally connected dedicated storage device (Section 4.2.2).

• NAS head A host computer that offers the file serving services, but which has access to external storage connected via a storage network. NAS heads correspond with the devices called NAS gateways in our book (Section 4.2.2). In this case, client and server components work over network file systems such as NFS or CIFS (Section 4.2).

The block layer

The block layer differentiates between block aggregation and the block-based storage devices. The block aggregation in the SNIA model corresponds to our definition of the virtualization on block level (Section 5.5). SNIA thus uses the term 'block aggregation' to mean the aggregation of physical blocks or block vectors into logical blocks or block vectors. To this end, the block layer maps the physical blocks of the disk storage devices onto

logical blocks and makes these available to the higher layers in the form of volumes (block vectors). This either occurs via a direct (1 : 1) mapping, or the physical blocks are first aggregated into logical blocks, which are then passed on to the upper layers in the form of volumes (Figure 10.4). In the case of SCSI, the storage devices of the storage device layer exist in the form of one or more so-called logical units (LU). Further tasks of the block layer are the labelling of the logical units using so-called logical unit numbers (LUNs), caching and – increasingly in the future – access control.

Block aggregation can be used for various purposes, for example:

• Volume/space management The typical task of a volume manager is to aggregate several small block vectors to form one large block vector. On SCSI level this means aggregating several logical units

 THE MODEL 317

to form a large volume, which is passed on to the upper layers such as the file/record layer (Section 4.1.4).

• Striping In striping, physical blocks of different storage devices are aggregated to one volume. This increases the I/O throughput of the read and write operations, since the load is distributed over several physical storage devices (Section 2.5.1).

• Redundancy In order to protect against failures of physical data carriers, RAID (Section 2.5) and remote mirroring (Section 2.7.2) are used. Snapshots (instant copies) can also be used for the redundant storage of data (Section 2.7.1). The block aggregation functions of the block layer can be realized at different points of the shared storage environment (Section 5.6):

• On the host Block aggregation on the host is encountered in the form of a logical volume manager software, in device drivers and in host bus adapters.

• On a component of the storage network The functions of the block layer can also be realized in connection devices of the storage network or in specialized servers in the network.

• In the storage device Most commonly, the block layer functions are implemented in the storage devices themselves, for example, in the form of RAID or volume manager functionality. In general, various block aggregation functions can be combined at different points of the shared storage environment. In practical use, RAID may, for example, be used in the disk subsystem with additional mirroring from one disk subsystem to another via the volume manager on the host computer (Section 4.1.4). In this setup, RAID protects against the failure of physical disks of the disk subsystem, whilst the mirroring by means of the volume manager on the host protects against the complete failure of a disk subsystem. Furthermore, the performance of read operations is increased in this set-up, since the volume manager can read from both sides of the mirror (Section 2.5.2).