As usage of the SAP® BusinessObjectsTM Business Intelligence (BI) platform increases, maintaining application performance while trying to meet varying levels of demand has become more challenging.
The traditional approach to addressing varying demand on the application is to reserve significant hardware resources, and over-provision the infrastructure to cater to anticipated demand spikes. However, that approach not only requires additional capital for hardware, as well as increased maintenance cost and energy consumption.
To maintain service-level agreements (SLAs), the system should instead adapt dynamically to load changes by providing accurate load monitoring and an on-demand resource provisioning service to the application.
Brocade's ServerIron ADX with Application Resource Broker (ARB) automates on-demand resource provisioning with visibility into application traffic and load level. ARB connects to VMware vCenter through a VMware vSphere client plug-in, performing on-demand provisioning and de-provisioning of virtual machines (VM) based on performance metrics from the ServerIron ADX and VMware vCenter. If a load metric reaches a predefined threshold, ARB communicates with vCenter and with ServerIron ADX to initiate appropriate actions, such as powering on a virtual machine and adding the VM to the load-balancing pool.
Do ARB and BOE get along with each other? Well, we tried them together at SAP Co-Innovation Lab in Palo Alto. A team with experts from Brocade, SAP, and VMware has just jointly performed a proof-of-concept (POC) at COIL to demonstrate the on-demand computing services provided by ARB with a BOE landscape.
For our testing, we set up a layered BOE landscape as described in the following diagram.
The BOE components were deployed as virtual machines and were brought into resource pools managed by Brocade ARB. ARB was configured with rules to bring up or down these VMs based on CPU usage. HP LoadRunner was used to generate load to the system.
We started the testing with only 1 Tomcat servers and 1 CMS server running. As load increases and CPU usage of existing Tomcat VM(s) reached a configurable threshold, additional Tomcat VM was provisioned by ARB and load was distribute to the new VM by ADX, the Brocade load balancer. Similar settings were applied to the CMS server.
Once we reached a peak load and stay there for a while, we started to reduce the load. When CPU usage dropped to the threshold value for de-provisioning, ARB started to remove the VMs one by one until the system had just sufficient capacity to handle the reduced load.
Interested?
Check out a Brocade ARB demo here and see yourself how it works. http://www.sdn.sap.com/irj/scn/elearn?rid=/library/uuid/806cb3d6-d4b8-2d10-5e89-94b896898240
Still want to know more technical details?
The participating companies have just published a joint whitepaper in SDN. Feel free to check the paper out from here http://www.sdn.sap.com/irj/scn/index?rid=/library/uuid/e0096305-8bbd-2d10-beb0-b756ed2b6854#rating
