POWER > Infrastructure > Linux

LPARs Allow Clients to run Linux Alongside AIX and IBM i


Old perceptions die hard. Many IT managers believe that x86 equates to Linux* solutions at a lower total cost of ownership (TCO). But the Linux OS and its myriad open-source tools run well on IBM Power Systems* servers and frequently with much better price-performance.

Skip Garvin, senior technical solutions manager at IBM Systems Lab Services Migration Factory, has witnessed many migrations to the Power Systems platform—often with a familiar and favorable outcome. Garvin remembers one client that required 550 cores of Intel to run their SAP/HANA application. The client saw that drop to 38 Power* cores after the migration was completed.

“When you migrate your applications from x86 to Power, there are a few things that will almost always be true. No. 1, they will almost always run faster. No. 2, they are almost always more reliable. No. 3, the physical footprint—the number of cores and the number of physical systems—will drop,” Garvin says.

Reducing the number of cores has several benefits. Fewer cores mean fewer servers to process the same volume of data, a reduced footprint in the data center and thus less server sprawl, and lower energy costs. And, on the subject of lower energy costs, in an article titled “Chip Wars” about gaining better performance with fewer servers (bit.ly/2JG4bxv), Garvin says that “green initiatives are always at odds with x86-based solutions.”

Many Good Candidates

Mark Short, lead migration consultant at IBM Systems Lab Services Migration Factory, believes that “HANA on Power is the killer app for Linux on POWER*.” Two case studies illustrate the tremendous benefits achieved from migrating to SAP HANA on Linux on POWER.

After the initial implementation of SAP HANA on x86 servers, a major European shoe retailer decided to move to SAP HANA on IBM Power Systems (ibm.co/2OzdShQ). Results reported include saving 40,000 euros per month in hardware leasing costs and achieving the same performance with half the processing cores.

A major wholesale and retail company had run into limitations with its x86 implementation of SAP HANA (ibm.co/2DczD5o). By migrating to Linux on POWER, the company cut the number of processor cores by 70 percent and increased performance by a factor of five.

The IBM whitepaper “SAP HANA on IBM Power Systems” (ibm.co/2JPP2d1) makes the case that the Power architecture is ideal for running demanding SAP HANA workloads.

Other databases are also good candidates to run on Linux LPARs, especially those running in environments with high transaction volumes. Sybase, MySQL, MariaDB, MongoDB and other database products perform well on Linux on POWER.

While Oracle doesn’t run on Linux on POWER, EnterpriseDB’s EDB Postgres, based on open-source PostgreSQL, does. Some clients may be interested in experimenting with EDB Postgres for its Oracle compatibility at a lower cost than Oracle. It’s worth noting that a number of database companies provide both community and enterprise editions of their products, with more features and commercial support available in the enterprise editions. The community edition may suffice for performing a baseline analysis of the product’s performance on Linux on POWER.

For clients wanting to explore machine learning and other artificial intelligence (AI) tools on the Power Systems platform, IBM provides PowerAI, a no-charge, prepackaged distribution of open-source deep learning frameworks. PowerAI can run in a Linux LPAR, making it easy to compare the performance of AI applications on Power versus other hardware platforms and OSes.

Side by Side With LPARs

LPARs enable a user to divide a computer’s processors, memory and storage into multiple sets of resources so that each set of resources can be operated independently with its own OS instance and applications. They’re perfect for experimenting with new workloads because each LPAR acts as an independent server. Thus, any problems a Linux LPAR encounters won’t affect any other system partitions. While LPARs are independent, they can share access to storage with other LPARs.

Clients can begin their experimentation by creating a Linux LPAR in a development or test server, installing a new application or cloning an existing one in the LPAR, and testing the new workload. The experimental LPAR can later be easily moved to a production server, or it can be deleted or archived. Note that it’s possible to combine production and test environments on a single server and a failure in a test LPAR won’t disrupt any production workloads. In practice, however, Garvin and Short report that clients prefer to maintain separate test and production servers.

LPARs are easy to set up and manage, and it’s also easy to allocate resources to them. It’s also easy to suspend, restart, archive and delete LPARs. And, if something goes wrong, it’s easy to stop an LPAR.

PowerVM Active Memory Sharing allows LPARs to share physical server memory. PowerVM also provides a shared processor pool to allocate processor capacity to LPARs. Small fractions of a processor can be allocated to an LPAR using Micro-Partitioning Technology. The Virtual I/O (VIO) Server allows for sharing of SCSI disk, optical, tape and network devices. The flexibility of allocating resources to LPARs makes it easy to run performance tests against LPARs with varying amounts of memory and processing capacity.

Live Partition Mobility provides additional flexibility in managing LPARs by making it possible to move an LPAR from one physical system to another with no interruption in its operation. Live Partition Mobility clones the LPAR being moved, including its running environment, and its processor state and memory contents.

Clients should consult their IBM documentation to determine which generations and models of Power servers support PowerVM and Live Partition Mobility.

Pay for Only What You Need

IBM provides Power Systems Capacity on Demand which makes it easy to activate dormant processor and memory resources already installed in a system (ibm.co/2OunjiH). Allocating dormant resources to experimental LPARs eliminates the need to procure new hardware or to remove resources from other LPARs that may need them.

Capacity on Demand is available in different forms. The static form is intended for adding capacity to meet an overall increase in demand (i.e. the demand is not expected to decrease). Elastic Capacity on Demand serves environments with peak fluctuating loads such as seasonal spikes or period-end processing. Utility Capacity on Demand provides automatic use of on-demand processors to support short and unpredictable workload spikes. The Capacity on Demand offering is flexible enough to support experimental workloads with different resource utilization patterns.

Power Enterprise Pool provides additional flexibility in managing resources while testing workloads. The feature is ideal for moving resources from a test environment to a production environment across servers. Once resource utilization is tuned for the test environment, the same set of resources from the pool is migrated to production with no impact on other resources and no additional resource planning needed.

Sol Lederman is a freelance technology writer based in Santa Fe, New Mexico.

comments powered by Disqus



2018 Solutions Edition

A Comprehensive Online Buyer's Guide to Solutions, Services and Education.


Advancing the Ecosystem

IBM Systems Magazine Subscribe Box Read Now Link Subscribe Now Link iPad App Google Play Store