Arquitecturas de Alta Disponibilidad
Introduccion
Esta seccion va dirigida a Network Engineers y a Implementadores que necesiten una solucion de Alta Disponibilidad a nivel red.
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.
Advertencia
En esta seccion discutimos solamente la arquitectura de los Resolvers y Aurotitativos, sin importar si la aplicacion pdns-app corre en la nube de Planisys o en la nube On-Premise.
En el grafico siguiente se ve un ejemplo de HA para Resolvers, desde tres Datacenters diferentes, que pueden estar ubicados en cualquier parte del Planeta.
Para eso debemos disponer minimamente de una red /24, que se pueda anunciar en el backbone de Internet a traves de BGP desde todos los Datacenters de la red Anycast.
Advertencia
Para poder implementar servicios con HA anycast, se debe tratar de servicios identicos, replicados o ejecutando las mismas transacciones a traves de Internet o de una Intranet entre Datacenters. Cada IP que se utiliza de esa red /24 , debe estar ocupada en TODOS los Datacenters por el MISMO servicio. Cuando una red se reserva para ANYCAST, no se pueden utilizar IPs sueltas de esa red en uno solo de los Datacenters.
Nota
En esta seccion no utilizamos el termino Cluster , dado que la clusterizacion esta implicita en todas estas Arquitecturas especiales de HA.
Anycast para Resolvers
P.ej. si anunciamos la red 179.63.249.0/24 desde 3 puntos geograficos diferentes (ejemplo Planisys en Miami, Amsterdam y San Francisco), debemos dar de alta las mismas IPs y los mismos servicios en los 3 Datacenters.
En el caso de DNS Resolvers se trata de una tarea sencilla, ya que se debera instalar un mismo servidor DNS Resolver con la misma IP en los 3 Datacenters (p.ej. 179.63.249.221). De esta manera, un cliente que utilice nuestro servicio de resolucion de nombres en dicha IP, podra acceder al mismo aunque dos de los tres Datacenters o Routers esten caidos.
El servicio de Internet local-loop o ADSL o Cablemodem de un cliente final en un ordenador/laptop/celular/tablet que quiera acceder a nuestra IP 179.63.249.221 para resolver un nombre, podra hacerlo aun estando dos de los tres Datacenters caidos sin ningun impacto o demora.
Nota
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 para Autoritativos
Este caso es muy similar al de Resolvers.
Si disponemos de varios Datacenters, es muy conveniente tener direcciones IP anycast como minimo para 1 autoritativo.
La diferencia entre tener 1 IP anycast en 3 Datacenters para 1 autoritativo, y tener 3 IPs diferentes en cada Datacenter para 3 autoritativos, es que en el caso anycast, si cae un Datacenter, el tiempo de convergencia BGP en el backbone suele ser muy corto de un pocos milisegundos. En cambio en el caso de IPs diferentes, si una falla, depende del timeout del dispositivo cuanto tiempo le lleva cambiar a una 2da IP autoritativa si la 1era no responde (puede llegar a varios segundos).
Nota
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
En el caso de poseer una gran capilaridad Edge (es decir, presencia en muchos Datacenters a lo largo del Planeta), se puede lograr una latencia muy corta hacia nuestros resolvers y autoritativos en cualquier geografia.
Por ejemplo los resolvers de Google 8.8.8.8 y 8.8.4.4 provienen de anuncios de borde o edge en muchisimos Datacenters, de las redes 8.8.8.0/24 y 8.8.4.0/24 en modo anycast.
Dichos anuncios de borde, dejan la impresion de cercania de p.ej. 10ms, contra servidores con IPs unicast que si estan en otro pais o a traves de un salto oceanico, pueden exceder los 200 milisegundos.
Advertencia
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).
Nota
En caso de querer ubicar algun servicio en una nube publica como AWS, GCP o Azure debemos tener en cuenta que una IP elastica del proveedor siempre va a ser Unicast, es decir el servicio esta localizado en un unico punto geografico. Dado que estas nubes publicas tienen elementos de HA en sus Datacenters, se las puede utilizar para algunos nameservers, y en paralelo utilizar nameservers Anycast en la medida que tengamos una red /24 disponible y posibilidad de anunciarla desde minimo dos routers en dos Datacenters diferentes.
Ejemplo mirroring en doble Datacenter
Esta seccion va dirigida a empresas que gestionan o poseen Datacenters.
En este caso tenemos dos Datacenters A y B interconectados a traves de una VLAN de Management , en uno de los cuales residen los servidores de PDNS. Luego por cada resolver y cada autoritativo en A , hay uno equivalente en B. Cada resolver y cada autoritativo tienen dos IPs: una local del Datacenter, y otra anycast. Para esto se define una red anycast que se anuncia tanto desde A como desde B, p.ej. 10.11.12.0/24 (si bien la red 10.0.0.0/8 en realidad no es ruteable en el Internet, la tomamos a modo de ejemplo).
La IP anycast de los resolvers es 10.11.12.2 , y la del autoritativo 10.11.12.3. Luego cada cual tiene una IP de Management propia del Datacenter, que , al estar interconectados por una VLAN de Management pueden ser no ruteables, p.ej. resolvers en 172.16.40.2 y 172.16.41.2 , y autoritativos en 172.16.40.3 y 172.16.41.3
Esto quiere decir que la red 172.16.40.0/24 es anunciada solo desde A, la red 172.16.41.0/24 es anunciada solo desde B, y la red 10.11.12.0/24 es anunciada desde ambos.
Mirroring con Planisys como proveedor Anycast
Planisys es un Cloud Provider ademas de Software Factory. Planisys desarrolla software, provee servicios en su nube, y despliega tambien OnPremise, en Datacenters de terceros y en nubes de terceros como 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.
En este grafico se ilustra el caso anterior, con el agregado de los servicios Resolver y Autoritativo dentro de la nube de Planisys. De esta manera, estos servidores van a tener identica funcionalidad en los datacenters A y B, asi como en la nube de Planisys.
