Configurations overview and diagrams

Configurations overview and diagrams

Introduction

In this chapter I will describe configuration of each system, that will be built in next posts. Here I will not describe configuring, just overall layouts, and differences between them.
We will use four versions of CouchDB deployment, cause it has differences in configurations, API interfaces, requirements and abilities.

• Single node: installed to Fedora Workstation. There is no clusterization, just one instance of CouchDB.
• Cluster of three nodes: three instances each inside Docker containers, configured to work together like one system. Also, we will install container with load balancing proxy (HAProxy).
• Big cluster: 10 instances each in own Docker container connected in one cluster. It requires additional configuration and understanding advanced methods of replication and data processing, like: map reduce, concurrent data access, synchronization, etc...
• Two clusters: 2 clusters, each with 3 nodes, each node in own Docker container. In process will be described data replication and synchronization between two different databases.

Details about each configuration

Single node 

Installation of CouchDB inside native Fedora Workstation.
To access will be used loopback adapter(localhost, 127.0.0.1)

Base urls:

• http://localhost:5984/ provides access to data processing APIs 
• http://localhost:5986/ provides access to admin part of CouchDB, for configuring node and access system databases

Cluster of three nodes

Three Docker containers deployed from one image with own configurations. Uses internal network of Docker. Additionally, one HAProxy container to provide load balancing of requests(from frontend port 5984 to same ports of each CouchDB container). It represents real configuration on one machine using virtualization. Diagram of this configuration:

To link nodes in one cluster we should use same Erlang cookie in each node, because CouchDB uses native distribution system of Erlang to provide interaction between nodes. This cookie should be secured, because can be used for intrusion to your system.
For interaction also used TCP ports 4369(Erlang Port Mapper Daemon) and range from 9100 to 9200(ports which will be mapped between nodes).

Base urls:

• http://172.17.0.5:5984/ provides access to data processing APIs, through load balancing proxy, it will send requests from frontend interface to backend servers interfaces by queue. It uses to balance loading, open your database to the world and protect service ports(5986) of nodes.
• http://172.17.0.2:5984/, http://172.17.0.3:5984/, http://172.17.0.4:5984/ provides access to data processing APIs, directly to each node. Data received by one of these hosts will be replicated between other nodes.
• http://172.17.0.2:5986/, http://172.17.0.3:5986/, http://172.17.0.4:5986/ provides access to admins part of each CouchDB node, for configuring exactly this node, but not others. Even if you create database through this port it will not be replicated to others, exception is databases under http://hostname:5986/_dbs path, here you can access clustered databases.