Trends > Linux

Multiple Savings with Server Consolidation

Understanding SCON and total cost of ownership with Linux for zSeries

In today's business environment, IT organizations are faced with a variety of pressures, including managing the complexity of expanding server farms and networking infrastructure, and retaining skilled programmers and administrators.

If that isn't enough, IT organizations are being pushed to effectively apply computer resources to boost various corporate initiatives such as refining process integration across the organization and improving the interface with suppliers and customers, all while exploiting the Internet (as well as intranets and extranets) to enhance communication and reduce cycle times.

What's the solution?

Consolidating distributed computing environments onto Linux* virtual servers running on zSeries* can deliver impressive cost savings, while providing a better platform for delivering more value from computing resources.

In this article, we'll examine several aspects of server consolidation (SCON) and total cost of ownership (TCO) when using Linux for zSeries.

We'll look at the features of zSeries systems that form the basis for effective SCON. This includes the latest eServer z900 and z800 hardware features, as well as some of the key capabilities of z/VM* to virtualize the hardware resources and support multiple instances of Linux running on these machines.

Then we'll examine deployment models that customers have used for SCON. Finally, we'll review issues to consider before starting a SCON project for Linux for zSeries.

TCO Advantages
Linux on zSeries delivers lower TCO. Using z/VM, users can create multiple instances of Linux running on a single zSeries system. Each instance is called a Linux virtual server. Each Linux virtual server can run the workload from a UNIX* or Intel*-based system from a distributed server farm. This consolidation reduces the number of server boxes and amount of networking infrastructure needed to connect servers.

Additional savings come from software license costs. Instead of tens or hundreds of licenses (one for each server), licenses are only required for the CPUs within the zSeries system running Linux. Fewer administrators, managing a set of Linux virtual servers under z/VM requires fewer resources than overseeing a large server farm, also providing cost savings. When IT staff is free from the day-to-day operation of a sprawling server farm, it can address strategic needs and deliver greater business value. TCO savings and tools are further examined in "Removing the Paralysis From Analysis."

When consolidating servers on Linux for zSeries, consider the servers' type of workloads. Many different workloads can be effectively consolidated, but not all workloads are good candidates for consolidation. Many workloads can be consolidated from Intel-based or UNIX servers (see Figure 1). Customers have deployed Linux on zSeries for a variety of workloads including:

• Networking infrastructure
• Web serving
• Web application serving
• Mail and messaging
• Application serving

CPU-intensive workloads with low levels of network I/O or low volumes of DASD I/O aren't good candidates for consolidation.

Different models exist for how to run the workload once it's consolidated. There's a straightforward, one-to-one model, where mapping each Linux virtual server runs the workload from one distributed server. This model uses the horizontal scalability capabilities of z/VM for consolidation. Another approach is to consolidate multiple distributed servers into a single Linux virtual server. This relies on vertical scalability from strong SMP scaling.

Some have expressed concern that SMP scalability on Linux is limited to less than 4-way scalability.Figure 2 shows several measures that achieve high levels of SMP scalability on zSeries.

One measurement is for a WebSphere* workload that shows close to linear scaling up through an 8-way system. Another measure is a Java* workload modeling simple transactions that scales up through a 10-way SMP. Finally, there's a business intelligence (BI) workload. Smooth scaling of this workload occurs whether the load is increased or if the number of assigned CPUs is increased. First the workload is increased while running with only one CPU. This shows linear response to the workload increases. When the number of CPUs is increased to eight, adding processing power provides linear improvement to the performance of this workload. Using the final model of deployment, you can mix the horizontal scalability that z/VM provides with vertical SMP scalability.

Hardware Features for SCON
For many years, zSeries systems have provided industry-leading capabilities for workload consolidation. Linux for zSeries builds on this, offering the ability to consolidate new workloads that previously didn't run on zSeries.

Linux for zSeries benefits from three decades of design hardware and virtualization investment. To manage multiple workloads, the capability to switch between multiple processes is critical. The capability to perform context switching efficiently allows users to run hundreds of Linux instances on a zSeries.

Figure 3 shows a comparison in the performance for a zSeries and an 8-way Intel-based server. The chart shows the time to switch between processes, looking at both the number of processes and the size of the data space for each process. While the Intel-based system takes significantly longer to switch between processes (especially with larger data spaces), the zSeries system provides consistent response across the range of measurements.

Another important aspect of zSeries that enables SCON is the design of its I/O and memory subsystems. The zSeries channel architecture provides efficient sharing of I/O adapters and high bandwidth data transfers. The memory hierarchy design allows zSeries to handle data-intensive workloads effectively. This includes BI workloads and "cache killers" like object-oriented code. The I/O and memory systems are key to the SMP scalability that can be achieved on zSeries.

Hipersockets provide high-speed communication among Linux virtual servers and Linux and z/OS* workloads running on the same system. Hipersockets are an optimized TCP/IP implementation that uses memory-to-memory transfers, instead of communicating "over the wire." Applications don't need to be altered to exploit hipersockets; they still can communicate with standard TCP/IP protocols. But the data communication gets a performance boost. Figures 4 and 5 show the benefits. Figure 4 shows the performance gains for interactive transactions, using a request-response (RR) model with a profile similar to the transfer rates for simple Web serving. Figure 5 shows the bulk data transfer rates similar to data streaming. While there's a significant boost to the data-transfer performance, end-to-end application performance benefits in proportion to how much of the application time is spent in data transfer.

In addition to the performance benefit, hipersockets also provide cost savings by reducing the networking hardware needed to interconnect servers. Hipersockets offer an advantage in security and reliability of networked servers. Fewer components are subject to failure, and there's less opportunity for security threats during communication among the servers.

While the aforementioned zSeries architectural features focused on consolidation and performance, the Integrated Facility for Linux (IFL) focuses on managing the overall software costs for customers deploying Linux on zSeries. IFLs are zSeries CPUs that are constrained to only run Linux or Linux virtual servers under z/VM. The processing capacity is dedicated to Linux and can't be used for traditional workloads. Therefore, customers can add capacity to their zSeries to run Linux without incurring the additional software costs associated with adding standard processing engines.

Features of z/VM for SCON
z/VM is the foundation of the environment enabling Linux virtual servers. z/VM has a long history of virtualizing system resources and providing an environment for application execution, providing scalability, flexibility and robustness for multiple workloads sharing physical resources. The virtual machine in which Linux runs, simulates the existence of a real, physical machine, including the processor, storage and I/O resources. Here are some of the important SCON highlights.

One important set of z/VM capabilities is focused on providing control over how the shared physical resources are prioritized among the virtual servers. The SET SHARE command can be used to prioritize and set limits for CPU, storage and paging. This can be set programmatically or changed at run-time to address changing demands on the system. It's also possible to set both hard and soft limits on resource usage. A hard limit can't be exceeded; a soft limit may be exceeded but only if available, unused resources exist. Other controls allow I/O throttling so that no single virtual server consumes all of the I/O capacity starving other virtual servers.

In-memory technologies from z/VM improve overall system performance. Virtual disks in storage can be used to boost caching performance. Minidisk caches can provide rapid access to shared data.

z/VM also can be used in high-availability configurations, offering features to automate the take-over of workload in the event of a failure. Also, virtual servers can be configured for hot stand-by. Unlike distributed physical servers that consume power, occupy floor space and need administrator attention, virtual stand-by servers don't consume any resources unless there's a primary server failure and they need to take over the workload. Only as they take over the workload do they start to consume resources like CPU and memory.

A key component of Linux virtual servers is the guest-to-guest communication channels. z/VM provides a range of connectivity options among the virtual servers including: IUCV, VCTC and hipersockets (including hipersockets guest LAN). These are detailed in "Consolidation Combination" (July 2002).

As You Begin
Customers who have been successful in initiating SCON projects with Linux virtual servers have had one aspect in common: a strong champion within the organization. Typically, this person has a vision of both the cost savings potential from SCON and how consolidated servers will provide a strong base for strategic efforts within the company. Without a strong champion, consolidation efforts can be easily bogged down with internal politics and a lack of focus on addressing issues that may arise.

Another important aspect of successful deployments is to start small. Choose an application and set of servers that can be easily consolidated. Use this as a pilot project. Put measurements in place for this pilot project and track it as you would for any other IT project. It's often easiest to start with a couple of infrastructure workloads such as file and print serving or DNS and proxy serving.

Many successful deployments begin with an analysis of the savings in TCO. Customers can use one of the tools available (TCOnow!) or a service like IBM's Scorpion Studies to understand the savings they should expect. Identifying savings provides a clear goal and a measurable objective.

Common characteristics also exist among the unsuccessful SCON projects. One pitfall can be the internal politics between the distributed computing camp and the mainframe camp. The distributed computing organization may see SCON projects as an effort to put IT back into the "glass-house" environment. One way to diffuse this issue is to separate the application management and administration from the machine management and administration. Often the distributed team has the application management skills that are still needed for success after the consolidation. The mainframe team can focus on configuring virtual servers and managing the hardware.

Conclusion
As you define your consolidation project, use these characteristics to help manage the project through the initial pilot into full production deployment. Other system-management issues must be considered at the outset, so that when you're ready for production, the transition is smooth.

For instance, how will your consolidated workload integrate into your system management tools and procedures? Will you continue using the same tools and procedures as with your distributed servers or integrate completely into your mainframe administration procedures?

Among the areas of system management to consider are the backup and restore for data management, clustering and availability products used with the distributed workload, and security. By considering these aspects at the outset of an SCON effort, you can guarantee a more successful deployment.

Next page: >>