Cloud Deployment Considerations
Couchbase Server can be deployed on the following cloud computing platforms: Amazon Web Services (AWS), MS Azure, and Docker, an open-source project.
Before you can deploy Couchbase Server in a cloud, you have to take into consideration certain aspects of its operation.
Many cloud providers warn users that they need to reboot certain instances for maintenance.
To make sure that instance reboots of Couchbase Server do not disrupt your applications, take the following steps:
Install Couchbase Server on the new node.
From the Couchbase Web Console, add the new node to the cluster.
From the Couchbase Web Console, remove the node that you wish to reboot.
Rebalance the cluster.
Shut down the instance.
Dealing with local storage is not very much different than a datacenter deployment. However, EC2 provides an interesting solution: using the EBS storage you can prevent data loss when an instance fails. Writing Couchbase data and configuration to EBS creates a reliable medium of storage.
Using EBS is not required, however, follow the best practices while performing backups. Keep in mind that you will have to update the per-node disk path when configuring Couchbase Server to the point you have mounted an external volume.
When you use Couchbase Server in the cloud, server nodes can use internal or public IP addresses. Because IP addresses in the cloud can change quite frequently, you can configure Couchbase Server to use a hostname instead of an IP address.
For Amazon EC2, Amazon-generated hostnames are recommended. These hostnames automatically resolve to either an internal or external address.
By default, Couchbase Server uses specific IP addresses as a unique identifier. If the IP changes, an individual node will not be able to identify its address, and other servers in the same cluster will not be able to access it.
To configure Couchbase Server instances in the cloud to use hostnames, follow the steps later in this section. Make sure that your hostname always resolves to the IP address of the node by using a dynamic DNS service such as DNSMadeEasy. The dynamic DNS service will allow you to update the hostname automatically when an underlying IP address changes.
The following steps completely destroy any data and configuration from the node, so you should start with a fresh Couchbase Server installation. If you already have a running cluster, you can rebalance a node out of the cluster, make the change, and then rebalance it back into the cluster.
Nodes with both IPs and hostnames can exist in the same cluster.
When you set the IP address using this method, you should not specify the address as
localhost or 127.0.0.1 as this will be invalid when used as the identifier for multiple nodes within the cluster.
Instead, use the correct IP address for your host.
It’s important to make sure you have both allowed AND restricted access to the appropriate ports in a Couchbase Server deployment. Nodes must be able to talk to one another on various ports, and it is important to restrict both external and internal access only to authorized individuals. Unlike a typical datacenter deployment, cloud systems are open to the world by default, and steps must be taken to restrict access.
Prior to Couchbase Server 4.x.x, the general recommendation was to use similar instance types for all the nodes in the cluster. With Multi-dimensional Scaling, you can take advantage of different instance types for Index and Query nodes, which require less storage but more CPU cores and more RAM. For Data nodes, choose the similar instance types.
It is very easy to deploy Couchbase Server in the cloud. Regarding software, there is no difference whether you install Couchbase Server on bare-metal or a virtualized operating systems. On the other hand, the cloud management and deployment characteristics require a separate discussion on the best ways to use Couchbase Server.
For the purposes of this discussion, the cloud is referred to as Amazon’s EC2 environment, since that is by far the most common cloud-based environment. However, the same considerations apply to any environment that acts like EC2 (an organization’s private cloud, for example).
In terms of the software itself, EC2 has been tested extensively and a variety of issues, exposed by sometimes unpredictable characteristics of this environment, have been encountered and resolved.
When deploying within the cloud, consider the following:
Local storage being ephemeral.
Server IP addresses of changing from runtime to runtime.
Security groups and firewall settings.