EBOOK. FROM DISASTER RECOVERY TO ACTIVE-ACTIVE: NuoDB AND MULTI-DATA CENTER DEPLOYMENTS

Transcription

1 FROM DISASTER RECOVERY TO ACTIVE-ACTIVE: NuoDB AND MULTI-DATA CENTER DEPLOYMENTS

2 INTRODUCTION Traditionally, multi-data center strategies were deployed primarily to address disaster recovery scenarios. The most common deployments included one data center serving production workloads and another (backup) data center that was either passive or just partially utilized, and responsive to production workloads only if the primary data center suffered an outage. In this ebook, we ll go over the options organizations have today with multi-data-center deployments, the spectrum of multi-data-center configurations, the benefits and limitations to each, and what NuoDB currently offers in multi-data center deployments. However, today we have instant access to rented data center resources, dynamic provisioning, and increasingly affordable and high-quality WAN infrastructure. When combined with improvements in distributed database technology, organizations are headed for a future where multi-data-center deployments are no longer just for disaster recovery, but used to meet increasing workloads, scale, and user experience demands....organizations are headed for a future where multi-data center deployments are no longer just for disaster recovery... 2

3 MULTI-DATA CENTER OPPORTUNITIES When implementing next-generation, multi-data-center strategies, CIOs and IT strategists commonly have multiple objectives: Achieve disaster resilience with continuous service availability during data center failures and disasters. Optimize cloud economics by deploying workloads across various cloud and noncloud environments. Support geographically distributed access with low latency guarantees for mobile users, branch offices, and backbone data centers. Integrate and automate business processes across the organization s vendor/ partner/customer ecosystem. Maintain data sovereignty and meet data privacy requirements across multiple legal jurisdictions. Provide operational flexibility to run workloads wherever makes most sense for financial, workload balancing, maintenance, or convenience reasons. 3

4 DEPLOYMENT SCENARIOS AND USE CASES Traditionally, due to complexity, cost, and available technology, organizations used functionality innate to the database for multi-data-center, disaster recovery strategies. However, these strategies involve tradeoffs unacceptable in today s world, including inefficient utilization and lack of availability across multiple locations. Today, organizations desire a sophisticated activeactive approach that can keep costs, complexity, and management efforts to a minimum. While traditional active-active deployments require extra technology, configuration, application code, and management resources, NuoDB offers a modern solution, which includes active-active capabilities native to the database itself. The following is a description of the spectrum of multi-data center deployment scenarios, how NuoDB handles these scenarios, and the benefits, costs, and capabilities for each: Multi-Data Center Deployment Scenarios: + + Cold Standby + + Warm Standby + + Hot Standby + + Hot Standby with Read Replicas + + Active-Active: Partitioned Data & Access + + Active-Active: Transactional Consistency + + Active-Active: Conflict Resolution 4

5 NuoDB ARCHITECTURE A A First, let s take a quick look at NuoDB s architecture so we can better understand how it performs in a multi-data-center deployment. Unlike the monolithic structures of the past, NuoDB was designed from the beginning using a distributed, peer-to-peer architecture that still appears to the application as a single logical SQL database. Query Processing Storage Storage Manager (SM) Durability TE SM TE SM Not-yet-provisioned, Available Node By using a two-tiered architecture that can separate and independently scale transaction processing (Transaction Engines) from durability (Storage Managers), NuoDB can be deployed across multiple data centers and is optimized for inmemory speeds, continuous availability, and elastic scale-out. In the coming sections, we ll first explore how the scenario is achieved using traditional methods and then explain its NuoDB equivalent and the benefits it brings. 5

6 COLD STANDBY A single data center is active, running applications and the database. Data is backed up to a remote location periodically. If the data center suffers an outage, the applications and data will be unavailable for a certain amount of time until the backup database is recovered or started up, applications are started up, and a new data center is brought online. COLD STANDBY USING NuoDB We do not recommend this approach to disaster recovery due to its inherent limitations. Instead, at the very least, we recommend running a minimal NuoDB footprint in a remote location (see Warm Standby with NuoDB ) to prevent this scenario from occurring. This scenario generally results in some data loss depending on the frequency of the backup. 6

7 WARM STANDBY A single data center is active - running applications and the database. The active data center either batch or continuously replicates transactions to a second, backup data center. If the active data center suffers an outage, the applications and data will be unavailable for a certain amount of time until the backup database is recovered or started up, applications are started up, and remote data center is brought online. 7

8 WARM STANDBY USING NuoDB By deploying a single Storage Manager in a remote location, customers can have a minimal footprint for disaster protection. NuoDB automatically replicates transactions without any additional technologies, special configuration, or coordination. Minimal Disaster Recovery (DR) protection requires a single SM in a DR site to maintain a fully redundant copy of the database. In this scenario, if the active data center goes down, customers will need to deploy Transaction Engines before the database can be ready for use. 8

9 HOT STANDBY A single data center is active - running applications and the database. The active database replicates transactions to an actively running database in the backup data center. This secondary site does not, however, process transactions under normal circumstances. However, if the active data center suffers an outage, there is no recovery period for the database. Typically, the application is also online in the backup data center resulting in a minimal outage. 9

10 HOT STANDBY USING NuoDB NuoDB is designed to maintain a single logical database across all nodes, even across multiple data centers. It is always active, across all database nodes. NuoDB will not need any recovery time in order for nodes in the backup data center to become active - it will already be ready to connect to applications and perform transactions. In this scenario, the peers in the Hot Site are active so require no recovery time in the event of a disaster. 10

11 HOT STANDBY WITH READ REPLICAS This is the same configuration as Hot Standby. However, applications may use the secondary data center to fulfill read-only requests, allowing partial utilization of this data center. If the active data center suffers an outage, the second data center may immediately be converted to support the full read/write workload. 11

12 HOT STANDBY WITH READ REPLICAS USING NuoDB Because NuoDB is always active, across all database nodes, it can easily be used to provide read (and write) access in the remote location. Deploying applications in the remote site allows for read (and write) replicas in the remote location. 12

13 ACTIVE-ACTIVE: PARTITIONED DATA & ACCESS In a traditional scenario, there would be two data centers that are each actively running the same database and application. However, the data and access is partitioned such that the application only reads/writes to a specific partition. Changes from one data center are asynchronously replicated to the other data center only for availability or read access. In the event of a data center outage, there may be some data loss because the replication is occurring asynchronously. Traditional active-active with partitioned data approaches require significant additional technology, configuration, and coordination for this type of implementation. Typically, this is a complicated and difficult configuration to set-up, deploy, and manage. 13

14 ACTIVE-ACTIVE: PARTITIONED DATA & ACCESS USING NuoDB NuoDB supports this deployment approach without needing any additional technologies, special configuration, or coordination. In addition, NuoDB uses acknowledgement of transaction commits to preserve data durability within and across environments. This means that, in the event of a data center outage, NuoDB will suffer no data loss except for in-flight transactions. In each data center, the application only reads/writes to a specific partition. The data is replicated to the other data center for availability or read access. In the case of a network partition between data centers, by default, NuoDB preserves consistency and will automatically shutdown database processes in one data center. It is possible to configure NuoDB to not automatically shutdown database processes on a network partition, but NuoDB will not be able to resolve any inconsistencies between data centers when the network partition is resolved. 14

15 ACTIVE-ACTIVE: TRANSACTIONAL CONSISTENCY In this scenario, two data centers are actively running an application that requires maintaining transactional consistency across the data centers. Data consistency across data centers is maintained using Two-Phase Commit. If either data center suffers an outage, the other data center may continue to fully operate as normal. If the network communication between the data centers goes down, the transactions requiring global consistency (using Two-Phase Commit) will fail. Unfortunately Two-Phase Commit is prohibitively inefficient with regards to latencies and concurrencies for multi-data-center use cases. 15

16 ACTIVE-ACTIVE: TRANSACTIONAL CONSISTENCY USING NuoDB NuoDB supports this deployment approach without needing any additional technologies, special configuration, or coordination. As in the previous example, NuoDB uses acknowledgement of transaction commit to preserve data durability within and across environments. Upon network partition, NuoDB will automatically shut down the minority portion of the database in order to preserve consistency. Upon a network partition, by default, NuoDB will shut down the minority portion of the database in order to preserve consistency. 16

17 ACTIVE-ACTIVE: CONFLICT RESOLUTION The configuration is equivalent to the previous example. However, if the network communication between the data centers goes down, both data centers will continue to operate normally and preserve consistency within their local environments. Once network communication is restored, the two databases will re-sync, resolve conflicts, and restore global data consistency. Traditional active-active approaches require significant additional technology, configuration, and coordination for this type of implementation. Typically, this is a complicated and difficult configuration to set-up, deploy, and manage. 17

18 ACTIVE-ACTIVE: CONFLICT RESOLUTION USING NuoDB A priority future capability of NuoDB is to support the ability to self-heal and resolve consistencies upon restoration of a network partition. With this option, customers will be able to choose to maintain availability within each data center while sacrificing global consistency during the network communications outage. Upon network partition, NuoDB will continue to run and preserve consistency within the local environment. Upon restoration of network communication, the two databases will re-sync and resolve any conflicts to restore global consistency. 18

19 CONFIGURATION BENEFITS AND COSTS The following table lists the benefits and costs for each of these configurations: Reliability: No Down Time Utilization Reliability: Effectively Handle Network Unreliability Cost: Application Logic to Partition Data ( Sharded ) Cost: Application Logic for Conflict Resolution Cold Standby X X N/A N/A N/A Warm Standby X X N/A N/A N/A Hot Standby X N/A N/A N/A Hot Standby (with RRS) Active-Active (data partitioned) Active-Active (transactional consistency) Active-Active (conflict resolution) PARTIAL N/A N/A N/A X X X N/A X 19

20 ACTIVE-ACTIVE WITH NuoDB: A STRAIGHTFORWARD SOLUTION NuoDB is designed to provide active-active capabilities while maintaining transactional consistency capabilities as a single logical database. The following are some example NuoDB use cases: Backup Data Center Run NuoDB in a second data center with minimal resources, allowing additional resources to be rapidly added to the second data center in the event that it needs to go live. Public Cloud with Local Backup Run the application entirely on a public cloud while keeping an always-updated copy of the data on-premises. Public Cloud High Availability Run NuoDB across multiple Amazon Web Services (AWS) regions to provide availability in the case of an AWS region outage. 20

21 Twinned Data Center with Active-Active Functionality Run NuoDB across two data centers with live applications in both locations simultaneously, allowing load balancing, database capacity rebalancing during peak usage times, failover, and optimization of each data center to process certain types of workloads (e.g. back-office versus front-office, administration versus general transactions processing). Hybrid Cloud Run NuoDB simultaneously in a public cloud and in an on-premises data center. For example, an organization may run front-end services (e.g. SaaS/Mobile applications) from a public cloud and back-end activities in an on-premises deployment. Simultaneous Execution on Multiple Public Clouds Run NuoDB across multiple clouds (e.g. AWS and Azure) and dynamically favor one cloud for reasons of cost or performance. A high-priority future goal is to allow full active-active operations during network partitions, giving customers the option to provide high availability during a network outage, and resolve global inconsistencies upon restoration of the network. 21

22 LEARN MORE ABOUT NuoDB: About NuoDB NuoDB s elastic SQL database for cloud applications helps customers get applications to market faster and reduce their total cost of ownership. Software vendors and ecommerce companies rely on NuoDB to obtain the combination of scale-out simplicity, elasticity, and continuous availability that cloud applications require, with the transactional consistency and durability that databases of record demand. As a result, customers can capitalize on modern technologies such as cloud computing and containerization to ensure their applications are ready for today s evolving expectations, as well as any future requirements. NuoDB is headquartered in Cambridge, MA, USA, with offices in Dublin and Belfast. For more information, visit nuodb.com. info@nuodb.com +1 (617) NuoDB, Inc., all rights reserved. EB DRAA SK 22