In this article, we will explore the disaster recovery (DR) deployment architecture for Finastra's banking solution in Oracle Cloud Infrastructure (OCI). Finastra offers a range of banking products and solutions, including Core Banking, Payments and Transaction Processing, Digital Banking, Risk and Compliance Management, and Analytics and Business Intelligence. To ensure business continuity and data protection, a robust DR architecture is implemented in OCI. We will discuss the key components and design considerations that contribute to an effective DR solution.
High Level DC-DR Design with Data and Replication Flows
The design of our Disaster Recovery (DR) solution is tailored to the customer's Recovery Point Objective (RPO) and Recovery Time Objective (RTO) requirements. In cases where a customer has a more lenient RPO and RTO, opting for a cost-effective DR solution through backup and restore mechanisms becomes a viable strategy. This approach has been successfully implemented for a prominent ASEAN customer.
The DR deployment architecture for Finastra's banking solution in OCI is designed to replicate critical components and data in a secondary region. This ensures that in the event of a disaster in the primary region, services can be quickly restored in the secondary region. Let's delve into the architecture details:
The architecture provisions resources and services in both the primary and secondary regions. The primary region handles normal operations, while the secondary region acts as a standby for disaster recovery purposes. All key components, including the database, technical components (Apache RPS, cash Web, VA API, Mobile, integrator, report server), and associated subnets, are replicated in the secondary region.
OCI Autonomous Transaction Processing (ATP) is used as the database solution in both the primary and secondary regions. Data Guard technology is employed to replicate data in real-time from the primary to the standby database. This ensures that data remains consistent and readily available for failover.
To keep the technical components synchronized between the primary and secondary regions, the RSYNC utility is utilized. This allows for efficient and reliable synchronization of data and configurations, ensuring that the standby environment is up-to-date.
The architecture aims to achieve a low RPO, meaning that data loss is minimal in the event of a disaster. With real-time data replication, the RPO can be kept to a few minutes. The RTO, which represents the time taken to recover services, is targeted to be less than one hour, ensuring minimal downtime for critical banking operations.
The Web Application Firewall (WAF) plays a crucial role in controlling traffic routing during a DR scenario. It directs incoming traffic to either the primary or secondary site based on predefined rules. This ensures that users are seamlessly redirected to the appropriate site, depending on the availability of services.
To streamline and automate the DR switch process, Jenkins and OCI Ansible collections are utilized. This allows for both planned and unplanned DR activities to be executed efficiently. The automation ensures a fast and reliable failover process, minimizing manual intervention and reducing recovery time.
The DR architecture is designed to optimize costs while maintaining the required level of redundancy and availability. By provisioning resources at 50% capacity in the secondary region, cost savings are achieved while still enabling a fully functional DR environment.
The disaster recovery deployment architecture for Finastra's banking solution in OCI ensures business continuity and data protection. By replicating critical components and data in a secondary region, financial institutions can quickly recover services in the event of a disaster. With real-time database replication, synchronized technical components, automated failover, and cost optimization measures, the architecture provides a robust and efficient DR solution.