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

Michael Pleshakov

[Nota del editor – Esta entrada se ha actualizado para hacer referencia a la API de NGINX Plus, que sustituye y deja obsoleto el módulo independiente de configuración dinámica mencionado en la versión original de la entrada.]

Una de las grandes ventajas de una arquitectura de microservicios es la rapidez y facilidad con las que se pueden escalar las instancias de servicio. Cuando se dispone de varias instancias de servicio, se necesita un equilibrador de carga y algún mecanismo que le informe rápidamente de los cambios en el conjunto de instancias de servicio disponibles. Esto se conoce como descubrimiento de servicios. NGINX Plus ofrece dos opciones para integrarse con sistemas de descubrimiento de servicios: la API de NGINX Plus y la resolución reiterada del sistema de nombres de dominio (DNS). Esta entrada del blog se centra en la segunda opción.

Cuando se escalan las instancias de servicio (en esta entrada del blog las llamaremos backends) añadiendo o eliminando máquinas virtuales (VM) o contenedores, es necesario modificar la configuración del balanceador de carga para reflejar cada cambio en el conjunto de backends. Según la aplicación, el escalado puede producirse varias veces al día, a la hora o incluso por minuto. Dada la elevada frecuencia de los cambios de configuración, es necesario automatizarlos, y una forma de hacerlo es mediante la detección de servicios a través de DNS.

Muchas de las plataformas en las que ejecuta sus aplicaciones actualmente, como Kubernetes, admiten la detección de servicios mediante DNS. Al final de esta entrada del blog incluimos enlaces a artículos que explican cómo integrar NGINX Plus con plataformas populares y herramientas de detección de servicios que utilizan DNS.

Un breve repaso de las principales funciones de DNS

Antes de explicar cómo configurar el descubrimiento de servicios mediante DNS, repasemos brevemente algunas características del protocolo DNS que resultan especialmente 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), que define durante cuánto tiempo pueden considerar válido el registro. Para cumplir con los estándares DNS, los clientes deben consultar el servidor DNS para obtener una actualización cuando un registro haya superado su TTL. NGINX Plus respeta el TTL de forma predeterminada, pero también permite controlar de manera más precisa la «vida útil» de un registro: puede configurar NGINX Plus para que ignore los TTL y, en su lugar, actualice los registros con una frecuencia determinada. (Más adelante en esta publicación explicaremos cómo gestiona el TTL NGINX Open Source.)

DNS sobre TCP

De forma predeterminada, los clientes y servidores DNS se comunican mediante UDP, pero si un nombre de dominio se resuelve en un gran número de direcciones IP de backend, es posible que la respuesta completa no quepa en un único datagrama UDP, cuyo tamaño está limitado a 512 bytes. El uso de TCP en lugar de UDP resuelve este problema: cuando el conjunto completo de registros no cabe en un datagrama, el servidor establece una marca de truncamiento en su respuesta, lo que indica al cliente que debe cambiar a TCP para obtener todos los registros. DNS sobre TCP es compatible con NGINX 1.9.11 y versiones posteriores, y con NGINX Plus R9 y versiones posteriores. Para obtener más información, consulte Equilibrio de carga del tráfico DNS con NGINX y NGINX Plus en nuestro blog.

SRV Registros

DNS resuelve los nombres de host en direcciones IP, pero ¿qué ocurre con los números de puerto? En algunos casos —por ejemplo, al equilibrar la carga de contenedores Docker— no se puede recurrir a números de puerto conocidos, ya que estos se asignan dinámicamente. DNS dispone de un tipo especial de registro: el registro de servicio (SRV); este incluye números de puerto y algunos parámetros adicionales. A partir de R9, NGINX Plus admite registros SRV (por lo que puede extraer de ellos la información de los puertos).

Nota del editor: Para obtener una visión general de todas las novedades de NGINX Plus R9, consulte Announcing NGINX Plus R9 en nuestro blog.

Métodos de descubrimiento de servicios mediante DNS para NGINX y NGINX Plus

A continuación, le mostraremos cinco formas de utilizar DNS para la detección de servicios en NGINX y NGINX Plus, ordenadas de menor a mayor complejidad. Las tres primeras están disponibles tanto en NGINX como en NGINX Plus, mientras que las dos últimas solo están disponibles en NGINX Plus.

En este análisis de los métodos de descubrimiento de servicios, supondremos que tenemos un servidor de nombres autoritativo 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 cuatro primeros métodos que analizaremos, NGINX y NGINX Plus solicitan registros A estándar a DNS; con el último método, NGINX Plus solicita en su lugar registros SRV.

$ nslookup backends.example.com 10.0.0.2Server:		10.0.0.2
Address:	10.0.0.2#53

Name:	backends.example.com
Address: 10.0.0.11
Name:	backends.example.com
Address: 10.0.0.10
Name:	backends.example.com
Address: 10.0.0.12

Uso de DNS para la detección de servicios con NGINX

Empezaremos mostrándole las tres formas de usar DNS con NGINX Open Source (como hemos mencionado anteriormente, también puede usarlas 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:

server {    location / {
        proxy_pass http://backends.example.com:8080;
    }
}

Cuando NGINX se inicia o vuelve a cargar su configuración, consulta un servidor DNS para resolver backends.example.com. El servidor DNS devuelve la lista de los tres servidores backend mencionados anteriormente, y NGINX utiliza el algoritmo Round Robin predeterminado para equilibrar la carga de las solicitudes entre ellos. NGINX selecciona el servidor DNS del archivo de configuración del sistema operativo /etc/resolv.conf.

Este método es la forma menos flexible de realizar la detección de servicios y presenta, además, los siguientes inconvenientes:

• Si no se puede resolver el nombre de dominio, NGINX no puede iniciarse ni volver a cargar su configuración.
• NGINX almacena en caché los registros DNS hasta el siguiente reinicio o recarga de la configuración, ignorando los valores TTL de los registros.
• No podemos especificar otro algoritmo de balanceo de carga, ni configurar comprobaciones de estado pasivas u otras funciones definidas mediante parámetros de la directiva server, que describiremos en la siguiente sección.

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

Para aprovechar las opciones de balanceo de carga que ofrece NGINX, puede definir el grupo de servidores ascendentes en el bloque de configuración upstream. Sin embargo, en lugar de identificar cada servidor por su dirección IP, utilice el nombre de dominio como parámetro de la directiva server.

Al igual que con el primer método, backends.example.com se resuelve en tres servidores backend cuando NGINX se inicia o recarga su configuración. Pero ahora podemos definir un algoritmo de balanceo de carga más sofisticado, el de Menos conexiones, y utilizar el parámetro max_fails para habilitar las comprobaciones de estado pasivas, especificando que NGINX marque un servidor como inactivo cuando fallen tres solicitudes consecutivas.

upstream backends {    least_conn;

    server backends.example.com:8080 max_fails=3;
}

server {
    location / {
        proxy_pass http://backends;
    }
}

Aunque este método nos permite elegir el algoritmo de balanceo de carga y configurar comprobaciones de estado, sigue presentando los mismos inconvenientes que el método anterior en cuanto al inicio, la recarga y el TTL.

Configurar 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 valid=10s;
server {
    location / {
        set $backend_servers backends.example.com;
        proxy_pass 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 caduca su TTL. Debe incluir la directiva resolver para especificar explícitamente el servidor de nombres (NGINX no consulta /etc/resolv.conf, como ocurre con los dos primeros métodos). Al incluir el parámetro valid en la directiva resolver, puede indicar a NGINX que ignore el TTL y vuelva a resolver los nombres con una frecuencia determinada. En este caso, indicamos a NGINX que vuelva a resolver los nombres cada 10 segundos.

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

Este método elimina dos inconvenientes del primero: 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 resolverlo. Sin embargo, como no utiliza un grupo de servidores upstream, no se puede especificar el algoritmo de balanceo de carga ni otros parámetros en la directiva server (como hicimos en el segundo método).

Uso de DNS para la detección de servicios con NGINX Plus

Ahora veremos los dos métodos de detección de servicios mediante DNS que son exclusivos de NGINX Plus.

Uso de registros «A» con NGINX Plus

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

• Incluya la directiva «resolver» para especificar el servidor de nombres, como en el método anterior.
• Incluya la directiva zone en el bloque de configuración upstream para asignar una zona de memoria compartida.
• Añada el parámetro resolve a la directiva server en la que usamos el nombre de dominio.

Veamos el siguiente ejemplo:

resolver 10.0.0.2 valid=10s;
upstream backends {
    zone backends 64k;
    server backends.example.com:8080 resolve;
}

server {
    location / {
        proxy_pass http://backends;
    }
}

De forma predeterminada, NGINX Plus respeta el TTL y vuelve a resolver los nombres cuando caducan los registros. Para que NGINX Plus vuelva a resolver los nombres con una frecuencia determinada, incluya el parámetro «valid» en la directiva «resolver».

En el fragmento, cada 10 segundos NGINX Plus consulta el servidor de nombres en 10.0.0.2 para resolver backends.example.com. Si no se puede resolver el nombre, NGINX Plus no genera ningún error, ni al iniciarse, ni al recargar la configuración, ni durante la ejecución. En su lugar, el cliente ve la página de error estándar 502.

Uso de registros SRV con NGINX Plus

NGINX Plus R9 y las versiones posteriores admiten registros DNS SRV. Esto permite que NGINX Plus obtenga de un servidor de nombres no solo direcciones IP, 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 suelen asignarse dinámicamente.

Nota del editor: Para obtener una visión general de todas las nuevas funciones de NGINX Plus R9, consulte «Presentamos NGINX Plus R9» en nuestro blog.

SRV se definen mediante una terna formada por el 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 datos. Nuestro servidor de nombres 10.0.0.2 tiene tres registros SRV con la terna formada por el nombre de servicio http, el protocolo tcp y el 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.2Server:		10.0.0.2
Address:	10.0.0.2#53

_http._tcp.backends.example.com	service = 0 2 8090 backend-0.example.com.
_http._tcp.backends.example.com	service = 0 1 8091 backend-1.example.com.
_http._tcp.backends.example.com	service = 10 1 8092 backend-2.example.com.

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

$ nslookup backend-0.example.com 10.0.0.2...
Name:	backend-0.example.com
Address: 10.0.0.10

$ nslookup backend-1.example.com 10.0.0.2
...
Name:	backend-1.example.com
Address: 10.0.0.11

$ nslookup backend-2.example.com 10.0.0.2
...
Name:	backend-2.example.com
Address: 10.0.0.12

Veamos más detenidamente la información del primer registro SRV devuelto por el primer comando nslookup:

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

• _http._tcp. – El nombre y el protocolo del registro SRV. Lo especificaremos como valor del parámetro service de la directiva server en el archivo de configuración de NGINX Plus (véase más abajo).
• 0 – La prioridad. Cuanto menor sea el valor, mayor será la prioridad. NGINX Plus designa los servidores con la prioridad más alta como servidores principales y el resto como servidores de respaldo. Este registro tiene el valor más bajo (la prioridad más alta) de 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 al añadirlo al grupo de servidores upstream (equivale al parámetro weight de la directiva server).
• 8090 – El número de puerto. NGINX Plus establece el puerto del backend en este valor al añadirlo al grupo de servidores upstream.
• backend‑0.example.com – El nombre de host del servidor backend. NGINX Plus resuelve este nombre y añade el backend correspondiente al grupo de servidores upstream. Si el nombre se resuelve en varios registros, NGINX Plus añade varios servidores.

Veamos ahora cómo configurar NGINX Plus para que utilice registros SRV. Este es el archivo de configuración de ejemplo:

resolver 10.0.0.2 valid=10s;

upstream backends {
    zone backends 64k;
    server backends.example.com service=_http._tcp resolve;
}

server {
    location / {
        proxy_pass http://backends;
    }
}

Mediante el parámetro service de la directiva server, especificamos el nombre y el protocolo de los registros SRV que queremos resolver. En nuestro caso, son _http y _tcp, respectivamente. Salvo por el parámetro service y el hecho de que no especificamos ningún puerto, es igual que el ejemplo de configuración de la sección anterior.

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

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

Si configuramos la supervisión de la actividad en tiempo real para NGINX Plus, podremos 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 un peso de 1) recibe un tercio de las solicitudes, mientras que el servidor 10.0.0.10:8090 (con un peso de 2) recibe dos tercios. Al ser un 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 la detección de servicios con NGINX Plus, hay algunos aspectos que conviene tener en cuenta:

• El servidor DNS debe tener una alta disponibilidad o contar con un servidor de respaldo. Si el servidor DNS deja de estar disponible, NGINX Plus deja de recibir actualizaciones. Los backends existentes se mantienen en la configuración (a menos que reinicie NGINX Plus o vuelva a cargar la configuración), ignorando los valores de TTL de los registros correspondientes.
• Puede especificar varios servidores de nombres con la directiva resolver, de modo que, si uno de ellos no está disponible, NGINX Plus pruebe los demás.
• Como se mencionó en la introducción, una alternativa al DNS para la detección de servicios con NGINX Plus es la NGINX Plus API, que permite realizar solicitudes HTTP sencillas para añadir o eliminar servidores de un grupo de servidores upstream.

Ejemplos

Si quieres consultar ejemplos completos, echa un vistazo a estas entradas de blog sobre la integración de NGINX y NGINX Plus con plataformas de descubrimiento de servicios que utilizan DNS:

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

Actualizaremos esta lista a medida que publiquemos más información sobre nuevas opciones de integración.

Conclusión

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

¿Todo listo para probar la detección de servicios mediante DNS para NGINX Plus, junto con sus otras funciones avanzadas? Empiece hoy mismo su prueba gratuita de 30 días o póngase en contacto con nosotros para hablar sobre sus casos de uso.

Sobre el autor

Michael Pleshakov

Más artículos de Michael Pleshakov