• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
ITG whitepaper: Value Proposition for AIX on IBM Power Systems: Ownership Experiences Compared with Linux on Commodity x86-based Servers
 

ITG whitepaper: Value Proposition for AIX on IBM Power Systems: Ownership Experiences Compared with Linux on Commodity x86-based Servers

on

  • 738 views

 

Statistics

Views

Total Views
738
Views on SlideShare
738
Embed Views
0

Actions

Likes
0
Downloads
19
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

    ITG whitepaper: Value Proposition for AIX on IBM Power Systems: Ownership Experiences Compared with Linux on Commodity x86-based Servers ITG whitepaper: Value Proposition for AIX on IBM Power Systems: Ownership Experiences Compared with Linux on Commodity x86-based Servers Document Transcript

    • February 2011MANAGEMENT BRIEF Value Proposition for IBM POWER7 Based Systems x86 Server Consolidation in SAP Enterprise Environments International Technology Group 4546 El Camino Real, Suite 230 Los Altos, California 94022-1069 ITG Telephone: (650) 949-8410 Facsimile: (650) 949-8415 Email: info-itg@pacbell.net
    • Copyright © 2011 by the International Technology Group. All rights reserved. Material, in whole or part, contained in thisdocument may not be reproduced or distributed by any means or in any form, including original, without the prior writtenpermission of the International Technology Group (ITG). Information has been obtained from sources assumed to be reliable andreflects conclusions at the time. This document was developed with International Business Machines Corporation (IBM) funding.Although the document may utilize publicly available material from various sources, including IBM, it does not necessarilyreflect the positions of such sources on the issues addressed in this document. Material contained and conclusions presented inthis document are subject to change without notice. All warranties as to the accuracy, completeness or adequacy of such materialare disclaimed. There shall be no liability for errors, omissions or inadequacies in the material contained in this document or forinterpretations thereof. Trademarks included in this document are the property of their respective owners.
    • TABLE OF CONTENTS EXECUTIVE SUMMARY 1 Consolidation Drivers 1 Consolidation Economics 1 Infrastructure Value 3 Conclusions 4 CHALLENGES AND SOLUTIONS 6 Consolidation Challenges 6 General Picture 6 Size and Complexity 6 Growth 7 Evaluating Platforms 8 Power Systems 8 General Picture 8 Virtualization and Workload Management 9 New Capabilities 10 x86 and VMware 11 Deployment Patterns 11 Scalability Issues 12 Other Limitations 13 Availability Optimization 13 Power Systems 13 AIX Software 15 x86 Environments 16 DETAILED DATA 17 Installations 17 IT Costs 18 Basis of Calculations 18 Cost Breakdowns 19 Costs of Downtime 20List of Figures 1. Three-year x86 and Power Server Costs for Consolidated SAP Deployments 2 2. Three-year Costs of Downtime for Consolidated SAP Deployments 4 3. Approaches to Supporting Large Complex SAP Workloads 5 4. SAP Instances: Midsize User Example 7 5. Comparative SAP SD 2-tier Performance per Core: POWER7 Based and Intel X7560-based Servers (SAPS) 9 6. Recent SAP SD Benchmark Results With and Without VMware 13 7. Key POWER7 Availability Optimization Technologies 14 8. Key AIX 7.1 Availability Optimization Features 15 9. Installations Summary 17 10. Three-year IT Cost Breakdowns 19International Technology Group 1
    • EXECUTIVE SUMMARYConsolidation DriversWhen it was introduced in 2001, SAP R/3 4.6 contained around 80 million lines of code. By 2006, SAPwas quoting 270 million lines of code, and with the introduction of Business Suite 7 in 2009, the totalreached 392 million. Lines of code continue to grow. With add-ons, complementary applications andcustomization, even midsize SAP installations may run from 500 million to a billion lines of code.Complex middleware, double-digit growth in databases and workloads, and increasingly diverse softwaretechnologies and system processes magnify the challenges of supporting such environments. Higherlevels of integration, acceleration of business processes and moves toward “real-time” practices magnifythem further.SAP versions, application portfolios and process structures vary widely between organizations. However,for most if not all SAP users, it is clear that the demands placed on underlying server, storage andnetwork infrastructures will continue to expand for the foreseeable future.How will these challenges be met? For a growing number of SAP users, part of the answer – in manycases, a large part of the answer – is to consolidate servers. The cost savings, gains in infrastructurescalability and flexibility, and improvements in quality of service that may be realized throughconsolidation have appealed to SAP users of all sizes, in all industries.Consolidation of UNIX platforms has been under way for more than a decade, and there has beengrowing interest in x86 server initiatives. The latest generation of Intel Nehalem EX Xeon 7500 and 5600processors series and Advanced Micro Devices (AMD) equivalents has significantly increased x86 serverperformance, and VMware and other x86 virtualization tools have also grown more sophisticated.The combination of powerful, inexpensive x86 hardware and virtualization appears to offer a compellingvalue proposition. Use of these, it is argued, represents the most cost-effective means of realizing x86server consolidation.But appearances can be deceptive.SAP systems are among the most demanding environments that may be deployed on any server platform.However, consolidation challenges are greater, and cost structures more complex than for most otherapplications. UNIX system capabilities may realize economies that exceed – often by wide margins –those that are possible with even the most advanced x86 servers and virtualization tools.This is particularly the case for the latest generation of IBM POWER7 based systems. In comparisonspresented in this report, three-year IT costs in organizations consolidating x86 Windows and Linuxservers to POWER7 based systems range from 14 percent to 46 percent less, and average 39 percent lessthan for use of Intel Xeon 7500-based servers and VMware vSphere 4.Consolidation EconomicsWhere can hard data on SAP server consolidation be obtained? A great deal of information is available onthe subject, but its usefulness varies widely.For example, SAP SD two-tier benchmarks may be employed to measure the performance of serversexecuting standardized workloads, but provide less insight into how well platforms will perform withconcurrent mixed workloads, particularly when these are virtualized. Moreover, real productionenvironments tend to be a great deal more complex and less predictable.International Technology Group 1
    • Equally, vendor collateral such as case studies, surveys and internal test results are often selective, andtotal cost of ownership (TCO) and return on investment (ROI) tools are heavily dependent on theassumptions around which they are built.This report is based on input from 46 organizations that have consolidated x86 or IBM Power platformssupporting SAP systems since 2007. Input from both groups helped to clarify consolidation patterns.Among the 27 organizations that had conducted x86-to-x86 consolidation initiatives, for example, majorSAP production systems were typically deployed on non-virtualized servers configured in three-tierhierarchies. VMware and equivalent hosts were in most cases employed for test, development and othernon-production instances; comparatively light-duty production instances; or combinations of these.In contrast, IBM Power server users routinely employed logical partitions (LPARs) and other PowerVMvirtualization technologies for production as well as non-production applications.Users of both platforms tended to employ rack-mounted hardware and virtualization for database andCentral Instance (CI) serving, and blades for application and Web serving.Three organizations were selected for more detailed configuration and cost comparisons. In each case,numbers and sizes of instances were translated to latest-generation Intel Nehalem EX- and POWER7based server configurations, and three-year costs were calculated for these. Results are summarized infigure 1. Figure 1 Three-year x86 and Power Server Costs for Consolidated SAP Deployments MILL PRODUCTS COMPANY ($ Thousands) x86 Servers 316.1 Power Systems 270.8 INDUSTRIAL MACHINERY COMPANY ($ Thousands) x86 Servers 829.7 Power Systems 566.7 LOGISTICS SERVICES COMPANY ($ Thousands) x86 Servers 2,068.0 Power Systems 1,109.0 Hardware Maintenance Software licenses & support Personnel FacilitiesComparisons are of SAP installations in two manufacturing and one logistics services companies withbetween 800 and 15,000+ employees, and 350 to 2,000+ named users.The more than 2,000 SAP users in the largest installation – the logistics services company – would notnormally be supported by x86 servers. However, the company employs multiple enterprise resourceplanning (ERP), customer relationship management (CRM) and other systems to support the operationsof different business units. These systems, individually, are within the size range that may be supportedon x86 servers.International Technology Group 2
    • For mill products company comparisons, configurations are based on use of x86 and Power versions of amajor Linux distribution, and with MaxDB databases. For the industrial machinery and logistics servicescompanies, x86 server costs are based on use of Windows Server 2008, SQL Server 2008 and vSphere 4.Power Systems costs are based on use of IBM AIX 7.1, DB2 9.7 and PowerVM virtualization.Costs include acquisition of server hardware and licenses for operating systems and virtualization tools;hardware maintenance and software support; server administration personnel; and facilities (primarilyenergy costs). Hardware, software, maintenance and support costs were calculated based on street prices;i.e., discounted prices actually paid by users.Calculations do not include costs for MaxDB, DB2 and SQL Server databases. In practice, these would becalculated as percentages of SAP Application Value (SAV) plus support, and would be the same for x86servers and Power Systems.Lower costs for Power Systems are due to multiple factors, including higher system-level performanceand greater density of virtualized environments compared to x86 servers. Personnel costs are reduced byhigher integration and more advanced automation (these capabilities are discussed in the followingsection). Facilities and energy costs are reduced by use of fewer platforms and smaller configurations.Details of companies, SAP installations, server configurations and software stacks, and serveradministration staffing levels, and of the methodology and assumptions employed may be found in theDetailed Data section of this report.Infrastructure ValueAt a time of weak demand and budgetary pressures, the ability to reduce or at least contain growth in ITexpenditure is a priority for most organizations. But it is rarely the only priority.SAP systems literally “run the business.” Underlying system infrastructures must meet other demands.The ability to provide required levels of performance and scalability, and to meet exacting demands forquality of service – including such variables as availability, recoverability and security – also materiallyaffect value propositions for server platforms.In these areas, there are also strong cases for POWER7 based systems, which are recognized industryperformance leaders. Scalability extends from four-core 3.0 GHz blades to Power 795 systems that maybe configured with up to 256 4.0 GHz cores, eight terabytes (TB) of main memory and 1,000 LPARs.User surveys have also consistently rated Power Systems as delivering significantly higher levels ofavailability than competitive UNIX and x86 platforms. In POWER7 based systems, reliability,availability and security (RAS) capabilities in hardware, microcode and AIX software have been furtherstrengthened.Experience has shown that major system outages can translate into lost sales, impaired productivity,operational disruption, delayed orders and deliveries, dissatisfied customers and other negative effects.Although unplanned (i.e., accidental) outages may be more visible, the cumulative impact of plannedoutages for such tasks as scheduled maintenance, hardware and software upgrades and security patchingmay be equally if not more damaging.Higher levels of availability for POWER7 based systems have significant bottom-line implications. Forexample, in the three installations upon which cost comparisons are based, “costs of downtime” rangefrom 58 percent to 77 percent less, and average 74 percent less than for Windows and x86 Linux servers.Figure 2 illustrates these disparities.International Technology Group 3
    • Figure 2 Three-year Costs of Downtime for Consolidated SAP Deployments MILL PRODUCTS COMPANY ($ Thousands) x86 Servers 470.7 Power Systems 199.2 INDUSTRIAL MACHINERY COMPANY ($ Thousands) x86 Servers 1,168.1 Power Systems 337.9 LOGISTICS SERVICES COMPANY ($ Thousands) x86 Servers 4,101.0 Power Systems 934.1Costs include idle and underutilized capacity for production and/or logistics operations; schedulingchanges; order, shipment and payment delays; inventory carrying; customer-related costs such as latedelivery and imperfect order fees; and other items. The basis of these calculations is again described inthe Detailed Data section of this report.Lower costs of downtime for Power Systems are again due to a combination of factors. RAS featuresbuilt into Power Systems and AIX are more sophisticated than x86 Windows and Linux equivalents.More effective workload management mechanisms reduce risks that system overloads will cause outages.These capabilities are discussed in the following section.ConclusionsThe ability of POWER7 based systems to deliver lower IT costs reflects multiple factors. One is higher“raw” performance – in terms of SD two-tier benchmark results, for example, performance per core forPOWER7 based systems is 1.5 to 2.0 times greater than for Intel 7500 series-based equivalents.Other capabilities are also significant. Processor-based accelerators, memory expansion (POWER7 is thefirst major commercial processor to offer this capability), as well as highly granular microcode-basedpartitioning, industry-leading mixed workload management and other features materially increase theamount of work that can be performed by POWER7 based systems.POWER7 based systems can manipulate a wider range of variables than x86 platforms – includingthreads, processors, cache, main memory and I/O, multiple types of partition, multiple threads anddedicated or pooled processors – to optimize performance for heterogeneous workloads. Resources maybe re-allocated in a matter of milliseconds as needs change.Such capabilities may provide a great deal of value in executing any complex mixed workload set. Butthey are particularly relevant to virtualized environments where it is necessary to support heterogeneousworkloads running in multiple partitions on the same physical platform.International Technology Group 4
    • Users of earlier POWER6 based systems have found that that the actual amount of work performed bythese is routinely from two to four times greater than raw performance measurements would indicate.New POWER7 based capabilities indicate that disparities between formal and real performance will besignificantly larger for this generation of architecture.The capabilities of Windows and x86 Linux servers with VMware, Microsoft Hyper-V, Xen and otherx86 virtualization enablers are weaker. The microcode-based partitioning technology employed byPOWER7 based systems is more efficient and secure than software-based techniques such as VMware.POWER7 based workload management is – by a wide margin – superior to x86 server equivalents.The Virtual I/O Server (VIOS) feature of Power Systems also enables these to support significantly largernumbers of virtual I/O adapters than Windows and x86 Linux equivalents. Organizations may also createredundant VIOS configurations that reduce risks of downtime due to I/O subsystem failures.These differences add a new perspective to industry debates about the relative merits of “scale-up” (i.e.,use of larger systems) and “scale-out” (i.e., multiplication of small servers) approaches to handling large,growing SAP workloads. In practice, there is a third-option: to increase the density of workloads handledby platforms. This approach, illustrated in figure 3, can be referred to as “scale-in.” Figure 3 Approaches to Supporting Large Complex SAP Workloads SCALE-UP SCALE-OUT SCALE-IN Increase workload densityIn practice, these approaches are complementary. It will be a great deal more cost-effective to supportgrowth in SAP environments through scale-up or scale-out strategies if server platforms first operate withhigh levels of efficiency.This is not to say that x86 server consolidation initiatives using VMware and equivalents cannot providesignificant value to customers. Clearly, they can. But there are major differences in levels ofconcentration and quality of service that may be realized using x86 servers and Power Systems, and usersshould be aware of these.International Technology Group 5
    • CHALLENGES AND SOLUTIONSConsolidation ChallengesGeneral PictureConsolidation is a long-established trend among SAP users. After initially deploying multiple SAP ERPsystems supporting business unit and local operations, many large users have replaced these with largerglobal and regional systems over the last decade. In some cases, single global instances have even beenput in place by organizations with worldwide operations.Finance, human resources, procurement and other back-end systems have been consolidated and sharedservices structures put in place. Even when other finance systems have remained decentralized, singlegeneral ledgers (GLs) have often been implemented. Consolidation has also extended to CRM, supplychain and other SAP systems, and to data centers, storage, networks and other IT resources.Cost reduction has been a major driver of these trends, although a variety of other benefits have typicallybeen targeted. These have typically included better concentration of data for analytical as well asoperational applications; greater consistency of systems and processes; improved availability, recoveryand security; and increased staff productivity.The same logic has applied to server consolidation. Experience has shown that, in distributed serverinstallations, proliferation inflates costs, generates inefficiencies and impairs quality of service. Whereservers have been installed over multi-year periods, inefficiencies are often magnified by use of multiplegenerations of hardware, and by different versions of operating systems, tools and driver software.Consolidation initiatives have typically sought to reduce costs for hardware and software maintenance,energy, space and server administration. Economies are also typically realized in ongoing hardware costs– higher levels of capacity utilization mean that fewer new servers are required – and software licensecosts may be reduced if fewer instances are employed.Among SAP users, server consolidation has proved particularly attractive – the need to support largemultiple-instance landscapes has meant that high levels of server proliferation have developed in manyorganizations – and particularly difficult.Even in small installations, the size and complexity of SAP environments pose challenges that aresignificantly greater than those encountered with most other types of server consolidation.Size and ComplexityFor more than a decade, SAP environments have not only grown larger, but also more diverse. Earlydeployments focused on transactional processes. There were less than 20 major modules. Processes werehighly structured. Implementation involved three-tier client/server hierarchies supporting databases of, atmost, a few hundred gigabytes.Since that time, the SAP portfolio has evolved into a functionally broader spectrum of solutions. Industry-specific functions have become more granular, while the scope of SAP offerings now extends far beyondtransactions to include SAP and partner solutions that address processes that deal with information,communication and collaboration.A present-day SAP enterprise environment may contain solutions addressing between 300 and 500processes generating highly diverse workloads. In large installations, there may be thousands of processes.International Technology Group 6
    • These effects extend across entire SAP landscapes. Even relatively simple SAP environments normallyinclude multiple production as well as development, quality assurance, training and other non-productioninstances, and in larger installations from five to ten instances of the same system are common. Figure 4shows an example for a midsize SAP user. Figure 4 SAP Instances: Midsize User Example NON- SYSTEM PRODUCTION PRODUCTION Enterprise Resource Planning (ERP) 3 5 Business Intelligence (BI) 3 3 Customer Relationship Management (CRM) 2 3 Event Management (EM) 2 4 Global Trade Services (GTS) 1 2 Learning 1 2 Portal 1 2 Process Integration (PI) 4 3 Product Lifecycle Management (PLM) 1 3 Solution Manager 1 1 Supply Chain Management (SCM) 2 3 Sandboxes – 4 Tools & utilities 5 7 TOTAL 26 42Large installations routinely contain hundreds of instances.GrowthEven in a harsh economic climate, SAP environments continue to expand. Workloads tend to expandeven in stable organizations. If the business is itself growing, the effect is multiplied.Data growth is particularly rapid. Users routinely experience annual growth rates of 30 to 50 percent overlong periods. Terabyte-sized databases have become common even in midsize installations. Growth ratesare significantly higher in some industries, and for certain applications such as business intelligence,compliance and e-commerce systems.Although data growth is often seen as an issue affecting storage and network infrastructures, it also hasmajor implications for server platforms. Processor and memory overhead are increased, and higher levelsof internal bandwidth and I/O throughput are required.With the transition to SAP Business Suite 7, these effects are magnified. Users who have implementedUnicode, for example, have typically experienced increases of over 30 percent in processor capacity, over50 percent in main memory and up to 60 percent in database size.International Technology Group 7
    • Evaluating PlatformsUnder any scenario, the stresses that SAP systems place on underlying servers are not small – and formost users, they will increase significantly in the future. It will be necessary to support increasinglycomplex end-to-end workloads with high levels of concurrency and throughput.Among organizations consolidating servers, these trends will be reflected in the workloads supported byvirtual as well as physical machines.How, then, should the ability of platforms to handle these stresses be assessed? Multiple capabilitiesshould be evaluated. A first requirement is for raw performance. Increasingly complex SAP softwarestructures require a great deal of processing power and I/O bandwidth. Challenges are compounded when– as is, for example, the case for VMware – hypervisors also generate high levels of system overhead.Measurement of application-level performance, however, is not a simple process. While metrics such asSD two-tier may be useful, results are typically generated using standardized workloads, low I/O activityand highly controlled operating conditions. Actual production environments tend to be very different,particularly when they involve large databases, virtualization and diverse, fluctuating workloads.In virtualized environments, a broader range of factors – including hypervisor and workload managementcapabilities – must be taken into account.Even small SAP instances normally experience spikes in activity, and may be idle for long periods. Ifinsufficient allowance is made for peak utilization, there is risk that workloads will interfere with eachother, causing overall server performance to degrade or triggering outages. If insufficient allowance ismade for periods of low utilization, a high percentage of server capacity may be idle at any time.Efficient virtualization means optimizing capacity use over time. If a system delivering, say, 10,000SAPS of SD-rated benchmark performance can execute workloads three times larger than anotherplatform with the same rating over a given period, this will significantly affect cost-effectiveness.One implication is that, in planning for server consolidation, average capacity utilization may not be ameaningful value. A server may operate at an average of 10 to 15 percent utilization, but may spike at 40to 60 percent. Peak utilization must be known, or at least estimated with a reasonable degree of accuracy.In comparing server platforms, further caveats should also be applied to capacity utilization statistics.Knowing that a server is operating at, say, 65 or 85 percent of capacity does not provide insight into howefficiently that capacity is used. In practice, a great deal more work may be performed by a POWER7based system even if utilization is the same as for another platform.Power SystemsGeneral PicturePOWER7 based systems are built around the seventh generation of the POWER Reduced Instruction SetComputing (RISC) architecture that was first introduced in 1990. During the 2000s, this platform hasundergone a steady series of enhancements that have made it the market share leader in the overall UNIXserver market, and the most common system for new SAP UNIX deployments.Worldwide, more than 18,000 Power installations support SAP systems for more than 6,000 customers.International Technology Group 8
    • POWER7 based systems are recognized industry performance leaders among UNIX and x86 platforms.SAP SD benchmarks have, for example, shown significantly higher absolute and per core performancethan for latest-generation Intel Nehalem EX-based servers.Figure 5, for example, shows recent SD two-tier benchmark results for systems employing POWER7 andIntel Xeon 7500 series processors. Figure 5 Comparative SAP SD 2-tier Performance per Core: POWER7 Based and Intel X7560-based Servers (SAPS)In this presentation, results are for the SAP Application Performance Standard (SAPS) metric. Numbersof processors and cores are shown for each platform; e.g., Power 780 – 8/64 x 3.8 GHz refers to a Power780 configured with eight POWER7 processors, each with eight 3.8 GHz cores for a total of 64 cores.The POWER7 processor incorporates a number of innovative IBM features that deliver high levels ofperformance with a comparatively small chip size. The processor incorporates 1.2 billion transistors,compared to 2.3 billion for the eight-core Intel 7500. Lower transistor counts contribute to both fasterspeeds and reduced energy consumption.More than 80 percent of SAP Power users employ LPARs, and many employ micro-partitions, VIOS andother PowerVM capabilities. Users routinely support 50 to 100 LPARs on single Power servers, and somesupport hundreds.POWER7 based systems support use of IBM AIX and i operating systems, as well as Red Hat EnterpriseLinux (RHEL) and SuSE Linux Enterprise Server (SLES). These may run concurrently.Virtualization and Workload ManagementPOWER5 (2004), POWER6 (2007) and POWER7 (2010) generations of architecture have alsoprogressively expanded not only the performance, but also the virtualization and workload managementcapabilities of this platform.Power Systems support multiple types of partitioning. These include hypervisor-based LPARs, whichmay be initially configured in increments as small as 1/10 core, but expanded in increments as small as1/100th core; and VIOS, which allow applications running in multiple LPARs to share I/O adapters.International Technology Group 9
    • Also supported are Workload Partitions (WPARs), which allow users to create multiple application-specific partitions within single AIX instances. WPARs are typically employed for development, test andlight-duty production applications.Key workload management features in POWER7 hardware, the microcode-based PowerVM hypervisorand AIX software, are closely integrated with partitioning mechanisms. The implications are important.Partitioning creates the potential for high levels of concentration. However, the extent to which this willoccur in practice depends heavily on the mechanisms that allocate system resources, and monitor andcontrol workload execution processes across and within partitions. If these mechanisms are ineffective, anoverall system capacity may be poorly utilized.Power Systems workload management capabilities among the most sophisticated in existence. Systemresources, including processors and memory, may be dedicated to or shared by partition-based physical,logical (thread-based) and virtual processors. The system evaluates utilization of all resources every 10milliseconds, and may change allocations as rapidly.Users employing the earlier generation of IBM POWER6 based systems have found that use of PowerVMpartitioning, coupled with shared processor pools and other mechanisms can significantly improve theamount of work performed by a given configuration.New CapabilitiesIn POWER7 based systems, a number of new capabilities have been added that boost performance as wellas virtualization and workload management. These include: • Intelligent threading. Increasing the number of POWER-supported threads from two to four (POWER7 SMT4) can increase performance for certain applications. For example, IBM has reported internal test results showing that use of SMT4 can increase system throughput for ABAP software stacks by up to 66 percent and 27 percent compared to use of single or dual (SMT2) threads respectively. Not all workloads, however, benefit from this approach. For example, database transactions and high-performance analytical processing may run more efficiently using single threads that exploit the full power of processor cores. This is particularly the case for high-volume systems. With POWER7 based systems, workloads may be executed using one, two or four threads per core. The system can automatically determine which to use for optimum performance, or system administrators may select the number of threads employed. In automatic mode, continuous optimization of performance for system-wide as well as partition workloads is provided. • Intelligent cache. A similar approach has been extended to cache memory. The system may be set to automatically determine the appropriate level of cache for specific workloads. Automated mode is again supported by performance optimization functions. On Power 770, 780 and 795 systems, an additional TurboCore mode allows users to configure only half of system cores to exploit shared L3 cache and main memory. This mode is appropriate for high-volume database and transaction processing workloads where larger cache sizes and memory bandwidth can yield significant performance advantages. • Active Memory Expansion. This enables system-managed compression and decompression of data in memory. IBM tests for SAP workloads indicate that de facto memory size may be increased by 75 percent with less than one percent processor overhead, and by 111 percent with around 15 percent processor overhead. Customers have reported comparable results.International Technology Group 10
    • Active Memory Expansion may materially reduce hardware costs, particularly for memory- intensive applications. It also means that workloads representing up to twice as many users can be supported These capabilities are obviously relevant to the demands of virtualized hosts managing numerous partitions, equipped with large physical memories. Automation is again much in evidence. Systems can automatically turn Active Memory Expansion on or off to optimize performance for workloads running in individual partitions. The amount of memory made available in this manner may be subject to system-level priorities.The IBM emphasis on automation is striking. In some cases, autonomic technologies are employed.Autonomic computing, meaning the application of artificial intelligence techniques to systemadministration and optimization, has been a major IBM design focus for more than a decade. Thecompany is the recognized industry leader in this area.Automation has a number of bottom-line implications. One is that staffing and personnel costs foradministrative tasks may be reduced. Another is that the potential for performance bottlenecks andoutages due to administrator errors is reduced.Equally, if not more important, automation accelerates processes that affect capacity utilization. A systemcapable of automatically determining requirements and re-allocating resources in a matter of millisecondswill inevitably be more efficient than one that depends upon human intervention. Such differences mayhave a far from negligible impact on configuration sizes and costs.The impact of all of the capabilities described above is cumulative.A comparative evaluation of POWER7 based systems would need to start with 50 to 100 percent moreSAPS per core than Nehalem EX equivalents; allow for a minimum of two times gains due tovirtualization and workload management capabilities; and factor in real memory savings through use ofActive Memory Expansion.In terms of overall cost structure, it would be necessary to account for the smaller, denser configurationsenabled by Power Systems – which contribute to lower system administration, data center occupancy andenergy costs – as well as economies realized through levels of automation, availability and security thatare significantly higher than for any x86 server, operating system or virtualization enabler.x86 and VMwareDeployment PatternsConsolidation of x86 servers supporting SAP systems has been practiced for more than a decade. It hasaccelerated during the last few years with the appearance of more powerful Intel and AMD processor-based servers and growing use of VMware and (more rarely) other x86 virtualization enablers.Among SAP UNIX server users, server consolidation has in most cases involved extensive use ofpartitioning technologies such as IBM LPARs, and HP and Sun equivalents. x86 consolidation has been amore diverse trend. Among SAP x86 users that contributed to this report, for example, 23 of 26 employedcombinations of non-virtualized and virtualized servers.Virtualization was typically employed for test, development, training and comparatively light-dutyproduction instances – examples included SAP Content Manager, Portal, Process Integration (formerlyExchange Infrastructure), Solution Manager and e-procurement and analytics tools. x86 platformssupporting e-mail, collaboration, file and print serving, and other complementary applications were alsocommonly moved to virtualized servers.International Technology Group 11
    • Some users had also virtualized ERP, CRM, supply chain management (SCM) and other more substantialSAP applications. These tended, however, to be either relatively small or partial environments; e.g., oneorganization that reported that it had virtualized a core production ERP system had actually done so foronly a few modules.This picture appears to be consistent with overall deployment patterns. Most industry estimates are thatnon-production systems account for between 60 and 80 percent of all deployed SAP instances in virtualmachines (VMs). Virtualized production systems typically support small user organizations, lessdemanding SAP applications or both.Use of VMware by a number of SAP Web hosting organizations reflects similar dynamics. Althoughthese often employ large numbers of servers and VMs, they typically support customers who individuallyrepresent small systems and workloads.User input also indicates the growing role of blades in server consolidation initiatives. In many cases,organizations have employed rack-mounted servers to support production database servers and centralinstances; blades to support production application and Web serving; and VMware servers to supportother instances. Exact mixes, however, varied widely from organization.Scalability IssuesThe demographics of VMware use are striking in that, in principle, VMware can deliver extremely highlevels of performance and scalability.The Virtual Infrastructure 3 (VI3) product set, introduced in 2006, supports up 32 physical cores, 256gigabytes (GB) of main memory and 128 VMs per host. The latest vSphere 4 version extends support to64 physical cores, 1 terabyte (TB) of main memory and 320 VMs per host.However, only a small fraction of the architectural potential of either version has been exploited inpractice. One reason for this is that, in a SAP environment, system overhead increases rapidly asworkloads within instances grow larger.In VMware architecture, the number of physical processors that can be exploited by a VM depends uponthe number of virtual processors (vCPUs) supported. For most of its history, VMware allowed use of onlytwo vCPUs per VM. Virtual Infrastructure 3 extended support to four, and vSphere 4 to eight vCPUs.These transitions, however, have been accompanied by performance degradation. This is reflected even inSAP SD benchmark results. During 2009, for example, several SD two-tier benchmarks run on the sameNehalem EX-based physical machine using VMware ESX Server 4.0 – the core component of thevSphere 4 environment – showed striking variations.As figure 6 illustrates, use of ESX 4.0 with eight virtual CPUs reduced performance by more than 38percent compared to the same test run without VMware – from 18,170 to 11,230 SAPS.This was the case despite use of larger main memory – 96GB compared to 48GB. Moreover, the VMwareresult was arrived at using Linux and SAP MaxDB, which generate lower system overhead than WindowsServer 2008 and SQL Server 2008 employed for the test without VMware.VMware performance degradation if these were employed would probably be in the 40 to 50 percentrange for benchmark results, and significantly higher in real production conditions.The same physical machine configured with four vCPUs delivered only 6,250 SAPS, around a third of theperformance realized without VMware.International Technology Group 12
    • Figure 6 Recent SAP SD Benchmark Results With and Without VMware PLATFORM Fujitsu PRIMERGY TX300 S5 / RX300 S5 2 processors / 8 cores / 16 threads Xeon X5570, 2.93 GHz, 64 KB L1 cache & 256 KB L2 cache per core 8 MB L3 cache per processor DATE CERTIFIED CONFIGURATION MAIN MEMORY SAPS Windows Server 2008 Enterprise May 13, 2009 48 GB 18,170 Edition + SQL Server 2008 SLES 10 + MaxDB 7.8 August 4, 2009 VMware ESX Server 4.0 96 GB 11,230 1 VM using 8 vCPUs SLES 10 + MaxDB 7.8 August 4, 2009 VMware ESX Server 4.0 96 GB 6,250 1 VM using 4 vCPUsNo comparable SD results are available for Power Systems. However, industry experience has been thatsystem overhead is low even for very large partitioned configurations. IBM has also published internaltest results showing near-linear scaling as partitions expand from 8 to 32 vCPUs, the PowerVMarchitectural limit.Other LimitationsVMware suffers from other limitations compared to Power Systems. The software-based partitioningmethod it employs is less well suited to dense database and transactional workloads than IBM LPARs,and workload management capabilities are significantly weaker and less well integrated.Although VMware (the company) has invested heavily in management solutions, these are primarilydesigned to manage resources across server farms, and storage and networks supporting these, rather thanwithin individual servers.As a result, users are often reluctant to “push the envelope” in configuring numbers of VMs on individualservers. Unless instances generate very small, homogeneous and/or stable workloads, there are significantrisks that workloads will interfere with each other. If this occurs, overall system performance may bedegraded, and outages may occur.In addition to scalability limitations, this caution contributes to the fact that most VMware users havecreated significantly fewer VMs on single hosts than vSphere architecture allows.Availability OptimizationPower SystemsMaintenance of high availability is not a simple process. Organizations running business-critical SAPsystems typically need to employ specialized practices, and duplexed data centers and clustered failovertools may also be put in place to guard against the effects of disastrous system and site outages.Downtime levels, however, are also materially affected by platform capabilities. These must not onlyprevent unplanned (i.e. accidental) downtime, but also minimize the frequency and duration of plannedoutages for scheduled maintenance, hardware and software upgrades, and other recurring tasks. Theavailability optimization capabilities of POWER7 based systems address both sets of requirements.International Technology Group 13
    • A key characteristic is that availability optimization is designed and implemented across all major systemcomponents, including hardware, PowerVM virtualization and AIX software.At the hardware level, POWER7 based systems incorporate multiple levels of redundancy andconcurrency, as well as mechanisms for monitoring, diagnostics, fault isolation and resolution, and faultmasking (enabling systems to continue functioning even if a fault occurs) that are more sophisticated thanthose of most x86 platforms. Figure 7 shows examples. Figure 7 Key POWER7 Availability Optimization Technologies BASIC CAPABILITIES Redundancy, hot-swap & failover Redundant/hot-swap disks, PCI adapters, GX buses, fans & blowers, power supplies, power regulators & other components. Redundant disk controllers & I/O paths. Concurrent system clock repair. Redundant oscillators/dynamic oscillator failover. Concurrent firmware update Server firmware may be updated without taking systems offline. Concurrent maintenance Allows processors, memory cards & adapters to be replaced, upgraded or serviced without taking systems offline. MONITORING, DIAGNOSTICS & FAULT ISOLATION/RESOLUTION Hardware-assisted memory scrubbing Automatic daily test of all system memory. Detects & reports developing memory errors before they cause problems. Chipkill error checking Technology capable of detecting & correcting single-bit as well as 2-, 3- & 4-bit errors in memory devices, including cache & memory interfaces. Employs RAID-like striping of data across memory devices to provide redundancy & enable reinstatement of original data. Significantly more reliable than conventional error correction code (ECC) technology. First Failure Data Capture (FFDC) Employs 1,000+ embedded sensors that identify errors in any system component. Root causes of errors are determined without the need to recreate problems or run tracing or diagnostics programs. FAULT MASKING Processor instruction retry If an instruction fails to execute due to a hardware or software fault, Alternate processor recovery the system automatically retries the operation. If the failure persists, the operation is repeated on a different processor &, if this does not Processor-contained checkstop succeed, the failed processor is taken out of service (checkstopped). Only LPARs supported by the failed processor are affected. Dynamic processor sparing Allows idle Capacity Upgrade on Demand (CUoD) processors to be automatically activated as replacements for failed processors. Partition availability priority In the event of a processor failure, maintains LPAR-based workloads based on assigned priorities; i.e., remaining processor capacity is assigned to the highest-priority workloads. Memory sparing Enables redundant memory modules to be activated in the event of memory failures. Enhanced memory subsystem Enables memory controller & cache sparing. Enhanced cache recovery Detects & purges processor, L2 & L3 cache errors. Recovers & reinstates original data. Dynamic I/O line bit repair (eRepair) Detects & bypasses failed memory pins. PCI bus parity error retry Retries an I/O operation if an error occurs.POWER7 based systems benefit from a number of technology transfers from IBM mainframe systems,which enjoy the highest levels of availability of any major platform. Key mainframe-derived featuresinclude First Failure Data Capture (FFDC) and Alternate Processor Retry.According to IBM, the availability optimization features of POWER7 based systems were developedjointly by the company’s Power and System z (mainframe) design teams.International Technology Group 14
    • AIX SoftwareA further, closely integrated level of availability optimization is provided by the AIX operating system.The latest version 7.1 includes the features shown in figure 8. Figure 8 Key AIX 7.1 Availability Optimization Features Second Failure Data Capture Supports First Failure Data Capture technology with additional diagnostic & data (SFDC)* capture features built into the operating system. Multisystem First Failure Data Consolidates FFDC information, & provides single point to launch data collection, Capture* debug & monitoring actions across multiple systems. Run-time error checking System-wide framework for FFDC & SFDC capabilities. Concurrent Kernel Updates Enables some kernel fixes to be installed without rebooting. Allows patches to be applied without interruption of service. Can be employed for approximately 80 percent of required single module kernel updates. Kernel exploitation of POWER Exploits a POWER7 hardware feature that separates memory spaces for the Storage Keys* kernel, file system & drivers to prevent software errors affecting one of these from spreading to the others. Functional Recovery Routines* Suite of diagnostic & recovery routines that can enable recovery from errors that would otherwise cause the operating system to crash. Kernel no-execute protection Establishes kernel data areas that should not be treated as executable code. Enables immediate detection if erroneous device driver or kernel code strays into these areas. Avoids potential system crashes. Kernel stack overflow detection Detects stacks overflows & enables recovery of some of these. Tracing facilities System trace – main AIX trace facility. Lightweight memory trace – allows tracing of key kernel events only. Lightweight structure results in minimal performance impact. Component trace – enables tracing with per-component granularity. Dynamic Tracing with probevue Allows developers or system administrators to dynamically place probes in existing application or kernel code, without requiring special source code or even recompilation. Simplifies debugging of complex system or application code. POSIX trace Implements POSIX Trace Standard for application tracing. Live Dump* Allows key subsystems to dump diagnostic information for service analysis, without requiring a full system dump. Firmware-assisted dump* Allows firmware to incorporate FFDC information in system dumps. MiniDump Small compressed dump of system data for diagnostic analysis. Enables quick snapshot of crash without full system dump. Parallel Dump Compressed format enabling multiple processors to dump in parallel sub-areas. Greatly reduces time to produce dump. Netmalloc debug Memory subsystem monitoring tool that enables isolation of memory leaks. Live Partition Mobility Allows movement of active LPARs between Power Systems. Brief interruptions – no more than one or two seconds – may occur due to network latency. Live Application Mobility Allows movement of WPARs between systems. Service interruptions are longer than for Live Partition Mobility – typically around 20 seconds. Cluster Aware AIX Provides kernel-based heartbeat, messaging, file sharing, commands & APIs, data collection & event management services supporting clustered HA solutions. *Mainframe-derived featureKey AIX mainframe-derived features include Second Failure Data Capture (SFDC), Kernel Exploitationof Storage Keys and Functional Recovery Routines, which are drawn from z/OS operating system.Other Power and AIX capabilities include Live Partition Mobility, which allows movement of activeLPARs between Power Systems, and Live Application Mobility, which allows WPARs to be moved in thesame manner. Live Partition Mobility users may experience service interruptions of one or two secondsdue to network latency. For Live Application Mobility, interruptions are typically around 20 seconds.International Technology Group 15
    • In addition, high availability clustering solutions are offered by IBM and third parties for POWER7 basedsystems. PowerHA SystemMirror for AIX, for example, is one of the most widely used and matureclustered failover and recovery solutions for UNIX-based servers. It has been deployed by thousands ofusers over more than a decade.Although the amount of time required to failover and restart systems and reinstate data may vary, the“best practice” norm for PowerHA SystemMirror is that operations may be fully restored within twohours with little or no data loss. Users have achieved mainframe-class failover and recovery even forcomplex large-scale transactional workloads.x86 EnvironmentsSince the mid-2000s, Power Systems and AIX have consistently shown higher levels of availability thancompetitive UNIX and x86 servers in user surveys.Although x86 hardware platforms share some of the same RAS features, the capabilities of PowerSystems, are broader in design and technologically more sophisticated. The AIX operating system is also– by wide margins – better optimized to deliver high availability than Windows or x86 Linux variants.In x86 environments, moreover, availability must be maintained not only across processors and serverplatforms, but also across Windows or Linux, and virtualization tools such as VMware and Xen.Typically, this means dealing with the offerings of at least four vendors. Optimization of availabilityfeatures is inevitably more problematic than is the case for Power Systems.Use of high availability clusters does not necessarily change this picture. Windows and Linux clusterstypically experience more downtime than UNIX equivalents, and failover and recovery processes tend tobe both slower and less reliable. Clusters also tend to generate complexity, and the effects are magnifiedif they are multiplied across farms of small servers.Experience has shown that x86 clusters are often necessary to achieve availability levels that may berealized by standalone Power Systems.International Technology Group 16
    • DETAILED DATAInstallationsThe cost comparisons presented in this report based on the three installations summarized in figure 9. Figure 9 Installations Summary COMPANY MILL PRODUCTS INDUSTRIAL MACHINERY LOGISTICS SERVICES Business Profile Plastic products manufacturer Industrial equipment manufacturer Logistics services $180 million sales $400 million $1.5+ billion sales 800 employees 2,000 employees 15,000+ employees 6 plants & distribution centers 10 manufacturing facilities Applications & SAP for Mill Products – BI, SAP for Industrial Machinery & SAP for Transportation & Logistics Instances CRM, ERP, SM: Components – BI, CRM, ERP, – BI, BO, CRM, ERP, GRC, PI, GTS, PI, PLM, Portal, SCM, SM: Portal, SCM, SM, SRM: 31 instances 49 instances 95 instances Users 350 750 2,000+ x86 SERVERS Servers Rack Servers Rack Servers Rack Servers 3 x 2/12 x 2.93 GHz* 2 x 4/32 x 2.26 GHz* 1 x 8/64 x 2.26 GHz 2 x 2/12 x 3.33 GHz* Windows Server, Cluster 2 x 4/32 x 2.26 GHz* Linux Server – 24 virtual guests 2 x 4/32 x 2 GHz 2 x 4/32 x 2 GHz* MaxDB, Linux HA VMware – 35 VMs Windows Server 2008 Windows Server 2008 SQL Server 2008, HA Cluster SQL Server 2008, HA Cluster 2 x 8/64 x 2 GHz VMware – 54 VMs Blade Servers Windows Server 2008 Datacenter 4 x 2/12 x 2.66 GHz 8 x 2/8 x 2.4 GHz Blade Servers Windows Server 2008 2 x 4/32 x 2 GHz Blade chassis 16 x 2/12 x 2 GHz Fabric manager 9 x 2/12 x 2.66 GHz 14 x 2/8 x 2.4 GHz Windows Server 2008 3 x Blade chassis Fabric manager Personnel 0.55 FTE 0.95 FTE 2.25 FTEs POWER SYSTEMS Servers Rack Servers Rack-mounted Rack-mounted 2 x 740 2/12 x 3.7 GHz* 2 x 750 2/16 x 3 GHz* 750 4/32 x 3.55 GHz* PowerVM – 29 partitions PowerVM – 39 partitions 750 4/32 x 3 GHz* MaxDB, Linux Server, HA AIX 7.1, DB2 9.7, PowerHA PowerVM – 65 partitions AIX 7.1, DB2 9.7, PowerHA Blade Servers 3 x PS702 4/16 x 3 GHz Blade Servers PowerVM – 18 partitions, AIX 10 x PS701 2/8 x 3 GHz BladeCenter C 8 x PS702 4/16 x 3 GHz BOFM PowerVM – 47 partitions, AIX 2 x BladeCenter H BOFM Personnel 0.3 FTE 0.5 FTE 1.05 FTEs BI: Business Intelligence PLM: Product Lifecycle Management BO: Business Objects SCM: Supply Chain Management CRM: Customer Relationship Management SM: Solution Manager ERP: Enterprise Resource Planning SRM: Supplier Relationship Management GRC: Governance, Risk & Compliance VMs: Virtual machines GTS: Global Trade Services *Clustered configuration PI: Process IntegrationInternational Technology Group 17
    • In this summary, IBM model numbers are shown for Power Systems, while x86 servers are brandedproducts from a major manufacturer equipped with Intel Xeon 7500, 6500 or 5600 series processors.Numbers of processors and cores are shown for servers – e.g., “ 4/32 x 2.26 GHz” refers to a four-socketx86 server equipped with eight-core Intel Xeon X7560 processors, while “750 2/16 x 3 GHz” refers to atwo-socket IBM Power 750 system equipped with two eight-core POWER7 3.0 GHz processors.Blade servers are housed in IBM BladeCenter C and H chassis, which may be configured with up to 6 or14 blades respectively, and x86 equivalents. Chassis are equipped with IBM BladeCenter Open FabricManager (BOFM) and equivalent x86 fabric managers.IT CostsBasis of CalculationsThree-year IT costs were calculated as follows. • Server costs. Hardware and maintenance costs are for initial acquisition and three-year 24/7 coverage respectively for the server configurations shown. For sizing and cost calculations for the mill products company, x86 as well as for Power servers were configured with versions of the same major Linux distribution, along with virtualization and high availability (HA) clustering solutions offered for this distribution. For the two other installations, x86 servers were configured with Windows Server 2008 Enterprise or Datacenter Edition and VMware vSphere 4 Acceleration Kit; while Power Systems were configured with AIX 7.1 Enterprise Edition and PowerVM Enterprise Edition microcode. A third-party solution widely employed among SAP users, and IBM PowerHA SystemMirror for AIX are employed for clustered Windows and Power configurations respectively. Software costs include initial licenses as well as three-year 24/7 support. IBM support costs are for Software Maintenance (SWMA), while Microsoft costs are for Software Assurance coverage. Server configurations were sized based on use of SAP MaxDB for the mill products company, and SQL Server 2008 Enterprise Edition and DB2 9.7 Enterprise Edition for the two other installations. For reasons discussed earlier, database license and support costs are not included in cost calculations. • Facilities costs. These include data center occupancy, power and cooling equipment, and energy consumption over a three-year period. Occupancy cost calculations were based on EIA 42U rack mount units and blade chassis, including service clearances and allowance for inactive areas. A conservative assumption for annual cost per square foot for existing facilities was employed (i.e., costs do not include new facilities construction). Costs for power and cooling equipment were based on configurations of such equipment appropriate for the servers employed in each installation and scenario. Costs were calculated for acquisition and maintenance over a three-year period, using discounted list prices for equipment from leading vendors. Costs were based on prorated values; e.g., if servers required 15 percent of the output of a 10-ton chiller (“ton,” in this context, is a standard cooling metric), calculations were for 15 percent of three-year costs for this equipment.International Technology Group 18
    • Energy costs were calculated based on estimated electricity consumption for server configurations. Specific utilization levels and hours of operation for each profile installation were then applied, and a conservative assumption for average price per kilowatt/hour was employed to determine three-year costs. • Personnel costs. These were calculated for the numbers of full time equivalent (FTE) server administration staff shown in figure 9. Calculations were based on annual salaries of $79,066 and $85,237 for x86 and Power Linux administrators respectively for the Mill Products Company: and $77,985 and $88,152 respectively for Windows and VMware, and Power/AIX and PowerVM administrators respectively for the Industrial Machinery and Logistics Services companies. Salaries were increased by 48.3 percent to allow for benefits, bonuses, training and other personnel-related costs, and calculated for a three-year period.All cost values employed were for the United States.Cost BreakdownsBreakdowns of three-year IT costs for all installations are presented in figure 10. Figure 10 Three-year IT Cost Breakdowns x86 SERVERS POWER SYSTEMS MILL PRODUCTS COMPANY Hardware 80,797 50,615 Maintenance 3,139 2,070 Software licenses & support 20,828 95,370 Personnel 193,471 113,766 Facilities 17,848 8,973 TOTAL ($) 316,083 270,794 INDUSTRIAL MACHINERY COMPANY Hardware 275,503 183,511 Maintenance 8,050 20,899 Software licenses & support 166,370 147,533 Personnel 329,608 196,094 Facilities 50,165 18,656 TOTAL ($) 829,696 566,693 LOGISTICS SERVICES COMPANY Hardware 693,108 327,631 Maintenance 21,802 20,494 Software licenses & support 409,920 293,387 Personnel 780,649 411,798 Facilities 162,554 55,615 TOTAL ($) 2,068,033 1,108,925International Technology Group 19
    • Costs of DowntimeCosts of downtime were calculated using a two-phase process.First, average costs per hour of downtime for the three companies summarized in figure 2 were calculatedusing appropriate industry- and company-specific values. “Average,” in this context, means that costs arebased on overall annual volumes of business activity divided by hours of operation.For the two manufacturing companies, three main cost categories were employed: 1. Outbound supply chain disruption consisted of costs caused by disruption of activities between factory release and customer delivery. These included costs of idle and underutilized capacity, including personnel costs; handling of delivery delays, including distribution center and transportation costs; inventory carrying costs; and costs of change for affected processes. 2. Inbound supply chain and production disruption consisted of costs incurred for activities between initial supplier queries and factory release. These included costs of idle and underutilized capacity for inbound logistics and production operations; handling of delivery delays; inventory carrying costs; and costs of supplier order, production scheduling and other changes. 3. Other costs included penalties for late delivery and imperfect orders, along with buyback costs such as rebates; costs of customer billing delays; reduced productivity of and additional work performed by sales, customer service and administrative personnel; and other items.For the logistics services company, two cost categories were employed: 1. Operational disruption consisted of costs caused by delays in transportation and warehousing processes. These included costs of idle and underutilized capacity, including equipment-related costs and personnel-related costs for drivers, warehouse, fuelling, maintenance and other personnel; costs of rescheduling; and other items. Cost items corresponded to the “Operating Costs” category normally reported by transportation and logistics companies. Items included rents and equipment costs; salaries, wages and benefits; fuel and fuel taxes; depreciation and amortization; operating supplies and expenses; insurance; operating licenses and taxes; communications and utilities; and general and administrative costs. 2. Other costs included late delivery penalties; buyback costs such as additional discounts and rebates; costs of customer billing delays; and reduced productivity of and additional work performed by sales and headquarters; and other items.Second, average costs per hour of downtime were multiplied by numbers of hours of downtime per yearfor each platform. These were calculated based on user input. The focus was placed on downtime forunderlying server platforms, rather than downtime for SAP applications, databases and middleware.Annual costs of downtime for each platform were then multiplied for three-year totals.All cost values were again for the United States.International Technology Group 20
    • ABOUT THE INTERNATIONAL TECHNOLOGY GROUP ITG sharpens your awareness of what’s happening and your competitive edge . . . this could affect your future growth and profit prospectsThe International Technology Group (ITG), established in 1983, is an independent research andmanagement consulting firm specializing in information technology (IT) investment strategy, cost/benefitmetrics, infrastructure studies, deployment tactics, business alignment and financial analysis.ITG was an early innovator and pioneer in developing total cost of ownership (TCO) and return oninvestment (ROI) processes and methodologies. In 2004, the firm received a Decade of Education Awardfrom the Information Technology Financial Management Association (ITFMA), the leading professionalassociation dedicated to education and advancement of financial management practices in end-user ITorganizations.The firm has undertaken more than 100 major consulting projects, released approximately 160management reports and white papers, and delivered nearly 1,800 briefs and presentations to individualclients, user groups, industry conferences and seminars throughout the world.Client services are designed to provide factual data and reliable documentation to assist in the decision-making process. Information provided establishes the basis for developing tactical and strategic plans.Important developments are analyzed and practical guidance is offered on the most effective ways torespond to changes that may impact or shape complex IT deployment agendas.A broad range of services is offered, furnishing clients with the information necessary to complementtheir internal capabilities and resources. Customized client programs involve various combinations of thefollowing deliverables: Status Reports In-depth studies of important issues Management Briefs Detailed analysis of significant developments Management Briefings Periodic interactive meetings with management Executive Presentations Scheduled strategic presentations for decision-makers Email Communications Timely replies to informational requests Telephone Consultation Immediate response to informational needsClients include a cross section of IT end users in the private and public sectors representing multinationalcorporations, industrial companies, financial institutions, service organizations, educational institutions,federal and state government agencies as well as IT system suppliers, software vendors and service firms.Federal government clients have included agencies within the Department of Defense (e.g. DISA),Department of Transportation (e.g. FAA) and Department of Treasury (e.g. US Mint). International Technology Group 4546 El Camino Real, Suite 230 Los Altos, California 94022-1069 ITG Telephone: (650) 949-8410 Facsimile: (650) 949-8415 Email: info-itg@pacbell.net POL03081-USEN-00