Power Enterprise Pools 2.0 with Utility Capacity

View Only

Power Enterprise Pools 2.0 with Utility Capacity - A Cloud-Based Approach

By STEPHANIE JENSEN posted Thu June 25, 2020 07:24 PM

Like

With the release of 930 HMC and 930 system firmware in mid-May 2019, a new version of Power Enterprise Pools is available. Power Enterprise Pools 2.0 with Utility Capacity (PEP 2.0) aims to simplify pool administration by leveraging the IBM Cloud as a central point of management. PEP 2.0 makes use of automation via a cloud-based architecture to enable utility capacity across a collection of systems. This eases multi-system resource sharing and provides new flexibility for clients deploying a private cloud infrastructure.

Overview

A PEP 2.0 pool can contain Power E980 systems only. On each system in a pool, all installed cores and memory are active — meaning all resources are available for use. Each system in a pool must have permanent base capacity. Each minute, core and memory consumption on each system is tracked and aggregated across the pool. All usage under base capacity across the pool is not charged. All usage that is above base capacity is metered by the minute and charged on a “pay-as-you-go” basis. Memory usage is tracked by assignment to active partitions and is not based on actual operating system usage of the memory, while core usage is tracked by actual usage of partitions in the pool.

Figure 1

Currently a single pool can contain up to 32 Power E980 systems. These systems must be in the same enterprise and country. A pool can support up to 1000 partitions, and they must be shared processor partitions. At least 25% of the available cores and at least 50% of the available memory on each system must be activated as base capacity. In addition Cloud Edition software is required for each base processor activation. Furthermore, each HMC managing a system in the pool must have Network Time Protocol (NTP) enabled and Performance and Capacity Monitoring must be enabled for each managed system in the pool. A connection to Cloud Management Console (CMC) is also required. Finally, clients must purchase prepaid capacity credits — these are used to cover metered usage charges (usage above the base capacity of the pool).

To reiterate, for each system in a pool, base capacity must be purchased to provide a “base” of uncharged usage. This base capacity can consist of Base Processor Activations for any operating system, Base Linux Processor Activations, Base AIX software license entitlements, Base IBM i software license entitlements, and Base 1 GB Memory activations. The total usage across the pool is aggregated each minute to determine the overall consumption of the various base capacity types. If the total consumption across the pool in any minute exceeds the pool’s base capacity, metered usage is accrued. Thus, metered usage is additional resource usage above base capacity.

Now that some of the requirements are out of the way let’s look at a few basic examples. For instance, if we have a two system pool in which system A has 5 base cores and system B has 5 base cores—in any minute if the total usage of both systems is less than or equal to 10 cores, no charges are accrued. However, if usage exceeds 10 cores then there are metered usage charges. Figure 1 illustrates how two systems in a three system pool can exceed their base capacity—but since the total base capacity of the pool is not exceeded, no metered usage is accrued (i.e. no capacity credits are consumed).

Figure 2

Figure 2 displays a three system pool. The pool has a total of 384 cores, of which 192 are base cores. System A exceeds its base capacity for the entire time interval and the other two systems do not. In aggregate the usage exceeds the pool’s base capacity, hence metered usage charges are accrued. This is because system A exceeded its base capacity significantly enough to take the pool’s total consumption above the pool’s total base capacity, while systems B and C’s usage was not low enough to offset system A’s usage.

Figure 3

Figure 3 illustrates the same scenario, but in this case the usage for System A, although exceeding its base capacity, is not excessive enough to exceed the pool’s total base capacity. Since for these minutes the total pool consumption is less than the total pool base capacity metered usage is not accrued.

Metered Usage

Metered usage is the usage above base capacity across the pool. It is charged by the average usage during a minute, not the peak usage. There are four types of core charges for metered usage: Any O/S hardware core, Linux/VIOS only hardware core, AIX software, and IBM i software. There is a single memory charge. Metered usage charges are covered by capacity credits which are ordered in eConfig or purchased via Entitled Systems Support (ESS) where available. Capacity credits must be pre-purchased. Figure 4 shows the rate table that describes the number of resource minutes that one capacity credit provides. For instance, one any O/S core can be used for 20,000 minutes at the cost of one credit.

Figure 4 *The values in this table can change

Budgeting

As metered usage accrues, client accounts are debited in real time. To alleviate concerns of runaway metered usage, a budget can be put in place to cap metered usage charges. Clients can set monthly metered capacity usage limits to stay under budget. Clients can set alerts to be notified when the rate of consumption is threatening to exceed the budget. Alerts can be set for rate of consumption, remaining budget balance, and remaining capacity credit balance. As metered usage approaches the monthly budget users can choose to do nothing or raise the budget limit for that month (or subsequent months). In the case where the entire monthly budget is consumed, throttling of the pool’s systems begins to slow consumption. Any usage above the monthly budget is not charged to the client. Resource consumption can also be managed in the standard way using shared processor partition configurations or shared processor pools.

When throttling is enabled, CMC creates a throttling task for every system in the pool. HMCs managing systems in the pool periodically check for tasks. When an HMC finds a throttling task associated with a system it manages it runs the task. Throttling is initiated for other reasons besides exceeding the monthly budget. These reasons include Capacity on Demand (CoD) code expiration, a past due pool account status in ESS, and the pool’s remaining capacity credit balance reaching zero and not being replenished within 30 days. In the case of CoD code expiration, the PowerVM hypervisor initiates throttling.

When throttling is caused by the monthly budget being met, increasing the monthly budget on the budget panel stops throttling.

Throttling

Throttling uses a gradual model to limit the rate of consumption of each system in a pool. Each system in the pool is throttled based on its metered core usage when throttling starts. For example, if a system has 10 base cores and is using 20 cores when throttling is initiated, that core usage value is used throughout the throttling period by the throttling algorithm. The first reduction in consumption rate applied by the throttling algorithm limits metered core usage by 10 percent of the metered core usage at the start of throttling. After 24 hours, the metered core usage is limited by 30 percent. After 48 hours, the metered core usage is limited by 60 percent. After 72 hours, core usage is limited to the sum of the number of base any O/S cores and base Linux/VIOS cores on that system. For example, assume a system has 10 base cores and is consuming 20 cores at the time throttling is started. In round one the algorithm limits the system’s core usage by 10 percent of its metered usage. Since the metered usage is 10 cores, the algorithm limits the total usage by 1 core giving a throttled upper bound of 19 cores for that system for the first 24 hours. The next throttling round throttles the metered usage by 30 percent, which is 3 cores. Thus, for the next 24 hours, usage is capped at 17 cores. The third round throttles the system’s metered usage by 60 percent giving an upper bound of 14 cores for the next 24 hours. The final round of throttling limits the core usage to the system’s base core capacity of 10 cores. Throttling never limits consumption to less than base capacity. This gradual model of throttling is not used when the reason for throttling is CoD code expiration. In this case the system’s core usage is immediately throttled to its base capacity.

When a system is throttled, if there are sufficient cores available to meet the entitled capacity of all the partitions on the system, each partition is guaranteed its entitled capacity, but there is reduced uncapped capacity available for uncapped partitions. If there are insufficient cores available to meet the entitled capacity of all the partitions on the system, each partition’s entitled capacity is scaled based on the ratio of active non-throttled cores to entitled capacity of all the partitions on the system. For example, if due to throttling there are only 25 cores available, but the total entitled capacity is 50 cores, each partition would have only 50 percent of its entitled capacity guaranteed. If other partitions do not use all of their entitled capacity, then this unused capacity can be shared among other partitions on the system. If there are partitions with very low entitled capacity and there is a large overcommitment of entitled capacity, the low entitled capacity partitions may be starved for CPU causing them to become unresponsive.

When throttling is started or stopped, notifications appear in the CMC GUI as well as the HMC GUI. Furthermore, the PEP 2.0 event log and the system's CoD history log contain throttling start and stop messages to provide start and stop times.

CoD Codes

All CoD codes are managed automatically by CMC and ESS. There are no XML files and no CoD codes that must be downloaded and applied. CoD codes are used to add systems to a pool, to provide a system’s PowerVM hypervisor with purchased base capacity information for throttling when pool membership CoD codes expire, to continue a system’s membership in a pool, and to remove a system from a pool. Pool membership codes expire after 90 days. CMC automatically starts the CoD code renewal process 10 days prior to expiration. If a CoD code is not successfully renewed, CMC retries daily and notifies the user when there are 7 or fewer days left until expiration. The Update CoD code task in the EP 2.0 app can be used to attempt CoD code renewal at any time when there are 10 or fewer days left until expiration. Throttling to base capacity is initiated by the PowerVM hypervisor on a system if a new code is not received before expiration of the previous code. CoD Codes are not renewed if the pool account status in ESS is past due or the pool’s remaining capacity credit balance reaches zero and is not replenished within 30 days.

Charging for Metered Core Usage

Metered core usage can be tracked by the client in the CMC EP 2.0 app on the “Core Usage” panel. It displays total usage as well as metered usage for configurable time intervals and zoom levels. For instance, a view of the usage for yesterday at the minute level can be selected using the bar chart interface.

Let’s look at more in depth examples of how metered core usage charging works. As mentioned previously, total pool consumption is aggregated across the pool for each minute to determine if there is metered usage. Total pool core consumption for one minute is computed by looking at each active partition in the pool, determining its O/S type, computing its average core usage for that minute, and summing it with the average usage for every other active partition of the same O/S type in that minute. This generates four values for pool core usage in that minute: AIX, IBM i, Linux, and VIOS. Here is an example of pool core usage for one minute and the associated charges:

Figure 5

In this example (referencing Figure 5) there are 14 core minutes of AIX usage, 1 core minute of IBM i usage, and 15 core minutes of Linux/VIOS usage. The pool’s base capacity for any O/S hardware is 15. There are 14 AIX core minutes + 1 IBM i core minute = 15 any O/S hardware core minutes, thus there are 15 used - 15 base giving 0 metered any O/S hardware core minute charges. The pool’s base capacity for AIX software license entitlements is 10 cores. Since the total usage for AIX is 14 core minutes there are 14 used - 10 base = 4 metered AIX software core minute charges. The same logic is applied to IBM i software license entitlements giving 0 metered IBM i software core minute charges. The same logic is again used to reveal that metered Linux/VIOS hardware charges are 0.

The following example (referencing Figure 6) shows a more subtle result:

Figure 6

In this example any O/S hardware metered core usage is 0 because 11 AIX + 2 IBM i = 13 any O/S core minutes which is less than the 15 base any O/S hardware cores. AIX software metered core usage is 1 because there are 11 AIX core minutes of usage but only 10 base AIX software license entitlements. For IBM i the result is 0 charges since the 2 base covers the 2 used core minutes. Remember that there are only 13 cores used for any O/S hardware cores but there are 15 base cores. Any O/S cores that are not used by AIX and IBM i are used to cover Linux/VIOS usage. Since there are 20 base Linux/VIOS hardware cores but there are 25 core minutes of Linux/VIOS usage, normally the result is 5 core minute charges. However, the 2 left over any O/S cores offset some of the Linux/VIOS usage. Thus, the result is only 3 core minutes of metered Linux/VIOS hardware core charges.

GUI Overview

The Enterprise Pools 2.0 app in CMC is used to view and manage PEP 2.0 pools. It can be used to create a pool, add systems to a pool, remove systems from a pool, and move systems between pools. Because the management of CoD codes is automated in CMC, none of these actions require the client to contact IBM or to download CoD codes or XML files. Furthermore, the app can be used to set monthly budgets for metered capacity consumption, and to tailor alerts and thresholds for a pool based upon budget, remaining capacity credit balance, or resource consumption. It displays the real-time capacity credit balance, the budget status, the metered resource rate table, and the capacity credit purchase history. Furthermore, clients can breakdown capacity credit usage by resources within a pool or drill down within a selected time period to see detailed usage by a partition or system. Clients can use the core and memory usage panels to analyze total or metered minutes and capacity credits. The event log shows all important actions and events for a pool. The inventory panel displays all relevant inventory information including systems in a pool and the partitions on those systems. It contains current information on core and memory usage as well as the base capacity for a pool. The usage statement panel shows metered usage by resource type, by month and by quarter, for the life of the pool. Finally, clients can export data displayed on the GUI to spreadsheets.