Instant Capacity

HP Instant Capacity, or "iCAP," offers inactive processors and cell boards with memory at a fraction of the price of equivalent active components. The remainder of the active component purchase price, along with costs for software licenses and hardware and software support, are incurred only when the hardware is activated.

HP Instant Capacity consists of both a hardware and software component. Instant Capacity hardware is a small fixed percentage of the active component price, installed in the server but not used by the operating system. When the resource is needed, the Customer purchases the usage rights for the hardware. Once applied to the system, the Customer can then activate and use the component.

HP Instant Capacity Software, which is included with both HP-UX 11i and later and OpenVMS 8.3 and later, is responsible for activating and deactivating hardware and maintaining the system inventory stored in complex firmware. The system inventory maintains the number of usage rights owned by the system, which in turn is used to determine the maximum number of components that can be active.

The HP Instant Capacity portfolio includes:

• Instant Capacity for Processors
• Instant Capacity for Cell Boards with Memory
• Temporary Instant Capacity (TiCAP)
• Global Instant Capacity (GiCAP)

HP Instant Capacity allows Customers to pay for resources when they need them, and to move resources where they need them.

HP Instant Capacity hardware is a small portion of the active component price, and does not require software licenses or support while inactive. Therefore, the majority of hardware costs (as well as 100% of the associated software and support costs) is deferred until the resources are actually needed.

HP Instant Capacity is a fully Customer managed solution which requires no connection to HP or metering appliance on site. Some common benefits and applications of HP Instant Capacity are listed below.

• Simplify capacity planning. Plan IT procurements based on actual demand, not estimations.
• Eliminate over-provisioning. Size only for what you need today - Instant Capacity hardware can be activated permanently or temporarily depending on application demand.
• Consolidate with confidence. Instant Capacity allows resources to move as needed between partitions without any impact to production.
• Extend server lifespan. A server configured with active and Instant Capacity components has more potential to grow with the business and extends the upgrade path for your hardware.
• Minimize impacts of upgrades. Instant Capacity hardware reduces upgrades to a simple command with little to no downtime.
• Improve system availability. Instant Capacity processors automatically replace failed processors without a reboot, at no cost to the Customer.
• Handle fluctuating workloads cost-effectively. Active resources can be sized to meet average utilization, and short-term peaks can be met with Temporary Instant Capacity.
• Move resources where you need them, when you need them. Instant Capacity Software can be used to move usage rights between partitions, and now, with Global Instant Capacity, even between servers. By consolidating server resources, utilization of existing resources is optimized without incurring costs related to over-provisioning.
• Automate with the HP Virtual Server Environment. Instant Capacity is an integral part of the HP Virtual Server Environment and is compatible with all components of the HP VSE. For example, activation and deactivation of processors can be automated with Global Workload Manager to meet changing service level objectives.
• Implement cost-effective high availability and disaster tolerant solutions. Combinations of Instant Capacity, Temporary Instant Capacity and/or Global Instant Capacity can be used to implement cost-effective disaster tolerant environments that move your resources in the event of a failover.

Customers assume title for Instant Capacity hardware at time of purchase. HP Instant Capacity hardware is a small percentage of the active component purchase price, as shown below in Table 6.3.5.1. The "Right to Use" the hardware, which allows activation of the component, is the remaining percentage of the active component purchase price at time of activation, not at the time of original purchase of the iCAP hardware.

Architecture

There is no premium for HP's Instant Capacity program – at any given point in time, the price of the Instant Capacity Hardware plus the price of the Right to Use is always equal to the active purchase price. All Customers that participate in the HP Instant Capacity program must also sign the applicable Instant Capacity contract prior to placing an order.

HP Instant Capacity is based on the concept of hardware usage rights. Active hardware implicitly includes usage rights, whereas HP Instant Capacity Hardware does not. Without usage rights, the Instant Capacity Software will not allow the operating system to use the hardware. The usage rights for HP Instant Capacity Hardware are purchased separately and called the "Right to Use" or "RTU".
NOTE: All Instant Capacity Right to Use products must have either Option 02A or Option 0D1 selected. Select Option 02A when activating a component at the Customer's site, and select Option 0D1 to activate a component in the HP Factory. The quantity of the selected option must equal the quantity of the usage right ordered.

The product structure of Instant Capacity Hardware is identical to the equivalent active hardware. For example, if an active processor module contains a single dual-core processor, the Instant Capacity product will also contain a single dual-core processor.

Every Instant Capacity product has an associated Right to Use product which is the usage rights for that specific component. The Right to Use for an 8GB memory module for an rx8640 is a different product than the Right to Use for an 8GB memory module for an sx2000 Superdome. The number of usage rights needed to activate a component depends on the type of component. A cell board or a memory module each will require one Right to Use, but a dual-core Instant Capacity processor will require two (2) usage rights, one for each core on the module.
NOTE: The Right to Use products for all HP Instant Capacity processors activate a single unit only, where a unit is defined as a single processor core, cell board or memory module.

Usage rights are not tied to specific hardware components within an Instant Capacity system, and can in fact be transferred between identical hardware components. Deactivating a component results in the usage right for that component being released and made available for use by another component. The available usage right can then be used to activate an Instant Capacity component in another partition within the same complex. This powerful feature of the HP Instant Capacity Software allows Customers to move resources between partitions within a complex. Usage rights can also be transferred in this manner between servers using a new feature called Global Instant Capacity, described later.

A new feature included with HP Instant Capacity Software version 8.x or later allows Customers to deactivate active hardware. This means that a fully owned system, including one without any Instant Capacity components, can leverage the benefits of moving usage rights with Instant Capacity Software or test Instant Capacity functionality.

NOTE: When moving processor core usage rights between partitions either within the same server or on different servers, the Customer is responsible for ensuring they remain in compliance with their software licensing obligations.

HP Instant Capacity Software tracks the total number of expected inactive components in a protected location in firmware called the system inventory. The Instant Capacity Software ensures that the number of inactive components in the complex is always equal to (or greater than) the number of expected number of inactive components that is recorded in the system inventory.

In the image below, an rx7640 has been configured with 12 active processor cores and 4 Instant Capacity processor cores, distributed over two partitions. The system inventory in this system would indicate that at least 4 processor cores are expected to be inactive in the complex at any given time.

Application of an Instant Capacity Codeword modifies the system inventory on an Instant Capacity system. Since Instant Capacity systems do not communicate to HP, Codewords are used to modify the inventory when certain events occur, such as the activation of a component, or an add-on of Instant Capacity hardware. Instant Capacity Codewords are used to:

• add a usage right to a system, enabling an iCAP component to be subsequently activated,
• add Temporary Instant Capacity to a system,
• add Global Instant Capacity Sharing Rights to a GiCAP Group Manager,
• adjust the system inventory after the add-on of iCAP hardware,
• upgrade the iCAP Software, or
• upgrade system hardware (e.g. HP 9000 to HP Integrity, single core to dual core).

Application of a Right to Use Codeword will add another usage right to the system by adjusting the data held in the system inventory, at which time the Instant Capacity Software will allow an Instant Capacity component to be activated at the Customer's discretion. In the example rx7640 from the previous section, applying a Right to Use for one processor core would increase the data stored in system inventory from 4 to 3, meaning that at any given time, at least 3 cores had to be inactive in the complex.

Instant Capacity Codewords are downloaded by the Customer from an external web site called the Utility Pricing Solutions Portal, accessible at http://www.hp.com/go/icap/portal. Codewords are typically available on the Portal within 24 hours of an order being shipped. Some basic information such as the serial number of the system and the purchase order number are required in order to retrieve a Codeword. Upon retrieving the Codeword, the Customer may transfer the Codeword by any means they prefer to the Instant Capacity system, and apply the Codeword with a simple command. Application of a Codeword enables the Customer to then activate a component, use Temporary or Global Instant Capacity, and so on.

NOTE: Instant Capacity Customers are obligated to apply all Codewords to the system as requested by HP.

HP Instant Capacity processors and cell boards with memory modules are available for HP Integrity and HP 9000 Midrange and Superdome servers. The Instant Capacity Software is included with HP UX 11i version 1 or later and OpenVMS 8.3 or later.

Instant Capacity Processors do not include usage rights and therefore not used by the operating system. In the event that an active processor fails, an Instant Capacity processor will be activated to replace the failed processor immediately at no cost to the Customer. Depending on the nature of the failure, this may or may not require a reboot of the partition.

To permanently activate a processor core, the usage right for that core must be purchased and the Codeword downloaded from the Utility Pricing Solutions Portal and applied to the server.
NOTE: When activating a processor core, licenses for all per-core licensed software installed in the partition must also be purchased, as well as the associated hardware and software support.

NOTE: While ordering add-on iCAP processors it is mandatory to order the iCAP startup and installation service (HA114A1 option 551).

Instant Capacity processors can also be activated temporarily using Temporary Instant Capacity, described later.

This included temporary capacity is called "Instant Access Capacity" or "IAC", and is functionally identical to Temporary Instant Capacity (described later). Instant Access Capacity is included with Instant Capacity processors ordered with new servers as well as Instant Capacity processor add-ons. Any Customer running Instant Capacity Software version 6.x or later can take advantage of Instant Access Capacity, which can be used for the following purposes:

• Use an Instant Capacity processor core immediately while processing an order for processor core usage rights or Temporary Instant Capacity (TiCAP)
• Handle short term peaks in demand
• Evaluate Instant Capacity software performance
• Test and/or evaluate Instant Capacity and/or Temporary Instant Capacity functionality
• Test how applications respond to processors being activated and deactivated online
• Test interoperability of Instant Capacity with the HP Virtual Server Environment

When an order for a complex containing Instant Capacity processors is processed, a Codeword for the applicable amount of Instant Access Capacity will be made available on the Utility Pricing Solutions Portal. Upon taking delivery of the hardware, the Customer can log on to the Portal to retrieve the Codeword and apply it to the complex.

Once Instant Access Capacity has been consumed, the Customer will no longer have the ability to temporarily activate the Instant Capacity processor core. HP recommends that Customers maintain some amount of Temporary Instant Capacity on Instant Capacity systems as a best practice to ensure immediate access to extra processing resources when needed.

HP processor modules typically contain two cores: for example, the HP Integrity Montvale 1.6 GHZ 24 MB module contains one dual core processor, and the HP Integrity Itanium 2 Madison 9M module contains two single core processors. Therefore, it is most common to see configurations with even numbers of active and Instant Capacity cores.

Effective August 15, 2006, HP Instant Capacity allows partitions in new systems to be configured with odd numbers of active cores by ordering factory integrated processor core usage rights. For example, a Customer may want to order an HP Integrity Superdome with a single cell partition with three active Montvale cores and five Instant Capacity Montvale cores. The quote for such a configuration would contain:

• 1 × HP Superdome sx2000 Cell Board (A9837A)
  
• 1 × HP Superdome Montvale 1.6 GHz 24 MB 1P/2C module, Factory integrated (AD374A-0D1)
  
• 3 × HP Superdome iCAP Montvale 1.6 GHz 24 MB 1P/2C modules, Factory integrated (AD375A-0D1)
  
• 1 × Right to Use for one Montvale 1.6 GHz 24 MB Processor Core (AD376A)
  
• 1 × Right to Use for one Montvale 1.6 GHz 24 MB Processor Core, Factory integrated (AD376A-0D1)

This configuration option is supported on Arches Midrange and High End (sx2000 Superdome, rx7640/rx8640).

HP instant capacity allows add-on cell boards to be configured with odd number of active cores. For example, a customer may want to order an add-on sx2000 cell board with three active Montvale cores and five Instant Capacity Montvale cores. The quote for such a configuration would contain:

• 1 × HP Superdome sx2000 add-on Cell Board (A9837A)
  
• 1 × HP Superdome Montvale 1.6 GHz 24 MB 1P/2C module, Factory integrated (AD362A-0D1)
  
• 3 × HP Superdome iCAP Montvale 1.6 GHz 24 MB 1P/2C modules, Factory integrated (AD363A-0D1)
  
• 1 × Right to Use for one Montvale 1.6 GHz 24 MB Processor Core (AD364A)
  
• 1 × Right to Use for one Montvale 1.6 GHz 24 MB Processor Core, Field integrated (AD364A-02A)

HP Instant capacity also allows add-on processors (without cell board) with odd number of cores. For instance, in the above example if the customer wants to order one active Montvale and 3 iCAP Montvale cores to an exiting cell board, the quote for such a configuration would look like

• 2 × HP Superdome iCAP Montvale 1.6 GHz 24 MB 1P/2C modules (AD375A)
  
• 1 × Right to Use for one Montvale 1.6 GHz 24 MB Processor Core (AD376A)
  
• 1 × Right to Use for one Montvale 1.6 GHz 24 MB Processor Core, Field integrated (AD376A-02A)

Each active cell within a system requires at least one active core, so at minimum, the number of permanently active cores must equal the number of active cells in the server. Therefore, activation of a cell board may or may not require activation of an additional processor core.

In this section, the term "temporary capacity" will be used to refer to the common functionality of both Temporary Instant Capacity and Instant Access Capacity.

Temporary capacity provides a means to temporarily activate more cores than there are usage rights in a complex, enabling Customers to meet short-term peaks in demand without having to purchase a permanent usage right. This temporary activation is available in increments of processor core days and is called temporary capacity.

A "processor core day" is 24 hours (or 1,440 minutes) of activation for one processor core, and includes:

1. hardware activation of the processor core,
2. an HP-UX DC-OE or OpenVMS MCOE license,
3. an HP Virtual Server Environment license,
4. a license for all standalone products included in HP-UX DC-OE, OpenVMS MCOE and the Virtual Server Environment Suite,
5. hardware support for the processor core, and
6. software support for the included software licenses.

A processor core day can be consumed by activating a single core for 24 hours, two cores activated for 12 hours, four cores activated for one hour a day for six days, and so on. The core can be turned on and off until the 24 hours is consumed. There are currently two ways for Customers to acquire temporary capacity:

1. Instant Access Capacity, or "IAC", is included with every Instant Capacity processor core and consists of 5 processor core days of temporary capacity.
2. Temporary Instant Capacity, or "TiCAP" consists of 30 processor core days of temporary capacity, and is an optional add-on that can be purchased for a complex containing Instant Capacity processor cores.

Temporary capacity is applied at the complex level and can be used to activate any Instant Capacity processor core(s) on all active cell boards within the entire system. Temporary capacity is very similar to a phone card – just as you need a phone to use a phone card, you must have Instant Capacity processors to use temporary capacity.

Temporary Instant Capacity is applied to the Instant Capacity system via a Codeword and tracked locally by the Instant Capacity Software. No connection to HP is required, and the balance is prepaid. As Instant Capacity processor cores are activated, the Instant Capacity Software decrements the available temporary capacity balance stored in system inventory.

Tracking granularity is in 30 minute increments (activating one processor core for 1 minute will consume 30 minutes of temporary capacity on the system). How quickly temporary capacity is consumed depends on how many Instant Capacity processor cores are activated and for how long.

When Instant Capacity cores are activated temporarily, the Instant Capacity Software will summarize when the temporary capacity balance will be depleted at the current consumption rate. The software will also notify a user-defined email address once there is a certain number of days left, based on a customized setting in the software. This allows the Customer to take necessary action when the temporary capacity balance is completely consumed.

Once the Temporary Instant Capacity balance is depleted, the Customer must take one of the following actions:

• deactivate the temporarily activated Instant Capacity core(s),
  
• apply additional Temporary Instant Capacity to the system, or
  
• purchase usage rights to permanently activate the core(s).

If the temporary capacity balance reaches zero and Customer continues to use the temporarily activated processor cores the temporary capacity balance will go negative and continue to accrue. On the next reboot of any partition in the complex the Instant Capacity Software will automatically deactivate as many temporarily activated processor cores as is necessary to either stop consumption of temporary capacity or to bring the partition to the minimum of one active processor core per active cell board. The Customer is responsible for any negative TiCAP Balance that accrues on the server. Temporary Instant Capacity can be kept and used indefinitely (e.g., it does not expire) until it is depleted.

To determine the total number of temporary capacity days (or minutes) required, multiply the number of Instant Capacity cores by the number of days (or minutes) of required activation. This number should then be divided by 30 days (or 43,200 minutes) and rounded up to determine the total number of Temporary Instant Capacity units required. If purchasing a new system, include the five days of Instant Access Capacity included with each iCAP core in this calculation.

It is recommended to configure a small buffer of temporary capacity and purchase more as needed, particularly if it is unclear how much temporary capacity is needed or how quickly it will be consumed.

Temporary capacity includes hardware support for all processor cores that are activated temporarily. It also includes some software licenses and associated support for that software, specifically:

1. HP-UX 11i and later Foundation, Enterprise and Data Center Operating Environments,
2. OpenVMS 8.3 and later Foundation, Enterprise and Mission Critical Operating Environments,
3. HP Virtual Server Environment Suite, and
4. all standalone products contained inthe above bullets.

When an Instant Capacity processor core is temporarily activated, it is licensed for any combination of software installed in the partition which is listed in the table below.

Temporary capacity does not include software products licensed on a per server or per user basis, nor are OpenView products sold on a standalone basis are not included in this program at this time. Additionally, any HP per core licensed software that is not included with temporary capacity must be licensed for the maximum number of cores that may be active in the partition at any given time. This includes all permanently active cores and any Instant Capacity cores that are activated even temporarily. For example, the following HP UX Operating Environments with Serviceguard Storage Management Suite are not included with Temporary capacity:

HP-UX 11i v3 new Operating environments with Serviceguard Storage Management Suite

• T8684CB - HAOE w/SG SM Oracle Prem HP-UX v3 LTU
• T8685CB - HAOE w/SG CFS HP-UX v3 LTU
• T8686CB - HAOE w/SG CFS for Oracle HP-UX v3 LTU
• T8687CB - HAOE w/SG CFS for RAC HP-UX v3 LTU
• T8694CB - DCOE w/SG SM Oracle Prem HP-UX v3 LTU
• T8695CB - DCOE w/SG CFS HP-UX v3 LTU
• T8696CB - DCOE w/SG CFS for Oracle HP-UX v3 LTU
• T8697CB - DCOE w/SG CFS for RAC HP-UX v3 LTU

HP-UX 11i v2/v3 Operating environments with Serviceguard Storage Management Suite

• T2794BA – MCOE with Serviceguard Storage Management for Oracle Premium
• T2795BA – MCOE with HP Serviceguard Cluster File System
• T2796BA – MCOE with HP Serviceguard Cluster File System for Oracle
• T2797BA – MCOE HP Serviceguard Cluster File System for RAC

Therefore, if DCOE with HP Serviceguard Cluster File System was installed in a partition with eight active and four Instant Capacity cores, and the Customer intended to use Temporary capacity to temporarily activate the iCAP cores in that partition, a total of 12 per core licenses (T8695CB) must be ordered.
NOTE: Temporary Capacity does not include software licenses and support for all HP software! Permanent perpetual software licenses for any per-core licensed software not listed in the table below must be licensed for the maximum number of cores that may be active in the partition at any given time. The maximum number of active cores is defined as the total number of active cores plus any Instant Capacity cores that may be activated temporarily.

Global Instant Capacity, or GiCAP (pronounced "jee iCAP"), is a new optional feature included with HP Instant Capacity Software version 8.x or later. GiCAP is an extension of Instant Capacity-all previous versions of Instant Capacity have allowed Customers to move usage rights within a server, and Global Instant Capacity now allows Customers to move usage rights between servers.

The top value propositions of Global Instant Capacity include:

• Cost-effective High Availability and Disaster Recovery: In case of planned or unplanned downtime, transfer core usage rights from a failed partition on one server to one or more other servers in the group that are providing backup availability. Without GiCAP, the only way to provide this failover scenario is to provision each server with an adequate amount of temporary capacity in case of potential failures, or configure fully active hardware to sit idle. GiCAP also provides the capability to extract core usage rights from a completely unavailable server and deploy these usage rights to activate iCAP cores on a failover partition in another server. Note that cell board and memory usage rights cannot be extracted using this feature.
• Load Balancing. To provide adaptability and accommodation of changing demands, usage rights can be transferred between servers in a group. For example, a server with extra unused capacity can release usage rights to be used to activate additional components on an overloaded server that needs extra capacity.
• Pooled temporary capacity. Temporary capacity usage rights can be shared across servers for better efficiency and ease of use. By pooling temporary capacity, there is no need to provision temporary capacity for each server.

GiCAP allows usage rights processors, cell boards and memory modules to be loaned and borrowed between servers. In disaster recovery mode, only core usage rights can be seized from an unavailable server. Instant Capacity cell boards and memory are not compatible with GiCAP disaster recovery or high availability. Deactivation of resources on one server releases usage rights which can then be loaned to another server and used to activate Instant Capacity resources. The complex on which the resources are deactivated is loaning usage rights to the activating (or borrowing) complex.

Usage rights are loaned and borrowed with GiCAP in three steps:

1. One member of the Group (the loaning member) deactivates resources (cores, cells or memory).
2. The released usage rights are then moved to another member of the Group (the borrowing member) by the Group Manager.
3. The borrowing member uses the borrowed usage rights to activate identical iCAP resources (cores, cells or memory).

Temporary capacity from all members of the Group is available for use by any Group member. GiCAP consolidates all of the temporary capacity owned by individual servers into one common pool, which means there is only one single temporary capacity balance to manage, and all servers have access to temporary capacity when needed.

Instant Capacity Software can move usage rights within a server because the usage rights are tracked locally in system inventory. In order to track usage rights across a group of servers with Global Instant Capacity, a separate server called the GiCAP Group Manager is required.

The Group Manager requires no connection to HP, and is used by the Customer to manage their GiCAP environment. The GiCAP Group Manager creates groups, maintains information about the resources that members can exchange, and facilitates the movement of usage rights between group members. The Group Manager does not have to be a dedicated server - the Customer can use an existing server on site as long as it meets the Group Manager requirements:

• must be an HP-UX 11i or later nPar or vPar
• must be running Instant Capacity Software version 8.x
• must be able to communicate over the network to all group members

The Group Manager may be run on either a partitionable or non-partitionable system, but changing the configuration of the partitions may result in the Group Manager becoming inoperative, so it is therefore recommended that the Group Manager be on a non-partitionable server for optimal availability. It is also recommended that the Group Manager not run on a group member - both for recoverability and ease of use. That is, the system should be independent of the group, but it does not need to be dedicated only to the Group Manager software. The Group Manager system must have a machine-readable serial number, as displayed by the shell command "getconf CS_MACHINE_SERIAL" and must run HP-UX 11i v1 or later. A management server fitting these requirements could be used, such as the Superdome Support Management Station (SMS). The separate server used to provide quorum service for the Serviceguard cluster could also potentially be used to host the Group Manager, or an HP Systems Insight Manager CMS.

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.

NOTE: The Group Manager cannot run in an Integrity Virtual Machine (also known as a "guest"). This is because the GiCAP Group Manager requires programmatic access to information to identify the serial number and partition information of where it is running. This information is not available in a HPVM and thus the Group Manager can not be run in that environment.

The GiCAP Group Manager can manage any number of groups, as the number of groups on a Group Manager has no impact on performance.

GiCAP is enabled via the purchase of GiCAP Sharing Rights. GiCAP Sharing Rights can be thought of as tokens which are consumed by every iCAP processor core brought into a GiCAP Group. In order to bring a server into a GiCAP Group, there must be at least as many tokens as there are iCAP processor cores within the server.

One GiCAP Sharing Right must be ordered for every Instant Capacity processor core in the entire complex, across all partitions. To share iCAP cells with memory, a GiCAP Sharing Right should be ordered for every core on the iCAP cell. A server without any Instant Capacity hardware will not consume any Sharing Rights and can enter a GiCAP Group without consuming any Sharing Rights to deactivate resources and lend usage rights to other Group members.

GiCAP Sharing Rights are downloaded from the Utility Pricing Solutions Portal as Codewords using the same process as used for all other Instant Capacity Codewords. The Codeword is applied to the GiCAP Group Manager system (not the individual Group Members). Sharing Rights are owned by the server for which they are purchased, and expire when the server leaves the GiCAP Group.

GiCAP Sharing Rights can be purchased for new servers as well as an add on to existing environments.

Global Instant Capacity is built on the concept of a server group, or GiCAP Group. This is a collection of servers that are allowed to loan and borrow usage rights.

GiCAP Grouping Rules are defined by HP and specify what servers can be grouped. Grouping Rules are downloaded from the Utility Pricing Solutions Portal as an encrypted file and applied to the GiCAP Group Manager. A readable version of the Grouping Rules is also available on the Portal. To create a group, the GiCAP Group Manager will check that 1) there are enough Sharing Rights available, and 2) that the proposed group is supported by the current Grouping Rules.

Only the same class of servers can be grouped together in a GiCAP group, i.e. Superdomes with Superdomes and Mid Range servers with other Mid Range servers. Any server with Montvale and Montecito processors can be grouped with any other server with Montvale and Montecito processors irrespective of the clock speed or the cache size as long as they are of the same class. Also any HP 9000 server with PA8900 processors (on both sx1000 and sx2000) can be grouped with an HP Integrity server with Montvale or Montecito processors, provided that the servers are of the same class. For e.g. an rp8440 with PA8900 1.068 GHz, 3MB can be grouped with an rx7640 with Montvale 1.6GHz, 24MB. For all other processor types, only servers with identical processors (e.g. same processor product number) can be grouped together.

NOTE: GiCAP moves usage rights for cell boards with memory as well as usage rights for processors. When deactivating a cell, you also deactivate the memory on that cell. An Instant Capacity cell with the same amount (or less) of Instant Capacity memory can then be activated in another server. This capability is available only when both servers have at least one partition accessible by the GiCAP Group Manager and therefore, is not recommended for high availability or disaster recovery scenarios.

There is no restriction on location of group members, but Customers are responsible for adhering to all applicable import/export laws and customs regulations.

NOTE: GiCAP group size should be limited to fewer than 9 complexes, or fewer than 20 hard partitions, for optimal performance.

In the case of processors, GiCAP moves both the hardware usage right (Right to Use, or "RTU") and some per-core licensed software (License to Use, or "LTU"). When describing movement of processor resources with GiCAP, we refer to the movement of both the RTU and the LTU(s).

Not all HP Software can be moved between servers using GiCAP. Only the per-core licensed software listed in the table below can be moved. For example, HP software that is licensed per partition or per cluster cannot be moved with GiCAP. Note that GiCAP is not supported on OpenVMS. Additionally, only the "with system" software license product numbers are listed here for brevity. Please note that the corresponding add on software Product Numbers also apply.

In the context of GiCAP, two software licenses are considered equal if the two licenses are for the same software product, or if the two licenses are for two different standalone products contained within the same bundle or suite.

For example:

• DC-OE = DC-OE
• standalone MirrorDisk/UX = standalone MirrorDisk/UX
• standalone MirrorDisk/UX = standalone Process Resource Manager (both are contained in VSE-OE)
• standalone vPars = standalone Integrity VM (both are contained in HP VSE Suite)
• standalone Serviceguard = standalone Workload Manager (both are contained in DCOE)

NOTE: A partition can loan processor resources to another partition only if the software configuration of the loaning partition is equal to or greater than the software configuration of the borrowing partition.

In the context of GiCAP, software license "A" is considered greater than software license "B" if software license "A" is a bundle or standalone product that contains software license "B." Put another way, software license "A" is a superset of software license "B." For example, Data Center OE is greater than Virtual Server OE, which is in turn, greater than Base OE (see for more details on what standalone products are contained in specific bundles and suites). HP-UX 11i v3 old operating environments (MCOE, EOE and FOE) and new operating environments (DC-OE, HA-OE, VSE-OE and BOE) can co-exist in the same GiCAP group. The following illustrates the relationship between HP-UX 11i v3 new and old operating environments for the purpose of GiCAP LTU sharing.

For example:

• DCOE > VSE-OE
• MCOE > BOE
• HA-OE > FOE
• EOE > standalone PRM
• EOE > FOE + standalone MirrorDisk/UX + standalone PRM
• MCOE > FOE + standalone MirrorDisk/UX + standalone PRM + standalone WLM
• HP VSE Suite > standalone vPars + standalone Capacity Advisor
• EOE + Standalone WLM > FOE + standalone WLM

In general, a partition can lend processor resources to another partition only if the software configuration of the loaning partition is equal to or greater than the software configuration of the borrowing partition. It is the responsibility of the Customer to ensure that they remain in compliance with their software licensing agreements when using GiCAP to move processor resources between partitions.

Note as well that when loaning processor resources to another GiCAP Group Member, a license must be loaned for every software product installed on the borrowing partition. For example, if the borrowing partition is running HP UX 11i v3 Base OE plus standalone MirrorDisk/UX and standalone Online JFS, the loaning partition must loan either a single VSE-OE or DCOE license (since both VSE-OE and DC-OE are supersets of all products installed on the borrowing partition), or a BOE license plus 2 licenses for any standalone VSE-OE or DC-OE products.

Due to the potential for complications due to software licensing, it is highly recommended that Customers plan GiCAP solutions in advance, similar to designing the layout of high availability clusters. By diagramming a solution and detailing the software configuration of all partitions, allowable paths for GiCAP transfers can be identified. Alternatively, to keep things simple, GiCAP transfers can be planned between partitions of identical software configurations only.

GiCAP does not move all per-core licensed HP Software. The following HP-UX Operating Environments with Serviceguard Storage Management Suite are examples of per-core licensed HP software that can not be moved between servers with Global Instant Capacity:

HP-UX 11i v3 new Operating environments with Serviceguard Storage Management Suite

• T8684CB - HAOE w/SG SM Oracle Prem HP-UX v3 LTU
• T8685CB - HAOE w/SG CFS HP-UX v3 LTU
• T8686CB - HAOE w/SG CFS for Oracle HP-UX v3 LTU
• T8687CB - HAOE w/SG CFS for RAC HP-UX v3 LTU
• T8694CB - DCOE w/SG SM Oracle Prem HP-UX v3 LTU
• T8695CB - DCOE w/SG CFS HP-UX v3 LTU
• T8696CB - DCOE w/SG CFS for Oracle HP-UX v3 LTU
• T8697CB - DCOE w/SG CFS for RAC HP-UX v3 LTU

HP-UX 11i v2/v3 Operating environments with Serviceguard Storage Management Suite

• T2794BA – MCOE with Serviceguard Storage Management for Oracle Premium
• T2795BA – MCOE with HP Serviceguard Cluster File System
• T2796BA – MCOE with HP Serviceguard Cluster File System for Oracle
• T2797BA – MCOE HP Serviceguard Cluster File System for RAC

Therefore, if DC-OE with HP Serviceguard Cluster File System was installed in a partition with eight active and four Instant Capacity cores, the Customer could use Global Instant Capacity to temporarily activate the iCAP cores in that partition by borrowing four usage rights from another GiCAP Group Member. However, the Customer would be responsible for purchasing permanent software licenses for all 12 cores in the partition since GiCAP does not move DC-OE with HP Serviceguard Cluster File System (T8695CB ).

NOTE: Global Instant Capacity does not move software licenses and support for all HP software! Permanent perpetual software licenses for any software not listed in Table 6.3.5.6 must be licensed for the maximum number of cores that may be active in the partition at any given time. The maximum number of active cores is defined as the total number of active cores plus any Instant Capacity cores that may be activated temporarily via usage rights borrowed from other GiCAP Group Members.

Customers are responsible for determining the policy of their applicable ISVs for moving third party software licenses between servers using GiCAP.

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.

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.

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.

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.

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.

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.

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.

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.

GiCAP can transfer usage rights between servers with different support levels. When a support call is placed on a hardware or software component that has been borrowed from another server, the level of support delivered to the Customer will be the level of support purchased for the borrowing complex, not the complex loaning the resources. For example, if a server covered under same day support loans usage rights to a server covered under 24 x 7 support, and the component fails, 24 x 7 support will be delivered.

Support pricing for GiCAP consists of an ongoing monthly support charge. The ongoing support charge covers support for the GiCAP software as well as to compensate for potential support level differences between servers within the grouping. Watson will select the appropriate support band, 6B0, to apply the support associated with each GiCAP Sharing Right.

Customers are responsible for maintaining license compliance, and should work with their ISV to determine their specific licensing requirements for an Instant Capacity environment. All Customers should consult their ISVs to determine the policy for moving software licenses between processor cores both within a server and between servers, and perform testing in order to assess how applications respond to iCAP activations.

Instant Capacity hardware has the same product lifecycle as the equivalent active component. Both versions of the component will become available, go obsolete, and no longer be covered by standard HP support at the same point in time.

The Right to Use for an Instant Capacity component will remain on HP's Corporate Price List as long as the hardware component is supported. The Right to Use will not be orderable after the End of Support date for the hardware.

Temporary Instant Capacity will remain available as long as there is at least one Instant Capacity processor for the server still covered under standard HP support.

• All Instant Capacity Customers must sign and abide by the Terms and Conditions of the Instant Capacity Contract, which is an addendum to the Customer's standard purchase agreement.
• Customers must apply all Codewords as requested by HP.
• No Instant Capacity component can be removed from the system/complex in which it was originally installed.

• Instant Capacity hardware is supported on partitions running HP UX 11i and later or OpenVMS 8.3 and later only.
• A partition must contain at least one active (non Instant Capacity) cell board.
• Instant Capacity cell boards must be assigned to a partition.
• Every active cell board must contain at least one active core and exclusively active memory (i.e. Instant Capacity memory is not supported on active cell boards).
• Instant Capacity cell boards contain exclusively Instant Capacity processors and Instant Capacity memory modules.
• When activating an Instant Capacity cell board, all memory on the cell must also be activated.
• Each active cell within a system requires at least one active core, so at minimum, the number of permanently active cores must equal the number of active cells in the server. Therefore, activation of a cell may or may not require the purchase of permanent usage rights for an additional processor core.
• Each Instant Capacity processor core activated permanently via the purchase of a Right to Use requires the corresponding purchase of licenses for the applicable HP UX or OpenVMS Operating Environment and any other per-core licensed software installed in the partition. Hardware and software support must also be purchased and be identical to the support and OE on the server in which the processors are installed.
• When creating a new partition in the field, all components must be active (i.e., no Instant Capacity components can be included when creating a new partition). New partition creation fails if any of the cell boards contain Instant Capacity components. See the User's Guide for more details.
• It is strongly recommended that all cells in a partition, both active and inactive, be configured identically and symmetrically.
• It is strongly recommended that Configuration Guidelines for Superdome be followed when designing partition layout in order to place iCAP cells in the optimal location on the backplane for performance and availability. Consult the Superdome subchapter of this guide for more details.

All configuration rules listed in this section apply both to Temporary Instant Capacity and Instant Access Capacity.

• Temporary Instant Capacity for processors is supported on partitions running HP UX 11i and later or OpenVMS 8.3 and later only.
• Temporary capacity does not expire. It can be held indefinitely and used as often as needed until the capacity balance is depleted.
• Temporary capacity is tracked at the complex level and can be consumed by any Instant Capacity processor(s) on active cell boards within the complex.
• Temporary capacity can only be used on the server for which it was purchased unless that server is a member of a Global Instant Capacity Group.
• Temporary Instant Capacity can be applied to Instant Capacity processor cores on active cell boards only. It cannot not be applied to processors on iCAP cell boards, or to Instant Capacity cell boards or Instant Capacity memory modules.
• Temporary Instant Capacity (TiCAP) is purchased in increments of 30 processing days. Any quantity of TiCAP can be purchased at a time.
• TiCAP can be purchased for existing systems as long as those systems have iCAP processors.
• TiCAP includes temporary software licenses solely for the software products listed in this guide. Any additional software running in a partition with Instant Capacity processors that are intended to be activated temporarily using TiCAP must be licensed for the maximum number of cores that may be active at any given point in time.
• TiCAP includes temporary hardware and software support for all iCAP processors activated temporarily.

• GiCAP is supported on HP UX systems only.
• GiCAP grouping rules determine which servers can be put in a group (hardware related rules). The latest grouping rules are available on the Utility Pricing Solutions Portal, accessible at http://www.hp.com/go/icap/portal.
  
• A GiCAP Sharing Right must be purchased for every iCAP core within the server you want to group.
  
• All partitions on all servers in the group and the Group Manager must be running HP UX 11i and later and Instant Capacity Software version 9.x or later.
  
• GiCAP group sizes should be limited to fewer than 9 complexes, or fewer than 20 nPars, for optimal performance.
  
• The Group Manager can run on any HP UX instance except a virtual machine. It is recommended that the Group Manager be a non partitionable server which is not a Group Member for optimal availability.
  
• Usage rights extraction using icapmanage works only on partitioned servers. In order to seize usage rights from a failed partition, the Group Manager must be able to communicate with another HP UX partition on the server. GiCAP also supports the capability to extract core usage rights from a completely unavailable server (where the GiCAP Group Manager is not able to communicate with the failed server) and deploy these usage rights in failover partitions in other servers. Note that cell board and memory usage rights cannot be extracted using this feature.
  
• iCAP version 9,x and later supports the capability to have a standby GiCAP Group Manager which can take over GiCAP operations in the event of a primary Group Manager failure.

© Copyright 2010 Hewlett-Packard Development Company, L.P.

The information contained herein is subject to change without notice. The only warranties for HP products and services are set forth in the express warranty statements accompanying such products and services. Nothing herein should be construed as constituting an additional warranty. HP shall not be liable for technical or editorial errors or omissions contained herein.