1. Set up the infrastructure to deploy Oracle Enterprise Performance Management
  2. Learn About the Architecture

Learn About the Architecture

The infrastructure required to deploy Oracle Enterprise Performance Management (Hyperion) applications on Oracle Cloud Infrastructure includes compute instances, networking components, storage resources, and databases. To deploy and manage your cloud topology efficiently, define the infrastructure as code in Terraform configuration files.

Use the Terraform configuration included in this solution to set up the infrastructure resources necessary to deploy Oracle Enterprise Performance Management applications on Microsoft Windows servers in the cloud.

Before You Begin

Before you begin building the infrastructure, learn about the architectural options, and review the design considerations.

For a detailed description of all the architectural options and the design considerations, see Design the infrastructure to deploy Oracle Enterprise Performance Management in the cloud.

This document provides a brief overview of the supported HA architectures: single availability domain, and multiple availability domains.

HA Architecture: Single Availability Domain

In this architecture, the applications and the databases are deployed across two fault domains in a single availability domain.

All the application instances in the topology are active. Redundant instances of the application are hosted in separate fault domains. So the instances aren't hosted on the same physical hardware. This architecture ensures high availability within the availability domain. A hardware failure or maintenance event that affects one fault domain doesn't affect the instances in the other fault domains.

If an instance fails, then the traffic is diverted to the other instances in the availability domain, which continue to process the requests. Any incomplete tasks that were being processed by the failed instance must be resubmitted by the users.

All the components in this multitier architecture are in a single region. The resources in each tier are isolated at the network level in separate subnets.


Description of hyperion-single-ad.png follows
Description of the illustration hyperion-single-ad.png

HA Architecture: Multiple Availability Domains

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

The primary and standby environments in this architecture are symmetric; that is, both the environments provide identical compute and storage capacity.

  • When the primary environment is active, the load balancer is configured to route traffic to only the availability domain that hosts the primary topology.
  • If the primary environment is unavailable for any reason, you can switch over to the standby environment, and update the backend set of the load balancer to route traffic to the availability domain that hosts the standby topology. When the primary environment becomes available again, you can switch back to it and update the load balancer accordingly.

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

Logical host names are assigned to the databases and the application instances. To reduce the effort for reconfiguring instances during a switchover or switchback, the same logical host names are used in the primary and standby environments.

All the components in this multi-tier architecture are in a single region. The resources in each tier are isolated at the network level in separate subnets. Every subnet is regional; so, outages in an availability domain don't affect any of the subnets.

Description of hyperion-multi-ad.png follows
Description of the illustration hyperion-multi-ad.png

Components of the Architecture

When you use the Terraform code included in this solution to deploy the architecture, the following compute, database, networking, and storage resources are created.

  • Virtual cloud network (VCN) and subnets

    You specify the CIDR block and the DNS label for the VCN.

    The Terraform code calculates the CIDR blocks for the regional subnets required for the bastion host, load balancer, web tier, application tier, and database resources.

    The code also provisions the necessary network gateways, route tables, and security rules. The specific security rules are listed later in this document.

  • Bastion Host

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

    The bastion host in this architecture is attached to a public subnet, and it has a public IP address. Connections to the bastion host from administrators outside the cloud flow through the internet gateway attached to the VCN. An ingress security rule is configured 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 subnets by using dynamic SSH tunneling. The dynamic tunnel provides a SOCKS proxy on the local port; but the connections originate from the remote host.

  • Load Balancer

    The primary and standby nodes of the load balancer are provisioned in separate fault domains or availability domains. So, high availability is ensured for the load-balancer tier.

    You can provision a public or private load balancer.

    • If you provision a public load balancer, then HTTPS requests from external users, such as users of Hyperion Financial Reporting Web Studio, flow through the internet gateway to the public load balancer. You can use the Oracle Cloud Infrastructure Web Application Firewall service to protect the applications from malicious and unwanted internet traffic.

      You can configure the load balancer to terminate SSL/TLS and distribute HTTP requests to the private web tier.

    • If you provision a private load balancer, then 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 public or private load balancer in your public or on-premises DNS.
  • Web Tier

    The web tier is hosted on Microsoft Windows Server compute instances that are attached to a private subnet. The instances are distributed in separate fault domains or availability domains, ensuring high availability of the web tier.

    You specify the number of compute instances to be created for the web tier, the compute shape to be used, the listen port number, and the size and performance attributes of the block volumes.

  • Application Tier
    The application tier includes Microsoft Windows Server compute instances on which you can deploy the following Oracle Enterprise Performance Management applications.

    Note:

    For each application, you specify the number of compute instances that should be created, the compute shape to be used, the listen port number, and the size and performance attributes of the block volumes.
    • 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.

    • (Optional) 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 enables global financial consolidation, reporting, and analysis in a single, highly scalable software solution.

    • (Optional) 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.

    • (Optional) 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.

    • (Optional) Oracle Essbase

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

    • (Optional) 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.

    • (Optional) 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.

    • (Optional) 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.

    The compute instances for each application are distributed separate fault domains or availability domains. So, every component in the application tier is highly available.

    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.
  • Database Tier

    The database tier contains Oracle Cloud Infrastructure Database instances. For high availability, use 2-node virtual machine (VM) DB systems or Exadata DB systems.

    You can choose to provision separate databases for Oracle Hyperion Foundation Services and for the applications.

    For each database, you specify the edition, version, license model, number of nodes, CDB and PDB names, shape, size, and character set.

    • If you choose the single-AD architecture, then the database nodes are distributed in separate fault domains, ensuring that each database cluster is tolerant to failures at the fault-domain level.
    • If you choose the multiple-AD architecture, then the primary and standby databases are provisioned in separate availability domains, ensuring that the databases are tolerant to failures at the availability-domain level. Oracle Data Guard in synchronous mode ensures that the standby database is a transactionally consistent copy of the primary database.

    All the database nodes are attached to a 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 back up the databases to Oracle Cloud Infrastructure Object Storage within the region, without traversing the public internet.

  • File Storage

    The components in the application tier have access to shared Oracle Cloud Infrastructure File Storage, for storing shared binaries and data generated by the applications. You specify the mount path and the size limit for the filesystem.

Security Rules

The Terraform code creates a separate security list for each subnet.

Each security list contains one or more stateful security rules, based on the traffic flow requirements of the resources in the subnet.

  • Security list for the bastion host
    Security Rule Type Source or Destination Port
    Egress VCN 3389
    Egress VCN 22
    Ingress 0.0.0.0/0 22
  • Security list for the load balancer
    Security Rule Type Source or Destination Port/s
    Egress 0.0.0.0/0 All
    Ingress 0.0.0.0/0 The listen ports that you specify for the load balancer
  • Security list for the web servers
    Security Rule Type Source or Destination Port/s
    Egress 0.0.0.0/0 All
    Ingress VCN The listen ports that you specify for the web tier.
  • Security list for the databases
    Security Rule Type Source or Destination Port/s
    Egress 0.0.0.0/0 TCP: All
    Ingress VCN TCP: 22
    Ingress VCN TCP: 1521
  • Security list for the application servers

    This security list contains the following security rules:

    • An egress rule to allow all TCP traffic bound for any host outside the subnet.
    • An ingress rule to allow TCP traffic from any host in the VCN to RDP port 3389.
    • Ingress rules to allow TCP traffic from any host in the VCN to the following ports:
      Application Port/s
      Oracle Hyperion Foundation Services: WebLogic servers 7001, 9000
      Oracle Hyperion Foundation Services: Dimension servers 5251, 5255
      Oracle Hyperion Foundation Services: Reporting and Analysis Framework Agent 6860, 6861
      Oracle Hyperion Planning servers: WebLogic servers 7001
      Oracle Hyperion Planning servers: Java web application 8300
      Oracle Hyperion Planning servers: RMI 11333
      Oracle Essbase servers: Agent 1423
      Oracle Essbase servers: applications 32768-33768
      Oracle Essbase servers: OPMN ports 6711, 6712
      Oracle Hyperion Financial Management: WebLogic servers 7001, 7363
      Oracle Hyperion Financial Management: servers 9091
      Oracle Hyperion Tax Provision servers 22200
      Oracle Hyperion Profitability and Cost Management servers 6756
      Oracle Hyperion Strategic Finance servers 8900
      Oracle Hyperion Financial Data Quality Management, Enterprise Edition servers 6550
  • Security rules for Oracle Cloud Infrastructure File Storage
    • An ingress rule to allow TCP traffic from any host in the VCN to ports 111 and 2048-2050
    • An ingress rule to allow UDP traffic from any host in the VCN to ports 111 and 2048
    • An egress rule to allow TCP traffic from ports 111 and 2048-2050 to any host in the VCN
    • An egress rule to allow UDP traffic from port 111 to any host in the VCN

Required Services and Permissions

You need the following services for this solution:
  • Oracle Cloud Infrastructure Compute
  • Oracle Cloud Infrastructure Database
  • Oracle Cloud Infrastructure Networking
  • Oracle Cloud Infrastructure Load Balancing
  • (Optional) Oracle Cloud Infrastructure FastConnect
  • Oracle Cloud Infrastructure Identity and Access Management
  • Oracle Cloud Infrastructure Object Storage
  • Oracle Cloud Infrastructure File Storage
  • Oracle Cloud Infrastructure Block Volumes
Ask your tenancy administrator to create an Oracle Cloud Infrastructure Identity and Access Management policy that includes the following permissions:
Allow group your.group to manage instance-family in compartment your.compartment
Allow group your.group to manage virtual-network-family in compartment your.compartment
Allow group your.group to manage database-family in compartment your.compartment
Allow group your.group to manage object-family in compartment your.compartment
Allow group your.group to manage volume-family in compartment your.compartment
Allow group your.group to manage load-balancers in compartment your.compartment
Allow group your.group to read compartments in compartment your.compartment
Allow group your.group to manage file-family in compartment your.compartment
Allow group your.group to read all-resources in tenancy
  • Replace your.group with the name of the group that the user provisioning the infrastructure resources belongs to.
  • Replace your.compartment with the OCID of the compartment in which you want to provision the infrastructure.