iCap architecture

As illustrated in the following figure, iCap architecture consists of the following components:

  • A master PAS and agent PASs
    The iCap master PAS usually runs on one of the managed LPARs. All other managed LPARs run agent PASs. 

Related topic

Product-architecture


The master PAS controls changing the defined capacities (DCs) and group capacity limits (GCLs) of all the LPARs or groups that iCap is managing.
For more information about choosing a system to run the master PAS, see Master-PAS-guidelines.


  • Agents running data collectors
    A data collector on each LPAR collects information about MSU usage, including the 4HRA, Workload Manager (WLM) importance data, and the 4HRA for container and mobile workloads. The data collector sends this information to the master PAS.
    WLM importance data refers to the number of MSUs that each importance class consumes. For more information about WLM Tuning, see the WLM Tuning parameter description in Policy-level-and-subpolicy-level-parameters.
    If there are no active agents, iCap doesn’t collect WLM data or container and mobile workload data.


  • An assessor
    The assessor dynamically reallocates CPU capacity based on policy rules.
  • A BCPii driver
    iCap uses the IBM Base Control Program internal interface (BCPii) function to access the LPAR management facilities on the IBM Hardware Management Console (HMC) system. Specifically, iCap modifies defined capacity (DC) and group capacity limit (GCL) only.

Important

  • The following diagram shows an example of the product architecture in a Country Multiplex Pricing (CMP) environment. You can also manage iCap on a single CPC.
  • All managed LPARs and groups must be accessible by the same HMC.
  • Each CPC requires at least one active LPAR that is running a version 3.0 master or agent PAS. 

New iCap architecture_v3_(6.5.17).png

 

Tip: For faster searching, add an asterisk to the end of your partial query. Example: cert*