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``. .. warning:: 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. .. image:: anycast.jpg 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. .. warning:: 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. .. note:: 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. .. 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 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). .. 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 ------------- 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. .. 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:: 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. .. image:: doble-datacenter.jpg 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. .. image:: triple-datacenter.jpg