A High Availability (HA) architecture is one of the key requirements for any Enterprise Deployment. It refers to the ability of users to access a system without loss of service. Deploying a High Availability system minimizes the time when the system is down or unavailable and maximizes the time when it is running or available. This section provides an overview of high availability from a problem-solution perspective.
High Availability (HA) preparation is an integral part of contingency planning. This document serves as a reference document for the preparation of specific High Availability (HA) architecture. It explains how a standard OFSAA deployment should be architected to protect its applications from unplanned downtime and minimize planned downtime.
Topics:
· Approach
The objective of this document is to establish a process to configure OFSAA instance deployment for High Availability (HA).
NOTE:
This document does not apply to set up a Disaster Recovery (DR) instance. It should be used to ensure service continuity through the maintenance of an additional instance.
This document is prepared after considering the below assumptions:
1. A Load Balancer (software or hardware) is identified and installed.
2. An appropriate backup strategy for OFSAA File System ($FIC_HOME and FTPSHARE) and Oracle Database (or Databases) is (or are) already installed and configured.
3. Installation of the OFSAA platform and applications on the primary node is completed and set up is working.
4. A secondary instance (node) for OFSAA is identified and configured with appropriate prerequisite software. No installation of OFSAA products is required at this stage.
5. Hardware configurations (in terms of RAM, CPU, and CORE) do not vary between the OFSAA primary and secondary nodes.
6. It is also mandatory that the file system references such as the OS mount and directories, web application server profiles, domains, deployed paths, and so on are the same between the primary and secondary nodes.
1. The OFSAA instance (or instances) configuration is in ACTIVE-PASSIVE mode. Due to the architectural limitations of the OFSAA platform, the OFSAA components (processing layer) cannot be configured for ACTIVE-ACTIVE mode. However, the web and database tiers can be configured for ACTIVE-ACTIVE mode.
NOTE:
This document does not apply to set up a Disaster Recovery (DR) instance. It should be used to ensure service continuity through the maintenance of an additional instance.Though OFSAA instance (or instances) configuration is in ACTIVE-PASSIVE mode, OFSAA allows Distributed Activation Manager (AM) based Batch Processing from v8.0.5.0.0 onwards, to configure AM engines to run on multiple OFSAA nodes. For more information, see Distributed Activation Manager (AM) based Batch Processing section in the OFS Analytical Applications Infrastructure Administration Guide.
2. This document does not consider any particular OFSAA Application specific configuration. It documents the generic configuration across the platform that is generally applicable for the application stack deployed on top of it.
3. This document does not consider the reporting layer HA configuration. For example, the OBIEE server.
4. This document considers HA configuration only against Oracle WebLogic Server and (or) IBM WebSphere Application Server.
There are many ways to devise the HA architecture based on the requirements, but the following is the recommended approach (to be used as reference) to devise any further changes or modifications to the architecture as per the use cases.
Let us consider the following OFSAA deployment architecture for HA configuration as the end state.
Figure 1: OFSAA deployment architecture for HA configuration as the end state
In this illustration, the HA setup is proposed to be ACTIVE-ACTIVE configuration at the HTTP Server, Web Application Server, and Database or HDFS layers. The OFSAA layer is configured for ACTIVE-PASSIVE configuration.
NOTE:
Access to OFSAA applications is provided using the Global Load Balancer IP or hostname (Virtual IP). In the event of a primary node failure, the access to the secondary node is seamless, requiring no changes to the configuration information across all tiers.
Session Affinity or Sticky Session is configured at the HTTP Server level.
At any time, OFSAA patch installations should be performed only on an active node. Promotions of patches to a passive node are taken care of as part of the sync-up process for File System components.
HA configuration for HDFS should be created after referring to the HDFS vendor-specific documentation. This document does not describe any details about HA configuration for HDFS.