Deploy an ERP system using Ellucian Banner

Ellucian Banner is an enterprise resource planning (ERP) system for higher education institutions. It includes self-service options for students, staff, and administrators to access the features they need at any time and from any device. Oracle Cloud Infrastructure, with its comprehensive portfolio of infrastructure and platform services, is the ideal public cloud for deploying Ellucian Banner.

Architecture

This multi-tier reference architecture contains the infrastructure resources required to deploy highly available instances of Ellucian Banner applications on Oracle Cloud Infrastructure.

The architecture includes redundant resources at every tier, to ensure high availability across the stack.
  • Dual-node load balancers are used for the incoming traffic from users and administrators. The nodes of each load balancer are in separate fault domains.
  • Two bastion hosts enable secure access by internal users to the resources in the cloud.
  • The compute instances for hosting the applications are distributed across two fault domains. Each application is hosted on two compute instances, which are attached to separate subnets.
  • The applications use a dual-node database that's attached to a private subnet. Each database node is provisioned in a separate fault domain, with Oracle Data Guard used for high availability.
  • Compartment security zones enforce security policy requirements for critical enterprise data and prevent misconfiguration errors so you can deploy workloads securely.
  • Cloud Guard continuously monitors configurations and activities to identify threats and automatically acts to remediate issues at a compartment level.

Note:

In regions that have multiple availability domains, you can distribute the resources across two availability domains.

The following diagram illustrates this architecture.

Description of ellucian-oci.png follows
Description of the illustration ellucian-oci.png

The architecture has the following components:

  • 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 demilitarized zone (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 can avoid exposing the more sensitive components of the topology without compromising access to them.

    This reference architecture contains two bastion hosts. For enhanced security, they allow connectivity from only the on-premises network. One bastion host is for the cloud infrastructure administrator to handle OS upgrades and other operational tasks. Database administrators can use the second bastion host.

    You can configure autoscaling for these nodes, to ensure that additional bastion hosts are created automatically when needed.

  • Administrator application (AA) nodes

    These compute instances host the applications that are used by administrators for loading and managing data.

  • Self-service application (SSA) nodes

    These compute instances host the applications that are used by self-service users and educational department heads, the end users of the Ellucian Banner applications.

  • Database nodes

    The database nodes store the data loaded by administrators or by other users.

    The database nodes can be virtual machines (VMs) with Data Guard for high availability, or readily available Oracle Database instances using a two-node real application cluster (RAC) deployment with Data Guard.

  • Load balancers

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

    This architecture uses separate load balancers for the administrator's applications and the self-service applications, for tighter security and traffic separation. You can upgrade the load balancer shape if needed.

  • NAT gateway

    The NAT gateway enables private resources in a VCN to access hosts on the internet, without exposing those resources to incoming internet connections.

    For example, the NAT gateway enables downloading patches to the database nodes.

  • Service gateway

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

  • 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. 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 seldom or rarely access.

  • Virtual cloud network (VCN) and subnets

    A VCN is a customizable, private network that you set up in an Oracle Cloud Infrastructure region. Like traditional data center networks, VCNs give you complete control over your network environment. You can segment VCNs into subnets, which can be scoped to a region or to an availability domain. Both regional subnets and availability domain-specific subnets can coexist in the same VCN. A subnet can be public or private.

  • Security lists

    For each subnet, you can create security rules that specify the source, destination, and type of traffic that must be allowed in and out of the subnet.

  • Availability domains

    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.

  • Cloud Guard

    Oracle Cloud Guard helps maintain good security posture by detecting weak security configurations and risky activities that can indicate cloud security threats.

    Cloud Guard processes logs and events at a compartment level for all major Oracle Cloud Infrastructure services, such as compute, networking, and storage to provide timely results that you can address manually or automatically.

  • Security zones

    Security zones ensure Oracle's security best practices from the start by enforcing policies such as encrypting data and preventing public access to networks for an entire compartment. A security zone is associated with a compartment of the same name and includes security zone policies or a "recipe" that applies to the compartment and its sub-compartments. You can't add or move a standard compartment to a security zone compartment.

  • Local peering gateway (LPG)

    An LPG enables you to peer one VCN with another VCN in the same region. Peering means the VCNs communicate using private IP addresses, without the traffic traversing the internet or routing through your on-premises network.

    With Cloud Guard and Security Zones enabled at the compartment level, two separate compartments host the database and bastion host (in a private subnet) and SSA and AA (in a public subnet). Local peering gateways enable communication between components in these compartments.

Recommendations

Your requirements might differ from the architecture described here. Use the following recommendations as a starting point.

  • Cloud Guard

    Clone and customize the default recipes provided by Oracle to create custom detector and responder recipes. These recipes enable you to specify what type of security violations generate a warning and what actions are allowed to be performed on them. For example, an Object Storage bucket can have visibility set to public.

    Apply Cloud Guard at the tenancy level to cover the broadest scope and to reduce the administrative burden of maintaining multiple configurations.

    You can also use the Managed List feature to apply certain configurations to detectors.

  • Security Zone

    A security zone compartment complies with strict security policies that are preconfigured and can’t be modified. These security policies impose strict requirements on resources in the compartment, such as ensuring that compute instances use customer-managed encryption keys through the Oracle Key Management Cloud Service (KMS). Oracle recommends that you create resources in a security zone-enabled compartment whenever using a private subnet. You can’t create a VNC with a public subnet in a security zone-enabled compartment.

  • Bastion host

    Use a VM.Standard.1.1 compute shape. This host accesses other compute nodes and isn’t involved in data processing or other tasks. Start with two nodes and use the autoscaling feature to scale in or out as needed.

    Bastion hosts are created in a compartment with Security Zones enabled and are not allowed to have a public IP address. Ensure that you create customer-managed keys using Oracle Key Management Cloud Service because they’re required when creating this instance.

  • Administrator application (AA) nodes

    Use the VM.Standard2.24 shape, which provides 24 OCPUs and 320 GB of RAM. Start with two nodes in separate fault domains and separate subnets. Use the autoscaling feature to scale in or out as necessary.

    Create AA nodes in compartments with only Cloud Guard enabled. You can clone and modify the default recipe for detector and responder for any specific requirement. Oracle recommends that you use the default recipe as-is.

  • Self-service application (SSA) nodes

    Use the VM.Standard2.24 shape, which provides 24 OCPUs and 320 GB of RAM. Start with two nodes in separate fault domains and separate subnets. Use the autoscaling feature to scale in or out as necessary.

    Create SSA nodes in compartments with only Cloud Guard enabled. You can clone and modify the default recipe for detector and responder for any specific requirement. Oracle recommends that you use the default recipe as-is.

  • Database nodes

    Each database node is a compute node. Use the VM.DenseIO2.24 shape, which provides locally attached storage for higher I/O operations per second (IOPS) and up to 24.6 Gbps of networking bandwidth. Create two nodes in different fault domains and use RAID configuration (RAID 10) to protect data on locally attached disks. Enable Oracle Data Guard between the two nodes for high availability.

    Create database nodes in a compartment with both Cloud Guard and Security Zones enabled. This configuration ensures that database nodes adhere to the strict security policies of Security Zones. You can clone and modify the default recipe for detector and responder for any specific requirement. Oracle recommends that you use the default recipe as-is.

    If your database requires a fully dedicated, single-tenant node with even higher performance, especially for network bandwidth, then consider using the BM.DenseIO2.52 shape.

  • Load balancers

    The load balancers distribute incoming traffic to the application VMs. Use the 100-Mbps shape.

  • Object Storage

    Use Oracle Cloud Infrastructure Object Storage to store backups of the database and other data.

    Create object storage in a compartment with Security Zones enabled and set its visibility to private only. This configuration ensures that the Object Storage bucket adheres to the strict security policies of Security Zones.

  • VCN

    When you create the VCN, determine how many IP addresses your cloud resources in each subnet require. Using the Classless Inter-Domain Routing (CIDR) notation, specify a subnet mask and a network address range that's large enough for the required IP addresses. Use an address range that's within the standard private IP address space.

    Select an address range that doesn’t overlap with any other network (in Oracle Cloud Infrastructure, your on-premises data center, or in another cloud provider) that you intend to set up private connections to.

    After you create a VCN, you can't change its address range.

    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.

    Use regional subnets.

  • Security lists

    Use security lists to define ingress and egress rules that apply to the entire subnet.

    This architecture allows Internet Control Message Protocol (ICMP) internally for the entire private subnet. Oracle also recommends using Network Security Groups (NSG) for a more granular security implementation.

Considerations

  • Performance and cost

    Oracle Cloud Infrastructure offers compute shapes that cater to a wide range of applications and use cases. Choose the shapes for your compute instances carefully. Select shapes that provide optimal performance for your load at the lowest cost.

  • Availability

    Consider using a high-availability option based on your deployment requirements and your region. The options include distributing resources across multiple availability domains in a region, and distributing resources across the fault domains within an availability domain.

  • Cost

    A bare metal GPU instance provides necessary CPU power for a higher cost. Evaluate your requirements to choose the appropriate compute shape.

  • Monitoring and alerts

    Set up monitoring and alerts on CPU and memory usage for your nodes, so that you can scale the shape up or down as needed.

Change Log

This log lists significant changes: