Linux on the Mainframe
| Once Linux was ported to the mainframe, it turned out that its behavior on this platform was quite good. In fact, with Linux on the mainframe, you can:
3.3.1 Scale with the workload
It has been claimed by some experts in the industry that Linux running on systems with multi-CPU capability does not scale well. What would be the point in running Linux on a large mainframe with multiple CPUs? Performance measurements, however, clearly show that many Linux applications on a mainframe scale well. Figure 3-2 illustrates a scalability experiment with a business intelligence workload performed on an IBM zSeries processor. When adding copies of the workload (up to eight), the time that one CPU takes to complete the work increases linearly. The diagram also indicates that when the workload level is kept constant at eight, the time taken to complete the work is halved when an additional CPU is added, then roughly halved again when CPUs are doubled. Finally, we reach a level of eight CPUs running eight workloads. Figure 3-2. Scalability for Linux business intelligence workload. With increased load, response time increases linearly. With added CPUs, it decreases linearly on average.
The ideal scaling behavior of a multiprocessor would be when eight units of work on eight CPUs finish at the same time as one unit of work on one CPU. In Figure 3-2, if you compare the left-most and right-most measurements, they are not far off from that ideal. This experiment clearly indicates that on IBM's mainframe, Linux workloads scale well. 3.3.2 Utilize CPU power
On the mainframe, you can have hundreds of Linux images. The workload management capabilities of the mainframe let you utilize the mainframe to a higher degree than an average server performing a single task. As an example, consider the four stylized workloads depicted as functions of CPU utilization in Figure 3-3. Each workload exhibits a very different behavior from the others over time, but all of them use about 50% of one CPU. One workload uses 100% of the CPU at times and then goes back down to zero again. The others are less radical, but have their own characteristics. Figure 3-3. Workloads using 50% of one CPU
Each of these workloads has a justification for the machine it is on. The two on the left need their machines due to peaks workloads. The two on the right may be running on systems that do not allow a higher utilization for sustained periods of time due to constraints in the application or another part of the system. As an experiment, we will now consolidate the four workloads on a 4-CPU machine. When we build a composite of all four workloads, we get the graph shown in Figure 3-4. The average utilization is still 50%. Using a 4-CPU machine that can sustain a higher utilization than 50%, we can reclaim some of the "white-space" and put even more work on it. Figure 3-4. Utilization after consolidation 50% utilization of four CPUs
Another alternative is to use only three CPUs. If these workloads were running on VM on a 3-way mainframe, VM would manage them in the following way. You would need to decide what workload was your least favored (for example, the topmost workload) and its peaks would get elongated to the right. Or, you could decide to slow all the workloads down the same amount. Notice that just after the highest peaks there is excess capacity. Despite the slowdown, work would be caught up very quickly. When can you stay with the 3-way machine and when would you need a 4-way machine? If Figure 3-4 shows a 24-hour day starting at midnight, the first shift has the highest peaks. There is not much room to grow on the first shift. If you needed to add work on the first shift, that would be a reason to go to a larger machine. Similarly, if none of the first shift workloads could afford elongation (for example, if it was real-time work), you would need a 4-way machine. Most of the time, there is capacity to spare. For the first quarter of the chart, utilization is at 2.2 to 2.3 CPUs. In the second quarter of the chart, average utilization is probably around 2.7 to 2.8. On a mainframe running z/VM or z/OS, that level of utilization is not a problem. In fact, there is room for even more work. These sample workloads are obviously made up to show different behaviors rather than to provide a good consolidation example. Larger numbers of unpredictably behaving workloads turn out to be statistically favorable for a consolidation solution. Later (see Chapter 6, "Total Cost of Ownership: the Challenge") we will look at what kinds of workloads make a favorable consolidation case. |