HP rp7405 HP-UX 11i v3 Dynamic nPartitions - Features and Configuration Recomm - Page 5

Scenarios for Dynamic nPartitions

Page 5 highlights

If a cell with I/O (an I/O chassis or core I/O or both) is online activated, then the I/O is also available to the partition. However, the I/O is not automatically activated: a separate command, olrad, is required to activate the I/O. The command for I/O chassis activation is olrad -A -s cell_hardware_path where the I/O chassis connected to the cell specified by cell_hardware_path is online activated. The cell_hardware_path must be a global slot number. A cell with I/O can be online deactivated, but, for the operation to succeed, the I/O must first have been deactivated using the olrad command. The deactivation of I/O is subject to Critical Resource Analysis (CRA). If the CRA detects usages on the chassis to be deactivated, they will be noted in the logs. The command for I/O chassis deactivation is olrad -D -s cell_hardware_path where the I/O chassis connected to the cell specified by cell_hardware_path is online deactivated. The cell_hardware_path must be a global slot number. The olrad command can also be used to perform OLA, OLD, and OLR for PCI cards. However, such operations are intended to be performed when the I/O chassis is active. Changing PCI cards when the I/O chassis is inactive requires a power cycle sequence of the associated cell before the I/O chassis can be activated again. For more information, see the manual pages for olrad. Scenarios for Dynamic nPartitions Scenarios showing the value of Dynamic nPartitions are described in this section. Many more cases are possible. Dynamic nPartitions functionality provides greater flexibility when more cells are in the system complex. A two-cell server does not allow a wide range of uses of Dynamic nPartitions. Accordingly, most examples are applicable to servers with four or more cells. Adding capacity to an nPartition Dynamic nPartitions functionality provides a means to add resources to an nPartition where the workload has increased beyond the original capacity of the partition. As long as the complex contains an unassigned cell, or a vacant slot into which a new cell can be inserted, the capacity of any nPartition can be increased with a cell online addition operation. Multiple cells can be added in succession, until all available cells in the entire complex are in use. Shifting floating capacity to meet demand peaks Dynamic nPartitions functionality is valuable when a server complex is divided into multiple partitions hosting application workloads that exhibit uncorrelated but predictable fluctuations in demand. The Dynamic nPartitions operations are fairly heavyweight, so the fluctuations must be of significant duration, a few hours or more. Different resource management tools are appropriate for workload spikes lasting only a few minutes or less. For example, one partition hosts an application that is extremely busy reconciling financial accounts at the end of the month, while another partition does intensive data mining at the beginning of the next month. Alternatively, seasonal variations are likely when supporting retail operations, or applications might see extremely high loads only during the income tax preparation season. Finally, if different partitions supported call centers in different time zones, there could be regular, daily workload variations. 5

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22

5
If a cell with I/O (an I/O chassis or core I/O or both) is online activated, then the I/O is also
available to the partition.
However, the I/O is not automatically activated: a separate command,
olrad
, is required to activate the I/O.
The command for I/O chassis activation is
olrad –A -s
cell_hardware_path
where the I/O chassis connected to the cell specified by
cell_hardware_path
is online activated.
The
cell_hardware_path
must
be a global slot number.
A cell with I/O can be online deactivated, but, for the operation to succeed, the I/O must first have
been deactivated using the
olrad
command. The deactivation of I/O is subject to Critical Resource
Analysis (CRA).
If the CRA detects usages on the chassis to be deactivated, they will be noted in the
logs.
The command for I/O chassis deactivation is
olrad –D -s
cell_hardware_path
where the I/O chassis connected to the cell specified by
cell_hardware_path
is online
deactivated.
The
cell_hardware_path
must
be a global slot number.
The olrad command can also be used to perform OLA, OLD, and OLR for PCI cards.
However, such
operations are intended to be performed when the I/O chassis is active.
Changing PCI cards when
the I/O chassis is inactive requires a power cycle sequence of the associated cell before the I/O
chassis can be activated again.
For more information, see the manual pages for
olrad
.
Scenarios for Dynamic nPartitions
Scenarios showing the value of Dynamic nPartitions are described in this section.
Many more cases
are possible.
Dynamic nPartitions functionality provides greater flexibility when more cells are in the system
complex.
A two-cell server does not allow a wide range of uses of Dynamic nPartitions.
Accordingly,
most examples are applicable to servers with four or more cells.
Adding capacity to an nPartition
Dynamic nPartitions functionality provides a means to add resources to an nPartition where the
workload has increased beyond the original capacity of the partition.
As long as the complex
contains an
unassigned cell
, or a vacant slot into which a new cell can be inserted, the capacity of
any nPartition can be increased with a
cell online addition
operation.
Multiple cells can be added in
succession, until all available cells in the entire complex are in use.
Shifting floating capacity to meet demand peaks
Dynamic nPartitions functionality is valuable when a server complex is divided into multiple partitions
hosting application workloads that exhibit uncorrelated but predictable fluctuations in demand.
The
Dynamic nPartitions operations are fairly heavyweight, so the fluctuations must be of significant
duration, a few hours or more.
Different resource management tools are appropriate for workload
spikes lasting only a few minutes or less.
For example, one partition hosts an application that is extremely busy reconciling financial accounts
at the end of the month, while another partition does intensive data mining at the beginning of the
next month.
Alternatively, seasonal variations are likely when supporting retail operations, or
applications might see extremely high loads only during the income tax preparation season.
Finally,
if different partitions supported call centers in different time zones, there could be regular, daily
workload variations.