Linux on System z, an end-to-end view: from Sizing to Performance Analysis to Capacity Planning

November 10, 2006

Dennis Mosby - Certified I/T Specialist Eduardo Oliveira - Sr. Certified I/T Specialist

Techline Americas IBM Sales & Distribution dmmosby@us.ibm.com eduardoc@us.ibm.com

2

Table of Contents

PREFACE 3

About the authors 3

Acknowledgements 4

DISCLAIMERS 5

INTRODUCTION 6

OVERVIEW OF LINUX ON SYSTEM Z SIZING TOOLS 6

OVERVIEW OF OUR SIZING AND CONSOLIDATION 9

DESCRIPTION OF SERVERS TO BE CONSOLIDATED 10

SIZING PROCESS AND PROJECTIONS 11

THE LINUX QUICKSIZER METHODOLOGY 12

THE LINUX SERVER CONSOLIDATION (LSC) METHODOLOGY 15

ACTUAL RESULTS ON TARGET SERVER USING ZCP3000 19

GROWTH PROJECTION WITH ZCP3000 24

FUTURE RESEARCH AREAS 27

CONCLUSION 28

3

Preface

About the authors Dennis Mosby is a Technical Sales Specialist with Techline, Americas. His responsibilities include technical support for System z hardware, z/OS, z/VM, and Linux on System z. He joined IBM in 1983 and previously worked in Sales as a Senior Systems Engineer and in IBM Global Services as a Large Systems and Storage IT Specialist and as an IT Availability Manager. He holds a Bachelors Degree (1972) in Mathematics from the University of Tennessee, Knoxville, Tennessee. Eduardo Costa de Oliveira is an IBM Senior Certified IT Specialist with the Americas Techline since 1998. He joined IBM as an Associate Engineer in 1986 and previously held technical positions in the IBM Microelectronics Toronto Lab and in the former IBM Sumare Plant (now Solectron). He also spent over 18 months in international assignments in the former IBM Endicott Glendale Lab (NY), IBM Boeblingen Lab (Germany), and IBM Kawasaki (Japan). He holds a Masters Degree in Computer Science - Software Engineering (1997) by the University of Waterloo, Ontario-Canada, and a Bachelors Degree in Electrical Engineering (1985, Electronics) by the State University of Campinas (UNICAMP), Campinas, State of São Paulo, Brazil. Mr. Oliveira is fluent in English, Brazilian Portuguese, and Spanish.

4

Acknowledgements Thanks to the following professionals for their technical review and proofreading: Alex Choung, Techline Americas, Atlanta Richard A. Hanson, Techline Americas, Atlanta Fausto M. Vasquez, Techline Americas, Bethesda

5

Disclaimers § Sizing estimates are based on industry experience, knowledge of machine

architectures and available specification data. In actual use, relative capacity and costs can and often do vary significantly from these estimates. The user should validate sizing and cost assumptions throughout the various stages of any IT project. IBM makes no guarantee but only can assure that this is our best effort to estimate the costs incurred and value delivered.

§ This presentation and charts are for information/presentation purposes only and

in no way are intended to be example of what individual customer situations would encounter nor a commitment or guarantee of any kind by IBM.

6

Introduction Critical enterprise Linux applications are being deployed in ever increasing numbers on IBM System z and zSeries servers. Sizing the server to support those critical workloads is especially important. Equally important is the on-going capacity planning of z/VM and the Linux workloads. The purpose of this paper is to provide information on sizing tools and provide guidance on sizing and capacity planning for Linux workloads that run on System z. One of the responsibilities of IBM Techline is to perform Linux on System z workload sizings. When we made presentations about Linux on System z sizing, questions were raised about the accuracy of our projections. Because we were receiving informal feedback of our sizing projections and not details, we could not thoroughly answer those questions. Therefore, desiring to answer customer questions and our own, we decided to do our own Linux server consolidation from Intel servers to a zSeries server, size the capacity needed, move the workload, use zCP3000 to analyze the utilization, and report the details.

Overview of Linux on System z Sizing tools First, a brief description of the various tools available to size Linux workloads that will run on System z servers.

• zSeries Processor Selection Guide (zPSG) provides System z and zSeries processor sizing estimations for new applications and should be used when applications are under development or when application profiles are available. For Linux workloads, zPSG supports applications using the IBM WebSphere Application Server and the Apache Webserver.

• zSeries Processor Capacity Reference (zPCR) provides capacity

planning insight for System z9 and zSeries processors running workload environments under z/OS, z/VM, and Linux and using various LPAR partition configurations. The tool’s LPAR Configuration Capacity Planning function projects capacity expectation for individual partitions and for the LPAR host as a whole. The capacity information learned from other sizing tools, such as the zPSG mentioned above or the tools listed in the next section, can be merged as a new partition to an existing host and the new capacity requirements for that host can be seen. The LPAR Capacity Comparison Report provides a capacity perspective for a planned new

7

partition relative to the capacity being consumed on the current processor for this workload.

• Linux Rule of Thumb Quicksizer tool is typically used in determining

whether a Linux consolidation project is within the customer's budget and whether TCO and server consolidation studies should be pursued with the customer. The sizer provides an estimate of the System z capacity needed to match what is currently in use on existing servers; therefore, we need to know some information about the source servers, like make and model, speed of the processors in megahertz, and peak utilization. The source servers can be IBM or servers from other vendors. The tool considers the raw capacity of the source servers and their utilization, adjusts for workload characteristics, and compares to the capacity on the target zSeries server. The Rule of Thumb Quicksizer does allow for the presence of z/VM in the required capacity. The sizings completed with the Quicksizer must be followed by a formal Linux Server Consolidation (see below) sizing with IBM Techline.

• Linux Server Consolidation tool provides an estimate of the zSeries

capacity needed to match what is currently in use on existing servers and is similar in methodology to the Quicksizer described above. However, the Linux Server Consolidation tool provides better accuracy than the Quicksizer because it refines the sizing based upon a “workload factor”. Besides the make and model, speed of the processors in megahertz, and peak utilizations of the source servers, the Linux Server Consolidation questionnaire asks for additional information on workload characteristics, such as the number of concurrent users during peak, whether throughput is gated by CPU resource contention or I/O resource contention, and whether the workload has tight or wide address reference patterns. Another significant factor the tool considers is the timing of workload peaks on the various servers. Since zSeries is good at managing multiple workloads effectively, server consolidation of many servers with different workloads can work very well, especially when the various workloads tend to peak at different times. The Linux Server Consolidation tool allows for the presence of z/VM.

• Communication Controller for Linux (CCL) Sizer provides an estimate of

the System z and zSeries capacity executing the Communication Controller for Linux needed to match what is currently in use on 3745 Communication Controllers. Communication Controller for Linux on System z is a software product that emulates 3745 hardware. The CCL sizer is based upon benchmark performance tests with defined workload characteristics. The sizer considers transactional SNA Network Interconnect (SNI) and Boundary Function (BF) workload types. The workload utilization from the source 3745 controllers can be in terms of peak transactions per second,

8

peak bytes transferred per second, or peak percent Central Control Unit (CCU) utilization.

• zCP3000 is a tool designed to do capacity planning for IBM zSeries, S/390,

and IBM compatible S/390 processors running various SCP/workload environments. The zCP3000 VM extract utility (CP3KVMXT) is a VM-based utility that builds a zCP3000 input file from key performance measurements. Together, the two tools can provide capacity planning data for multiple Linux guests running under z/VM. In VM, "workloads" are groups of VM userids representing different business units, which can grow at different rates in the zCP3000 capacity planning model. CP3VMXT allows user-defined workload groups, like LINUXDB or LINUXWEB, to group multiple, related Linux guest machines into one workload so that the same growth rate can be applied to the whole group. The insight gained from CP3KVMXT/zCP3000 can help determine if the current capacity of resources (IFLs, memory, I/O) is sufficient to handle various growth scenarios, such as additional Linux consolidations or new Linux applications or more users.

The following table summarizes the sizing tools for Linux workloads discussed above, when they are to be used, and from whom they are available.

Available Planning Data Model with Available via

New WebSphere or Apache webserver; rates & sizes estimated zPSG IBM Representative, IBM

Business Partner Merge consolidation sizer input into

existing, partitioned zSeries processor

zPCR IBM Representative, IBM

Business Partner, customers via web download

Existing application Servers, peak utilization

Linux ROT Quicksizer

IBM Techline (engaged via IBM Representative)

Existing application Servers, peak utilization, workload

characteristics

Linux Server Consolidation

IBM Techline (engaged via IBM Representative), IBM

Regional Designated Specialist

Trans. per second, bytes per second transfer rate, or CCU % util.

of 3745 CCL Sizer IBM Techline (engaged via

IBM Representative)

Existing Linux servers under z/VM, Measurements from z/VM

CP2KVMXT & zCP3000

IBM Techline (engaged via IBM Representative), IBM

Representative, IBM Business Partner

9

Overview of our Sizing and Consolidation To keep it simple, we decided to begin with a well-known and frequently used application that is available in all Linux distributions: webserving with the Apache HTTP Server from the Apache Software Foundation (www.apache.org). The webserving application was a cgi script that scans files, extracts data from the files, and builds the html page to return to the requester. We plan to look at other workload types (WebSphere Application Server, DB2, MQSeries, Domino, and others) as future studies. We have three Intel based servers available in Techline, so we implemented the Apache HTTP Server on those machines. Using a tool which has the ability to generate and sustain server overload (httperf), we sent http requests to our servers at a specific transaction rate and measured the peak processor utilization with the Sysstat system monitoring tool (SAR command). Using information about the performance characteristics of our servers and the utilization, we performed a Linux Server Consolidation sizing with a target server being an IBM zSeries 800. To introduce the idea that the peak utilizations on the source servers do not occur at the same time (non-concurrent peaks), in our scenario, we will assume each server is located in different time zones of the world, like New York, London and Sydney. To compare sizing accuracy and results, we used both the Linux Server Consolidation tool and the Linux Rule of Thumb Quicksizer in our study. Next, we implemented the Apache HTTP Server on Linux running under z/VM V5.1 on an IBM zSeries 800 server. We sent http requests at the rate of the sum of the rates sent to the Intel servers and captured the utilization with the z/VM Monitor. Using the VM Extract Utility for zCP3000 (VMXT) and zCP3000 Capacity Planning tool, we compared the projected utilization from the sizing tool to the actual utilization on the z800. We also used the zCP3000 Capacity Planning tool to make growth projections of the Linux workload and compared the tool’s projected utilization with growth to the actual utilization.

Apache Webservers z800

z/VM Linux Apache

Consolidate Workload

10

The rest of this paper will look in detail at the steps outlined above. We will describe the process and findings and provide helpful hints if you want to do your own z/VM-Linux workload capacity planning.

Description of servers to be consolidated To perform a consolidation sizing of a workload from one architecture to another, it is necessary to have a thorough understanding of the source servers (the servers from which the workload is moving), the type of workload, and the peak processor utilization of those servers.

1. Hardware description of source servers:

In our study, there are three source servers. The hardware detail for each server is listed in the following table:

Vendor Model/Type Number of processors

Clock Speed

Memory L2 cache

IBM xSeries 225 (Intel) 8649-6BX

1 3.06 GHz 512 MB 512 KB

IBM xSeries 206 (Intel) 8482-4MU

1 3.20 GHz 512 MB 1 MB

IBM Intellistation Mpro (Intel) 6230-46U

1 3.20 GHz 1 GB 512 KB

2. Source servers software and application: The software detail for each server is listed in the following table:

Server Linux distribution Kernel level Apache release xSeries 225 8649-6BX RedHat 9.0 2.4.20 2.0.40 xSeries 206 8482-4MU SuSE SLES 9 2.6.5 2.0.49 Intellistation 6230-46U SuSE SLES 9 2.6.5 2.0.49

The target webserving application was a cgi script that scans files, extracts data from the files, and builds the html page to return to the requester. The cgi script is the sample “info2html” script provided on most Linux distributions.

3. Transaction rates and peak utilizations of source servers:

Using the http request generation tool on a machine separate from the webserver, we sent http requests at a set transaction rate across the network to the each of the three servers listed above and captured the processor utilization with the SAR command.

11

Below is an example of the output from the SAR command from one of the servers while http requests were being sent to its Apache webserver: Linux 2.6.5-7.97-smp (techline-x206) 05/16/06 09:56:46 CPU %user %nice %system %iowait %idle 09:56:48 all 0.00 0.00 0.00 0.75 99.25 09:56:50 all 7.48 0.00 0.75 0.00 91.77 09:56:52 all 10.75 0.00 0.75 0.00 88.50 09:56:54 all 11.00 0.00 1.00 1.25 86.75 09:56:56 all 10.75 0.00 0.75 0.00 88.50 09:56:58 all 10.78 0.00 1.00 1.00 87.22 09:57:00 all 11.00 0.00 0.75 0.00 88.25 09:57:02 all 10.75 0.00 0.75 0.00 88.50

From this output we can conclude our peak utilization to be approximately 13% (rounded). We ran the same transaction rate a few more times to be sure the results were consistent. The table below shows the transaction rate and resulting utilization for each of our servers: Server Transactions per second Processor Utilization xSeries 225 8649-6BX 2 6% xSeries 206 8482-4MU 3 13% Intellistation 6230-46U 3 22%

Sizing process and projections Once we had the results from the Intel based boxes, the next step was to perform a full server consolidation study for Linux on System z. We decided to approach this step using the two tools we have at our disposal:

- The Linux Rule of Thumb QuickSizer (Linux QuickSizer) - The Linux Server Consolidation (LSC) tool

The Linux QuickSizer requires less data as input and is easier to use; however, the projections can be less accurate than the projections obtained using the LSC tool, which requires more data. Both tools are described earlier in this paper. By using two different tools to perform the sizing, we hope to gain insight into the trade-offs and issues involved in a Linux QuickSizer analysis versus the full Linux Server Consolidation analysis. We will comment on those issues in this paper. It is important to mention, at this point, that sizing DOES NOT PRODUCE EXACT results. The entire process attempts to produce the best possible capacity

12

projection based upon limited data. Nothing can replace the process of implementing a pilot environment and rolling out the application step by step, measuring actual utilization of every action, every new set of users added, and every new application executed. However, in lieu of actual measurements and results, the next best thing one can have is a sizing projection.

The Linux QuickSizer Methodology When one requests a Linux QuickSizer study from Techline, we first point the requester to a URL which contains the Linux QuickSizer questionnaire. The reason why there is a questionnaire is to standardize the data collection process and to provide the sales representative with the proper text to be brought to the customer. Currently, the Linux Rule of Thumb (ROT) QuickSizer Questionnaire can be obtained by IBM employees at the following URL: - Linux Rule of Thumb (ROT) Quick Sizer Questionnaire

http://w3-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/PRS649 If you do not have access to the IBM Intranet, please contact TECHLINE to receive a copy of this document. Techline can be reached at techline@us.ibm.com (at this time, there is no external copy of the document in the Techdocs). To give you an idea of what information is required for IBM Americas Techline to perform this study, below is a sample of the data required:

Fill in the information below for each type of existing server that will be consolidated into the zSeries or S/390 server. Replace the sample input shown below with the customer’s input. Add rows if more servers need to be described. Alternatively, provide a separate file with the information requested below.

Type of servers

Model # of server

s

# of processors per server

Processor Speed

Utilization Type of workload

1 pSeries XXXX 2 4 500 MHz 60% DB servers 2 xSeries YYYY 4 2 3600 MHz 15% Lotus Notes servers 3 Non-IBM

Unix ZZZZ 1 2 400 MHz 30% DNS server

4 Non-IBM Intel

WWW 2 2 1800 MHz 10% Apache Server

The table above lists the information required. It also illustrates why this is called a “QuickSizer” since it does not require many, nor detailed entries.

13

The information required begins with the type of server to indicate the technology of the current platform. The tool allows us to consolidate IBM and non-IBM machines. Most entries are self-explanatory, like the number of servers being consolidated, the number of processors per server (n-way), the server’s operational frequency (in MHz), the current servers’ utilization, and the type of workload being executed in the servers. Note that one question that is not included in the questionnaire is the type of System z technology the client would expect to consolidate the servers on. In this study, we will use the z800 family of processors. We will use this questionnaire to define our consolidation project. These are the servers we will consolidate:

Server Transactions per second Processor Utilization xSeries 225 8649-6BX 2 6% xSeries 206 8482-4MU 3 13% Intellistation 6230-46U 3 22%

Let us then complete our QuickSizer Questionnaire’s table using the entries above: Type of

servers

Model # of servers

# of processors per server

Processor Speed

Utilization Type of workload

1 Intel 86496BX 1 1 3066 MHz 6% Apache server 2 Intel 84824MU 1 1 3200 MHz 13% Apache server 3 Intel 623046U 1 1 3200 MHz 22% Apache server Based on the above input, we used the Linux QuickSizer tool and came up with the following sizing estimates when projected in a z800 System z machine: From Customer:

Number Server Arch. % CPU Number Intel/Unix Desired Linux Server of Util on of Clock % CPU Util Description Servers Source CPU's/ Speed of IBM server

in Group Server Server MHz Server Group 1 1 Intel 6 1 3066 100 Server Group 2 1 Intel 13 1 3200 100 Server Group 3 1 Intel 22 1 3200 100

14

Sizing ROT Estimate:

Target IBM Server z800 (G5, G5T, G6, G6T, z800, z890, z900, z900T,

z990, T for Turbo models, z9EC, z9BC)

Estimate: #IFLs 2.4 IFLs - Linear method (formula L)

330 MIPs (pm) Exponential method (formula E) VM assumed

As you can see, the results are actually provided in two different calculations:

- An estimate of how many IFLs would be required in the target technology (z800) using a linear method

- An estimate in MIPs using an exponential method - This tool included 15% for z/VM utilization

The actual methodology of making the projection is IBM Confidential and cannot be disclosed; however, we will compare both results in our analysis and take the worst case scenario. Please note that MIP rating is not the best way to evaluate the capacity of a System z server. While MIPS may be useful for rough processor positioning, they should never be used for capacity planning purposes. Single-number processor capacity numbers like MIPs are inherently prone to error because they are not sensitive to the type of work being processed. There are appropriate tools available to customers, like zPCR, that implement the LSPR comparison, which is less prone to error than MIPs, in an easy way. However, in this specific scenario, the estimate of 330 MIPs was given by the exponential formula of the QuickSizer tool and will be taken into account in our analysis. The question is: Which estimate constitutes the worst case scenario? IBM does not publish MIPs numbers for its System z servers. There are many published sources of processor capacity data available in the industry today and if you “Google” the words “z800 MIPs”, you can find those sources. Remembering that an IFL is a full speed engine, one can use the numbers as follows: one z800 IFL as approximately 192 MIPs, 350 MIPs for two, and 499 MIPs for three IFLs. Using the above information, 330 MIPS would be approximately 1.9 IFLs. Therefore, the worst case scenario would be the result where the number of IFLs was forecasted to be 2.4 IFLs. Let us then use this number as the final sizing result for our environment.

15

The Linux Server Consolidation (LSC) Methodology As mentioned in the previous section, the Linux Server Consolidation methodology requires more input information. However, since it has more parameters from which we can gain insight and that we can control, its results are more likely to be closer to the actual utilization one would see on the real hardware. The LSC process starts very similarly to the previous Linux QuickSizer process. There is a questionnaire with more questions for the customer to complete. The URL below provides where IBM employees can find the LSC questionnaire: - zSeries Linux Server Consolidation Sizing Questionnaire http://w3-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/PRS1423 If you do not have access to the IBM Intranet, please contact TECHLINE to receive a copy of this document. Techline can be reached at techline@us.ibm.com (at this time there is no external copy of the document in the Techdocs). As explained earlier, the LSC tool requires more information than the Linux QuickSizer tool. For example, below you will find a portion of the sizing questionnaire sent to the client (with input customized to our consolidation scenario):

1. Specify the zSeries processor on which the workloads will be consolidated (at a minimum specify the processor family). If known, specify the number of physical processing engines used by the LPAR.

Family (Examples: 9672 G6, z800, z890, z900, z990):

Z800

Processor Model: (For z990, please use the “model” numbers that indicate the number of engines configured in the processor, e.g. 301, 302, etc. not the actual model numbers of A08, B16, etc.)

2066-002

Number of physical CPs/IFLs to be used by the consolidated workloads (if known):

2

Will Linux images run in VM guests? Yes As you can see, the questions above are simple, but enough to indicate an extra level of detail that was not present on the Linux QuickSizing study. The next question is shown below:

2. Which approach have you used for input on CPU%? (mark appropriate box)

Overall peak has been determined and CPU%s are from the same time interval

X Peak CPU%s may be from different time intervals

16

In our scenario, each server we are consolidating is located in a different part of the world, in New York, London and Sydney. It is very likely that, due to the time zone differences, the peaks are not happening at the same time. The next item asks for the application description and it needs to be repeated as many times as the number of servers being consolidated. Since all three servers are running Apache webservers, the closest description for all servers’ applications are “HTTP Server, general usage”. 3. Application 1 Name or Type of application: ………………………………………………………… Specify type of workload / software used (type in adjacent column and/or mark in the list below of common types of workloads):

• Web serving: X_HTTP Server, general usage __HTTP Server with static files __HTTP Server with JSPs __HTTP Server with EJBs __HTTP Server with CGIs __HTTP Server – heavy graphics

• Web Application Server (WAS, Weblogic) __With substantial Java application __With little Java content

• Mail Server __Domino NRPC (Notes) __SMTP __SAMS __POP __IMAP

• __File/Print Serving (Samba) • __Network Print Serving • __OLTP • __Internet Service Provider (ISP) • BI data warehouse

__Simple query __Complex query __Complex query with heavy parallel

• Data Base Server __Production __Program development

• __LDAP Server • __DNS Server, Router, Firewall • __Sprayer (workload balancing) • __FTP • __DB2 Connect (or Type 4 JDBC remote DB access)

Total number of servers or LPARs running this workload: (It should match the number of Servers in column 1 below)

17

One important observation we could make from the final results (real measured results on the z800) is that the correct selection of the workload type plays a paramount role in the accuracy. It is very important for the person performing the sizing to ask the right questions, even if the questionnaire was returned to Techline completed. The issue here is that a minor change in the LSC tool’s parameters can produce a significant change in the estimates. By talking to the client about his/her questionnaire and computing environment, the IT Specialist will get a sense of whether he/she can take the information as provided or if there is a need to “override” some information based on the experience and skills of the specialist. For example, information that sometimes needs overriding after long discussions with the requester about the meaning of peaks and average peaks is in the area of the provided server utilization. The next step of the sizing requires the information below: Description of servers No. of Servers

Vendor and Model/Type

No. of CPU Engines

Clock Speed in MHz

Avg CPU% for Peak 15-30 Minute Interval

Timeframe of Peak (i.e. Hr of Day, Week, Quarter) EST

1 IBM 8649-6BX 1 3066 MHz 6% 9:00AM – 9:30AM 1 IBM 8482-4MU 1 3200 MHz 13% 3:00AM – 3:30AM 1 IBM 6230-46U 1 3200 MHz 22% 11:00PM- 11:30PM

The most common inaccuracy on the server description is the reporting of the CPU percent utilization. Depending on the server’s technology, the actual, reasonable utilization is usually much lower than what the client’s report. This is an area the IT Specialist performing the sizing should always pay attention to and challenge the requester to obtain more realistic numbers. The next information required is the characteristics of the workloads. Again, since we are using the same workload for all three servers being consolidated, a single entry can suffice here. Description of workload (mark only one box for each Question) Q1. Number of concurrent users during peak interval: X 10s of users or few batch

jobs 100s of users or 10s of

jobs 1000s of users, 100s of

jobs If workload is not a common one (i.e. HTTP server, router, firewall, DNS server, Samba file/print server, web application server, mail server, DB server, etc.), describe the following workload execution characteristics: Q2. User or job characteristics (with regard to importance, priority, response time needs, type of processing) Similar In between Diverse Q3. Throughput is gated by: CPU resource contention Neither I/O resource contention

18

Q4. Address reference patters are: Tight or with minimal data

movement Nominal, moderate Wide or with lots of data

movement Q5. Does not apply to Linux (The sizing team will use 2 as the default response). Q6. Affinity of users or jobs to data is: High, maybe with

partitioned data Nominal Low, any user might

address any data Note that, for Q1, we are using tens of users on each server. Questions Q2 through Q6 are required only if the workload being consolidated does not fit within any of the pre-defined workloads listed earlier. In our case, we know the workloads are defined as “HTTP Server, general usage”; therefore there is no need for us to pursue more answers because this is a well-known, pre-defined workload. This completes the information that can be extracted from the Linux Server Consolidation questionnaire. Again, the internals of this tool are classified as “IBM CONFIDENTIAL”; therefore, we will only show in this paper the “client’s deliverable” output. This is typically how the input is presented to the customer:

Below are the results of the sizing, already in terms of the z800 2066-002 we used to consolidate the workloads.

**

Utilization ReportProcessor utilization values include additional 15.00% for VM Operating Environment

Techline Servers: Consolidating 3 applications running on 3 servers Date of analysis: 09/14/2006

System z9 or zSeries Case-1 Case-2Peaks are Peaks are

Processor Feature MSU Complimentary Concurrent Complimentary Concurrent

1 2066-001 1W 32 84% 119% 0% 0%2 2066-002 2W 60 45% 63% 0% 0%34

19

As you can see, the results from the LSC tool are presented in a different format than the results provided by the Linux QuickSizer. Also notice that the processor utilization includes an additional 15% for the VM Operating Environment. Although the percent utilization for the VM Operating Environment could be somewhat too high for this small workload, we decided to use it in this case study because it is the default amount in the tool and it does not influence the sizing estimate results as much as other factors, such as input utilization or workload characteristics. The final results in our consolidation scenario show that we will take 45% of a 2-way z800 where the Central Processors (CPs) or IFLs are at full speed (model 002). At this point we can see some significant discrepancy between the results obtained using the two methodogies. The Linux QuickSizer calls for 2.4 x IFLs @ 100%; the Linux Server Consolidation tool calls for 2.0 IFLs @ 45%. We can guess the LSC tool would be closer to reality since it uses more sophistication; however, one cannot yet tell. The final word will be given by implementing the same workloads from the three source servers on the real z800 server and that is the scope of the next section.

Actual results on target server using zCP3000 Finding an available zSeries or System z machine for our study presented a challenge. Eventually, we were able to use an LPAR on a z800 (2066-002) that was already running with z/VM 5.1 at the ATS eServer Technical Center in New York. Because of the z800 architecture and which Linux distributions were available to us, we decided to use SuSE SLES8 on this machine. The software detail for the target server is listed in the following table: Server Linux distribution Kernel level Apache release zSeries z800 2066-002 SuSE SLES 8 2.4.19 1.3.26 We defined our guest Linux machine in the z/VM directory using DIRMAINT, set up the network to the Linux machine, installed SLES8, and enabled the Apache webserver. When we tested with the http requester to the webserver, we discovered another problem. We were only utilizing one processor even though we knew that there were two processors on the machine and the LPAR running z/VM was assigned two processors. We corrected this by changing the MACHINE directory statement for the Linux guest machine. The MACHINE statement specifies the virtual machine architecture and the maximum number of virtual

20

processors the user can define. After the update, we were utilizing both processors on the target z800. Once a Linux workload is up and running on System z machines, we can use the Capacity Planning tools like zCP3000 (introduced in an earlier section) to report the actual measurements of CPU utilization, IOs, etc. One way to measure the performance of Linux under z/VM running on a System z server is to use z/VM CP monitor data. This process is well described in the URLs below:

- Getting Ready for z/VM Capacity Planning Studies http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/PRS788

- CP2KVMXT z/VM Extract Utility for zCP3000 Capacity Planning http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/PRS718 The process is very simple. The CP Monitor must be enabled to collect event and sample data for the Processor, Storage, User, and I/O (dasd class) domains. Then the CP monitor is activated. The application CP2KVMXT runs under z/VM and extracts/formats the monitor data and creates a file type *.EDF. This EDF file is the input file used to feed the capacity planning tool named zCP3000. There are two ways to do the extraction:

• Online - the extraction is done at real time • Batch - the extraction is done by reading the monitor data from a DASD.

There are advantages and disadvantages of each extraction method. In this study we opted to use the batch approach, since we had enough DASD space available to us. By using CP monitor data and the CP2KVMXT z/VM Extract Utility, we were able to extract the real CPU utilization on the z800 machine after the workloads that were running in the Intel servers were consolidated on it. This allowed the direct comparison of the forecasted utilization results obtained via the Linux QuickSizer and the Linux Server Consolidation methodologies to the real utilization on the z800 server and for the first time we would see the beginning and the end of two different Techline offerings: Linux Consolidation Sizing and Capacity Planning. The zCP3000 Capacity Planning tool offers a variety of ways to present its results. A full report of many pages can be generated, capturing various graphic representations of different System z functions. A major plus of this tool is that it

21

also creates a “smart text” to follow each graph, explaining the meaning of graphs in details. In this paper we show only a few of the available graphs and we chose graphs that we thought would better indicate the type of comparison information we were interested in. One nice feature that zCP3000 also offers is the capability to draw the Central Electronics Complex (CEC) and the LPARs (Logical Partitions). Note that our z800 had regular CPs and IFLs. We chose to run our z/VM and Linux workloads in the regular CPs, not in the IFLs. The reason is that the z800 already had another Linux installation that was making use of these IFLs. To separate the environments we decided to use the regular CPs instead. This does not invalidate any of the results obtained here and the same results would be valid if the workloads were running in IFLs. Below is the CEC/LPAR graphical representation: The CEC name is CECA07A with three partitions: zVM51 (our test partition), S01, and ZVM44. The 7603 DASD volume is also visible. As mentioned earlier, the partition where we ran our consolidated workloads was the partition with z/VM v5.1, LPAR ZVM51.

22

If you remember, the expected utilization forecasted by the consolidation tools was the following: 1) QuickSizer: 2.4 x IFLs @ 100% 2) LSC tool: 2.0 x IFLs @ 45% Let us now compare these estimated utilizations with the real utilization on the z800 server. The graph below displays the entire CEC utilization in MIPS.

As one can see from the above graph, the main workloads in this machine during the study were SUSE01 and TCPIP. The workloads that we were not interested in were the workloads running in the partitions that were not the target partition. Both were negligible: WORK_SYS_S01 (3 MIPS) and WORK_SYS_ZVM44 (0 MIPS). Let us now look inside the ZMV51 LPAR and see details of how this LPAR is absorbing the workloads being consolidated. The next graph indicates the total utilization for each workload running on the z800 (partition ZVM51). It indicates a total utilization of 44.1%. This result is due to the individual contributions of two workloads: SUSE01 (42.1%) plus TCPIP (2.0%).

23

Note that z/VM “sees” our apache server as it would see any other z/VM guest. In this case z/VM reports the workload name SUSE01. In any client’s environment, one would need to know what application is running where. In our case, we know that SUSE01 is running the apache webserver. The graph below illustrates the same results as above, but in a different format:

Comparing these results to the results projected by the server consolidation tools, we see that the Linux QuickSizer projected a CPU utilization percent much higher than the actual measured results. But when one looks into the LSC tool projected results of 45%, there is no way to hide how close this number is from the actual utilization of 44.1% found in the real z800 server running the consolidated workloads. The reason is that, as previously discussed, the input required by the QuickSizer is much simpler and less sophisticated. It does produce valid results for a preliminary study, to enable the person considering the consolidation to have a “ballpark result” and to determine whether or not the consolidation should be seriously considered. One important issue to be taken into account is the proper definition of the workload characteristics being consolidated. As mentioned in the previous sections, the proper definition is paramount to the accuracy of the results. The results can vary 4X just by changing the workload factors used in the LSC tool. Even though the results projected and measured were near identical, it is not safe to assume this will happen every time. Proper assumptions and correct input are key to the sizing study. Sizing is part science, part art.

24

Growth projection with zCP3000 To check the processes and tools a step further, we decided to simulate a growth scenario. Instead of driving the Apache server running in the z800 Linux partition with 8 transactions per second, we drove it 50% higher, with 12 transactions per second. But before presenting the actual results, we would like to present the projections we obtained using the zCP3000 Capacity Planning tool to simulate this 50% growth. Then, let us compare the utilization projected with the actual utilization measured in the z800 when Apache is driven by 12 transactions per second. The saturation design point considered is 90%, which indicates that when the server reaches 90% response time for the workloads with less priority tends to increase. The graph below illustrates the projection results:

One can see that the projected utilization is in between 60% and 70%. This is in line with our expectations when we drove the utilization up by 50%. The original utilization was 44.1%. Assuming a linear relation, one can expect an utilization of 66.2%. Let us now compare this projection to the real deal.

25

The results below are illustrative of the data gathered from the z800 when running Apache at 12 transactions per second, or 50% more than the initial 8 transactions per second:

Note that the LPAR of interest has two components, the Linux workload and the TCPIP workload. All other z/VM workloads are zero as the reader can see below:

zCP3000 allows the user to set the threshold that it should use to ignore workloads. In this case, this value was set to workloads with less than 1.0% utilization. This is a handy feature to allow the person performing the study to delete workloads with minimum contribution to the CEC’s total utilization. This strategy will produce clear graphs, not too crowded by symbols and definitions of workloads that are not going to influence the outcome of the study.

26

For comparison purposes, we are including a few other graphs equivalent to the ones previously displayed to represent the pre-growth scenario, but now accounting for the 50% growth:

Another graph to be compared to the results obtained prior to the growth:

As the reader can see the measured utilization was 64.3%. This result is very close to the projected utilization we previously defined based on the growth scenario defined.

27

Future Research Areas We have in mind some areas we intend to explore and study the possible effects. The following is a potential list, among others, that we intend to study:

- Effects of SLES9 (2.6 kernel) instead of SLES8 (2.4 kernel) - Effects of z/VM 5.2 instead of z/VM 5.1 - Size and measure other workloads such as WebSphere Application Server,

DB2, MQSeries - The use of a new Server Consolidation Tool being rolled out soon

28

Conclusion Although the scope of this study was limited in nature, it provided us the feedback we were always looking for, narrowing the gap from a server consolidation sizing study to the real results obtained in a real System z machine. It also proved that the workload qualification is paramount in determining the projected utilization, since depending on the parameters used to qualify a given workload in the sizing phase, the results can vary greatly. We plan to increase the scope of the study to produce more data points, accounting for different scenarios and middleware. This is important because, in obtaining the information and feedback from this project, we can close the cycle from sizing to capacity and, at the same time, we are able to provide the same feedback to development. This may lead to better tools, enhancing the sizing capabilities, and possibly triggering the development of new ones. We also plan to use the new server consolidation tool, currently in beta testing. This new tool will provide environmental information, such as power consumption, area required per server, and the BTUs required for cooling. These are our goals and motivation. We invite the reader to send us comments.