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

© 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

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

• 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

• 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

• 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

• 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

• 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

• 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

• 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

• “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?

• 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

• 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

• 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

• 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

• 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

• 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

• 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

• 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
Report sizing

• 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
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.

• “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

• 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

• 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

• 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”

• 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?

Virtualization

• 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.

• *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

• 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

• 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

SAP BusinessObjects BI 4.1 Upgrade
Webinar Series
BI 4.1 Sizing and Virtualization
Q & A
Brought to you by the Customer Experience Group

Thank you
Carlos Lourenco
Customer Experience Group
carlos.lourenco@sap.com

© 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.

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

More Related Content

What's hot (20)

Similar to SAP #BOBJ #BI 4.1 Upgrade Webcast Series 3: BI 4.1 Sizing and Virtualization (20)

More from SAP Analytics (20)

Recently uploaded (20)

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