Hyperion Enterprise Performance Management System Installation and Configuration Guide Release 11.1.1.2 (252 Pages) and Oracle Hyperion Enterprise Performance Management System Manual Deployment Guide Release 11.1.1.2 (160 Pages) are a wealth of knowledge. I know because I have read a great deal of it and keep them quite close during each engagement. Most of what you need to know is available in the documentation and a good deal of additional knowledge can be found on the support forums. I do not want to rehash the specifics of the installation and configuration. There are just too many variables to cover everything without reposting most of the already prepared material. What I hope to provide here is just a primer on architecture considerations and general installation activities with this release.
The Hyperion architecture establishment and installation activities in our organization cover the following five areas.
- Defining an Architecture – Work with the client to define the hardware, software, and the distribution of Hyperion components
- Provide Pre-Installation Requirements – Provide the client with a detailed list of activities prior to the installation
- Installation – Running the installation and configuration utilities
- Validation – Perform all functional activities necessary to validate the environment readiness
- Documentation – Provide the client with all the details of the environment as it is configured.
In this post, I will go through step 1 that you, as the Hyperion architect, should deliver. Steps 2-5 will be available in the coming weeks. For the sake of simplicity I will be using the example of a common installation, primarily Hyperion Planning, Hyperion Financial Management (HFM), and the core BI applications.
Defining the architecture is somewhat difficult, especially if you do not have a good understanding of your organizations’ usage patterns or platform preferences. Below are the core questions that need to be answered to define the necessary architecture.
How many servers will be needed?
The number of servers depends on a lot of things. Below is a sample of some of the questions I typically ask when recommending the server infrastructure.
- How many users do you have?
- Will you be leveraging an existing Relational Database Platform?
- What products did you purchase?
- What products do your users use most frequently?
- Will you be using loadbalancing?
Let’s assume the answer is 100 users, the client has an existing Oracle database I can leverage, the client purchased HFM and Planning, and the client uses a lot of Financial Reports.
With these assumptions, you will want to make sure the Workspace and Reporting platforms are a decent size and the reporting application services reside on a separate server from the application servers. In addition, since you are going to leverage an existing relational database, you can plan on having a stand-alone data tier for Planning and Essbase. Just to further simplify the matter, let’s assume there is no load balancing and clustering. For our example discussion, I will assume 3 servers will be included in the architecture.
What would be the system specifications and Operating System?
Once again, the answer to this question can vary widely based on the answers below.
- What operating systems does your organization support?
- How long do you intend to use this hardware?
- Will you be using virtual machines?
- Will you be using shared or local disks?
- How much data do you have now and what does your growth look like?
Keep in mind that HFM requires a Windows Server so I will need at least one of those. It may be simpler from an administrative perspective to have a homogeneous OS infrastructure but it is not necessary. If you have no preference, this is what I would typically go with. If you have a propensity for some flavor of UNIX, then I would go that route where applicable. Many organizations keep hardware in place for up to 3 years. With that in mind, I think the best approach is to buy the most robust and powerful hardware you can afford. The cost of migrating in 24 months will often be greater than the hardware spend. VMware is quickly growing in popularity and I see deployments in virtual environments quite often with success. Although Essbase does not require a physical server, I recommend that it not reside on virtual machines due to higher disk I/O. It is also the application that is expecting the most growth.
What Web Application Server should we use? Should it be Oracle Application Server 10g, WebSphere, WebLogic, or the Embedded Java container (Apache Tomcat 5.5.17)?
- What does your organization support?
- Do you have a license for anything?
- Will you need clustering?
First, some comments in favor of the Apache Tomcat server. It is free and Hyperion does do some development on that platform. So far, I have found it to be stable in most situations. If your organization has a Web Application group, it may not be standardized on a version that is required by Hyperion. In these instances, it may make sense to deploy Tomcat as opposed to a version of WebLogic or WebSphere that your organization does not support. Additionally, if the organization is upgrading its application server farm in the future, Hyperion may be an outlier.
Now for the downside, there isn’t really any help desk you can call for Tomcat outside of Hyperion. Unless your organization has a few other Tomcat servers, there is likely to be a learning curve in the administration and support. Then, there is always the question of scalability. Clustering with Tomcat is quite a bit more complex. Our common recommendation on application servers is that you should use what you know. If you do not know anything about application server administration and do not have a huge user base, Tomcat is probably your best choice due to its ease of installation.
One rule of thumb is that you can expect a single Tomcat instance to handle 25-30 concurrent threads comfortably. The practical maximum is 50 per instance. If you are using other sorts of Java servers, it is a good idea to review with those administrators their experience with free servers. In a development environment, one could benchmark how Hyperion EAR and WAR files behave in comparison to those of other Java apps.
With all these assumptions, I deliver a Viso diagram detailing which components go on which servers with general recommendations for server sizing and operating systems.
In our 2nd installment, I will review the pre-installation activates that need to occur before the installation begins.