Avoid Paying The Virtualization Tax: Deploying Virtualized BI 4.0 The Right Way

Transcription

1 Avoid Paying The Virtualization Tax: Deploying Virtualized BI 4.0 The Right Way Material by Ashish C. Morzaria, Presented by Matthew Shaw,

2 LEARNING POINTS Understanding the Virtualization Tax : What is it, how it affects you How resource sharing is a virtualization tax Findings From SAP virtualization tests in COIL: Why we tested, how we tested What we found, what it means to you Recommendations & Best Practices: How to minimize the virtualization tax you pay Proper (official!) recommendations from SAP

3 SAP s VIRTUALIZATION SUPPORT STATEMENT Virtualization is fully supported by SAP for functionality: All BusinessObjects BI products (includes 3.x and 4.x lines) In most cases, you do not have to reproduce issues on physical systems BUT: The customer is 100% responsible for configuration and performance of the host/hypervisor environment SAP Note : Simplified statement for ALL SAP products - VMware, Hyper-V, and Citrix Xen SAP cannot tell you to configure your system in a specific way under all usage scenarios - (We don t do this in the physical world either).

4 TERMINOLOGY Hypervisor: The bare metal virtualization software running on the host h/w Physical processor: A real processor seated within a socket on a motherboard Core or pcpu (Physical CPU): Physical core (not CPU) in the host system. A dual processor, quad-core system would have 8 pcpus vcpu (Virtual CPU): A virtual core provisioned in a virtual machine and has no mapping or relationship to a physical core or CPU Example: an 8 vcpu VM has eight virtual processors and can be provisioned even on a quad-core host

5 THE VIRTUALIZATION TAX A TAX typically refers to the additional cost w/o benefits: Performance Costs: Performance loss due to resource sharing and hypervisor operations Capital Costs: Additional hardware required (i.e. upgrade SANs, infrastructure) Hardware reuse less likely (newer hardware has tangible benefits) Financial Costs: Server sprawl means more machines to manage Additional training, experience, people required Potentially additional software licensing requirements

6 TAX IMPLICATIONS ON BI SYSTEMS BI is not a typical application to virtualize: Very bursty, very I/O intensive more than ERP! IT teams not familiar with performance profiles of BI systems End users directly feel infrastructure latencies BI systems can grow bigger (and quicker!) than you think: Not uncommon to see BI systems larger than SAP BW systems Scale-out strategy is different than other enterprise applications Most BI teams are not prepared to negotiate effectively: Poor visibility into the infrastructure may not have tools Almost no ability to hold virtualization teams to performance metrics

7 RESOURCES ARE DIVIDED, NOT CREATED Resources are always shared even if you don t see it: Each VM will see its allocated amount but may not actually get it Assumption: not everyone will ask for everything at the same time Without specific promises from the hypervisor: You will get the resource only if it is available If it is shareable (i.e. CPU), you will split it with other contenders If it is not shareable (i.e. RAM), someone will have to swap out With specific promises from the hypervisor: Amount of resource you get based on how well you (or your virtual machine) negotiate

8 RESOURCE SHARING - NORMAL vcpu1 vcpu 2 vcpu1 vcpu2 vcpu1 vcpu2 vcpu1 vcpu2 vcpu3 vcpu4 vcpu 3 vcpu4 vcpu3 vcpu4 vcpu3 vcpu4 VM1 VM2 VM3 VM4 pcpu1 pcpu 2 pcpu1 pcpu 2 pcpu3 pcpu4 pcpu3 pcpu4 VMware vsphere Host

9 RESOURCE SHARING LIGHTLY LOADED vcpu1 vcpu 2 vcpu1 vcpu2 vcpu1 vcpu2 vcpu1 vcpu2 vcpu3 vcpu4 vcpu 3 vcpu4 vcpu3 vcpu4 vcpu3 vcpu4 VM1 VM2 VM3 VM4 pcpu1 pcpu 2 pcpu1 pcpu 2 pcpu3 pcpu4 pcpu3 pcpu4 VMware vsphere Host

10 RESOURCE SHARING HEAVILY LOADED vcpu1 vcpu 2 vcpu1 vcpu2 vcpu1 vcpu2 vcpu1 vcpu2 vcpu3 vcpu4 vcpu 3 vcpu4 vcpu3 vcpu4 vcpu3 vcpu4 VM1 VM2 VM3 VM4 pcpu1 pcpu 2 pcpu1 pcpu 2 pcpu3 pcpu4 pcpu3 pcpu4 VMware vsphere Host

11 VIRTUALIZING SAP BI 4 DEPLOYMENTS

12 THE PROBLEM Many believe BI cannot/should not be virtualized: Customers have had performance problems in the past Inexperience and lack of proper guidance led to misconceptions Existing guidance suggests high virtualization tax: Previous guidance using older versions of VMware vsphere/esx Many published studies are technically flawed (even ones by Business Objects! ) Some guidance is physical is just easier to deploy and support Some guidance can cause additional unnecessary tax: Most SAP guidance is Netweaver-based and inappropriate for BI

13 HYPOTHESIS SAP BI 4 can be virtualized in production with little or no virtualization tax, provided: All hardware and software is configured correctly Computational resources are guaranteed just as in a physical world Default settings are acceptable except for specific vendor recommendations (i.e. no magic settings) Best practices from SAP (for BI) and VMware are followed

14 THE OBJECTIVES 1. Validate the hypothesis and create SAP BI-specific guidance for customers, partners, and SAP AGS: Improve the operation of customer s deployments Provide evidence to help customers with their IT teams 2. Disprove previous internal and external guidance, tests, and publications that supposedly prove unusually large virtualization overhead

15 METHODOLOGY Identical tests on physical and virtual systems Each set of tests repeated three times to ensure consistency Standard deviations calculated to detect anomalies Starting with idle system, add 10 more users every 5 minutes OS, hypervisor, and BI-level measurements continually taken

16 SAP s CO-INNOVATION LAB (COIL)

17 HARDWARE Main Memory 8 DDR3 DIMMs 128G/Node Intel Xeon 5600/ Core 2.66 GHz. 12M Cache 6.4GT High Density 2 Independent DP Nodes 20 DP Nodes Per Enclosure 2 Hot-Plug SSD/HDD Per Node TwinBlade TM SBE-720D/E

18 HARDWARE TEST SETUP Same external systems used for both tests Dedicated network switch Local storage used for BI nodes Physical host configured with RAM size of VM (32 GB)

19 SOFTWARE TEST SETUP Virtualization environment: VMware ESXi 5.1 BI 4 systems (Physical pss10147 and Virtual pss10145) Windows 2008 R2 (64-bit) SAP BI 4.0 SP5 CMS DB (Physical pss10144): Windows 2008 R2 (64-bit) Oracle 11g R2 Reporting DB (Physical pss10143): Windows 2008 R2 (64-bit) Microsoft SQL Server 2008 R2

20 TEST FINDINGS

21 F1: IMPORTANCE OF CONFIGURATION Observations: Virtual system performed better HUH? CPU benchmarked 10% faster than physical I/O performance 10% faster than physical Findings: Improper configuration of hardware due to repurposing Different teams for h/w provisioning and s/w deployment Conclusion: System configuration matters even at the BIOS level It is *very* easy to make a mistake, so be careful before drawing conclusions!

22 F2: SYNTHETIC BENCHMARKS INVALID Observations: Synthetic (non-bi) benchmarks show 10% degradation VMware s tests using SD Benchmark (simulating a full ERP system) shows a 6% degradation (Certifications # and ) SAP BI test suite shows statistically insignificant delta Findings: Profile of BI is different and has more I/O Likely that any virtualization overhead is absorbed waiting for I/O Conclusion: Synthetic benchmarks should not be used at all You should benchmark using representative BI workloads only

23 F3: <80% SIMILAR Observations while CPU < 80%: Average latency between physical and virtual at 90 th percentile was within timing margin of error Throughput of each system at each load level was statistically identical given the margin of error Both systems had similar growth curves for latency and throughput Findings: Physical and virtual have statistically insignificant performance deltas Physical and virtual have similar ramps for throughput and latency Conclusion: Properly configured, virtualized SAP BI 4 systems operate with nearly identical performance characteristics to physical deployments

24 F4: PERFORMANCE DEGRADATION SIMILAR Observations while CPU > 80%: Physical and virtual both start degrading after CPU >80% Virtual system degraded slightly earlier than physical when CPU >80% Systems had similar degradation slopes for throughput and latency Findings: Consequences of overloading BI system severe for physical and virtual Less buffer room for virtual systems (degradation starts sooner) Conclusion: Recommendations that scale-out needs to start at 65% still holds Depriving virtual SAP BI 4 systems of required resources increases the performance consequences of an already overloaded system

25 CONCLUSIONS YES! SAP BI 4 can be virtualized w/o performance penalties: If you follow SAP s scale-out recommendations, little performance delta Throughput and latency profiles similar between virtual & physical Degradation curves are similar (and equally problematic) Severe consequences for misconfiguration or poor planning: Even small configuration mistakes can cost a lot Not guaranteeing resources is a misconfiguration Not scaling out properly is poor planning SAP s recommendation for scale-out at 65% holds true

26 RESERVATIONS, SHARES, AND LIMITS Reservations: Guarantee of a resource for a single or group of virtual machines Example: 8 GB reservation on a 16 GB VM means 8 GB will always be available Shares: Proportion of a resource relative to all other virtual machines on a given host. The proportion is calculated as a VM s share divided by the sum total of all shares given out. Example: 100 shares out of 500 means 20% share of resources Limits: Maximum amount of resource a VM can use regardless of how much has been provisioned Example: 4 GB limit on 8 GB VM = no more than 4 GB can be used

27 BEST PRACTICES & RECOMMENDATIONS

28 BEST PRACTICE RECOMMENDATIONS - 1 Make friends with your IT team: Educate how BI is different than other apps to virtualize Make sure IT knows what you need and why Demonstrating your understanding will add to your credibility Care about the underlying infrastructure: Understand if your infrastructure is oversubscribed Realize that dedicated resources may cost more Ask for monitoring software or performance reports

29 BEST PRACTICE RECOMMENDATIONS - 2 Ignore invalid guidance: Ignore SAP software guidance unless it specifies SAP BI Disregard previous BI virtualization studies Disregard non-sap virtualization recommendations for BI Avoid resource contention where possible: Evaluate I/O paths for all interconnected systems Don t forget to evaluate the systems you connect to! Reserve the resources your system needs! Do not use shares, affinity, limits not what you need Use CPU reservations Use Memory reservations

30 SIZING VIRTUALIZED SAP BI 4 SYSTEMS

31 VIRTUALIZED SAP BI 4 SIZING No virtualization specific sizing adjustments necessary IF: Host and all guests properly configured and provisioned Resource contention is avoided as much as possible Resource reservations are strictly enforced (i.e. CPU, RAM, I/O) Without reservations, ALL sizing exercises are invalid: All sizing assumes full CPU, RAM, and I/O capacity Without CPU reservations, SAPS for a VM can be variable Without RAM reservations, swapping can drastically affect performance The design and architecture of your SAP BI 4 landscape must be properly planned and sized regardless of whether your system is physical or virtual. A poorly architected system will perform poorly even on dedicated physical hardware

32 SIZING RESOURCES Updated June 2013: SAP BI 4 Sizing Companion Guide SAP BI 4 Sizing Estimator Virtualization Specific: Best Practices for Virtualizing SAP BI 4 Deployments Evaluating selected Java best practices for SAP BI 4 vsphere

33 FINAL THOUGHTS

34 THE OTHER TAX - LICENSING How you deploy must be reflected in your licensing: Virtualization rights are described in your licensing agreement Your rights depend on when your contract was signed Ensure you know what yours are contact your SAP representative CPU-based licensing: CPU-based pricing is based on how many physical cores your VMs can execute on You must license a core regardless of if you get to use all of it You can easily multiply licensing costs without CPU reservations Concurrent Session-Based Licensing (CSBL) eliminates this problem CPU reservations are the best way to ensure you have the processing power for each CPU license you have paid for consider this in your justification!

35 KEY LEARNINGS There is no reason to resort to physical deployments if you configure your virtual environment correctly You do care how your systems are provisioned Use SAP s recommendations we ve proven them! (now) Sizing virtual is no different if you follow recommendations Ensure your licensing matches your deployment

36 Thank you Contacts Matthew Shaw BI Architect, Ashish C. Morzaria Sizing Product Owner,