Descripción general de GSLB #

Hoy en día, la alta disponibilidad de los servicios TI es una necesidad y es por ello que las empresas y organizaciones desarrollan sistemas de cómputo distribuidos alrededor del mundo y alojan servicios en más de un Data Center, ya que ofrece los siguientes beneficios:

Tolerancia a fallos:Cuando el servicio alojado en el centro de datos falla, el servicio continúa en cualquiera de los otros sitios disponibles.
Recuperación automática del centro de datos:cuando un centro de datos falla, el servicio se redirige automáticamente a cualquier otro centro de datos disponible.
Balanceo de carga:El tráfico podría optimizarse distribuyendo la carga entre todos los sitios disponibles mejorando la latencia y haciendo más rápida la entrega del servicio.
Latencia mejorada:El tráfico de la aplicación cliente es directamente con el servidor real, sin necesidad de pasar todos los datos de la aplicación a través del balanceador de carga.

La adopción e implementación de servicios de TI en la nube requiere que un método basado en WAN sea la mejor opción para proporcionar soluciones de alta disponibilidad geolocalizadas. Esto es lo que llamamos balanceo de carga de servicio global o GSLB.

Cuándo utilizar GSLB #

Se recomienda utilizar el servicio GSLB para los siguientes casos de uso:

Empresas que alojan sus servicios en más de un centro de datos a través de WAN.
Empresas que requieren crear alta disponibilidad de servicios o centros de datos.
Los proveedores de servicios de Internet crearán servicios de equilibrio de carga entrante para que los utilicen sus usuarios.

Definitivamente, cuando se requiere compartir usuarios y tráfico entre servidores alrededor del mundo sin puntos de falla GSLB es la solución adecuada.

¿Cómo funciona GSLB? #

GSLB es un mecanismo de equilibrio de carga basado en el protocolo DNS ; es rápido y fiable porque utiliza el protocolo UDP y la respuesta del cliente es prácticamente en tiempo real.

En una solicitud DNS común, por ejemplo www.zvnlb.net , un cliente envía la resolución de la solicitud DNS a los servidores DNS configurados localmente (por ejemplo 8.8.8.8 y 8.8.4.4 ) y luego el sistema cliente selecciona aleatoriamente uno de los servidores para responder a la solicitud y enviar la consulta.

El servidor DNS seleccionado recibe la solicitud del cliente (por ejemplo, ¿cuál es la dirección IP de www.zvnlb.net ?) y los servidores DNS configurados localmente intentan encontrar quién es el responsable de resolver la zona DNS zvnlb.net.

El DNS utilizado por el cliente, 8.8.8.8 o 8.8.4.4 en este caso, detecta que ns1.zvnlb.net y ns2.zvnlb.net son responsables de las resoluciones de zona para zvnlb.net , por lo que envían la consulta DNS recibida por el cliente (por ejemplo, ¿cuál es la dirección IP de www.zvnlb.net ?) a uno de ellos.

Uno de los servidores de nombres, ya sea ns1.zvnlb.net o ns2.zvnlb.net, recibe la consulta DNS de 8.8.8.8 o 8.8.4.4 y, a continuación, el servidor de nombres que recibe la solicitud comprueba los servidores disponibles para el host www.zvnlb.net y responde a la consulta DNS con la lista de servidores de aplicaciones disponibles para servir la aplicación real para el host www.zvnlb.net ; por lo tanto, esta información será recibida finalmente por el cliente.

Ahora el cliente seleccionará aleatoriamente uno de los servidores de aplicaciones de la lista recibida en la consulta DNS y enviará directamente la solicitud a la aplicación http://www.zvnlb.net.

Los servidores DNS ns1.zvnlb.net (ubicado en Frankfurt, en nuestro ejemplo) y ns2.zvnlb.net (ubicado en Toronto, en nuestro ejemplo) verifican constantemente el estado de la aplicación www.zvnlb.net ( 192.235.113.3 y 194.23.52.21, respectivamente). Si ns1.zvnlb.net o ns2.zvnlb.net detectan algún problema al verificar el estado de alguno de los servidores DNS, el servidor no disponible se desactivará temporalmente y su dirección IP no aparecerá en las consultas DNS hasta que vuelva a estar disponible.

El siguiente diagrama muestra el tráfico DNS descrito con capacidades GSLB.

Configuración de GSLB para la recuperación ante desastres de centros de datos #

Esta configuración se recomienda para servicios que requieren alta disponibilidad de los Centros de Datos para Recuperación de Desastres, de modo que si todos los servicios de una determinada empresa están en un centro de datos y dicho centro de datos falla, el sistema moverá todos los servicios afectados a otro centro de datos disponible.

Siga este ejemplo real de configuración de GSLB para construir un centro de datos activo-pasivo para recuperación ante desastres.

Hemos desplegado dos RELIANOID Balanceadores de carga en dos centros de datos en diferentes sitios, Frankfurt 159.89.7.124 y Toronto 159.203.12.35 y tenemos un servicio web que responde al host DNS www.zvnlb.net, configurado en Centro de datos 1 y Centro de datos 2El diseño de esta arquitectura va a permitir enviar todo el tráfico de los clientes a la Centro de datos 1 pero si falla entonces redirige a los clientes a Centro de datos 2.

Para lograr esta configuración siga el procedimiento que se indica a continuación.

Conéctate a RELIANOID panel web en el Centro de datos 1 (Frankfurt en nuestro caso), haga clic en el menú principal GSLB módulo y crear uno nuevo Fincas, en nuestro ejemplo se llamará DNS1-Frankfurt en el puerto virtual 53.

Una vez creada la granja, edítela y vaya a la pestaña Zonas y cree la zona DNS que será administrada por el módulo GSLB, en este caso zvnlb.net , de la siguiente manera:

Una vez creada esta zona realice la primera configuración como se muestra a continuación:

Tenga en cuenta que ns1 y ns2 son los servidores de nombres responsables de las resoluciones DNS para la zona zvnlb.net (en nuestro caso, un servicio GSLB en Frankfurt y otro en Toronto).

Luego, conéctese a la RELIANOID Panel web en el Data Center 2, en el menú principal seleccionar GSLB y crea un nuevo Fincas, en nuestro caso se llamará DNS2-Toronto en el puerto virtual 53.

Edite la nueva granja GSLB y vaya a la pestaña Zonas , cree aquí la zona DNS que será administrada por este servicio GSLB para zvnlb.net de la siguiente manera:

Una vez creada esta nueva zona realice la primera configuración de la siguiente manera:

Al igual que en el caso del GSLB en el Centro de Datos 1 , los servidores de nombres n1 y n2 apuntarán a los servicios GSLB tanto en el Centro de Datos 1 como en el Centro de Datos 2 , respectivamente.

A continuación, haga clic en la pestaña Servicios y cree un nuevo servicio, por ejemplo webpriority :

Seleccione la opción Algoritmo Prioridad: Conexiones siempre a la de mayor prioridad disponible y configure el servicio de la siguiente manera:

Reinicie la granja para aplicar los cambios. Es necesario aplicar la misma configuración del servicio GSLB en ambos centros de datos.

Tenga en cuenta que si Farm Guardian no está configurado para aplicar ninguna comprobación de estado, el servicio GSLB utiliza una comprobación predeterminada check_tcp para el puerto TCP definido en el campo de comprobación de estado en la configuración del servicio.

Para habilitar el nuevo servicio, vaya a la zona creada ( zvnlb.net en nuestro caso) y cree un nuevo recurso . A continuación, créelo seleccionando el nuevo servicio , como se muestra a continuación.

Por último, guarde los cambios. Es necesario aplicar esta configuración en ambos centros de datos.

En este punto, el host www.zvnlb.net es administrado por el módulo GSLB en modo Prioridad , por lo que todo el tráfico se enviará al Centro de datos 1 y luego, si falla, el tráfico se redirigirá al otro Centro de datos disponible 2.

El TTL se ha configurado en 5, es el tipo de fecha de vencimiento que se le pone a un registro DNS. El TTL sirve para indicarle al servidor recursivo o al solucionador local cuánto tiempo debe mantener dicho registro en su caché. Por lo tanto, cuanto menor sea el valor configurado, más rápido se detectarán los cambios.

Aplicando este método podríamos agregar tantos centros de datos como sea necesario incluyendo nuevos servidores de nombres con servicio GSLB.

La siguiente solicitud DNS muestra la configuración de los servidores de nombres para zvnlb.net y la resolución DNS para el host www.zvnlb.net.

usuario@cliente:# host -t ns zvnlb.net servidor de nombres zvnlb.net ns2.zvnlb.net. servidor de nombres zvnlb.net ns1.zvnlb.net.

Ambos servidores de nombres utilizan las direcciones IP virtuales configuradas en las granjas GSLB.

Ahora, utilice sus servidores DNS actuales para resolver un host (por ejemplo, www ) en esta zona:

usuario@cliente:# nslookup www.zvnlb.net Servidor: 8.8.8.8 Dirección: 8.8.8.8#53 Respuesta no autorizada: Nombre: www.zvnlb.net Dirección: 188.166.230.211

Como se muestra, actualmente el host 188.166.230.211 es el nodo de aplicación real activo en el Centro de Datos 1. Tan pronto como el host no sea accesible (por ejemplo, si el servicio http en 188.166.230.211 no está disponible), la resolución DNS cambiará como se muestra a continuación.

usuario@cliente:# nslookup www.zvnlb.net Servidor: 8.8.8.8 Dirección: 8.8.8.8#53 Respuesta no autorizada: Nombre: www.zvnlb.net Dirección: 139.59.186.84

En cuanto falle el servidor de aplicaciones, la resolución DNS cambiará el host al Centro de datos 2. Una vez que el host del Centro de datos 1 esté operativo, la recuperación se aplicará automáticamente.

Configuración de GSLB para centros de datos activos-activos #

La alta disponibilidad con el modo de prioridad es una buena opción para un sistema de recuperación ante desastres, pero el centro de datos de respaldo que se utiliza para la recuperación no tiene mucho uso, por lo que generalmente es más eficiente equilibrar la carga de todo el tráfico entre los centros de datos disponibles.

Para estos casos, utilice el método de compartición para su servicio GSLB llamado Round Robin Load Balancing, como se muestra en el ejemplo para el nuevo servicio llamado web :

Ahora, agréguelo en la zona zvnlb.net y cambie la configuración del recurso www de la siguiente manera:

Guarde los cambios y reinicie la granja si se le solicita.

Para probarlo, intente resolver el host www.zvnlb.net y el resultado se verá como se muestra:

usuario@cliente:# nslookup www.zvnlb.net Servidor: 8.8.8.8 Dirección: 8.8.8.8#53 Respuesta no autorizada: Nombre: www.zvnlb.net Dirección: 188.166.230.211 Nombre: www.zvnlb.net Dirección: 139.59.186.84

Tenga en cuenta que el solucionador de DNS devuelve ambos servidores de aplicaciones en lugar de uno, como en el caso de recuperación ante desastres.

Una vez que el host tiene una falla, la resolución DNS cambiará automáticamente. Vea a continuación lo que sucede.

root@client:# nslookup www.zvnlb.net Servidor: 8.8.8.8 Dirección: 8.8.8.8#53 Respuesta no autorizada: Nombre: www.zvnlb.net Dirección: 139.59.186.84

El servidor de aplicaciones no disponible se desactiva de la lista de respuestas de DNS.

En cuanto el host 188.166.230.211 vuelva a estar disponible, se incluirá de nuevo en la resolución DNS.

Delegar una zona en la RELIANOID Servicio GSLB #

En el caso de una zona pública (por ejemplo, zvnlb.net ) que ofrece un servicio GSLB como servidor de nombres que necesita ser reconocido por los servidores DNS públicos de dicho dominio, es necesario registrar la dirección IP pública utilizada por el servicio GSLB en el registrador de su dominio (como NameCheap, Goddaddy u otros). El siguiente enlace explica cómo registrar las IP de GSLB como servidores de nombres en un registro de dominio.

Registrar un host como servidor de nombres

Siguiendo el procedimiento indicado, debe registrar ns1.zvnlb.net y ns2.zvnlb.net con las direcciones IP proporcionadas.

Creación de una subzona dedicada para GSLB #

En caso de que no sea posible delegar la resolución de DNS al servicio GSLB de RELIANOID, se podría realizar la configuración que se explica a continuación. El siguiente ejemplo muestra cómo construir un subzona por la www.zvnlb.net que apunta a los servidores de nombres de esta nueva subzona en el servicio GSLB.

El nodo 1 (por ejemplo , ns1.zvnlb.net con IP 162.243.5.109 ) y el nodo 2 (por ejemplo , ns2.zvnlb.net con IP 178.62.233.104 ) son servidores de nombres configurados que ofrecen servicios de resolución DNS para la zona zvnlb.net . Esta zona está bajo un servicio DNS público Bind9 y queremos ofrecer capacidades GSLB para algunos hosts de nuestra infraestructura, por lo que decidimos crear la subzona DNS cluster.zvnlb.net y configurar 2 granjas GSLB como servidores de nombres DNS para este propósito.

Hemos creado la subzona para nuestro dominio cluster.zvnlb.net en nuestros servidores DNS Bind9 de la siguiente manera:

Ahora sigue la sección Delegar una zona en la RELIANOID Servicio GSLB Para mantener 159.89.7.124 y 159.203.12.35 En nuestro ejemplo, como servidores de nombres reconocidos para la zona. grupo.zvnlb.net por servidores DNS públicos.

Luego, puede aplicar la configuración como se explica para el dominio zvnlb.net en la sección anterior Configuración de GSLB para la recuperación ante desastres de centros de datos.

Apuntar un Host en nuestro propio DNS referenciado a un servicio GSLB #

En las secciones anteriores hemos creado un host llamado www.zvnlb.net con balanceo de carga en modos de prioridad y round robin, por lo que podemos reutilizar esta configuración para ofrecer capacidades GSLB a otro servidor de nombres DNS que no admite esta función de forma predeterminada.

Para lograr esta configuración, solo tenemos que crear un nuevo recurso en la zona DNS que no admita opciones GSLB (por ejemplo, relianoid.io es administrado por Bind9), como un nombre canónico o CNAME, como se muestra a continuación:

Una vez aplicado el cambio, www.relianoid.io apuntará a www.zvnlb.net , pero si la resolución del host www.zvnlb.net cambia, www.relianoid.io también cambiará automáticamente .

Tenga en cuenta que este ejemplo se realiza en un servidor DNS Bind9, pero los nombres canónicos o CNAMES son configuraciones de host DNS compatibles con cualquier implementación de servicio de servidor DNS.

Esta sencilla explicación muestra que se puede utilizar un servicio GSLB incluso si nuestro servicio DNS actual no ofrece capacidades GSLB, solo reenviando la resolución del host dado en una zona que no es GSLB al servicio GSLB en RELIANOID Equilibrador de carga.