Years ago, we recognized the potential of running Linux on System z to reduce costs and improve the infrastructure of our information systems. Coming from a background of z/OS and Windows, we weren’t necessarily prepared to effectively exploit Linux on System z. Eventually, we generated a hit list we needed to work through for Linux on System z. As the penguin is the Linux mascot, it seemed natural to phrase the checklist in penguin terms:
• Why penguins (what’s in it for us)?
• Nesting the penguins (hardware environment)
• Feeding the penguins (software environment)
• Protecting the penguins (security and monitoring)
• Working the penguins (deploying Linux applications)
• Hatching new penguins (what’s next?).
Sometimes, getting started is the hardest part. That was the case here. Many conversations, some colorful, covered “why Linux on System z?” It came down to three questions:
• Can we save money?
• Does Linux on System z have the qualities of service we need (reliability, capacity, performance, and availability)?
• How difficult will implementation be?
We debated these questions repeatedly before concluding we were ready to try Linux on System z. We had no experience with AIX, Linux, or UNIX. We thought we could trust Linux on System z; the technology has existed for more than a decade, becoming a mainstream way to do things. This concept is important in conservative IT and business environments where there’s always concern over change and risk.
We committed to leverage our 40-plus year mainframe investment and exploit z/VM virtualization. Just as with Linux, the enterprise’s experience with z/VM was also zero. Eventually, we fell back on our collective trust in IBM mainframe technology. Our experience with z/OS helped us understand that, by levering z/VM and Linux, we would be building on our extensive System z experiences.
What’s in It for Us?
Through some research, we concluded that virtualization with Linux on System z can definitely save money. Our infrastructure of commodity servers is extensive. Licensing software on those servers is expensive and complex. Understanding and managing server software pricing means working with the IBM Processor Value Unit (PVU) licensing structure. The number of PVUs determines how much it costs to run software on a given server-based application between Linux on System z compared to the physical server platform. In the PVU model, IBM assigns a PVU setting to an existing server based on the type of server and number of cores in the server. Software pricing multiplies the cost of the specific software PVU by the number of PVUs across all the servers in the environment where that application runs.
In the case of Intel servers, each physical server typically contains a dual quad-core configuration with eight total cores per server. IBM assigns 100 PVUs per core, for a total of 800 PVUs per physical server. Our typical deployment of an application dedicates physical servers for each environment of that application. Application environments include development, testing, staging, and production. In the case of production environments, we dedicate multiple physical servers for capacity and redundancy.
Our System z configuration includes three Integrated Facility for Linux (IFL) processors; each requires 120 PVUs of software licensing. Given the capacity of the IFLs, we estimate that each IFL can support up to two dozen virtual servers. This substantially increases the number of servers we can execute given a specific PVU price point.
Consider this simple example: a comparison running a hypothetical IBM software product priced at $100 per PVU: