Best Practices für Memorystore for Redis Cluster

Auf dieser Seite finden Sie Informationen zur optimalen Verwendung von Memorystore for Redis Cluster. Auf dieser Seite werden auch potenzielle Probleme aufgezeigt, die vermieden werden sollten.

Hinweis: Beispiele für die Konfiguration von Redis-Cluster-Clients finden Sie unter Codebeispiele für Clientbibliotheken.

Best Practices für die Speicherverwaltung

In diesem Abschnitt werden Strategien für die Speicherverwaltung für Cluster beschrieben, damit Memorystore for Redis Cluster effizient für Ihre Clientanwendungen funktioniert.

Konzepte zur Speicherverwaltung

• Schreiblast: Das Volumen und die Geschwindigkeit, mit der Sie Schlüssel in Ihrem Redis-Cluster hinzufügen oder aktualisieren. Die Schreiblast kann je nach Redis-Anwendungsfall und Anwendungsmustern von normal bis sehr hoch reichen.

• Entfernungsrichtlinie: Memorystore for Redis Cluster verwendet die Entfernungsrichtlinie volatile-lru. Mit Befehlen wie EXPIRE können Sie die Verdrängung von Schlüsseln festlegen.

Cluster mit normaler Schreiblast überwachen

Sehen Sie sich den Messwert /cluster/memory/maximum_utilization an. Wenn /cluster/memory/maximum_utilization bei 100% oder niedriger liegt, ist die Leistung Ihres Redis-Clusters bei einer normalen Schreiblast gut.

Wenn die Arbeitsspeichernutzung jedoch fast 100% erreicht und Sie davon ausgehen, dass die Datennutzung zunimmt, sollten Sie die Clustergröße erhöhen, um Platz für neue Daten zu schaffen.

Cluster mit hoher Schreiblast überwachen

Sehen Sie sich den Messwert /cluster/memory/maximum_utilization an. Je nach Schweregrad der hohen Schreiblast kann es bei folgenden Schwellenwerten zu Leistungsproblemen im Cluster kommen:

• Bei sehr hohen Schreiblasten können Probleme auftreten, wenn /cluster/memory/maximum_utilization 65% oder mehr erreicht.

• Bei mäßig hohen Schreiblasten können Probleme auftreten, wenn /cluster/memory/maximum_utilization 85% oder mehr erreicht.

In diesen Szenarien sollten Sie die Clustergröße erhöhen, um die Leistung zu verbessern.

Wenn Probleme auftreten oder Sie befürchten, dass Ihr Cluster eine hohe Schreiblast hat, wenden Sie sich an den Google Cloud -Support.

Shards skalieren

Wenn Sie die Anzahl der Shards in einem Cluster skalieren, sollten Sie dies in Zeiten mit wenigen Schreibvorgängen tun. Das Skalieren in Zeiten hoher Schreiblast kann aufgrund des Speicher-Overheads, der durch Replikation oder Slot-Migration verursacht wird, zu einer hohen Speicherauslastung Ihres Clusters führen.

Wenn Ihr Redis-Anwendungsfall Schlüsselentfernungen verwendet, kann die Skalierung auf eine kleinere Clustergröße die Cache-Trefferquote reduzieren. In diesem Fall müssen Sie sich jedoch keine Sorgen um Datenverlust machen, da die Schlüsselentfernung erwartet wird.

Bei Redis-Anwendungsfällen, in denen Sie keine Schlüssel verlieren möchten, sollten Sie nur auf einen kleineren Cluster herunterskalieren, der noch genügend Platz für Ihre Daten bietet. Die neue Zielanzahl von Shards sollte mindestens das 1,5-Fache des von Daten verwendeten Arbeitsspeichers zulassen. Mit anderen Worten: Sie sollten genügend Shards für das 1, 5-Fache der Datenmenge in Ihrem Cluster bereitstellen. Mit dem Messwert /cluster/memory/total_used_memory können Sie sehen, wie viele Daten in Ihrem Cluster gespeichert sind.

Best Practices für die CPU-Nutzung

Wenn ein unerwarteter Zonenausfall auftritt, führt dies zu einer Reduzierung der CPU-Ressourcen für Ihren Cluster, da die Kapazität von Knoten in der nicht verfügbaren Zone verloren geht. Wir empfehlen die Verwendung von hochverfügbaren Clustern. Wenn Sie mehrere Replikate pro Shard (im Gegensatz zu einem Replikat pro Shard) verwenden, stehen Ihnen bei einem Ausfall zusätzliche CPU-Ressourcen zur Verfügung. Sie können bis zu fünf Replikate pro Shard haben.

Außerdem empfehlen wir, die CPU-Auslastung der Knoten so zu verwalten, dass die Knoten genügend CPU-Overhead haben, um zusätzlichen Traffic von verlorener Kapazität zu verarbeiten, wenn ein unerwarteter zonaler Ausfall auftritt. Sie sollten die CPU-Auslastung für Primärinstanzen und Replikate mit dem Messwert CPU-Sekunden des Hauptthreads /cluster/cpu/maximum_utilization überwachen.

Je nach Anzahl der Replikate, die Sie pro Knoten bereitstellen, empfehlen wir die folgenden /cluster/cpu/maximum_utilization-CPU-Nutzungsziele:

• Bei Clustern mit einem Replikat pro Knoten sollten Sie einen /cluster/cpu/maximum_utilization-Wert von 0,5 Sekunden für das primäre Replikat und 0,5 Sekunden für das Replikat anstreben.
• Bei Clustern mit zwei oder mehr Replikaten pro Knoten sollten Sie einen /cluster/cpu/maximum_utilization-Wert von 0,9 Sekunden für den primären Knoten und 0,5 Sekunden für jedes Replikat anstreben.

Wenn die Werte für den Messwert diese Empfehlungen überschreiten, empfehlen wir, die Anzahl der Shards in Ihrem Cluster zu erhöhen. Wenn Sie weniger als fünf Replikate für Ihren Cluster haben, können Sie die Anzahl der Replikate auch auf maximal fünf Replikate erhöhen.

Wenn Ihr Cluster eine hohe CPU-Auslastung aufweist oder die Ressourcen des Clusters erschöpft sind (z. B. durch zu viele Verbindungen), kann es zu Fehlern im Cluster kommen und externe Messwerte fehlen.

Ressourcenintensive Redis-Befehle

Wir empfehlen dringend, keine ressourcenintensiven Redis-Befehle zu verwenden. Die Verwendung dieser Befehle kann zu folgenden Leistungsproblemen führen:

• Hohe Latenz und Client-Zeitüberschreitungen
• Arbeitsspeichermangel, der durch Befehle verursacht wird, die die Arbeitsspeichernutzung erhöhen
• Datenverlust während der Knotenreplikation und ‑synchronisierung, weil der Redis-Hauptthread blockiert ist
• Nicht ausgeführte Systemdiagnosen, Beobachtbarkeit und Replikation

In der folgenden Tabelle sind Beispiele für ressourcenintensive Redis-Befehle aufgeführt und es werden ressourceneffiziente Alternativen vorgeschlagen.

Tipp: Diese Befehle sind nicht nur ressourcenintensiv, sondern mit zunehmender Gesamtgröße der Daten steigen auch die Kosten für die Verwendung dieser Befehle.

Mit SLOWLOG können Sie herausfinden, welche Befehle mit langer Ausführungszeit Sie verwenden. Dieses Tool bietet eine Liste der Befehle, deren Ausführung am längsten dauert. Sie kennen also die Befehle, die Latenzprobleme verursachen. In der folgenden Tabelle finden Sie ressourceneffiziente Alternativen für diese Befehle.

Kategorie	Ressourcenintensiver Befehl	Ressourceneffiziente Alternative
Für den gesamten Schlüsselbereich ausführen	KEYS	SCAN
Für einen Schlüsselsatz mit variabler Länge ausführen	LRANGE	Begrenzen Sie die Größe des Bereichs, den Sie für eine Abfrage verwenden.
	ZRANGE	Begrenzen Sie die Größe des Bereichs, den Sie für eine Abfrage verwenden.
	HGETALL	HSCAN
	SMEMBERS	SSCAN
Ausführung eines Scripts blockieren	EVAL	Achten Sie darauf, dass Ihr Script nicht unendlich lange ausgeführt wird.
	EVALSHA	Achten Sie darauf, dass Ihr Script nicht unendlich lange ausgeführt wird.
Dateien und Links entfernen	DEL	UNLINK
Veröffentlichen und abonnieren	PUBLISH	SPUBLISH
	SUBSCRIBE	SSUBSCRIBE

Best Practices für Skalierungsschwellenwerte

Szenarien für Skalierungsschwellenwerte fallen in die folgenden Kategorien:

• Skalierung für die Arbeitsspeicherauslastung
• Skalierung für CPU-Auslastung
• Skalierung zur Vermeidung von Hotspots

Wenn Ihre Arbeitslast auf dem Entfernen von Schlüsseln basiert, empfiehlt Google, die CPU- oder Arbeitsspeicherauslastung nicht zu verringern. Bei diesen Arbeitslasten erreicht die Arbeitsspeicherauslastung häufig ihre maximale Kapazität, bevor automatisch Entfernungen erfolgen. Die resultierenden Speicherspitzen blockieren Vorgänge zur Verkleinerung.

In den folgenden Abschnitten werden gängige Szenarien und Messwertschwellenwerte beschrieben, die eine Skalierung rechtfertigen könnten.

Skalierung der Arbeitsspeicherauslastung

Wenn Sie feststellen möchten, wann Sie basierend auf der Arbeitsspeichernutzung skalieren müssen, beobachten Sie die Messwerte /cluster/memory/average_utilization und /cluster/memory/maximum_utilization. Weitere Informationen zu diesen Messwerten finden Sie unter Unterstützte Monitoring-Messwerte.

Wenn Ihr Cluster eine der folgenden Bedingungen erfüllt, sollten Sie einen horizontalen Skalierungsvorgang auslösen:

• Die durchschnittliche Arbeitsspeicherauslastung Ihres Clusters überschreitet den empfohlenen Schwellenwert von 70%.
• Die maximale Arbeitsspeicherauslastung überschreitet 80% und die durchschnittliche Arbeitsspeicherauslastung überschreitet 50%.

Wenn Ihr Cluster eine der folgenden Bedingungen erfüllt, sollten Sie einen Vorgang zur Verkleinerung auslösen:

• Die durchschnittliche Arbeitsspeicherauslastung Ihres Clusters fällt unter den empfohlenen Schwellenwert von 50%.
• Die maximale Arbeitsspeicherauslastung sinkt unter 60% und die durchschnittliche Arbeitsspeicherauslastung sinkt unter 40%.

Skalierung der CPU-Auslastung

Wenn Sie die Messwerte /cluster/cpu/average_utilization und /cluster/cpu/maximum_utilization im Blick behalten, können Sie feststellen, wann eine Skalierung anhand der CPU-Auslastung erforderlich ist.

Wenn Ihr Cluster eine der folgenden Bedingungen erfüllt, sollten Sie einen horizontalen Skalierungsvorgang auslösen:

• Die durchschnittliche CPU-Auslastung Ihres Clusters überschreitet den empfohlenen Schwellenwert von 70%.
• Die maximale CPU-Auslastung überschreitet 80% und die durchschnittliche CPU-Auslastung überschreitet 50%.

Wenn Ihr Cluster eine der folgenden Bedingungen erfüllt, sollten Sie einen Vorgang zur Verkleinerung auslösen:

• Die durchschnittliche CPU-Auslastung Ihres Clusters fällt unter den empfohlenen Grenzwert von 50%.
• Die maximale CPU-Auslastung sinkt unter 60% und die durchschnittliche CPU-Auslastung unter 40%.

Skalierung zur Vermeidung von Hotspots

Memorystore for Redis Cluster bietet durchschnittliche und maximale Varianten desselben Messwerts, mit denen Sie Hotspots für diese Messwertfamilie identifizieren können. Der Höchstwert steht für den Clusterknoten mit der höchsten Last, während der Durchschnittswert die Last für den gesamten Cluster darstellt. Wenn der Höchstwert deutlich über dem Durchschnittswert liegt, deutet dies darauf hin, dass ein bestimmter Knoten unverhältnismäßig stark ausgelastet ist (ein Hotspot). Wir empfehlen, den Cluster horizontal zu skalieren, um dieses Problem zu beheben. Weitere Informationen finden Sie unter Clusterkapazität skalieren.

Wenn Sie eine erhebliche Abweichung zwischen den durchschnittlichen und maximalen Abweichungen feststellen, können Sie die Befehle INFO memory und INFO cpu für die Clusterknoten ausführen, um Echtzeitdaten direkt aus dem Cluster zu erfassen. Weitere Informationen zur Verwendung dieser Befehle finden Sie in der Redis-Dokumentation unter INFO.

Best Practices für Redis-Clients

Ihre Anwendung muss einen clusterfähigen Redis-Client verwenden, wenn sie eine Verbindung zu einem Cluster herstellt. Beispiele für clusterfähige Clients und Beispielkonfigurationen finden Sie unter Codebeispiele für Clientbibliotheken. Ihr Client muss eine Zuordnung von Hash-Slots zu den entsprechenden Knoten im Cluster verwalten, um Anfragen an die richtigen Knoten zu senden und den Leistungsaufwand durch Clusterweiterleitungen zu vermeiden.

Clientzuordnung

In den folgenden Situationen müssen Clients eine vollständige Liste der Slots und der zugeordneten Knoten abrufen:

• Wenn der Client initialisiert wird, muss er die anfängliche Zuordnung von Slots zu Knoten füllen.

• Wenn eine MOVED-Weiterleitung vom Server empfangen wird, z. B. bei einem Failover, wenn alle Slots, die vom ehemaligen primären Knoten bereitgestellt werden, vom Replikat übernommen werden, oder beim Resharding, wenn Slots vom primären Quellknoten zum primären Zielknoten verschoben werden.

• Wenn ein CLUSTERDOWN-Fehler vom Server empfangen wird oder Verbindungen zu einem bestimmten Server dauerhaft Zeitüberschreitungen verursachen.

• Wenn der Server einen READONLY-Fehler zurückgibt. Dies kann passieren, wenn eine primäre Instanz zu einem Replikat herabgestuft wird.

• Außerdem sollten Clients die Topologie regelmäßig aktualisieren, um die Clients auf Änderungen vorzubereiten und über Änderungen informiert zu werden, die möglicherweise nicht zu Weiterleitungen oder Fehlern vom Server führen, z. B. wenn neue Replikatknoten hinzugefügt werden. Beachten Sie, dass veraltete Verbindungen im Rahmen der Topologieaktualisierung ebenfalls geschlossen werden sollten, um die Notwendigkeit der Verarbeitung fehlgeschlagener Verbindungen während der Befehlsausführung zu reduzieren.

Client-Erkennung

Die Clienterkennung erfolgt in der Regel durch Senden eines CLUSTER SLOT-, CLUSTER NODE- oder CLUSTER SHARDS-Befehls an den Redis-Server. Wir empfehlen die Verwendung des Befehls CLUSTER SHARDS. CLUSTER SHARDS ersetzt den Befehl CLUSTER SLOTS (verworfen) und bietet eine effizientere und erweiterbare Darstellung des Clusters.

Die Größe der Antwort für die Befehle zur Cluster-Client-Erkennung kann je nach Clustergröße und -topologie variieren. Größere Cluster mit mehr Knoten erzeugen eine größere Antwort. Daher ist es wichtig, dass die Anzahl der Clients, die die Clustertopologie ermitteln, nicht unbegrenzt wächst.

Diese Topologieaktualisierungen sind auf dem Redis-Server ressourcenintensiv, aber auch wichtig für die Anwendungsverfügbarkeit. Daher ist es wichtig, dass jeder Client zu einem bestimmten Zeitpunkt nur eine einzige Discovery-Anfrage stellt (und das Ergebnis im Arbeitsspeicher zwischenspeichert) und die Anzahl der Clients, die die Anfragen stellen, begrenzt wird, um eine Überlastung des Servers zu vermeiden.

Wenn die Clientanwendung beispielsweise gestartet wird oder die Verbindung zum Server verliert und eine Clustererkennung durchführen muss, besteht ein häufiger Fehler darin, dass die Clientanwendung mehrere Wiederverbindungs- und Erkennungsanfragen stellt, ohne beim Wiederholungsversuch einen exponentiellen Backoff hinzuzufügen. Dies kann dazu führen, dass der Redis-Server über einen längeren Zeitraum nicht mehr reagiert, was zu einer sehr hohen CPU-Auslastung führt.

Überlastung der Erkennung in Redis vermeiden

Wir empfehlen Folgendes, um die Auswirkungen eines plötzlichen Anstiegs von Verbindungs- und Erkennungsanfragen zu minimieren:

• Implementieren Sie einen Clientverbindungspool mit einer begrenzten und kleinen Größe, um die Anzahl der gleichzeitigen eingehenden Verbindungen von der Clientanwendung zu begrenzen.

• Wenn die Verbindung des Clients zum Server aufgrund einer Zeitüberschreitung getrennt wird, versuchen Sie es mit exponentiellem Backoff mit Jitter noch einmal. So wird verhindert, dass mehrere Clients den Server gleichzeitig überlasten.

• Verwenden Sie den Memorystore for Redis Cluster-Erkennungsendpunkt, um eine Clustererkennung durchzuführen. Der Discovery-Endpunkt ist hochverfügbar und wird über alle Knoten im Cluster hinweg per Load Balancing verteilt. Außerdem versucht der Discovery-Endpunkt, die Cluster-Discovery-Anfragen an Knoten mit der aktuellsten Topologieansicht weiterzuleiten.

Nicht reagierende Verbindungen erkennen und verarbeiten

Wir empfehlen dringend, Ihre Clientanwendung so zu konfigurieren, dass nicht reagierende Verbindungen zu Memorystore for Redis Cluster erkannt werden. Wenn eine nicht reagierende Verbindung erkannt wird, muss der Client sie zurücksetzen. Zum Erstellen einer ausfallsicheren Anwendung empfehlen wir die folgenden Clientkonfigurationen:

• TCP-Keep-Alive-Parameter konfigurieren: Legen Sie die Parameter TCP keepalive time, TCP keepalive interval und TCP keepalive probes so fest, dass Clients nicht reagierende Verbindungen proaktiv erkennen und trennen, auch wenn die Verbindungen inaktiv sind. Wenn Sie beispielsweise den Parameter TCP keepalive time auf 30 Sekunden, TCP keepalive interval auf 10 Sekunden und TCP keepalive probes auf 3 festlegen, setzen Clients nicht reagierende inaktive Verbindungen innerhalb einer Minute zurück.
• TCP-Nutzerzeitlimits konfigurieren: Legen Sie dieses Zeitlimit in Ihren Clients fest, um Verbindungen mit ausstehenden Anfragen zurückzusetzen, die nicht mehr reagieren. Wenn Sie das Zeitlimit beispielsweise auf 15 Sekunden festlegen, setzen Clients nicht reagierende Verbindungen mit ausstehenden Anfragen nach 15 Sekunden zurück.

Best Practices für die Persistenz

In diesem Abschnitt werden Best Practices für die Persistenz erläutert.

RDB-Persistenz und Hinzufügen von Replikaten

Die folgenden Best Practices helfen Ihnen, die besten Ergebnisse beim Sichern Ihres Clusters mit RDB-Snapshots oder beim Hinzufügen von Replikaten zu Ihrem Cluster zu erzielen:

Speicherverwaltung

RDB-Snapshots verwenden einen Prozess-Fork und einen Copy-on-Write-Mechanismus, um einen Snapshot von Knotendaten zu erstellen. Je nach Muster der Schreibvorgänge auf Knoten wächst der belegte Speicher der Knoten, da die von den Schreibvorgängen betroffenen Seiten kopiert werden. Der Speicherbedarf kann bis zu doppelt so groß sein wie die Daten im Knoten.

Damit die Knoten genügend Arbeitsspeicher haben, um den Snapshot abzuschließen, behalten Sie maxmemory bei 80% der Knotenkapazität bei oder legen Sie diesen Wert fest, sodass 20% für den Overhead reserviert sind. Dieser Arbeitsspeicher-Overhead hilft Ihnen zusätzlich zum Monitoring von Snapshots, Ihre Arbeitslast so zu verwalten, dass Snapshots erfolgreich erstellt werden. Außerdem sollten Sie beim Hinzufügen von Replikaten den Schreibtraffic so weit wie möglich reduzieren. Weitere Informationen finden Sie unter Cluster mit hoher Schreiblast überwachen.

Hinweis: Wenn Sie einem Cluster, der mehr als 80% des maximalen Speichers des Clusters verwendet, ein Replikat hinzufügen, schlägt der Vorgang fehl und Sie erhalten eine Fehlermeldung.

Um dieses Problem zu beheben, reduzieren Sie die Arbeitsspeichernutzung Ihres Clusters auf eine der folgenden Arten:

• Reduzieren Sie den Speicherbedarf Ihres Clusters auf weniger als 80% des maximal zulässigen Arbeitsspeichers des Knotens.
• Skalieren Sie den Knotentyp für Ihren Cluster, damit er mehr Arbeitsspeicher hat.

Wenn die Arbeitsspeichernutzung Ihres Clusters unter dem Schwellenwert von 80% liegt, fügen Sie das Replikat wieder hinzu.

Veraltete Snapshots

Das Wiederherstellen von Knoten aus einem veralteten Snapshot kann zu Leistungsproblemen für Ihre Anwendung führen, da sie versucht, eine erhebliche Menge veralteter Schlüssel oder andere Änderungen an Ihrer Datenbank, z. B. eine Schemaänderung, abzugleichen. Wenn Sie Bedenken hinsichtlich der Wiederherstellung aus einem veralteten Snapshot haben, können Sie die RDB-Persistenzfunktion deaktivieren. Sobald Sie die Persistenz wieder aktivieren, wird im nächsten geplanten Snapshot-Intervall ein Snapshot erstellt.

Auswirkungen von RDB-Snapshots auf die Leistung

Je nach Arbeitslastmuster können RDB-Snapshots die Leistung des Clusters beeinträchtigen und die Latenz für Ihre Anwendungen erhöhen. Sie können die Auswirkungen von RDB-Snapshots auf die Leistung minimieren, indem Sie sie so planen, dass sie in Zeiten mit geringem Clustertraffic ausgeführt werden, wenn Sie mit weniger häufigen Snapshots einverstanden sind.

Wenn Ihr Cluster beispielsweise von 1:00 Uhr bis 4:00 Uhr wenig Traffic hat, können Sie die Startzeit auf 3:00 Uhr und das Intervall auf 24 Stunden festlegen.

Wenn Ihr System eine konstante Last hat und häufige Snapshots erfordert, sollten Sie die Auswirkungen auf die Leistung sorgfältig prüfen und die Vorteile der Verwendung von RDB-Snapshots für die Arbeitslast abwägen.

Replikat hinzufügen

Zum Hinzufügen eines Replikats ist ein RDB-Snapshot erforderlich. Weitere Informationen zu RDB-Snapshots finden Sie unter Speicherverwaltung.

Wann sollte ein Einzelzonencluster verwendet werden?

Wenn Sie einen Cluster so konfigurieren, dass er keine Replikate verwendet, empfehlen wir, einen Cluster mit einer einzelnen Zone zu verwenden. Das kann folgende Gründe haben:

Kosten und Leistung

Wenn Sie die Kosten minimieren und die Leistung für Ihre Clients in derselben Region maximieren möchten, empfehlen wir Ihnen, einen Cluster mit einer einzelnen Zone auszuwählen.

Auswirkungen von Ausfällen minimieren

Wenn Sie einen einzonalen Cluster auswählen, ist es weniger wahrscheinlich, dass sich zonale Ausfälle auf Ihren Cluster auswirken. Wenn Sie alle Knoten in einer einzelnen Zone platzieren, sinkt die Wahrscheinlichkeit, dass ein zonaler Ausfall Ihren Server betrifft, von 100% auf 33%. Die Wahrscheinlichkeit, dass die Zone, in der sich Ihr Cluster befindet, ausfällt, beträgt 33 %. Die Wahrscheinlichkeit, dass Knoten, die sich in der nicht verfügbaren Zone befinden, betroffen sind, beträgt dagegen 100 %.

Schnelle Erholung

Wenn ein zonaler Ausfall für einen Cluster mit einer einzelnen Zone auftritt, optimiert Memorystore for Redis Cluster die Wiederherstellung Ihrer Daten. Sie können schnell einen neuen Cluster in einer funktionierenden Zone bereitstellen und Ihre Anwendung umleiten, um den Betrieb mit minimalen Unterbrechungen fortzusetzen.

Best Practices für die Kapazitätsplanung

Damit Sie Ressourcen erfolgreich bereitstellen und robuste Architekturen erstellen können, empfehlen wir die folgenden Best Practices für die Kapazitätsplanung:

• An mehreren Standorten bereitstellen: Wenn Sie aufgrund vorübergehender Ressourceneinschränkungen keinen Cluster in Ihrer bevorzugten Zone erstellen können, versuchen Sie, den Cluster entweder in einer anderen Zone innerhalb derselben Region oder in einer anderen Region zu erstellen.
• Regionsübergreifenden Zugriff verwenden: Konfigurieren Sie Ihre Clients so, dass sie auf Ihre Cluster in verschiedenen Regionen zugreifen können. Wenn Sie aufgrund lokaler Ressourceneinschränkungen einen Cluster in einer anderen Region bereitstellen müssen, können Ihre Clients eine Verbindung zum Cluster herstellen.
• Regionenübergreifende Replikation verwenden: Wenn Sie einen sekundären Cluster in einer anderen Region zu einem primären Lese- oder Schreibcluster für die Notfallwiederherstellung hochstufen möchten, führen Sie einen Wechsel aus.

Best Practices für Lettuce

In diesem Abschnitt werden Best Practices für die Verwendung von Lettuce zum Herstellen einer Verbindung zu einem Cluster beschrieben.

Parameterwerte aktualisieren

Wenn Sie Lettuce verwenden, ändern Sie den Parameter validateClusterNodeMembership in false. Andernfalls können bei einer Änderung der Topologie unknownPartition-Fehler auftreten.

Transport Layer Security (TLS) aktivieren

In diesem Abschnitt werden die Sicherheitsvorteile und Leistungsauswirkungen der Verwendung von Transport Layer Security (TLS) erläutert und Empfehlungen für die Aktivierung gegeben.

Sicherheitsvorteile

Die Verwendung von TLS bietet die folgenden Sicherheitsvorteile:

• IAM-Authentifizierung (Identity and Access Management): TLS verwendet diese Art der Authentifizierung, um vor Server-Spoofing-Angriffen wie Person-in-the-Middle-Angriffen zu schützen.
• Verschlüsselung während der Übertragung: Die integrierte Verschlüsselung vonGoogle Cloudschützt den Traffic im Google-Netzwerk auf Infrastrukturebene. Dazu müssen Sie jedoch sowohl dem Host- als auch dem Netzwerkstack von Google vertrauen. Diese Verschlüsselung ist zwar transparent und standardmäßig aktiviert, aber nicht Ende-zu-Ende. TLS hingegen verwendet die Verschlüsselung während der Übertragung auf der Anwendungsebene. Diese Ende-zu-Ende-Verschlüsselung bietet Ihnen mehr Kontrolle über Ihre Verschlüsselungsschlüssel und -prozesse.
• Schutz von Authentifizierungstokens: Wenn Sie die IAM-Authentifizierung verwenden, wird durch die Aktivierung von TLS das Risiko minimiert, dass Ihre Authentifizierungstokens offengelegt werden und verloren gehen.

Auswirkungen auf die Leistung

TLS wirkt sich folgendermaßen auf die Leistung aus:

• Verbindungen herstellen: Ein Client und ein Server, die eine TLS-Sitzung eingerichtet haben, können die Sitzung fortsetzen, ohne den ressourcenintensiven Prozess zum Herstellen der Verbindung zwischen Client und Server zu wiederholen. Durch die Aktivierung der TLS-Wiederaufnahme reduzieren Sie den Aufwand für den Aufbau einer Verbindung zwischen dem Client und dem Server.

  Wenn Sie die TLS-Wiederaufnahme nicht einrichten, ist das Herstellen von Verbindungen ressourcenintensiv. Sowohl bei neuen als auch bei bestehenden Verbindungen können viele Verbindungen zwischen dem Client und dem Server zu Zeitüberschreitungen führen. Dies kann einen Schneeballeffekt verursachen, da Memorystore for Redis Cluster versucht, Verbindungen mit Zeitüberschreitung wiederherzustellen, was die Ressourcen erhöht, die für die Herstellung von Verbindungen verwendet werden.

• Daten verschlüsseln und entschlüsseln: Die Verschlüsselung und Entschlüsselung von Daten umfasst CPU-intensive Vorgänge, die sich sowohl auf den Client als auch auf den Server auswirken. Dies kann die Kapazität Ihres Clusters verringern und die Latenz des Clusters erhöhen.

Empfehlungen

Wenn Sie überlegen, ob Sie TLS aktivieren möchten, empfehlen wir Ihnen, Ihre Sicherheitsrichtlinien zu prüfen und die Vor- und Nachteile von TLS zu berücksichtigen. Wenn Sie TLS aktivieren, beachten Sie Folgendes:

• Durch die Aktivierung der TLS-Wiederaufnahme wird der Aufwand für den Verbindungsaufbau verringert. Eine Verbindung zwischen dem Client und dem Server ist nur für die erste Verbindung erforderlich. Eine plötzliche Erweiterung der Clustergröße des Clients kann jedoch zu einer kurzen Unterbrechung führen, die durch den ersten vollständigen Handshake jedes neuen Clienthosts verursacht wird.
• Einige Clientbibliotheken bieten möglicherweise keine integrierten Steuerelemente zum Aktivieren von TLS. Sie können jedoch benutzerdefinierten Code verwenden, um diese Funktion in Ihre Cluster einzubinden.