The New zenterprise A Cost-Busting Platform

Transcription

1 The New zenterprise A Cost-Busting Platform TCO Lessons Learned, Establishing Equivalence (aka Improving ROI with CICS and the Mainframe)

2 Total Cost of Ownership In Context: The Mainframe Is IBMs Premier Platform IBM arguably makes the best x86 and UNIX hardware However, the mainframe remains the pinnacle of IBM technology Technologies pioneered on the mainframe eventually get emulated in limited ways on x86 and UNIX systems As we already know, today the mainframe has: The best hardware world s fastest microprocessor (5.5 GHz), most I/O channels, hardware assisted clustering for scale out,... The best software able to smoothly integrate the value of the existing (z/os, CICS, COBOL, PL/I, etc.) with the newest technologies of today (Linux, J2EE, Java, XML, REST, etc.) Best for efficiency heavily automated, world-leading problem determination and performance analysis, minimal administrative footprint (centralized deployment = very few LPARs, eg. <5) Best for environmentals lowest electrical, networking and floor space usage per unit of work processed compared to others 2

3 What s So Special About A Mainframe Anyway? A few things come together to make mainframes special Centralized computing is inherently more efficient than distributed or modular computing High availability at the application level, not just the hardware, and easy DR Ability to reuse existing assets in new ways and via new technologies gives huge investment protection Unmatched workload management enables stuffing the pipe without impact to important work run continuously at 100% safely Balanced compute and I/O hardware for ultimate scale up Hardware assisted clustering (used by all middleware) for ultimate scale out 3 The results can be measured for instance, throughput per core on mainframes is MUCH higher than on other machines Simply switching to a modular deployment model while remaining on mainframe hardware requires a 6x expansion in compute capacity Mainframes routinely provide the highest availability to their end users Reusing (sometimes with some modernization) existing assets is fast, cheap and safe compared to the other options Flexibility in scale and ability to dynamically react to workload spikes without manual intervention gives peace of mind against changing conditions

4 Customer Data: System z Utilization Unheard Of On Other Hardware Platforms Example: Core banking workloads running simultaneously with high utilization Data Warehouse Online Data Warehouse Batch Overnight Batch Online Transactions Compare to a medium-sized EMEA bank with a range of Sun/Oracle and x86 servers, average over whole estate <10% 1125 total servers, 228 no data (MS Windows) 624 have average utilization 10% or less (70% of estate) 511 have 5% or less (60%), only 5% avg over 40% utilization 4

5 Typical Customer Deployment Pattern Shows The Importance Of The Mainframe Many applications depend on the core mainframes for their data and services In the diagram it is striking that there are almost no connections between individual client nodes, communications travel to/from the core The mainframes provide a highly available central cluster of core services and data to the whole business 5

6 Cost per unit of work IBM Competitive Project Office Example of The Cost Differences Of System z vs. Distributed Why do distributed database costs per unit of work rise as workloads grow? Core proliferation Software priced per-core Oracle database software costs Largest component of cost Hardware cost escalates faster as number of cores (SMP) grows Why do System z database costs per unit of work fall as workloads grow? Linear scalability Size of Database Workload DB2 on z/os Mainframe software pricing reflects economies of scale 6

7 Core Proliferation For A Small Workload Shows Relative Efficiency (Actual Customer) 6x 8-way Production / Dev 2x 64-way Production / Dev Application/MQ/DB2/Dev partitions x z900 3-way Production / Dev / QA / Test 6 processors (1,660 MIPS) processors (800,072 Performance units) $25.4M (5 yr. TCO) 29x more cores! $17.9M (5 yr. TCO) 7 Still a mainframe customer (primary workloads moved to 2 new mainframes), this equivalence shows only the filler applications that moved off in an application portfolio management initiative

8 Core Proliferation Is Not Related To Size De-consolidation of applications to dedicated servers Dedicated servers / images for functional roles application, database, security, batch, systems management Separate servers for production, development, quality assurance test Low utilization due to provisioning for the peak on each server and preprovisioning for growth NOT SOLVED by virtualization due to capacity reservations in production! Disaster Recovery 100% coverage doubles the number of cores required 8 Processing comparisons Mainframe has dedicated processors for I/O, distributed does not Processing expansion (CICS/COBOL path lengths are highly optimized) Converting IMS hierarchical database to relational results in a 3x expansion No networking on mainframe reduces computation (and latency) Storage expansion and increased data management

9 Core Proliferation For A Smaller Project (Actual Customer Experience) 2x 16-way Production / Dev / Test / Education App, DB, Security, Print and Monitoring 4x 1-way Admin / Provisioning / Batch Scheduling z890 2-way Production / Dev / Test / Education App, DB, Security, Print, Admin & Monitoring processors (332 MIPS) $17.9M (4 yr. TCO) Plus: 2x HP SAN Servers (existing) Many (existing) Windows servers 36 Unix processors (222,292 Performance Units) 41x more cores Almost 5 Year Migration 670 Performance Units per MIPS No Disaster Recovery $4.9M (4 yr. TCO)

10 Move To x86 Worst Core Proliferation Ever! (Actual Customer Experience) 3x HP DL580 (2ch/20co) Production / Dev / Test (2011 x86 technology) processors (499 MIPS) z800 Production / Dev / Test (2002 mainframe technology) 3 60 Linux processors (383,022 Perf Units, 8 MIPS/core) 29x more cores (with the 9 year technology gap) Equivalent to 180x more cores with current technology Year Migration 768 Performance Units per MIPS

11 Works In Reverse Too! Typical UNIX-Style Data Workloads Benefit From System z Which platform provides the lowest TCA over 3 years? 3 Oracle RAC clusters 4 server nodes per cluster 12 total Oracle T3-4 servers (768 cores) $28.7M (3 yr. TCA) Oracle DB workload 3 Database Workloads Oracle Enterprise Edition Oracle Real Application Cluster TCA includes hardware, software, maintenance, support and subscription. Workload Equivalence derived from a proof-of-concept study conducted at a large Cooperative Bank and projecting to T3-4 servers using published TPC-C Results normalizing them to Relative Performance Units as available from Ideas International 11 3 Oracle RAC clusters 4 nodes per cluster Each node is a Linux on z guest zec12 with 27 IFLs $5.7M (3 yr. TCA) 80% less cost!

12 Chargeback (or Cost Accounting) Can Mislead If Allocations Are Not Truly Aligned With Platforms The mainframe is often the computing platform that has been around the longest in the data center It is also the platform that is best at accounting and billing for usage Great for supporting cloud deployments! Therefore many datacenter fixed costs that are not platform specific are recovered or accounted for under the mainframe The Eagle TCO team has now come across 3 customers who recover the company jet costs under the heading of mainframe computing... Many small costs on a per-server basis are ignored and recovered as overhead to the whole data center... via the mainframe! While most important applications that run off the mainframe continue to use the mainframe, everyone gets charged their fair share However, this chargeback / accounting scheme gives the impression that the mainframe is expensive compared to other options Unfortunately this creates incentives to move off, and it is only when customers eventually update their chargeback that they discover they were led astray 12

13 Other Savings The Mainframe Provides Special pricing metrics for new workloads and integration Sub-capacity pricing for utility pricing of workloads Consolidation with Linux on System z reduces the software and management costs of modular UNIX-style workloads Specialty processors and devices to reduce cost further Fast, simple hardware refresh with investment protection Easy and low cost disaster recovery Minimal additional capacity for non-production environments (development, test) Gold standard in tooling for automation and problem determination Enjoy the simplicity, security and performance advantages of collocating important workloads and data together 13

14 System z Linux Consolidation Saves Money Large financial services company Mixed Oracle and WAS environments on Intel Scaling out rapidly up to 172 images on 836 cores Refresh existing x86 Consolidate on Linux on z Observation Software 9.76M 3.70M Software costs down 62% Hardware 2.32M 5.22M Hardware costs up 125% Labor/Facilities 3.83M 0.69M Charge to department down 82% Migration 0.18M 0.41M Cost Avoidance M Total 16.1M 9.41M 5 Year Savings: 6.6M 26:1 core consolidation from virtualized x86 to Linux on z 14

15 Hardware Generation Hardware Generation IBM Competitive Project Office Distributed Servers Need To Be Replaced Every 3 To 5 Years Lifecycle of Unix Servers Initial Distributed System 1 st Technology Refresh 30 months 2nd Technology Refresh 3rd Technology Refresh Refresh is normally even worse than just repurchasing existing capacity as this real customer demonstrates: 15 6 months provisioning Initial Mainframe System 24 months production Lifecycle of Mainframe Generations 30 months 1 Weekend upgrading to new hardware and patch levels 30 months 1 st Technology Refresh Time 30 months production 30 months 2 nd Technology Refresh No need to retire the server, upgrade in place. Non-mainframe systems must co-exist for months at a time while being refreshed, requiring space, power, licenses etc. In this case only 24 months of productive work is realized for each 30 month lease period and the leases overlap up to 6 months The mainframe by contrast is upgraded over a weekend and is fully productive at all times

16 Cost (x1,000) IBM Competitive Project Office Disaster Recovery On System z Costs Much Less Than On Distributed Servers A large European insurance company with mixed distributed and System z environment at : Disaster Recovery Cost as a percentage of Total Direct Costs: System z 3% Distributed 21% Total Costs DR Costs Two mission-critical workloads on distributed servers had DR cost > 40% of total costs System z 3% 21% Distributed 16

17 Non-Production Environments Require Fewer Resources On The Mainframe High Availability mechanisms for Production Dedicated failover (Prod x 2.5) N+1 clustered (Prod x 2 worst case) Mainframe (usually Prod x 1, sometimes less!) Development and Test Capacity Mainframe Prod +20% Distributed a range, often Prod +200% 100 Mainframe Usage Profile 80 Dev / Test 60 QA 40 Production 20 Production QA Dev/Test/DR hours

18 Cost per Unit IBM Competitive Project Office Reality Of Incremental Costs For Different Platforms Is Quite Different Mainframes are priced to deliver a substantial economy of scale as they grow Doubling of capacity results in as little as a 30% cost growth for software on z/os Average Cost is significantly more than incremental cost Average Unit Cost OK for Non-mainframe Total Units Units Mainframe has more pronounced economy of scale 18

19 $250,000 $200,000 Incremental cost per MIP = $28 Monthly License Charge (MLC) Mainframe Pricing Curves Favor Growth (Software Example Shown) Incremental cost per MIP = $12 DB2 V8 z/os V1 CICS TS V3 IMS/DB V9 Total price $150,000 $100,000 $50,000 $0 0 1,000 2,000 3,000 4,000 5,000 6,000 7,000 8,000 9,000 10,000 MIPs of system 19

20 Future Mainframe Directions Consolidate and improve analytics Keep data where it originates rather than move it around Allows change from delayed data warehouse model to real-time analytics with feedback loop into online systems Offload to specialty devices where necessary for cost, but crucially, do this dynamically under computer control, not manually so retain a single access paradigm for all work Continue to enable new technologies to access existing services and data eg. CICS enables HTTP, then XML and now RESTful access to existing transactions and data Enable adaptation to changing business requirements eg. CICS embeds WAS Liberty for batch allowing batch tasks to run at any time during the day in cooperation with online work Continue to provide the most efficient centralized deployment model Ever larger, faster and better machines with middleware to exploit 20 Enhance existing cloud and management capabilities eg. Smart Cloud Provisioning with workload patterns support

21 Many Customers Have Built Complex Data Movement Solutions With Unforeseen Costs Analytical Data Analytical Data Analytical Data A large European bank: 120 database images created from bulk data transfers 1,000 applications on 750 cores with 14,000 software titles ETL consuming 28% of total distributed cores and 16% of total MIPS Operational Data Analytical Data Analytical Data A large Asian bank: One mainframe devoted exclusively to bulk data transfers ETL consuming 8% of total distributed core and 18% of total MIPS 21

22 Clearly Moving Data Is Not Free Here is a Typical Situation z10 Power 7 Analytical Data Analytical Data Analytical Data 4 yr. amortized cost summary System costs = $8,046,198 Labor costs = $223,137 Total = $8,269,335 Analytical Data Operational Data 22

23 IBM zenterprise System is Optimized for All Critical Data Run the business Grow the business Operational Data Analytics Data IBM DB2 Analytics Accelerator zenterprise EC12 23

24 Analytics on zenterprise with the Accelerator Beats the Competition Standalone Pre-integrated Competitor Quarter Unit DB2 v10 z/os 1 GP+1 ziip IBM zenterprise IBM DB2 Analytics Accelerator zec12 Unit Cost (3yr TCA) $905/RpH Unit Cost (3yr TCA) $71/RpH Workload Time 3,043 mins Workload Time 294 mins Reports per Hour (RpH) 3,178 Reports per Hour (RpH) 32,891 Competitor ¼ Rack (HW+SW+Storage) $2,876,561 zec12 (1 GP + 1 ziip, HW+SW+50TB Storage)+Accelerator $2,337,400 12x better price performance! Source: IBM Customer Study. 24

25 The IBM Eagle team helps customers understand mainframe costs and value Worldwide team of senior technical IT staff Free of Charge Total Cost of Ownership (TCO) studies Help customers evaluate the lowest cost option among alternative approaches Includes a one day on-site visit and is specifically tailored to a customer s enterprise Studies cover POWER, PureSystems and Storage accounts in addition to System z For both IBM customer and Business Partner customer accounts Over 300 customer studies since formation in 2007 Contact: eagletco@us.ibm.com Fit For Purpose Platform Selection Private Cloud Implementation Enterprise Server Economics 25

26 What happens in a TCO study? Workload identified for analysis frontends databases other components Application XYZ (Prod, Dev, QA) Deployment Choices Do nothing Optimize current environment Deploy on other platforms Key steps in analysis 1. Establish equivalent configurations - Needed to deliver workload 2. Compare Total Cost of Ownership - TCO looks at different dimensions of cost 26

27 How can we determine equivalent configurations? Real world aspects determine accurate equivalence App 1 App 1 Bottoms up approach App 2 App 2 Top Down approach What we see in customer environments App App DB DB What we know about platforms and measure in atomic benchmarks 27

28 Platform differences and atomic benchmarks set a baseline for establishing equivalence App 1 App 1 App 2 App 2 App App DB DB Platform factors GHz, cache, I/O, co-location Variability in demand Different size servers Workload Management Mix workloads with different priorities 28

29 Like zec12, new zbc12 has larger cache structures to support more concurrent workloads zbc12 chip or Cores Intel Sandy Bridge chip Cores L1 Cache 960KB L2 Cache 12MB L1 Cache 512KB L2 Cache 2MB L3 Cache 24MB (4.8-6MB per core*) L3 Cache 20MB (2.5MB per core) L4 Cache (192MB per SC chip) No L4 Cache Advantages of large cache: Fewer cache misses help maintain thread processing speed Improves database performance by holding larger working sets Improves consolidated workload performance by supporting more working sets * Six core PU chips using 4 and 5 active core per PU chip. 4.8 MB L3 cache if 5 active core per chip. 6MB L3 cache if 4 active core per chip. 29

30 Single Array Element Addition Time (ns) IBM Competitive Project Office Intel servers slow down under cache intensive workloads Multiple concurrent processes introduces cache contention Example: 5 processes each with 70MB working set size Intel workloads significantly slowed due to cache contention System z with z/os showed results 8x faster than Intel system zec12 Power7 Sandy Bridge 30

31 Larger cache is beneficial for SAP workloads as well as CICS, VSAM and Batch workloads Cost advantage for smaller scale SAP database: SAP Applications SQL Server on Intel SAP Applications DB2 on z/os 4 x HP DL GHz 4ch/32co zec12 with 3 GP + 2 ziips 128 DB cores 5 cores Database Unit Cost $86/User Database Unit Cost $61/User 29% lower unit cost # of Users 23,000 Hardware $0.34M Software $1.64M Total (3 yr. TCA) $1.98M # of Users 23,000 DB2 Solution Edition(HW+SW) $1.40M Total (3 yr. TCA) $1.40M Note: Workload Equivalence established from a large US Retailer SAP DB offload incorporating estimated CPU Savings from DB2 for z/os upgrade (107 Performance Units per MIPS). Upgrading from DB2 V8 to V10 reduces average CPU usage by 28%. DB2 V10 for z/os on zec12 and SQL Server 2008 on Intel 31

32 Dedicated I/O subsystem means System z is ideal for high bandwidth workloads Capacity benchmark for Bank of China: Transactions per second 9,000 8,000 7,000 6,000 5,000 4,000 3,000 2,000 1, ,024 5,723 Goal: 4,100 TPS 4,665 3,120 1, ,000 10,000 15,000 20,000 MIPS Data Transfer (MB/sec) Read Write ,589 3,120 4,665 5,723 8,024 Transactions per second System z easily surpassed benchmark goal, and demonstrates near linear scalability Reads and writes are well-balanced and scale linearly, demonstrating no constraints on I/O constraint 32

33 CPU utilization IBM Competitive Project Office Tests show Intel s performance degrades as I/O demand increases Test case scenario: Run multiple virtual machines on x86 server Each virtual machine has an average I/O rate x86 processor utilization is consumed as I/O rate increases With no dedicated I/O subsystem, Intel s performance degrades Intel CPU As IO Load Increases CPU% Excess CPU cycles spent on processing I/O No IO 256KB IO 512KB IO 1MB IO 1.5MB IO VMs 33

34 Multi-tenant database testing also demonstrates System z s superior ability to handle I/O load Which platform can achieve the lowest cost per workload? 1 workload on 16-core quarter unit Pre-integrated DB Competitor V2 Multi-Tenant Private Cloud $2.27M/workload I/O Intensive Database Workload Brokerage high volume trading workload, each driving a minimum* of 243 transactions per second on 200GB database 5 multi-tenant workloads on zec12 2 GPs + 2 ziips DB2 10 for z/os on zec12 $1.73M/workload 25% lower cost! * Maximum TPS was measured at 270 based on 70 ms injection interval for customer threads. SLA requires no more than 10% degradation in throughput, yielding a Minimum TPS of

35 Platform differences and atomic benchmarks set a baseline for establishing equivalence App 1 App 1 App 2 App 2 App App DB DB Platform factors GHz, cache, I/O, co-location Variability in demand Different size servers Workload Management Mix workloads with different priorities 35

36 Larger servers with more resources make more effective consolidation platforms Most workloads experience variance in demand When you consolidate workloads with variance on a virtualized server, the variance of the sum is less (statistical multiplexing) The more workloads you can consolidate, the smaller is the variance of the sum Consequently, bigger servers with capacity to run more workloads can be driven to higher average utilization levels without violating service level agreements, thereby reducing the cost per workload 36

37 A single workload requires a machine capacity of 6x the average demand Server utilization = 17% Server Capacity Required 60/sec 6x Peak To Average Average Demand m=10/sec Assumes coefficient of variation = 2.5, required to meet 97.7% SLA 37

38 Consolidation of 4 workloads requires server capacity of 3.5x average demand Server utilization = 28% Server Capacity Required 140/sec 3.5x Peak To Average Average Demand 4*m = 40/sec Assumes coefficient of variation = 2.5, required to meet 97.7% SLA 38

39 Consolidation of 16 workloads requires server capacity of 2.25x average demand Server utilization = 44% 2.25x Peak To Average Server Capacity Required 360/sec Average Demand 16*m = 160/sec Assumes coefficient of variation = 2.5, required to meet 97.7% SLA 39

40 Consolidation of 144 workloads requires server capacity of 1.42x average demand Server utilization = 70% 1.42x Peak To Average Server Capacity Required 2045/sec Average Demand 144*m = 1440/sec Assumes coefficient of variation = 2.5, required to meet 97.7% SLA 40

41 Actual data from a POWER customer demonstrates how statistical multiplexing applies to all large scale virtualization platforms PAF5PDC Large US insurance company 13 production POWER7 frames Some large servers, some small servers Detailed CPU utilization data 30 minute intervals, one whole week For each LPAR on the frame For each frame in the data center Measure peak, average, variance 41 Cores CPU % /9/1912 0:00 12/10/1912 0: /9/ /10/ /11/1912 0:00 0:00 0:00 12/11/1912 0:00 12/12/1912 0:00 12/12/1912 0:00 MSP159 12/13/1912 0:00 12/13/1912 0:00 12/14/1912 0:00 12/14/1912 0:00 12/15/1912 0:00 12/15/1912 0:00 12/16/1912 0:00 12/16/1912 0:00 All Guidewire

42 Customer data confirms statistical multiplexing theory Workloads vs. Peak-to-Average (Final Theoretical Model Overlaid) 8 Peak To Average Ratio LPAR Count Servers with more LPARs have less variance in their utilization! The larger the shared processor pool, the greater the statistical benefit Large scale virtualization platforms are able to consolidate large numbers of virtual machines because of this Servers with capacity to run more workloads can be driven to higher average utilization levels without violating service level agreements 42

43 Just for grins, what does a typical x86 VMware consolidation look like? Peak To Average (PROD only) Pk:Avg-1 for POWER curve fit y = x R 2 = VMs) Servers with more LPARs show no difference in the variance in their utilization than any other! This looks more like a random number generator than a consolidation curve! No apparent correlation between workloads and consolidation... 43

44 Platform differences and atomic benchmarks set a baseline for establishing equivalence App 1 App 1 App 2 App 2 App App DB DB Platform factors GHz, cache, I/O, co-location Variability in demand Different size servers Workload Management Mix workloads with different priorities 44

45 Priority transactional workload does not degrade when low priority workloads added System z - Transactional Workload Running Uncontested z/os WLM - Priority Transactional Workload Running With Other Workloads - 1 Hour Run %CPU Utilization Priority Workload %CPU Utilization Donor Wkld 7 Donor Wkld 6 Donor Wkld 5 Donor Wkld 4 Donor Wkld 3 Donor Wkld 2 Donor Wkld 1 Priority Workload Capacity Used High Priority Steady State % CPU Minutes Unused (wasted) % CPU Minutes Capacity Used High Priority Steady State % CPU Minutes Unused (wasted) - 0% CPU Minutes 45 Priority Workload Metrics Total Throughput: 417.8K Maximum TPS Priority Workload Metrics Total Throughput: 414.7K Maximum TPS NO steady state CPU usage leakage 1% total transaction leakage

46 z/os Workload Manager (WLM) extends priority all the way down to storage FICON protocol supports advanced storage connectivity features not found in x86 Priority Queuing: Priority of the low-priority programs will be increased to prevent high-priority channel programs from dominating lower priority ones 46

47 Tests demonstrate comparison of System z PR/SM virtualization to a common hypervisor High Priority web workload has defined demand over time SLA requires that response time does not degrade Low Priority web workload has unlimited demand It soaks up unused CPU minutes FB guest (WAS FB + guest DB2) (WAS FB High + DB2) Priority (WAS + DB2) z/vm LPAR High PR/SM Weight FINDPRIME FINDPRIME FB Soaker Soaker Low Priority (WAS + DB2) z/vm LPAR Low PR/SM Weight FB guest FINDPRIME (WAS FB + guest DB2) FINDPRIME Soaker (WAS FB High 99% share + DB2) Priority FB 1% Soaker Low Priority (WAS + DB2) share 99% share (WAS + DB2) 1% share High share Low share Common Intel Hypervisor PR/SM Partitions zec12 32 Shared cores Intel Westmere EX 40 cores 47

48 System z demonstrates perfect workload management zvm 10VM 32 Core % CPU Usage % CPU Usage % CPU Usage % CPU Usage % CPU Usage z/vm 10VM 32 Core CPU Usage With Physical Time (mins) Time (mins.) Time (mins) Demand curve for 10 high priority workloads running in 1 z/vm LPAR (PR/SM weight = 99) Workloads consume 72% of available CPU resources (28% unused) Usage - FB Standalone Total throughput: 9.13M Average response time: 140ms Demand curve when 14 low priority (PR/SM weight = 1) workloads are added in a second z/vm LPAR All but 2% of available CPU resources is used (high=74%, low=24%) Donor Workload Priority Workload High priority workload throughput is maintained (9.13M) No response time degradation (140ms)

49 % CPU Usage % CPU Usage IBM Competitive Project Office Unlike this common Intel hypervisor which demonstrates imperfect workload management ESX % CPU Usage FB % CPU Usage ESX CPU Usage Shared Demand curve for 10 high priority workloads running on a common Intel hypervisor (high share) Workloads consume 58% of available CPU resources (42% unused) Usage - FB Standalone Total throughput: 6.47M Average response time: 153ms % CPU Usage Time (mins) Time (mins.) Time (mins) 55 Demand curve when 14 low priority (low share) workloads are added 22% of available CPU resources is unused (high=42%, low=36%) Donor Workload Priority Workload High priority workload throughput drops 31% (4.48M) Response time degrades 45% (220ms)

50 % CPU Usage % CPU Usage % CPU Usage % CPU Usage IBM Competitive Project Office System z virtualization enables mixing of high and low priority z/vm 10VM 32 Core CPU Usage With Physical workloads without penalty ESX CPU Usage Shared Time (mins) Time (mins.) Time (mins) 55 Perfect workload management Donor Workload Consolidate workloads of different priorities on the same platform Priority Workload Full use of available processing resource (high utilization) Imperfect workload management Forces workloads to be segregated on different servers Donor Workload Priority Workload System z Common Intel hypervisor More servers are required (low utilization)

51 Imperfect workload management leads to core proliferation and higher costs Which platform provides the lowest TCA over 3 years? VMs VMs Virtualized on 3 Intel 40 core servers VMs $13.7M (3 yr. TCA) High priority workloads Low priority workloads IBM WebSphere 8.5 ND IBM DB2 10 AESE Monitoring software High priority online banking workloads driving a total of 9.1M transactions per hour and low priority discretionary workloads driving 2.8M transactions per hour VMs z/vm VMs z/vm Consolidation ratios derived from IBM internal studies.. zec12 numbers derived from measurements on z196. Results may vary based on customer workload profiles/characteristics. Prices will vary by country. 51 z/vm on zec12 32 IFLs $5.77M (3 yr. TCA) 58% lower cost!

52 How can we determine equivalent configurations? Real world aspects determine accurate equivalence App 1 App 1 Bottoms up approach App 2 App 2 Top Down approach What we see in customer environments App App DB DB What we know about platforms and measure in atomic benchmarks 52

53 Why are rehosting costs underestimated? From HP s Mainframe Alternative Sizing guide, published in 2012 Can a 2-chip, quad-core x86-based Blade server really replace 3,000+ MIPS? Simple core comparisons are inherently inaccurate Real world use cases suggest this number is off by a factor of times 53

54 Eagle TCO study shows this mid-sized workload was not cheaper on the distributed platform 6x 8-way (x86) Production / Dev 2x 64-way (Unix) Production / Dev Application/MQ/DB2/Dev partitions processors? 2x z900 3-way Production / Dev / QA / Test 1,660 MIPS (6 processors) 3 3 $25.4M (5 yr. TCO) 29x more cores! $17.9M (5 yr. TCO) 482 Performance Units per MIPS 54

55 Eagle TCO Study shows a pure Intel offload was not cost-effective 20 3x HP DL580 (2ch/20co) Production / Dev / Test (2011 x86 technology) MIPS (2.1 processors) z800 Production / Dev / Test (2002 mainframe technology) processors Despite a 9-year technology gap, the Intel platform still required 29x more processors 768 Performance Units per MIPS 55

56 Is there a cross over point? 1,000 MIPS? 500 MIPS? A sampling of Eagle TCO data suggests there is no minimum MIPS value that automatically makes an offload financially beneficial The determining factor is really the nature of the workload 56

57 Eagle TCO study shows this small workload was not cheaper on the distributed platform 2x 16-way (Unix) Production / Dev / Test / Education App, DB, Security, Print and Monitoring 4x 1-way (Unix) Admin / Provisioning / Batch Scheduling z890 2-way Production / Dev / Test / Education App, DB, Security, Print, Admin & Monitoring MIPS (0.88 processors) processors $17.9M (4 yr. TCO) 41x more cores! $4.9M (4 yr. TCO) 670 Performance Units per MIPS 57

58 Eagle TCO study shows even this VERY small workload was not cheaper on the distributed platform 4x p550 (1ch/2co) Application and DB z890 Production / Test MIPS (0.24 processors) 8 processors $8.1M (5 yr. TCO) 33x more cores! $4.7M (5 yr. TCO) 499 Performance Units per MIPS 58

59 What happens in a TCO study? Workload identified for analysis frontends databases other components Application XYZ (Prod, Dev, QA) Deployment Choices Do nothing Optimize current environment Deploy on other platforms Key steps in analysis 1. Establish equivalent configurations - Needed to deliver workload 2. Compare Total Cost of Ownership - TCO looks at different dimensions of cost 59