TO ACTIVE-ACTIVE - NuoDBgo.nuodb.com/rs/139-YPK-485/images/DR-Ebook_FINAL.pdf · ebook from disaster recovery to active-active: nuodb and multi-data center deployments

EBOOK

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

EBOOK FROM DR TO ACTIVE-ACTIVE

2

INTRODUCTIONTraditionally, 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.

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.

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.

...organizations are headed for a future where multi-data center deployments are no longer just for disaster recovery...


3


3

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.

Achieve disaster resilience with continuous service availability during data center failures and disasters.

Optimize cloud economics by deploying workloads across various cloud and non-cloud environments.

Support geographically distributed access with low latency guarantees for mobile users, branch offices, and backbone data centers.

When implementing next-generation, multi-data-center strategies, CIOs and IT strategists commonly have multiple objectives:

MULTI-DATA CENTER OPPORTUNITIES


4

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 active-active 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:

DEPLOYMENT SCENARIOS AND USE CASES

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


5

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.

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 in-memory 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.

NuoDB ARCHITECTURE

Durability

Storage Manager (SM)SM SM

Not-yet-provisioned,Available Node

TE TE

AA

Query Processing

Storage


6

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. This scenario generally results in some data loss depending on the frequency of the backup.

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.

COLD STANDBY COLD STANDBY USING NuoDB


7

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.

WARM STANDBY


8


8

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. 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.Minimal Disaster Recovery (DR) protection requires a single SM in

a DR site to maintain a fully redundant copy of the database.

WARM STANDBY USING NuoDB


9

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.

HOT STANDBY


10


10

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.

HOT STANDBY USING NuoDB

In this scenario, the peers in the Hot Site are active so require no recovery time in the event of a disaster.


11

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.

HOT STANDBY WITH READ REPLICAS


12


12

Because NuoDB is always active, across all database nodes, it can easily be used to provide read (and write) access in the remote location.

HOT STANDBY WITH READ REPLICAS USING NuoDB

Deploying applications in the remote site allows for read (and write) replicas in the remote location.


13

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.

ACTIVE-ACTIVE: PARTITIONED DATA & ACCESS


14


14

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

ACTIVE-ACTIVE: PARTITIONED DATA & ACCESS USING NuoDB

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.


15


15

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.

ACTIVE-ACTIVE: TRANSACTIONAL CONSISTENCY


16


16

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 a network partition, by default, NuoDB will shut down the minority portion of the database in order to preserve consistency.

ACTIVE-ACTIVE: TRANSACTIONAL CONSISTENCY USING NuoDB

Upon network partition, NuoDB will automatically shut down the minority portion of the database in order to preserve consistency.


17

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.

ACTIVE-ACTIVE: CONFLICT RESOLUTION


18


18

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.

ACTIVE-ACTIVE: CONFLICT RESOLUTION USING NuoDB

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.


19


19

CONFIGURATION BENEFITS AND COSTSThe 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) PARTIAL N/A N/A N/A

Active-Active (data partitioned) X

Active-Active (transactional consistency)

X X N/A

Active-Active (conflict resolution) X


20


20

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.

ACTIVE-ACTIVE WITH NuoDB: A STRAIGHTFORWARD SOLUTION


21


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.


22


22EB DRAA 07173 SK

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.

[email protected] | +1 (617) 500-0001 | www.nuodb.com

© 2017 NuoDB, Inc., all rights reserved.

LEARN MORE ABOUT NuoDB:

http://nuodb.com

mailto:info%40nuodb.com?subject=

http://www.nuodb.com

http://www.youtube.com/nuodb

http://www.linkedin.com/company/nuodb

http://www.linkedin.com/company/nuodb

http://www.twitter.com/nuodb

http://www.nuodb.com/twitter

http://www.github.com/nuodb



Documents

TO ACTIVE-ACTIVE - NuoDBgo.nuodb.com/rs/139-YPK-485/images/DR-Ebook_FINAL.pdf · ebook from disaster recovery to active-active: nuodb and multi-data center deployments