Clustering Loading Balancing

Rob Donahue Senior Manager - Business Technology Solutions Performance Engineering

www.odtug.com 1 ODTUG Kaleidoscope 2008

OBJECTIVE

• Discuss the challenges associated with integrating Hyperion with the larger enterprise environment.

• Review some strategies to deploy Hyperion into the enterprise utilizing a scalable architecture.

• Discuss architecting a Hyperion implementation that will support the needs of the business.


IMPLEMENTATION GOALS

• Hyperion System 9 implementations are increasingly being deployed to support enterprise business functions. The goal is then to implement a system in such a way that is scalable & fault tolerant.– Scalable - The ability of a system to adapt to

increased demands without the need for significant reconfiguration or additional investment.

– Fault Tolerant – An architecture which allows the system to continue working even when part of the system infrastructure fails.


IMPLEMENTATION CHALLENGES

• The Hyperion application platform is a complex multi-tiered system that takes careful thought and planning to deploy and manage.

• Hyperion applications support critical business functions within an organization and are no longer seen as ‘departmental solutions’.

• This shift elevates the risk and priority of a Hyperion deployment in a given organization.

• It is important that Hyperion be given the same considerations in its infrastructure as other enterprise class applications such as PeopleSoft or SAP.


INTEGRATING WITH THE ENTERPRISE

• Architecting Hyperion to integrate into the enterprise is more than just building out the physical server infrastructure for production.– It means integrating with an organizations:

• Architecture standards– Infrastructure platforms (HW / OS)– Web Application Server platform (i.e. WebSphere)

• IT process & procedures– Security– Change management– Incident management

• To deliver a robust enterprise implementation it is critical that the enterprise IT group be engaged at the planning phase of the project.

• The IT standards in place within an organization should not be seen as a roadblock to a project, but rather a gatekeeper which helps to ensure the implementations reliability.


PLANNING THE IMPLEMENTATION• When planning for the implementation of Hyperion it is important to not just size and

plan the production environment. A successful implementation plan should document the following for the Development, Test / QA & Production environments:

– Logical Architecture– Projected User population– Integration points within the enterprise– Infrastructure required– Security Model– Change Management

• During the planning phase it is important to understand your organizations IT processes & procedures as it applies to the deploying the Hyperion platform within the enterprise. The Hyperion implementation should adhere to IT standards whenever possible.

– Procedures• Change Management• Incident Management• Security

– Standards• Architecture• Documentation• Design Reviews


INTEGRATING WITH THE ENTERPRISE: TECHNICAL STANDARDS

• It is important to understand your organizations IT standards as it applies to the Hyperion platform. The Hyperion implementation should adhere to IT standards whenever possible.

– Platforms• Server (i.e. UNIX / Windows)• RDBMS (i.e. Oracle / SQL Server)• Web Application Server (i.e. WebSphere / WebLogic)

• This sets the foundation of the implementation to have the best support from the internal experts.

– The application team does not typically have the technical resources required to manage the supporting components of an enterprise application environment.

• Server Administration• RDBMS Administration• Web Administration• Network Administration

– The IT group is better enabled to ensure that the components supporting the Hyperion environment are managed and monitored which frees up the application team to focus on the application.


• IT is in the best position to administer the supporting infrastructure of the Hyperion environment, but not necessarily administer the applications. Therefore it is important to reach a clear understanding on the rights and responsibilities of each team.

– ID / Security Management– Object Migrations– Application administration (i.e. start / stops of application processes,

application upgrades / patches)– Supporting component administration (i.e. start / stop of RDBMS

processes)– Server administration (i.e. start /stop of servers, OS patches)These rights may be different for each environment (i.e. development, test,

production).• Understanding the division of labor in advance will reduce issues

later.

INTEGRATING WITH THE ENTERPRISE: TECHNICAL STANDARDS


• It is critical to engage IT & integrate with the established processes.• Some key process areas to consider are:

– Operational Monitoring – What tools & processes are in place to allow IT to monitor the servers and processes within the environment and alert administrators to problems?

– Incident Management – Is there a defined set of processes for users and application administers & management to identify, track & resolve issues.

– Change Management – Is there a defined set of processes to ensure that changes to the environment are documented & approved before being put into production? This also ensures that user & business impact is understood and communicated before any changes are made.

– ID Administration – How would a new user request access to the environment?• What rights should the user receive?• Which applications does the user need access to?• Who approves the request?• How are users removed from the system?

– Help Desk Integration – Can the central help desk act as the point of contact for end-user issues?

– Desktop / PC support – Can any required desktop software be deployed by the workstation team? (i.e. Excel Add-in)

INTEGRATING WITH THE ENTERPRISE: Process


ARCHITECTING FOR SUCCESS

• As was mentioned earlier Hyperion is a true enterprise application and all the robust functionality that delivers on those critical business functions brings with it complexities that need to be understood.

• The goal when architecting an enterprise solution is to build a model that creates a robust and flexible environment. However the cost of the implementation must be rationalized against the business.

• The Hyperion applications by and large follow a 3-tier architecture model. This means the applications are comprised of components that split across 3 logical tiers:

– Web– Application– Data

• It is important to understand how the Hyperion applications in an implementation are architecture so that they can be deployed along any enterprise architecture standards in place.

• In addition there are some best practices to follow when implementing any enterprise application.


ARCHITECTURE CHALLENGES

• The complexity of the application creates a challenge in designing an architecture that meets the performance & stability needs of the business that is cost effective.

• The architecture needs to create a flexible environment that can be supported once implemented.

• The architecture wherever possible should look to reduce single points of failure and build in fault tolerance & redundancy where possible.


ARCHITECTURE – KEY CONSIDERATIONS

• It is important to gather and agree upon the non-functional requirements to assist in designing the architecture.

– Uptime SLA’s - 24x7 is VERY expensive– Response Time SLA’s– Recovery SLA’s– Data Retention Needs– Data Loss Tolerance

• No individual team or person can design the architecture. It is important to involve others in the design process.

– Supporting IT groups– Implementation Partners– Vendor Experts

• Once an architecture design has been developed it should be formally reviewed & approved by all the teams who will be either building or supporting the environment.


LOAD BALANCING• Allows for ‘horizontal’ scalability• Commonly Used Methods:

– using a load balancer: software load balancer, hardware appliance or a combination.

– using DNS solutions– using NLB network load balancing (Windows specific)

• Hardware Load Balancing– Offers ability to distribute load plus features like HTTP compression,

SSL encryption and better performance– Has its own CPU and hardware resources. Ex: Cisco Smart Switch– Must be configured to ‘sticky sessions’

• Software Load Balancing– Can use a plug-in to web server– Reduced performance when web server is used for SSL and

compression• Not all applications can be load balanced.


• Horizontal vs. Vertical Scalability – Delivers better performance & fault tolerance– It is important to consider building the web and application tiers to be horizontally

scalable through the a farming architecture.• Use multiple smaller servers in these tiers to handle the transactional load.

– Lower cost– Fault tolerance– Redundancy– Reduction in outages for patches / upgrades

• If additional capacity is needed then a server is added to the farm rather than expanding or replacing the server.

– Utilize Web Application Server Clustering when appropriate– When appropriate (both technically and financially) utilize hardware load

balancers.– DNS & Network Load Balancing can be unreliable.– Some Hyperion System 9 components are not suited to a horizontally scalable

model• Shared Services• Essbase Administrative Services• BI+ Core Services

HORIZONTALLY SCALABLE ARCHITECTURE


Data Tier components such as Essbase & the RDBMS metadata repositories tend to be vertically scalable and as such other methods may be utilized to ensure performance and reliability.•N+1 Clusters

– If fault tolerance is needed in a component that cannot be load balanced then a N+1 cluster may be appropriate.

• Active / Passive Cluster Model• Applications & Services can be automatically switched to a passive

stand-by server if needed.• DNS & Storage move dynamically with the cluster so no

reconfiguration of applications is needed following an incident.– Typically requires 3rd party software or additional operating system

components.• Veritas Cluster Manager• Microsoft Clustering

VERTICALLY SCALABLE ARCHITECTURE


• N+1 Clusters require an additional server to serve as the passive stand-by server.

– Best practices suggest the passive stand-by be of the same size and configuration as the other servers in the cluster. This can have significant cost impacts that may offset the benefits.

– Additional care must be done when building the environment to ensure the proper network and storage configurations are utilized.

– Once implemented an N+1 Cluster creates a very stable and flexible environment with many benefits for performance and management.

N+1 CLUSTER ARCHITECTURE


SCALABLE ARCHITECTURE - LOGICAL

Horizontally Scalable Components

Horizontally Scalable Components

Vertically Scalable Components

Vertically Scalable Components


EXAMPLE ARCHITECTURE

• Large scale implementation utilizing:– HW Load Balancing (Cisco

Smart Switch)– Software Load Balancing

(WebSphere Clustering)– N+1 Cluster for Essbase &

Oracle


LOAD BALANCED TRANSACTION FLOW


QUESTIONS

Rob [email protected] Orion PlaceSuite 100Columbus, OH 43240


Clustering Loading Balancing

Documents

Transcript of Clustering Loading Balancing