Updated: 11 December 1998

OpenVMS Alpha Galaxy Guide

An evolution in OpenVMS functionality, OpenVMS Galaxy leverages proven OpenVMS Cluster, symmetric multiprocessing, and performance capabilities to offer greater levels of performance, scalability, and availability with extremely flexible operational capabilities.

Clustering

Fifteen years of proven OpenVMS Cluster technology facilitates communication among clustered instances within an OpenVMS Galaxy.

An OpenVMS Cluster is a software concept. It is a set of coordinated OpenVMS operating systems, one per computer, communicating over various communications media to combine the processing power and storage capacity of multiple computers into a single, shared-everything environment.

An OpenVMS Galaxy is also a software concept. However, it is a set of coordinated OpenVMS operating systems, in a single computer, communicating through shared memory. An instance of the operating system in an OpenVMS Galaxy can be clustered with other instances within the Galaxy or with instances in other systems.

An OpenVMS Galaxy is a complete system in and of itself. Although an OpenVMS Galaxy can be added to an existing cluster as multiple cluster nodes can be added today, the single system is the OpenVMS Galaxy architecture focus. An application running totally within an OpenVMS Galaxy can take advantage of performance opportunities not present in multisystem clusters.

SMP

Any instance in an OpenVMS Galaxy can be an SMP configuration. The number of CPUs is part of the definition of an instance. Because an instance in the OpenVMS Galaxy is a complete OpenVMS operating system, all applications behave the same as they would on a traditional, single-instance computer.

CPU reassignment

A CPU can be dynamically reassigned from one instance to another while all applications on both instances continue to run. Reassignment is realized by three separate functions: stopping, reassigning, and starting the CPU in question. As resource needs of applications change, the CPUs can be reassigned to the appropriate instances. There are some restrictions; for example, the primary CPU in an instance cannot be reassigned, and a CPU cannot specifically be designated to handle certain interrupts.

Dynamic Reconfiguration

Multiple instances of the OpenVMS operating system allow system managers to reassign processing power to the instances whose applications most need it. As that need varies over time, so can the configuration. OpenVMS allows dynamic reconfiguration while all instances and their applications continue to run.

2.5 OpenVMS Galaxy Benefits

Many of the the benefits of OpenVMS Galaxy technology result directly from running multiple instances of the OpenVMS operating system in a single computer.

With several instances of OpenVMS in memory at the same time, an OpenVMS Galaxy computing environment gives you quantum improvements in:

• Compatibility---Existing applications run without changes.
• Availability---Presents opportunities to upgrade software and expand system capacity without down time.
• Scalability---Offers scaling alternatives that improve performance of SMP and cluster environments.
• Adaptability---Physical resources can be dynamically reassigned to meet changing workload demands.
• Cost of ownership---Fewer computer systems reduce system management requirements, floor space, and more.

The following descriptions provide more details about these benefits.

Compatibility

Existing single-system applications will run without changes on instances in an OpenVMS Galaxy. Existing OpenVMS Cluster applications will also run without changes on clustered instances in an OpenVMS Galaxy.

Availability

An OpenVMS Galaxy system is more available than a traditional, single-system-view, SMP system because multiple instances of the operating system control hardware resources.

OpenVMS Galaxy allows you to run different versions of OpenVMS (Version 7.2 and later) simultaneously. For example, you can test a new version of the operating system or an application in one instance while continuing to run the current version the other instances. You can then upgrade your entire system, one instance at a time.

Scalability

System managers can assign resources to match application requirements as business needs grow or change. When a CPU is added to a Galaxy configuration, it can be assigned to any instance of OpenVMS. This means that applications can realize 100 % of a CPU's power.

Typical SMP scaling issues do not restrict an OpenVMS Galaxy. System managers can define the number of OpenVMS instances, assign the number of CPUs in each instance, and control how they are used.

Additionally, a trial-and-error method of evaluating resources is a viable strategy. System managers can reassign CPUs among instances of OpenVMS until the most effective combination of resources is found. All instances of OpenVMS and their applications continue to run while CPUs are reassigned.

Adaptability

An OpenVMS Galaxy is highly adaptable because computing resources can be dynamically reassigned to other instances of the operating system while all applications continue to run.

Reassigning CPUs best demonstrates the adaptive capability of an OpenVMS Galaxy computing environment. For example, if a system manager knows that resource demands change at certain times, the system manager can write a command procedure to reassign CPUs to other instances of OpenVMS and submit the procdure to a batch queue. The same could be done to manage system load characteristics.

In an OpenVMS Galaxy environment, software is in total control of assigning and dynamically reassigning hardware resources. As additional hardware is added to an OpenVMS Galaxy system, resources can be added to existing instances; or new instances can be defined without affecting running applications.

Cost of ownership

An OpenVMS Galaxy presents opportunities to upgrade existing computers and expand their capacity, or to replace some number of computers, whether they are cluster members or independent systems, with a single computer running multiple instances of the operating system. Fewer computers greatly reduces system management requirements as well as floor space.

Performance

An OpenVMS Galaxy can provide high commercial application performance by eliminating many SMP and cluster-scaling bottlenecks. Also, the distribution of interrupts across instances provides many I/O configuration possibilities; for example, a system's I/O workload can be partitioned so that certain I/O traffic is done on specific instances.

2.6 OpenVMS Galaxy Version 1.0 Features

With OpenVMS Alpha Version 7.2, you can create an OpenVMS Galaxy environment that allows you to:

• Run three instances of OpenVMS on an AlphaServer 8400
• Run two instances of OpenVMS on an AlphaServer 8200
• Run two instances of OpenVMS on an AlphaServer 4100
• Reassign CPUs between instances
• Perform independent booting and shutdown of instances
• Use shared memory for communication between instances
• Cluster instances within an OpenVMS Galaxy using the shared memory cluster interconnect
• Cluster instances with non-Galaxy systems
• Create applications using OpenVMS Galaxy APIs for resource management, event notification, locking for synchronization, and shared memory for global sections
• Use the Galaxy Configuration Utility to view and control the OpenVMS Galaxy environment
• Run a single-instance OpenVMS Galaxy on any Alpha system for application development

This chapter describes the things you need to consider to make sure that you create the OpenVMS Galaxy configuration that is best for your business and for your computing environmnet.

3.1 Is an OpenVMS Galaxy for You?

For companies looking to improve their ability to manage unpredictable, variable, or growing IT workloads, OpenVMS Galaxy technology provides the most flexible way to dynamically reconfigure and manage system resources. An integrated hardware and software solution, OpenVMS Galaxy allows system managers to perform tasks such as reassigning individual CPUs through a simple drag and drop procedure.

An OpenVMS Galaxy computing environment is ideal for high-availability applications, such as:

• Database servers
• Transaction processing systems
• Data Warehousing
• Data Mining
• Internet servers

An OpenVMS Galaxy computing environment is a natural evolution for current OpenVMS users with clusters or multiple sparsely configured systems.

An OpenVMS Galaxy is attractive for growing organizations with varying workloads---predictable or unpredictable.

3.3 Possible OpenVMS Galaxy Configurations

An OpenVMS Galaxy computing environment lets customers decide how much cooperation exists between instances in a single computer system.

In a shared-nothing computing model, the instances do not share any resources; operations are isolated from one another.

In a shared-partial computing model, the instances share some resources and cooperate in a limited way.

In a shared-everything model, the instances cooperate fully and share all available resources, to the point where the operating system presents a single cohesive entity to the network.

3.3.1 Shared-Nothing Computing Model

With APMP, all available memory is allocated into private memory for each instance of OpenVMS. Each instance has its own set of CPUs and an appropriate amount of I/O resources assigned to it.

Figure 3-1 Shared-Nothing Computing Model

In a shared-partial configuration (shown in Figure 3-2), a portion of system memory is designated as shared memory, which each instance can access. Code and data for each instance are contained in private memory. Data that is shared by applications in several instances is stored in shared memory.

The instances are not clustered.

Figure 3-2 Shared-Partial Computing Model

3.3.3 Shared-Everything Computing Model

Figure 3-3 Shared-Everything Computing Model

A single-instance Galaxy is for non-Galaxy platforms, that is, those without a Galaxy console. Galaxy configuration data, which is normally provided by console firmware, is instead, created in a file. By setting the system parameter GALAXY to 1, SYSBOOT reads the file into memory and the system boots as a single-instance Galaxy, complete with shared memory, Galaxy system services, and even self-migration of CPUs. This can be done on any Alpha platform.

Single-instance Galaxy configurations will run on everything from laptops to mainframes. This capability allows early adopters to evaluate OpenVMS Galaxy features, and most importantly, to develop and test Galaxy-aware applications without incurring the expense of setting up a full-scale Galaxy platform.

Because the single-instance Galaxy is not an emulator---it is real Galaxy code---applications will run on multi-instance configurations.

For more information about running a single-instance Galaxy, see Chapter 8.

3.5 Using the OpenVMS Configuration Calculator

The OpenVMS Galaxy Configuration Calculator (Galculator) is an application program you can use to determine the Galaxy configuration that best suits your needs. The Galculator also contains hardware illustrations. It is available at:
http://www.openvms.digital.com

To create an OpenVMS Galaxy Version 7.2 computing environment on an AlphaServer 8400 or 8200 system, the Galculator steps you through the following hardware requirements:

• One I/O module (I/O module of type KFTIA or KFTHA) for each partition.
• At least one processor module for each partition.
• A dedicated serial console port for each partition.
  The AlphaServer 8400 provides a built-in UART for the first console line. Each additional console requires a module set.
  The only hardware required for Galaxy operation that is not in the typical AlphaServer 8400 configuration is the KFE72-DA console subsystem.
  The KFE72-DA module set is the set of EISA bus modules that establish a console port.
• A display device for the OpenVMS Galaxy Configuration Utility.
  Compaq recommends an Alpha or VAX workstation running DECwindows or a Windows NT workstation with an Xterminal emulator. For more information about the OpenVMS Galaxy Configuration Utility, see Chapter 10.

OpenVMS V7.2 customers might want to use the following optional hardware:

• Plug-in units (PIUs) for I/O expansion from an I/O module (PCI or XMI)
• I/O adapters for network, storage, or traditional cluster interconnects
• Additional CPUs

The following is a sample display from the OpenVMS Galculator:

Compaq Computer Corporation OpenVMS Galaxy System Configuration 2-instance AlphaServer 8400 Galaxy Parts List ______________________________________________________________________ REQUIRED HARDWARE: Notes: 1) The following parts list should be compared against the base system parts list to determine if the parts already exist, or need to be ordered. 2) This parts list covers only the parts required to transform an existing system into a Galaxy configuration. Although we have tried to be complete, there is no substitute for the official options catalog. CONSOLE SUBSYSTEMS and PCI CARD-CAGES 1 KFE72-DA Console Subsystems (3 module set). 1 DWLPB-AA/BA PCI/EISA card-cages. Notes: 1) Use DWLPB-AA (dual PCI card-cage, back-side) for PCI/EISA options. 2) Use DWLPB-BA (single PCI card-cage, front or back) for PCI expansion. 3) Each KFE72-DA contains 1 on-board Ethernet port, 2 serial line ports, and 1 floppy disk port. 4) The KFE72-DA module set must be placed in the bottom-most card-cage slots. I/O PROCESSOR MODULES 1 KFTHA-AA 4-Hose I/O Processor Modules. 1 KFTIA-AA 1-Hose I/O Processor Modules. Notes: 1) If you use both KFTIA and KFTHA modules, a KFTIA must be placed in slot 9. The remaining I/O modules can be placed in any order as long as you configure consecutive slots in descending order (slots 9,8,7,6). 2) If you intend to use an XMI subsystem, it must be cabled into a KFTIA in system slot 9. PROCESSOR MODULES 5 756P1-AX Processor Modules. Notes: 1) A number of different speed processors available are available. The 756P1-AX is a dual 440mhz module. You can use whichever speed processors you choose as long as all processors are the same speed. 2) After installing the processors, be sure to upgrade to the proper Galaxy Console Firmware. (LFU> Update KN7C*). MISCELLANEOUS PARTS In addition to the above parts, consider the following parts to help you organize and manage your Galaxy system. 1) A Terminal-Server (for example, DECserver200 or 900, etc.) to organize your console serial lines. Having reverse-LAT access to your consoles is helpful. 2) An Ethernet HUB to manage your Ethernet connections. 3) A suitable workstation for using the OpenVMS Galaxy Configuration Utility. 4) Refer to the OpenVMS Galaxy Guide for more information. MEMORY MODULES 1 MS7CC-EA (1GB) Memory Modules. 1 MS7CC-GA (4GB) Memory Modules. SYSTEM CAPACITY AS SPECIFIED: 1) There are 10 processors of which 8 can be migrated. 2) There are 5 I/O Hoses available for PCI and XMI. 3) There are 57 possible PCI devices if all hoses are used. 4) There are 2 KFTIA I/O modules. Each contains 2 Ethernet Ports, 4 SCSI Ports, and 1 optional FDDI port. Remember that only the instance owning the I/O modules can access these ports.

3.6 CD Drive Recomendation

Compaq recommends that a CD drive be available for each instance in an OpenVMS Galaxy computing environment. A single CD drive ships as part of each AlphaServer 8400, 8200, and 4100 system. If you plan to use multiple system disks in your OpenVMS Galaxy, a CD drive per instance will be very helpful for upgrades and software installations.

If your OpenVMS Galaxy instances are clustered together and use a single common system disk, a single CD drive may be sufficient because the CD drive can be served to the other clustered instances. For operating system upgrades, the instance with the attached CD drive can be used to perform the upgrade.

3.7 Important Cluster Information

This section contains information that will be important to you if you are clustering instances with other instances in an OpenVMS Galaxy computing environment or with non-Galaxy OpenVMS Clusters.

For information about OpenVMS Galaxy licensing requirements that apply to clustering instances, see Chapter 4.

3.7.1 Becoming an OpenVMS Galaxy Instance

When you are installing OpenVMS Alpha Version 7.2, the OpenVMS installation dialog asks questions about OpenVMS Cluster and OpenVMS Galaxy instances.

If you answered "Yes" to the question

Will this system be a member of a VMScluster? (Yes/No)

And you answered "Yes" to the question

Will this sytem be an instance in an OpenVMS Galaxy? (Yes/No)

the following information is displayed:

For compatibility with an OpenVMS Galaxy, any systems in the VMScluster which are running versions of OpenVMS prior to V7.1-2 must have a remedial kit installed. The appropriate kit from the following list must be installed on all system disks used by these systems. (Later versions of these remedial kits may be used if available.) Alpha V7.1 and V7.1-1xx ALPSYSB02_071 Alpha V6.2 and V6.2-1xx ALPSYSB02_062 VAX V7.1 VAXSYSB01_071 VAX V6.2 VAXSYSB01_062

For more information, see OpenVMS Alpha Installation and Upgrade Manual.

3.7.2 SCSI Cluster Considerations

This section summarizes information about SCSI device naming for OpenVMS Galaxy computing environments. For more complete information about OpenVMS Cluster device naming, see the OpenVMS Cluster Systems.

If you are creating an OpenVMS Galaxy with shared SCSI buses, you must note the following:

For OpenVMS to give the SCSI devices the same name on each instance correctly, you will likely need to use the device-naming feature of OpenVMS.

For example, assume that you have the following adapters on your system when you enter the SHOW CONFIG command:

PKA0 (embedded SCSI for CDROM) PKB0 (UltraSCSI controller KZPxxx) PKC0 (UltraSCSI controller)

When you make this system a two-instance Galaxy, your hardware looks like the following:

Instance 0 PKA0 (UltraSCSI controller) Instance 1 PKA0 (embedded SCSI for CDROM) PKB0 (UltraSCSI controller)

Your shared SCSI will be connected from PKA0 on instance 0 to PKB0 on instance 1.

If you INIT the system with the LP_COUNT environment variable set to 0, you will not be able to boot OpenVMS on the system unless the SYSGEN parameter STARTUP_P1 is set to MINIMUM.

This is because, with the LP_COUNT variable set to 0, you will now have PKB connected to PKC, and the SCSI device-naming that was set up for initializing with multiple partitions is not correct for initializing with the LP_COUNT variable set to 0.

During the device configuration that occurs during boot, OpenVMS will notice that PKA0 and PKB0 are connected together. OpenVMS expects that each device has the same allocation class and names, but in this case, they will not.

The device naming which was set up for the 2 instance Galaxy will not function correctly since the console naming of the controllers has changed.

3.8 Security Considerations in an OpenVMS Galaxy Computing Environment

OpenVMS Galaxy instances executing in a shared-everything cluster environment, in which all security database files are shared between all instances, automatically provide a consistent view of all Galaxy-related security profiles.

If you choose not to share all security database files throughout all Galaxy instances, a consistent security profile can only be achieved manually. Changes to an object's security profile must be followed by similar changes on all instances where this object can be accessed.

Because of the need to propagate changes manually, it is unlikely that such a configuration would ever be covered by a US C2 evaluation or by similar evaluations from other authorities. Organizations that require operating systems to have security evaluations should ensure that all instances in a single OpenVMS Galaxy belong to the same cluster.

Copyright © Compaq Computer Corporation 1998. All rights reserved. Legal

6512PRO_001.HTML