38
IBM PowerLinuxOpen Source Infrastructure Services Reference Architecture and Sizing Guide 2012-04-23 (Version 516) Paul Clarke and Jason Furmanek Lab Services Power Systems [email protected] [email protected]

IBM PowerLinux™ Open Source Infrastructure Services Reference Architecture and Sizing Guide

Embed Size (px)

DESCRIPTION

The Open Source Infrastructure Services (OSIS) Reference Architecture and Sizing Guide provides an overview of an open source application landscape with IBM PowerLinux™ servers. The document first introduces a popular set of open source applications in support of web, mail, file, print, and network serving based on open source from the Red Hat Enterprise Linux (RHEL) and SUSE Linux Enterprise Server (SLES) distributions

Citation preview

Page 1: IBM PowerLinux™ Open Source Infrastructure Services Reference Architecture and Sizing Guide

IBM PowerLinux™Open Source Infrastructure Services

Reference Architecture and Sizing Guide

2012-04-23(Version 516)

Paul Clarke and Jason FurmanekLab Services Power Systems

[email protected]@us.ibm.com

Page 2: IBM PowerLinux™ Open Source Infrastructure Services Reference Architecture and Sizing Guide

Summary

The Open Source Infrastructure Services (OSIS) Reference Architecture and Sizing Guide provides an overview of an open source application landscape with IBM PowerLinux™ servers. The document first introduces a popular set of open source applications in support of web, mail, file, print, and network serving based on open source from the Red Hat Enter-prise Linux (RHEL) and SUSE Linux Enterprise Server (SLES) distributions. It then shows considerations for sizing, scaling, high availability, and cost analysis of these solu-tions.

The intended audience for this guide is professionals planning for open source applications on IBM PowerLinux servers. It is one of two solution guides for OSIS. For information onOSIS implementation and tuning, refer to the second solution guide, IBM PowerLinux ™ Open Source Infrastructure Services Implementation and Tuning Guide.

Page 3: IBM PowerLinux™ Open Source Infrastructure Services Reference Architecture and Sizing Guide

OSIS Reference Architecture and Sizing Guide

Table 1 - FAQ Quick Reference

FAQ Response Quick Reference LinkIs open source ready for use today in the Enterprise?

Yes, 73% of survey respondents considered open source on equal footing to propriety soft-ware.

Introduction

What software is included in the OSIS reference architecture landscape?

OSIS includes virtualization software from IBM and open source software from Linux distributions and other providers.

Solution Landscape

How do I engage with clients about OSIS? Discover the client’s open source use and plans, optionally analyze for consolidation and sizing, and show them how to exploit IBM PowerLinux systems.

Solution Guide Use

Is virtualization that important for an open source landscape?

Yes, virtualization using IBM PowerVM pro-vides system resource sharing, allowing for higher system utilization while efficiently run-ning multiple workloads.

Virtualization with IBM PowerVM and Error: Reference source not found

Does the OSIS reference architecture landscape allow for hardware flexibility for integration and scaling?

Yes, OSIS can run on any configuration of PowerLinux hardware and integrate with other Linux systems.

Possible Solution Architectures

Are there specific sizing metrics for OSIS? Yes, web visits and number of emails pro-cessed are commonly used metrics.

Metrics of Interest

How do I size a system with known requirements?

Use the results from test examples in this doc-ument as a starting point and optionally a proof-of-concept (POC).

Sizing

Are there performance throughput examples available?

Yes, included in this document are results from measuring web and mail requests in a simulated client environment.

Performance Results for

How do I estimate system requirements? Estimate system requirements for CPU, mem-ory and networking by using test results from an existing environment or benchmarks.

An Example of Hardware Estimation

How can I scale the OSIS landscape? Through dynamic sharing of resources, adding additional resources to virtual servers, using external storage, or by adding additional sys-tems.

Scalability

How can I improve availability of the OSIS landscape?

By using hardware and software availability options such as redundant hardware, dual soft-ware configurations, and clustered systems.

Availability

How would I perform a system consolidation sizing?

First, either measure or estimate the utilization of the current systems. Then, use comparative benchmark results to estimate PowerLinux system requirements.

Collecting and Analyzing Existing WorkloadUtilizations and Sizing a PowerLinux System

How would I perform a competitive cost analysis?

After sizing PowerLinux system(s), compare all acquisition and ownership costs (hardware, software and facilities) for both PowerLinux and competitive systems.

Total Cost of Acquisition and Ownership(TCA/TCO)

Can open source applications be migrated to PowerLinux systems?

Yes, IBM provides tools for migrating web (LAMP) configurations and if necessary, re-compiling C/C++ programs.

Migration

OSIS Reference Architecture and Sizing Guide.odt IBM Confidential Page 3

Page 4: IBM PowerLinux™ Open Source Infrastructure Services Reference Architecture and Sizing Guide

OSIS Reference Architecture and Sizing Guide

Table of Contents

1 INTRODUCTION...................................................................................................................................................6

2 SOLUTION GUIDE USE.......................................................................................................................................7

3 OSIS REFERENCE ARCHITECTURE...............................................................................................................8

4 POSSIBLE SOLUTION ARCHITECTURES....................................................................................................13

4.1 SMALL/DEVELOPMENT SOLUTIONS ARCHITECTURE............................................................................................................134.2 MEDIUM SOLUTIONS ARCHITECTURE...............................................................................................................................134.3 LARGE SOLUTIONS ARCHITECTURE.................................................................................................................................14

5 OSIS REFERENCE ARCHITECTURE TEST DESCRIPTION.....................................................................15

5.1 WEB SERVING TEST SCENARIO......................................................................................................................................155.2 MAIL SERVING TEST SCENARIO.....................................................................................................................................165.3 METRICS OF INTEREST..................................................................................................................................................16

6 SIZING...................................................................................................................................................................18

6.1 WORKLOAD ESTIMATION...............................................................................................................................................186.2 APPLICATION PERFORMANCE ESTIMATION........................................................................................................................18

7 PERFORMANCE RESULTS FOR OSIS...........................................................................................................19

7.1 TESTED CONFIGURATIONS..............................................................................................................................................197.1.1 Tested Configuration - Topology..............................................................................................................207.1.2 Tested Configuration Details....................................................................................................................207.1.3 Tested Configuration Results....................................................................................................................21

7.2 AN EXAMPLE OF HARDWARE ESTIMATION.......................................................................................................................22

8 SCALABILITY......................................................................................................................................................23

8.1 SCALABILITY TESTING ON IBM POWERLINUX.................................................................................................................238.2 WEB WORKLOAD........................................................................................................................................................248.3 MAIL WORKLOAD........................................................................................................................................................24

9 AVAILABILITY ..................................................................................................................................................25

9.1 HARDWARE AVAILABILITY CONSIDERATIONS....................................................................................................................259.2 SOFTWARE AVAILABILITY CONSIDERATIONS.....................................................................................................................25

9.2.1 Virtualization Availability.........................................................................................................................259.2.2 Linux Availability......................................................................................................................................26

10 CONSOLIDATION ..............................................................................................................................................27

10.1 COLLECTING AND ANALYZING EXISTING WORKLOAD UTILIZATIONS....................................................................................2710.2 SIZING A POWERLINUX SYSTEM FOR CONSOLIDATION.......................................................................................................2710.3 TOTAL COST OF ACQUISITION AND OWNERSHIP (TCA/TCO)...........................................................................................28

11 MIGRATION.........................................................................................................................................................30

11.1 MIGRATING WEB (LAMP) WORKLOADS ......................................................................................................................3011.2 MIGRATING EXISTING C/C++ APPLICATIONS..................................................................................................................3011.3 APPLICATION COMPATIBILITY WITH IBM POWERLINUX....................................................................................................3011.4 INTEGRATION WITH EXISTING LANDSCAPES......................................................................................................................30

12 APPENDIX.............................................................................................................................................................31

12.1 VIRTUALIZATION MANAGEMENT COMPARISON..................................................................................................................3112.2 ECONFIG REFERENCE CONFIGURATION............................................................................................................................33

OSIS Reference Architecture and Sizing Guide.odt IBM Confidential Page 4

Page 5: IBM PowerLinux™ Open Source Infrastructure Services Reference Architecture and Sizing Guide

OSIS Reference Architecture and Sizing Guide

12.3 HARDWARE CONFIGURATION EXAMPLE 1........................................................................................................................3312.4 HARDWARE CONFIGURATION EXAMPLE 2........................................................................................................................3412.5 SOFTWARE CONFIGURATION EXAMPLE............................................................................................................................3512.6 INDUSTRY STANDARD BENCHMARK DESCRIPTIONS............................................................................................................36

13 REFERENCES......................................................................................................................................................37

DISCLAIMER AND TRADEMARKS................................................................................................................39

FIGURE 1 - CLIENT TECHNICAL DISCOVERY, ANALYSIS AND EXPLOITATION..........................................7

FIGURE 2 - OSIS REFERENCE ARCHITECTURE OVERVIEW................................................................................8

FIGURE 3 - OSIS TEST CONFIGURATION..................................................................................................................15

FIGURE 4 - TEST CONFIGURATION - WEB REQUESTS.........................................................................................21

FIGURE 5 - TEST CONFIGURATION - MAIL REQUESTS.......................................................................................21

FIGURE 6 - WEB SERVER SCALING RESULTS........................................................................................................24

FIGURE 7 - MAIL SERVER SCALING RESULTS......................................................................................................24

FIGURE 8 - SUMMARIZING X86 SYSTEM UTILIZATION EXAMPLE.................................................................27

FIGURE 9 - SIZING X86 CONSOLIDATION TO IBM POWERLINUX 7R2 EXAMPLE.......................................28

FIGURE 10 –TCA/TCO TEMPLATE EXAMPLE FOR ONE SYSTEM.....................................................................28

TABLE 1 - FAQ QUICK REFERENCE.............................................................................................................................3

TABLE 2 - SMALL SOLUTION ARCHITECTURE CONFIGURATION - EXAMPLE...........................................13

TABLE 3 - MEDIUM SOLUTION ARCHITECTURE CONFIGURATION - EXAMPLE.......................................13

TABLE 4 - LARGE SOLUTION ARCHITECTURE CONFIGURATION - EXAMPLE...........................................14

TABLE 5 - HARDWARE ESTIMATION EXAMPLE....................................................................................................22

OSIS Reference Architecture and Sizing Guide.odt IBM Confidential Page 5

Page 6: IBM PowerLinux™ Open Source Infrastructure Services Reference Architecture and Sizing Guide

OSIS Reference Architecture and Sizing Guide

1 IntroductionA survey by OpenLogic reveals that many enterprises consider using open source and adoption of open source is on the rise. The IBM PowerLinux™ Open Source Infra-structure Services (OSIS) reference architecture consists of a landscape of open source software available from Linux distributions provided by Red Hat and SUSE and the open source community. IBM PowerLinux servers with IBM PowerVM™ offer a highly virtualized, workload optimized, cloud-ready platform that can support more workloads per server and greater throughput per virtual server – saving up to 16% or more in acquisition costs as compared to HP ProLiant systems with VMware1. It is an ideal platform for replac-ing more expensive infrastructure applications with robust open source offerings. Open source applications for PowerLinux servers are included and supported with commercial Linux distributions from Red Hat and Novell.

These open source applications provide a highly flexible environment for IBM Power-Linux servers, which means choices in architecture, sizing, and individual server con-figurations.

Combining IBM PowerLinux 7R2 with PowerVM's superior virtualization capabilities enables up to 160 simultaneously active virtual servers on a single 16-core system. Such a capable system provides an excellent reference platform for a consolidated open source solution.

This paper describes a study IBM has performed with several open source applications. Based on experiences and results from installation, configuration, and performance testing, this paper describes architectures, results from tested configura-tions, and suggested approaches to scaling, sizing, migration, consolidation, and availability.

1 Achieve 16% lower total cost of acquisition over years with 3 IBM POWER7, two socket, 16-core, 3.55GHz servers instead of 4 HP DL380 G7 two socket, 12-core, 3.3 GHz servers, leveraging the higher utilization and virtualization efficiencies of PowerVM.

• Performance based on IBM analysis of the SPECint_rate benchmark on HP DL380 G7 two socket, 12-core server (3.33 GHz Intel® Xeon® X5680 processor) and on the IBM PowerLinux 7R2 16-core server (3.55GHz processors).

• Prices from www.hp.com (link resides outside of ibm.com).

• Assumption is that the throughput impact of VMware is 10%, based on SAP Note 1409608 (10% overhead) and VMware whitepaper “Virtu-alizing Business Critical Applications”, 2010 (“keeping virtualization overhead at a very limited at 2-10 percent “) at http://www.vmware.-com/files/pdf/VMW_10Q1_WP_vSPHERE_USLET_EN_R6_proof.pdf

OSIS Reference Architecture and Sizing Guide.odt IBM Confidential Page 6

Page 7: IBM PowerLinux™ Open Source Infrastructure Services Reference Architecture and Sizing Guide

OSIS Reference Architecture and Sizing Guide

2 Solution Guide UseWhen reviewing the potential use IBM PowerLinux systems with open source applications, OSIS solution guides can be part of an overall assessment process with a customer. Figure 1 below outlines several phases and activities that are ap-propriate in working on an OSIS proposal with a client.

1. Discover client’s technical requirements and usage (HW, SW, data center)2. Analyze their requirements and current environment3. Exploit with proposals based on IBM PowerLinux and OSIS

Figure 1 - Client Technical Discovery, Analysis and Exploitation

OSIS Reference Architecture and Sizing Guide.odt IBM Confidential Page 7

Page 8: IBM PowerLinux™ Open Source Infrastructure Services Reference Architecture and Sizing Guide

OSIS Reference Architecture and Sizing Guide

3 OSIS Reference Architecture

3.1 OSIS Solution LandscapeThe IBM PowerLinux Open Source Infrastructure Services (OSIS) solution landscape consists of IBM PowerLinux 7R2 hardware, virtualization software, Linux OS and open source applications. Refer to Figure 2 below for details.

Figure 2 - OSIS Reference Architecture Overview

The OSIS reference architecture landscape includes the following software:1. IBM provided:

IBM PowerVM for IBM PowerLinux – provides virtualization of IBM PowerLinux servers, allowing up to 160 virtual servers configured per system. PowerVM includes: Virtual I/O Server (VIOS) - manages system CPU, memory, and network resource sharing Integration Virtualization Manager (IVM) - provides a web based virtualization manager

IBM Installation Toolkit - a no-charge offering that provides installation of Linux and configuration of open source applications for web, mail, file, print and network serving

Optional management consoles (for solutions with multiple systems) Hardware Management Console (HMC) includes both hardware and software used to perform a variety of

system management tasks for all IBM Power Systems, including IBM PowerLinux servers. In particular, it may be used to create or change logical partitions, including dynamically assigning hardware to a partition.

IBM Systems Director Management Console (SDMC) - provides server hardware management and virtu-alization management.

Optional Cloud Foundation (advanced virtualization with image control) IBM Systems Director for IBM PowerLinux provides the integrated tools needed to efficiently visualize

and communicate the relationships of physical and virtual systems that are discovered, monitor their health, define and receive threshold alerts, and update system firmware and operating environments. Built-in auto-

OSIS Reference Architecture and Sizing Guide.odt IBM Confidential Page 8

Page 9: IBM PowerLinux™ Open Source Infrastructure Services Reference Architecture and Sizing Guide

OSIS Reference Architecture and Sizing Guide

mation capabilities enable IT administrators to schedule updates and configuration changes to proactively avoid problems, and reduce the administrative burden of routine maintenance.

IBM Systems Director VMControl for IBM PowerLinux provides creations and modification of system pools using PowerLinux virtual workloads, make dynamic virtual workload adjustments and move work-loads within system pools, resulting in an optimized virtual environment with increased resilience to cope with planned or unplanned downtime.

2. Linux Distributions Red Hat Enterprise Linux (RHEL) and SUSE Enterprise Linux Server (SLES) provide both a base Linux operating system and the following open source applications of the OSIS landscape: Postfix provides mail serving by receiving and delivery of mail. Postfix is an alternative to the sendmail server,

which is also included with Linux distributions. Dovecot and Cyrus provide interoperability with other mail servers and clients using POP, IMAP4 and MSS in-

dustry standard protocols fetchmail provides mail clients with mail retrieval procmail , SpamAssassin provide mail filtering and anti-spam protection smtp-source provides mail generation for performance testing Apache HTTP Server provides HTTP web serving MySQL provides database serving PHP provides PHP scripting Berkeley Internet Naming Domain (BIND) provides domain name services (DNS) Squid caching proxy for the web supporting HTTP, HTTPS, FTP, and more mpstat , nmon, iostat provide system utilization information on CPU, memory, network, disk

3. Other optional (no-charge) open source applications: Ganglia provides a system resource utilization monitoring system that is highly scalable and customizable Webmin provides a web based administration interface for managing Linux applications and services associated

with the OSIS reference architecture Drupal provide web-based content management

This solution guide focuses on the following mail and web serving applications that are included with Linux distributions, optionally installed and configured using the IBM Installation Toolkit. The web serving applications includes the Apache Web Server (Apache), which typically runs PHP/Perl scripts with

a database such as MySQL. The combination of Linux, Apache, MySQL, and PHP is commonly referred to as the LAMP architecture or stack.

The mail serving applications include Postfix, Dovecot and Cyrus. The Postfix mail server supports the Simple Mail Transfer Protocol (SMTP), while both Dovecot and Cyrus integrate with Postfix to provide Post Office Protocol (POP) and Internet Message Access Protocol (IMAP). A comparison of mail servers is available on Wikipedia.

OSIS Reference Architecture and Sizing Guide.odt IBM Confidential Page 9

Page 10: IBM PowerLinux™ Open Source Infrastructure Services Reference Architecture and Sizing Guide

Illustration 2: Application Services Data Flows

OSIS Reference Architecture and Sizing Guide

3.1.1 Landscapes Based on x86 SystemsTypical x86-based landscapes for open source mail and web servers consist of workstations, multiple application servers and possibly storage servers. As shown in Illustration 2: Application Services Data Flows, a typical end user request flows as follows:

For web serving,1. A browser submits an end-user request

that the web server corresponding to the web page processes.

2. Web server retrieves static and/or dy-namic data from a storage device and returns it to the browser.

3. Programs; such has PHP scripts re-trieve dynamic content from a data-base and return the content to the browser.

For mail serving,1. Mail clients send end-user emails to the mail server in their mail domain.2. If necessary, the mail server forwards emails to the mail server of the recipient’s mail domain.3. Mail filtering is applied (open source examples include Procmail and SpamAssassin).4. The mail server stores mail.5. The recipient requests mail.

IBM information center provides additional information about running Linux open source applications on IBM Power systems.

3.2 Virtualization with IBM PowerVMUtilizing IBM PowerVM for virtualization is fundamental to the OSIS landscape. Notice how each of the following virtu-alization goals aligns with requirements for a OSIS reference architecture landscape: Consolidate multiple environments, including under-utilized servers and systems with varied and dynamic resource re-

quirements. Grow and shrink resources dynamically, derive energy efficiency, save space, and optimize resource utilization. Deploy new workloads by provisioning virtual machines or new systems rapidly to meet new and changing business

demands. Develop and test applications in secure, independent domains while production can be isolated to its own domain on

the same system. Transfer live workloads to support server migrations, balance system load, or avoid planned downtime. Control server sprawl and thereby reduce system management costs.

IBM PowerLinux systems deployed for open source mail and web applications may consist of either add-on systems or replacements of existing systems. Using IBM PowerVM virtualization technology, a single system can run multiple virtu-al servers, each running one or more applications. Virtual servers can share physical resources such as processors, memo-ry, and networking devices. For proper deployment, sizing of these IBM PowerLinux systems and virtual servers is re-quired. The term IBM Power Systems virtual server is used throughout this paper, instead of the equivalent term Logical Partition (LPAR) or term Virtual Machine (VM) used with x86-based virtualization.

PowerVM is the industry-leading virtualization solution for AIX, IBM i, and Linux environments on IBM POWER tech-nology. PowerVM offers a secure virtualization environment, built on the advanced RAS features and leadership perfor-

OSIS Reference Architecture and Sizing Guide.odt IBM Confidential Page 10

Page 11: IBM PowerLinux™ Open Source Infrastructure Services Reference Architecture and Sizing Guide

OSIS Reference Architecture and Sizing Guide

mance of the Power Systems platform. It features leading technologies such as Power Hypervisor, Micro-Partitioning, Dy-namic Logical Partitioning (DLPAR), Shared Processor Pools, Shared Storage Pools, Integrated Virtualization Manager (IVM), PowerVM Lx86, Live Partition Mobility, Active Memory Sharing, N Port ID Virtualization (NPIV), and Suspend/Resume. PowerVM is a combination of hardware enablement and value-added software. Additional information is available in the IBM Redbooks publication IBM PowerVM Virtualization Introduction and Configuration, SG247940.

By applying PowerVM virtualization technology, it is possible to configure multiple virtual web, database, and mail servers utilizing a pool of system resources with one IBM PowerLinux system. Additional load on the physical network can be avoided by utilizing a high capacity virtual network between these virtual servers. The benefits of virtualizing workloads with PowerVM in this way include: Higher resource utilization: Promoting high resource utilization by virtualizing resources including processors,

memory, and I/O across multiple virtual machines. Consolidation: Hosting diverse workloads on the same server. Reduced costs: Saving system administrator time and IT infrastructure costs. Scalability: Simplifying deployment of multiple copies of the same workload type. PowerVM supports virtual

servers as small as 1/10 of a processor core, allowing up to 160 virtual servers on an IBM PowerLinux system with 16 cores.

Recoverability: Bringing a workload back online after an outage, quickly and reliably. Rapid provisioning: Deploying the ready-to-run workload, quickly and easily. Availability: Eliminating planned downtime by moving a running partition to another server, with Live Partition

Mobility, while upgrading or maintaining hardware--without interrupting productive work.

Note that a key difference between the sharing of the physical system resources using PowerVM versus x86-based virtual-ization technologies is in the handling of virtual server CPU and memory commitments. Unlike x86-based virtualization technologies that only add CPU and memory resources to active virtual servers, PowerVM can also remove both CPU and memory resources, reallocating these resources transparently to other virtual servers when and where the resources are needed. For example, PowerVM can dynamically remove resources from an under-utilized virtual mail server and add the resource to a virtual web server when needed. This feature, commonly referred to as Dynamic Logical Partitioning (DLPAR), allows for configuration of a larger number of virtual severs per system, up to 160 virtual servers for a 16 core Power System. For additional information on higher system utilization and performance using PowerVM, refer to A Comparison of PowerVM and x86-Based Virtualization Performance.

OSIS Reference Architecture and Sizing Guide.odt IBM Confidential Page 11

Page 12: IBM PowerLinux™ Open Source Infrastructure Services Reference Architecture and Sizing Guide

Illustration 3: OSIS Web and Mail Virtual Servers

OSIS Reference Architecture and Sizing Guide

3.3 Open Source Infrastructure Services (OSIS)

With the adoption of virtualization using IBM PowerVM, it is pos-sible to consolidate both web and mail on one or more IBM Power-Linux systems using virtual servers as shown in Illustration 3: OSISWeb and Mail Virtual Servers. Migration of multiple physical servers to virtual servers is possible without changing the network flow or application handling of requests. However, there are sever- al key differences to point out:

1. It is possible to configure Virtual Ethernet con-nections directly between web and database virtual servers, and between mail virtual servers. These high speed (in-memory) virtual Ethernet connections reduce IP traffic on network switches, improving the overall network performance and network reliability.2. Virtual servers dynamically share CPU and memory. Since web and mail workloads vary throughout the day, a more efficient utilization of system resources occurs. PowerVM's efficient and dynamic sharing of physi-cal resources by the virtual servers en-ables adding additional virtual servers to leverage any under-utilized system resources. When sizing open source workloads, proper selection of hard-ware, monitoring of system resources and a careful mix of workloads can re-sult in a highly utilized system that consolidates a significant number of workloads on a single server.

OSIS Reference Architecture and Sizing Guide.odt IBM Confidential Page 12

PowerLinux Highlight: Consolidate up to 160 physical servers to a single PowerLinux 16 core system using PowerVM and virtual servers.

16 cores per systemx max 10 vCPUs per corex max 4 threads per vCPU= max 640 threads (or logical CPUs per system)

Page 13: IBM PowerLinux™ Open Source Infrastructure Services Reference Architecture and Sizing Guide

OSIS Reference Architecture and Sizing Guide

4 Possible Solution ArchitecturesUsing Illustration 1: OSIS Reference Architecture above as an overall architecture landscape for OSIS, you can modify several as-pects of the architecture to address small, medium, and large con-figurations. Options in support of various sizes of the reference ar-chitecture configuration include:

1. The number of IBM PowerLinux systems used and their placement. Even though a single system can handle sig-nificant web, mail, file, print and networking requests, there may be requirements for additional memory or CPU resources beyond a single system or network quality of service (QoS) requires placement of systems near end-users.

2. The use of direct attached or network attached storage. Network attached storage provides the advantage of higher capacity throughput with high-speed networks and adapters, caches, and additional disk arms. You can configure IBM PowerLinux systems with up to six internal drives, additional drives placed in expansion drawers and network attached storage devices.

3. Increase memory capacity by adding additional memory. Even with memory sharing across virtual servers and imposing limits on the amount of memory utilized by a virtual server, it may be necessary in large configurations to add additional memory when reaching a system’s memory capacity.

4. Add network adapters or upgrade their capacity. Even with efficient Ethernet port sharing across virtual servers, large configuration may require additional network bandwidth or improved latency. You can address this re-quirement by installing additional network adapters or selecting higher speed adapters. NOTE: Increase network throughput by leveraging PowerVM Ethernet port aggregation, which supports multi-ple physical Ethernet ports using only one virtual Ethernet port and one single IP address. Aggregation of ports provides an efficient and dynamic method of adjusting network bandwidth without applications impact. For ad-ditional information, refer to IBM PowerVM Virtualization Introduction and Configuration.

4.1 Small/Development Solutions ArchitectureIn a small solution landscape, all of the web, mail, file, print, and networking servers run on a single IBM PowerLinux system using virtual servers with minimal memory and CPU resources required. Use internal storage to handle the lower disk throughput requirements. You may use unused CPU capacity for additional open source applications such as file, print, and networking.

PowerLinux Systems

Cores per System Memory (GB) per System

Storage Network Adapters

Virtualization Console

1 16 32 6 x Internal Disks 1 (4 port 1Gb) PowerVM IVM

Table 2 - Small Solution Architecture Configuration - Example

4.2 Medium Solutions ArchitectureIn a medium solution landscape, all of the web, mail, file, print, and networking servers can run on a single IBM Power-Linux using virtual servers. This configuration adds additional memory and storage resources to handle the expected in-crease in workload. In addition, attached storage addresses higher disk throughput requirements.

PowerLinux Systems

Cores per System Memory (GB) per System

Storage Network Adapters

Virtualization Console

1 16 64 External – 12S SAS Expansion

Drawer

1 (4 port 1Gb) PowerVM IVM

Table 3 - Medium Solution Architecture Configuration - Example

OSIS Reference Architecture and Sizing Guide.odt IBM Confidential Page 13

PowerLinux Highlight: Adding additional CPUs, memory, storage, and networking ports toPowerLinux systems allows the OSIS landscape to scale.

Page 14: IBM PowerLinux™ Open Source Infrastructure Services Reference Architecture and Sizing Guide

OSIS Reference Architecture and Sizing Guide

4.3 Large Solutions ArchitectureIn a large solution landscape where high workload is expected, all web, mail, file, print, and networking could run on one or more IBM PowerLinux systems, each configured with maximum memory and CPU resources. Multiple network adapters address network throughput requirements for mail and file serving. Multiple network attached storage adapters (Fibre Channel) improve disk bandwidth.

PowerLinux Systems

Cores per System Memory (GB) per System

Storage Network Adapters

Virtualization Console

2 or more 16 128 External – SAN 2 (4 port 1Gb) HMC or SDMC

Table 4 - Large Solution Architecture Configuration - Example

When reviewing plans for large solution architecture, you should also consider possible cloud requirements. With the ad-dition of IBM Systems Director VMControl, virtual server images and system pool lifecycle management is provided as follows:

Capturing of information from active systems and storing the information in a repository as reusable system im-ages, also referred to as virtual appliances

Users can create and manage system pools – or groups of virtual appliances deployed across multiple physical servers – as easily as managing a single entity. The advanced virtualization management capabilities of VMCon-trol provide a pathway for organizations to build sophisticated cloud computing environments.

NOTE: For large solutions, Integrated Virtualization Manager (IVM) may become insufficient, requiring either a Hard-ware Management Console (HMC) or Systems Director Management Console (SDMC). Specifically for multiple system solutions, HMC and SDMC provide efficient access to multiple systems. Refer to section 12.1 Virtualization Manage-ment Comparison on page 31 for a comparison of IVM with HMC.

The key differences between IVM and HMC/SDMC are:1. Costs – IVM is included with PowerVM, while HMC and SDMC require purchasing additional products2. Dual VIOS – IVM supports only a single VIOS, while HMC/SDMC support multiple VIOS. Multiple VIOS

provides redundancy, allowing for VIOS maintenance without virtual server interruptions.3. Multiple Shared Processor Pools - IVM only supports only one pool, while HMC and SDMC support multiple

processor pools.4. Workload Management Groups – IVM only supports one group, while HMC/SDMC support multiple groups.

OSIS Reference Architecture and Sizing Guide.odt IBM Confidential Page 14

Page 15: IBM PowerLinux™ Open Source Infrastructure Services Reference Architecture and Sizing Guide

OSIS Reference Architecture and Sizing Guide

5 OSIS Reference Architecture Test DescriptionTesting of the OSIS reference architecture consisted of both web and mail serving using the lightweight servers included with the Linux distributions. These servers typically handle the content and processing as follows:

Web serving: the server receives requests, processes the requests, formats and returns a response to the browser. Processing of dynamic content usually requires additional applications being involved, execution of scripts and usually database activity.

Mail serving: the server receives emails from mail clients, performing filter operations, storing the email and then later retrieving and sending email to mail clients. The size and number of mail requests tend to determine the server’s capacity. Other than applying filters, the message content and attachments do not affect overall per-formance or sizing.

Depending on the size of the configuration and application tested, configurations varied by utilizing different memory, CPU, networking, and storage options. The following sections provide details of both the web and mail serving scenarios shown in Figure 3, followed by a dis-cussion of metrics of interest.

Figure 3 - OSIS Test Configuration

5.1 Web Serving Test ScenarioThe web serving test scenario is based on the Linux operating system, Apache, MySQL and PHP (collectively called LAMP), along with a simulation of virtual clients browsing a website based on Drupal. The following describes the test scenario (refer to Illustration 3: OSIS Web and Mail Virtual Servers and Figure 3):1. To simulate web clients running internet browsers without the need for end-users operating workstations, software on

a “web workload” virtual server connected directly to the physical network generated a virtual client’s web workload. 2. This virtual client web workload used the open source utility httperf. In this test scenario for evaluating web serving

capacity, httperf produced a large number of URL requests to the web server, with no think time. To simulate multi-

OSIS Reference Architecture and Sizing Guide.odt IBM Confidential Page 15

Page 16: IBM PowerLinux™ Open Source Infrastructure Services Reference Architecture and Sizing Guide

OSIS Reference Architecture and Sizing Guide

ple virtual web clients, httperf issues parallel requests via multi-threading. The following is an example of running httperf from the command line:

httperf --hog –server=<web server host name> --uri=/drupal/?q=blog/1 --num-calls=100 –num-connections=100 --hog causes as many TCP ports as necessary, allowing more requests to be issued --server is the web server’s URL (or IP address) --uri is the web page being requested --num-calls is the number of single request calls made to the server --num-connections is the number of connections

3. The Apache web server received these requests and routed them to the application associated with the website. Test-ing used platform Drupal, an open source content management application implemented with PHP. Drupal also uti-lized a database to maintain web content. Use of MySQL for the database completed the testing of LAMP stack.

5.2 Mail Serving Test ScenarioThe Mail serving test scenario is based on the Linux operating system, Postfix and Dovecot mail servers along with a sim-ulation of virtual clients sending and receiving emails. The following describes the test scenario (refer to Illustration 3:OSIS Web and Mail Virtual Servers and Figure 3):1. To simulate mail clients sending and receiving emails without the need for end-users operating workstations, soft-

ware in a “Mail Workload” virtual server connected directly to the physical network generated mail activity from a virtual client.

2. Open source utility smtp-source generated the virtual client mail workload. In this test scenario for evaluating mail server capacity, smtp-source generated a large number of mail requests to the mail server, with no think time. To simulate multiple virtual mail clients, smtp-source issued parallel request via multi-threading. The following is an example of running smtp-source from the command line:

smtp-source -R 30 -s 10 -l 5120 -m 200 -c -f <from email ID> -t <to email ID> <mail server hostname>:25

smtp-source is the Linux open source utility for sending smtp emails

-R 30 means to send emails with a random think time of 0 to 30 seconds. Note, if not specified the messages are sent with no “think time”, resulting in maximum throughput

-s 10 means to send the emails over 10 parallel connections

-l 5120 means send emails of 5120 byte (fixed) size

-m 200 means to send 200 emails

3. The Postfix email server processed incoming mail requests and placed them on an incoming mail queue. 4. When testing anti-spam, Procmail and SpamAssassin processed emails by updating when appropriate the emails to

indicate spam.5. The virtual client mail workload also receives emails from the Dovecot mail server using the open source utility

fetchmail and the POP mail protocol. This test scenario for evaluating mail server capacity used fetchmail configured to receive all emails for each of the end-users. To simulate multiple virtual mail clients, fetchmail issued parallel re-quests via multi-threading and stored the emails in mail folders on the virtual client.

5.3 Metrics of InterestThe metric of main interest for web and mail serving is Number of Requests per Second. Also, related to the Number of Requests per Second are secondary metrics such as the Number of Concurrent Users and Average Response Time.

Obtain these metrics for selected IBM PowerLinux system and virtual server configurations, running specific types of web or mail requests. To determine the maximum Number of Requests per Second, a sufficient number of instances of the workload were required to saturate one or more of the virtual server resources.

PowerVM supports up to ten virtual CPUs (vCPUs) per core. Since Linux reports each thread as a separate logical CPU, Linux reports up to 640 logical CPUs on a 16-core IBM PowerLinux system. Below is an example of a virtual server configured with the maximum number of IBM PowerLinux cores, vCPUs, threads, logical CPUs:

16 cores/system x 10 vCPUs/core x 4 threads/vCPU= 640 threads (or logical CPUs per system)

OSIS Reference Architecture and Sizing Guide.odt IBM Confidential Page 16

Page 17: IBM PowerLinux™ Open Source Infrastructure Services Reference Architecture and Sizing Guide

OSIS Reference Architecture and Sizing Guide

NOTE: simultaneous execution of the virtual client workload is required for the web and mail applications to drive enough threads to cause high CPU utilizations.

Monitor the CPU, memory, disk and network utilization metrics of the virtual servers during testing for resource con-tention. Obtain maximum throughput by running workloads that force one or more of these metrics to their limits. For example, during initial testing of a small configuration, maximum logical CPU utilization could be achieved before reach-ing disk, network, or memory limitations. The open source utility nmon2 monitored a virtual server’s average logical CPU utilization and the utilization of individual logical CPUs. Logical CPU utilization results determined whether a suf-ficient number of application threads were running to maximize overall throughput.

NOTE: the values achieved for these two metrics (Connections per Second and Number of Concurrent Users) are specific to the web and mail application used and the specific type of requests. Expect these values to be different for different types of requests and/or applications.

2 The nmon utility can be installed using the IBM Installation Toolkit and run from the Linux command line to show real time CPU, disk, memory and network utilization for a virtual server.

OSIS Reference Architecture and Sizing Guide.odt IBM Confidential Page 17

Page 18: IBM PowerLinux™ Open Source Infrastructure Services Reference Architecture and Sizing Guide

OSIS Reference Architecture and Sizing Guide

6 SizingSizing is the process of determining the hardware needed to support the execution of an application in a production envi-ronment, under specific performance constraints specified by the customer.

Realizing that OSIS utilizes IBM PowerVM for virtualization, run multiple mixed workloads on the same system using virtual servers. Configure virtual servers with either dedicated or prioritized shared resources. For example, configure a virtual server with dedicated processor(s), or dedicated network port(s). IBM PowerVM provides near linear scaling of throughput, allowing multiple web and mail application workloads to be aggregated together for a total sizing (for details, refer to section 8 Scalability on page 23). For example, if it is determined that a virtual server with 2 CPUs is required for a specific web workload and a second virtual server with 3 CPUs is required for a specific mail workload, 5 CPUs should be considered as the total requirement when mixing the workloads. During sizing, consider reviewing the aggregated to-tals for network, disk and memory.

This paper suggests sizing by following the steps outlined below.

6.1 Workload EstimationFor workload estimating, determine the amount of work an application needs to handle. As discussed in an earlier sec-tion, a web application needs to create and return static and dynamic content to web clients. Likewise, a mail application needs to receive and return email to mail clients. In these cases, an estimate of the workload would be the number of web and mail requests that these applications require to handle per second.

In some cases to arrive at an estimate, obtain data or an estimate from the client for how the business has been running in the recent past. For instance, an insurance company may estimate that they receive 125,000 requests for quotes in a regu-lar working day of 8 hours. Since the online version of the service will be available round the clock, there could be 375,000 requests in a period of 24 hours. For this example, we can now estimate the Requests per Second as follows: If the processing of each quote entails the processing of 4 web requests by the web application, then that means

1,500,000 web requests in 24 hours. If we assume a peak hourly rate of 12% of the total for 24 hours, we could esti-mate 180,000 web requests per hour or 50 web Requests per Second.

If the processing of each quote also requires sending one email per day as follow up to potential clients requesting quotes, this would result in 4 mail Requests per Second.

When possible, it is best to size of web or mail workloads while running on existing systems. Refer to Consolidation on page 27 below for information about sizing existing workloads.

6.2 Application Performance EstimationExamine web and mail application workloads next in order to determine the average time needed to generate each request per CPU. One method of obtaining this figure is to run a workload test that drives the application to maximum speed, measure the total number of requests served in a given period, and determine the average number of Requests per Second for one CPU. When using more than one virtual server to handle the requests, the total number of CPUs needs to be de-termined. For an example of 50 web requests handled by a virtual server with one CPU, that is also accessing a database virtual server configured with 0.2 CPUs, the aggregated total would be 1.2 CPUs. Since most capacity measurements utilize 100% CPU, it may be better to adjust the Requests per Second per CPU throughput to 80% CPU utilization. For an example of 50 web Requests per Second that used 1.2 CPUs, this would calculate to be about 33 Requests per Second per CPU (80% times 50 Requests/Sec divided by 1.2 CPUs).

As described in a previous section for a specific case of testing web and mail applications, simulate multiple virtual clients by running multiple open source workload generators simultaneously to achieve near 100% CPU utilization. As noted above, actual customer environments will not stress the server resources so exhaustively and thus adjust requests per sec-ond throughput results accordingly.

Consider estimating the number of clients by running the workloads with a “think time” added.

OSIS Reference Architecture and Sizing Guide.odt IBM Confidential Page 18

Page 19: IBM PowerLinux™ Open Source Infrastructure Services Reference Architecture and Sizing Guide

OSIS Reference Architecture and Sizing Guide

7 Performance Results for OSISThis section provides details and results for a set of OSIS configurations tested for this paper, using the following metrics:o Connections per Second was determined by having virtual clients make consecutive requests with no “think” time

between requests. o Number of Concurrent Users was determined by multiplying the Number of Connections per Second value with a

think time of 30 seconds. Though the values obtained for the metrics are specific to web and mail request types and their request sizes used in the workload tested, one could obtain a different set of values using customer provided in-formation and techniques outline in this paper. For example, if the customer believes their web requests are larger or think times should be different, modify the pages on the web site and/or configure the web workload generation utility with a different think time.

7.1 Tested ConfigurationsTesting for this paper included four configurations on a single IBM PowerLinux. The difference between the configura-tions was the number of CPUs and specifically for mail, configurations with and without Linux software RAID and anti-spam configured.

Tested PowerLinux system information: IBM PowerLinux 7R2 2 sockets with sixteen (16) 3.55 GHz processors 128 GB memory 6 internal SAS drives 1 Ethernet adapter with four 1Gbit ports

The following two scenarios where tested to provide information on the:1. Maximum request throughput supported by the specific virtual server configuration. Testing included sequen-

tially sending requests and waiting for replies without wait times, over multiple connections. This is not a mea-sure of the maximum number of users since no “think time” is used.

2. Multiple user requests supported, using a think time. Requests submitted with average “think time” of 15 sec-onds (based on random think times of 1 to 30 seconds). Throughput calculated to be the number of requests pro-cessed over a period. For example, a result of 66 requests per second based on 1000 requests over 15 seconds (1000/15).

Notes: Average response times are not provided, but can be calculated to be sub-second based on the number of requests

processed within a second. For example, 50 requests per second would have an average response time of .02 seconds (1/50).

Requests included sending fixed size (~5k) email to the mail server and waiting for delivery to the user’s mail-box. Testing showed that obtaining email from the server added very little to the server utilization. That is, Postfix and anti-spam processing utilized the system more than Dovecot retrieving the emails.

Web requests based on returning an balanced number of static and dynamic web pages managed by Drupal con-tent management server. Dynamic web page requests used requests for reports, statistics and content from Dru-pal. Use of dynamic pages resulted in a significant increase in disk utilization.

OSIS Reference Architecture and Sizing Guide.odt IBM Confidential Page 19

Page 20: IBM PowerLinux™ Open Source Infrastructure Services Reference Architecture and Sizing Guide

OSIS Reference Architecture and Sizing Guide

7.1.1 Tested Configuration - Topology

7.1.2 Tested Configuration Details

Virtual Server At-tribute

Mail / DBVirtual Server

Web Virtual Server

Number of CPUs 1 1Number of vCPUs 1 1Size of Memory(GB) 4 4Number of disks 1 and RAID1 1Ethernet Virtual Virtual

NOTE: further details for a similar configuration provided in section 12.2.

OSIS Reference Architecture and Sizing Guide.odt IBM Confidential Page 20

Page 21: IBM PowerLinux™ Open Source Infrastructure Services Reference Architecture and Sizing Guide

OSIS Reference Architecture and Sizing Guide

7.1.3 Tested Configuration Results

7.1.3.1 Web WorkloadTest Sce-nario

Maximum Re-quests Per Sec-

ond

Number of Con-current Users

Web/Database Virtual Server with 1 CPU% CPU Uti-

lizationMemory Uti-

lizationDisk Uti-lization

Network Uti-lization

1 34 n/a 96% 3.4 GB 18% to 34% Minimal2 34 ~500 (15 sec aver-

age think time)96% Minimal Minimal

Figure 4 - Test Configuration - Web Requests

Web testing observations:1. Web pages referenced in the test were both static and dynamic, which re-

quired the Apache web server application and the Drupal server to use addi-tional CPU and disk resources. Disk utilization increased from about 3% to over 30% when changing from 0% to 50% dynamic web page content.

2. Retrieving different types of web page content impacts system resources dif-ferently. For example, dynamic content resulted in higher disk utilization as database queries to occur.

3. Additional testing showed adding additional physical CPUs to the web virtual server increased the throughput near linearly. That is, two CPUs provided about twice the throughput of one CPU. For additional information on scal-ing, refer to section 8 Scalability on page 23.

Below is an example for simulating a web client workload,httperf --hog --server=<web server hostname> --uri=<web page> --num-conns=1000 --num-calls=100 --period=1,30

httperf is the Linux open source utility for generating URL web requests

--hog means to use as many TCP ports as necessary

--num-conns=1000 means to create 1000 connections to create

--num-calls=100 means to issue 100 requests on each of the connection created Running this command multiple times for different web pages can maximize utilization of the virtual server's vCPUs by generating activity

across multiple web application threads

7.1.3.2 Mail Workload

Test Sce-nario

Maximum Requests

per Second

Number of Con-current Users

Mail Virtual Server with 1 CPUs% CPU Uti-

lizationMemory

Utilization% Disk Utiliza-

tion (Max)Network

Utilization1 17.3 n/a 51% 2.8 GB 85% minimal

1 (anti-spam) 0.8 50% 3%2 16 20 (with 15 sec aver-

age think time)35% 50%

2 (anti-spam) 0.9 99% 3%

Figure 5 - Test Configuration - Mail Requests

Mail testing observations:1. Testing was not able to drive utilization higher because of the time latency with

the clients (waiting on requests between email deliveries). Removing mail de-livery from the test scenario allowed the CPU utilization to reach near 100% and Requests per Second increased by about 400%.

2. Use of anti-spam (Procmail and SpamAssassin) significantly reduced emails Re-quests per Second (from 17.3 to 0.8). Results shown using Linux software RAID1.

OSIS Reference Architecture and Sizing Guide.odt IBM Confidential Page 21

PowerLinux Highlight: > 100k web pages per hour returned during testing with one physical core.

PowerLinux Highlight: 2x throughput seen during testing with 2 CPUs.

PowerLinux Highlight: > 3600 emails per hour with anti-spam protection using one core.

Page 22: IBM PowerLinux™ Open Source Infrastructure Services Reference Architecture and Sizing Guide

OSIS Reference Architecture and Sizing Guide

3. Significant disk I/O occurs since messages are first stored in an “incoming” queue and then moved the user’s mail-box on the server.

4. Disk I/O contention can be eased by:a. adding a second virtual server, with a second virtual diskb. using either software or hardware RAID as follows:

i. Software RAID: using Linux RAID support with multiple virtual disks, each assigned to a different physical disk. Testing with RAID1 showed:1. With anti-spam: no significant changes to CPU or disk utilizations2. Without anti-spam: a drop in disk utilization from 85% to 50%, with no significant change in Requests

per Second and CPU/memory utilizations.ii. Hardware RAID: configuring a system to use RAID with the physical disk, each virtual disk will then have

multiple physical disks assigned to it.5. Changing the physical CPU entitlements, refer to section 8 Scalability for details.

Below is an example for simulating a mail client workload,smtp-source -R 30 -s 10 -l 5120 -m 200 -c -f <from email ID> -t <to email ID> <mail server hostname>:25

smtp-source is the Linux open source utility for sending smtp emails

-R 30 means to send emails with a random think time of 0 to 30 seconds. Note, if not specified the messages are sent with no “think time”, resulting in maximum throughput

-s 10 means to send the emails over 10 parallel connections -l 5120 means send emails of 5120 byte (fixed) size

-m 200 means to send 200 emails

-c means to display a counter

:25 means to use the default smtp port

7.2 An Example of Hardware Estimation

The following shows a simple method of estimating a system based on an client example and testing information provided in this paper.

Consider a customer who needs a configuration that might handle:1. at most 2000 users requesting both static and dynamic web pages on an average of once every 15 seconds2. 1000 emails per hour being handled by the mail server running anti-spam

Applying these requirements to the test configuration example discussed earlier:1. 2000 web users downloading pages every 15 seconds results in about 133 Re-

quests per second (2000/15). If we consider a target CPU of no more than 80%, we can recalculate the example testing shown earlier of 34 Requests per sec at 96%, to be 28 Requests per Second (34 / 96% * 80%) for one CPU. This means a good starting point would be to use 4.6 physical CPUs (133/28) for the web virtual server.

2. 1000 emails per hour are about 0.27 Requests per Second. The example testing shown above indicates ~1 email per second can be received and delivered, well above the requirement. A good starting point might be to use 0.4 physi-cal CPUs for the mail virtual server.

Requirements Tests Results per CPU Sizing @ 80% CPUWorkload Requests

per SecondRequests per Second

CPUUtilization

EstimatedRequests per Second

EstimatedPhysical CPUs

2000 web requests every 15 seconds 133 (2000 / 15) 34 96% 28 (34 / 96% * 80%) 4.6 (133 / 28)1000 emails per hour 0.27 (1000 / 60 / 60) 0.9 99% 0.7 (0.9 / 99% * 80%) 0.4 (0.27 / 0.7)Total 5.0 pCPUs / vCPUs

Table 5 - Hardware Estimation Example

OSIS Reference Architecture and Sizing Guide.odt IBM Confidential Page 22

PowerLinux Highlight: 2000 web users and 1000 emails per hour estimated for 5 cores.

Page 23: IBM PowerLinux™ Open Source Infrastructure Services Reference Architecture and Sizing Guide

OSIS Reference Architecture and Sizing Guide

8 ScalabilitySince IBM PowerLinux utilizes IBM PowerVM for virtualization of the web and mail servers, testing shows (in the following sec-tions) that when increasing the CPU resources, PowerVM pro-vides a near linear increase in the workload throughput. How-ever, near linear scaling of performance does not always occur for x86-bsaed virtualization technologies. To showcase Pow-erVM performance, IBM undertook a study to compare the per-formance of IBM PowerVM and VMware virtualization tech-nologies employing two industry-standard benchmarks.

8.1 Scalability Testing on IBM PowerLinuxIn scalability testing, one of the most important aspects of determining the num-ber of physical CPUs for a virtual server is to insure that an appropriate workload is being applied against the application servers. Since each IBM PowerLinux vir-tual CPU can provide Linux with 1, 2 or 4 threads of execution, the workload needs to exercise all available threads. For example, when benchmarking a mail workload with 4 virtual CPUs, 16 virtual mail clients and corresponding mail boxes were required to exercise the 16 threads available to the mail application.

Typically, one performs simpler tests with older dual core x86 servers since their Simultaneous Multithreading (SMT) is limited to only 2 threads of execution, not 4. Due to misunderstandings of threading impacts on performance when using inappropriate benchmarks, performance measurements are often performed incorrectly and thus do not reflect the true scaling capabilities of IBM PowerLinux utilizing 4 threads of execution. For example, if a benchmark was performed us-ing only one virtual client to send and receive emails, a maximum of 25% of an x86 dual-core SMT system could be uti-lized, while 12.5% of a virtual server with 2 physical CPUs on a PowerLinux system. The PowerLinux system is only half as utilized compared to the x86 system (12.5% of capacity vs. x86 system at 25%), even though both systems were tested the same way.

NOTE: IBM PowerLinux system utilizes IBM POWER7 hardware architecture, which supports Simultaneous Multi-threading (SMT) of up to 4 threads per virtual CPU, providing a performance boost when there are many processes and/or threads running at the same time. During sizing, configuration and testing of virtual servers ensure the workload lever-ages the number of threads available for the virtual server. Adjust the number of threads per CPU (1, 2, or 4), the number of virtual CPUs and/or the workload configuration accordingly.

OSIS Reference Architecture and Sizing Guide.odt IBM Confidential Page 23

PowerLinux Highlight: PowerVM achieves better virtual server scaling than VMware as showing in this report, A Comparison of PowerVM and VMware Virtualization Performance

PowerLinux Highlight: IBM internal testing of 24 virtual servers running on 12 core systems show an estimate of 3% overhead using PowerVM vs 27% overhead using VMware vSphere v4.

PowerLinux Highlight: 4 threads of parallel execution with IBMPOWER7 Architecture, twice that of other architectures. Linuxleverages 4 logical CPUs for every virtual CPU.

Page 24: IBM PowerLinux™ Open Source Infrastructure Services Reference Architecture and Sizing Guide

OSIS Reference Architecture and Sizing Guide

8.2 Web WorkloadThe following chart shows performance scaling of the tested web server con- figu-ration using additional physical CPUs (pCPUs).

Testing observations related to scaling:1. CPU utilization was near linear throughout the test-

ing as expected when using IBM PowerVM. Testing shows about 28 Requests per Second per physical processor (pCPU).

2. Disk utilization remained low as it ranged from 8% for 0.1 pCPU to 60% for 4 pCPUs.

3. Network utilization levels were minimal during the testing since web requests per second reached only about 109 per second and the data amounts were about 8 Kbytes each.

4. Memory utilization remained under 4 GB.

NOTE: Even with only 0.1 pCPUs of utilization, the virtual web server could handle up to 7200 requests per hour us-ing the test website.

8.3 Mail WorkloadThe following chart shows performance scaling of the tested mail server configu-ration using additional physical CPUs (pCPUs).

Testing observations related to scaling:1. Since anti-spam filtering requires significant CPU

resources as compared to processing of email with-out filters, adding additional pCPUs provides near linear scaling as expected with IBM PowerVM.

2. Without anti-spam filtering configured, requests per second increases significantly, but not linearly be-cause of the latency associated with client requests. That is, the client workload utility (fetchmail) was not able to retrieve requests fast enough). NOTE: Since disk utilization was high during initial testing, configuring Linux software RAID1 for the 2 and 4 pCPUs configurations, reduced the disk uti-lization from 100% to 60%-70%. Even though Linux software RAID CPU overhead was not significant (<10%), use of either hardware RAID or network attached storage would also be viable alternative options for reducing disk utilizations without affecting CPU utilization.

3. Network utilization levels were minimal during the testing since mail requests per second reached only a maximum of 49 for 5K messages sizes.

4. Memory utilization remained under 4 GB during testing.

NOTE: Since most mail servers use one or more mail filters, testing shows that the number of pCPUs assigned to the mail virtual server determines the throughput, with near linear scaling.

OSIS Reference Architecture and Sizing Guide.odt IBM Confidential Page 24

Web Requests (estimated for 80% CPU utilization)

0

50

100

150

Re

qu

ests

per

Se

con

d

Web Requests

per Second

2 28 57 109

0.1 pCPU 1 pCPU 2 pCPU 4 pCPU

Mail Requests (estimated for 80% CPU utilization)

0

50

100

pCPUs

Req

ues

ts p

er S

eco

nd

Mail (no

filtering)

17 27 43 49

Mail (spam

filtering)

0.1 1.3 1.5 2.9

0.1 1 2 4

Figure 6 - Web Server Scaling Results

Figure 7 - Mail Server Scaling Results

PowerLinux Highlight: ~360 emails per hour when tested with 1/10 core.

PowerLinux Highlight: >7200 web page returned per hour when tested with 1/10 core.

Page 25: IBM PowerLinux™ Open Source Infrastructure Services Reference Architecture and Sizing Guide

OSIS Reference Architecture and Sizing Guide

9 Availability

When sizing IBM PowerLinux systems for OSIS, consider availability requirements as part of the final hardware and soft-ware configuration. The following sections discuss several hardware and software considerations.

9.1 Hardware Availability ConsiderationsWhen using IBM PowerVM, resources are available to multiple virtual servers as they share CPU, disks, memory and net-work resources. When virtualizing all system resource, IBM PowerVM can provide the optimal availability of the re-source to the virtual server that needs it the most. IBM PowerVM also provides the prioritization of the CPU resource, al-lowing virtual servers to receive either dedicated or higher priority of a CPU resource.

Network redundancy can be accomplished by aggregating several Ethernet ports together (called Link Aggregation), us-ing ports from the same Ethernet card or using multiple Ethernet cards. Multiple virtual servers can share the resulting virtual device. Improvements to network performance and redundancy occur automatically when spreading and balancing requests across multiple Ethernet ports. In sizing a system, consider adding additional Ethernet adapters for both port and adapter redundancy.

For disk and data redundancy, RAID support is available either at the software level by the Linux operating system or at the hardware level through an appropriate IBM PowerLinux backplane. Additional disks are needed and can be installed internally (max of 6), through external expansion drawers or network attached storage. In testing, Linux software RAID1 provided improvements of both performance and redundancy by using three disk drives instead of one.

IBM Systems Director VMControl provides partition mobility, allowing virtual servers moved from one IBM PowerLin-ux system to another. Moving virtual servers to another PowerLinux system provides for availability during both planned outages and for scaling workloads.

9.2 Software Availability Considerations

9.2.1 Virtualization Availability

IBM PowerVM provides support for dual virtual I/O servers, which increases application availability by enabling Virtual I/O Server maintenance without a downtime for the virtual application servers.

NOTE: The Integrated Virtualization Manager (IVM) does not support a dual VIOS configuration. A Hardware Management Console (HMC) or Systems Director Management Console (SDMC) is required.

For additional information on dual VIOS and managing availabil- i-ty, refer to PowerVM Managing & Monitoring.

To provide additional network redundancy and improved throughput, use multiple virtual switches. For planning and im-plementation details, refer to Using Virtual Switches in Pow-erVM to Drive Maximum Value of 10 Gb Ethernet, http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP101752

For a comparison between Integrated Virtualization Manager and other management consoles, refer to IBM Integrated Virtualization Manager Lowering the cost of entry into PowerVM Virtualization.

OSIS Reference Architecture and Sizing Guide.odt IBM Confidential Page 25

Page 26: IBM PowerLinux™ Open Source Infrastructure Services Reference Architecture and Sizing Guide

OSIS Reference Architecture and Sizing Guide

9.2.2 Linux AvailabilityBoth Novell and Red Hat provide the products for clustering of multiple IBM PowerLinux systems:

Novell SUSE Linux Enterprise Server High Availability Extension is included with the license for IBM PowerLinux and supports OpenAIS—the Open Source Initiative's certified implementation of the Service Avail-ability Forum Application Interface Specification. SUSE uses OpenAIS for its clustering messaging and mem-bership layer. OpenAIS is the leading standards-based communication protocol for server and storage clustering. OpenAIS integrates easily with other infrastructure software, including the Apache web server and Postfix.

Red Hat HPC Solution provides is a low-cost, end-to-end software stack for high performance computing. It pro-vides all the tools needed to deploy, run, and manage an HPC cluster in one easy to install package.

OSIS Reference Architecture and Sizing Guide.odt IBM Confidential Page 26

Page 27: IBM PowerLinux™ Open Source Infrastructure Services Reference Architecture and Sizing Guide

OSIS Reference Architecture and Sizing Guide

10 Consolidation

Proposals to clients for IBM PowerLinux deployments of OSIS may involve the consolidation of existing Linux work-loads from x86 servers to IBM PowerLinux servers. The following sections highlight aspects of preparing for these situ-ations. For an example of an overall high-level process view, refer to Figure 1 - Client Technical Discovery, Analysisand Exploitation.

10.1 Collecting and Analyzing Existing Workload UtilizationsWhen possible, it is best to collect information from systems running workloads similar to the workloads for OSIS. If a customer allows it, install software on these servers to monitor system resource utilization such as CPU, network, and disk. IBM support teams can help analyze this information for sizing the appropriate IBM PowerLinux system. In many cases, customers are surprised with under utilization of their x86 servers and start to realize the potential saving by consol-idation onto virtualized servers.

The collection of CPU, disk, memory, and network utilization is possible through collection and reporting software, such as IBM ATS Server Consolidation Monitor (ATS SCON Monitor). ATS SCON Monitor is a 64-bit Microsoft Windows application that runs on Windows .NET Framework version 4. The monitor collects and reports system architecture and perfor-mance data from a user specified list of Windows computers and UNIX/Lin-ux hosts. IBM Techline can produce a PDF report from collected data.

A second data collection utility used by authorized SCON (server consolida-tion)-trained IBM personnel or IBM business partners is Consolidation Discovery and Analysis Tool (CDAT) with VISIAN. Obtain CDAT from the IBM SCON support team by an authorized IBM or IBM business partner representa-tive.

The following is an example of a utilization summary from either ATS SCON or CDAT. This summary is useful as input into in performing a cost analysis, discussed in the next section.

x86 System Name

Workload Type (Java, C, etc)

Average CPU Utilization (%)

Memory Uti-lization (GB)

Network Utiliza-tion (MB/s)

Disk I/O Utiliza-tion (MB/s)

WebServer1 Java, PHP 15% 2 GB 50 100MailServer1 C 20% 3 GB 40 60<more sys-tems>

Figure 8 - Summarizing x86 System Utilization Example

10.2 Sizing a PowerLinux System for ConsolidationWith workload utilization information from existing x86 system, either estimated or measured (see previous section), you may be able to perform a reasonable sizing of IBM PowerLinux system using published benchmarks.

Both IBM and IBM business partners have access to a database of benchmarks through IDEAS CPsystems Competitive Profiles. Examples of benchmarks used for comparing systems are; SPECjbb2005, SPECWeb2005 and SPECint2006rate. For additional information, refer to section 12.5 Industry Standard Benchmark Descriptions on page 35. NOTE: Use IBM Power 730 benchmarks until availability of IBM PowerLinux system benchmarks.

For example, IDEAS provides the following SPECint2006rate results: 578 for a IBM Power 730 16-core (configured with RHEL 6 and 128 GB of memory), or 36.125 per core. 426 for a HP ProLiant DL380 G7 12-core (configured with RHEL 6 and 48 GB of memory), or 35.5 per core.

OSIS Reference Architecture and Sizing Guide.odt IBM Confidential Page 27

Page 28: IBM PowerLinux™ Open Source Infrastructure Services Reference Architecture and Sizing Guide

OSIS Reference Architecture and Sizing Guide

Perform a sizing by using the CPU utilization information of the existing x86 systems to estimate the number of Power-Linux cores required when consolidating the workload. For example, when utilizing only 15% of the x86 CPU:o about 5.3 benchmark units are required (15% of 35.5)o at 80% utilization, consider using 28.9 units per core (80% of 578 / 16 cores)o which allows for an estimate of 1 PowerLinux 7R2 core to run a workload of 21 units (21 / 29)

NOTE: This example assumes that the workload is utilizing all of the threads in all of physical CPUs as was done in the benchmark.

To provide a comprehensive consolidated view, add information for additional x86-based systems using a sizing template as shown below with data from the example above.

System Type

# of Systems

Cores

SPECin-t2006rate

(100%utilization)

Utilization(estimated or target)

TotalSPECint2006rate

(Rate * Utilization)

Consolidation Rate(# cores IBM PowerLinux

7R2 needed =Total per old system / Total

per POWER7 core)IBM Power-Linux 7R2

1 16 578 80% 462 (per system)28.9 (per core)

HP ProLiant DL380 G7

1 12 426 15% 63.9 (per system)5.325 (per core)

2.2(63.9 / 28.9)

<additional x86 systems>Total <n> POWER7 cores

per old system

Figure 9 - Sizing x86 Consolidation to IBM PowerLinux 7R2 Example

10.3 Total Cost of Acquisition and Ownership (TCA/TCO)

Typically, a TCA an/or a one-year TCO is required as part of a consolidation proposal. If there are competitive x86 sys-tems included in the cost analysis, IDEAS CPsystems Competitive Profiles can help provide both list and discounted pric-ing for these x86 systems. This is also very useful if the customer is also considering consolidating to a newer x86 sys-tem.

In addition to hardware costs, a cost analysis should also include software license and maintenance costs. Consolidation can provide significant savings for software costs based on the number of systems or processing cores. When software costs are associated with the number of cores utilized, IBM PowerLinux systems provide the following options for mini-mizing costs:

1. When using software priced based on maximum number of cores assigned to a virtual server, configure a Power-Linux virtual server with a fixed number of physical CPUs using the virtualization manager.

2. When using software priced based on the maximum number of cores running in the system, reconfigure a Power-Linux system to deactivate some of the CPU cores via the Advanced Systems Management (ASM) console.

The following is an example of a template used for estimating the total TCA costs when comparing an IBM PowerLinux system to either an existing or a proposed replacement x86-based Linux system.

Costs One Year Costs (TCO/TCA)IBM PowerLinux 7R2 X86 Competitive

Hardware $20,960 [1] $7,893 [2]

Linux OS included [3] $1,999 [4]

Virtualization included [5] $2,592[6]

Software <middleware, ISV> [7] <middleware, ISV>[8]

Facility n/a n/a

OSIS Reference Architecture and Sizing Guide.odt IBM Confidential Page 28

Page 29: IBM PowerLinux™ Open Source Infrastructure Services Reference Architecture and Sizing Guide

OSIS Reference Architecture and Sizing Guide

Total

Figure 10 –TCA Template Example for One System

Table notes:1. Hardware Costs of IBM PowerLinux

i. List prices provided by IBM “Browse & buy”.ii. Example is for one IBM PowerLinux 7R2 system with 16-core POWER7 3.55 GHz, 64 GB of memory, and two 300

GB disk drives. For more details, see 12.3 System Configuration Example.2. Hardware Costs of x86 Competitive

i. Pricing of systems can be performed using IDEAS CPsystems Competitive Profilesii. Example is for one HP DL380 G7 system with 12-core Xeon X5680 3.33 GHz, 32 GB of memory and two 300 GB

drives.3. Linux OS Costs for IBM PowerLinux are included in the IBM “Browse & buy” list price, above.4. Linux OS Costs for x86 Competitive include:

i. $1,999 for a 2-socket server, unlimited virtual guests and one year of standard subscription.NOTE: Software prices are available at Red Hat Store and SUSENOTE: As of 9/1/2011, VMware is providing SUSE Linux Enterprise Server (SLES) for VMware with subscription at no cost to vSphere customers with support and subscription contacts.

5. Virtualization Costs for PowerLinux are included in the IBM “Browse & buy” list price, above.6. Virtualization Costs for x86 Competitive includes:

i. $2,592 for VMware vSphere Standard ($1,296 per processor), including 1yr supportNOTE: Typically x86 systems use VMware vSphere for virtualization. Information about VMware vSphere v5.0 is available at VMware vSphere v5.0 and pricing at VMware vSphere Pricing.

7. Software Costs for PowerLinux considerations:i. IBM Distributed Software pricing based on IBM Processor Value Unit (PVU). IBM PowerLinux 7R2 requires 70

PVU’s per core. For information on counting the number of cores when running IBM software in a virtual server, refer to the Sub-capacity (Virtual-ization) License Counting Rules for IBM Power Systems.

ii. ISV software pricing may be based on (1) system, (2) sockets/processors, 16 (cores), or (x) cores used by virtual server.

8. Software Costs for x86 considerations:i. IBM Distributed Software pricing based on IBM Processor Value Unit (PVU) ii. For example, Intel Xeon X5680 requires 70 PVU’s per core.

iii. ISV software pricing may be based on (1) system, (2) sockets/processors, 16 (cores), or (x) cores used by virtual server.

9. Facilities Costs i. Optionally included, usually only in a three cost of ownership analysis. Usually not considered an initial cost of ac-

quisition analysis.ii. Facility Costs typically includes both Electrical and Infrastructure Costs. Which can be estimated as follows:

i. Electrical Costs can be estimated with the following calculation:Electrical Costs per Year = Total Power in kW x kW rate per hour x hours per year

a. IDEAS CPsystems Competitive Profiles provides the maximum power consumption of systems.b. IBM Energy Estimator c. HP Power Advisor is available for HP x86 systems.

ii. Infrastructure Costs estimated from system power consumption and floor space. Cost Model: Dollars per kW plus Dollars per Square Foot of Computer Floor explains one method of determining these costs. For example, when using this for a tier III facility:10 year Infrastructure Cost = Total Power in kW x ($23,000 per kW of UPS output for IT) + ($2880 per m2 of allocated raised floor for Computer Room costs)

a. The 10 year costs can be reduced to 3 years by multiplying by 30%b. Total power based on the systems power consumption in kWatts, which is watts divided by 1000.c. Floor space estimated by using 0.6 square meters for a standard 42u rack, divided by the area in the rack

used by the system. For example, a 2u system would use 0.03 m2 = 0.6 x 2/42

OSIS Reference Architecture and Sizing Guide.odt IBM Confidential Page 29

Page 30: IBM PowerLinux™ Open Source Infrastructure Services Reference Architecture and Sizing Guide

OSIS Reference Architecture and Sizing Guide

11 Migration

11.1 Migrating Web (LAMP) Workloads When consolidating from x86-based web workloads to PowerLinux systems, the IBM Installation Toolkit provides the IBM Server Consolidation Tool (SCT) that helps the administrator get through the most time-consuming aspect of server consolidation - replicating the software stack and migrating application data from one system to another.

IBM SCT provides migration of the software stack commonly known as the LAMP stack. LAMP stands for Linux, Apache HTTP Server, MySQL Server, and PHP or Perl or Python. The tool finds the necessary information from an x86-based Linux server (source machine) and installs a new virtual server on an IBM PowerLinux system (target machine) with the same users, groups, configuration files, and data of the source machine. For additional information, refer to the IBM Installation Toolkit website.

11.2 Migrating Existing C/C++ ApplicationsIn situations where there is not yet a version of an open source application supported for the IBM Power Architecture®, IBM Software Development Kit is available to assist with the recompilation of the application for the Power platform. The IBM Software Development Kit for Linux on POWER (SDK) is a free, Eclipse-based Integrated Development Envi-ronment (IDE). The SDK integrates C/C++ source development with the Advance Toolchain, Post-Link Optimization, and classic Linux performance analysis tools, including OProfile and Valgrind.

11.3 Application Compatibility with IBM PowerLinuxFor applications that have dependencies on IBM software, IBM provides Software product compatibility reports, such as the Products that use a specif-ic operating system report that shows applications supported by Linux distri-bution for IBM Power.

For applications that have dependencies on ISV software, IBM provides the following information about partner resources and information on ISV Solu-tions on SUSE and Red Hat at the Resources for selling ISV solutions web-site: Use the Global Solutions Directory to find information about IBM and

ISV applications on PowerLinux Use the SUSE and Red Hat application Catalogs to find information about ISV applications to complete your cus-

tomer’s solution Find links to Business partner information Request Rapid Port assistance

NOTE: Migration planning should not include IBM PowerVM Lx86, since IBM has announced PowerVM Lx86 With-drawal from Marketing as of 1/27/2012 and End of Support on 4/27/2013. Lx86 enables running Linux x86 binaries with IBM PowerLinux.

11.4 Integration with Existing Landscapes

The OSIS reference architecture can integrate into a landscape containing other systems, based on either x86 or IBM Power Systems. Because the OSIS reference architecture is based on open source implementations of standard applica-tion services, continued utilization of existing systems with varying processor architectures alongside and together with IBM PowerLinux systems is seamless. Existing services like DNS, mail, web, web proxy, MySQL, file, print, LDAP, etc. can be used as-is, or be candidates for completely compatible replacement through consolidation on IBM PowerLinux servers.

OSIS Reference Architecture and Sizing Guide.odt IBM Confidential Page 30

Page 31: IBM PowerLinux™ Open Source Infrastructure Services Reference Architecture and Sizing Guide

OSIS Reference Architecture and Sizing Guide

12 Appendix

12.1 Virtualization Management ComparisonThe following provides a quick comparison of the Integrated Virtualization Manager (IVM) and the Hardware Manage-ment Console (HMC). Additional information found in:

1. Systems Director Mgt Console: Intro & Overview, http://www.redbooks.ibm.com/abstracts/sg247860.html?Open2. IBM Integrated Virtualization Manager Lowering the cost of entry into PowerVM Virtualization,

ftp://public.dhe.ibm.com/common/ssi/ecm/en/pow03073usen/POW03073USEN.PDF

OSIS Reference Architecture and Sizing Guide.odt IBM Confidential Page 31

Page 32: IBM PowerLinux™ Open Source Infrastructure Services Reference Architecture and Sizing Guide

OSIS Reference Architecture and Sizing Guide

OSIS Reference Architecture and Sizing Guide.odt IBM Confidential Page 32

Page 33: IBM PowerLinux™ Open Source Infrastructure Services Reference Architecture and Sizing Guide

OSIS Reference Architecture and Sizing Guide

12.2 Reference Configuration

Best Practice: When configuring IBM PowerLinux systems with virtualization using PowerVM, request pre-install of the PowerVM Virtual I/O Server (VIO) software. Select the pre-install as a no-charge option in eConfig (see example).

NOTE: Do not order systems with Linux preloaded since virtualization is configured before Linux. At this time, it is not possible to order a system from IBM with both VIO and Linux preinstalled.

12.3 System Configuration ExampleThe following configuration is for a PowerLinux 7R2 system with:

1. 16-core 3.55 GHz POWER72. 64 GB memory3. 2 300GB 10K RPM SAS disks4. PCIe2 low profile 4-port 1Gb Ethernet adapter5. Linux operating system6. IBM PowerVM for IBM PowerLinux

IBM.com “Browse & buy”: $20,960

OSIS Reference Architecture and Sizing Guide.odt IBM Confidential Page 33

Page 34: IBM PowerLinux™ Open Source Infrastructure Services Reference Architecture and Sizing Guide

OSIS Reference Architecture and Sizing Guide

12.4 Software Configuration ExampleThe following configuration includes all of the software for the OSIS reference architecture. Software not listed is either included with the Linux distribution or available without charge.

1. Red Hat Enterprise Linux (RHEL) for unlimited virtual servers, with 1 year of standard subscription and 1 year of IBM supportNOTE: Instead of shipping Linux distribution media, IBM provides a document (registration card) with the nec-essary download information for the Linux distribution. The $50 DVD Process Charge for Linux on POWER covers providing this information, not actual DVDs.

2. IBM PowerVM for IBM PowerLinux with 1 year of maintenance

OSIS Reference Architecture and Sizing Guide.odt IBM Confidential Page 34

Page 35: IBM PowerLinux™ Open Source Infrastructure Services Reference Architecture and Sizing Guide

OSIS Reference Architecture and Sizing Guide

12.5 Industry Standard Benchmark Descriptions

SPECfp2006: Measures the compute-intensive floating-point speed of the computer processor, memory archi-tecture, and compilers.

SPECfp_rate2006: Determines the number of tasks from a collection of 17 floating-point compute intensive programs that can be run in a specified time.

SPECint2006: Measures the compute-intensive integer speed of the computer processor, memory architecture, and compilers.

SPECint_rate2006: Determines the number of tasks from a collection of 12 integer compute intensive programs that can be run in a specified time.

SPECjbb2005: Evaluates the performance of servers running typical Java™ business applications by simulating an order processor for a wholesale supplier.

LINPACK: Measures how fast a dedicated system can solve a dense system of linear equations as a means of determining the floating-point performance of the system. It is used to gauge effectiveness for high performance and technical computing.

Stream: Measures sustainable memory bandwidth and the corresponding computation rate for simple vector ker-nels.

SPECOMPM2001: Measures a system's parallel processing capabilities for medium problem sizes using a suite of applications based on the OpenMP standards for shared-memory parallel processing. It is used to gauge effec-tiveness for high performance and technical computing.

SPECOMPL2001: Measures a system's parallel processing capabilities for large problem sizes using a suite of applications based on the OpenMP standards for shared-memory parallel processing. It is used to gauge effec-tiveness for high performance and technical computing.

TPC-C™: Evaluates online transaction processing using simulated order-entry and distribution environment ap-plications.

SPECweb2009: Emulates users sending browser requests over broadband Internet connections to a web server using both HTTP and HTTPS. It provides banking, e-commerce, and support workloads, along with a new power workload based on the e-commerce workload. Dynamic content is implemented in PHP, JSP, and ASPX.

SPECweb2005: Emulates users sending browser requests over broadband Internet connections to a web server. It provides three new workloads: a banking site (HTTPS), an e-commerce site (HTTP/HTTPS mix), and a sup-port site (HTTP). Dynamic content is implemented in PHP, JSP, and ASPX.

OSIS Reference Architecture and Sizing Guide.odt IBM Confidential Page 35

Page 36: IBM PowerLinux™ Open Source Infrastructure Services Reference Architecture and Sizing Guide

OSIS Reference Architecture and Sizing Guide

13 References

IBM PowerVM Virtualization

1. A Comparison of PowerVM and VMware Virtualization Performance, http://www.ibm.com/common/ssi/cgi-bin/ssialias?infotype=SA&subtype=WH&appname=STGE_PO_PO_USEN&htmlfid=POW03041USEN&attachment=POW03041USEN.PDF

2. IBM PowerVM Virtualization Introduction and Configuration, http://www.redbooks.ibm.com/abstracts/sg247940.html?Open

3. IBM Integrated Virtualization Manager Lowering the cost of entry into PowerVM Virtualization, ftp://public.dhe.ibm.-com/common/ssi/ecm/en/pow03073usen/POW03073USEN.PDF

4. Achieve technical and business benefits through processor virtualization, http://www.ibm.com/developerworks/aix/library/au-provirt/index.html

5. IBM System Planning Tool, http://www.ibm.com/systems/support/tools/systemplanningtool/index.shtml

Virtual I/O Server (VIOS)

1. IBM Infocenter, http://publib.boulder.ibm.com/infocenter/powersys/v3r1m5/index.jsp?topic=/iphb1/iphb1kickoff.htm

IBM Systems Director

1. IBM Systems Director Management Console: Introduction and Overview, http://www.redbooks.ibm.com/abstracts/sg247860.html

IBM PowerLinux

1. IBM Installation Toolkit (website), http://www.software.ibm.com/webapp/set2/sas/f/lopdiags/installtools/home.html 2. Think Power Linux (website), http://www.ibm.com/developerworks/group/tpl

Consolidation

1. IBM Installation Toolkit (website), http://www.software.ibm.com/webapp/set2/sas/f/lopdiags/installtools/home.html 2. IBM Software Development Kit, http://www.ibm.com/webapp/set2/sas/f/lopdiags/sdklop.html 3. IDEAS CPsystems Competitive Profiles, http://partners.boulder.ibm.com/src/compdlib.nsf/pages/BPThirdPartyTools 4. IBM Processor Value Unit (PVU), http://www.ibm.com/software/lotus/passportadvantage/pvu_licensing_for_customer-

s.html 5. IBM Energy Estimator, http://www-912.ibm.com/see/EnergyEstimator 6. Cost Model: Dollars per kW plus Dollars per Square Foot of Computer Floor, http://uptimeinstitute.org/wp_pdf/(TU-

I3029A)CostModelDollarsperkWPlusDollars.pdf 7. ATS SCON Monitor, https://www.ibm.com/partnerworld/wps/servlet/mem/ContentHandler/PSIBMATSSCONMonitor 8. IBM Techline, mailto:[email protected] 9. IBM SCON support team, mailto:[email protected]

Migration

1. IBM Installation Toolkit (website), http://www.software.ibm.com/webapp/set2/sas/f/lopdiags/installtools/home.html 2. IBM Software Development Kit, http://www.ibm.com/webapp/set2/sas/f/lopdiags/sdklop.html 3. Software product compatibility reports, http://publib.boulder.ibm.com/infocenter/prodguid/v1r0/clarity/index.jsp 4. Resources for selling ISV solutions, http://public.dhe.ibm.com/common/ssi/ecm/en/pow03041usen/POW03041USEN.PDF

http:/www.ibm.com/partnerworld/wps/servlet/ContentHandler/pw_com_reseller5. Rapid Port, http://www.ibm.com/partnerworld/mem/support/trs_develop_rapidport.html 6. IBM information center, http://publib.boulder.ibm.com/infocenter/lnxinfo/v3r0m0/topic/liaay/kickoff_powerlinux.htm

IBM Software

1. IBM PowerVM for IBM PowerLinux, http://www.ibm.com/systems/power/software/virtualization/editions/index.html 2. IBM Installation Toolkit, http://www14.software.ibm.com/webapp/set2/sas/f/lopdiags/installtools 3. Hardware Management Console (HMC), http://www.ibm.com/developerworks/wikis/display/virtualization/HMC 4. IBM Systems Director Management Console (SDMC), http://www.redbooks.ibm.com/abstracts/sg247860.html 5. IBM Systems Director, http://www-03.ibm.com/systems/power/software/management/express.html

OSIS Reference Architecture and Sizing Guide.odt IBM Confidential Page 36

Page 37: IBM PowerLinux™ Open Source Infrastructure Services Reference Architecture and Sizing Guide

OSIS Reference Architecture and Sizing Guide

6. IBM Systems Director VMControl, http://www.ibm.com/systems/software/director/vmcontrol/enterprise.html Open Source Software

1. Enterprise Open Source Usage Ubiquitous (article), http://olex.openlogic.com/wazi/2011/survey-shows-enterprise-open-source-usage-ubiquitous/

2. SUSE Linux Enterprise Server (SLES) for VMware (product website), http://www.vmware.com/products/sles-for-vmware/overview.html

3. Virtualizing Business-Critical Applications on VMware vSphere, http://www.vmware.com/files/pdf/VMW_10Q1_WP_vSPHERE_USLET_EN_R6_proof.pdf

4. Postfix, http://www.postfix.org/documentation.html 5. Dovecot, http://www.dovecot.org 6. Cyrus, http://www.cyrusimap.org/ 7. fetchmail, http://www.fetchmail.info/ 8. procmail, http://www.procmail.org/ 9. SpamAssassin, http://spamassassin.apache.org 10. smtp-source, http://www.postfix.org/smtp-source.1.html 11. Apache HTTP Server, http://httpd.apache.org 12. MySQL, http://www.mysql.com 13. PHP, http://www.php.net 14. Berkeley Internet Naming Domain (BIND), http://docs.redhat.com/docs/en-

US/Red_Hat_Enterprise_Linux/5/html/Deployment_Guide/ch-bind.html 15. Squid, http://www.squid-cache.org 16. Ganglia, http://ganglia.sourceforge.net 17. webmin, http://www.webmin.com/docs.html 18. Drupal, http://drupal.org/

OSIS Reference Architecture and Sizing Guide.odt IBM Confidential Page 37

Page 38: IBM PowerLinux™ Open Source Infrastructure Services Reference Architecture and Sizing Guide

OSIS Reference Architecture and Sizing Guide

Disclaimer and Trademarks13.1

The information in this Guide is intended to provide guidance for those implementing IBM PowerLinux Open Source Infrastructure Services (OSIS). It discusses findings based on a solution that was created and tested under laboratory conditions. These findings may not be realized in all customer environments, and implementation in such environments may require additional steps, configurations, and performance analysis.

The following paragraph does not apply to the United Kingdom or any other country where such provisions are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION

PROVIDES THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NONINFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer of express or implied warranties in certain transactions, therefore, this statement may not apply to you.

This information could include technical inaccuracies or typographical errors. Changes are periodically made to the information herein; these changes will be incorporated in new editions of the publication.

IBM may make improvements and/or changes in the product(s) and/or the program(s) described in this publication at any time without notice.

Implementation and certification of the solution rests on the implementation team. The users of this guide should always check the latest release information in the product Readme file(s) and check the product web pages for the latest updates and findings.

Any references in this information to nonIBM web sites are provided for convenience only and do not in any manner serve as an endorsement of those web sites. The materials at those web sites are not part of the materials for this IBM product and use of those web sites is at your own risk.

This information was developed for products and services offered in the U.S.A.

IBM may not offer the products, services, or features discussed in this document in other countries.

Consult your local IBM representative for information on the products and services currently available in your area. Any reference to an IBM product, program, or service is not intended to state or imply that only that IBM product, program, or service may be used. Any functionally equivalent product, program, or service that does not infringe any IBM intellectual property right may be used instead. However, it is the user's responsibility to evaluate and verify the operation of any nonIBM product, program, or service.

Linux is a trademark of Linus Torvalds in the United States, other countries or both.

The registered trademark Linux® is used pursuant to a sublicense from LMI, the exclusive licensee of Linus Torvalds, owner of the mark on a worldwide basis.

Intel, Itanium and Xeon are registered trademarks and MMX and Pentium are trademarks of Intel Corporation in the United States and/or other countries

AMD Opteron is a trademark of Advanced Micro Devices, Inc.

Java and all Javabased trademarks and logos are trademarks of Sun Microsystems, Inc. In the United States and/or other countries.

All performance information was determined in a controlled environment. Actual results may vary. Performance information is provided “AS IS” and no warranties or guarantees are expressed or implied by IBM. Buyers should consult other sources of information, including system benchmarks, to evaluate the performance of a system they are considering buying.

SPECjAppServer, SPEC OMP, SPECviewperf, SPECapc, SPEChpc, SPECjvm, SPECmail, SPECimap and SPECsfs are trademarks of the Standard Performance Evaluation Corporation (SPEC).

Photographs show engineering and design models. Changes may be incorporated in production models.

Copying or downloading the images contained in this document is expressly prohibited without the written consent of IBM.

© IBM Corporation 2010IBM CorporationSystems and Technology GroupRoute 100Somers, New York 10589

Produced in the United States of AmericaNovember 2011All Rights Reserved

This document was developed for products and/or services offered in the United States. IBM may not offer the products, features, or services discussed in this document in other countries.

The information may be subject to change without notice. Consult your local IBM business contact for information on the products, features and services available in your area.

All statements regarding IBM future directions and intent are subject to change or withdrawal without notice and represent goals and objectives only.

IBM, the IBM logo, ibm.com, IBM Systems Director VMControl, POWER, POWER Hypervisor, Power Systems, Power Architecture, PowerVM, MicroPartitioning, are trademarks or registered trademarks of International Business Machines Corporation in the United States, other countries, or both. If these and other IBM trademarked terms are marked on their first occurrence in this information with a trademark symbol (® or ™), these symbols indicate U.S. registered or common law trademarks owned by IBM at the time this information was published. Such trademarks may also be registered or common law trademarks in other countries. A current list of IBM trademarks is available on the web at "Copyright and trademark information" at www.ibm.com/legal/copytrade.shtml

Linux is a trademark of Linus Torvalds in the United States, other countries or both.

Intel, Itanium and Xeon are registered trademarks and MMX and Pentium are trademarks of Intel Corporation in the United States and/or other countries

AMD Opteron is a trademark of Advanced Micro Devices, Inc.

Java and all Javabased trademarks and logos are trademarks of Sun Microsystems, Inc. In the United States and/or other countries.

Other company, product, and service names may be trademarks or service marks of others.

IBM hardware products are manufactured from new parts, or new and used parts. In some cases, the hardware product may not be new and may have been previously installed. Regardless, our warranty terms apply.

This equipment is subject to FCC rules. It will comply with the appropriate FCC rules before final delivery to the buyer.

Information concerning nonIBM products was obtained from the suppliers of these products or other public sources. Questions on the capabilities of the nonIBM products should be addressed with those suppliers.

When referring to storage capacity, 1 TB equals total GB divided by 1000; accessible capacity may be less.

The IBM home page on the Internet can be found at: http://www.ibm.co m .

The IBM Power Systems home page on the Internet can be found at: http://www.ibm.com/systems/power/

xxxxxxxxUSEN00

End of Document

OSIS Reference Architecture and Sizing Guide.odt IBM Confidential Page 38