Ron Gordon
Director, IBM Power Systems
Hybrid Increase Efficiency and Lower Operational Costs using IBM Power Systems Enterprise Pools 2.0
A Use Case for Power Enterprise Pools 2.0 with Utility Capacity
Today’s IT infrastructure budgets are more tightly managed than before because of the changing economic conditions worldwide. Companies are frequently needing to refresh IT server infrastructure because of increased demands, new applications being added, or the life cycle and depreciation schedules are at an end. So, not only are new technologies and upgraded configurations analyzed, but the finances are also an increased critical part of the decision making. Technological advances are happening every day that should be incorporated into the decision process to reap the benefits of systems configurations and cost optimizations.
One of the latest technologies in IBM Power Systems is Power Private Cloud with Shared Utility Capacity, also called Enterprise Pools 2.0 or EP2.0 for brevity. EP2.0 is discussed in a previous blog, and here I present a case as to why this technology should be investigated when making IT infrastructure changes. It is important to note that this applies not only to IBM Power Enterprise Systems like the 980 and E1080 but also to the IBM Power Midrange 950 and IBM Power Scale Out servers 922 and 924.
Cores and Memory Cost
First, we must recognize that on the IBM Power Enterprise servers, the cores and memory have a two-part cost:
1. Purchase of cores and
2. Activation of the core so they can be used as a compute resource
In most cases, the activations are higher costs than the purchase. The same is for memory. In IBM Power Scale Out, the cores and memory are always all activated with a single price. The configuration of the active cores and memory is usually based on supporting the peak expected usage, while this peak may only be 20% of the time. (I will discuss mitigation with LPM, mobile cores, and COD later.)
Use Case of EP2.0
So let me present a case for the use of EP2.0 and start by saying I am not a medical doctor, nor do I sell insurance but “results may vary and see your doctor if symptoms persist” and “only pay for what you need”.
Survey and experience indicate that most Power Systems run at about 30-40% utilization, and this does not account for lower usage during 3rd shifts or weekends. This implies that there is excess capacity – a cost not being put to use. It also seems that when upgrades to newer generations are being performed, the analysis is to replace the cores and memory with the same performance and capacity with a core count reduced based on rPerfs or CPWs deltas. So, if you were 40% utilized on your legacy system, 40% efficiency is built into the upgraded system. You could equate this to only using 40 cents of every dollar you spent. As a side note, Power Systems like to run at about 85% utilization and using PowerVM and correctly set up partitions (shared, dedicated, shared pools, VPs, weights) they can easily achieve that 85% utilization. This should not affect performance. Of course, extra capacity does allow for unforeseen spikes and increased workloads, which is good, but expensive.
Then we install a backup or DR server very similar to the production server. Now we doubled the cost of inefficiency since that server is in standby mode, not doing much work. (Again…CBU, COD, Mobile cores later.)
IBM Power Systems is addressing this cost/efficiency concern to lower operational costs by introducing Enterprise Pools 2.0, which is available across the POWER9 and POWER10 portfolio of servers. Realize this is sometimes a TCO vs TCA analysis since the EP2.0 implementation comes at a premium, mainly reflected in the TCA, while the TCO analysis can produce a 30%-50% cost savings.
Here is a refresher on how EP2.0 works:
(30 core activation cost saved)
In this example, three systems individually were designed to handle peak load and hence had 30, 40, and 30 cores activated, respectively to handle the compute demand at peak. Through analysis, the peaks when viewed at points of time never exceeded 70 cores; hence, EP2.0 base is set to equal 70 cores across the pool. Remember, in Power System EP2.0, the systems participating in the Enterprise Pool have all cores activated but you only “pay” for the base cores. In the above case, you set the base as 30, 40, and 30, respectively, on the three servers in the pool. This is logically viewed as a pool with 70 active cores while the total activated cores could be 48, 64, 48, where the workloads can expand and use all the cores on all the servers if there is demand, effectively 150 cores. This dynamic usage is automatic: No actions are required by administrators. If the total usage exceeds the 70 cores, then as the non-base cores are used, there is a per-minute charge incurred at the rates in the below table. The excess capacity usage is measured on a per-minute basis and charged against Capacity Credits ($240 per Capacity Credit), which provide several thousand minutes of usage. Cores, memory, and operating system entitlements vary by system type.
So, for example, if on a 980 an AIX partition exceeds the pool base by 2 cores, with no additional memory needed for 10 hours, the usage cost is $24.00 or 10% of a cloud usage credit. (I will leave the math up to you if you want to verify.)
- The first is the TCO-focused choice where you set the base cores to match your aggregate system usage. This is the example above
- The second model is a “pay-go” model where you set the base to the minimum of 1 core and 256 GB memory and just pay for what you use since most execution will exceed 1 core and 256 GB memory.
Users with very small system requirements, such as an IBM i application needing only 2 cores or less but they must purchase a minimum 6-core system, may benefit from a “pool” of 1 system minimally EP2.0 configured.
Comparing EP2.0 to COD, Mobile Cores, and LPM
You may be wondering why you just can’t use COD, Mobile Cores, or LPM to satisfy dynamic or rebalancing requirements. The answer is you can. But all of these require planning and manual actions to perform. If we look at COD, using AIX as the example, the cost is $13.00 per day per core and $1 for 8 GB of memory if needed, so call it $14.00. It is per day, and don’t forget to turn COD off or the meter keeps running. All of these also require re-definition of the VMs. And if you have a CBU or DR server, there is additional planning and scripting needed (EP2.0 servers do NOT have to be in the same datacenter) as well as absorbing the inefficiencies previously mentioned. So not only can there be cost savings comparing EP2.0 to CBU, COD, LPM, and mobile cores, there are operational efficiencies to be gained because of the automation.
Getting Started/Additional Information
To learn more about how IBM Power Systems Private Cloud Solution with Dynamic Capacity Pricing (EP2.0) may be beneficial to you, or to compute the best base numbers for your system, please contact your Mainline Account Executive directly or click here to contact us with any questions..
You may be interested in:
BLOG: IBM Power Systems Private Cloud Solution with Dynamic Capacity Pricing
BLOG: IBM AIX 35th Anniversary, POWER10, and the Future
BLOG: IBM Announces Power10 based Power System Enterprise 1080