The NSS Architecture

To gain more of an understanding of how the underlying structure of Novell Storage Services is layed out, read the following sections. This section is not required reading for NSS setup and maintenance.

The Novell Storage Services architecture contains the following layers:

NSS Architecture

The NSS configuration process, through the NSS architecture, prepares blocks of storage so that files created in or moved to NSS can be located easily. Hard disk space on any number of storage devices can be fully optimized. Unused free space that exists on all hard disks and NetWare volumes on your server can be combined into a storage pool, then used to create NSS volumes. This pooling allows you to have better control of your unused storage free space. NSS can even use any free space that is available on your Sys volume.

The traditional NetWare file system uses NetWare partitions, volumes, directories, and files. NSS uses NSS partitions, NSS storage groups, NSS volumes, directories, and files. For a basic description of these, see NSS Components.

NOTE: For this release, only hard drives and CD-ROM storage devices are recognized in NSS. In the future, additional storage device types will be supported through the storage provider modules.

The NSS architectural layers, from the media (device) connection to the interface (client) connection, are as follows:

Media Access Layer (MAL)
Loadable Storage Subsystem (LSS)
Object Engine
Common Layer Interface (CLI)
Semantic Agents (SA)

The next figure illustrates the five layers of NSS.

Media Access Layer

The Media Access Layer (MAL) provides the connection to and communicates with storage devices such as hard drives and CD-ROMs. The MAL lets network administrators create NSS storage groups and NSS volumes through the MAL managers (providers and consumers) that view and manage the storage capabilities of servers as a quantity of storage deposits.

The MAL frees administrators from having to enable large numbers of storage devices individually. The modular design allows new devices and new technologies to be added easily as required for productivity.

The storage object bank is the central layer of the MAL that is responsible for storage manager and storage object registration. Usable free space (storage deposit) is deposited in to the object bank by the registered provider in the MAL. Each registered storage object in the object bank has a deposit type. Each storage deposit type is tagged with attributes, for example, media such as Read-Only disks.

There are two types of storage managers in the MAL: consumers and providers. Consumers and providers are the managers you select when you set up or change your NSS configuration. (See Configure NSS Using NWCONFIG for information.)

After a consumer claims free space, input/output then proceeds to and from the device on which the free space (now owned by NSS) resides. Since the MAL provides an abstraction of system storage media, NSS could be portable to other operating systems such as UNIX or OS/2*. This means potentially any type of device could be supported on any system.

Providers interface and manage the physical system resources (devices) used by the MAL. They are installed with NSS and query the server's storage devices for free space. Providers find, manage, and register storage objects, such as DOS partitions, NetWare volumes, or CD-ROMs in the object bank. Providers understand and can recognize various partition types such as NetWare or DOS.

Providers
- Locate partitions or NetWare volumes
- Determine whether they are in use
- Construct storage objects if they are not
- Deposit the storage objects as storage deposits in the object bank
If you add new media such as a hard disk, you choose a provider (through the Update Provider Information option) to scan and recognize the device for NSS configuration.
Consumers are similar to other applications installed in NetWare 5. Consumers are attached to the file system and help build the file input and output path. They configure and claim (or take) ownership of the storage deposit that has been combined from various media types by the provider. Consumers register themselves with the object bank so they can control any deposited media objects (storage deposits) they own. Consumers take NSS ownership of the file system free space or free space on physical partitions for storage group and NSS volume creation. NSS consumers cannot own NetWare partition space, but they can consume free space inside a NetWare volume.

See A Concept of NSS Configuration for an example of how providers and consumers are used in NSS.

Loadable Storage Subsystem

The Loadable Storage Subsystem (LSS) contains the loadable file system types that various devices understand. Currently, the LSS supports file system types for CD-ROM (using ISO9660 and Hierarchical File System or Macintosh HFS), DOS FAT (for local hard drives and DOS FAT partitions), and the NSS file system for rapid restart and scalability. If you enter volumes at the server console, and you use DOS or CD-ROM formats, the LSS recognizes both of them and displays them as NSS volumes. See Other Volumes That NSS Creates for information on DOS and CD-ROM formats.

The LSS gathers information from the Media Access Layer (MAL) about the storage devices it recognizes (for this release, hard drives and CD-ROMs). The MAL lets the LSS know what storage devices it identifies and registers an existing NSS volume on the storage devices with NSS. The LSS then obtains information from the MAL about the NSS volume on which the data resides and passes the information up to the semantic agent (SA) so the volume can be viewed at the client workstation.

Object Engine

The object engine layer is the NSS object store. The design of this layer differs from the traditional NetWare file system by providing much higher levels of volume, directory, and file object efficiency. The NSS object engine uses sophisticated and efficient mechanisms to manage the objects it stores, achieving high levels of performance, scalability, robustness, and modularity.

Performance. The NSS object engine stores objects on disks in balanced trees (called B-trees) to improve performance. The compact B-tree structures guarantee that the system can retrieve an object from disk in no more than four input and output cycles. This provides more speed per cache block. B-trees also improve memory management by allowing the system to locate an object anywhere in storage without loading the entire directory entry table (DET) into memory.

The ability to share name space also improves disk space usage. Instead of storing a name for each name space in a single stored object as is the case in the traditional NetWare file system, NSS uses one name for DOS and another name for NFS. The name spaces in an object share a common name if no naming conflicts exist.

Scalability. The object engine uses 64-bit interfaces to let network administrators create a much greater number of objects (volumes, files, and eventually HTML pages, etc.) and individual objects much larger than in the traditional NetWare file system.

Rapid recovery. To enable rapid NSS volume mounts after a system crash, the LSS maintains a log that records all transactions written and waiting to be written to disk. The object engine defines interfaces for any LSS to implement journaled management recovery. If a server crashes, the traditional NetWare recovery procedure uses the VREPAIR utility to check and repair inconsistencies in the DET, which might takes hours to complete. By contrast, NSS locates an error on a disk by referencing the journal, noting the incomplete transaction, and correcting the error by either re-processing the incomplete transaction or by backing it out. Consequently, the NSS volume does not have to be thoroughly searched.

Modularity. The modularity of the object engine lets network administrators define new storage objects and plug them in to the storage system whenever they are needed. In the near future, new storage technologies such as the Digital Video Disc (DVD) could be plugged in to the engine transparently without affecting other pieces of the software.

Common Layer Interface

The Common Layer Interface (CLI) contains a set of Application Protocol Interfaces (APIs) that define the interfaces the NSS semantic agents (see Semantic Agents) use to access the object engine for NSS naming, object, and management services.

Naming services include basic object naming and lookup operations as well as name space and context management services.
Object services provide the creation, deletion, storage, and definition of objects.
Management services provide other underlying types of NSS management, such as registration, file locking, transactions, and management of storage pools and NSS volumes.

Semantic Agents

The Semantic Agent (SA) layer contains loadable software modules that define client-specific interfaces available to stored NSS objects.

For example, the traditional NetWare file system Semantic Agent interprets requests received from a NetWare client, passes the requests to the Common Layer Interface, and onward to the object engine for execution.

In the future, another semantic agent may implement an HTTP interface, allowing Web browsers to access data also stored by the object engine. This modular approach means administrators no longer need separate storage solutions for their various storage systems. New semantic agents can be created and loaded on the server as NetWare modules at any time without interrupting other loaded semantic agents.

How NSS Retrieves a File

After the NSS modules are installed and loaded and you configure NSS (create your storage groups and NSS volumes), your NSS volumes are ready to use.

The next illustration explains how a file is retrieved as it moves through the NSS architectural layers.

Notice what happens to a file owned by NSS that is requested from the client machine.

Lisa wants to access the file agenda. She is logged in to the network from a Novell client. The request for a file moves through the NSS structure if the NSS volume in which the file resides has been added to NDS:

Client. The request to retrieve and open the file agenda is initiated by Lisa at a Novell client machine.
Semantic Agent (SA). The request for the file agenda passes from the Novell client to its SA. The NetWare Core Protocol (NCP) request is interpreted by the traditional NetWare file system SA, which in turn translates the client request in to the set of common layer calls required to execute the NetWare file system operation. The SA then passes the request to the Common Layer Interface (CLI) that this client wants to access the file agenda.
Common Layer Interface (CLI). Once the request is received from the SA, the CLI routes the request in to its proper naming, object, and management services, then passes the request on to the object engine layer for execution.
Object Engine. The request is received from the CLI. Once the request is executed in this interface, the object engine identifies the NSS volume on which the file resides and sends notification to the object engine layer (MAL) to retrieve the file.
Media Access Layer. The request to retrieve agenda is sent from the object engine to the MAL. The MAL managers notify the media (the specific hard drive or CD-ROM) on which the data is written.
Media. The request is received that the file agenda resides on x hard drive. The file is retrieved and the request is sent back to the Novell client for Lisa to open.