Manage multiple Oracle E-Business Suite customers across tenancies

This reference architecture describes how two different Oracle E-Business Suite (EBS) workloads can be managed across tenancies. This use case is prevalent among managed service providers (MSPs) who implement EBS workloads for multiple customers across tenancies. The MSPs deliver hosting and application management services for their EBS customers on Oracle Cloud, while delivering value in costs and long-term operational efficiencies.

This scenario is also a useful starting point for any customer who needs to work across tenancies or MSPs in general for managing their Cloud customers.

Thousands of organizations around the world rely on Oracle EBS to run their key business operations. Building on a 30-year history of innovation, Oracle EBS continues to deliver and to invest in the suite with a focus on functional advances, mobility, UI modernization, and operational efficiency while helping customers gain all the benefits of Oracle Cloud. Oracle EBS supports today’s evolving business models, drives productivity, and meets the demands of the modern mobile user.

Oracle’s EBS customers, as they look to the future and consider the benefits of cloud solutions, often seek partners with the specific skills and experience they need to succeed. Oracle’s partner ecosystem is critical to our customers’ success. Our partners are trusted advisors, equipped with the demonstrated expertise and tools to drive your success. Their differentiated services, combined with Oracle’s technology, help enable Oracle's customers to achieve their business goals. They help to deliver end-to-end Oracle Cloud strategy, consulting, and implementation services utilizing Oracle Cloud solutions and services.

Note:

If you are just beginning your Oracle Cloud Infrastructure (OCI) journey, further details for moving your E-Business Suite workload in OCI can be found in the My Oracle Support (MOS) reference: Getting Started with Oracle E-Business Suite on Oracle Cloud Infrastructure, Doc ID 2517025.1, referenced in the "Explore More" topic.

Architecture

This reference architecture comprises two tenancies, Tenancy-A and Tenancy-B. Tenancy-A contains one VCN for Customer-A’s EBS workload and a second VCN for the MSP. Tenancy-B has a single VCN containing Customer-B’s EBS workload.

Customer-A’s workload consists of an application tier containing multiple instances of the application which provides high availability. The database used is an Oracle Base Database Service (single-node database systems) on a virtual machine (VM).

For Customer-A, both internal zone (private subnet) and the external zone (public subnet) are configured. Internal users can access the private zone in the VCN through the Dynamic Routing Gateway (DRG). A private load balancer directs the traffic to the application nodes in the internal zone. A public load balancer allows external user requests to be passed into the DMZ by the Internet Gateway (IGW). The database is deployed in a private subnet.

Customer-B’s workload consists of a single application tier with Oracle Base Database Service (single-node database systems) on a virtual machine (VM) where both the application tier and database tier are deployed in a private subnet.

Inter-VCN communication is needed to provide managed cloud service to both Customer-A and Customer-B. This reference architecture uses a remote peering connection (RPC) to enable the inter-VCN communication. The peering allows the VCNs' resources to communicate by using private IP addresses, without routing the traffic over the internet or through an on-premises network. An RPC is a component you create on the DRG attached to your VCN. Its job is to act as a connection point for a remotely peered VCN. As part of the VCN configuration, each administrator must create an RPC for the DRG on their VCN. A given DRG must have a separate RPC for each remote peering it establishes for the VCN (with a maximum of 10 RPCs per tenancy).
  • The MSP's DRG has two RPC connections, one for each customer (RPC-1 for Customer-A and RPC-2 for Customer-B, respectively).
  • Customer-A has one RPC connection: RPC-3 and Customer-B has one RPC connection: RPC-4.
  • RPC-1 is connected to RPC-3 for Customer-A and RPC-2 is connected to RPC-4 for Customer-B.

The following diagram illustrates this reference architecture.

Description of deploy-ebs-multi-tenancies.png follows
Description of the illustration deploy-ebs-multi-tenancies.png

deploy-ebs-multi-tenancies-oracle.zip

The architecture has the following components:

  • Tenancy

    When you sign up for OCI, Oracle creates a tenancy for your company, which is a secure and isolated partition within OCI where you can create, organize, and administer your cloud resources.

  • Region

    An OCI region is a localized geographic area that contains one or more data centers, called availability domains. Regions are independent of other regions, and vast distances can separate them (across countries or even continents).

  • Compartment

    Compartments are cross-region logical partitions within an OCI tenancy. Use compartments to organize your resources in Oracle Cloud, control access to the resources, and set usage quotas. To control access to the resources in a given compartment, you define policies that specify who can access the resources and what actions they can perform.

  • Availability Domains (AD)

    Availability domains are standalone, independent data centers within a region. The physical resources in each availability domain are isolated from the resources in the other availability domains, which provides fault tolerance. Availability domains don’t share infrastructure such as power or cooling, or the internal availability domain network. So, a failure at one availability domain is unlikely to affect the other availability domains in the region.

  • Fault Domains

    A fault domain is a grouping of hardware and infrastructure within an availability domain. Each availability domain has three fault domains with independent power and hardware. When you distribute resources across multiple fault domains, your applications can tolerate physical server failure, system maintenance, and power failures inside a fault domain.

  • Virtual Cloud Network (VCN) and subnets

    A VCN is a customizable, software-defined network that you set up in an OCI region. Like traditional data center networks, VCNs give you complete control over your network environment. A VCN can have multiple non-overlapping CIDR blocks that you can change after you create the VCN. You can segment a VCN into subnets, which can be scoped to a region or to an availability domain. Each subnet consists of a contiguous range of addresses that don't overlap with the other subnets in the VCN. You can change the size of a subnet after creation. A subnet can be public or private.

  • Load Balancer (LB)

    The OCI Load Balancing service provides automated traffic distribution from a single entry point to multiple servers in the back end.

  • Security List (SL)

    Security Lists act as virtual firewalls for your compute instances. A security list consists of a set of ingress (connections initiated from the internet) and egress (connections initiated from within the VCN) security rules that apply to all the VNICs in any subnet with which the security list is associated.

  • Route Table (RT)

    Virtual route tables contain rules to route traffic from subnets to destinations outside a VCN, typically through gateways outside a VCN (for example, to the internet, to your on-premises network, or to a peered VCN).

  • Service Gateway (SG)

    The service gateway provides access from a VCN to other services, such as Oracle Cloud Infrastructure Object Storage. The traffic from the VCN to Oracle Services travels over the Oracle network fabric and never traverses the internet.

  • Internet Gateway (IGW)

    An internet gateway is an optional virtual router you can add to your VCN to allow traffic between the public subnets in a VCN and the public internet.

  • Dynamic Routing Gateway (DRG)
    The DRG is a virtual router that provides a path for private network traffic between a VCN and a network outside the region, such as a VCN in another OCI region, an on-premises network, or a network in another cloud provider. With the new enhancement features of DRG, you can now attach the following resources:
    • VCNs
    • RPCs
    • Site-to-Site VPN IPSec tunnels
    • OCI FastConnect virtual circuits
    Each attachment comes with a unique Route Table, which allows you to define policies that route traffic between attachments. This enhancement simplifies connectivity and caters to more complex network topologies and routing. This reference architecture uses a Hub and Spoke network topology, which allows you to use Palo Alto, a network virtual appliance, in a hub VCN to filter or inspect traffic between a customer's on-premises network and the application workload spoke VCN.
  • Object Storage

    Object storage provides quick access to large amounts of structured and unstructured data of any content type, including database backups, analytic data, and rich content such as images and videos. You can safely and securely store and then retrieve data directly from the internet or from within the cloud platform. You can seamlessly scale storage without experiencing any degradation in performance or service reliability. Use standard storage for "hot" storage that you need to access quickly, immediately, and frequently. Use archive storage for "cold" storage that you retain for long periods of time and rarely access.

  • FastConnect (FC)

    Oracle Cloud Infrastructure FastConnect provides an easy way to create a dedicated, private connection between your data center and OCI. FastConnect provides higher-bandwidth options and a more reliable networking experience when compared with internet-based connections.

  • Virtual Circuit (VC)

    A virtual circuit is a layer-2 or layer-3 Ethernet VLAN that runs over one or more physical network connections to provide a single, logical connection between the router on the edge of your network and the Oracle router. Each virtual circuit is made up of information shared between the customer and Oracle, as well as an Oracle FastConnect partner (if you're connecting through an Oracle FastConnect partner). Private virtual circuits support private peering, while public virtual circuits support public peering.

  • E-Business Suite Application Tier

    An Oracle E-Business Suite application is composed of servers and file system. In this reference architecture, for Customer-A, it is deployed with multiple application tier nodes and caters to the application. When deploying an Oracle E-Business Suite application tier with multiple nodes, you can use either a shared or non-shared application tier file system. This architecture adopts a shared application tier file system, which reduces disk space requirements and eliminates the need to apply patches to each node in the environment.

  • Oracle E-Business Suite Database Tier

    In this reference architecture, both customers are using OCI's Base Database Service. Using this service, you can maintain absolute control over your data while leveraging the combined capabilities of Oracle Database and OCI, managed by Oracle.

Recommendations

When working with E-Business Suite on OCI, the following recommendations can prove useful, although they might vary depending upon your implementation.
  • VCN

    When you create a VCN, determine the number of CIDR blocks required and the size of each block based on the number of resources that you plan to attach to subnets in the VCN. Use CIDR blocks that are within the standard private IP address space.

    Select CIDR blocks that don't overlap with any other network (in OCI, your on-premises data center, or another cloud provider) to which you intend to set up private connections.

    After you create a VCN, you can change, add, and remove its CIDR blocks. When you design the subnets, consider your traffic flow and security requirements. Attach all the resources within a specific tier or role to the same subnet, which can serve as a security boundary.

    Oracle recommends using regional subnets because they’re more flexible. They make it easier to efficiently divide your VCN into subnets while also designing for availability domain failure.

  • Security

    In order to strengthen the security posture of your OCI tenancy, Oracle recommends using Cloud Guard and Security zones. You must enable Cloud Guard before you create Security zones. Cloud Guard helps you detect policy violations in existing resources that were created before the Security zone.

    Cloud Guard

    Cloud Guard is a cloud-native service that helps customers monitor, identify, achieve, and maintain a strong security posture on Oracle Cloud. Use the service to examine your OCI resources for security weaknesses related to configuration, and your OCI operators and users for risky activities. Upon detection, Cloud Guard can suggest, assist, or take corrective actions, based on your configuration. The following list summarizes what you need to know to get started planning for Cloud Guard:
    • Target: Defines the scope of what Cloud Guard checks. All compartments within a target are checked in the same way and you have the same options for processing problems that are detected.
    • Detector: Performs checks to identify potential security problems based on activities or configurations. Rules followed to identify problems are the same for all compartments in a target.
    • Responder: Specifies actions that Cloud Guard can take when detectors identify problems. Rules for how to process identified problems are the same for all compartments in a target.

    Security zones

    For resources that require maximum security, Oracle recommends that you use Security zones. A security zone is a compartment associated with an Oracle-defined recipe of security policies that are based on best practices. For example, the resources in a Security zone must not be accessible from the public internet and they must be encrypted using customer-managed keys.

    When you create and update resources in a Security zone, OCI validates the operations against the policies in the security-zone recipe, and denies operations that violate any of the policies.

  • Network security groups (NSGs)

    You can use NSGs to define a set of ingress and egress rules that apply to specific VNICs. We recommend using NSGs rather than security lists, because NSGs enable you to separate the VCN's subnet architecture from the security requirements of your application.

  • Load balancer bandwidth

    While creating the load balancer, you can either select a predefined shape that provides a fixed bandwidth, or specify a custom (flexible) shape where you set a bandwidth range and let the service scale the bandwidth automatically based on traffic patterns. With either approach, you can change the shape at any time after creating the load balancer.

  • E-Business Suite Cloud Manager Tool

    Oracle E-Business Suite Cloud Manager is a web-based application that drives all the principal automation flows for Oracle E-Business Suite on OCI, including provisioning new environments, performing lifecycle management activities on those environments, and restoring environments from on-premises.

    Oracle highly recommends all customers who intend to move their Oracle E-Business Suite workload to OCI to use this automation tool for lift and shift, provisioning, and lifecycle management. However, if our current automation offerings do not meet your specific requirements, you may use a manual procedure.

  • Web Application Firewall

    There are many deployments like Customer-A, where customers have requirements to expose some application modules for their suppliers and partners. There may also be a requirement for certain end users to connect from outside the corporate firewall. To meet these requirements, you need to expose certain application endpoints to the internet via a demilitarized zone (DMZ). Web clients/browsers and servers communicate via protocols such as HTTP, HTTPS, FTP, and so on, and malicious actors could exploit vulnerabilities in how these protocols are used.

    Protocols are located at different layers of the protocol stack. Although web exploits happen at the application layer (layer 7), it can impact other layers via packet flooding (data link layer) or SYN flooding (network layer). However, web exploits at the application layer are becoming more common than network layer attacks on web servers. These web exploits (for example, SQL injection, Cross-Site Scripting, Security Misconfiguration, and so on), if not handled, could compromise security and impact application availability. OCI's Web Application Firewall (WAF) helps you make your endpoints more secure by monitoring and filtering out potentially malicious traffic. It is a cloud-based, Payment Card Industry (PCI) compliant, global security service that protects applications from malicious and unwanted internet traffic.

Acknowledgments

Author: Madhusri Bhattacharya