Document revision date: 19 July 1999

The Compaq Galaxy Software Architecture on OpenVMS Alpha lets you run multiple instances of OpenVMS in a single computer. You can dynamically reassign system resources, mapping compute power to applications on an as-needed basis---without having to reboot the computer.

This chapter describes OpenVMS Galaxy concepts and highlights the features available in OpenVMS Alpha Version 7.2--1.

2.1 A New Computing Model and a New Software Architecture

Adaptive Partitioned Multiprocessing (APMP) is a new model of computing in which multiple instances of operating systems execute cooperatively in a single computer. With APMP, processors (and other physical resources) are partitioned in order to run multiple instances of operating systems.

APMP is another form of multiprocessor computing like symmetric multiprocessing (SMP) and massively parallel processing (MPP). For example, with two identical computers (the hardware is the same), one could run as an SMP system and the other could run as an APMP system.

The Galaxy Software Architecture is the complementary architecture that leverages Adaptive Partitioned Multiprocessing (APMP) capabilities. The Galaxy Architecture provides the software structure and operation components that fully exploit the APMP computing model.

2.2 The Galaxy Software Architecture on OpenVMS

Compaq's first implementation of the APMP model of computing is the Galaxy Software Architecture on OpenVMS, which uses APMP to execute multiple instances of OpenVMS in a single computer.

Software logically partitions CPUs, memory, and I/O ports by assigning them to individual instances of the OpenVMS operating system. This partitioning, which a system manager directs, is a software function; no hardware boundaries are required. Each individual instance has the resources it needs to execute independently. An OpenVMS Galaxy environment is adaptive in that resources such as CPUs can be dynamically reassigned to different instances of OpenVMS.

2.3 OpenVMS Galaxy Components and Concepts

The Galaxy Software Architecture on OpenVMS includes the following hardware and software components:

Console

The console on an OpenVMS system is comprised of an attached terminal and a firmware program that performs power-up self-tests, initializes hardware, initiates system booting, and performs I/O services during system booting and shutdown. The console program also provides run-time services to the operating system for console terminal I/O, environment variable retrieval, NVRAM (nonvolatile random access memory) saving, and other miscellaneous services.

In an OpenVMS Galaxy computing environment, the console plays a critical role in partitioning hardware resources. It maintains the permanent configuration in NVRAM and the running configuration in memory. The console provides each instance of the OpenVMS operating system with a pointer to the running configuration data.

Shared memory

Memory is logically partitioned into private and shared sections. Each operating system instance has its own private memory; that is, no other instance maps those physical pages. Some of the shared memory is available for instances of OpenVMS to communicate with one another, and the rest of the shared memory is available for applications.

The Galaxy Software Architecture is prepared for a nonuniform memory access (NUMA) environment and, if necessary, will provide special services for such systems to achieve maximum application performance.

CPUs

In an OpenVMS Galaxy computing environment, CPUs can be reassigned between instances.

I/O

An OpenVMS Galaxy has a highly scalable I/O subsystem because there are multiple, primary CPUs in the system---one for each instance. Also, OpenVMS currently has features for distributing some I/O to secondary CPUs in an SMP system.

Independent instances

One or more OpenVMS instances can execute without sharing any resources in an OpenVMS Galaxy. An OpenVMS instance that does not share resources is called an independent instance.

An independent instance of OpenVMS does not participate in shared memory use. Neither the base operating system nor its applications access shared memory.

An OpenVMS Galaxy can consist solely of independent instances; such a system would resemble traditional mainframe-style partitioning.

2.3.1 APMP Concepts

Architecturally, APMP is based on an SMP hardware architecture. It assumes that CPU, memory, and I/O have full connectivity within the machine and that the memory is cache coherent. Each subsystem has full access to all other subsystems.

As shown in Figure 2-1, APMP then looks at the resources as if they were a pie. The various resources (CPUs, private memory, shared memory, and I/O) are arranged as concentric bands within the pie in a specific hierarchy. Shared memory is at the center.

Figure 2-1 APMP Diagram

APMP supports the ability to divide the pie into multiple slices, each of disparate size. Each slice, regardless of size, has access to all of shared memory. Furthermore, because software partitions the pie, you can vary the number and size of slices dynamically.

In summary, each slice of the pie is a separate and complete instance of the operating system. Each instance has some amount of dedicated private memory, a number of CPUs, and the necessary I/O. Each instance can see all of shared memory, which is where the application data resides. System resources can be reassigned between the instances of the operating system without rebooting.

2.3.2 Another APMP Picture

Another possible way to look at the APMP computing model is to think about how a system's resources could be divided.

For example, the overall sense of Figure 2-2 is that the proportion by which one resource is divided between instances is the proportion by which each of the other resources must be divided.

Figure 2-2 Another APMP Diagram

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 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.
• Performance---Eliminates many bottlenecks and provides more I/O configuration possibilities.

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 in 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 procedure 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 7.2--1 Features

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

• Run three instances of OpenVMS on AlphaServer GS140 or 8400 systems
• Run two instances of OpenVMS on AlphaServer GS60, GS60E, 8200, or 4100 systems
• 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 environment.

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
• NonStop eBusiness solutions

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 9.

3.5 OpenVMS Galaxy Configuration Considerations

When you plan to create an OpenVMS Galaxy computing environment, you need to make sure that you have the appropriate hardware for your configuration. General OpenVMS Galaxy configuration rules include:

• One or more CPUs per instance
• One or more I/O modules per instance
• Dedicated serial console port per instance
• Memory
  • Enough private memory for OpenVMS and applications
  • Enough shared memory for the shared memory cluster interconnect, global sections, and so on.
• Display for configuration management with either an Alpha or VAX workstation running DECwindows or a Windows NT workstation with an Xterminal emulator.

For more information about hardware-specific configuration requirements, see the chapter in this book specific to your hardware and Section 3.5.4.

3.5.1 XMI Bus Support

The XMI bus is supported only on the first instance (Instance 0) of a Galaxy configuration in an AlphaServer 8400 system.

Only one DWLM-AA XMI plug-in-unit subsystem cage for all XMI devices is supported on an AlphaServer 8400 system. Note that the DWLM-AA takes up quite a bit of space in the system because an I/O bulkhead is required on the back of the system to connect all XMI devices to the system. This allows only two additional DWLPB PCI plug-in units in the system.

3.5.2 Memory Granularity Restrictions

Private memory must start on a 64MB boundary.

Shared memory must start on an 8MB boundary.

All instances except the last must have a multiple of 64MB.

Incorrectly configuring memory will result in wasted memory.

3.5.3 EISA Bus Support

The EISA bus is supported only on the first instance (Instance 0) of a Galaxy configuration. Due to the design of all EISA options, they must always be on Instance 0 of the system. A KFE70 must be used in the first instance for any EISA devices in the Galaxy system.

All EISA devices must be on Instance 0. No EISA devices are supported on any other instance in a Galaxy system.

A KFE72-DA installed in other instances provides console connection only and cannot be used for other EISA devices.

3.5.4 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 and to make sure that you have the appropriate I/O modules, processor modules, and sufficient memory for your configuration. The Galculator also contains hardware illustrations. It is available at:
http://www.compaq.com/openvms

To create an OpenVMS Galaxy Version 7.2--1 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 11.

OpenVMS V7.2--1 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

For information about installing KFE72-DA console subsystem hardware for OpenVMS Galaxy configurations, see Chapter 6.

3.5.5 OpenVMS Galculator Display Example

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.

	privacy and legal statement
6512PRO_001.HTML