Updated: 11 December 1998 |
OpenVMS Alpha Galaxy Guide
Previous | Contents |
The Galaxy Configuration Utility (GCU) is a DECwindows Motif application that allows system managers to configure and manage an OpenVMS Galaxy system from a single workstation window.
Using the GCU, system managers can:
The GCU resides in the SYS$SYSTEM directory along with a small number of files containing configuration knowledge.
The GCU consists of the following files:
SYS$SYSTEM:GCU.EXE | GCU executable image |
SYS$MANAGER:GCU.DAT | Optional DECwindows resource file |
SYS$MANAGER:GALAXY.GCR | Galaxy Configuration Ruleset |
SYS$MANAGER:GCU$ACTIONS.COM | System management procedures |
SYS$MANAGER: xxx.GCM | User-defined configuration models |
SYS$HELP:GALAXY_GUIDE.DECW$BOOK | Online help in Bookreader form |
The GCU can be run from any Galaxy instance. If the system does not directly support graphics output, then the DECwindows display can be set to an external workstation or suitably configured PC. However, the GCU application itself must always run on the Galaxy system.
When the GCU is started, it loads any customizations found in its resource file (GCU.DAT); then it loads the Galaxy Configuration Ruleset (GALAXY.GCR). The ruleset file contains statements that determine the way the GCU displays the various system components, and includes rules that govern the ways in which users can interact with the configuration display. Users do not typically alter the ruleset file unless they are well versed in its structure or are directed to do so by a Compaq Services Engineer. After the GCU display becomes visible, the GCU determines whether the system is currently configured as an OpenVMS Galaxy or as a single-instance Galaxy on a non-Galaxy platform. If the system is configured as a Galaxy, the GCU displays the active Galaxy configuration model. The main observation window displays a hierarchical view of the Galaxy. If the system has not yet been configured as a Galaxy, the GCU prompts you as to whether or not to create a single-instance Galaxy. Note that the GCU can create a single-instance Galaxy on any Alpha system, but multiple-instance OpenVMS Galaxy environments are created by using console commands and console environment variables.
Once the Galaxy configuration model is displayed, users can either
interact with the active model or take the model off line and define
specific configurations for later use. The following sections discuss
these functions in greater detail.
10.1 GCU Tour
The GCU can perform three types of operations:
Most GCU operations are organized around the main observation window and its hierarchical display of Galaxy components. The observation window provides a porthole into a very large space. The observation window can be panned and zoomed as needed to observe part of or all of the entire Galaxy configuration. The main toolbar contains a set of buttons that control workspace zoom operations. Workspace panning is controlled by the horizontal and vertical scrollbars; workspace sliding is achieved by holding down the middle mouse button down as you drag the workspace around. This obviously assumes you have a three-button mouse.
The various GCU operations are invoked from pull down or popup menu functions. General operations such as opening and closing files, and invoking external tools, are accomplished using the main menu bar entries. Operations specific to individual Galaxy components are accomplished using popup menus that appear whenever you click the right mouse button on a component displayed in the observation window.
In response to many operations, the GCU displays additional dialog
boxes containing information, forms, editors, or prompts. Error and
information responses are displayed in popup dialog boxes or inside the
status bar along the bottom of the window, depending on the severity of
the error and importance of the message.
10.1.1 Creating Galaxy Configuration Models
You can use the GCU to create Galaxy configuration models and a single-instance Galaxy on any Alpha system.
When viewing the active Galaxy configuration model, direct manipulation of display objects (components) may alter the running configuration. For example, dragging a CPU from its current location and dropping it on top of a different instance component will invoke a management action procedure, that reassigns the selected CPU to the new instance. At certain times this may be a desirable operation; however, in other situations you might want to reconfigure your Galaxy all at once rather than component by component. To accomplish this, you must create an offline Galaxy configuration model.
To create a Galaxy configuration model, we must start with an existing model, typically the active one, alter it in some manner, and save it in a file.
Starting from the active Galaxy Configuration Model:
The reason for creating offline models is to allow significant
configuration changes to be automated. For example, you can create
models representing the desired Galaxy configuration at different times
and then engage the models interactively by following this procedure.
10.1.2 Observation
The GCU can display the single active Galaxy configuration model, or any number of offline Galaxy configuration models. Each loaded model appears as an item in the Model menu on the toolbar. You can switch between models by clicking the desired menu item.
The active model is always named GLX$ACTIVE.GCM. When the active model is first loaded, a file by this name will exist briefly as the system verifies the model with the system hardware.
When a model is visible, you can zoom, pan, or slide the display as needed to view Galaxy components. Use the buttons on the left side of the toolbar to control the zoom functions.
The zoom functions include:
Galactic zoom | Zoom to fit the entire component hierarchy into observation window. |
Zoom 1:1 | Zoom to the component normal scale. |
Zoom to region | Zoom to a selected region of the display. |
Zoom in | Zoom in by 10 percent. |
Zoom out | Zoom out by 10 percent. |
Panning is accomplished by using the vertical and horizontal
scrollbars. Sliding is done by pressing and holding the middle mouse
button and dragging (sliding) the cursor and the image.
10.1.2.1 Layout Management
The Automatic Layout feature manages the component layout. If you ever need to refresh the layout while in Automatic Layout mode, simply select the root (topmost) component.
To alter the current layout, select Manual Layout from the Windows menu. In Manual Layout Mode, you can freely drag and drop components however you like to generate a pleasing structure. Because each component is free from automatic layout constraints, you may need to invest some time in positioning each component, possibly on each of the charts. To make things simpler, you can click press the right mouse button on any component and select Layout Subtree to provide automatic layout assistance below that point in the hierarchy.
When you are satisfied with the layout, you must save the current model
in a file to retain the manual layout information. The custom layout is
used when the model is open. Note that if you select Auto Layout mode,
your manual layout will be lost for the in-memory model. Also, in order
for CPU components to reassign in a visually effective manner, they
must perform subtree layout operations below the instance level. For
this reason, it is best to limit any manual layout operations to the
instance and community levels of the component hierarchy.
10.1.2.2 OpenVMS Galaxy Charts
The GCU provides six distinct subsets of the model, known as charts.
The six charts include:
Chart name | Shows |
---|---|
Logical Structure | Dynamic resource assignments |
Physical Structure | Nonvolatile hardware relationships |
CPU Assignment | Simplified view of CPU assignments |
Memory Assignment | Memory subsystem components |
IOP Assignment | I/O module relationships |
Failover Targets | Processor failover assignments |
These charts result from enabling or disabling the display of various component types to provide views of sensible subsets of components.
Specific charts may offer functionality that can be provided only for that chart type. For example, reassignment of CPUs requires that the instance components be visible. Because instances are not visible in the Physical Structure or Memory Assignment charts, you can reassign CPUs only in the Logical Structure and CPU Assignment charts.
For more information about charts, refer to Section 10.4.
10.1.3 Interaction
When viewing the active Galaxy configuration model, you can interact directly with the system components. For example, to reassign a CPU from one instance to another, you can drag and drop a CPU onto the desired instance. The GCU will validate the operation and execute an external command action to make the configuration change. Interacting with a model that is not engaged, is simply a drawing operation on the offline model, and has no impact to the running system.
While interacting with Galaxy components, the GCU applies built-in and user-defined rules that prevent misconfiguration and improper management actions. For example, you cannot reassign primary CPUs, and you cannot reassign a CPU to any component other than a Galaxy instance. Either operation would result in an error message on the status bar, and the model would return to its proper configuration. If the attempted operation violates one of the configuration rules, the error message, displayed in red on the status bar, will describe the rule that fired.
You can view details for any selected component by clicking the right mouse button and either selecting the Parameters item from the popup menu or by selecting Parameters from the Components menu on the main toolbar.
The GCU can shut down or reboot one or more Galaxy instances using the
Shutdown or Reboot items on the Galaxy menu. The various shutdown or
reboot parameters can be entered in the Shutdown dialog box. Be sure to
specify the CLUSTER_SHUTDOWN option to fully shut down clustered Galaxy
instances. The Shutdown dialog box allows you to select any combination
of instances, or all instances. The GCU is "smart" enough to
shut down its owner instance last.
10.2 Managing an OpenVMS Galaxy with the GCU
Your ability to manage a Galaxy system using the Galaxy Configuration Utility (GCU) depends on the capabilities of each instance involved in a management operation.
The GCU can be run from any instance in the Galaxy. However, the Galaxy Software Architecture implements a push-model for resource reassignment. This means that, in order to reassign a processor, you must execute the reassign command function on the instance that currently owns the processor. The GCU is aware of this requirement, and will attempt to use one or more communications paths to send the reassignment request to the owner instance. DCL is not inherently aware of this requirement; therefore, if you use DCL to reassign resources, you will need to use SYSMAN or a separately logged-in terminal to issue the commands on the owner instance.
The GCU favors using SYSMAN, and its underlying SMI_Server processes to provide command paths to the other instances in the Galaxy. However, the SMI_Server requires that the instances be in a cluster so that the command environment falls within a common security domain. However, Galaxy instances might not be clustered.
If the system cannot provide a suitable command path for the SMI_Server
to use, the GCU will attempt to use DECnet task-to-task communications.
This requires that the participating instances be running DECnet, and
that each participating Galaxy instance have a proxy set up for the
SYSTEM account.
10.2.1 Independent Instances
You can define a Galaxy system so that one or more instances are not members of the Galaxy sharing community. These are known as independent instances, and they are visible to the GCU.
These independent instances can still participate in CPU reassignment.
They cannot utilize shared memory or related services.
10.2.2 Isolated Instances
It is possible for an instance to not be clustered, have no proxy
account established, and not have DECnet capability. These are known as
isolated instances. They are visible to the GCU, and
you can reassign CPUs to them. The only way to reassign resources from
an isolated instance is from the console of the isolated instance.
10.2.3 Required PROXY Access
When the GCU needs to execute a management action, it always attempts to use the SYSMAN utility first. SYSMAN requires that the involved instances be in the same cluster. If this is not the case, the GCU will next attempt to use DECnet task-to-task communications. For this to work, the involved instances must each have an Ethernet device, DECnet capability, and suitable proxy access on the target instance.
For example, consider a two-instance configuration that is not clustered. If instance 0 were running the GCU and the user attempts to reassign a CPU from instance 1 to instance 0, the actual reassignment command must be executed on instance 1. To do this, the GCU's action procedures in the file SYS$MANAGER:GCU$ACTIONS.COM will attempt to establish a DECnet task-to-task connection to the SYSTEM account on instance 1. This requires that instance 1 has granted proxy access to the SYSTEM account of instance 0. Using the established connection, the action procedure on instance 0 will pass its parameters to the equivalent action procedure on instance 1, which now treats the operation as a local operation.
The GCU action procedures assume that they will be used by the system manager. Thus, in the action procedure file SYS$MANAGER:GCU$ACTIONS.COM, the SYSTEM account is used. To grant access to the opposite instances SYSTEM account, the proxy must be set up on instance 1.
To establish proxy access:
$ SET DEFAULT SYS$SYSTEM $ RUN AUTHORIZE |
UAF> CREATE/PROXY UAF> ADD PROXY instance::SYSTEM SYSTEM UAF> EXIT |
Replace instance with the name of the instance to which you are granting access. Perform these steps for each of the instances you want to manage from the instance on which you run the GCU. For example, in a typical two-instance Galaxy, if you run the GCU only on instance 0, then you need to add proxy access only on instance 1 for instance 0. If you intend to run the GCU on instance 1 also, then you need to add proxy access on instance 0 for instance 1. In three-instance Galaxy systems, you may need to add proxy access for each combination of instances you want to control. For this reason, a good rule of thumb is to always run the GCU from instance 0.
You are not required to use the SYSTEM account. To change the account, you need to edit SYS$MANAGER:GCU$ACTIONS.COM on each involved instance. Locate the line that establishes the task-to-task connection, and replace the SYSTEM account name with one of your choosing.
Note that the selected account must have OPER, SYSPRV, and CMKRNL
privileges. You also need to add the necessary proxy access to your
instances for this account.
10.3 Galaxy Configuration Models
The GCU is a fully programmable display engine. It uses a set of rules to learn the desired characteristics and interactive behaviors of the system components. Using this specialized configuration knowledge, the GCU assembles models that represent the relationships among system components. The GCU obtains information about the current system structure by parsing a configuration structure built by the console firmware. This structure, called the Galaxy Configuration File, is stored in memory and is updated as needed by firmware and by OpenVMS executive routines to ensure that it accurately reflects the current system configuration and state.
The GCU converts and extends the binary representation of the configuration file into a simple ASCII representation, which it can store in a file as an offline model. The GCU can later reload an offline model and alter the system configuration to match the model. Whether you are viewing the active model or an offline model, you are always free to save the current configuration as an offline Galaxy Configuration Model(.GCM)file.
To make an offline model drive the current system configuration, the model must be loaded and engaged. To engage a model, click the Engage button. The GCU will scan the current configuration file, compare it against the model, and create a list of any management actions that are required to engage the model. The GCU presents this list to you for final confirmation. If you approve, the GCU will execute the actions, and the model will become engaged to reflect the current system configuration and state.
When you disengage a model, the GCU immediately marks the CPUs and
instances as offline. You can then freely arrange the model however you
like, and either save the model, or reengage the model. In typical
practice, you are likely to have a small number of models, that have
proved to be useful for your business operations. These can be engaged
by a system manager or a suitably privileged user, or through DCL
command procedures.
10.3.1 Active Model
The GCU maintains a single active model. This model is always derived
from the in-memory configuration file. The configuration file can be
from a Galaxy console or from a file-based, single-instance Galaxy on
any Alpha system. Regardless of its source, console callbacks maintain
the integrity of the file. The GCU utilizes Galaxy event services to
determine when a configuration change has occurred. When a change
occurs, the GCU parses the configuration file and updates its active
model to reflect the current system. The active model is not saved to a
file unless you choose to save it as an offline model. Typically, the
active model becomes the basis for creating additional models. When
creating models, it is generally best to do so online so that you are
sure your offline models can engage when they are needed.
10.3.2 Offline Models
The GCU can load any number of offline Galaxy configuration models and freely switch among them, assuming they were created for the specific system hardware. The model representation is a simple ASCII data definition format.
You should never need to edit a model file in its ASCII form. The GCU
models and ruleset adhere to a simple proprietary language known as the
Galaxy Configuration Language (GCL). This language continues to evolve
as needed to represent new Galaxy innovations. Beware of this fact if
you decide to explore the model and ruleset files directly. If you
accidentally corrupt a model, you can always generate another. If you
corrupt the ruleset, you may need to download another from the OpenVMS
Galaxy website.
10.3.2.1 Example: Creating an Offline Model
To create an offline Galaxy configuration model:
To engage an offline model:
Previous | Next | Contents |
Copyright © Compaq Computer Corporation 1998. All rights reserved. Legal |
6512PRO_005.HTML
|