Uso de DNS para el descubrimiento de servicios con NGINX y NGINX Plus

[Editor: esta publicación se ha actualizado para hacer referencia a la API NGINX Plus , que reemplaza y deja obsoleto el módulo de configuración dinámica independiente mencionado en la versión original de la publicación].

Una de las grandes ventajas de una arquitectura de microservicios es la rapidez y facilidad con la que se pueden escalar instancias de servicio. Con múltiples instancias de servicio, necesita un equilibrador de carga y alguna forma de informarle rápidamente sobre los cambios en el conjunto de instancias de servicio disponibles. Esto se conoce como descubrimiento de servicios . NGINX Plus ofrece dos opciones para la integración con sistemas de descubrimiento de servicios: la API de NGINX Plus y la re-resolución del Sistema de nombres de dominio (DNS) . Esta entrada del blog se centra en este último aspecto.

Al escalar instancias de servicio (las llamaremos backends en esta publicación del blog) agregando o quitando máquinas virtuales (VM) o contenedores, la configuración del balanceador de carga debe cambiarse para reflejar cada cambio en el conjunto de backends. El escalamiento puede ocurrir varias veces al día, por hora o incluso por minuto, dependiendo de la aplicação. Dada la alta frecuencia de los cambios de configuración, es necesario automatizarlos y una de las formas de lograrlo es el descubrimiento de servicios a través de DNS.

Muchas plataformas en las que ejecuta sus aplicações hoy en día, como Kubernetes , admiten el descubrimiento de servicios mediante DNS. Proporcionamos enlaces al final de esta publicación de blog a artículos que explican cómo integrar NGINX Plus con plataformas populares y herramientas de descubrimiento de servicios que usan DNS.

Una revisión rápida de las características clave del DNS

Antes de explicar cómo configurar el descubrimiento de servicios a través de DNS, echemos un vistazo rápido a algunas características del protocolo DNS que son particularmente relevantes o útiles.

Tiempo de vida

Para evitar que los clientes DNS utilicen información obsoleta, los registros DNS incluyen el campo de tiempo de vida (TTL) para definir durante cuánto tiempo los clientes pueden considerar válido el registro. Para cumplir con los estándares DNS , los clientes deben consultar al servidor DNS para obtener una actualización cuando un registro supera su TTL. NGINX Plus respeta el TTL de manera predeterminada, pero también proporciona un control granular sobre la “vida útil” de un registro: puede configurar NGINX Plus para ignorar los TTL y, en su lugar, actualizar los registros con una frecuencia específica. (Discutiremos cómo NGINX Open Source maneja el TTL más adelante en la publicación).

DNS sobre TCP

De forma predeterminada, los clientes y servidores DNS se comunican a través de UDP, pero si un nombre de dominio se resuelve en una gran cantidad de direcciones IP de back-end, la respuesta completa podría no caber en un único datagrama UDP, que está limitado a 512 bytes. El uso de TCP en lugar de UDP resuelve este problema: cuando un conjunto completo de registros no cabe en un datagrama, el servidor establece un indicador de truncamiento en su respuesta, que le indica al cliente que cambie a TCP para obtener todos los registros. DNS sobre TCP es compatible con NGINX versión 1.9.11 y posteriores, y NGINX Plus R9 y posteriores. Para obtener más detalles, consulte Equilibrio de carga del tráfico DNS con NGINX y NGINX Plus en nuestro blog.

Registros SRV

El DNS resuelve los nombres de host en direcciones IP, pero ¿qué pasa con los números de puerto? Hay algunos casos (por ejemplo, cuando se equilibra la carga de contenedores Docker) en los que no se puede confiar en números de puerto conocidos, porque los números de puerto se asignan de forma dinámica. El DNS tiene un tipo especial de registro, el registro de Servicio ( SRV ) , que incluye números de puerto y algunos otros parámetros. En R9 y versiones posteriores, NGINX Plus admite registros SRV (y por lo tanto puede extraer información del puerto de ellos).

Editor: para obtener una descripción general de todas las nuevas características de NGINX Plus R9, consulte Anuncio de NGINX Plus R9 en nuestro blog.

Métodos para el descubrimiento de servicios con DNS para NGINX y NGINX Plus

Ahora le mostraremos cinco formas de usar DNS para el descubrimiento de servicios en NGINX y NGINX Plus, en orden de creciente sofisticación. Los primeros tres están disponibles tanto en NGINX como en NGINX Plus, y los dos últimos solo en NGINX Plus.

En este estudio de los métodos de descubrimiento de servicios, asumiremos que tenemos un servidor de nombres autorizado para la zona example.com , con la dirección IP 10.0.0.2. Hay tres servidores backend que corresponden al nombre de dominio backends.example.com , como se muestra en la siguiente salida de la utilidad nslookup . Con los primeros cuatro métodos que analizaremos, NGINX y NGINX Plus solicitan registros A estándar del DNS; con el método final, NGINX Plus solicita registros SRV en su lugar.

$ nslookup backends.example.com 10.0.0.2 Servidor:		10.0.0.2 Dirección:	10.0.0.2#53 Nombre: backends.example.com Dirección: 10.0.0.11 Nombre: backends.example.com Dirección: 10.0.0.10 Nombre: backends.example.com Dirección: 10.0.0.12

Uso de DNS para el descubrimiento de servicios con NGINX

Comenzaremos mostrándole las tres formas de usar DNS con NGINX Open Source (como mencionamos anteriormente, también puede usarlos con NGINX Plus).

Uso del nombre de dominio en la directiva proxy_pass

La forma más sencilla de definir el grupo de servidores ascendentes (backends) es especificar un nombre de dominio como parámetro de la directiva proxy_pass :

servidor { ubicación / {
contraseña_proxy http://backends.example.com:8080;
}
}

A medida que NGINX se inicia o recarga su configuración, consulta a un servidor DNS para resolver backends.example.com . El servidor DNS devuelve la lista de los tres backends analizados anteriormente y NGINX utiliza el algoritmo Round Robin predeterminado para equilibrar la carga de las solicitudes entre ellos. NGINX elige el servidor DNS del archivo de configuración del sistema operativo /etc/resolv.conf .

Este método es la forma menos flexible de realizar el descubrimiento de servicios y tiene los siguientes inconvenientes adicionales:

• Si no se puede resolver el nombre de dominio, NGINX no podrá iniciarse ni recargar su configuración.
• NGINX almacena en caché los registros DNS hasta el próximo reinicio o recarga de configuración, ignorando los valores TTL de los registros.
• No podemos especificar otro algoritmo de equilibrio de carga, ni tampoco podemos configurar controles de estado pasivos u otras características definidas por parámetros en la directiva del servidor , que describiremos en la siguiente sección.

Uso de un nombre de dominio en un grupo de servidores ascendentes

Para aprovechar las opciones de equilibrio de carga que ofrece NGINX, puede definir el grupo de servidores ascendentes en el bloque de configuración ascendente . Pero en lugar de identificar servidores individuales por dirección IP, utilice el nombre de dominio como parámetro de la directiva del servidor .

Al igual que con el primer método , backends.example.com se resuelve en tres servidores backend a medida que NGINX inicia o recarga su configuración. Pero ahora podemos definir un algoritmo de equilibrio de carga más sofisticado, Least Connections , y usar el parámetro max_fails para habilitar controles de estado pasivos, especificando que NGINX marca un servidor como inactivo cuando fallan tres solicitudes consecutivas.

backends ascendentes { menor_conexión;

servidor backends.example.com:8080 máx_fallos=3;
}

servidor {
ubicación / {
contraseña_proxy http://backends;
}
}

Si bien este método nos permite elegir el algoritmo de equilibrio de carga y configurar controles de estado, aún tiene los mismos inconvenientes con respecto al inicio, la recarga y el TTL que el método anterior.

Establecer el nombre de dominio en una variable

Este método es una variante del primero , pero nos permite controlar la frecuencia con la que NGINX vuelve a resolver el nombre de dominio:

Resolver 10.0.0.2 válido=10s;
servidor {
ubicación / {
establecer $backend_servers backends.example.com;
contraseña_proxy http://$backend_servers:8080;
}
}

Cuando se utiliza una variable para especificar el nombre de dominio en la directiva proxy_pass , NGINX vuelve a resolver el nombre de dominio cuando expira su TTL. Debe incluir la directiva de resolución para especificar explícitamente el servidor de nombres (NGINX no hace referencia a /etc/resolv.conf como en los primeros dos métodos). Al incluir el parámetro válido en la directiva de resolución , puede indicarle a NGINX que ignore el TTL y vuelva a resolver los nombres en una frecuencia específica. Aquí le indicamos a NGINX que vuelva a resolver los nombres cada 10 segundos.

Nota:  Para equilibrar la carga TCP/UDP, este método de utilizar una variable en la directiva proxy_pass es compatible con NGINX 1.11.3 y versiones posteriores, y NGINX Plus R10 y versiones posteriores.

Este método elimina dos inconvenientes del primer método: la operación de inicio o recarga de NGINX no falla cuando no se puede resolver el nombre de dominio y podemos controlar la frecuencia con la que NGINX vuelve a resolver el nombre. Sin embargo, debido a que no utiliza un grupo ascendente, no puede especificar el algoritmo de equilibrio de carga ni otros parámetros para la directiva del servidor (como hicimos en el segundo método ).

Uso de DNS para el descubrimiento de servicios con NGINX Plus

Ahora veremos los dos métodos de descubrimiento de servicios con DNS que son exclusivos de NGINX Plus.

Uso de registros A con NGINX Plus

Con NGINX Plus, podemos volver a resolver nombres DNS con la frecuencia que queramos y sin los inconvenientes comentados anteriormente para los tres primeros métodos. Para utilizar esta función, necesitamos:

• Incluya la directiva resolver para especificar el servidor de nombres, como en el método anterior.
• Incluya la directiva de zona en el bloque de configuración ascendente para asignar una zona de memoria compartida.
• Agregue el parámetro resolve a la directiva del servidor donde usamos el nombre de dominio.

Consideremos el siguiente ejemplo:

resolver 10.0.0.2 válido=10s ; backends ascendentes { zona backends 64k ; servidor backends.example.com:8080 resolver ; } servidor { ubicación / { proxy_pass http://backends; } }

De forma predeterminada, NGINX Plus respeta el TTL y resuelve nuevamente los nombres cuando los registros expiran. Para que NGINX Plus vuelva a resolver los nombres con una frecuencia específica, incluya el parámetro válido en la directiva de resolución .

En el fragmento, cada 10 segundos NGINX Plus consulta al servidor de nombres en 10.0.0.2 para resolver backends.example.com . Si no se puede resolver el nombre, NGINX Plus no falla, ni al iniciarse, ni al recargar la configuración ni durante el tiempo de ejecución. En cambio, el cliente ve el estándar502 página de error.

Uso de registros SRV con NGINX Plus

NGINX Plus R9 y versiones posteriores admiten registros DNS SRV . Esto permite que NGINX Plus obtenga no solo direcciones IP de un servidor de nombres, sino también números de puerto, pesos y prioridades. Esto es fundamental en entornos de microservicios donde los números de puerto de los servicios a menudo se asignan de forma dinámica.

Editor: para obtener una descripción general de todas las nuevas características de NGINX Plus R9, consulte Anuncio de NGINX Plus R9 en nuestro blog.

Los registros SRV se definen mediante un triplete del nombre del servicio, el protocolo de comunicación con el servicio y el nombre de dominio. Al consultar el servidor de nombres, debemos proporcionar los tres. Nuestro servidor de nombres 10.0.0.2 tiene tres registros SRV con el triplete de nombre de servicio http , protocolo tcp y nombre de dominio backends.example.com , como se muestra en esta salida de la utilidad nslookup :

$ nslookup -query=SRV _http._tcp.backends.example.com 10.0.0.2 Servidor:		10.0.0.2 Dirección:	10.0.0.2#53 _http._tcp.backends.example.com servicio = 0 2 8090 backend-0.example.com. _http._tcp.backends.example.com servicio = 0 1 8091 backend-1.example.com. _http._tcp.backends.example.com servicio = 10 1 8092 backend-2.example.com.

Cuando consultamos el nombre de host en cada registro SRV , obtenemos su dirección IP:

$ nslookup backend-0.example.com 10.0.0.2 ...
Nombre: backend-0.example.com Dirección: 10.0.0.10 $ nslookup backend-1.example.com 10.0.0.2 ...
Nombre: backend-1.example.com Dirección: 10.0.0.11 $ nslookup backend-2.example.com 10.0.0.2 ...
Nombre: backend-2.example.com Dirección: 10.0.0.12

Analicemos más de cerca la información del primer registro SRV devuelto por el primer comando nslookup :

_http._tcp.backends.example.com servicio = 0 2 8090 backend-0.example.com.

• _http._tcp. – El nombre y el protocolo del registro SRV . Especificaremos esto como el valor del parámetro de servicio para la directiva del servidor en el archivo de configuración de NGINX Plus (ver a continuación).
• 0 – La prioridad. Cuanto menor sea el valor, mayor será la prioridad. NGINX Plus designa a los servidores con mayor prioridad como servidores principales y al resto de los servidores como servidores de respaldo. Este registro tiene el valor más bajo (la prioridad más alta) entre todos los registros, por lo que NGINX Plus designa el backend correspondiente como servidor principal.
• 2 – El peso. NGINX Plus establece el peso del backend en este valor a medida que agrega el backend al grupo ascendente (equivalente al parámetro de peso en la directiva del servidor ).
• 8090 – El número de puerto. NGINX Plus establece el puerto del backend en este valor a medida que agrega el backend al grupo ascendente.
• backend‑0.example.com – El nombre de host del servidor backend. NGINX Plus resuelve este nombre y agrega el backend correspondiente al grupo ascendente. Si el nombre se resuelve en múltiples registros, NGINX Plus agrega múltiples servidores.

Ahora veamos cómo configuramos NGINX Plus para usar registros SRV . Aquí está el archivo de configuración de muestra:

Resolver 10.0.0.2 válido=10s;

backends ascendentes {
backends de zona 64k;
backends del servidor.ejemplo.com servicio=_http._tcp resolver;
}

servidor {
ubicación / {
contraseña_proxy http://backends;
}
}

Utilizando el parámetro de servicio de la directiva del servidor , especificamos el nombre y el protocolo de los registros SRV que deseamos resolver. En nuestro caso son _http y _tcp respectivamente. Aparte del parámetro de servicio y el hecho de que no especificamos un puerto, parece igual que el ejemplo de configuración de la sección anterior .

Según los valores devueltos por el primer comando nslookup en esta sección, NGINX Plus se configura con tres servidores backend:

• 10.0.0.10 – Servidor principal con puerto 8090 y peso 2.
• 10.0.0.11 – Servidor principal con puerto 8091 y peso 1.
• 10.0.0.12 – Servidor de respaldo con puerto 8092 y peso 1.

Si configuramos el monitoreo de actividad en vivo para NGINX Plus, podemos ver esos backends en el panel integrado:

Observe cómo se distribuyen las solicitudes según los pesos especificados. El servidor 10.0.0.11:8091 (con peso 1) recibe un tercio de las solicitudes, mientras que el servidor 10.0.0.10:8090 (con peso 2) recibe dos tercios. Como servidor de respaldo, el servidor 10.0.0.12:8092 no recibe ninguna solicitud a menos que los otros dos servidores estén inactivos.

Advertencias

Al utilizar DNS para el descubrimiento de servicios con NGINX Plus, hay algunas cosas a tener en cuenta:

• El servidor DNS debe tener alta disponibilidad o tener un servidor de respaldo. Si el servidor DNS deja de estar disponible, NGINX Plus deja de recibir actualizaciones. Mantiene los backends existentes en la configuración (a menos que lo reinicie o recargue la configuración), ignorando los valores TTL de los registros correspondientes.
• Puede especificar varios servidores de nombres con la directiva resolver , de modo que si uno de ellos no funciona, NGINX Plus pruebe con los demás.
• Como se mencionó en la introducción, una alternativa al DNS para el descubrimiento de servicios con NGINX Plus es la API NGINX Plus , que le permite realizar solicitudes HTTP simples para agregar o eliminar servidores en un grupo ascendente.

Ejemplos

Si desea profundizar en ejemplos completos, consulte estas publicaciones de blog sobre la integración de NGINX y NGINX Plus con plataformas de descubrimiento de servicios que usan DNS:

• Descubrimiento de servicios para NGINX Plus mediante registros DNS SRV de Consul
• Equilibrio de carga de servicios de Kubernetes con NGINX Plus

Actualizaremos esta lista a medida que escribamos más sobre nuevas opciones de integración en el futuro.

CONCLUSIÓN

El descubrimiento de servicios a través de DNS, totalmente disponible en NGINX Plus, proporciona una forma sencilla de actualizar la configuración del balanceador de carga en un entorno de microservicios. La compatibilidad con registros SRV en la versión 9 y posteriores hace que NGINX Plus sea aún más potente, ya que permite que NGINX Plus obtenga no solo direcciones IP, sino también números de puerto de los backends.

¿Está listo para probar el descubrimiento de servicios con DNS para NGINX Plus, junto con sus otras funciones mejoradas? Comience hoy su prueba gratuita de 30 días o contáctenos para analizar sus casos de uso .