skip book previous and next navigation links
go up to top of book: HP OpenVMS Alpha Partitioning and Galaxy Guide HP OpenVMS Alpha Partitioning and Galaxy Guide
go to beginning of chapter: Managing Workloads With Partitions Managing Workloads With Partitions
go to previous page: Using Hard and Soft Partitions on OpenVMS Systems Using Hard and Soft Partitions on OpenVMS Systems
go to next page: Partitioning for the AlphaServer ES47/ES80/GS1280Partitioning for the AlphaServer ES47/ES80/GS1280
end of book navigation links

OpenVMS Partitioning Guidelines  



Hard partitioning is available only on AlphaServer ES47/ES80/GS1280 and GS80/160/320 systems. Using partitions on AlphaServer ES47/ES80/GS1280 systems is similar to using partitions on GS80/160/320 systems.

When deciding whether to use hard or soft partitions on AlphaServer ES or GS series systems, note the following:


NoteIn an OpenVMS Galaxy computing environment, MOP (Maintenance Operations Protocol) Booting is only supported on Instance 0.

Setup for partitions must follow setup rules.

For QBB-based systems, each partition (hard or soft) must have its own console line. Note that each QBB in the system can have one console line in it. Therefore, the maximum number of partitions (hard or soft) in the system equals the number of QBBs in the system.

Hard Partition Rules:

Each hard partition must have:

For maximum fault isolation and availability, ES47/ES80/GS1280 systems should be hard partitioned on system building block boundaries. For the ES47/ES80, this means on the 2P SBB boundary. For the GS1280, it is the 8P SBB boundary. When configured on system building block boundaries, hard partitions will have no single points of failure for the entire system. Power and cooling are self-contained within the hard partition. The interprocessor links will be turned off. This is the most robust form of partitioning. Note that a robust hard partition may contain multiple system building blocks.

For the GS1280 system, it is possible to hard partition the system building blocks into subsystem building blocks (SSBBs). An 8P SBB may be partitioned down to the 2P level. These hard partitions are separately powered and offer the ability to power off a dual-CPU module if needed for repair. This level of partitioning does not offer the fault isolation and robustness of a system that is partitioned on 8P SBB boundaries.

For hard partitions at the 8P or 2P SBB level, an individual serial console line per hard partition is supported. When an 8P SBB is subpartitioned into multiple hard partitions, the serial console can only connect to one subpartition at a time. If simultaneous access to all subpartition consoles is needed, then telnet sessions across the management LAN must be used. The section Process for Partition Setup describes the partition setup process, and the section Hard Partition Configuration Example illustrates configuration setup with two examples.


NoteRequired Console:

Hard partitioning capability on the ES47/ES80/GS1280 Series requires a minimum of the V6.6 console set, which is available at the AlphaServer firmware Web site:

http://ftp.digital.com/pub/Digital/Alpha/firmware/readme.html

Note that this Web site address is case sensitive.

Soft Partition Rules:

Each soft partition must have:

Process for Partition Setup  

The basic process for setting up hard and soft partitions at the Management Backplane Module (MBM or SCM) is the following:

  1. Create hard and soft partitions.
  2. Assign CPU, IO, and memory resources to the partitions.
  3. Power on CPUs and connect to consoles.
  4. Check and reset console environment variables if necessary.

This process is illustrated in Partitioning Sequence.

 

Figure 1  Partitioning Sequence  
Partitioning sequence

Physical hardware and ownership relationships are represented as branches of a single configuration tree in each system. Partitions, both hard and soft, can be thought of as ownership containers representing the accessibility and visibility of all resources in the configuration.The top level configuration branch shown in System Configuration Tree includes both the hardware and software configuration trees.

 

Figure 2  System Configuration Tree  
System config tree

In the hardware configuration tree shown in Hardware Configuration Tree, the physical nature of the box is delimited. Each bullet or filled circle represents a node in the tree (where node is not an individual computer but a point of connection in the tree). From the hardware root the tree divides to the building blocks, and within each building block to the major system categories such as memory, input/output, and CPU. At a lower level in the configuration tree, within I/O, for example, the tree branches to individual devices on the system, and so on. Each node in the tree has a definition that includes its parent, its siblings, its children, and its ownership.

 

Figure 3  Hardware Configuration Tree  
Hardware Configuration Tree

The scope of a partition is always on a branch, up or down, but never across branches. A soft partition, as shown in Software Configuration Tree, always looks up its tree for potentially available resources. The hard partition owns assigned resources that are available to all nodes below it.

In general, resources that are in use by a specific instance of an operating system are owned by the soft partition that represents that partition in the configuration tree. The cooperative push model in effect with multiple instances in a hard partition dictates that resources owned by a given instance can only be given away, not taken. A resource owned by nodes further up the tree may be used cooperatively (for example, shared memory at the community level), assigned down the tree to a specific soft partition, or up the tree where it becomes available to potentially multiple soft partitions.

Direct assignment of resources between soft partitions is called migration; only CPUs can move between soft partitions. The migration partitioning feature is not specific to Galaxy: CPUs can be migrated from any soft partition to another in the same hard partition without direct communication between them. All management of CPU resources is initiated with OpenVMS DCL SET/STOP CPU commands.


NoteMigration Restriction for ES47/ES80/GS1280 Systems:
You cannot migrate a CPU that has attached IO. To check if there is attached IO, either check the physical configuration for a hose attached to a CPU, or use the MBM show partition output: in the IOPs section, a CPU with attached IO has a dashed line; the CPU ID is the corresponding PID in the CPUs section of the show partition output. ( Hard Partition Configuration Example for an example.)

 

Figure 4  Software Configuration Tree
  

Software Configuration Tree


go to previous page: Using Hard and Soft Partitions on OpenVMS Systems Using Hard and Soft Partitions on OpenVMS Systems
go to next page: Partitioning for the AlphaServer ES47/ES80/GS1280Partitioning for the AlphaServer ES47/ES80/GS1280