Gemeinsam genutzte Caches mit NGINX Plus Cache-Clustern, Teil 2

Herausgeber – Dies ist der zweite Teil einer Reihe zum Thema Caching mit hoher Kapazität und hoher Verfügbarkeit:

• Gemeinsam genutzte Caches mit NGINX Plus-Cache-Clustern, Teil 1
• Gemeinsam genutzte Caches mit NGINX Plus-Cache-Clustern, Teil 2 (dieser Beitrag)

Wie können Sie mit NGINX oder NGINX Plus einen Cache-Cluster mit großer Kapazität und hoher Verfügbarkeit erstellen? In diesem Beitrag wird beschrieben, wie Sie mit zwei oder mehr NGINX- oder NGINX Plus-Cache-Servern einen hochverfügbaren Cache-Cluster erstellen. (Sofern nicht anders angegeben, gilt die hier beschriebene Methode gleichermaßen für NGINX Open Source und NGINX Plus, der Kürze halber beziehen wir uns jedoch nur auf NGINX Plus.)

Rezension – Die Sharded Cache-Lösung

Der erste Teil dieser Reihe beschrieb ein Muster zum Erstellen sehr großer, geteilter Cache-Cluster.

Dieses Muster ist effektiv, wenn Sie einen Cache mit sehr großer Kapazität erstellen müssen, der nach Belieben skaliert werden kann. Da jede Ressource nur auf einem Server zwischengespeichert wird, ist sie nicht vollständig fehlertolerant, aber der konsistente Hash-Lastausgleich stellt sicher, dass beim Ausfall eines Servers nur sein Anteil des zwischengespeicherten Inhalts ungültig wird.

Erstellen eines hochverfügbaren Cache-Clusters

Wenn die Minimierung der Anzahl der Anfragen an Ihre Ursprungsserver um jeden Preis Ihr Hauptziel ist, ist die Cache-Sharding-Lösung nicht die beste Option. Stattdessen kann eine Lösung mit sorgfältiger Konfiguration primärer und sekundärer NGINX Plus-Instanzen Ihre Anforderungen erfüllen:

Die primäre NGINX Plus-Instanz empfängt den gesamten Datenverkehr und leitet Anfragen an die sekundäre Instanz weiter. Die sekundäre Instanz ruft den Inhalt vom Ursprungsserver ab und speichert ihn im Cache. Die primäre Instanz speichert auch die Antwort der sekundären Instanz im Cache und gibt sie an den Client zurück.

Beide Geräte verfügen über vollständig aufgefüllte Caches und der Cache wird entsprechend Ihren konfigurierten Timeouts aktualisiert.

Konfigurieren des primären Cache-Servers

Konfigurieren Sie den primären Cache-Server so, dass alle Anforderungen an den sekundären Server weitergeleitet und die Antworten zwischengespeichert werden. Wie durch den Backup- Parameter der Serverdirektive in der Upstream-Gruppe angegeben, leitet der primäre Server Anfragen direkt an den Ursprungsserver weiter, falls der sekundäre Server ausfällt:

proxy_cache_path /tmp/mycache keys_zone=mycache:10m; server { status_zone mycache; # für erweiterten Status von NGINX Plus listen 80; proxy_cache mycache; proxy_cache_valid 200 15s; location / { proxy_pass http://secondary; } } upstream secondary { zone secondary 128k; # für erweiterten Status von NGINX Plus Server 192.168.56.11; # sekundärer Server 192.168.56.12 Backup ; # Herkunft }

Konfigurieren des sekundären Cache-Servers

Konfigurieren Sie den sekundären Cache-Server so, dass er Anforderungen an den Ursprungsserver weiterleitet und Antworten zwischenspeichert.

proxy_cache_path /tmp/mycache keys_zone=mycache:10m;
server {
status_zone mycache; # für erweiterten NGINX Plus-Status

listen 80;

proxy_cache mycache;
proxy_cache_valid 200 15s;

location / {
proxy_pass http://origin;
}
}

upstream origin {
zone origin 128k; # für erweiterten NGINX Plus-Status

server 192.168.56.12; # origin
}

Konfigurieren von Hochverfügbarkeit

Schließlich müssen Sie eine hohe Verfügbarkeit (HA) konfigurieren, sodass der sekundäre Server den eingehenden Datenverkehr übernimmt, wenn der primäre Server ausfällt, und der primäre Server den Datenverkehr zurücknimmt, wenn er anschließend wiederhergestellt ist.

In diesem Beispiel verwenden wir die Aktiv-Passiv-HA-Lösung für NGINX Plus . Die extern angekündigte virtuelle IP-Adresse lautet 192.168.56.20 und der primäre Cache-Server fungiert als primärer Knoten für HA im Cluster. Wenn Sie NGINX Open Source verwenden, können Sie Keepalived oder eine andere HA-Lösung manuell installieren und konfigurieren.

Failover-Szenarien

Denken Sie daran, dass wir einen hochverfügbaren Cache-Cluster erstellen möchten, der auch dann weiter funktioniert, wenn ein Cache-Server ausfällt. Wir möchten nicht, dass die Belastung des Ursprungsservers zunimmt, entweder wenn ein Cache-Server ausfällt oder wenn er wiederhergestellt wird und veraltete Inhalte aktualisieren muss.

Angenommen, der Primärserver fällt aus und die NGINX Plus HA-Lösung überträgt die externe IP-Adresse an den Sekundärserver.

Der sekundäre Server verfügt über einen vollen Cache und arbeitet normal weiter. Es entsteht keine zusätzliche Belastung des Ursprungsservers.

Wenn der primäre Cache-Server wiederhergestellt ist und wieder Client-Datenverkehr empfängt, ist sein Cache veraltet und viele Einträge sind abgelaufen. Der primäre Server aktualisiert seinen lokalen Cache vom sekundären Cacheserver. Da der Cache auf dem sekundären Server bereits auf dem neuesten Stand ist, kommt es zu keiner Zunahme des Datenverkehrs zum Ursprungsserver.

Nehmen wir nun an, dass die Sekundärseite ausfällt . Der Primärserver erkennt dies (mithilfe einer Integritätsprüfung, die als Teil der HA-Lösung konfiguriert ist) und leitet den Datenverkehr direkt an den Backup-Server (den Ursprungsserver) weiter.

Der primäre Server verfügt über einen vollen Cache und arbeitet normal weiter. Auch hier entsteht keine zusätzliche Belastung des Ursprungsservers.

Wenn der sekundäre Server wiederhergestellt wird, ist sein Cache veraltet. Allerdings empfängt es nur dann Anforderungen vom Primärserver, wenn der Cache des Primärservers abläuft. Zu diesem Zeitpunkt ist auch die Kopie des Sekundärservers abgelaufen. Auch wenn der sekundäre Server eine Inhaltsanforderung vom Ursprungsserver stellen muss, erhöht dies nicht die Häufigkeit der Anforderungen an den Ursprung. Es gibt keine negativen Auswirkungen auf den Ursprungsserver.

Testen des Failover-Verhaltens

Um unsere HA-Lösung zu testen, konfigurieren wir den Ursprungsserver so, dass er Anfragen protokolliert und für jede Anfrage die aktuelle Zeit zurückgibt . Dies bedeutet, dass sich die Antwort des Ursprungsservers jede Sekunde ändert:

access_log /var/log/nginx/access.log;
location / {
return 200 "Es ist jetzt $time_localn";
}

Die primären und sekundären Cache-Server sind bereits so konfiguriert, dass sie Antworten mit dem Statuscode zwischenspeichern200 für 15 Sekunden. Dies führt normalerweise zu Cache-Updates alle 15 oder 16 Sekunden.

Proxy_Cache_gültig 200 15 s;

Überprüfen des Cacheverhaltens

Einmal pro Sekunde senden wir eine HTTP-Anfrage an die hochverfügbare virtuelle IP-Adresse für den Cache-Cluster. Die Antwort ändert sich nicht, bis die Caches auf dem primären und sekundären Server ablaufen und die Antwort vom Ursprungsserver aktualisiert wird. Dies geschieht alle 15 oder 16 Sekunden.

$ while sleep 1 ; do curl http://192.168.56.20/ ; done Es ist jetzt 9/Feb/2017:06:35:03 -0800 Es ist jetzt 9/Feb/2017:06:35:03 -0800 Es ist jetzt 9/Feb/2017:06:35:03 -0800 Es ist jetzt 9/Feb/2017:06:35:19 -0800 Es ist jetzt 9/Feb/2017:06:35:19 -0800 ^C

Wir können auch die Protokolle auf dem Ursprungsserver prüfen, um zu bestätigen, dass dieser nur alle 15 oder 16 Sekunden eine Anfrage empfängt.

Überprüfen des Failovers

Wir können überprüfen, ob das Failover ordnungsgemäß funktioniert, indem wir entweder den primären oder den sekundären Server stoppen, beispielsweise indem wir die Nginx -Prozesse stoppen. Der Dauerlasttest wird weiterhin ausgeführt und die Antwort wird durchgehend zwischengespeichert.

Die Überprüfung des Zugriffsprotokolls auf dem Ursprungsserver bestätigt, dass dieser nur alle 15 bis 16 Sekunden eine Anfrage empfängt, unabhängig davon, welcher Cache-Server ausfällt oder wiederhergestellt wird.

Zeitpunkt der Cache-Aktualisierungen

In einer stabilen Situation wird der zwischengespeicherte Inhalt normalerweise alle 15 bis 16 Sekunden aktualisiert. Der Inhalt läuft nach 15 Sekunden ab und es gibt eine Verzögerung von bis zu 1 Sekunde, bevor die nächste Anfrage empfangen wird, was eine Cache-Aktualisierung verursacht.

Gelegentlich scheint die Cache-Aktualisierung langsamer zu sein (bis zu 30 Sekunden zwischen Inhaltsänderungen). Dies tritt auf, wenn der Inhalt des primären Cache-Servers abläuft und der primäre Server zwischengespeicherte Inhalte, die fast abgelaufen sind, vom sekundären Server abruft. Wenn dies ein Problem darstellt, können Sie auf dem sekundären Server ein kürzeres Cache-Timeout konfigurieren.

Zusammenfassung

Durch die hier beschriebene Aufteilung der Caches auf zwei oder mehr NGINX-Cache-Server lässt sich effektiv ein Cache-Cluster mit hoher Verfügbarkeit erstellen, der die Belastung der Ursprungsserver minimiert und sie vor Verkehrsspitzen schützt, wenn einer der Cache-Server ausfällt oder wiederhergestellt wird.

Die Gesamtkapazität des Cache ist auf die Kapazität eines einzelnen Cache-Servers begrenzt. Der erste Teil dieser Reihe beschreibt ein alternatives Sharded-Cache-Muster, das einen Cache auf einen Cluster von Cache-Servern verteilt. In diesem Fall entspricht die Gesamtkapazität der Summe aller Cache-Server, der Inhalt wird jedoch nicht repliziert, um vor Datenverkehrsspitzen zum Ursprungsserver zu schützen, falls ein Cache-Server ausfällt.

Probieren Sie Hochverfügbarkeits-Caching auf Ihren eigenen Servern aus – starten Sie noch heute Ihre kostenlose 30-Tage-Testversion oder kontaktieren Sie uns, um Ihre Anwendungsfälle zu besprechen .