Table of Contents
Advertisement
Overview of z/VM capacity planning
An important element of z/VM capacity planning is knowing what z/VM is good
at: the value of z/VM is its ability to consolidate distributed Linux workloads that
under-utilize CPUs or do not require peak processing at the same time. z/VM
improves the cost and performance efficiencies because it shares CPU cycles
among virtual servers that, if distributed on separate servers, would be idle. There
are three key characteristics that you should look for when deciding whether a
Linux server could be consolidated on z/VM. Look for Linux workloads that:
v Under-utilize CPUs
v Do not require peak processing at the same time as others
v Have idle times, so that z/VM can share processing cycles with other Linux
Distributed servers running applications being considered for consolidation that
run at high utilization throughout the day and peak with other candidate
applications are poor candidates for consolidation. In general, the lower the
utilization of a candidate application, or the more solitary its peaks are compared
to other candidates under consideration, the more likely it can be consolidated.
Likewise, consider a benchmarking strategy that recognizes the real-world
characteristics of your Linux workloads. A typical (inappropriate) approach is to
conduct atomic measurements that compare throughput of a single instance of an
application at a CPU utilization of 100%. This type of benchmarking practice, while
simple and easy to conduct, yields inappropriate and misleading expectations of
capacity because the practice does not incorporate any of the real-world
operational characteristics or highlight any of the elements and advantages of
consolidation. While such benchmark comparisons may be appropriate in a
distributed paradigm for assessing capacity and performance of standalone servers
running a single instance of an application, these comparisons are flawed when
evaluating z/VM and the mainframe. The flaw is that such comparisons inflate the
true operational utilization and throughput of the standalone distributed servers
and do not account for the ability of z/VM to share idle cycles among virtual
servers, which is not possible on under-utilized standalone distributed servers.
Conducting a benchmark in such a fashion simply answers the question that, if
you had one server running one instance of an application at an assumed
utilization of 100%, how much throughput can you expect. In a consolidation case,
that is not the question to ask. The question when designing a methodology for
assessing capacity for consolidation is how many distributed workloads can you fit
on z/VM using the true operational utilization and throughput of those workloads
you are considering.
Once you have selected the right set of applications and their servers for
consolidation, establish a base set of measurements that capture the real
operational throughput of the servers. Figure 4 on page 23 shows a simplified
consolidation example, in which there were many application instances running on
separate standalone servers. Each of these application servers were 10% busy
producing 74 transactions per second.
22
z/VM: Getting Started with Linux on System z
virtual servers.
Advertisement
Table of Contents
