• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
IBM PowerLinux™ Open Source Infrastructure Services Reference Architecture and Sizing Guide
 

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

on

  • 973 views

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 ...

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

Statistics

Views

Total Views
973
Views on SlideShare
973
Embed Views
0

Actions

Likes
0
Downloads
3
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

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

    • IBM PowerLinux™ Open Source Infrastructure ServicesReference Architecture and Sizing Guide 2012-04-23 (Version 516) Paul Clarke and Jason Furmanek Lab Services Power Systems pacman@us.ibm.com furmanek@us.ibm.com
    • SummaryThe Open Source Infrastructure Services (OSIS) Reference Architecture and Sizing Guideprovides an overview of an open source application landscape with IBM PowerLinux™servers. The document first introduces a popular set of open source applications in supportof 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 thenshows 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 applicationson 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.
    • OSIS Reference Architecture and Sizing GuideTable 1 - FAQ Quick ReferenceFAQ Response Quick Reference LinkIs open source ready for use today in the En­ Yes, 73% of survey respondents considered Introductionterprise? open source on equal footing to propriety soft- ware.What software is included in the OSIS refer­ OSIS includes virtualization software from Solution Landscapeence architecture landscape? IBM and open source software from Linux distributions and other providers.How do I engage with clients about OSIS? Discover the client’s open source use and Solution Guide Use plans, optionally analyze for consolidation and sizing, and show them how to exploit IBM PowerLinux systems.Is virtualization that important for an open Yes, virtualization using IBM PowerVM pro- Virtualization with IBM PowerVM and Error:source landscape? vides system resource sharing, allowing for Reference source not found higher system utilization while efficiently run- ning multiple workloads.Does the OSIS reference architecture land­ Yes, OSIS can run on any configuration of Possible Solution Architecturesscape allow for hardware flexibility for inte­ PowerLinux hardware and integrate with othergration and scaling? Linux systems.Are there specific sizing metrics for OSIS? Yes, web visits and number of emails pro- Metrics of Interest cessed are commonly used metrics.How do I size a system with known require­ Use the results from test examples in this doc- Sizingments? ument as a starting point and optionally a proof-of-concept (POC).Are there performance throughput examples Yes, included in this document are results Performance Results foravailable? from measuring web and mail requests in a simulated client environment.How do I estimate system requirements? Estimate system requirements for CPU, mem- An Example of Hardware Estimation ory and networking by using test results from an existing environment or benchmarks.How can I scale the OSIS landscape? Through dynamic sharing of resources, adding Scalability additional resources to virtual servers, using external storage, or by adding additional sys- tems.How can I improve availability of the OSIS By using hardware and software availability Availabilitylandscape? options such as redundant hardware, dual soft- ware configurations, and clustered systems.How would I perform a system consolidation First, either measure or estimate the utilization Collecting and Analyzing Existing Workloadsizing? of the current systems. Then, use comparative Utilizations and Sizing a PowerLinux System benchmark results to estimate PowerLinux system requirements.How would I perform a competitive cost After sizing PowerLinux system(s), compare Total Cost of Acquisition and Ownershipanalysis? all acquisition and ownership costs (hardware, (TCA/TCO) software and facilities) for both PowerLinux and competitive systems.Can open source applications be migrated to Yes, IBM provides tools for migrating web MigrationPowerLinux systems? (LAMP) configurations and if necessary, re- compiling C/C++ programs.OSIS Reference Architecture and Sizing Guide.odt IBM Confidential Page 3
    • OSIS Reference Architecture and Sizing GuideTable of Contents1 INTRODUCTION...................................................................................................................................................62 SOLUTION GUIDE USE.......................................................................................................................................73 OSIS REFERENCE ARCHITECTURE...............................................................................................................84 POSSIBLE SOLUTION ARCHITECTURES....................................................................................................13 4.1 SMALL/DEVELOPMENT SOLUTIONS ARCHITECTURE............................................................................................................13 4.2 MEDIUM SOLUTIONS ARCHITECTURE...............................................................................................................................13 4.3 LARGE SOLUTIONS ARCHITECTURE.................................................................................................................................145 OSIS REFERENCE ARCHITECTURE TEST DESCRIPTION.....................................................................15 5.1 WEB SERVING TEST SCENARIO......................................................................................................................................15 5.2 MAIL SERVING TEST SCENARIO.....................................................................................................................................16 5.3 METRICS OF INTEREST..................................................................................................................................................166 SIZING...................................................................................................................................................................18 6.1 WORKLOAD ESTIMATION...............................................................................................................................................18 6.2 APPLICATION PERFORMANCE ESTIMATION........................................................................................................................187 PERFORMANCE RESULTS FOR OSIS...........................................................................................................19 7.1 TESTED CONFIGURATIONS..............................................................................................................................................19 7.1.1 Tested Configuration - Topology..............................................................................................................20 7.1.2 Tested Configuration Details....................................................................................................................20 7.1.3 Tested Configuration Results....................................................................................................................21 7.2 AN EXAMPLE OF HARDWARE ESTIMATION.......................................................................................................................228 SCALABILITY......................................................................................................................................................23 8.1 SCALABILITY TESTING ON IBM POWERLINUX.................................................................................................................23 8.2 WEB WORKLOAD........................................................................................................................................................24 8.3 MAIL WORKLOAD........................................................................................................................................................249 AVAILABILITY ..................................................................................................................................................25 9.1 HARDWARE AVAILABILITY CONSIDERATIONS....................................................................................................................25 9.2 SOFTWARE AVAILABILITY CONSIDERATIONS.....................................................................................................................25 9.2.1 Virtualization Availability.........................................................................................................................25 9.2.2 Linux Availability......................................................................................................................................2610 CONSOLIDATION ..............................................................................................................................................27 10.1 COLLECTING AND ANALYZING EXISTING WORKLOAD UTILIZATIONS....................................................................................27 10.2 SIZING A POWERLINUX SYSTEM FOR CONSOLIDATION.......................................................................................................27 10.3 TOTAL COST OF ACQUISITION AND OWNERSHIP (TCA/TCO)...........................................................................................2811 MIGRATION.........................................................................................................................................................30 11.1 MIGRATING WEB (LAMP) WORKLOADS ......................................................................................................................30 11.2 MIGRATING EXISTING C/C++ APPLICATIONS..................................................................................................................30 11.3 APPLICATION COMPATIBILITY WITH IBM POWERLINUX....................................................................................................30 11.4 INTEGRATION WITH EXISTING LANDSCAPES......................................................................................................................3012 APPENDIX.............................................................................................................................................................31 12.1 VIRTUALIZATION MANAGEMENT COMPARISON..................................................................................................................31 12.2 ECONFIG REFERENCE CONFIGURATION............................................................................................................................33OSIS Reference Architecture and Sizing Guide.odt IBM Confidential Page 4
    • OSIS Reference Architecture and Sizing Guide 12.3 HARDWARE CONFIGURATION EXAMPLE 1........................................................................................................................33 12.4 HARDWARE CONFIGURATION EXAMPLE 2........................................................................................................................34 12.5 SOFTWARE CONFIGURATION EXAMPLE............................................................................................................................35 12.6 INDUSTRY STANDARD BENCHMARK DESCRIPTIONS............................................................................................................3613 REFERENCES......................................................................................................................................................37 DISCLAIMER AND TRADEMARKS................................................................................................................39FIGURE 1 - CLIENT TECHNICAL DISCOVERY, ANALYSIS AND EXPLOITATION..........................................7FIGURE 2 - OSIS REFERENCE ARCHITECTURE OVERVIEW................................................................................8FIGURE 3 - OSIS TEST CONFIGURATION..................................................................................................................15FIGURE 4 - TEST CONFIGURATION - WEB REQUESTS.........................................................................................21FIGURE 5 - TEST CONFIGURATION - MAIL REQUESTS.......................................................................................21FIGURE 6 - WEB SERVER SCALING RESULTS........................................................................................................24FIGURE 7 - MAIL SERVER SCALING RESULTS......................................................................................................24FIGURE 8 - SUMMARIZING X86 SYSTEM UTILIZATION EXAMPLE.................................................................27FIGURE 9 - SIZING X86 CONSOLIDATION TO IBM POWERLINUX 7R2 EXAMPLE.......................................28FIGURE 10 –TCA/TCO TEMPLATE EXAMPLE FOR ONE SYSTEM.....................................................................28TABLE 1 - FAQ QUICK REFERENCE.............................................................................................................................3TABLE 2 - SMALL SOLUTION ARCHITECTURE CONFIGURATION - EXAMPLE...........................................13TABLE 3 - MEDIUM SOLUTION ARCHITECTURE CONFIGURATION - EXAMPLE.......................................13TABLE 4 - LARGE SOLUTION ARCHITECTURE CONFIGURATION - EXAMPLE...........................................14TABLE 5 - HARDWARE ESTIMATION EXAMPLE....................................................................................................22OSIS Reference Architecture and Sizing Guide.odt IBM Confidential Page 5
    • OSIS Reference Architecture and Sizing Guide1 IntroductionA survey by OpenLogic reveals that many enterprises consider using open source andadoption of open source is on the rise. The IBM PowerLinux™ Open Source Infra-structure Services (OSIS) reference architecture consists of a landscape of opensource software available from Linux distributions provided by Red Hat and SUSEand the open source community.IBM PowerLinux servers with IBM PowerVM™ offer a highly virtualized, workloadoptimized, cloud-ready platform that can support more workloads per server andgreater throughput per virtual server – saving up to 16% or more in acquisition costsas compared to HP ProLiant systems with VMware 1. 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 withcommercial 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 PowerVMs superior virtualization capabilities enables up to 160 simultaneouslyactive virtual servers on a single 16-core system. Such a capable system provides an excellent reference platform for aconsolidated open source solution.This paper describes a study IBM has performed with several open source applications. Based on experiences and resultsfrom 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 twosocket, 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.pdfOSIS Reference Architecture and Sizing Guide.odt IBM Confidential Page 6
    • OSIS Reference Architecture and Sizing Guide2 Solution Guide UseWhen reviewing the potential use IBM PowerLinux systems with open source applications, OSIS solution guides can bepart 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 environment 3. Exploit with proposals based on IBM PowerLinux and OSIS Figure 1 - Client Technical Discovery, Analysis and ExploitationOSIS Reference Architecture and Sizing Guide.odt IBM Confidential Page 7
    • OSIS Reference Architecture and Sizing Guide3 OSIS Reference Architecture3.1 OSIS Solution LandscapeThe IBM PowerLinux Open Source Infrastructure Services (OSIS) solution landscape consists of IBM PowerLinux 7R2hardware, virtualization software, Linux OS and open source applications. Refer to Figure 2 below for details.Figure 2 - OSIS Reference Architecture OverviewThe 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
    • 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, disk3. 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 managementThis 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
    • OSIS Reference Architecture and Sizing Guide3.1.1 Landscapes Based on x86 SystemsTypical x86-based landscapes for open source mail and web servers consist of workstations, multiple application serversand possibly storage servers. As shown in Illustration 2: Application Services Data Flows, a typical end user requestflows 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. Illustration 2: Application Services Data Flows 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 Powersystems.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 orreplacements 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 LogicalPartition (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
    • OSIS Reference Architecture and Sizing Guidemance 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), andSuspend/Resume. PowerVM is a combination of hardware enablement and value-added software. Additional informationis 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 mailservers utilizing a pool of system resources with one IBM PowerLinux system. Additional load on the physical networkcan be avoided by utilizing a high capacity virtual network between these virtual servers. The benefits of virtualizingworkloads 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 virtualizationtechnologies that only add CPU and memory resources to active virtual servers, PowerVM can also remove both CPU andmemory resources, reallocating these resources transparently to other virtual servers when and where the resources areneeded. For example, PowerVM can dynamically remove resources from an under-utilized virtual mail server and addthe 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 corePower System. For additional information on higher system utilization and performance using PowerVM, refer to AComparison of PowerVM and x86-Based Virtualization Performance.OSIS Reference Architecture and Sizing Guide.odt IBM Confidential Page 11
    • OSIS Reference Architecture and Sizing Guide3.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- PowerLinux Highlight: Consolidate up toLinux systems using virtual servers as shown in Illustration 3: OSIS 160 physical servers to a single PowerLinuxWeb and Mail Virtual Servers. Migration of multiple physical 16 core system using PowerVM and virtualservers to virtual servers is possible without changing the network servers.flow or application handling of requests. However, there are sever- al 16 cores per systemkey differences to point out: x max 10 vCPUs per core 1. It is possible to configure Virtual Ethernet con- x max 4 threads per vCPU nections directly between web and database virtual servers, = max 640 threads (or logical CPUs per system) 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. PowerVMs 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. Illustration 3: OSIS Web and Mail Virtual ServersOSIS Reference Architecture and Sizing Guide.odt IBM Confidential Page 12
    • OSIS Reference Architecture and Sizing Guide4 Possible Solution Architectures PowerLinux Highlight: Adding additional CPUs,Using Illustration 1: OSIS Reference Architecture above as an memory, storage, and networking ports tooverall architecture landscape for OSIS, you can modify several as- PowerLinux systems allows the OSIS landscape topects of the architecture to address small, medium, and large con- scale.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 PowerLinuxsystem using virtual servers with minimal memory and CPU resources required. Use internal storage to handle the lowerdisk throughput requirements. You may use unused CPU capacity for additional open source applications such as file,print, and networking. PowerLinux Cores per System Memory (GB) per Storage Network Virtualization Systems System Adapters Console 1 16 32 6 x Internal Disks 1 (4 port 1Gb) PowerVM IVMTable 2 - Small Solution Architecture Configuration - Example4.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 Cores per System Memory (GB) per Storage Network Virtualization Systems System Adapters Console 1 16 64 External – 12S 1 (4 port 1Gb) PowerVM IVM SAS Expansion DrawerTable 3 - Medium Solution Architecture Configuration - ExampleOSIS Reference Architecture and Sizing Guide.odt IBM Confidential Page 13
    • OSIS Reference Architecture and Sizing Guide4.3 Large Solutions ArchitectureIn a large solution landscape where high workload is expected, all web, mail, file, print, and networking could run on oneor more IBM PowerLinux systems, each configured with maximum memory and CPU resources. Multiple networkadapters address network throughput requirements for mail and file serving. Multiple network attached storage adapters(Fibre Channel) improve disk bandwidth. PowerLinux Cores per System Memory (GB) per Storage Network Virtualization Systems System Adapters Console 2 or more 16 128 External – SAN 2 (4 port 1Gb) HMC or SDMCTable 4 - Large Solution Architecture Configuration - ExampleWhen 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 asfollows:  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 systemsolutions, 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 products 2. 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
    • OSIS Reference Architecture and Sizing Guide5 OSIS Reference Architecture Test DescriptionTesting of the OSIS reference architecture consisted of both web and mail serving using the lightweight servers includedwith 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 Configuration5.1 Web Serving Test ScenarioThe web serving test scenario is based on the Linux operating system, Apache, MySQL and PHP (collectively calledLAMP), along with a simulation of virtual clients browsing a website based on Drupal. The following describes the testscenario (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
    • 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 connections3. 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 emails3. 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 ofRequests 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 ofweb or mail requests. To determine the maximum Number of Requests per Second, a sufficient number of instances ofthe 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 serverconfigured 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
    • OSIS Reference Architecture and Sizing GuideNOTE: simultaneous execution of the virtual client workload is required for the web and mail applications to driveenough 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. Forexample, 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 logicalCPU 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 specificto the web and mail application used and the specific type of requests. Expect these values to be different for differenttypes 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
    • OSIS Reference Architecture and Sizing Guide6 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 usingvirtual servers. Configure virtual servers with either dedicated or prioritized shared resources. For example, configure avirtual server with dedicated processor(s), or dedicated network port(s). IBM PowerVM provides near linear scaling ofthroughput, 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 fora specific web workload and a second virtual server with 3 CPUs is required for a specific mail workload, 5 CPUs shouldbe 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 applicationneeds to receive and return email to mail clients. In these cases, an estimate of the workload would be the number of weband 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 inthe 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 be375,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 onpage 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 requestper 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 Secondfor 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 databasevirtual server configured with 0.2 CPUs, the aggregated total would be 1.2 CPUs. Since most capacity measurementsutilize 100% CPU, it may be better to adjust the Requests per Second per CPU throughput to 80% CPU utilization. For anexample of 50 web Requests per Second that used 1.2 CPUs, this would calculate to be about 33 Requests per Second perCPU (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 clientsby running multiple open source workload generators simultaneously to achieve near 100% CPU utilization. As notedabove, 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
    • OSIS Reference Architecture and Sizing Guide7 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 portsThe 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
    • OSIS Reference Architecture and Sizing Guide7.1.1 Tested Configuration - Topology7.1.2 Tested Configuration Details Virtual Server At- Mail / DB Web tribute Virtual Server Virtual Server Number of CPUs 1 1 Number of vCPUs 1 1 Size of Memory(GB) 4 4 Number of disks 1 and RAID1 1 Ethernet 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
    • OSIS Reference Architecture and Sizing Guide7.1.3 Tested Configuration Results7.1.3.1 Web Workload Test Maximum Re- Web/Database Virtual Server with 1 CPU Number of Con- Sce- quests Per Sec- % CPU Uti- Memory Uti- Disk Uti- Network Uti- current Users nario ond lization lization lization lization 1 34 n/a 96% 3.4 GB 18% to 34% Minimal 2 34 ~500 (15 sec aver- 96% Minimal Minimal age think time)Figure 4 - Test Configuration - Web RequestsWeb testing observations:1. Web pages referenced in the test were both static and dynamic, which re- PowerLinux Highlight: > 100k quired the Apache web server application and the Drupal server to use addi- web pages per hour returned tional CPU and disk resources. Disk utilization increased from about 3% to during testing with one physical over 30% when changing from 0% to 50% dynamic web page content. core.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 PowerLinux Highlight: 2x server increased the throughput near linearly. That is, two CPUs provided throughput seen during testing about twice the throughput of one CPU. For additional information on scal- with 2 CPUs. 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 servers vCPUs by generating activity across multiple web application threads7.1.3.2 Mail Workload Maximum Number of Con- Mail Virtual Server with 1 CPUs Test Sce- Requests current Users % CPU Uti- Memory % Disk Utiliza- Network nario per Second lization Utilization tion (Max) Utilization 1 17.3 n/a 51% 2.8 GB 85% minimal 1 (anti-spam) 0.8 50% 3% 2 16 20 (with 15 sec aver- 35% 50% 2 (anti-spam) 0.9 age think time) 99% 3%Figure 5 - Test Configuration - Mail RequestsMail 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- PowerLinux Highlight: > 3600 livery from the test scenario allowed the CPU utilization to reach near 100% and emails per hour with anti-spam Requests per Second increased by about 400%. protection using one core. 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
    • 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 disk b. 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 utilizations 2. 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 port7.2 An Example of Hardware EstimationThe following shows a simple method of estimating a system based on an client example and testing information providedin 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 seconds 2. 1000 emails per hour being handled by the mail server running anti-spamApplying these requirements to the test configuration example discussed earlier: 1. 2000 web users downloading pages every 15 seconds results in about 133 Re- PowerLinux Highlight: 2000 quests per second (2000/15). If we consider a target CPU of no more than web users and 1000 emails per 80%, we can recalculate the example testing shown earlier of 34 Requests per hour estimated for 5 cores. 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% CPU Workload Requests Requests CPU Estimated Estimated per Second per Second Utilization Requests per Second Physical 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 / vCPUsTable 5 - Hardware Estimation ExampleOSIS Reference Architecture and Sizing Guide.odt IBM Confidential Page 22
    • OSIS Reference Architecture and Sizing Guide8 ScalabilitySince IBM PowerLinux utilizes IBM PowerVM for virtualizationof 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 occurfor 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. 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.8.1 Scalability Testing on IBM PowerLinuxIn scalability testing, one of the most important aspects of determining the num- PowerLinux Highlight: 4 threads ofber of physical CPUs for a virtual server is to insure that an appropriate workload parallel execution with IBMis being applied against the application servers. Since each IBM PowerLinux vir- POWER7 Architecture, twice thattual CPU can provide Linux with 1, 2 or 4 threads of execution, the workload of other architectures. Linuxneeds to exercise all available threads. For example, when benchmarking a mail leverages 4 logical CPUs for everyworkload with 4 virtual CPUs, 16 virtual mail clients and corresponding mail virtual CPU.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) islimited to only 2 threads of execution, not 4. Due to misunderstandings of threading impacts on performance when usinginappropriate benchmarks, performance measurements are often performed incorrectly and thus do not reflect the truescaling 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 onlyhalf as utilized compared to the x86 system (12.5% of capacity vs. x86 system at 25%), even though both systems weretested 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/orthreads 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 numberof virtual CPUs and/or the workload configuration accordingly.OSIS Reference Architecture and Sizing Guide.odt IBM Confidential Page 23
    • OSIS Reference Architecture and Sizing Guide8.2 Web WorkloadThe following chart shows performance scaling of the tested web server con- PowerLinux Highlight: >7200 figu-ration using additional physical CPUs (pCPUs). web page returned per hour when tested with 1/10 core.Testing observations related to scaling: 1. CPU utilization was near linear throughout the test- Web Requests (estimated for 80% CPU utilization) ing as expected when using IBM PowerVM. Testing 150 shows about 28 Requests per Second per physical Requests per Second processor (pCPU). 100 2. Disk utilization remained low as it ranged from 8% 50 for 0.1 pCPU to 60% for 4 pCPUs. 0 3. Network utilization levels were minimal during the 0.1 pCPU 1 pCPU 2 pCPU 4 pCPU testing since web requests per second reached only Web Requests 2 28 57 109 per Second about 109 per second and the data amounts were about 8 Kbytes each. 4. Memory utilization remained under 4 GB. Figure 6 - Web Server Scaling Results 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 Workload PowerLinux Highlight: ~360The following chart shows performance scaling of the tested mail server configu- emails per hour when testedration using additional physical CPUs (pCPUs). with 1/10 core.Testing observations related to scaling: 1. Since anti-spam filtering requires significant CPU Mail Requests (estimated for 80% CPU utilization) resources as compared to processing of email with- Requests per Second out filters, adding additional pCPUs provides near 100 linear scaling as expected with IBM PowerVM. 50 2. Without anti-spam filtering configured, requests per 0 second increases significantly, but not linearly be- 0.1 1 2 4 cause of the latency associated with client requests. Mail (no 17 27 43 49 filtering) That is, the client workload utility (fetchmail) was Mail (spam 0.1 1.3 1.5 2.9 not able to retrieve requests fast enough). filtering) pCPUs NOTE: Since disk utilization was high during initial Figure 7 - Mail Server Scaling Results 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 mailvirtual server determines the throughput, with near linear scaling.OSIS Reference Architecture and Sizing Guide.odt IBM Confidential Page 24
    • OSIS Reference Architecture and Sizing Guide9 AvailabilityWhen 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 resultingvirtual device. Improvements to network performance and redundancy occur automatically when spreading and balancingrequests across multiple Ethernet ports. In sizing a system, consider adding additional Ethernet adapters for both port andadapter redundancy.For disk and data redundancy, RAID support is available either at the software level by the Linux operating system or atthe hardware level through an appropriate IBM PowerLinux backplane. Additional disks are needed and can be installedinternally (max of 6), through external expansion drawers or network attached storage. In testing, Linux software RAID1provided 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 plannedoutages and for scaling workloads.9.2 Software Availability Considerations9.2.1 Virtualization AvailabilityIBM PowerVM provides support for dual virtual I/O servers, which increases application availability by enabling VirtualI/O Server maintenance without a downtime for the virtual application servers.NOTE: The Integrated Virtualization Manager (IVM) does notsupport a dual VIOS configuration. A Hardware ManagementConsole (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 improvedthroughput, 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/WP101752For a comparison between Integrated Virtualization Manager and other management consoles, refer to IBM IntegratedVirtualization Manager Lowering the cost of entry into PowerVM Virtualization.OSIS Reference Architecture and Sizing Guide.odt IBM Confidential Page 25
    • OSIS Reference Architecture and Sizing Guide9.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 Initiatives 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
    • OSIS Reference Architecture and Sizing Guide10 ConsolidationProposals 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 acustomer allows it, install software on these servers to monitor system resource utilization such as CPU, network, anddisk. IBM support teams can help analyze this information for sizing the appropriate IBM PowerLinux system. In manycases, 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 possiblethrough collection and reporting software, such as IBM ATS Server Con­solidation Monitor (ATS SCON Monitor). ATS SCON Monitor is a 64-bitMicrosoft Windows application that runs on Windows .NET Frameworkversion 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) withVISIAN. 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 inputinto in performing a cost analysis, discussed in the next section.x86 System Workload Type Average CPU Memory Uti- Network Utiliza- Disk I/O Utiliza-Name (Java, C, etc) Utilization (%) lization (GB) tion (MB/s) 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 Example10.2 Sizing a PowerLinux System for ConsolidationWith workload utilization information from existing x86 system, either estimated or measured (see previous section), youmay 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 CompetitiveProfiles. 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
    • OSIS Reference Architecture and Sizing GuidePerform 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 templateas shown below with data from the example above. Consolidation Rate SPECin- Utilization Total (# cores IBM PowerLinux System # of t2006rate Cores (estimated SPECint2006rate 7R2 needed = Type Systems (100% or target) (Rate * Utilization) Total per old system / Total utilization) per POWER7 core) IBM Power- 1 16 578 80% 462 (per system) Linux 7R2 28.9 (per core) HP ProLiant 1 12 426 15% 63.9 (per system) 2.2 DL380 G7 5.325 (per core) (63.9 / 28.9) <additional x86 systems> Total <n> POWER7 cores per old systemFigure 9 - Sizing x86 Consolidation to IBM PowerLinux 7R2 Example10.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. Consolidationcan provide significant savings for software costs based on the number of systems or processing cores. When softwarecosts 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 PowerLinuxsystem to either an existing or a proposed replacement x86-based Linux system. Costs One Year Costs (TCO/TCA) IBM PowerLinux 7R2 X86 CompetitiveHardware $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/aOSIS Reference Architecture and Sizing Guide.odt IBM Confidential Page 28
    • OSIS Reference Architecture and Sizing GuideTotalFigure 10 –TCA Template Example for One SystemTable 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 Profiles ii. 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 SUSE NOTE: 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 support NOTE: 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/42OSIS Reference Architecture and Sizing Guide.odt IBM Confidential Page 29
    • OSIS Reference Architecture and Sizing Guide11 Migration11.1 Migrating Web (LAMP) WorkloadsWhen consolidating from x86-based web workloads to PowerLinux systems, the IBM Installation Toolkit provides theIBM Server Consolidation Tool (SCT) that helps the administrator get through the most time-consuming aspect of serverconsolidation - 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 theIBM 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 providesSoftware 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 thefollowing 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 assistanceNOTE: 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 withIBM PowerLinux.11.4 Integration with Existing LandscapesThe OSIS reference architecture can integrate into a landscape containing other systems, based on either x86 or IBMPower 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 withIBM 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 PowerLinuxservers.OSIS Reference Architecture and Sizing Guide.odt IBM Confidential Page 30
    • OSIS Reference Architecture and Sizing Guide12 Appendix12.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?Open 2. IBM Integrated Virtualization Manager Lowering the cost of entry into PowerVM Virtualization, ftp://public.dhe.ibm.com/common/ssi/ecm/en/pow03073usen/POW03073USEN.PDFOSIS Reference Architecture and Sizing Guide.odt IBM Confidential Page 31
    • OSIS Reference Architecture and Sizing GuideOSIS Reference Architecture and Sizing Guide.odt IBM Confidential Page 32
    • OSIS Reference Architecture and Sizing Guide12.2 Reference ConfigurationBest Practice: When configuring IBM PowerLinux systems with virtualization using PowerVM, request pre-install ofthe 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 isnot 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 POWER7 2. 64 GB memory 3. 2 300GB 10K RPM SAS disks 4. PCIe2 low profile 4-port 1Gb Ethernet adapter 5. Linux operating system 6. IBM PowerVM for IBM PowerLinuxIBM.com “Browse & buy”: $20,960OSIS Reference Architecture and Sizing Guide.odt IBM Confidential Page 33
    • OSIS Reference Architecture and Sizing Guide12.4 Software Configuration ExampleThe following configuration includes all of the software for the OSIS reference architecture. Software not listed is eitherincluded 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 support NOTE: 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 maintenanceOSIS Reference Architecture and Sizing Guide.odt IBM Confidential Page 34
    • OSIS Reference Architecture and Sizing Guide12.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 systems 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 systems 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
    • OSIS Reference Architecture and Sizing Guide13 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=POW03041USE N.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:eSizings@us.ibm.com 9. IBM SCON support team, mailto:support@ibmsconbpsupport.com 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_reseller 5. 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.htmlOSIS Reference Architecture and Sizing Guide.odt IBM Confidential Page 36
    • 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
    • OSIS Reference Architecture and Sizing GuideDisclaimer and Trademarks13.1 The information in this Guide is intended to provide Linux is a trademark of Linus Torvalds in the United guidance for those implementing IBM PowerLinux States, other countries or both. Open Source Infrastructure Services (OSIS). It dis­ cusses findings based on a solution that was created The registered trademark Linux® is used pursuant to a and tested under laboratory conditions. These findings sublicense from LMI, the exclusive licensee of Linus © IBM Corporation 2010 may not be realized in all customer environments, and Torvalds, owner of the mark on a world­wide basis. IBM Corporation implementation in such environments may require ad­ Systems and Technology Group Intel, Itanium and Xeon are registered trademarks and ditional steps, configurations, and performance analy­ Route 100 MMX and Pentium are trademarks of Intel Corporation sis. Somers, New York 10589 in the United States and/or other countries The following paragraph does not apply to the United Produced in the United States of America AMD Opteron is a trademark of Advanced Micro De­ Kingdom or any other country where such provisions November 2011 vices, Inc. are inconsistent with local law: INTERNATIONAL All Rights Reserved BUSINESS MACHINES CORPORATION Java and all Java­based trademarks and logos are trademarks of Sun Microsystems, Inc. In the United This document was developed for products and/or ser­ PROVIDES THIS PUBLICATION "AS IS" WITHOUT vices offered in the United States. IBM may not offer States and/or other countries. WARRANTY OF ANY KIND, EITHER EXPRESS OR the products, features, or services discussed in this IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE All performance information was determined in a con­ document in other countries. IMPLIED WARRANTIES OF NON­INFRINGEMENT, trolled environment. Actual results may vary. Perfor­ MERCHANTABILITY OR FITNESS FOR A PARTICU­ mance information is provided “AS IS” and no war­ The information may be subject to change without no­ LAR PURPOSE. Some states do not allow disclaimer ranties or guarantees are expressed or implied by tice. Consult your local IBM business contact for infor­ of express or implied warranties in certain transac­ IBM. Buyers should consult other sources of informa­ mation on the products, features and services avail­ tions, therefore, this statement may not apply to you. tion, including system benchmarks, to evaluate the able in your area. performance of a system they are considering buying. All statements regarding IBM future directions and in­ This information could include technical inaccuracies or typographical errors. Changes are periodically SPECjAppServer, SPEC OMP, SPECviewperf, tent are subject to change or withdrawal without notice made to the information herein; these changes will be SPECapc, SPEChpc, SPECjvm, SPECmail, SPEC­ and represent goals and objectives only. incorporated in new editions of the publication. imap and SPECsfs are trademarks of the Standard IBM, the IBM logo, ibm.com, IBM Systems Director Performance Evaluation Corporation (SPEC). VMControl, POWER, POWER Hypervisor, Power Sys­ IBM may make improvements and/or changes in the product(s) and/or the program(s) described in this Photographs show engineering and design models. tems, Power Architecture, PowerVM, Micro­Partition­ publication at any time without notice. Changes may be incorporated in production models. ing, are trademarks or registered trademarks of Inter­ national Business Machines Corporation in the United Implementation and certification of the solution rests Copying or downloading the images contained in this States, other countries, or both. If these and other IBM on the implementation team. The users of this guide document is expressly prohibited without the written trademarked terms are marked on their first occur­ should always check the latest release information in consent of IBM. rence in this information with a trademark symbol (® the product Readme file(s) and check the product web or ™), these symbols indicate U.S. registered or com­ pages for the latest updates and findings. mon law trademarks owned by IBM at the time this in­ formation was published. Such trademarks may also Any references in this information to non­IBM web be registered or common law trademarks in other sites are provided for convenience only and do not in countries. A current list of IBM trademarks is available any manner serve as an endorsement of those web on the web at "Copyright and trademark information" sites. The materials at those web sites are not part of at www.ibm.com/legal/copytrade.shtml the materials for this IBM product and use of those web sites is at your own risk. Linux is a trademark of Linus Torvalds in the United States, other countries or both. This information was developed for products and ser­ vices offered in the U.S.A. Intel, Itanium and Xeon are registered trademarks and MMX and Pentium are trademarks of Intel Corporation IBM may not offer the products, services, or features in the United States and/or other countries discussed in this document in other countries. AMD Opteron is a trademark of Advanced Micro De­ Consult your local IBM representative for information vices, Inc. on the products and services currently available in your area. Any reference to an IBM product, program, Java and all Java­based trademarks and logos are or service is not intended to state or imply that only trademarks of Sun Microsystems, Inc. In the United that IBM product, program, or service may be used. States and/or other countries. Any functionally equivalent product, program, or ser­ vice that does not infringe any IBM intellectual proper­ Other company, product, and service names may be ty right may be used instead. However, it is the users trademarks or service marks of others. responsibility to evaluate and verify the operation of any non­IBM product, program, or service. 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 non­IBM products was ob­ tained from the suppliers of these products or other public sources. Questions on the capabilities of the non­IBM 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/ xxxxxxxx­USEN­00 End of DocumentOSIS Reference Architecture and Sizing Guide.odt IBM Confidential Page 38