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


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

http://scn.sap.com/docs/DOC-56525








• Web Tier Deployment

• Intelligence Tier Deployment

• Processing Tier Deployment • System Configuration Wizard Demo

• High Availability and Load Balancing Scenarios

• Q&A

Agenda


• 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


What are the conceptual tiers in a BIPlatform ?






• Q&A

Agenda


Background Need for Web Tier Tuning

XIR2 XI3.1 BI4.0


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





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)

http://scn.sap.com/people/james.rapp/blog/2012/07/12/bi4-admins-get-ready-for-java-7






• Q&A

Agenda


Understanding the Management / Intelligence tier.


Optimizing BI Server Tiers 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.


Optimizing BI Server Tiers 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






• Q&A

Agenda


• 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


• 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


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


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


• 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






• Q&A

Agenda


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


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


Scale Out

BI Cluster

SAN Storage Database Cluster

Default Servers running on all machines


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


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)


SAP BusinessObjects BI 4.1 Upgrade

Webinar Series

BI 4.1 Deployment Best Practices

Q & A

Brought to you by the Customer Experience Group

Technology

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