The present disclosure generally relates to high availability computing systems.
Computational theory divides the resources to solve computation problems into two basic categories: computation time, and memory space. With commercial off-the-shelf components, a system engineer may add computer resources to a system in a so called “vertical” direction, for example, by adding faster central processing units (CPUs) or graphical processing units (GPUs), increasing the CPU cache size or number of cache levels, adding additional volatile random-access memory (RAM), increasing the capacity of non-volatile storage devices (e.g., hard-disk drives (HDDs), solid-state drives (SSDs)), etc. The off-the-shelf nature of many commercial components limits how many resources a system engineer can vertically add. For instance, a motherboard may limit the type or number of CPUs which can be included in the system, or the CPU architecture may limit the amount of volatile random-access memory (RAM) that can be recognized in a system.
Thus, out of necessity or cost, a system engineer may add computer resources to a system in a so called “horizontal” direction by adding additional server computers (hereinafter “servers”) to an interconnected distributed system of multiple servers. The interconnectedness of the system is often provided by off-the-shelf computer networking components. For example, Gigabit Ethernet as defined by the Institute of Electrical and Electronics Engineers' (IEEE) 802.3-2008 standard is sometimes used to connect a rack of servers together.
High availability (HA) computing systems aim to maximize the level of uptime of a system. With a horizontally scaled system, not only are the servers scrutinized as a potential point of failure, but the networking equipment connecting the servers are also scrutinized as a potential point of failure. In order to minimize the risk of system failure, redundant servers and/or networking devices are included in system designs.
Detection and mitigation of failure points are critical part of high availability computing systems. However, both the construction and administration of such functionality is often difficult and complex. Moreover, many community driven software projects may not take into account the variety of underlying network configurations used in horizontally scaled high availability systems.
FIGS. 1A and 1B are block diagrams illustrating a network configuration for an existing distributed system 100 available in the background art. The system 100 can be regarded as a high availability (HA) computing system. The system 100 includes a plurality of elements for redundancy. For example, the servers 106, 108, and 110, and network switches 102 and 104 may provide redundancy to increase the level of uptime of the system 100. The servers 106, 108, and 110 may provide functional redundancy amongst one another. The network switches 102 and 104 may also provide a level of redundancy amongst one another by providing separate connectivity paths between the servers 106, 108, and 110 and the broader networked world (not shown).
The servers 106, 108, and 110 are each of which is respectively communicatively coupled to two independent network switches 102 and 104. On the first network switch 102, the servers 106, 108, and 110, each have an Internet Protocol (IP) address of 10.0.2.x on the interface coupling the servers 106, 108, and 110 to the network switch 102. For instance, the server 106 has an IP address of 10.0.2.1 assigned to the interface that connects to the network switch 102, as so forth. The interfaces connecting the servers 106, 108, and 110 to the second network switch 104 have the format of 10.0.1.x. Both the 10.0.2.x and the 10.0.1.x address formats are indicted in FIG. 1A with the notation on the classless inter-domain routing (CIDR) notation—respectively 10.0.1.0/24 and 10.0.2.0/24. Thus, the server 106 has an IP address of 10.0.1.1 assigned to the interface that connects to the network switch 104, and so forth.
As shown in FIG. 2B, one communication path between the server 108 and the server 106 extends through the network switch 102 on the 10.0.2.0/24 subnet. The second communication path extends from the server 108 through the network switch 104 on the 10.0.1.0/24 subnet to the server application 154 running on the server 106. Again, assuming that the network switch 104 is grey to indicate that the network switch has experienced the first network switch failure in the system 100, the client application 152 monitors the two communication paths to determine when the network switch failure has occurred in order to mitigate the problem.
The application-specific construction of such a mechanism provided by existing solutions involve modifications to both the client application 152 and the server application 154. Moreover, in some cases, such an application-specific implementation may be limited to the specific network configuration (e.g., two independent network switches with a server application hosted on a first server and a client application hosted on a second server).
Thus, monitoring network switches for the redundancy desired in the depicted system 100 sometimes requires significant hardware or software modifications, thereby making the construction of such functionality difficult.
In attempting to reduce the complexity of redundant network switches, various solutions have been proffered. In one typical example, the domain name system (DNS) is configured as a round-robin system. Another DNS solution involves a DNS entry with a low time to live (TTL) and monitoring which IP address are responsive. Sometimes software application cache DNS resolution, and thus both DNS-based solutions may be inadequate solutions. Another typical example involves using a virtual IP address, but such a solution can reduce effective bandwidth and may require network reconfiguration. In another example, network interface card (NIC) bonding and the link aggregation control protocol (LACP) are used to aggregate the redundant communication paths into a single logical link, but link aggregation is complex and does not afford application level granularity.