DR Architecture: Multiple Regions

In this architecture, the web tier, application tier, and database tier are deployed in a region that's designated as the primary (active) site. A redundant topology is deployed as a standby (non-active) site in a remote region.

The primary and standby topologies in this architecture are symmetric; that is, both the topologies provide identical compute and storage capacity. If the primary topology is unavailable for any reason, you can recover the application in the remote region. A global DNS resolver directs HTTPS requests from external users, such as users of Hyperion Financial Reporting Web Studio, to the internet gateway attached to the VCN in the region that's currently active.

In the event of a failover or switchback, any incomplete tasks in the previously running environment must be resubmitted by the users.

Use logical host names for the databases and the application instances. To reduce the effort for reconfiguring instances during a failover or switchback, use the same logical host names in the primary and standby environments.

Description of the illustration hyperion-multi-region.png

The components in this multi-tier architecture are distributed symmetrically across two regions. Within each region, the resources are deployed in a single availability domain. The resources in each tier are isolated at the network level in separate subnets.

The VCNs in the two regions are peered, enabling traffic between the remote regions to use a private network backbone, bypassing the public internet.

The topology in the primary region contains the following resources. The topology in the standby region is a non-active replica of the primary topology.

• Bastion Host

  The bastion host is a compute instance that serves as a secure, controlled entry point to the topology from outside the cloud.

  The bastion host is provisioned typically in a DMZ. It enables you to protect sensitive resources by placing them in private networks that can't be accessed directly from outside the cloud. The topology has a single, known entry point that you can monitor and audit regularly. So you avoid exposing the more sensitive components of the topology, without compromising access to them.

  The bastion host in this architecture is attached to a public subnet and has a public IP address. Connections to the bastion host from administrators outside the cloud flow through the internet gateway attached to the VCN. You can configure an ingress security rule to allow SSH connections to the bastion host from the public internet. To provide an additional level of security, you can limit SSH access to the bastion host from only a specific block of IP addresses.

  You can access compute instances in private subnets through the bastion host. Enable ssh-agent forwarding, which allows you to connect to the bastion host, and then access the next server by forwarding the credentials from your local computer.

  You can also access the instances in the private subnet by using dynamic SSH tunneling. The dynamic tunnel provides a SOCKS proxy on the local port; but the connections originate from the remote host.

• Public Load Balancer
  HTTPS requests from external users, such as users of Hyperion Financial Reporting Web Studio, flow through the internet gateway that's attached to the VCN in currently active region. The requests then pass through the global Oracle Cloud Infrastructure Web Application Firewall (WAF) service, which protects the applications from malicious and unwanted internet traffic. Traffic that passes the WAF rules is forwarded to the public load balancer. The load balancer terminates SSL/TSL, and distributes HTTP requests to the private web tier.

  Note:

  To ensure domain resolution of your application endpoints, you should register the IP address of the public load balancer in your public DNS.
• Private Load Balancer
  Traffic from your internal and on-premises users flows through IPSec VPN tunnels or FastConnect virtual circuits to the dynamic routing gateway (DRG) that's attached to the VCN. A private load balancer intercepts the requests and distributes them to the private web tier.

  Note:

  To ensure domain resolution of your application endpoints, you should register the IP address of the private load balancer in your on-premises DNS.
• Web Tier

  The web tier is hosted on a compute instance that's attached to a private subnet.

• Application Tier

  The application tier includes compute instances for the following Hyperion components. (The abbreviations in parentheses are the labels used for these components in the architecture diagram.)

  • Oracle Hyperion Financial Data Quality Management, Enterprise Edition (FDMEE)

    A packaged solution that helps finance users develop standardized financial data management processes by using a web-based guided workflow.

  • Oracle Hyperion Financial Management (HFM)

    A multidimensional online analytical processing server on RDBMS that provides an environment for web-based consolidation, tax provision, QMR, JSK applications.

    The application delivers global financial consolidation, reporting, and analysis in a single, highly scalable software solution.

  • Oracle Hyperion Planning

    A centralized, Excel and web-based planning, budgeting, and forecasting solution that integrates financial and operational planning processes and improves business predictability.

  • Oracle Essbase

    An online analytical processing (OLAP) server that provides an environment for deploying prepackaged applications or developing custom applications.

  • Oracle Hyperion Tax Provision (HTP)

    A comprehensive global tax provision solution for multinational companies reporting under US GAAP or IFRS.

    The application encompasses all the stages of the corporate tax provision process, including tax automation, data collection, tax provision calculation, return-to-accrual automation, and tax reporting and analysis. The application is built using Oracle Hyperion Financial Management, and it leverages all the functionality provided by Financial Management.

  • Oracle Hyperion Strategic Finance

    A financial forecasting and modeling solution with on-the-fly scenario analysis and modeling capabilities, which helps you quickly model and evaluate financial scenarios, and offers out of the box treasury capabilities for sophisticated debt and capital structure management.

  • Oracle Hyperion Profitability and Cost Management

    An application that provides actionable insights, by discovering drivers of cost and profitability, empowering users with visibility and flexibility, and improving resource alignment.

  • Oracle Hyperion Foundation Services

    Common infrastructure components that enable you to install and configure all the modules of the Enterprise Performance Management system; and to manage users, security, metadata, and the life cycle of the applications.

    Foundation Services are necessary regardless of whether you want to deploy Hyperion Financial Management, or Hyperion Planning, or both.

  All the compute instances in the application tier are attached to a private subnet. So, the applications are isolated at the network level from all the other resources in the topology, and they are shielded from unauthorized network access.

  • The NAT gateway enables the private compute instances in the application tier to access hosts outside the cloud (for example, to download application patches or for any external integrations). Through the NAT gateway, the compute instances in the private subnet can initiate connections to the internet and receive responses, but won’t receive any inbound connections initiated from hosts on the internet.
  • The service gateway enables the private Oracle Linux compute instances in the application tier to access a Yum server within the region to get operating-system updates and additional packages.
  • The service gateway also enables you to backup the applications to Oracle Cloud Infrastructure Object Storage within the region, without traversing the public internet.

  To replicate the data stored in the block volumes attached to the application instances, you can take backups of the volumes, copy the backups to the remote region, and then use those backups to restore the volumes in the remote region.

  The components in the application tier have access to shared Oracle Cloud Infrastructure File Storage, for storing shared binaries and data generated by Hyperion applications.

  You can use rsync to synchronize the data from the file system in the primary availability domain to the file system in the standby availability domain.

• Database Tier

  The database tier in each region contains two databases: one for Hyperion Foundation Services, and the other for the Enterprise Performance Management applications.

  • For each database, a standby database is provisioned in the remote region. You can use Oracle Data Guard in asynchronous mode to synchronize the two databases and to fail over or switch back between the two databases.
  • The databases are attached to a separate private subnet. So, the databases are isolated at the network level from all the other resources in the topology, and they are shielded from unauthorized network access.
  • The service gateway enables you to backup the databases to Oracle Cloud Infrastructure Object Storage within the region, without traversing the public internet.