NoSQL and the Hybrid Cloud
NoSQL and the Hybrid Cloud
Join the DZone community and get the full member experience.Join For Free
If a NoSQL database can be deployed on-premise or it can be deployed in the cloud, why can’t it be deployed on-premise and in the cloud? It can, and it should. This article highlights a variety of hybrid cloud use cases for NoSQL database deployments.
Master / Slave
The master deployment resides on-premise and the standby deployment resides in the cloud, or vice versa.
Active Data Center / Standby Cloud
Active Cloud / Standby Data Center
It’s one thing to fail over a single instance; it’s another to fail over an entire deployment. The active deployment can reside on-premise and the standby deployment can reside in the cloud, or vice versa. In the event that the active deployment is unavailable, it can be failed over to the standby deployment.
Operational versus Analytical
It’s separation of concerns applied to real life. The operational applications read and write to one deployment while the analytical applications read and write to another deployment. The operational applications might read and write to the on-premise deployment while the analytical applications read and write to the cloud deployment, or vice versa.
The challenge lies in copying data from the active deployment to the standby deployment. While it is possible export and import the data, the most efficient mechanism is one-way synchronization with incremental updates. This is possible with Couchbase Server via cross data center replication (XDCR).
This is high availability at the infrastructure level. It can survive the failure of a single deployment.
The master deployment resides on-premise, but can expand to include nodes running in the cloud.
Rather than maintaining separate deployments on-premise and in the cloud, there is a single deployment that includes both the on-premise deployment and the cloud deployment. The nodes deployed in the cloud are running on standby. If the resources of the on-premise deployment are no longer sufficient, it can be extended to include standby nodes running in the cloud.
The challenge lies in being able to add and remove standby nodes running in the cloud on demand. This is possible with Couchbase Server because nodes can be added with activating them. As an alternative, an administrator could rely on the command line interface (CLI) to add standby nodes on demand. If it necessary to extend the on-premise deploy to the cloud, an administrator can activate the standby nodes by performing a rebalance operation.
Rather than relying on-way synchronizing and incremental updates between a master on-premise deployment and a slave cloud deployment, multiple cloud deployments rely on two-way synchronization in a multi-master topology. In addition, the individual cloud deployments can continue to rely on one-way synchronization and incremental updates to synchronize with an on-premise deployment.
Like a master / slave topology, the challenge lies in copying data from the active deployment to the standby deployment. However, a master / master topology requires two-synchronization with incremental updates. Couchbase Server supports both one-way synchronization and two-way synchronization with incremental updates via cross data center replication (XDCR).
This is high availability at both the infrastructure level and the enterprise level. It can survive the failure of multiple deployments. That’s because it can survive the failure of multiple cloud providers. The enterprise is no longer beholden to a single cloud provider. The enterprise is no longer susceptible to vendor lock-in. It not only increases infrastructure availability, it increases business agility.
The hybrid cloud is on its way; lead by Red Hat with its open hybrid cloud vision. The NoSQL database of the future must be ready for it.
Published at DZone with permission of Shane Johnson , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.