DNS für die Serviceerkennung mit NGINX und NGINX Plus verwenden

Michael Pleshakov

[Redaktion – Dieser Beitrag wurde aktualisiert und verweist nun auf die NGINX Plus API, die das in der ursprünglichen Version des Beitrags erwähnte separate Modul für die dynamische Konfiguration ersetzt und als veraltet kennzeichnet.]

Einer der großen Vorteile einer Microservices-Architektur besteht darin, dass sich Serviceinstanzen schnell und einfach skalieren lassen. Bei mehreren Serviceinstanzen benötigen Sie einen Load Balancer und eine Möglichkeit, diesen schnell über Änderungen an den verfügbaren Serviceinstanzen zu informieren. Dies wird als Service Discovery bezeichnet. NGINX Plus bietet zwei Optionen für die Integration in Service-Discovery-Systeme: die NGINX Plus API und die erneute Auflösung über das Domain Name System (DNS). Dieser Blogbeitrag befasst sich mit Letzterem.

Wenn Sie Dienstinstanzen durch das Hinzufügen oder Entfernen virtueller Maschinen (VMs) oder Container skalieren (in diesem Blogbeitrag nennen wir sie Backends), muss die Konfiguration des Load Balancers bei jeder Änderung am Bestand der Backends entsprechend angepasst werden. Je nach Anwendung kann die Skalierung mehrmals täglich, stündlich oder sogar minütlich erfolgen. Aufgrund der häufigen Konfigurationsänderungen müssen diese automatisiert werden. Eine Möglichkeit hierfür ist die Diensterkennung über DNS.

Viele Plattformen, auf denen Sie heute Ihre Anwendungen ausführen, wie etwa Kubernetes, unterstützen die Diensterkennung über DNS. Am Ende dieses Blogbeitrags finden Sie Links zu Artikeln, in denen erläutert wird, wie Sie NGINX Plus in gängige Plattformen und Diensterkennungstools integrieren, die DNS verwenden.

Ein kurzer Überblick über die wichtigsten DNS-Funktionen

Bevor wir erklären, wie die Serviceerkennung über DNS konfiguriert wird, werfen wir einen kurzen Blick auf einige besonders relevante oder nützliche Funktionen des DNS-Protokolls.

Gültigkeitsdauer

Um zu verhindern, dass DNS-Clients veraltete Informationen verwenden, enthalten DNS-Einträge das Feld „Time-to-Live“ (TTL), das festlegt, wie lange Clients den Eintrag als gültig betrachten können. Zur Einhaltung der DNS-Standards müssen Clients den DNS-Server nach einer Aktualisierung abfragen, sobald die TTL eines Eintrags abgelaufen ist. NGINX Plus berücksichtigt die TTL standardmäßig, bietet jedoch auch eine präzisere Steuerung der „Lebensdauer“ eines Eintrags: Sie können NGINX Plus so konfigurieren, dass TTLs ignoriert und Einträge stattdessen in einem festgelegten Intervall aktualisiert werden. (Wie NGINX Open Source mit der TTL umgeht, erläutern wir später in diesem Beitrag.)

DNS über TCP

Standardmäßig kommunizieren DNS-Clients und -Server über UDP. Wenn ein Domainname jedoch in eine große Anzahl von Backend-IP-Adressen aufgelöst wird, passt die vollständige Antwort möglicherweise nicht in ein einzelnes UDP-Datagramm, dessen Größe auf 512 Byte begrenzt ist. Dieses Problem lässt sich durch die Verwendung von TCP anstelle von UDP lösen: Wenn ein vollständiger Satz von Einträgen nicht in ein Datagramm passt, setzt der Server in seiner Antwort ein Kürzungs-Flag, das den Client anweist, zu TCP zu wechseln, um alle Einträge abzurufen. DNS über TCP wird ab NGINX Version 1.9.11 und ab NGINX Plus R9 unterstützt. Weitere Informationen finden Sie im Beitrag Lastverteilung für DNS-Datenverkehr mit NGINX und NGINX Plus in unserem Blog.

SRV-Einträge

DNS löst Hostnamen in IP-Adressen auf, aber wie sieht es mit Portnummern aus? In manchen Fällen – beispielsweise beim Lastenausgleich für Docker-Container – können Sie sich nicht auf allgemein bekannte Portnummern verlassen, da die Portnummern stattdessen dynamisch zugewiesen werden. DNS verfügt über einen speziellen Eintragstyp – den Dienst-SRVEintrag –, der Portnummern und einige weitere Parameter enthält. Ab R9 unterstützt NGINX Plus SRV-Einträge (und kann daher Portinformationen daraus extrahieren).

Redaktion – Einen Überblick über alle neuen Funktionen in NGINX Plus R9 finden Sie im Beitrag „Announcing NGINX Plus R9“ in unserem Blog.

Methoden zur Serviceerkennung mit DNS für NGINX und NGINX Plus

Im Folgenden stellen wir Ihnen fünf Möglichkeiten vor, DNS für die Serviceerkennung in NGINX und NGINX Plus zu verwenden – geordnet nach zunehmender Komplexität. Die ersten drei sind sowohl in NGINX als auch in NGINX Plus verfügbar, die letzten beiden ausschließlich in NGINX Plus.

Für diesen Überblick über Methoden zur Serviceerkennung gehen wir davon aus, dass für die Zone ein autoritativer Nameserver vorhanden ist: example.com, mit der IP-Adresse 10.0.0.2. Dem Domainnamen sind drei Backend-Server zugeordnet: backends.example.com, wie die folgende Ausgabe des Dienstprogramms nslookup zeigt. Bei den ersten vier vorgestellten Methoden fragen NGINX und NGINX Plus standardmäßige A-Einträge vom DNS ab; bei der letzten Methode fragt NGINX Plus stattdessen SRV-Einträge ab.

$ 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

DNS für die Diensterkennung mit NGINX verwenden

Zunächst zeigen wir Ihnen die drei Möglichkeiten, DNS mit NGINX Open Source zu verwenden (wie oben erwähnt, können Sie diese auch mit NGINX Plus nutzen).

Verwendung des Domainnamens in der proxy_pass-Direktive

Die einfachste Möglichkeit, die Gruppe der Upstream-Server (Backends) zu definieren, besteht darin, einen Domainnamen als Parameter für die Direktive proxy_pass anzugeben:

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

Wenn NGINX gestartet oder seine Konfiguration neu geladen wird, fragt es einen DNS-Server ab, um backends.example.com aufzulösen. Der DNS-Server gibt die Liste der drei oben beschriebenen Backends zurück, und NGINX verwendet den standardmäßigen Round-Robin-Algorithmus, um die Anfragen auf diese zu verteilen. NGINX wählt den DNS-Server anhand der Betriebssystem-Konfigurationsdatei /etc/resolv.conf aus.

Diese Methode ist die unflexibelste Art der Serviceerkennung und hat außerdem folgende Nachteile:

• Wenn der Domainname nicht aufgelöst werden kann, kann NGINX nicht gestartet oder seine Konfiguration neu geladen werden.
• NGINX speichert die DNS-Einträge bis zum nächsten Neustart oder Neuladen der Konfiguration im Cache und ignoriert dabei die TTL-Werte der Einträge.
• Wir können weder einen anderen Lastverteilungsalgorithmus angeben noch passive Integritätsprüfungen oder andere Funktionen konfigurieren, die durch Parameter der server-Direktive festgelegt werden und die wir im nächsten Abschnitt beschreiben.

Verwenden eines Domainnamens in einer Upstream-Servergruppe

Um die von NGINX bereitgestellten Optionen für den Lastenausgleich zu nutzen, können Sie die Gruppe der Upstream-Server im Konfigurationsblock upstream definieren. Statt jedoch einzelne Server anhand ihrer IP-Adresse zu identifizieren, verwenden Sie den Domainnamen als Parameter für die Direktive server.

Wie bei der ersten Methode wird backends.example.com beim Starten oder Neuladen der Konfiguration von NGINX in drei Backend-Server aufgelöst. Nun können wir jedoch einen ausgefeilteren Lastverteilungsalgorithmus definieren, nämlich Least Connections, und mit dem Parameter max_fails passive Integritätsprüfungen aktivieren. Dabei wird festgelegt, dass NGINX einen Server als ausgefallen markiert, wenn drei aufeinanderfolgende Anfragen fehlschlagen.

upstream backends {    least_conn;

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

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

Obwohl wir mit dieser Methode den Lastverteilungsalgorithmus auswählen und Zustandsprüfungen konfigurieren können, weist sie in Bezug auf Start, Neuladen und TTL dieselben Nachteile wie die vorherige Methode auf.

Festlegen des Domainnamens in einer Variablen

Diese Methode ist eine Variante der ersten, ermöglicht uns jedoch zu steuern, wie oft NGINX den Domainnamen erneut auflöst:

resolver 10.0.0.2 valid=10s;
server {
    location / {
        set $backend_servers backends.example.com;
        proxy_pass http://$backend_servers:8080;
    }
}

Wenn Sie den Domänennamen mithilfe einer Variablen in der proxy_pass-Direktive angeben, löst NGINX den Domänennamen nach Ablauf seiner TTL erneut auf. Sie müssen die resolver-Direktive einfügen, um den Nameserver explizit anzugeben (NGINX greift dabei nicht wie bei den ersten beiden Methoden auf /etc/resolv.conf zurück). Mit dem Parameter valid in der resolver-Direktive können Sie NGINX anweisen, die TTL zu ignorieren und Namen stattdessen in einem festgelegten Intervall erneut aufzulösen. Hier weisen wir NGINX an, Namen alle 10 Sekunden erneut aufzulösen.

Hinweis: Für den TCP/UDP-Lastenausgleich wird diese Methode, bei der eine Variable in der proxy_pass-Direktive verwendet wird, ab NGINX 1.11.3 und ab NGINX Plus R10 unterstützt.

Diese Methode beseitigt zwei Nachteile der ersten Methode: Der Start- oder Neuladevorgang von NGINX schlägt nicht fehl, wenn der Domainname nicht aufgelöst werden kann, und wir können steuern, wie oft NGINX den Namen erneut auflöst. Da diese Methode jedoch keine Upstream-Gruppe verwendet, können Sie weder den Lastverteilungsalgorithmus noch andere Parameter für die server-Direktive angeben (wie bei der zweiten Methode).

DNS für die Serviceerkennung mit NGINX Plus verwenden

Sehen wir uns nun die beiden Methoden für die Diensterkennung mit DNS an, die ausschließlich in NGINX Plus verfügbar sind.

Verwendung von A-Einträgen mit NGINX Plus

Mit NGINX Plus können wir DNS-Namen beliebig oft neu auflösen, ohne die oben beschriebenen Nachteile der ersten drei Methoden in Kauf nehmen zu müssen. Um diese Funktion zu nutzen, müssen wir:

• Fügen Sie die Direktive „resolver“ ein, um wie bei der vorherigen Methode den Nameserver anzugeben.
• Fügen Sie die Direktive zone in den Konfigurationsblock upstream ein, um einen gemeinsam genutzten Speicherbereich zuzuweisen.
• Fügen Sie den Parameter „resolve“ zur Direktive „server“ hinzu, in der wir den Domainnamen verwenden.

Betrachten Sie das folgende Beispiel:

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

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

Standardmäßig berücksichtigt NGINX Plus die TTL und löst Namen erneut auf, wenn die Einträge ablaufen. Damit NGINX Plus Namen stattdessen in einem festgelegten Intervall erneut auflöst, fügen Sie der Direktive valid den Parameter resolver hinzu.

In diesem Codeausschnitt fragt NGINX Plus alle 10 Sekunden den Nameserver unter 10.0.0.2 ab, um backends.example.com aufzulösen. Wenn der Name nicht aufgelöst werden kann, schlägt NGINX Plus weder beim Start noch beim Neuladen der Konfiguration oder während der Laufzeit fehl. Stattdessen wird dem Client die Standardfehlerseite für den Fehler 502 angezeigt.

Verwendung von SRV-Einträgen mit NGINX Plus

NGINX Plus R9 und höher unterstützt DNS-SRV-Einträge. Dadurch kann NGINX Plus von einem Nameserver nicht nur IP-Adressen, sondern auch Portnummern, Gewichtungen und Prioritäten abrufen. Dies ist in Microservices-Umgebungen von entscheidender Bedeutung, da die Portnummern von Diensten häufig dynamisch zugewiesen werden.

Anmerkung der Redaktion – Einen Überblick über alle neuen Funktionen in NGINX Plus R9 finden Sie im Beitrag „Ankündigung von NGINX Plus R9“ in unserem Blog.

SRV-Einträge werden durch ein Tripel aus dem Dienstnamen, dem Protokoll für die Kommunikation mit dem Dienst und dem Domänennamen definiert. Bei der Abfrage des Nameservers müssen wir alle drei angeben. Unser Nameserver 10.0.0.2 verfügt über drei SRV-Einträge mit dem Dienstnamen http, dem Protokoll tcp und dem Domänennamen backends.example.com, wie diese Ausgabe des Dienstprogramms nslookup zeigt:

$ 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.

Wenn wir den Hostnamen in jedem SRV-Eintrag abfragen, erhalten wir die zugehörige IP-Adresse:

$ 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

Sehen wir uns die Informationen im ersten SRV-Eintrag, der vom ersten nslookup-Befehl zurückgegeben wurde, genauer an:

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

• _http._tcp. – Der Name und das Protokoll des SRV-Eintrags. Diesen Wert geben wir als Wert für den Parameter service in der Direktive server in der NGINX Plus-Konfigurationsdatei an (siehe unten).
• 0 – Die Priorität. Je niedriger der Wert, desto höher die Priorität. NGINX Plus legt die Server mit der höchsten Priorität als primäre Server und die übrigen Server als Backup-Server fest. Dieser Eintrag hat von allen Einträgen den niedrigsten Wert (die höchste Priorität), daher legt NGINX Plus das entsprechende Backend als primären Server fest.
• 2 – Die Gewichtung. NGINX Plus legt die Gewichtung des Backends beim Hinzufügen zur Upstream-Gruppe auf diesen Wert fest (entspricht dem Parameter weight der Direktive server).
• 8090 – Die Portnummer. NGINX Plus setzt den Port des Backends auf diesen Wert, wenn es das Backend der Upstream-Gruppe hinzufügt.
• backend‑0.example.com – Der Hostname des Backend-Servers. NGINX Plus löst diesen Namen auf und fügt das entsprechende Backend der Upstream-Gruppe hinzu. Wenn der Name in mehrere Einträge aufgelöst wird, fügt NGINX Plus mehrere Server hinzu.

Sehen wir uns nun an, wie wir NGINX Plus für die Verwendung von SRV-Einträgen konfigurieren. Hier ist die Beispielkonfigurationsdatei:

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;
    }
}

Mit dem Parameter service der Direktive server geben wir den Namen und das Protokoll der aufzulösenden SRV-Einträge an. In unserem Fall sind dies _http beziehungsweise _tcp. Abgesehen vom Parameter service und der Tatsache, dass wir keinen Port angeben, entspricht dies dem Konfigurationsbeispiel aus dem vorherigen Abschnitt.

Basierend auf den Werten, die der erste nslookup-Befehl in diesem Abschnitt zurückgibt, wird NGINX Plus mit drei Backend-Servern konfiguriert:

• 10.0.0.10 – Primärserver mit Port 8090 und Gewichtung 2.
• 10.0.0.11 – Primärserver mit Port 8091 und Gewichtung 1.
• 10.0.0.12 – Backup-Server mit Port 8092 und Gewichtung 1.

Wenn wir Live-Aktivitätsüberwachung für NGINX Plus konfigurieren, können wir diese Backends im integrierten Dashboard sehen:

Beachten Sie, wie die Anfragen entsprechend den angegebenen Gewichtungen verteilt werden. Der Server 10.0.0.11:8091 (mit der Gewichtung 1) erhält ein Drittel der Anfragen, während der Server 10.0.0.10:8090 (mit der Gewichtung 2) zwei Drittel erhält. Als Backup-Server erhält der Server 10.0.0.12:8092 nur dann Anfragen, wenn die beiden anderen Server ausgefallen sind.

Einschränkungen

Bei der Verwendung von DNS für die Diensterkennung mit NGINX Plus sind einige Punkte zu beachten:

• Der DNS-Server muss entweder hochverfügbar sein oder über einen Backup-Server verfügen. Wenn der DNS-Server nicht mehr verfügbar ist, erhält NGINX Plus keine Aktualisierungen mehr. Die vorhandenen Backends bleiben in der Konfiguration erhalten (sofern Sie NGINX Plus nicht neu starten oder die Konfiguration neu laden), wobei die TTL-Werte der entsprechenden Einträge ignoriert werden.
• Sie können mehrere Nameserver mit der Direktive „resolver“ angeben, sodass NGINX Plus die anderen ausprobiert, wenn einer davon nicht verfügbar ist.
• Wie in der Einleitung erwähnt, ist die NGINX Plus API eine Alternative zu DNS für die Serviceerkennung mit NGINX Plus. Mit ihr können Sie durch einfache HTTP-Anfragen Server zu einer Upstream-Gruppe hinzufügen oder daraus entfernen.

Beispiele

Wenn Sie sich ausführliche Beispiele ansehen möchten, lesen Sie diese Blogbeiträge über die Integration von NGINX und NGINX Plus mit Service-Discovery-Plattformen, die DNS verwenden:

• Diensterkennung für NGINX Plus mithilfe von DNS-SRV-Einträgen aus Consul
• Lastverteilung für Kubernetes-Dienste mit NGINX Plus

Wir werden diese Liste aktualisieren, sobald wir künftig weitere Beiträge über neue Integrationsmöglichkeiten veröffentlichen.

Fazit

Die Diensterkennung über DNS, die in NGINX Plus vollständig verfügbar ist, bietet eine einfache Möglichkeit, die Konfiguration des Loadbalancers in einer Microservices-Umgebung zu aktualisieren. Die Unterstützung für SRV-Einträge ab Version 9 macht NGINX Plus noch leistungsfähiger, da NGINX Plus dadurch nicht nur die IP-Adressen, sondern auch die Portnummern der Backends abrufen kann.

Möchten Sie die Diensterkennung über DNS für NGINX Plus und die weiteren erweiterten Funktionen ausprobieren? Starten Sie noch heute Ihre kostenlose 30-Tage-Testversion oder kontaktieren Sie uns, um Ihre Anwendungsfälle zu besprechen.

Über den Autor

Michael Pleshakov

Weitere Blogbeiträge von Michael Pleshakov