7.5 Why run Linux on zVM?

7.5 Why run Linux on z/VM?

The interest in Linux on the mainframe can be attributed to three things:

• As a source of new technology for mainframe users

• As an opportunity to reduce complexity when deploying an integrated server environment

• As a possibility to host large server farms

z/VM is ideally suited to hosting an integrated Linux server environment, letting companies run applications across multiple images on a single hardware platform. Information technologists can exploit the benefits of having numerous images, each running only one application, and yet limit the costs associated with having unique hardware for each image, as shown in Figure 7-3.

Figure 7-3. Application images can be brought closer to the back-end z/OS (integrated environment)

Many years of product development have made z/VM ideally suited today for Linux deployments. Through the years of product development, z/VM has been designed to support:

• Production systems. Typically, these are single-image operating systems or applications consuming large amounts of CPU, for example, VSE/ESA, or SAP R3 application servers.

• Interactive users. z/VM can support hundreds of CMS users.

• Test environments. These environments can be used for migration, or to test different operating system levels before deploying one.

7.5.1 Why z/VM is ideally suited for hosting large application Linux images

Even today, companies running large z/OS or VSE/ESA systems as guests of z/VM typically have only a few images (maybe just two: one for production and one for testing). The demand on z/VM is to maximize the amount of work that the z/OS or VSE/ESA guests can perform. In the past, this required VM developers to be very efficient in their support of new technologies such as large real memory, advanced disk storage systems, and processor facilities. The goal for supporting guest systems is to give each guest what it needs and get out of the way.

A characteristic of the z/VM operating system that benefits a Linux server environment is the high degree of resource sharing that is achieved with VM's CP. z/VM facilitates sharing processor capacity, main memory, disk devices, channel adapters, network adapters, and practically anything you can attach, connect, or plug into your mainframe among the virtual machines. Note that z/VM allows defining of guests dynamically; no static partitions need to be created ahead of time.

At the same time, if a guest needs sole access to a processor, device, or network resource, that resource can be dedicated to the guest. A hallmark of z/VM is its flexibility in supporting a wide variety of computing requirements. System administrators can mix and match shared resources with dedicated resources on the same z/VM system, and even in the same guest, changing the landscape of the virtual machine configurations, if needed, in a matter of minutes, not hours or days.

7.5.2 Why z/VM is ideally suited to Linux server consolidation

CMS workloads in the past were typically multi-image, interactive workloads. Many companies were deploying hundreds of CMS guests on their VM systems and were asking IBM for enhancements to support that workload. Today, Linux workloads tend to be spread across multiple images and be highly interactive, such as Web-serving workloads. Because of the similarities between Linux workloads and traditional VM workloads, the provisions made to accommodate these workloads also work well for Linux.

The refinements made to VM's scheduler and dispatcher over the course of decades are equally suited for a Linux server environment. This kind of environment requires the facilities to host a large number of images with an unpredictable set of workloads that must meet stringent response-time objectives.

The appeal of z/VM's resource sharing becomes obvious when one considers the amount of wasted resources that typically exist in a discrete server farm environment. It is not unusual for individual servers to have, on average, a utilization rate as low as 3%. Servers with such low utilization are, for example, domain name servers (DNS) where data does not have to be looked up often. A company can have many DNSs. ISPCompany, for example, could have a DNS for each client of its outsourcing business, which adds up to hundreds over time. In general, utilization rates depend on many factors, including:

• The function provided by the application

• Its I/O requirements

• The networking bandwidth

• The number of users or clients who access the application

• The level of technology available in the server itself

Many network infrastructure servers, such as DNSs and firewalls, experience short bursts of activity followed by periods of inactivity. When a server is inactive, its resources are unavailable to other servers that could benefit from additional processor capacity, real memory, network or I/O bandwidth, or disk space. Purchasing server resources to handle application peaks compounds this problem. Processor speed and technology, memory requirements, and all other tangible capital costs associated with a server application are generally measured by how much capacity an application needs when user demand is high. To provide any less resource means potentially falling short of the computing capacity which the application needs at critical times. Unfortunately, this only compounds the waste of system resources when the server is idle or underutilized. (See 3.3.2, "Utilize CPU power.")

In a z/VM world, a server running in a virtual machine can grow or shrink its consumption of available system resources based on application demand. For example, processor cycles that would otherwise be wasted during times of low utilization are available for other images running on the same z/VM system. When resource requirements in a guest exceed expectations, z/VM lets a guest get more cycles or be backed by more real storage, provided no one else with higher priority needs it. Using CP commands, a system administrator can allocate more processor capacity, disk storage, or network bandwidth to the virtual machine when it needs it, not days later. This is possible provided that the virtual resources are available. (It usually takes days to provision a real server to replace the one that no longer meets the customer's need for computing power.)

Figure 7-4 shows many servers with low utilization being consolidated on a mainframe under z/VM.

Figure 7-4. Many servers with low utilization can be consolidated on z/VM

There are other costs associated with separate, seldom used servers. When a server goes idle, it still requires energy, floor space, and other environmental costs such as cooling to maintain its connection to the network and be ready for its next transaction. A guest on z/VM does not represent incremental environmental costs, whether active or idle. The environmental cost of a z/VM system is fixed for a given configuration of hardware and wastes resources only if the server farm in aggregate becomes idle or has low utilization. Studies have shown that environmental cost savings can be realized when running a multi-image server environment on z/VM versus a discrete system solution.