SAP #BOBJ #BI 4.1 Upgrade Webcast Series 4: BI 4.1 Deployment Best Practices

©2013 SAP AG or an SAP affiliate company. All rights reserved.
1
SAP BusinessObjects BI 4.1 Upgrade Webinar Series
BI 4.1 Deployment Best Practices
Presenter: Harjeet Judge
SAP Customer Experience Group
Brought to you by the Customer Experience Group

2
We bring to you all that you need to successfully upgrade to the SAP BusinessObjects BI Platform 4.1.
You can find a BI 4.1 Upgrade Overview page on SCN at: http://scn.sap.com/docs/DOC- 56525
Webinars also complement these published resources: http://scn.sap.com/docs/DOC- 56308
SAP BusinessObjects BI Platform 4.1 Upgrade Enablement

3
•Web Tier Deployment
•Intelligence Tier Deployment
•Processing Tier Deployment
•System Configuration Wizard Demo
•High Availability and Load Balancing Scenarios
•Q&A
Agenda

4
•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 than 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
Conduct sizing exercise using the Sizing Estimator

5
What are the conceptual tiers in a BIPlatform ?

6
•Q&A
Agenda

7
Background Need for Web Tier Tuning
XIR2
XI3.1
BI4.0

© 2013 SAP AG or an SAP affiliate company. All rights reserved. 8
Optimizing BI Server Tiers
Web Server / Web Tier
BI 4.1
Tomcat 7 + SAP JVM 6
BI 4.1
Apache 2.4 +Tomcat 7 +
JVM 7
~25% or better improvement in delivery of static content
• Improving the User Experience in SAP BI Platform 4.0 with Apache http://scn.sap.com/docs/DOC-6191

9
Optimizing BI Server Tiers Web Application Server (Java)
•The embedded Tomcat web application server now utilizes SAP JVM 1.6.0_37 as of the first release of BI4.1
Tomcat 7 and SAP JVM 1.6.0_37 standard
•As of Java 7, a new garbage collector called the Garbage First Collector (or GC1) is enabled and is optimal for use with multi-CPU servers. You can find details on GC1 as it pertains to BI4.x here.
Java 7 + GC1
•GC1 simplifies garbage collection and can improve performance for java application servers running on multi-core systems
Key Message
•Roadmap for SAPJVM includes plans to update to Java 7. BI4.2?
Key Message
+ Be generous with Tomcat’s memory pool! (configuration)

10
•Q&A
Agenda

11
Understanding the Management / Intelligence tier.

Management/ Intelligence Tier
Central Management Server System Database / Repository
Metadata
Security
Server Info
Key Message: The CMS must have sufficient connections to the system database, else pending
requests are queued, causing degradation in user-response times. Increase up to 50 if poss.

Management/ Intelligence Tier
CMS Objects in Cache
Max objects in cache increased from 10K to 100K default in BI 4.0
Increasing this value corresponds to higher memory consumption
from CMS
Incrementing with System Database sizes larger than 100K objects
may improve CMS performance
-maxobjectsincache 250000

14
•Q&A
Agenda

15
•It 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

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

17
Using the System Configuration Wizard (Demo)
New in 4.1: Wizard performs essential post-install configuration
•Quick way to configure whole system consistently
•Response + log files are generated each run .
•SCW can be invoked in script mode
•Response file can be edited, and rerun using SCW.bat

18
Tailoring specific Services & Applications
•Deploy only one server for Lifecycle Management Service
Most heavy lifting is not handled by this service anyway
•Lifecycle Management Job service deployed in multiple servers
Can scale out for handling more load
•Put Security Token Service (STS) alongside DSL_Bridge for BW SSO.
•Auditing and Monitoring applications can be enable/disabled.
•Build-up scope of Search Index gradually

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

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

21
•Q&A
Agenda

22
•“Scale Up” or “Scale Out”?
•Scaling up has its limits, but machines are too large for single processes anymore
•Putting 5 WEBI servers on a machine might make sense – but 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 than other enterprise software
Homogeneous vs. Heterogeneous Nodes?

23
Single Server Deployments
Web Application Server
BusinessObjects Enterprise servers
FRS Root Folder
Database server hosting CMS system database
Suited for a small organization
Assuming you have proper backup, a disaster may lead to long periods of unavailability.
Trusted disaster recovery and back up strategies are critical to regaining availability.
Vertical Deployment
Web Client

24
Scale Out
BI Cluster
SAN Storage
Database Cluster
Default Servers running on all machines

25
Scale Out Web Server to server static content
Web Server
Serves static content or redirector only
Web Client
BI Server(s)
Web Application Server
Serves dynamic content only

26
Scale Out Web Server to server static content
Web Client
Web Server Farm
Static content or redirector only
Clustered Application Servers (Session Replication)
Business Intelligence Servers
Hardware redirector (Load Balancer)

27
SAP BusinessObjects BI 4.1 Upgrade Webinar Series
BI 4.1 Deployment Best Practices
Q & A
Brought to you by the Customer Experience Group

SAP #BOBJ #BI 4.1 Upgrade Webcast Series 4: BI 4.1 Deployment Best Practices

Recommended

Recommended

More Related Content

More from SAP Analytics

More from SAP Analytics (20)

Recently uploaded

Recently uploaded (20)

SAP #BOBJ #BI 4.1 Upgrade Webcast Series 4: BI 4.1 Deployment Best Practices