In this article, we mention AWS US East mainly as an example. You can host your application, database in any desired region. The same concepts explained in this article should apply to other regions.
High availability in very simple terms involves running multiple copies of your application code on servers that are guaranteed to fail independently. This typically will involve running at least two copies of the application code in two different regions or availability zones (although we cannot guarantee availability zones fail independently as such we recommend regions) that are close enough to not impose a heavy latency tax on connectivity. In database terms, you probably are familiar with replication but that alone simply will not ensure high availability if the instances to which the master node is replicating to is within the same data center and in some cases even on the same rack. It is like running several instances of your app code on the same server or two virtual machines in the same datacenter. Such a setup will not be considered highly available.
When adding servers to NodeChef, you have the option to choose the region and even the availability zone in the case of AWS and other cloud providers that support availability zones. We recommend you add servers from max two separate regions. These two regions must be close to each other distance wise. For example, AWS supports two separate US-East regions such as US East (Ohio) and US East (N. Virginia). In the case of a provider like DigitalOcean, you have the option to choose between New york 1, 2 and 3. You do not have to explicitly select an availability zone when using AWS as NodeChef by default will automatically spread your servers across multiple availability zones in the same region.
Once you add servers from multiple regions, for application containers, NodeChef by default will automatically distribute your instances on these servers in a least number of containers per server fashion. This ensures if container 1 is running on server 1, the next container will be running on server 2 and then it loops back to server 1 as you add more containers. Note, you can choose to run a single container per server or multiple containers per server. In the next part of this article series that deal with scalability, we dive into this.
For databases by default, Only a single instance of the database server is run on each server. For databases such as MySQL and PostgreSQL, you can run a minimum of two instances to achieve high availabilty. For example, if you want a Primary and secondary MySQL database setup with automatic failover managed by NodeChef. You will add one server in US East (N. Virginia) and another server in US East (Ohio). After the servers are added, you can create your database and choose to add 1 hot standby.
In the case of MongoDB replica sets however, you need at least 3 instances to run a replica set whether two data nodes and an arbiter or 3 data nodes. If you are fine with having two of your servers in one region spread across two different availability zones and the other in another region, then you can add two servers in N. Virginia and the other in Ohio. However, we cannot guarantee multiple availability zones will not all fail at the same time since we have no insights into how truly independent they are. Another option you can use in this case is to get your first two servers in US East from AWS and then get the third server from another cloud provider in the same US east area. For example you can select to use Vultr's New jersey datacenter to host your 3rd database server.
Runnig multiple instances of your application containers.
Let's say you have now added multiple servers and you already provisioned your app on NodeChef and want to add another instance of the app. On the dashboard, navigate to deployments → deployed apps. Find your app listed under the table. Under App containers, select the drop down and change the number of instances to two or the desired number of instances as seen below. Click on Cluster Actions → Reconfigure. Note, by default, NodeChef will not automatically add new servers in this case and will simply distribute the containers on your already available servers. You can however change this behaviour and instruct NodeChef to provision new servers on your cloud account when you add containers if required. We will cover this in the next part of this article series that deal with scaling. This example assumes you already have added servers and simply want to run multiple instances for high availability.
Running a MongoDB replica set
For MongoDB instances, after you have added the servers, and creating the MongoDB instance for the first time, you can select the replication setup and then launch as seen below. You can also add replication after you have already created the database initially as a single node.
If you have already created the database as a single node, navgiate to deployments → deployed apps. Click on Cluster Actions and then choose the replica set configuration you want. You can choose between +1 data node and arbiter or +2 data nodes.
If you try to setup a replica set and do not have at least 3 servers, the request will fail with an error prompting you to add more servers.
Running a primary and secondary setup for MySQL and PostgreSQL databases.
If you have already created the database instance and want to add the secondary, you can navigate to deployments → deployed apps. Under the database section. Change the number of instances of the database to two and click on Cluster Actions → Reconfigure.
If you are creating the database for the first time, then you can select the number of hot standby's and the primary and secondary setup will be created in one shot.
We hope this article provided you with good information on setting up a highly available application or database setup. You can always contact us if you have any further questions.