Hyperion Deployment Topology HA

  • Upload
    joe

  • View
    12

  • Download
    0

Embed Size (px)

DESCRIPTION

Hyperion clustering

Citation preview

High Availability Hyperion- SettingsPrepared by: Jeff Tantleff / Nareshkumar JayaveluKPI PartnersDescriptionThis document outlines HA Practices and standards for multi-tenant connections (distributed) approach to performance tune Presentation, Application layers.Revision LogDateAuthorChange MadeImpact

01/13/2016Jeff TantleffInitial SettingsBest practice for hyperion components

EPM Deployment Topology HAAs EPM usage reaches global users, implementing Oracle EPM in a highly available fashion is becoming a major part of infrastructure planning. Lets go through a couple of key considerations when considering High Availability for your organization.The first question I ask clients is if they really need it. I find that sometimes IT organizations are trying to start implementing load balancing and H/A as part of a corporate standard or some made up Sarbanes Oxley requirement. In reality, in many cases unplanned downtime, although obviously not welcome, can be tolerated in organizations in the event of a catastrophic hardware failure.The best bet is to work with the Finance to truly understand their availability times. Then, take a look at your backup/recovery plan, and your hardware vendor agreements for on-site emergency part replacement. Some clients have a 2-hour guarantee field replacement by their hardware vendor, and even full replacement parts on-site. Think of all the scenarios of unplanned downtime and apply a probability to it to accurately assess the total risk of a non-redundant implementation.If that does not make you take pause think cost. A highly available installation will double your hardware cost and almost triple your implementation time. There also could be additional licensing costs associated with redundant components.If after all of that and you decide that H/A is mandatory in your organization, go for it! But beware do not try this at home. A Highly available installation should only be performed by an Oracle Certified infrastructure partner.The biggest change in Oracles stance for high availably in version 11 is the dropped support for all 3rd party clustering solutions such as Veritas Cluster Server and Microsoft Cluster Server. which is quite unfortunate. The only supported clustering methodology is Oracle Clusterware. This is really bad news for those IT shops that already have an older system deployed on a different clustering technology. It also is especially frustrating because Oracle Clusterware requires the use of Oracle Cluster File System (OCFS) for shared disk resources.which on windows can take 5 minutes to failover. Nice.TerminologyFirst lets talk terminology, at least how I will define these terms for the use of this posting.High Availability

The ability to continue to provide computing resources in the event of a fatal hardware failure.

Cluster

Two or more linked machines that are used for Load Balancing and/or failover of services for high availability

Load Balancing

Distributing requests among multiple applications servers to evenly distribute load. Many times a Load Balancer is used as the single entry point and it will distribute requests based on load of the individual servers or in a simple round-robin fashion. The nice thing about load balancing, is that most of the time, you also get High Availability.Failover

The ability to automatically switch services to a standby server if the primary server fails.Notes on EssbaseSure if you look at the High Availability support matrix, Oracle is happy to say that Essbase can be clustered and Load Balanced. But look closely that is in read only mode only. While there are a few situations a read-only Essbase cluster makes senses for an organization, I almost always see this limitation making the Essbase cluster solution useless. It certainly will not work for Planning.To make matters worse, Oracle will not support 3rd party clustering of any kind on Essbase not even Oracle Clusterware. While this is supposed to be address in the next release in Sept/Nov, it leaves us little choice on the Essbase layer.Our options are to: Do it anyway. But just know that if Oracle determines that a support issue is related to the cluster, they have every right to insist that you demonstrate the issue without it in the mix before they will take responsibility. However, for most behavioral or performance issues that you would call support about, Oracle should not know or even care that your Essbase is running on top of a cluster.

Do an active / Cold stand-by. In essence have a powered-off machine configured with the same hostname/IP address connected to the same shared disk resource as the active machine. Upon failure, there will be a manual process of shutting down the active server (if needed), dismounting the disk resource, starting up the cold server, mounting the disk resource, and bringing services online.

Oracle recommends that you set up a base deployment with one server for each component, validate that it is working, and then scale out each component, depending on your high-availability and system-load requirements.

Deployment Directory Structure and Location Reference

The following illustration shows the enterprise deployment directory structure on each server. Binaries and configuration files for each EPM System component are located only on the server on which the component is installed. For example, Oracle Essbase binaries and configuration files, along with Essbase data directory (not shown in the illustration), are located on the Essbase host machine (ESSHOST1 in the deployment diagram).

Data directories of EPM System products other than Essbase are located on a shared disk that must be accessible from all the servers in the deployment. Because EPM System components are not installed on the shared disk, the shared disk does not have the directory structure depicted in the illustration. The shared disk hosts data directories for: Oracle Hyperion Reporting and Analysis Repository directory Exported or imported artifacts using Oracle Hyperion Enterprise Performance Management System Lifecycle ManagementThis document refers to the following installation and deployment locations: MIDDLEWARE_HOMErefers to the location of middleware components such as Oracle WebLogic Server, Oracle HTTP Server, Java, and, optionally, oneEPM_ORACLE_HOMEor more. TheMIDDLEWARE_HOMEis defined during EPM System product installation. The defaultMIDDLEWARE_HOMEdirectory isOracle/Middleware. EPM_ORACLE_HOMErefers to the installation directory containing the files required to support EPM System products.EPM_ORACLE_HOMEresides withinMIDDLEWARE_HOME. The defaultEPM_ORACLE_HOMEisMIDDLEWARE_HOME/EPMSystem11R1; for example,Oracle/Middleware/EPMSystem11R1. EPM_ORACLE_INSTANCEdenotes a location that is defined during the configuration process where some products deploy components. The default location isEPM_ORACLE_INSTANCEisMIDDLEWARE_HOME/user_projects/empsystem1; for example,Oracle/Middleware/user_projects/empsystem1. WEBLOGIC_DOMAIN_HOMErefers to the directory that contains the WebLogic Server domain configuration for EPM System.

Deployment Approach

Oracle recommends a modular deployment approach, depicted in the following illustration, to facilitate the verification of each EPM System component.

This approach simplifies troubleshooting during the setup process and facilitates configuration.The tasks that must be performed to complete each module in this deployment process are discussed in this document.

Deployment Scenarios

Before starting the EPM System setup process, you must complete the required server, database, and network setup process appropriate for your deployment strategy. EPM System Deployment ScenariosScenarioDeployment Instructions to Use

Set up base working environments

Set Up Oracle Hyperion Planning Installing and Configuring Foundation Services on FNDHOST1 Installing and Configuring Planning on PLANHOST1 Installing and Configuring Essbase Server on ESSHOST1

Set Up Consolidation Installing and Configuring Foundation Services on FNDHOST1 Installing and Configuring Financial Management Server on HFMHOST1 Installing and Configuring Financial Management Web Application on HFMWEBHOST1 Installing and Configuring FDM on FDMHOST1

Add products to an existing environment

Add Consolidation to Planning Installing and Configuring Financial Management Server on HFMHOST1 Installing and Configuring Financial Management Web Application on HFMWEBHOST1 Installing and Configuring FDM on FDMHOST1

Add Planning to Consolidation Installing and Configuring Planning on PLANHOST1 Installing and Configuring Essbase Server on ESSHOST1

Minimum Server SpecificationsTheStandard Deployment Topologyuses these servers, which have the Microsoft Windows 2008 R2 operating system installed. The server names indicated in this table are used throughout this document to identify specific servers involved in the deployment. Minimum Server Specifications for Standard DeploymentEPM System ComponentMachineProcessorMemory

Oracle Hyperion Foundation ServicesFNDHOST14 core 2 CPU16 GB

PlanningPLANHOST14 core 2 CPU12 GB

EssbaseESSHOST14 core 2 CPU16 GB

Oracle Hyperion Financial Management ServerHFMHOST14 core 2 CPU16 GB

Financial Management WebHFMWEBHOST14 core 2 CPU12 GB

Oracle Hyperion Financial Data Quality Management ServerFDMHOST14 core 2 CPU16 GB

User Access ControlDisable User Access Control (UAC) on each deployment server. To disable UAC:1. SelectStart, thenControl Panel, thenUser Accounts, thenUser Accounts, and thenChange User Account Control settings.2. In User Account Control Settings, ensure that the slider is set toNever Notify.

Deployment User Requirements

All EPM System components should be installed from a generic Windows user account (an account that does not belong to a specific user). All patches for this deployment must be run using the user account that was used to install EPM System.The deployment user account is referred to as thedeployment accountin this document. This user account should satisfy the following requirements: The deployment account is a member of the Administrators group on the server. User account control is disabled for the deployment account.2. Act as part of the operating system2. The following local security policies are assigned to the deployment account:2. Bypass traverse checking2. Log on as a batch job2. Log on as a service1. To view local security policy assignments on a server, selectStart, thenAdministrative Tools, thenLocal Security Policy, thenLocal Policies, and thenUser Rights Assignment.

Shared File System Requirements

A shared file system that is accessible from all the servers in the deployment is required to host these components: . Installation files. Reporting and Analysis Repository data. Artifacts for Lifecycle Management in Oracle Hyperion Shared Services. Data directory for FDM applications

The shared file system could be a share on a NAS/SAN or on one of the Windows servers. The deployment account must have read-write access to the shared file system. In the rest of this document, this shared location is referred to as\\SharedHost\SharedLocation.Host Name Resolution Requirements

The canonical host name of each server must be the same when accessed from within the server and from other servers in the deployment.You may want to create a local hosts file on each server to resolve host name issues.

EPM System uses Javas canonical host name resolution for resolving host names. To validate host names as resolved by Java, EPM System provides a utility (epmsys_hostname.bat. An archive of the utility (epmsys_hostname.zip) is available in the directory where you unzip the part numbers to install EPM System. See Downloading and Extracting EPM System Software for instructions.

Clock Synchronization

The clock on each server must be synchronized to within one second difference. To synchronize clocks, point each server to the same network time server.

Environment Details

Use this section to record the details for your environment.