• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Relative Capacity por Eduardo Oliveira e Joseph Temple
 

Relative Capacity por Eduardo Oliveira e Joseph Temple

on

  • 397 views

 

Statistics

Views

Total Views
397
Views on SlideShare
397
Embed Views
0

Actions

Likes
1
Downloads
6
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • IBM Systems for an On Demand Business – Agenda chart This presentation is intended to highlight three key areas: 1) Why is innovation in business important? Innovation is the most likely way for businesses to address challenges they face today: to grow while maintaining or better managing costs. 2) Secondly, we believe that IBM Systems can help you innovate – through technologies, people and solutions that help ignite innovation through business and technology integration – using technology as an innovation catalyst by combining it with business and market insights. In other words – becoming an On Demand Business 3) So before we go further, lets’ touch on why you may want to become an On Demand Business? (or continue your current path toward becoming an On Demand Business) At IBM, we believe an On Demand Business drives innovation more effectively . Why? Because an On Demand Business is dynamically responsive to customer demands, market opportunities and external threats. The real-time exchange of ideas, insights and experience is critical. The objective is to achieve growth and profit, not by aggressively cutting costs necessarily, but through innovations that improve product or service delivery, allow entry into new markets and increase productivity. Transition line: Many executives today believe that for a company to grow revenue it must innovate, to do new things that drive different results.
  • Large machines are required for parallel hell and parallel purgatory. Blades, Rack optimized clusters, and MPPs work well in parallel nirvana. Distributed Client Server build out is in the center of the chart.

Relative Capacity por Eduardo Oliveira e Joseph Temple Relative Capacity por Eduardo Oliveira e Joseph Temple Presentation Transcript

  • Relative Capacity Joseph Temple – Distinguished Engineer Eduardo Oliveira – Executive IT Specialist © Copyright IBM Corporation, 2008
  • Trademarks The following are trademarks of the International Business Machines Corporation in the United States, other countries, or both. The following are trademarks or registered trademarks of other companies. * All other products may be trademarks or registered trademarks of their respective companies. Notes : Performance is in Internal Throughput Rate (ITR) ratio based on measurements and projections using standard IBM benchmarks in a controlled environment. The actual throughput that any user will experience will vary depending upon considerations such as the amount of multiprogramming in the user's job stream, the I/O configuration, the storage configuration, and the workload processed. Therefore, no assurance can be given that an individual user will achieve throughput improvements equivalent to the performance ratios stated here. IBM hardware products are manufactured from new parts, or new and serviceable used parts. Regardless, our warranty terms apply. All customer examples cited or described in this presentation are presented as illustrations of the manner in which some customers have used IBM products and the results they may have achieved. Actual environmental costs and performance characteristics will vary depending on individual customer configurations and conditions. This publication was produced in the United States. IBM may not offer the products, services or features discussed in this document in other countries, and the information may be subject to change without notice. Consult your local IBM business contact for information on the product or services available in your area. All statements regarding IBM's future direction and intent are subject to change or withdrawal without notice, and represent goals and objectives only. Information about non-IBM products is obtained from the manufacturers of those products or their published announcements. IBM has not tested those products and cannot confirm the performance, compatibility, or any other claims related to non-IBM products. Questions on the capabilities of non-IBM products should be addressed to the suppliers of those products. Prices subject to change without notice. Contact your IBM representative or Business Partner for the most current pricing in your geography. Adobe, the Adobe logo, PostScript, and the PostScript logo are either registered trademarks or trademarks of Adobe Systems Incorporated in the United States, and/or other countries. Cell Broadband Engine is a trademark of Sony Computer Entertainment, Inc. in the United States, other countries, or both and is used under license therefrom. Java and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the United States, other countries, or both. Microsoft, Windows, Windows NT, and the Windows logo are trademarks of Microsoft Corporation in the United States, other countries, or both. Intel, Intel logo, Intel Inside, Intel Inside logo, Intel Centrino, Intel Centrino logo, Celeron, Intel Xeon, Intel SpeedStep, Itanium, and Pentium are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries. UNIX is a registered trademark of The Open Group in the United States and other countries. Linux is a registered trademark of Linus Torvalds in the United States, other countries, or both. ITIL is a registered trademark, and a registered community trademark of the Office of Government Commerce, and is registered in the U.S. Patent and Trademark Office. IT Infrastructure Library is a registered trademark of the Central Computer and Telecommunications Agency, which is now part of the Office of Government Commerce. For a complete list of IBM Trademarks, see www.ibm.com/legal/copytrade.shtml: *, AS/400® , e business(logo)® , DBE, ESCO, eServer, FICON, IBM® , IBM (logo)®, iSeries® , MVS, OS/390® , pSeries® , RS/6000® , S/30, VM/ESA® , VSE/ESA, WebSphere® , xSeries® , z/OS® , zSeries® , z/VM® , System i, System i5, System p, System p5, System x, System z, System z9® , BladeCenter® Not all common law marks used by IBM are listed on this page. Failure of a mark to appear does not mean that IBM does not use the mark nor does it mean that the product is not actively marketed or is not significant within its relevant market. Those trademarks followed by ® are registered trademarks of IBM in the United States; all others are trademarks or common law marks of IBM in the United States.
  • Agenda
    • General Ideas
    • Pfister’s Diagram
    • Workload Type/Characteristics
    • Workload Factor
    • Benchmarks
    • White Space
    • Virtualization and Utilization
    • Relative Capacity
    • Ideas International/Performance Comparison
    • Non-Functional requirements
    • Total Cost of Ownership (TCO)
    • Consolidation: Case Study
    • Platform Choices
  • General Ideas
    • It is the nature of computers that any computer can be programmed to accomplish any task.
    • Conversely, functionality is not enough.
    • Rational Platform Selection is based on the solution’s “non functional requirements”
  • Simplifying the Client Server Build Out Synchronization Time Bulk Data Traffic Shared Nothing High Latency Blades, Clusters,Squadrons HV Read Only Webserving , some DSS Shared Memory Low Medium Latency F6800,rx8400,rp8400 P670, Squadrons ML OLTP, Legacy SMP Shared Memory High Medium Latency F12000,F15000, SuperDome , P690 Data Warehouse, some DSS From: In Search of Clusters, The ongoing battle in lowly parallel comp uting by Greg Pfister , p461 Shared Everything Low Latency zSeries, Squadrons HE OLTP, Mixed Workload Price/Performance Total Capacity WLM & BI Function Virtualization Archit e ctural Divide Blades Midrange Client Server Mainframes Archit e ctural Divide High End UNIX Severs
  •  
  • Workload Characterization 2. I/O Bound – e.g. high I/O content applications 9. Protocol Serving – e.g. static HTTP, firewall, etc. 3. Mixed Low – e.g. multiple, data-intense applications or skewed OLTP, MQ 1 . Data Intensive – large working set and/or high I/O content applications 4. Mixed High – e.g. multiple, cpu-intense simple applications 8. Skewless OTLP – e.g. simple and predictable transaction processing 7. Java Heavy – e.g. cpu intensive java applications 6. Java Light – e.g. data intensive java applications 5. Database – e.g. Oracle DBMS or dynamic HTTP server 10. CPU Intensive – e.g. numerically intensive, etc. I/O Driven CPU Driven
  • Industry Benchmarks TPC-C, TPCE?? Parallel Hell positioning is empirical and folklore driven
  • Workload Considerations
    • Workloads may benefit from being physically close to the data
    • Most servers run in low to medium utilization
    • High I/O workloads Vs. High CPU workloads
    • Workloads may require high availability
      • Mission critical applications
  • Comparing servers using relative capacity : Given system B with capacity C B processing a workload at utilization U B capacity C A needed by system A to process the same workload is given by: where WLF is the Workload Factor. With WLF we try to compensate for all the architectural differences between system A and system B. It is simplified: Actually WLF = f(U B )
  • Parallel Serial Processor Speed Cache RAS Processor Speed Cache RAS Processor Speed Cache RAS
  • Industry Standard Benchmarks
    • System Level
    • Characteristics
    • No disk I/O
    • No network I/O
    • No database
    • Data sharing
    • Global memory
    • Interconnect important
    • Examples
    • SPEC OMPL2001
    • SPEC OMPM2001
    • Component
    • Characteristics
    • No disk I/O
    • No network I/O
    • No database
    • No data sharing
    • Cache / local memory
    • Scales w/QTY of cores
    • Examples
    • SPECint2000
    • SPECint_rate2000/2006
    • SPECfp2000/2006
    • SPECfp_rate2000
    • SPECjbb2000/2005
    • Specialty
    • Characteristics
    • Disk I/O
    • Network I/O
    • No data sharing
    • Local memory
    • Scales w/QTY of cores
    • Examples
    • SPECweb2005
    • NotesBench
    • SPECjAppServer 2004
    • SPECsfs97_R1.v3
    • Database Examples
    • TPC/H (Read Only)
    • SAP SD 2-Tier (Limited I/O)
    • System Level Database
    • Characteristics
    • Disk I/O
    • Network (except batch)
    • Global memory
    • Data sharing
    • Read/Write database
    • Examples
    • TPC/C
    • SAP SD 3-Tier
    • Oracle Apps
    • Oracle RAC
    • Oracle Batch
    • PeopleSoft Financials
    Memory Memory I/O CPU Cache CPU Cache I/O Local Interconnect Memory Memory I/O CPU Cache CPU Cache I/O Local Interconnect Global Interconnect Memory Memory I/O CPU Cache CPU Cache I/O Local Interconnect Memory Memory I/O CPU Cache CPU Cache I/O Local Interconnect Global Interconnect Memory Memory I/O CPU Cache CPU Cache I/O Local Interconnect Memory Memory I/O CPU Cache CPU Cache I/O Local Interconnect Global Interconnect Memory Memory I/O CPU Cache CPU Cache I/O Local Interconnect Memory Memory I/O CPU Cache CPU Cache I/O Local Interconnect Global Interconnect
  • System Design and Benchmarks
    • Industry standard benchmarks are used by vendors to establish performance or price/performance leadership.
      • Benchmarks are chosen to show off a platform not to allow comparisons
    • Benchmarks frequently do not match real customer workloads
      • Small – very limited stress on data delivery infrastructure
      • Throughput oriented with highly paralyzed processing – scales with quantity of processors for all vendors
    • Real workloads (including virtualization and mixed workloads) place tremendous stress on cache and system interconnect.
    Workload / Server Size Data Sharing / Workload Complexity On-Chip Cache Qty of Threads (1-2 Sockets) Any Benchmark Quantity of Cores / threads Parallelization Throughput Results TPC-H SAP SD 2-Tier SPECJBB2005 SPECintRate SPECfpRate SPECweb System Interconnect Cache Architecture Schedulers # of Processors TPC-C SAP SD 3-Tier Interconnect Cache Schedulers # Processors Virtualization Mixed Workload
  • 'White space' = wasted capacity Shared Systems Separate Dedicated Systems
  • Peak and Average
    • The desired peak utilization is the “Utilization at Saturation design point”, Usd
    • Average Utilization is:
    Where: P is the Peak Load A is the Average Load s is the number of servers used to implement the capacity
  • Virtualization enables higher CPU Utilization
    • Single workload model assumptions:
      • Average Utilization: 20.7%
      • Peak: 79%
    • As more copies of this workload are added, average utilization approaches peak
      • 8:1 39% Average, peak 76%
      • 16:1 48% Average, peak 78%
      • 64:1 61% Average, peak 78%
    • As workload is added the number of CPUs required for the work grows at a much lower rate.
  • Why Larger Servers for Virtualization?
    • Hardware Advantages
      • Higher utilization due to shared headroom.
      • More internal bandwidth to improve performance
      • Fewer disk & network adapters and ports
      • Able to share memory more effectively
      • More fault tolerant features
    • People Advantages
      • Fewer servers to order, install, track, maintain, and retire
      • Fewer Hypervisor instances to manage
      • Fewer firmware patches to apply
    • Data Center Advantages
      • Better power utilization
      • Reduced floor space
    Hardware Capacity Usable VM Capacity Smaller Servers Medium Peak to Avg. Utilization Gap Larger Servers Small to Very Small Peak to Avg. Utilization Gap
  • Relative Capacity Criteria
    • What is the number and utilization of servers?
      • How big is this? What is the potential for virtualization or workload management? Need to profile utilization by intervals.
    • How Parallel is the work?
      • Read only partitioned data, mostly read minimum sharing, mostly read shared data, read/write partitioned data, read/write shared data, etc. (Leverage of shared v. partitioned resources)
    • How large are the working sets for the DB, Memory, and Cache?
      • What is the "Workload Factor?" Need throughput v. utilization by intervals
    • What are the testing and QA practices?
      • How much nonproduction hardware is there as a result?
  • Relative capacity (cont’d)
    • Capacity Metric can vary (MIPS, MHz, tpm, tpc-c, n° engines, ...)
    • Utilization (%) can be measured with various tools (vmstat, top, Task Manager, ...)
    • WLF is measured in [ C B ]/[ C A ] units
      • i.e., LSPR values are MIPS/MIPS workload factors for two zSeries machines at same utilization
    • WLF difficult to measure!
      • not enough benchmarks to cover all the cases
      • driven by cache miss rate , which cannot be directly measured
      • “ Cloud of uncertainty” around measured values
  • Ideas International
    • Independent Organization
    • Publishes the Consolidated Analysis Report (CAR)
    • CAR contains the RPE2 performance index
    • RPE2 index can be used into cross-platform selection
    • Requires a License
    • http://www.ideasinternational.com/
    • RPE2 = Relative Performance Estimate 2 ( Copyright © 2008 - Ideas International Limited)
  • Performance Comparison
    • Server Utilization
    • Workload Type
    • I/O Latency
    • Cache
    • Clock Speed
    • Architecture
    • Non-functional requirements
  • Cost is a quantification of Non functional requirements
    • Costs go way beyond Hardware, Software, Maintenance
    • There are different ways to surface them
    • Here is one way to organize things:
      • Cost of outages
      • Prioritization
      • Growth
      • Administration Costs
      • Time to Market v Code Quality
      • Project Costs
      • Environmental Costs
  • A full range of TCO factors considerations – often ignored
    • Integration
      • Integrated Functionality vs. Functionality to be implemented (possibly with 3rd party tools)
      • Balanced System
      • Integration of / into Standards
    • Further Availability Aspects
      • Planned outages
      • Unplanned outages
      • Automated Take Over
      • Uninterrupted Take Over (especially for DB)
      • Workload Management across physical borders
      • Business continuity
      • Availability effects for other applications / projects
      • End User Service
      • End User Productivity
      • Virtualization
    • Skills and Resources
      • Personnel Education
      • Availability of Resources
    • Availability
      • High availability
      • Hours of operation
    • Backup / Restore / Site Recovery
      • Backup
      • Disaster Scenario
      • Restore
      • Effort for Complete Site Recovery
      • SAN effort
    • Infrastructure Cost
      • Space
      • Power
      • Network Infrastructure
      • Storage Infrastructure
    • Additional development and implementation
      • Investment for one platform – reproduction for others
    • Controlling and Accounting
      • Analyzing the systems
      • Cost
    • Operations Effort
      • Monitoring, Operating
      • Problem Determination
      • Server Management Tools
      • Integrated Server Management – Enterprise Wide
    • Security
      • Authentication / Authorization
      • User Administration
      • Data Security
      • Server and OS Security
      • RACF vs. other solutions
    • Deployment and Support
      • System Programming
        • Keeping consistent OS and SW Level
        • Database Effort
      • Middleware
        • SW Maintenance
        • SW Distribution (across firewall)
      • Application
        • Technology Upgrade
        • System Release change without interrupts
    • Operating Concept
      • Development of an operating procedure
      • Feasibility of the developed procedure
      • Automation
    • Resource Utilization and Performance
      • Mixed Workload / Batch
      • Resource Sharing
        • shared nothing vs. shared everything
      • Parallel Sysplex vs. Other Concepts
      • Response Time
      • Performance Management
      • Peak handling / scalability
  • Overview of Techline’s case study SAR Reports Webserver Webserver Webserver Server Consolidation Tool Projected Util. VMXT z/VM zLinux Apache Capacity Tool = Actual Util. ?
  • Platform Choices Legacy Quality of Service Total Cost Application Platform Support Application Structure
  •