Linux How To's | Bash Scripting | Python

Thursday, 12 May 2016

Note: This article was published by me in 'Open Source for You Magazine' - March 2016 Edition.

Having set up a DHCP server, I am planning to deploy a DNS server in our network. It is always a better option to have DNS and DHCP on the same server, so that IP addresses allocated by DHCP server to a particular host can be updated in DNS database at the very moment. By some means, if this DNS-DHCP server goes down, it impacts whole production environment adversely. As a preventive measure, we have to introduce secondary DNS-DHCP server, which has to be configured in high availability mode (HA), so that if primary server goes down, secondary server takes over and cater the incoming requests.

PowerDNS is our prime choice for configuring the authoritative DNS server, with MySQL database as backend, as this combination has its own merits. This setup handles incoming queries, looks through DNS records in MySQL database and provides appropriate responses. The DNS servers being in HA, the databases in both the servers must always be kept in sync. Moreover, both the DHCP servers work in active-active mode, such that they divide IP address pool among themselves and cater incoming DHCP requests working together. As a result, there are multiple read/write happening from both the server in their own MySQL databases. In order to keep both the databases in sync, there has to be such mechanism that if any server makes any changes in database, it should be reflected in the database of another server and they maintain same DNS records.

To create a high availability environment, as mentioned above, MySQL provides two solutions – MySQL replication and MySQL Cluster. Master-Slave replication, wherein we have one read/write and one or more read-only slaves, is not useful in this scenario, as the replication is one way (from Master to Slave). While MySQL Master-Master replication is one of the alternatives, it is not a good choice, especially when there are multiple masters receiving write requests simultaneously. Circular replication (A to B, B to C, C to D, and D to A) has a big disadvantage that if any node fails, replication halts for subsequent nodes in the chain.

On the other hand, MySQL Cluster is-

In-memory (or main-memory) database system – relies on main memory for data storage, management and manipulation, to achieve better performance while querying the data.

Shared-nothing architecture database – stores data over multiple independent data nodes in a cluster, instead of shared data storage, with no single point of failure (SPOF).

Distributed database system – stores portions of database on multiple nodes in the cluster, which is managed by central distributed database management system. So that, even if any node goes down, data integrity is maintained. Moreover, scaling becomes a handy task with almost 99.99% availability.

Synchronous replication – database updates are synchronously replicated between all the data nodes in the cluster, guaranteeing data availability upon node failures.

Cluster Components

Management Node/Server:

It maintains the cluster’s global configuration file and provides cluster information whenever required. It also maintains logs of events happening in the cluster. Management client in the management node does all the administrative work, like starting/stopping nodes, starting/stopping backups and checking cluster status.
MySQL Nodes/Servers:

These servers contain local configuration files, they run mysqld daemon and group together to form a cluster, thus achieving high performance (due to parallelism) and high availability. These nodes cater all incoming queries, communicate with data nodes and provide the application access to the cluster.

Data Nodes:

These nodes run ndbd daemon and are responsible for data storage and retrieval. Multiple data nodes come together to provide storage for entire cluster, so that clients see them as a single database. Besides data storage, they keep monitoring other data nodes in the cluster and inform the management server in case of failures.

How does it work..?

At the heart of the MySQL cluster, there lies NDB (Network Database) storage engine, which actually is responsible for high-available environment and data redundancy. In the basic scenario, we have an application that sends a query, usually an INSERT/UPDATE/DELETE-like SQL statements, to MySQL server. In MySQL cluster, one of the MySQL server running NDB storage engine (or NDBCluster), which receives incoming SQL queries and communicates with data nodes to store the data. After confirming successful writing of the data into the data nodes, MySQL server acknowledges the application with an OK status.

In order to keep data available even after a node failure, whole data is divided into number of chunks – ‘Partitions’, and number of partitions is equal to number of nodes present in cluster. So, each node has to store one partition along with copy of a partition – ‘Replica’. Number of the replica is mentioned in the configuration file on Management node. MySQL cluster boasts about its 99.999% availability and replicas are key elements.
Handling Failures

When a MySQL node fails, being a shared-nothing architecture, no other node (MySQL/Data or Management) in the cluster is affected, they will keep doing their tasks. It’s up to the application as it needs to manage to connect to another MySQL node in the cluster. On the other hand, if a data node fails, other data node in the cluster takes over the responsibility and due to data redundancy (replicas), data will also be available. While MySQL cluster takes care of node failures, you need to take care that failed data node wakes up as early as possible, as you never know when other node(s) will stop to work. Failure of Management node doesn’t hamper the setup much, as it only deals with monitoring and backup tasks, but then you might not be able to start/stop other cluster nodes. Having 2 management nodes is definitely a solution and will certainly help a lot.

Implementation

Considering that I have three subnets and I do not have any budget issues, I will opt to deploy 4 DNS-DHCP servers, out of which 3 will be primary for their respective networks and other will be secondary. I will have MySQL databases on all these 4 nodes (MySQL + Data nodes) and these are to be clustered for being in sync. For setting up MySQL cluster, I will need another two nodes to be configured as Management Nodes. So, the scenario is as below:

Any DBMS uses Storage engines or database engines to write, read, update or delete data from database. InnoDB is the default storage engine used by MySQL since its version 5.5, such that whenever a table is created without ENGINE clause, it would create an InnoDB table by default. With InnoDB, data is read and written from hard disk, where MySQL server runs, and hence it necessitates configuring the disks in RAID, to achieve data redundancy.

On the other hand, MySQL cluster uses NDBCluster engine, that uses network connectivity in order to access data spread across different data nodes (not on MySQL servers like InnoDB). Hence, while creating tables, one must explicitly mention NDBCluster storage engine in order to instruct MySQL servers that data has to be stored on the data nodes.