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

Owen GarrettSenior Director, Produktmanagement

Redaktion – Dies ist der erste Teil einer Reihe über 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 und verweist nun auf die NGINX Plus API, die das ursprünglich hier behandelte separate Modul für erweiterte Statusinformationen ersetzt und als veraltet kennzeichnet.

Wie können Sie mit NGINX oder NGINX Plus einen hochverfügbaren Cache-Cluster mit großer Kapazität aufbauen? Dies ist der erste Teil einer zweiteiligen Reihe, in der alternative Ansätze zum Erreichen dieses Ziels vorgestellt werden. Den zweiten Teil können Sie über den obigen Link aufrufen. (Sofern nicht anders angegeben, gelten die Ansätze gleichermaßen für NGINX Open Source und NGINX Plus; der Kürze halber sprechen wir jedoch nur von NGINX Plus.)

Überblick über das Caching mit NGINX Plus

NGINX Plus kann als Proxy-Cache-Server zwischen dem Ursprungsserver und den Remote-Clients eingesetzt werden. NGINX Plus verwaltet den Datenverkehr zum Ursprungsserver und speichert häufig verwendete, unveränderliche Ressourcen im Cache. Dadurch kann NGINX Plus bei Anfragen nach diesen Ressourcen direkt auf die Clients antworten und so die Last auf dem Ursprungsserver reduzieren. Der Proxy-Cache von NGINX Plus wird meist in einem Rechenzentrum in der Nähe des Ursprungsservers bereitgestellt, kann aber auch nach Art eines CDN in weltweit verteilten PoPs eingesetzt werden.

Das Caching 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 Cachings mit NGINX Plus – Grundlegende Konfiguration und die Rolle der Prozesse zum Laden und Verwalten des Caches
• Feinabstimmung der Cache-Zeiten – Implementierung von Verfahren wie Microcaching, um zu steuern, wie Inhalte zwischengespeichert und nach Ablauf ihrer Gültigkeit aktualisiert werden

Warum verwendet NGINX Plus keinen gemeinsam genutzten Datenträger für das Caching?

Jeder NGINX Plus-Server fungiert als eigenständiger Webcache-Server. Es gibt keine technische Möglichkeit, einen festplattenbasierten Cache von mehreren NGINX Plus-Servern gemeinsam zu nutzen. Dies ist eine bewusste Designentscheidung.

Das Speichern eines Caches auf einem gemeinsam genutzten Dateisystem mit hoher Latenz und potenziell geringer Zuverlässigkeit ist keine gute Designentscheidung. NGINX Plus reagiert empfindlich auf Festplattenlatenzen. Zwar verlagert die Threadpool-Funktion die Operationen read() und write() aus dem Hauptthread, doch wenn das Dateisystem langsam und die Cache-E/A hoch ist, kann NGINX Plus durch eine große Anzahl von Threads überlastet werden. Die Verwaltung eines konsistenten, gemeinsam genutzten Caches über mehrere NGINX Plus-Instanzen hinweg würde außerdem clusterweite Sperren erfordern, um sich überschneidende Cache-Vorgänge wie Befüllen, Lesen und Löschen zu synchronisieren. Schließlich führen gemeinsam genutzte Dateisysteme zu mangelnder Zuverlässigkeit und unvorhersehbarer Cache-Leistung – in einem Bereich, in dem Zuverlässigkeit und gleichbleibende Leistung von größter Bedeutung sind.

Warum sollte ein Cache von mehreren NGINX Plus-Servern gemeinsam genutzt werden?

Obwohl die gemeinsame Nutzung eines Dateisystems kein guter Ansatz für das Caching ist, gibt es dennoch gute Gründe, Inhalte über mehrere NGINX Plus-Server hinweg zwischenzuspeichern. Für jeden dieser Gründe gibt es eine entsprechende Methode:

• Wenn Ihr Hauptziel darin besteht, einen Cache mit sehr hoher Kapazität zu erstellen, verteilen (partitionieren) Sie Ihren Cache auf mehrere Server. Diese Technik wird in diesem Beitrag erläutert.
• Wenn Ihr Hauptziel darin besteht, eine hohe Verfügbarkeit zu erreichen und gleichzeitig die Last auf den Ursprungsservern zu minimieren, verwenden Sie einen hochverfügbaren gemeinsam genutzten Cache. Weitere Informationen zu dieser Technik finden Sie im ergänzenden Beitrag (demnächst verfügbar).

Cache-Sharding

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

Die gesamte Cache-Kapazität entspricht der Summe der Cache-Kapazitäten aller Server. Zugriffe auf den Ursprungsserver werden minimiert, da jede Ressource nur von einem Server zwischengespeichert wird (es gibt also nicht mehrere unabhängige Kopien derselben Ressource).

Dieses Muster ist insofern fehlertolerant, als Sie bei N Cache-Servern und dem Ausfall eines Servers nur 1/N Ihres Caches verlieren. Dieser „verlorene Anteil“ wird durch das konsistente Hashing gleichmäßig auf die verbleibenden N –1 Server verteilt. Einfachere Hashing-Verfahren verteilen hingegen den gesamten Cache neu auf die verbleibenden Server, sodass Sie während der Neuverteilung fast Ihren gesamten Cache verlieren.

Wenn Sie Load-Balancing mit konsistentem Hashing durchführen, verwenden Sie den Cache-Schlüssel (oder eine Teilmenge der Felder, aus denen der Schlüssel erstellt wird) als Schlüssel für den konsistenten Hash:

upstream cache_servers {    hash $scheme$proxy_host$request_uri consistent;

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

Sie können den eingehenden Datenverkehr auf die Load-Balancer-Ebene (LB) 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 zwischen zwei Optimierungen für Ihre Cache-Sharding-Konfiguration wählen.

Load-Balancer- und Cache-Ebenen kombinieren

Sie können die LB- und Cache-Ebenen kombinieren. In dieser Konfiguration werden auf jeder NGINX Plus-Instanz zwei virtuelle Server ausgeführt. Der virtuelle Lastverteilungsserver („LB VS“ in der Abbildung) nimmt Anfragen von externen Clients entgegen und verteilt sie mithilfe eines konsistenten Hash-Verfahrens auf alle NGINX Plus-Instanzen im Cluster, die über ein internes Netzwerk miteinander verbunden sind. Der virtuelle Caching-Server („Cache VS“) auf jeder NGINX Plus-Instanz lauscht unter seiner internen IP-Adresse auf den ihm zugewiesenen Anteil der Anfragen, leitet diese an den Ursprungsserver weiter und speichert die Antworten im Cache. Dadurch können alle NGINX Plus-Instanzen als Caching-Server fungieren, sodass Ihre Cache-Kapazität optimal genutzt wird.

Konfigurieren eines „Hot“-Caches der ersten Ebene

Alternativ können Sie auf der Frontend-LB-Ebene einen First-Level-Cache für besonders häufig abgerufene Inhalte konfigurieren und den großen gemeinsam genutzten Cache als Second-Level-Cache verwenden. Dies kann die Leistung verbessern und bei einem Ausfall der Second-Level-Cache-Ebene die Auswirkungen auf den Ursprungsserver verringern, da die Inhalte nur in dem Maße aktualisiert werden müssen, wie sie nach und nach aus dem First-Level-Cache ablaufen.

Wenn Ihr Cache-Cluster eine sehr große Menge häufig abgerufener Inhalte 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 groß, dass Inhalte aus dem Cache entfernt werden (um Platz für zuletzt angeforderte Inhalte zu schaffen), bevor sie auch nur zur Bearbeitung einer einzigen nachfolgenden Anfrage verwendet werden können.

Ein Indikator für diese Situation ist ein niedriges Verhältnis zwischen bereitgestellten und geschriebenen Inhalten. Diese beiden Metriken sind in den erweiterten Statistiken enthalten, die vom NGINX Plus API-Modul gemeldet werden. Sie werden in den Feldern Bereitgestellt und Geschrieben auf der Registerkarte Caches des integrierten Dashboards zur Überwachung der Live-Aktivität angezeigt. (Beachten Sie, dass das NGINX Plus API-Modul und das Dashboard zur Überwachung der Live-Aktivität in NGINX Open Source nicht verfügbar sind.)

Dieser Screenshot zeigt eine Situation, in der NGINX Plus mehr Inhalte 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, diese Inhalte zu identifizieren.

Zusammenfassung

Die Aufteilung eines Caches auf mehrere NGINX- oder NGINX Plus-Webcache-Server ist eine effektive Möglichkeit, einen skalierbaren Cache mit sehr hoher Kapazität zu erstellen. Konsistentes Hashing sorgt für ein hohes Maß an Verfügbarkeit und stellt sicher, dass beim Ausfall eines Caches nur der ihm zugewiesene Anteil der zwischengespeicherten Inhalte ungültig wird.

Im zweiten Teil dieses Beitrags wird ein alternatives Muster für einen gemeinsam genutzten Cache beschrieben, bei dem der Cache auf zwei NGINX- oder NGINX Plus-Cache-Servern repliziert wird. Die Gesamtkapazität ist auf die Kapazität eines einzelnen Servers begrenzt, die Konfiguration ist jedoch vollständig fehlertolerant, und es gehen keine zwischengespeicherten Inhalte verloren, wenn ein Cache-Server nicht mehr verfügbar ist.

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

Über den Autor

Owen GarrettSenior Director, Produktmanagement

Weitere Blogbeiträge von Owen Garrett