Deploy a Highly Available Bare Metal Database
Oracle Data Guard ensures high availability, data protection, and disaster recovery for enterprise data. With Data Guard, failover of the primary database to the standby database can be done manually by using the Data Guard Broker command line interface (DGMGRL CLI) or Oracle Enterprise Manager, or automatically by configuring a Compute node to act as a fast-start failover (FSFO) observer. The observer can automatically initiate failover and automatically reinstate a failed primary database as a standby database. Having FSFO observers in the deployment removes the need for manual intervention when database failover is necessary.
Architecture
This reference architecture shows how to deploy two bare metal DB systems and the infrastructure components needed to configure FSFO for an Oracle Database 12c Release 2 (12.2) deployed on Oracle Cloud Infrastructure in two regions.
This cloud database architecture can be used as a resilient database tier for many applications, including Oracle E-Business Suite, JD Edwards, and PeopleSoft.
The following diagram illustrates this reference architecture.
Description of the illustration ha-db.png
- Region
An Oracle Cloud Infrastructure 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).
- Availability domain
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.
Availability domains aren't shown in the architecture diagram.
- 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.
Fault domains aren't shown in the architecture diagram.
- 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.
- Observers
Observers are Compute nodes that have the necessary Oracle Database software installed and configured to initiate FSFO of the Oracle Database running on the bare metal DB system. An FSFO best practice is to run the observer process on a host that is located in a different data center than the primary or standby database. To meet that best practice, this reference architecture deploys three observer nodes. Oracle Database release 12.2 or higher is required for this setup.
- Primary and standby DB systems
These bare metal DB systems have an Oracle Database 12c Release 2 (12.2) configured for Data Guard replication.
Recommendations
Your requirements might differ from the architecture described here. Use the following recommendations as a starting point.
- DB system shapes
This reference architecture uses the BM.Standard2.52 bare metal shape for the DB systems. This shape has 51.2 TB of locally attached NVMe SSDs with low latency. We selected the bare metal shape because it lets us create multiple database homes and databases.
- Compute shapes
This reference architecture uses a VM.Standard2.1 core virtual machine (VM) shape for the observer nodes. The observer node is a low-footprint Oracle Call Interface client built into the DGMGRL CLI. A one-core VM shape is sufficient for this architecture.
- 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 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.
Use regional subnets.
- Security lists
Use security lists to define ingress and egress rules that apply to the entire subnet. For example, this reference architecture allows ICMP internally for the entire private subnet.
- 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, you might want to detect Object Storage buckets that 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 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, Oracle Cloud Infrastructure validates the operations against the policies in the security-zone recipe, and denies operations that violate any of the policies.
Considerations
Consider these points when deploying this reference architecture.
- Performance
To get the best performance for your application workloads, ensure that your primary bare metal DB system has enough cores to support the application and the Data Guard configuration.
- Availability
The observer nodes are deployed in multiple availability regions to ensure that FSFO can automatically occur even if one of the observer nodes goes offline. After failover occurs, the standby database becomes the primary database.
- Cost
Size the CPUs on the bare metal DB systems based on your needs. You can start with two or more cores and scale up to 52 cores on a BM.DenseIO2.52 shape. You can also scale up the cores dynamically without downtime.