Variant 3: Inherent HA with ISC DHCP

After using VRRP on your firewall/router to take care of routing, the next issue is DHCP. Most corporate networks use DHCP for dynamic distribution of addresses; frequently, dhcpcd is used in a typical failover configuration. ISC DHCPd comes with a handy feature that removes the need for Pacemaker. Much like the VRRP protocol, it lets you create "DHCP pools." The core idea behind these pools is that multiple DHCP servers take care of the same network; a DHCP request can therefore in principle be answered by more than one DHCP server. To avoid collisions in the addresses, the two DHCP servers keep their lease databases permanently synchronized.

In the case of failure of one of the two servers, a second node is still left. The pool-based solution thus offers the same kind of availability as a solution based on a cluster manager, but with considerably less effort and less complexity. The same rules apply as for VRRP; the combination of VRRP on one hand and a DHCP pool on the other gives admins a complete firewall/router in a high-availability design without the disadvantages of Pacemaker.

Variant 4: Database High Availability with Galera

Galera is sort of the latest craze with regard to databases and the way in which databases implement high availability (Figure 3). The solution is based on MySQL; basically, it extends MySQL in a modular way by adding a multi-master feature. Although Galera is not the only tool that can do this, it is, at the moment, the one with the biggest buzz factor. Galera is a seminal new technology because it solves almost all the problems inherent with high availability.

Figure 3: Galera ensures seamless high availability at the MySQL layer, but it takes a load balancer to make the program easy to use for most applications.

The first problem with high-availability setups is usually highly available data storage. Classic setups resort to tools like DRBD; however, they suffer from limitations. Most programs of this kind do not offer particularly good horizontal scaling and do not go beyond two nodes. Galera has built-in redundant data storage and ensures that data to be stored is always written across multiple nodes to the local MySQL instances before it declares a write to be complete. This means that each always exists several times; if one node fails, the same data is still available elsewhere.

The second typical HA problem is the question of access to the software. Classic MySQL replication uses a master/slave system in which writes only occur on the respective master server. Galera is different: Each MySQL instance that is part of a Galera cluster is a full MySQL server that can handle both reading and writing data.

Depending on the client software, this solution only has one inherent disadvantage: Most clients only let you specify a single host when you choose a database. The Galera Load Balancer provides a remedy for this by accepting all available Galera servers as a back end and forwarding connections from the outside to one working MySQL server.

The same problem affects the Galera load balancer as previously mentioned in the HAProxy section: The glbd daemon can be difficult to make highly available without Pacemaker. However, a Pacemaker setup that only runs one IP for the service and the glbd itself is comparatively easy to maintain and uncomplicated. Compared with MySQL replication with a combination of Corosync and Pacemaker, Galera is certainly more elegant and better designed, and it scales seamlessly, especially in the horizontal direction, which is fairly difficult with typical MySQL replication. (See the "Special Case: Ceph" box for another alternative.)

Special Case: Ceph

On the fringe of HA solutions is Ceph [3]. Ceph is not unknown in the IT community. I include it here primarily because Ceph has taken a completely new approach in terms of high availability, and Ceph inventor Sage Weil is unceasing in his drive to put this message across. Unlike virtually any other application, Ceph is in fact designed not for client/server communication but for a configuration that takes place between a client and a cluster. A Ceph cluster offers more than one point of contact to the clients; each monitoring server is authorized to provide information to the client (Figure 4).

Figure 4: Ceph is not a candidate in this article, but of all the programs I looked at, it is the most sensible option.

Because the part of Ceph that stores data is designed to be decentralized, the client talks to many individual object storage devices (OSDs). All told, the extremely decentralized Ceph concept ensures that additional software such as load balancers is not necessary. One thing is clear: The solution built into Ceph is highly specific in terms of Ceph; the authors of other software, however, would do well to look at the concept behind the object storage solution in more detail. Some simple abstraction could help to provide high availability seamlessly for many other services without a HA cluster manager.

Conclusions

If you prefer not to use Pacemaker, you have several options for working around the unloved cluster manager. For new protocols, finding an alternative is usually not a problem. (Galera is an excellent example.)

Things get complicated when you need to make a typical legacy protocol highly available. Although load balancers provide good service, the load balancer itself is a single point of failure that typically gives Pacemaker a way to creep back into the setup. However, Pacemaker setups for failing over a load balancer are not very complex – much less so than setups that rely exclusively on Pacemaker.

Pacemaker is definitely not dead: In fact, it will be necessary for quite a while, especially for legacy components. However, the solutions featured in this article, with Galera and Ceph first and foremost, clearly show that the IT world is headed elsewhere.