High Availability Architectures
Introduction
This section is aimed at Network Engineers and Implementers who need a High Availability solution at the network level.
Para lograr alta disponibilidad o HA (High Availability) en general existen una serie de tecnologias. En el caso de PDNS, la tecnologia mas efectiva a nivel de HA en el Internet es ANYCAST.
Warning
In this section, we discuss only the architecture of Resolvers and Authoritatives, regardless of whether the pdns-app application runs in the Planisys cloud or On-Premise.
In the following graphic, an example of HA for Resolvers is shown, from three different Datacenters, which can be located anywhere on the Planet.
For this, we must have at least a /24 network, which can be advertised on the Internet backbone through BGP from all the Datacenters in the Anycast network.
Warning
To implement services with HA anycast, they must be identical services, replicated or executing the same transactions over the Internet or an Intranet between Datacenters. Each IP used in that /24 network must be occupied in ALL the Datacenters by the SAME service. When a network is reserved for ANYCAST, IPs from that network cannot be used individually in just one of the Datacenters.
Note
In this section, we do not use the term Cluster, as clustering is implicit in all these special HA Architectures.
Anycast for Resolvers
For example, if we advertise the 179.63.249.0/24 network from 3 different geographical points (e.g., Planisys in Miami, Amsterdam, and San Francisco), we must set up the same IPs and services in all 3 Datacenters.
In the case of DNS Resolvers, it is a simple task, as the same DNS Resolver server must be installed with the same IP in all 3 Datacenters (e.g., 179.63.249.221). In this way, a client using our name resolution service on that IP will still be able to access it even if two of the three Datacenters or Routers are down.
The local-loop Internet service, ADSL, or Cablemodem of an end client on a computer/laptop/mobile/tablet that wants to access our IP 179.63.249.221 to resolve a name will still be able to do so even if two of the three Datacenters are down, without any impact or delay.
Note
En el caso de PDNS, los resolvers en modo Anycast de PDNS requieren de una 2da IP unica, nativa del Datacenter aparte de la 1er IP anycast que se repite en todos los Datacenters. Esta IP nativa es una IP de management para poder seguir conectado cada resolver al sistema central a traves del pipeline CI/CD y p.ej. recibir informacion sobre dominios a blacklistear.
Anycast for Authoritatives
This case is very similar to that of Resolvers.
If we have several Datacenters, it is very convenient to have anycast IP addresses for at least 1 authoritative server.
The difference between having 1 anycast IP in 3 Datacenters for 1 authoritative server, and having 3 different IPs in each Datacenter for 3 authoritative servers, is that in the anycast case, if one Datacenter goes down, the BGP convergence time in the backbone is usually very short, just a few milliseconds. On the other hand, in the case of different IPs, if one fails, the device timeout determines how long it takes to switch to a second authoritative IP if the first one does not respond (which can take several seconds).
Note
En el caso de PDNS, los autoritativos en modo Anycast de PDNS requieren de una 2da IP unica, nativa del Datacenter aparte de la 1er IP anycast que se repite en todos los Datacenters. Esta IP nativa es una IP de management para poder seguir conectado cada autoritativo al sistema central a traves del pipeline CI/CD y p.ej. imprimir cambios de registros en una zona, o agregar/quitar una zona. Es decir, los 3 autoritativos ejecutan las mismas tareas y son identicos excepto por la ip nativa.
Resolver Edge
In the case of having a large Edge Capillarity (i.e., presence in many Datacenters around the Planet), it is possible to achieve very short latency to our resolvers and authoritatives in any geography.
For example, Google’s resolvers 8.8.8.8 and 8.8.4.4 come from edge advertisements in many Datacenters, from the 8.8.8.0/24 and 8.8.4.0/24 networks in anycast mode.
These edge advertisements give the impression of proximity, e.g., 10ms, compared to servers with unicast IPs that, if they are in another country or across an oceanic hop, can exceed 200 milliseconds.
Warning
La resolucion de nombres en baja latencia y la alta disponibilidad de los resolvers y autoritativos, son la clave de la mejora de experiencia de navegacion en Internet, y tambien clave en los rankings SEO. Por otro lado, hay servicios criticos que requieren alta disponibilidad, aunque esta no sea anycast (p.ej. presencia en varios Datacenters de varias nubes publicas con diferentes IPs).
Note
If you want to locate a service in a public cloud like AWS, GCP, or Azure, you must take into account that an Elastic IP from the provider will always be Unicast, meaning the service is located in a single geographical point. Since these public clouds have HA elements in their Datacenters, they can be used for some nameservers, and in parallel, Anycast nameservers can be used as long as you have a /24 network available and the possibility of announcing it from at least two routers in two different Datacenters.
Mirroring Example in Dual Datacenter
This section is aimed at companies that manage or own Datacenters.
In this case, we have two Datacenters, A and B, interconnected through a Management VLAN, where the PDNS servers reside in one of them. Then for each resolver and each authoritative in A, there is an equivalent in B. Each resolver and each authoritative has two IPs: one local to the Datacenter and another anycast. For this, an anycast network is defined, which is announced from both A and B, e.g., 10.11.12.0/24 (although the 10.0.0.0/8 network is not actually routable on the Internet, we use it as an example).
The anycast IP of the resolvers is 10.11.12.2, and that of the authoritative is 10.11.12.3. Then each has a Management IP of its own Datacenter, which, being interconnected by a Management VLAN may be non-routable, e.g., resolvers at 172.16.40.2 and 172.16.41.2, and authoritatives at 172.16.40.3 and 172.16.41.3.
This means that the 172.16.40.0/24 network is announced only from A, the 172.16.41.0/24 network is announced only from B, and the 10.11.12.0/24 network is announced from both.
Mirroring with Planisys as Anycast Provider
Planisys is a Cloud Provider as well as a Software Factory. Planisys develops software, provides services in its cloud, and also deploys OnPremise, in third-party Datacenters, and in third-party clouds like AWS/GCP/Azure.
Planisys dentro de su producto PDNS, aparte de ser proveedor de este software que se puede desplegar OnPremise, o utilizar en su version nube en el Cloud de Planisys, tambien realiza anuncios BGP de terceras partes para ayudar con el Anycast dentro del producto PDNS.
Planisys utiliza su sistema autonomo AS52438 para anunciar redes via BGP, y se puede permitir, via RPKI, que anuncie redes de terceros.
This graphic illustrates the previous case, with the addition of the Resolver and Authoritative services within the Planisys cloud. In this way, these servers will have identical functionality in Datacenters A and B, as well as in the Planisys cloud.
