Migrating Banner to OCI Cloud Detail Architecture

 

What is the banner application?

Banner is an administrative software application developed specifically for higher education institutions by ELLUCIAN. Banner maintains student, faculty, course, alumni, financial, financial aid and personnel data. ... ✓ Supports functions that need to be carried out for an institution to run efficiently

 

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 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, software-defined 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. 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.

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

• 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 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 Oracle Cloud Infrastructure, your on-premises data centre, 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.

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.