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

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

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

Dieser Beitrag wurde aktualisiert, um auf die NGINX Plus-API zu verweisen, die das ursprünglich hier besprochene separate erweiterte Statusmodul ersetzt und veraltet.

Wie können Sie mit NGINX oder NGINX Plus einen Cache-Cluster mit großer Kapazität und hoher Verfügbarkeit erstellen? Dies ist der erste Teil einer zweiteiligen Serie, die einen alternativen Ansatz zur Erreichung dieses Ziels vorstellt. Den zweiten Teil erreichen Sie über den oben stehenden Link. (Sofern nicht anders angegeben, gelten die Ansätze gleichermaßen für NGINX Open Source und NGINX Plus, der Kürze halber beziehen wir uns jedoch nur auf NGINX Plus.)

Ein Überblick über NGINX Plus-Caching

NGINX Plus kann als Proxy-Cache-Server fungieren und zwischen dem Ursprungsserver und den Remote-Clients sitzen. NGINX Plus verwaltet den Datenverkehr zum Ursprungsserver und speichert gemeinsame, unveränderliche Ressourcen im Cache. Dadurch kann NGINX Plus den Clients bei Anforderungen dieser Ressourcen direkt antworten und so die Belastung des Ursprungsservers verringern. Der Proxy-Cache von NGINX Plus wird am häufigsten in einem Rechenzentrum neben dem Ursprungsserver bereitgestellt und kann auch in einer CDN-ähnlichen Weise in weltweit verteilten PoPs eingesetzt werden.

Das Zwischenspeichern von Inhalten ist ein überraschend komplexes Thema. Bevor Sie mit diesem Artikel fortfahren, sollten Sie sich mit einigen grundlegenden Caching-Techniken vertraut machen:

• Die Funktionsweise des NGINX Plus-Cachings – Kernkonfiguration und die Rolle der Cache-Loader- und Cache-Manager-Prozesse
• Feinabstimmung der Cache-Zeiten – Implementierung von Verfahren wie Mikrocaching, um zu steuern, wie Inhalte zwischengespeichert und nach Ablauf aktualisiert werden

Warum verwendet NGINX Plus keine gemeinsam genutzte Festplatte zum Caching?

Jeder NGINX Plus-Server fungiert als unabhängiger Web-Cache-Server. Es gibt keine technische Möglichkeit, einen festplattenbasierten Cache zwischen mehreren NGINX Plus-Servern zu teilen. Dies ist eine bewusste Designentscheidung.

Das Speichern eines Caches auf einem gemeinsam genutzten Dateisystem mit hoher Latenz und möglicherweise unzuverlässigem Betrieb ist keine gute Designentscheidung. NGINX Plus reagiert empfindlich auf Festplattenlatenz und obwohl die Thread-Pool-Funktion Lese- und Schreibvorgänge vom Haupt-Thread entlastet, kann NGINX Plus bei langsamem Dateisystem und hohem Cache-E/A durch eine große Anzahl von Threads überlastet werden. Für die Aufrechterhaltung eines konsistenten, gemeinsam genutzten Caches über alle NGINX Plus-Instanzen hinweg wären außerdem clusterweite Sperren erforderlich, um sich überschneidende Cache-Vorgänge wie Füll-, Lese- und Löschvorgänge zu synchronisieren. Schließlich führen gemeinsam genutzte Dateisysteme zu Unzuverlässigkeit und unvorhersehbarer Leistung beim Caching, wo Zuverlässigkeit und gleichbleibende Leistung von größter Bedeutung sind.

Warum einen Cache auf mehreren NGINX Plus-Servern gemeinsam nutzen?

Obwohl die gemeinsame Nutzung eines Dateisystems keine gute Methode zum Zwischenspeichern ist, gibt es dennoch gute Gründe, Inhalte auf mehreren NGINX Plus-Servern zwischenzuspeichern, jeweils mit einer entsprechenden Technik:

• Wenn Ihr Hauptziel die Erstellung eines Cache mit sehr hoher Kapazität ist, verteilen Sie Ihren Cache auf mehrere Server. Wir werden diese Technik in diesem Beitrag behandeln.
• Wenn Ihr Hauptziel darin besteht, eine hohe Verfügbarkeit zu erreichen und gleichzeitig die Belastung der Ursprungsserver zu minimieren, verwenden Sie einen hochverfügbaren gemeinsam genutzten Cache. Informationen zu dieser Technik finden Sie im Begleitbeitrag (in Kürze verfügbar).

Ihren Cache teilen

Beim Sharding eines Caches werden Cache-Einträge auf mehrere Web-Cache-Server verteilt. NGINX Plus-Cache-Sharding verwendet einen konsistenten Hashing-Algorithmus, um für jeden Cache-Eintrag einen Cache-Server auszuwählen. Die Abbildungen zeigen, was mit einem auf drei Server verteilten Cache passiert (linke Abbildung), wenn entweder ein Server ausfällt (mittlere Abbildung) oder ein weiterer Server hinzugefügt wird (rechte Abbildung).

Die gesamte Cachekapazität ist die Summe der Cachekapazitäten aller Server. Sie minimieren die Fahrten zum Ursprungsserver, da nur ein Server versucht, jede Ressource im Cache zu speichern (Sie verfügen nicht über mehrere unabhängige Kopien derselben Ressource).

Dieses Muster ist fehlertolerant in dem Sinne, dass Sie nur 1/ N Ihres Caches verlieren, wenn Sie N Cache-Server haben und einer ausfällt. Dieser „verlorene Anteil“ wird durch den konsistenten Hash gleichmäßig auf die verbleibenden N –1 Server verteilt. Einfachere Hashing-Methoden verteilen stattdessen den gesamten Cache auf die verbleibenden Server und Sie verlieren bei der Neuverteilung fast Ihren gesamten Cache.

Wenn Sie einen konsistenten Hash-Lastausgleich durchführen, verwenden Sie den Cache-Schlüssel (oder eine Teilmenge der Felder, die zum Erstellen des Schlüssels verwendet werden) als Schlüssel für den konsistenten Hash:

Upstream-Cacheserver { Hash $scheme$proxy_host$request_uri konsistent;

Server red.cache.example.com;
Server green.cache.example.com;
Server blue.cache.example.com;
}

Sie können eingehenden Datenverkehr über die Load Balancer (LB)-Ebene verteilen, indem Sie die Aktiv-Passiv-Hochverfügbarkeitslösung in NGINX Plus , Round-Robin-DNS oder eine Hochverfügbarkeitslösung wie Keepalived verwenden.

Optimieren Ihrer Sharded Cache-Konfiguration

Sie können für Ihre Cache-Sharding-Konfiguration zwischen zwei Optimierungen wählen.

Kombinieren der Load Balancer- und Cache-Ebenen

Sie können die LB- und Cache-Ebenen kombinieren. In dieser Konfiguration laufen auf jeder NGINX Plus-Instanz zwei virtuelle Server . Der virtuelle Lastausgleichsserver („LB VS“ in der Abbildung) akzeptiert Anfragen von externen Clients und verwendet einen konsistenten Hash, um sie auf alle NGINX Plus-Instanzen im Cluster zu verteilen, die über ein internes Netzwerk verbunden sind. Der virtuelle Caching-Server („Cache VS“) auf jeder NGINX Plus-Instanz überwacht seinen Anteil an Anfragen auf seiner internen IP-Adresse, leitet sie an den Ursprungsserver weiter und speichert die Antworten im Cache. Dadurch können alle NGINX Plus-Instanzen als Caching-Server fungieren und Ihre Cache-Kapazität maximieren.

Konfigurieren eines „Hot“-Cache der ersten Ebene

Alternativ können Sie einen First-Level-Cache auf der Front-End-LB-Ebene für sehr heiße Inhalte konfigurieren und den großen gemeinsam genutzten Cache als Second-Level-Cache verwenden. Dadurch kann die Leistung verbessert und die Auswirkungen auf den Ursprungsserver verringert werden, wenn eine Cache-Ebene der zweiten Ebene ausfällt, da der Inhalt nur aktualisiert werden muss, wenn der Cache-Inhalt der ersten Ebene nach und nach abläuft.

Wenn Ihr Cache-Cluster sehr große Mengen an Hot Content verarbeitet, stellen Sie möglicherweise fest, dass die Fluktuationsrate im kleineren Cache der ersten Ebene sehr hoch ist. Mit anderen Worten: Die Nachfrage nach dem begrenzten Speicherplatz im Cache ist so hoch, dass Inhalte aus dem Cache gelöscht werden (um Platz für kürzlich angeforderte Inhalte zu schaffen), bevor diese auch nur zur Erfüllung einer nachfolgenden Anforderung verwendet werden können.

Ein Indikator für diese Situation ist ein niedriges Verhältnis von bereitgestelltem zu geschriebenem Inhalt, zwei Kennzahlen, die in den erweiterten Statistiken enthalten sind, die vom NGINX Plus API- Modul gemeldet werden. Sie werden in den Feldern „Bereitgestellt“ und „Geschrieben“ auf der Registerkarte „Caches “ des integrierten Dashboards zur Live-Aktivitätsüberwachung angezeigt. (Beachten Sie, dass das NGINX Plus API- Modul und das Dashboard zur Live-Aktivitätsüberwachung in NGINX Open Source nicht verfügbar sind.)

Dieser Screenshot zeigt die Situation, in der NGINX Plus mehr Inhalt in den Cache schreibt, als es daraus bereitstellt:

In diesem Fall können Sie Ihren Cache so optimieren, dass nur die am häufigsten angeforderten Inhalte gespeichert werden. Die Direktive proxy_cache_min_uses kann dabei helfen, diesen Inhalt zu identifizieren.

Zusammenfassung

Durch das Sharding eines Caches über mehrere NGINX- oder NGINX Plus-Web-Cache-Server lässt sich effektiv ein skalierbarer Cache mit sehr hoher Kapazität erstellen. Der konsistente Hash bietet ein hohes Maß an Verfügbarkeit und stellt sicher, dass bei einem Cache-Fehler nur sein Anteil des zwischengespeicherten Inhalts ungültig wird.

Der zweite Teil dieses Beitrags beschreibt ein alternatives gemeinsam genutztes Cache-Muster, das den Cache auf einem Paar von NGINX- oder NGINX Plus-Cache-Servern repliziert. Die Gesamtkapazität ist auf die Kapazität eines einzelnen Servers beschränkt, die Konfiguration ist jedoch vollständig fehlertolerant und es geht kein zwischengespeicherter Inhalt verloren, wenn ein Cache-Server nicht verfügbar ist.

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