Guidelines for OpenVMS Cluster Configurations

Reference: For more information about DSSI, see the DSSI OpenVMS Cluster Installation and Troubleshooting Manual.

4.10 Ethernet Interconnect

The Ethernet interconnect provides single path connections within an OpenVMS Cluster system and a local area network (LAN). Ethernet and FDDI are both LAN-based interconnects. See Section 4.11 for information about FDDI and for general LAN-based cluster guidelines.

4.10.1 Advantages

The Ethernet interconnect offers the following advantages:

Lowest cost of all OpenVMS Cluster interconnects.
Supports 96 nodes on a single interconnect.
Allows for extended physical distribution of nodes.

4.10.2 Throughput

The maximum throughput of the Ethernet interconnect is 10 Mb/s. Because Ethernet adapters do not provide hardware assistance, processor overhead is higher than for CI or DSSI.

General network traffic on an Ethernet can reduce the throughput available for OpenVMS Cluster communication. The Ethernet can become an I/O bottleneck in an OpenVMS Cluster system. Therefore, consider the capacity of the total network design when you configure an OpenVMS Cluster system with many Ethernet-connected nodes or when the Ethernet also supports a large number of PCs or printers.

Reference: For information about reducing congestion on an Ethernet LAN, see Section 7.7.7.

4.10.3 Multiple Ethernet Load Balancing

If only Ethernet paths are available, the choice between which path the OpenVMS Cluster software uses is based on latency (computed network delay). If delays are equal, either path can be used. Otherwise, the OpenVMS Cluster software chooses the channel with the least latency. The network delay across each segment is calculated approximately every 3 seconds. Traffic is then balanced across all communication paths between local and remote adapters.

4.10.4 Supported Adapters and Buses

The following are Ethernet adapters and the internal bus that each supports:

DETRA (TURBOchannel)
DEFTA-FA (TURBOchannel)
DEFTA-xx (TURBOchannel)
DGLTA (TURBOchannel)
DE2xx (ISA)
DW110 (ISA)
DE42x (EISA)
DE435 (PCI)
DW300 (EISA)
TULIP (PCI)
KZPSM (PCI)
DE4xx (PCI)
DE500-xx (PCI)
TC4048 (PCI)
DGLPB (PCI)
3COM (PCMCIA)
DEMNA (XMI)
TGEC (embedded)
COREIO (TURBOchannel)
PMAD (TURBOchannel)
DE422 (EISA)
DEBNI (VAXBI)
DEBNA (VAXBI)
SGEC (embedded)
DESVA (embedded)
DESQA (Q-bus)
DELQA (Q-bus)

Reference: For complete information about each adapter's features and order numbers, see the Digital Systems and Options Catalog, order number EC-I6601-10.

To access the most recent Digital Systems and Options Catalog on the World Wide Web, use the following URL:

http://www.digital.com/info/soc

4.10.5 Ethernet-to-FDDI Bridges

You can use transparent Ethernet-to-FDDI translating bridges to provide an interconnect between a 10-Mb/s Ethernet segment and a 100-Mb/s FDDI ring. These Ethernet-to-FDDI bridges are also called "10/100" bridges. They perform high-speed translation of network data packets between the FDDI and Ethernet frame formats.

Reference: See Figure 7-22 for an example of these bridges.

4.11 Fiber Distributed Data Interface (FDDI)

FDDI is an ANSI standard LAN interconnect that uses fiber-optic cable. FDDI supports OpenVMS Cluster functionality over greater distances than other interconnects. FDDI also augments the Ethernet by providing a high-speed interconnect for multiple Ethernet segments in a single OpenVMS Cluster system.

4.11.1 Advantages

FDDI offers the following advantages:

Supports 96 nodes on a single interconnect.
Combines high throughput and longest distance between nodes.
Supports a variety of topologies.

4.11.2 Types of FDDI Nodes

The FDDI standards define the following two types of nodes:

Stations --- The ANSI standard single-attachment station (SAS) and dual-attachment station (DAS) can be used as an interconnect to the FDDI ring. Digital recommends that stations be attached to wiring concentrators and that wiring concentrators be attached to the dual FDDI ring, making the ring more stable.
Wiring concentrator --- The wiring concentrator (CON) provides a connection for multiple SASs or CONs to the FDDI ring. A DECconcentrator 500 is an example of this device.

4.11.3 Distance

FDDI limits the total fiber path to 200 km (125 miles). The maximum distance between adjacent FDDI devices is 40 km with single-mode fiber and 2 km with multimode fiber. In order to control communication delay, however, Digital recommends limiting the maximum distance between any two OpenVMS Cluster nodes on an FDDI ring to 40 km.

4.11.4 Throughput

The maximum throughput of the FDDI interconnect (100 Mb/s) is 10 times higher than that of Ethernet.

In addition, FDDI supports transfers using large packets (up to 4468 bytes). Only FDDI nodes connected exclusively by FDDI can make use of large packets.

Because FDDI adapters do not provide processing assistance for OpenVMS Cluster protocols, more processing power is required than for CI or DSSI.

4.11.5 Supported Adapters and Bus Types

Following is a list of FDDI adapters and the buses they support:

DEFPA (PCI)
DEFPZ (integral)
DEMFA (XMI)
DEFAA (Futurebus+)
DEFTA (TURBOchannel)
DEFZA (TURBOchannel)
DEFEA (EISA)
DEFQA (Q-bus)

Reference: For complete information about each adapter's features and order numbers, see the Digital Systems and Options Catalog, order number EC-I6601-10.

To access the most recent Digital Systems and Options Catalog on the World Wide Web, use the following URL:

http://www.digital.com/info/soc

4.11.6 Configuration Guidelines for FDDI-Based Clusters

FDDI-based configurations use FDDI for node-to-node communication. The following general guidelines apply to FDDI configurations:

The HS1xx and HS2xx family of storage servers provide FDDI-based storage access to OpenVMS Cluster nodes.
Alpha and VAX systems can be configured with any mix of FDDI adapters.
All FDDI paths used for OpenVMS Cluster communication must operate with a minimum of 10 Mb/s throughput and low latency. You must use translating bridges when connecting nodes on an Ethernet to those on an FDDI. LAN segments can be bridged to form an extended LAN.
Multiple, distinct OpenVMS Cluster systems can be configured onto a single, extended LAN. OpenVMS Cluster software performs cluster membership validation to ensure that systems join the correct LAN OpenVMS cluster.
Reference: For information about multiple LANs, see Section 6.6. For extended LAN (ELAN) configuration guidelines, see Table 7-3.

4.11.7 Multiple FDDI Adapters

Because FDDI is ideal for spanning great distances, you may want to supplement its high throughput with high availability by ensuring that critical nodes are connected to multiple FDDI rings. Physical separation of the two FDDI paths helps ensure that the configuration is disaster tolerant.

4.11.8 Multiple FDDI Load Balancing

If only FDDI paths are available, the OpenVMS Cluster software bases the choice between which path to use on latency (computed network delay). If delays are equal, either path can be used. Otherwise, OpenVMS Cluster software chooses the channel with the least latency. The network delay across each segment is calculated approximately every 3 seconds. Traffic is balanced across all communication paths between local and remote adapters.

Chapter 5
Choosing OpenVMS Cluster Storage Subsystems

This chapter describes how to design a storage subsystem. The design process involves the following steps:

Understanding storage product choices
Estimating storage capacity requirements
Choosing disk performance optimizers
Determining disk availability requirements

Understanding advantages and tradeoffs for:

CI based storage
DSSI-based storage
SCSI-based storage
Host-based storage
LAN InfoServer

The rest of this chapter contains sections that explain these steps in detail.

5.1 Understanding Storage Product Choices

In an OpenVMS CLuster, storage choices include the StorageWorks family of products, a modular storage expansion system based on the Small Computer Systems Interface (SCSI--2) standard. StorageWorks helps you configure complex storage subsystems by choosing from the following modular elements:

Storage devices such as disks, tapes, CD-ROMs, and solid-state disks
Array controllers
Power supplies
Packaging
Interconnects
Software

5.1.1 Criteria for Choosing Devices

Consider the following criteria when choosing storage devices:

Supported interconnects
Capacity
I/O rate
Floor space
Purchase, service, and maintenance cost

5.1.2 How Interconnects Affect Storage Choices

One of the benefits of OpenVMS Cluster systems is that you can connect storage devices directly to OpenVMS Cluster interconnects to give member systems access to storage.

In an OpenVMS Cluster system, storage devices can be connected to the following interconnects:

HSJ and HSC controllers (on the CI)
HSD controllers and ISEs (on the DSSI)
HSZ and RZ series (on the SCSI)
Local system adapters

Table 5-1 lists the kinds of storage devices that you can attach to specific interconnects.

Table 5-1 Interconnects and Corresponding Storage Devices
Storage Interconnect Storage Devices

CI HSJ and HSC controllers and SCSI storage

DSSI HSD controllers, ISEs, and SCSI storage

SCSI HSZ controllers and SCSI storage

FDDI HS xxx controllers and SCSI storage

**Table 5-1 Interconnects and Corresponding Storage Devices**
Storage Interconnect	Storage Devices
CI	HSJ and HSC controllers and SCSI storage
DSSI	HSD controllers, ISEs, and SCSI storage
SCSI	HSZ controllers and SCSI storage
FDDI	HS xxx controllers and SCSI storage

5.1.3 How Floor Space Affects Storage Choices

If the cost of floor space is high and you want to minimize the floor space used for storage devices, consider these options:

Choose disk storage arrays for high capacity with small footprint. Several storage devices come in stackable cabinets for labs with higher ceilings.
Choose high-capacity disks over high-performance disks.
Make it a practice to upgrade regularly to newer storage arrays or disks. As storage technology improves, storage devices are available at higher performance and capacity and reduced physical size. For example, replacing an HSC95 and SA800 with an HSJ40 and SW800 increases capacity and reduces floor-space consumption.
Plan adequate floor space for power and cooling equipment.

5.2 Determining Storage Capacity Requirements

Storage capacity is the amount of space needed on storage devices to hold system, application, and user files. Knowing your storage capacity can help you to determine the amount of storage needed for your OpenVMS Cluster configuration.

5.2.1 Estimating Disk Capacity Requirements

To estimate your online storage capacity requirements, add together the storage requirements for your OpenVMS Cluster system's software, as explained in Table 5-2.

Table 5-2 Estimating Disk Capacity Requirements
Software Component Description

OpenVMS operating system Estimate the number of blocks¹ required by the OpenVMS operating system.
Reference: Your OpenVMS installation documentation and Software Product Description (SPD) contain this information.

Page, swap, and dump files Use AUTOGEN to determine the amount of disk space required for page, swap, and dump files.
Reference: The OpenVMS System Manager's Manual provides information about calculating and modifying these file sizes.

Site-specific utilities and data Estimate the disk storage requirements for site-specific utilities, command procedures, online documents, and associated files.

Digital and third-party application programs Estimate the space required for each Digital and third-party application product to be installed on your OpenVMS Cluster system, using information from the application suppliers.
Reference: Consult the appropriate Software Product Description (SPD) to estimate the space required for normal operation of any layered product you need to use.

User-written programs Estimate the space required for user-written programs and their associated databases.

Databases Estimate the size of each database. This information should be available in the documentation pertaining to the application-specific database.

User data Estimate user disk-space requirements according to these guidelines:

Allocate from 10,000 to 100,000 blocks for each occasional user.
An occasional user reads, writes, and deletes electronic mail; has few, if any, programs; and has little need to keep files for long periods.
Allocate from 250,000 to 1,000,000 blocks for each moderate user.
A moderate user uses the system extensively for electronic communications, keeps information on line, and has a few programs for private use.
Allocate 1,000,000 to 3,000,000 blocks for each extensive user.
An extensive user can require a significant amount of storage space for programs under development and data files, in addition to normal system use for electronic mail. This user may require several hundred thousand blocks of storage, depending on the number of projects and programs being developed and maintained.

Total requirements The sum of the preceding estimates is the approximate amount of disk storage presently needed for your OpenVMS Cluster system configuration.

**Table 5-2 Estimating Disk Capacity Requirements**
Software Component	Description
OpenVMS operating system	Estimate the number of blocks¹ required by the OpenVMS operating system. Reference: Your OpenVMS installation documentation and Software Product Description (SPD) contain this information.
Page, swap, and dump files	Use AUTOGEN to determine the amount of disk space required for page, swap, and dump files. Reference: The OpenVMS System Manager's Manual provides information about calculating and modifying these file sizes.
Site-specific utilities and data	Estimate the disk storage requirements for site-specific utilities, command procedures, online documents, and associated files.
Digital and third-party application programs	Estimate the space required for each Digital and third-party application product to be installed on your OpenVMS Cluster system, using information from the application suppliers. Reference: Consult the appropriate Software Product Description (SPD) to estimate the space required for normal operation of any layered product you need to use.
User-written programs	Estimate the space required for user-written programs and their associated databases.
Databases	Estimate the size of each database. This information should be available in the documentation pertaining to the application-specific database.
User data	Estimate user disk-space requirements according to these guidelines: Allocate from 10,000 to 100,000 blocks for each occasional user. An occasional user reads, writes, and deletes electronic mail; has few, if any, programs; and has little need to keep files for long periods. Allocate from 250,000 to 1,000,000 blocks for each moderate user. A moderate user uses the system extensively for electronic communications, keeps information on line, and has a few programs for private use. Allocate 1,000,000 to 3,000,000 blocks for each extensive user. An extensive user can require a significant amount of storage space for programs under development and data files, in addition to normal system use for electronic mail. This user may require several hundred thousand blocks of storage, depending on the number of projects and programs being developed and maintained.
Total requirements	The sum of the preceding estimates is the approximate amount of disk storage presently needed for your OpenVMS Cluster system configuration.

¹Storage capacity is measured in blocks. Each block contains 512 bytes.

5.2.2 Additional Disk Capacity Requirements

Before you finish determining your total disk capacity requirements, you may also want to consider future growth for online storage and for backup storage.

For example, at what rate are new files created in your OpenVMS Cluster system? By estimating this number and adding it to the total disk storage requirements that you calculated using Table 5-2, you can obtain a total that more accurately represents your current and future needs for online storage.

To determine backup storage requirements, consider how you deal with obsolete or archival data. In most storage subsystems, old files become unused while new files come into active use. Moving old files from online to backup storage on a regular basis frees online storage for new files and keeps online storage requirements under control.

Planning for adequate backup storage capacity can make archiving procedures more effective and reduce the capacity requirements for online storage.

5.3 Choosing Disk Performance Optimizers

Estimating your anticipated disk performance work load and analyzing the work load data can help you determine your disk performance requirements.

You can use the Monitor utility and DECamds to help you determine which performance optimizer best meets your application and business needs.

5.3.1 Performance Optimizers

Performance optimizers are software or hardware products that improve storage performance for applications and data. Table 5-3 explains how various performance optimizers work.

Table 5-3 Disk Performance Optimizers
Optimizer Description

DECram for OpenVMS A disk device driver that enables system managers to create logical disks in memory to improve I/O performance. Data on an in-memory DECram disk can be accessed at a faster rate than data on hardware disks. DECram disks are capable of being shadowed with Volume Shadowing for OpenVMS and of being served with the MSCP server.¹

Solid-state disks In many systems, approximately 80% of the I/O requests can demand information from approximately 20% of the data stored on line. Solid-state devices can yield the rapid access needed for this subset of the data.

Disk striping Disk striping (RAID level 0) lets applications access an array of disk drives in parallel for higher throughput. Disk striping works by grouping several disks into a "stripe set" and by dividing the application data into "chunks," which are spread equally across the disks in the stripe set in a round-robin fashion.
By reducing access time, disk striping may improve performance, especially if the application:

Performs large data transfers in parallel.
Requires load balancing across drives.

Digital offers two independent types of disk striping:

Controller-based striping, in which HSJ and HSD controllers combine several disks into a single stripe set. This stripe set is presented to OpenVMS as a single volume. This type of disk striping is hardware based.
Host-based striping, which creates stripe sets on an OpenVMS host. The OpenVMS software breaks up an I/O request into several simultaneous requests that it sends to the disks of the stripe set. This type of disk striping is software based.

Note: You can use Volume Shadowing for OpenVMS software in combination with disk striping to make stripe set members redundant. You can shadow controller-based stripe sets or you can host-based disk stripe shadow sets.

Virtual I/O cache (VIOC) OpenVMS offers host-based caching in the form of VIOC, a clusterwide, file-oriented disk cache. VIOC reduces I/O bottlenecks within OpenVMS Cluster systems by reducing the number of I/Os from the system to the disk subsystem.

Controllers with disk cache Some storage technologies use memory to form disk caches. Accesses that can be satisfied from the cache can be done almost immediately and without any seek time or rotational latency. For these accesses, the two largest components of the I/O response time are eliminated. The HSC, HSJ, HSD, and HSZ controllers contain caches. Every RF and RZ disk has a disk cache as part of its embedded controller.

**Table 5-3 Disk Performance Optimizers**
Optimizer	Description
DECram for OpenVMS	A disk device driver that enables system managers to create logical disks in memory to improve I/O performance. Data on an in-memory DECram disk can be accessed at a faster rate than data on hardware disks. DECram disks are capable of being shadowed with Volume Shadowing for OpenVMS and of being served with the MSCP server.¹
Solid-state disks	In many systems, approximately 80% of the I/O requests can demand information from approximately 20% of the data stored on line. Solid-state devices can yield the rapid access needed for this subset of the data.
Disk striping	Disk striping (RAID level 0) lets applications access an array of disk drives in parallel for higher throughput. Disk striping works by grouping several disks into a "stripe set" and by dividing the application data into "chunks," which are spread equally across the disks in the stripe set in a round-robin fashion. By reducing access time, disk striping may improve performance, especially if the application: Performs large data transfers in parallel. Requires load balancing across drives. Digital offers two independent types of disk striping: Controller-based striping, in which HSJ and HSD controllers combine several disks into a single stripe set. This stripe set is presented to OpenVMS as a single volume. This type of disk striping is hardware based. Host-based striping, which creates stripe sets on an OpenVMS host. The OpenVMS software breaks up an I/O request into several simultaneous requests that it sends to the disks of the stripe set. This type of disk striping is software based. Note: You can use Volume Shadowing for OpenVMS software in combination with disk striping to make stripe set members redundant. You can shadow controller-based stripe sets or you can host-based disk stripe shadow sets.
Virtual I/O cache (VIOC)	OpenVMS offers host-based caching in the form of VIOC, a clusterwide, file-oriented disk cache. VIOC reduces I/O bottlenecks within OpenVMS Cluster systems by reducing the number of I/Os from the system to the disk subsystem.
Controllers with disk cache	Some storage technologies use memory to form disk caches. Accesses that can be satisfied from the cache can be done almost immediately and without any seek time or rotational latency. For these accesses, the two largest components of the I/O response time are eliminated. The HSC, HSJ, HSD, and HSZ controllers contain caches. Every RF and RZ disk has a disk cache as part of its embedded controller.

¹The MSCP server makes locally connected disks to which it has direct access available to other systems in the OpenVMS Cluster.

Reference: See Section 7.8 for more information about how these performance optimizers increase an OpenVMS Cluster's ability to scale I/Os.

5.4 Determining Disk Availability Requirements

For storage subsystems, availability is determined by the availability of the storage device as well as the availability of the path to the device.

5.4.1 Availability Requirements

Some costs are associated with optimizing your storage subsystems for higher availability. Part of analyzing availability costs is weighing the cost of protecting data against the cost of unavailable data during failures. Depending on the nature of your business, the impact of storage subsystem failures may be low, moderate, or high.

Device and data availability options reduce and sometimes negate the impact of storage subsystem failures.

5.4.2 Device and Data Availability Optimizers

Depending on your availability requirements, choose among the availability optimizers described in Table 5-4 for applications and data with the greatest need.

Table 5-4 Storage Availability Optimizers
Availability Optimizer Description

Redundant access paths Protect against hardware failures along the path to the device by configuring redundant access paths to the data.

Volume Shadowing for OpenVMS software Replicates data written to a virtual disk by writing the data to one or more physically identical disks that form a shadow set. With replicated data, users can access data even when one disk becomes unavailable. If one shadow set member fails, the shadowing software removes the drive from the shadow set, and processing continues with the remaining drives. Shadowing is transparent to applications and allows data storage and delivery during media, disk, controller, and interconnect failure.
A shadow set can contain up to three members, and shadow set members can be anywhere within the storage subsystem of an OpenVMS Cluster system.
Reference: See Volume Shadowing for OpenVMS for more information about volume shadowing.

System disk redundancy Place system files judiciously on disk drives with multiple access paths. OpenVMS Cluster availability increases when you form a shadow set that includes the system disk. You can also configure an OpenVMS Cluster system with multiple system disks.
Reference: For more information, see Section 8.2.

Database redundancy Keep redundant copies of certain files or partitions of databases that are, for example, updated overnight by batch jobs. Rather than using shadow sets, which maintain a complete copy of the entire disk, it might be sufficient to maintain a backup copy on another disk or even on a standby tape of selected files or databases.

DECevent DECevent, in conjunction with volume shadowing, can detect most imminent device failures with sufficient lead time to move the data to a spare device.
Enhance device reliability with appropriate software tools. Use device-failure prediction tools, such as DECevent, where high availability is needed. When a shadow set member has an increasing fault rate that might indicate potential failure, DECevent works with Volume Shadowing for OpenVMS to make a shadow set copy of the suspect device to a spare device. After the copy is made, the suspect device can be taken off the system for examination and repair without loss of data availability.

Newer devices Protect against failure by choosing newer devices. Typically, newer devices provide improved reliability and mean time between failures (MTBF). Newer controllers also improve reliability by employing updated chip technologies.

Implement thorough backup strategies Frequent and regular backups are the most effective way to ensure the availability of your data.

**Table 5-4 Storage Availability Optimizers**
Availability Optimizer	Description
Redundant access paths	Protect against hardware failures along the path to the device by configuring redundant access paths to the data.
Volume Shadowing for OpenVMS software	Replicates data written to a virtual disk by writing the data to one or more physically identical disks that form a shadow set. With replicated data, users can access data even when one disk becomes unavailable. If one shadow set member fails, the shadowing software removes the drive from the shadow set, and processing continues with the remaining drives. Shadowing is transparent to applications and allows data storage and delivery during media, disk, controller, and interconnect failure. A shadow set can contain up to three members, and shadow set members can be anywhere within the storage subsystem of an OpenVMS Cluster system. Reference: See Volume Shadowing for OpenVMS for more information about volume shadowing.
System disk redundancy	Place system files judiciously on disk drives with multiple access paths. OpenVMS Cluster availability increases when you form a shadow set that includes the system disk. You can also configure an OpenVMS Cluster system with multiple system disks. Reference: For more information, see Section 8.2.
Database redundancy	Keep redundant copies of certain files or partitions of databases that are, for example, updated overnight by batch jobs. Rather than using shadow sets, which maintain a complete copy of the entire disk, it might be sufficient to maintain a backup copy on another disk or even on a standby tape of selected files or databases.
DECevent	DECevent, in conjunction with volume shadowing, can detect most imminent device failures with sufficient lead time to move the data to a spare device. Enhance device reliability with appropriate software tools. Use device-failure prediction tools, such as DECevent, where high availability is needed. When a shadow set member has an increasing fault rate that might indicate potential failure, DECevent works with Volume Shadowing for OpenVMS to make a shadow set copy of the suspect device to a spare device. After the copy is made, the suspect device can be taken off the system for examination and repair without loss of data availability.
Newer devices	Protect against failure by choosing newer devices. Typically, newer devices provide improved reliability and mean time between failures (MTBF). Newer controllers also improve reliability by employing updated chip technologies.
Implement thorough backup strategies	Frequent and regular backups are the most effective way to ensure the availability of your data.

5.5 CI Based Storage

The CI interconnect provides the highest OpenVMS Cluster availability with redundant, independent transmit-and-receive CI cable pairs. The CI offers multiple access paths to disks and tapes by means of dual-ported devices between HSC or HSJ controllers.

5.5.1 Supported Controllers and Devices

The following controllers and devices are supported by the CI interconnect:

HSJ storage controllers
- SCSI devices (RZ,TZ, EZ)
HSC storage controllers
- SDI and STI devices (RA, ESE, TA)
- K.SCSI devices (RZ, TZ, EZ)

5.6 DSSI Storage

DSSI-based configurations provide shared direct access to storage for systems with moderate storage capacity. The DSSI interconnect provides the lowest-cost shared access to storage in an OpenVMS Cluster.

The storage tables in this section may contain incomplete lists of products.

5.6.1 Supported Devices

DSSI configurations support the following devices:

EF-series solid-state disks
RF-series disks
TF-series tapes
DECarray storage arrays
HSD storage controller
- SCSI devices (RZ,TZ, EZ)

Reference: RZ, TZ, and EZ SCSI storage devices are described in Section 5.7.

5.7 SCSI-Based Storage

The Small Computer Systems Interface (SCSI) bus is a storage interconnect based on an ANSI industry standard. You can connect up to a total of 8 or 16 nodes (3 of which can be CPUs) to the SCSI bus.

5.7.1 Supported Devices

The following devices can connect to a single host or multihost SCSI bus:

RZ-series disks
HSZ storage controllers

The following devices can connect only to a single host SCSI bus:

EZ-series disks
RRD-series CD-ROMs
TZ-series tapes

5.8 Host-Based Storage

Host-based storage devices can be connected locally to OpenVMS Cluster member systems using local adapters. You can make this locally connected storage available to other OpenVMS Cluster members by configuring a node as an MSCP server.

  6318P003.HTM
  OSSG Documentation
  26-NOV-1996 11:20:13.49

Legal