Oracle Autonomous Transaction Processing delivers a self-driving, self-securing, self-repairing database service that can instantly scale to meet demands of mission critical transaction processing and mixed workload applications. When you create an Autonomous Transaction Processing database, you can deploy it to one of two infrastructure platforms:
Customer in house developed Java Spring boot Workflow application needed to have following requirements on their live environment. In that case, Oracle Autonomous Transaction processing database met those requirements and our Database administration team worked on this to migrate the current workloads to Oracle ATP database.
The features which customer preferred in ATP are following. With the lower cost, High availability and performance was the key specializations for customer to go with ATP.
When it comes to achieve High availability in Oracle Cloud Gen 2 Environment, following components we used.
A region is a localized geographic area, and an availability domain is one or more data centers located within a region. A region is composed of one or more availability domains.
As we selected Frankfurt region, it has maximum of 3 availability domain.
Availability domains are isolated from each other, fault tolerant, and very unlikely to fail simultaneously. Because availability domains do not share infrastructure such as power or cooling, or the internal availability domain network, a failure at one availability domain within a region is unlikely to impact the availability of the others within the same region.
The availability domains within the same region are connected to each other by a low latency, high bandwidth network, which makes it possible for you to provide high-availability connectivity to the internet and on-premises, and to build replicated systems in multiple availability domains for both high-availability and disaster recovery.
A fault domain is a grouping of hardware and infrastructure within an availability domain. Each availability domain contains three fault domains. Fault domains let you distribute your instances so that they are not on the same physical hardware within a single availability domain. A hardware failure or Compute hardware maintenance that affects one fault domain does not affect instances in other fault domains. Every availability domain has 3 fault domains.
According to the above mentioned image, the web servers are distributed in between the availability domains.
In this implementation we have used several number of subnets to make separate security rules and access limitations in security purposes.
A public load balancer is regional in scope. If your region includes multiple availability domains, a public load balancer requires either a regional subnet (recommended) or two availability domain-specific (AD-specific) subnets, each in a separate availability domain. With a regional subnet, the Load Balancing service creates a primary load balancer and a standby load balancer, each in a different availability domain, to ensure accessibility even during an availability domain outage. If you create a load balancer in two AD-specific subnets, one subnet hosts the primary load balancer and the other hosts a standby load balancer. If the primary load balancer fails, the public IP address switches to the secondary load balancer. The service treats the two load balancers as equivalent and you cannot specify which one is “primary”.
To isolate your load balancer from the internet and simplify your security posture, you can create a private load balancer. The Load Balancing service assigns it a private IP address that serves as the entry point for incoming traffic.
When you create a private load balancer, the service requires only one subnet to host both the primary and standby load balancers. The load balancer can be regional or AD-specific, depending on the scope of the host subnet. The load balancer is accessible only from within the VCN that contains the host subnet, or as further restricted by your security rules.
The assigned floating private IP address is local to the host subnet. The primary and standby load balancers each require an extra private IP address from the host subnet.
In configuring the Java Spring boot application to oracle ATP, some challenges which we faced are below mentioned.