HP HP-UX Workload Manager 9000 Servers LTU B8843CA#003 Prospecto
Los códigos de productos
B8843CA#003
Pooling temporary capacity
Pooling temporary capacity
Pooling temporary capacity
Pooling temporary capacity
GiCAP also pools temporary capacity automatically. The user can not manually transfer Temporary Capacity to a specific system –
temporary capacity is first consumed on the local system and then if required, it is consumed from other systems in the group.
GiCAP also pools temporary capacity automatically. The user can not manually transfer Temporary Capacity to a specific system –
temporary capacity is first consumed on the local system and then if required, it is consumed from other systems in the group.
When a complex is consuming temporary capacity, the iCAP daemon will periodically contact the Group Manager to determine if
there are available core usage rights on other group members. If no such usage rights are available, temporary capacity will
continue to be consumed. If usage rights are available anywhere in the group, they will be transferred to the complex using
temporary capacity in order to stop temporary capacity consumption on that complex.
there are available core usage rights on other group members. If no such usage rights are available, temporary capacity will
continue to be consumed. If usage rights are available anywhere in the group, they will be transferred to the complex using
temporary capacity in order to stop temporary capacity consumption on that complex.
Using GiCAP for high availability
Using GiCAP for high availability
Using GiCAP for high availability
Using GiCAP for high availability
GiCAP can be used in several ways to provide cost effective high availability and disaster recovery solutions.
GiCAP can be used in several ways to provide cost effective high availability and disaster recovery solutions.
In the simplest variation, a GiCAP Group can be created that includes two types of members: servers to run primary processing tasks
and servers that provide failover processing. Both types of servers can contain Instant Capacity components for the most economical
solution. When a failure occurs or planned downtime is required on a partition in one of the active servers, GiCAP can be used to
extract processor core usage rights from that partition and transfer those usage rights to one or more of the adoptive failover servers.
Those transferred usage rights can then be used to activate additional processor cores on the failover servers in order to increase
capacity during a failover situation. GiCAP also enables moving capacity from one server partition to another server.
and servers that provide failover processing. Both types of servers can contain Instant Capacity components for the most economical
solution. When a failure occurs or planned downtime is required on a partition in one of the active servers, GiCAP can be used to
extract processor core usage rights from that partition and transfer those usage rights to one or more of the adoptive failover servers.
Those transferred usage rights can then be used to activate additional processor cores on the failover servers in order to increase
capacity during a failover situation. GiCAP also enables moving capacity from one server partition to another server.
GiCAP can also be used to move capacity from one or more non production servers, such as test servers, during a failover situation.
A set of standby servers which are part of a GiCAP Group can pool their resources to provide failover capability.
A set of standby servers which are part of a GiCAP Group can pool their resources to provide failover capability.
GiCAP in combination with TiCAP can be used in a similar scenario involving a set of non-production servers. Some of those servers
may be provisioned with TiCAP (perhaps for use during peak production times) and can contribute this TiCAP to the rest of the group
for use during a failover situation.
may be provisioned with TiCAP (perhaps for use during peak production times) and can contribute this TiCAP to the rest of the group
for use during a failover situation.
Systems with full usage rights can also be part of a GiCAP group and can be used as "donor" systems, contributing usage rights to
the group and allowing additional activations on member systems with iCAP components.
the group and allowing additional activations on member systems with iCAP components.
Some important notes to consider when using GiCAP to design an HA or DR solution:
The Version 8 GiCAP command that extracts usage rights from a downed partition (icapmanage), with the release of GiCAP
DR, v8.02.01, supports failover scenarios in which an entire server as well as a single partition becomes unavailable.
While GiCAP enables migration of all types of usage rights between member servers (cores, cells, memory), extraction from a
failed server is only for core usage rights. Instant Capacity cellboards and memory should not be used for high availability or
disaster recovery scenarios.
There is no way to specify the number of core usage rights that are extracted. The software extracts the maximum number
possible, while ensuring that the partition can still be booted in a compliant mode, resulting in a partition with one core usage
right (such as one active core) for each active cell upon reboot of the server.
Usage rights are always extracted from the hard partition. If there are multiple virtual partitions or VM guests for the hard
partition, they will all be affected by the reduction of usage rights.
DR, v8.02.01, supports failover scenarios in which an entire server as well as a single partition becomes unavailable.
While GiCAP enables migration of all types of usage rights between member servers (cores, cells, memory), extraction from a
failed server is only for core usage rights. Instant Capacity cellboards and memory should not be used for high availability or
disaster recovery scenarios.
There is no way to specify the number of core usage rights that are extracted. The software extracts the maximum number
possible, while ensuring that the partition can still be booted in a compliant mode, resulting in a partition with one core usage
right (such as one active core) for each active cell upon reboot of the server.
Usage rights are always extracted from the hard partition. If there are multiple virtual partitions or VM guests for the hard
partition, they will all be affected by the reduction of usage rights.
In order to accomplish usage right extraction network connectivity must exist between the Group Manager and the intended failover
partition. If the Group Manager system is unavailable, it is not possible to transfer usage rights to a standby server. However, iCAP
version 9.x onwards supports the capability to have a standby group manager. If the primary group manager fails, GiCAP
operations can continue by activating the standby group manager.
partition. If the Group Manager system is unavailable, it is not possible to transfer usage rights to a standby server. However, iCAP
version 9.x onwards supports the capability to have a standby group manager. If the primary group manager fails, GiCAP
operations can continue by activating the standby group manager.
As with the other solutions, application startup time will be longer as compared to using a typical Serviceguard package control
script that does not invoke GiCAP commands. When using GiCAP, the time required to perform core activation in a GiCAP group
can range from seconds to minutes, depending on the size of the group and the hardware involved. The time to perform a core
usage rights extraction is less but has the same range generally.
script that does not invoke GiCAP commands. When using GiCAP, the time required to perform core activation in a GiCAP group
can range from seconds to minutes, depending on the size of the group and the hardware involved. The time to perform a core
usage rights extraction is less but has the same range generally.
QuickSpecs
Instant Capacity
Instant Capacity
Instant Capacity
Instant Capacity
Global Instant Capacity (GiCAP)
DA - 11723 Worldwide — Version 20 — February 1, 2010
Page 23