SAP #BOBJ #BI 4.1 Upgrade Webcast Series 3: BI 4.1 Sizing and Virtualization

3,194 views

Published on

http://spr.ly/BI41_Migration_Webinars - Learn how to develop a good strategy for sizing your SAP BusinessObjects BI 4.1 deployment. Understand why core architectural differences between former BOE XI releases and BI 4.1 mandate new sizing considerations. Find out how to test and tune your BI system before releasing it to your user base. Also, learn about virtualization support and guidelines when deploying to virtual and cloud environments.

• Understand how and where virtualization works well
• Learn how to avoid difficult situations when managing virtualized resources
• Develop a strategy that allows for growth, and talk the same language as your administrators

For more on upgrading to SAP BusinessObjects BI 4.1, visit http://www.sapbusinessobjectsbi.com

Published in: Technology
0 Comments
4 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
3,194
On SlideShare
0
From Embeds
0
Number of Embeds
29
Actions
Shares
0
Downloads
268
Comments
0
Likes
4
Embeds 0
No embeds

No notes for slide

SAP #BOBJ #BI 4.1 Upgrade Webcast Series 3: BI 4.1 Sizing and Virtualization

  1. 1. © 2012 SAP AG. All rights reserved. 1Public SAP BusinessObjects BI 4.1 Upgrade Webinar Series BI 4.1 Sizing and Virtualization Presenter: Carlos Lourenco SAP Customer Experience Group Brought to you by the Customer Experience Group
  2. 2. © 2012 SAP AG. All rights reserved. 2Public We bring to you all that you need to successfully upgrade to the SAP BusinessObjects BI Platform 4.1. On SCN, you can find a BI 4.1 Upgrade Overview and other resources at: http://scn.sap.com/docs/DOC- 56525 Webinars will complement these published resources: http://scn.sap.com/docs/DOC- 56308 SAP BusinessObjects BI Platform 4.1 Upgrade Enablement
  3. 3. © 2012 SAP AG. All rights reserved. 3Public • Building Better BI systems • Developing a strategy • Sizing BI systems • Sizing differences XI 3.1 vs. BI 4.x • (Re)Introducing BI 4.x Sizing Estimator • Testing and Tuning BI systems • Validating your system before releasing to users • Architect for Virtual and environments • How should you deploy differently in these environments? • Key Learning Points Agenda
  4. 4. © 2012 SAP AG. All rights reserved. 4Public • BI is I/O Intensive • Stresses to I/O are even more critical (and harder to measure than CPU/RAM) • Spiky load makes estimation even harder – constant load vs. peak times • Underscores importance of understanding the workload *before* you start • BI is Designed to Use All System Resources • Real enterprise systems are “resource greedy” for performance • No real reason to restrict resource usage on a per system basis. • Throttling outside the machine is done by vLANs, QoS, and Storage Tiering SAP Business Intelligence Considerations
  5. 5. © 2012 SAP AG. All rights reserved. 5Public • Create the initial BI 4.X sizing calculation using the Sizing Estimator • Map out your deployment, creating new nodes or increasing numbers according to Sizing Guide • CMS DB is a key to overall performance and scalability of the entire BI Platform • Methodically build the system out • Start with a small landscape and increase load in 50-200 user steps, add services as needed • Carefully monitor and analyze performance and resource usage across entire landscape • Test, Collect Results, Analyze, Repeat • Modify your deployment architecture as necessary before adding users Developing a strategy for deploying SAP BI The BI Sizing Estimator and the Sizing Guide can be found at: http://scn.sap.com/docs/DOC-33183
  6. 6. © 2012 SAP AG. All rights reserved. 6Public • BI 4 is all 64-bit • BOE 3.1 was designed to squeeze the whole suite within a 32-bit architecture • BI 4 is designed to take advantage of modern hardware and RAM (64-bit addressing) • BI 4 can “stretch out” and is no longer artificially limited for resources • BI 4 is architecturally different from 3.1 • BOE 3.1 was a collection of applications with their own connectivity stacks • BI 4 components share a new common Semantic Layer for data connectivity • BI 4 is designed as a first-class and highly integrated SAP client for BI • BI 4 is bigger because it includes new services and applications • BI 4 is designed for modern infrastructure – don’t expect to run on the same hardware SAP BI 4.x is not a technical upgrade from BOE 3.1 or XI R2
  7. 7. © 2012 SAP AG. All rights reserved. 7Public • Sizing of each service is important • Pay attention to specific recommendations in BI Sizing Guide • Some services have recommended values, limits, or locations • Ex: Java App Server should have a 8 GB heap size and 1000 maximum threads configured • Number and placement of each service is also important • Ex: Keep the Crystal Caching and Processing Services on the same machine • Ex: Analysis OLAP services need one instance for 100 active connections • New in 4.0 – Adaptive Processing Service (APS) • Special service that hosts multiple services • Refer to sizing and admin guides for full list of hosted services • Whitepaper: Best Practices for SAPBO BI 4.0 Adaptive Processing Servers (http://scn.sap.com/docs/DOC-31711) SAP BI 4 Platform Services The BI Sizing Estimator and the Sizing Guide can be found at: http://scn.sap.com/docs/DOC-33183
  8. 8. © 2012 SAP AG. All rights reserved. 8Public • Can host a number of services simultaneously • Out of box configuration has all services in a single APS instance • Default install is to get system “up and running” and configurable for your scenarios • Configured for “small” systems – Dev, Test, Trial, limited deployments • Customers are not expected to go to production without re-configuration • For production, host important services in their own APS • Increased throughput, improved scalability, and better response times • Slightly higher memory consumption due to more service containers (one per APS) • Each service has its own memory and processor requirements: New in SAP BI 4.x: Adaptive Processing Service (APS) The BI Sizing Guide and BI Platform Installation Guide contain detailed technical information on specific services that is critical to configure and size correctly
  9. 9. © 2012 SAP AG. All rights reserved. 9Public • Troubleshooting and getting support is going to be painful • 22 services in one APS makes debugging that APS almost impossible • Typically need to create additional APSes before proceeding with Support • System resources harder to manage – what does a 16 GB process look like? • You may experience non-optimal system behavior • Lack of service isolation can magnify otherwise imperceptive operations • Example: Normal Java garbage collection processes: • Reclamation of freed memory for 22 services is computationally large • JVM may need to focus on collection instead of executing processes • Magnified wait times for the APS can affect entire system performance “What’s wrong with one APS if I have enough RAM?” Proper deployment is not about just “adding up the numbers”, it is about making better decisions based on the numbers you have
  10. 10. © 2012 SAP AG. All rights reserved. 10Public • “Scale Up” or “Scale Out”? • Scaling up has its limits, but machines are too large for single processes • Putting 5 WEBI servers on a machine does not make sense – watch out for bottlenecks (i.e. I/O)! • Requires planning and analysis of your scenarios: • If you schedule Crystal Reports mostly at night, the CR Job/Processing Services may be run on the same machine as the Web Intelligence Server • If CR users are actively analyzing data, putting CR and WEBI on the same server is a bad idea since they are both resource intensive • “Scale out” more of an option than before • Virtualization enables “splitting” a lot easier as there isn’t incremental hardware cost. • Design principles for scale out are no different from other enterprise software Homogeneous vs. Heterogeneous Nodes?
  11. 11. © 2012 SAP AG. All rights reserved. 11Public • Poorly provisioned databases will have an invisible effect • CMS DB latencies have a cascading effect – one BI admins can’t see! • Ensure that each reporting database has I/O path are large enough • I/O bottlenecks – disk and network – have severe effects • Worst thing you can do to an I/O intensive application is to starve it for data • Being on an underperforming file server can starve the BI system • Patch your SAP BW systems – incremental performance gains can be big • Many poorly performing WEBI instances can be traced back to a lack of BW patches • Ensure virtualization hosts can handle aggregate requirements • Putting 5 processing server VMs on one host means the host must have at least 5x the IO capability and 5x the RAM! Role of external systems to deployment
  12. 12. © 2012 SAP AG. All rights reserved. 12Public • Keeping up to date on BI system patching is important • Updates almost always have stability and performance improvements • Do not need to apply every patch, but at least every minor version and evaluate every support pack • Multi-node patching • Not always “fun” – ensure you are orchestrating the patches to minimize downtime • Parallel Patching available as of BI 4.0 SP05 • First, update in parallel all CMS host servers. • Second, update in parallel all non-CMS host servers. Role of maintenance strategy in deployments
  13. 13. © 2012 SAP AG. All rights reserved. 13Public • Processing Power • Do you have enough CPU power? • Are you set to properly scale your systems out? • Are your processes properly distributed across nodes? • Evaluate I/O requirements • Consider reporting databases, inter-node communication, I/O links, etc.. • CMS DB properly provisioned to ensure low latency/high throughput? • DB vendor specific, not part of SAP BI documentation • Memory – do you really have enough? • Nature of application means spikes and dynamic memory allocations Architecting BI Systems Always think about system design – and read the manuals Default systems are just that – the default, not optimal
  14. 14. Sizing BI Systems
  15. 15. © 2012 SAP AG. All rights reserved. 15Public • Sizing Estimator is not a replacement for a real sizing exercise • Results are completely dependent on input parameters • Does not take into account fault-tolerance, clustering, scale out, or topology • “SAPS” (SAP Application Performance Standard) • Hardware independent unit to describe performance of a system • 100 SAPS is the power to handle 2,000 business order line items per hour • SAP Application Benchmarks: http://www.sap.com/campaigns/benchmark/index.epx • “Initial Sizing” is platform-independent • Assumes optimal system parameter settings, standard business scenarios, etc.. Sizing production BI systems
  16. 16. © 2012 SAP AG. All rights reserved. 16Public • Underestimating the complexity of enterprise software • You need to be an IT professional to install enterprise software – BI 4 is no different • Not following SAP’s sizing resources: • Start with the BI 4 Sizing Estimator and the BI 4 Sizing Guide • Use the “BI 4 Sizing Estimator”, not the “Quick Sizer” or a pre-BI 4.x sizer • Sizing Estimator, Sizing Guide, Sizing Consultant, and Validation are ALL required • Underestimating the values within the Estimator • Understand the parameters – if the inputs are wrong, the estimate will be invalid • Plan for headroom to handle peaks in demand – don’t run at 80-100% all the time Challenges in accurately estimating BI workloads
  17. 17. © 2012 SAP AG. All rights reserved. 17Public • Sizing Estimator • Starting point – the outputs are NOT numbers you can blindly deploy with • You have to run load/stress tests to validate system capacity • Tool limitations • Lab tests likely used fewer reports than you will • Does not explicitly cover BW, HANA figures (Re)introducing the BI 4 Sizing Estimator
  18. 18. © 2012 SAP AG. All rights reserved. 18Public • Active users • # of users logged in at the same time (doing something or not) • If this number is not known, consider 10% of total users: • 10,000 users in system x 10% = 1,000 active users • Active concurrent users • # of users generating system load at any one time • If this number is not known, consider 10% of active users: • 1,000 active users x 10% = 100 active concurrent users • 10% is a good rule of thumb • Focused BI systems with targeted users can have a significantly higher ratio (i.e. 40%) • More complicated workflows take more time, increasing % of active concurrent users • Major reason for most BI systems being under provisioned SAP BI 4.x Sizing Estimator Estimating users
  19. 19. © 2012 SAP AG. All rights reserved. 19Public • Report size • Complexity and datasets are documented in the BI Sizing Companion Guide • Critical for proper sizing – default of “all medium” should never be used! • Customers usually underestimate the size of their reports • Difficult for accurate calculations b/c not all “medium” reports are the same • Different products have different report sizes • A large Crystal Report is a different size from a large Dashboard • Look at the BI 4 Sizing Guide for specifics of each report type • Type of user groups/workflows have different report sizes • Difficult to estimate the load generated by a user group – all workflows are different • Customers typically underestimate their user groups • i.e. “Information Consumers” typically generate “Business User” loads SAP BI 4.x Sizing Estimator Report sizing
  20. 20. © 2012 SAP AG. All rights reserved. 20Public • Information Consumers • Typically viewing predefined/static content, very little drilling or filtering on their own • Average of 5 minutes between navigation steps • Business Users (when in doubt, start here!) • Moderate amount of drilling and filtering on their own • Average of 30 seconds between navigation steps • Expert Users • Resource intensive operations including ad-hoc analysis, customization of reports, retrieving large numbers of rows, and heavy client-side filtering • Expert users have longer workflows and each step generates more load than any other group • Average of 10 seconds between steps SAP BI 4.x Sizing Estimator Users categories The purpose of these definitions is to give you a general idea – Focus on how hard the user hits the system, not on the think time.
  21. 21. © 2012 SAP AG. All rights reserved. 21Public • “THE” document you must understand and follow • Deceptively small, but provides specific guidance on specific services • Not intended as a “blueprint” – but look at the examples to make your own choices • Do you know the answers to these? • Why having more than one Crystal Reports Processing Service on a machine is bad? • How many users a single MDAS service can host before you need another one? • Where do you find the SAP BI 4 Sizing Companion Guide? BI 4 Sizing Guide The BI Sizing Estimator and the Sizing Guide can be found at: http://scn.sap.com/docs/DOC-33183
  22. 22. Testing & Tuning
  23. 23. © 2012 SAP AG. All rights reserved. 23Public • Goal: focus on reliability and consistency, then performance: • Reliability: ensure the system is highly available – including fault tolerance, etc. • Consistency: ensure acceptable performance at peak loads • Approach: • Start with a well configured, small system • Capture vital statistics • Gradually scale up the number of users • Analyze the tests using the collected metrics • Make changes and iterate Tuning for Reliability and Consistency
  24. 24. © 2012 SAP AG. All rights reserved. 24Public • Aim for a 60-65% average CPU utilization • That enables peaks to 80-90% w/o setting off data center alerts for high utilization • Systems peaking at 100% will impact user sessions • Emphasizes how important it is to scale slowly so you know what to add • What service in that APS is needing more headroom? • What’s a better use of your resources, another WEBI service or an additional MDAS? • CMS-specific • CMSes are usually on their own machines – add additional CMS hosts at 65% utilization How do I know when to scale? There is no “hard and fast rule” for scale out, but common practice of 80% utilization is completely inappropriate for bursty, I/O heavy applications like BI
  25. 25. © 2012 SAP AG. All rights reserved. 25Public • Be generous with RAM • Java allocates memory in “heaps” which can quickly grab large amounts of RAM • Java garbage collection happens more frequently under memory pressure • Heavy memory pressure can cause swapping at the OS level • Look at “max” usage, not “average” usage • You system must be able to accommodate system requests at peak usage. • Make sure your infrastructure team understands how BI is different • Educate IT team on the resource requirements of BI 4.X What about memory? Business Intelligence is one of the very few applications that does NOT have the performance profile of a “typical enterprise application”
  26. 26. © 2012 SAP AG. All rights reserved. 26Public • Benchmarking tools: • HP Loadrunner: commercial, can simulate 1000’s of users with a handful of machines • Apache JMeter: open source tool that provides graphical analysis of results • Others: use what you know, what you have • What to be careful about • Tests are only as good as the parameters – think time, report size, workflows • Remember to model the correct user profiles (and in correct proportion!) • Test iteratively and regularly – spot issues before users do – especially when virtualized • Can you use SAP’s load testing scripts to run on our own environment? • No – ours are specific standardized to test P&R and not suitable for customers • Each customer has different scenarios, so unlikely our scripts would work for anybody How to test a production deployment?
  27. 27. © 2012 SAP AG. All rights reserved. 27Public Virtualization
  28. 28. © 2012 SAP AG. All rights reserved. 28Public • Virtualization is FULLY supported by SAP • 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: Customer is 100% responsible for configuration and performance of the host environment • SAP Note 1492000 • Simplified statement for ALL SAP products • Supports VMware, Hyper-V, and Citrix Xen SAP’s virtualization support statement It is your responsibility to ensure the hypervisor and your virtual machines are provisioned and optimized correctly – during a Support Incident, SAP likely will not check, and we may never find the performance problem.
  29. 29. © 2012 SAP AG. All rights reserved. 29Public • *ALL* instructions for physical are 100% applicable to virtualized BI • No evidence that deviating from physical tuning within the VM is a good idea • You must properly configure the VM itself and the hypervisor – or it will hurt • Tests with VMware in SAP’s Co-Innovation Lab (COIL) show good results • Virtualization whitepaper specifically for SAP BI • Best practices for running BI 4 in virtualized environment - guidances from COIL projects Deploying SAP BI in a virtualized environment
  30. 30. © 2012 SAP AG. All rights reserved. 30Public • Ensure you will always have access to the resources your system needs • Use “memory reservations” for the full amount – especially true for Java applications • Configure CPU “shares” or “reservations” to ensure your systems get enough power • Do not scale down memory or CPU even if average utilization is low • Work with your Infrastructure Team to understand the bigger landscape • Are other VMs on the same machine jamming the I/O paths from the host? • Are you getting all of the CPU power for the CPU licenses you paid for? Virtualization specific guidelines
  31. 31. © 2012 SAP AG. All rights reserved. 31Public • Well designed systems require a plan, iteration, and testing • “Big bang” deployments rarely work and make it impossible to find bottlenecks • Modify your design to account for product or usage specific idiosyncrasies • Sizing BI systems • BI 4.x is a generational shift from 3.1 – don’t underestimate the new requirements • Administrators almost always underestimate user types, report sizes, and workflows • Sizing Estimator, Sizing Guide, Sizing Consultant, and Validation are ALL required • Architecting for virtual and Cloud environments • ALL design principles for physical are valid in virtual and Cloud environments Key Learning Points
  32. 32. © 2012 SAP AG. All rights reserved. 32Public SAP BusinessObjects BI 4.1 Upgrade Webinar Series BI 4.1 Sizing and Virtualization Q & A Brought to you by the Customer Experience Group
  33. 33. Thank you Carlos Lourenco Customer Experience Group carlos.lourenco@sap.com
  34. 34. © 2012 SAP AG. All rights reserved. 34Public © 2012 SAP AG. All rights reserved. No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG. The information contained herein may be changed without prior notice. Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors. Microsoft, Windows, Excel, Outlook, PowerPoint, Silverlight, and Visual Studio are registered trademarks of Microsoft Corporation. IBM, DB2, DB2 Universal Database, System i, System i5, System p, System p5, System x, System z, System z10, z10, z/VM, z/OS, OS/390, zEnterprise, PowerVM, Power Architecture, Power Systems, POWER7, POWER6+, POWER6, POWER, PowerHA, pureScale, PowerPC, BladeCenter, System Storage, Storwize, XIV, GPFS, HACMP, RETAIN, DB2 Connect, RACF, Redbooks, OS/2, AIX, Intelligent Miner, WebSphere, Tivoli, Informix, and Smarter Planet are trademarks or registered trademarks of IBM Corporation. Linux is the registered trademark of Linus Torvalds in the United States and other countries. Adobe, the Adobe logo, Acrobat, PostScript, and Reader are trademarks or registered trademarks of Adobe Systems Incorporated in the United States and other countries. Oracle and Java are registered trademarks of Oracle and its affiliates. UNIX, X/Open, OSF/1, and Motif are registered trademarks of the Open Group. Citrix, ICA, Program Neighborhood, MetaFrame, WinFrame, VideoFrame, and MultiWin are trademarks or registered trademarks of Citrix Systems Inc. HTML, XML, XHTML, and W3C are trademarks or registered trademarks of W3C®, World Wide Web Consortium, Massachusetts Institute of Technology. Apple, App Store, iBooks, iPad, iPhone, iPhoto, iPod, iTunes, Multi-Touch, Objective-C, Retina, Safari, Siri, and Xcode are trademarks or registered trademarks of Apple Inc. IOS is a registered trademark of Cisco Systems Inc. RIM, BlackBerry, BBM, BlackBerry Curve, BlackBerry Bold, BlackBerry Pearl, BlackBerry Torch, BlackBerry Storm, BlackBerry Storm2, BlackBerry PlayBook, and BlackBerry App World are trademarks or registered trademarks of Research in Motion Limited. Google App Engine, Google Apps, Google Checkout, Google Data API, Google Maps, Google Mobile Ads, Google Mobile Updater, Google Mobile, Google Store, Google Sync, Google Updater, Google Voice, Google Mail, Gmail, YouTube, Dalvik and Android are trademarks or registered trademarks of Google Inc. INTERMEC is a registered trademark of Intermec Technologies Corporation. Wi-Fi is a registered trademark of Wi-Fi Alliance. Bluetooth is a registered trademark of Bluetooth SIG Inc. Motorola is a registered trademark of Motorola Trademark Holdings LLC. Computop is a registered trademark of Computop Wirtschaftsinformatik GmbH. SAP, R/3, SAP NetWeaver, Duet, PartnerEdge, ByDesign, SAP BusinessObjects Explorer, StreamWork, SAP HANA, and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and other countries. Business Objects and the Business Objects logo, BusinessObjects, Crystal Reports, Crystal Decisions, Web Intelligence, Xcelsius, and other Business Objects products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of Business Objects Software Ltd. Business Objects is an SAP company. Sybase and Adaptive Server, iAnywhere, Sybase 365, SQL Anywhere, and other Sybase products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of Sybase Inc. Sybase is an SAP company. Crossgate, m@gic EDDY, B2B 360°, and B2B 360° Services are registered trademarks of Crossgate AG in Germany and other countries. Crossgate is an SAP company. All other product and service names mentioned are the trademarks of their respective companies. Data contained in this document serves informational purposes only. National product specifications may vary. The information in this document is proprietary to SAP. No part of this document may be reproduced, copied, or transmitted in any form or for any purpose without the express prior written permission of SAP AG.

×