Many cloud providers warn users that they need to reboot certain instances for maintenance. Couchbase Server ensures these reboots won’t disrupt your application. Take the following steps to make that happen: Install Couchbase Server on the new node. From Couchbase Web Console, add the new node to the cluster. From 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 Server data and configuration to EBS creates a reliable medium of storage. Using EBS is definitely not required, but you should make sure to follow the best practices around 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 that will 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 own 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. This can be accomplished by using a dynamic DNS service such as DNSMadeEasy which will allow you to automatically update the hostname 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.
As a rule, you should set the hostname before you add a node to a cluster. You can also provide a hostname in these ways: when you install a Couchbase Server node or when you do a REST API call before the node is part of a cluster. You can also add a hostname to an existing cluster for an online upgrade. If you restart, any hostname you establish with one of these methods will be used.
For Couchbase Server 2.0.1 and earlier you must follow a manual process where you edit configuration files for each node, as described for Couchbase Server in the cloud.
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 to only 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 4.x.x, the general recommendation is to use similar instance types for all the nodes in the cluster, but with Multidimensional Scaling you could take advantage of different instance types for Index and Query nodes as these nodes require less storage but more CPU cores and more RAM, and for data nodes choose similar instance types.