Auf dieser Seite werden die Cluster- und Knotenspezifikationen für Memorystore for Redis Cluster-Instanzen beschrieben. Eine Anleitung zum Erstellen einer Instanz finden Sie unter Instanzen erstellen.
Knotentyp auswählen
Alle Shards in Ihrem Cluster verwenden denselben Knotentyp, den Sie auswählen. Der beste Knotentyp für Ihren Cluster hängt von Ihren Anforderungen an Preis, Leistung und Keyspace-Kapazität ab.
Der Knotentyp redis-shared-core-nano ist für kleine Arbeitslasten vorgesehen. Dieser Knotentyp bietet eine variable Leistung und hat kein SLA, sodass er für Produktionsarbeitslasten nicht geeignet ist.
Mit dem Knotentyp redis-standard-small können Sie kleine Cluster bereitstellen und Ihren Cluster in kleineren Schritten erweitern. Das ist möglicherweise kostengünstiger als bei anderen Knotentypen. redis-standard-small bietet auch den Vorteil, dass Ihr Keyspace auf mehr Knoten mit einer höheren Gesamtzahl an vCPUs verteilt wird. Dies bietet ein besseres Preis-Leistungs-Verhältnis als redis-highmem-medium, sofern die Gesamtkapazität des Keyspace der kleineren Knoten für Ihre Datenanforderungen ausreicht.
Wenn Sie Arbeitslasten haben, die im Verhältnis zum Arbeitsspeicher eine höhere Rechenleistung erfordern, wählen Sie den Knotentyp redis-highcpu-medium aus. Wenn Sie mehr Kapazität benötigen, als redis-highmem-medium bietet, empfehlen wir die Knotentypen redis-standard-large, redis-highmem-xlarge oder redis-highmem-2xlarge. Wenn Sie immer größeren Knoten vCPUs hinzufügen (Hochskalierung), wird die Redis-Leistung möglicherweise nicht linear skaliert. Stattdessen empfehlen wir, die Skalierung zu erhöhen, indem Sie einem Cluster mehr Knoten hinzufügen, um ein besseres Preis-Leistungs-Verhältnis zu erzielen.
Spezifikation des Knotentyps
Die Knotenkapazität und ‑merkmale hängen vom ausgewählten Knotentyp ab:
Keyspace-Kapazität und reservierter Overhead
| Knotentyp | Standardmäßige Kapazität des beschreibbaren Keyspace | Gesamtknotenkapazität |
|---|---|---|
| redis-shared-core-nano | 1,12 GB | 1,4 GB |
| redis-standard-small | 5,2 GB | 6,5 GB |
| redis-highmem-medium | 10,4 GB | 13 GB |
| redis-highcpu-medium | 10,4 GB | 13 GB |
| redis-standard-large | 20,8 GB | 26 GB |
| redis-highmem-xlarge | 46,4 GB | 58 GB |
| redis-highmem-2xlarge | 88 GB | 110 GB |
Memorystore reserviert automatisch einen Teil der Instanzkapazität, um OOM-Fehler (Out Of Memory, fehlender Speicher) zu vermeiden. So wird ein reibungsloses Lesen und Schreiben von Schlüsseln gewährleistet. Die Arbeitsspeicherlimits und Speicherdetails sind wie folgt:
Speicher anpassen:Wir empfehlen zwar, die Standardeinstellungen zu verwenden, Sie haben aber die Möglichkeit, die Menge des reservierten Speichers mit der
maxmemory-Konfiguration anzupassen. Informationen zumaxmemoryfinden Sie unter Unterstützte Instanzkonfigurationen.Wie viel Speicherplatz erhalte ich? Sehen Sie sich die Spalte Standardkapazität für beschreibbaren Keyspace in der vorherigen Tabelle an. Hier sehen Sie, wie viel Speicherplatz standardmäßig für Ihre Schlüssel verfügbar ist.
Speicher maximieren: Wenn Sie den maximal möglichen Speicherplatz nutzen möchten, sehen Sie in der Spalte Gesamtknotenkapazität das Speicherlimit, wenn Sie die
maxmemory-Konfiguration auf 100 % festlegen. Wir empfehlen jedoch nicht, einenmaxmemory-Wert zu wählen, der höher als die Standardeinstellung ist.Der Knotentyp
redis-shared-core-nanohat ein festes Limit von 1, 12 GB und kann nicht mit dermaxmemory-Konfiguration geändert werden.
Knotenmerkmale
| Knotentyp | vCPU Anzahl | Angebotenes SLA | Standardanzahl von Clientverbindungen | Maximale Anzahl von Clientverbindungen | Maximaler Arbeitsspeicher für Clients ( Konfiguration „maxmemory-clients“) |
|---|---|---|---|---|---|
| redis-shared-core-nano | 0,5 | Nein | 5.000 | 5.000 | 12 % |
| redis-standard-small | 2 | Ja | 16.000 | 32.000 | 7 % |
| redis-highmem-medium | 2 | Ja | 32.000 | 64.000 | 7 % |
| redis-highcpu-medium | 8 | Ja | 32.000 | 64.000 | 7 % |
| redis-standard-large | 8 | Ja | 32.000 | 64.000 | 7 % |
| redis-highmem-xlarge | 8 | Ja | 64.000 | 64.000 | 4 % |
| redis-highmem-2xlarge | 16 | Ja | 64.000 | 64.000 | 4 % |
Je mehr virtuelle CPUs (vCPUs) Sie für Ihren Cluster auswählen, desto besser ist die Leistung. Wenn in Ihrem Cluster ressourcenintensive Arbeitslasten ausgeführt werden, wählen Sie einen Knotentyp mit einer höheren vCPU aus (z. B. redis-highmem-xlarge). Wenn in Ihrem Cluster weniger anspruchsvolle Aufgaben ausgeführt werden, wählen Sie einen Knotentyp mit einer niedrigeren vCPU aus (z. B. redis-highmem-medium).
Instanz skalieren
Beim Erstellen einer Memorystore for Redis Cluster-Instanz wählen Sie einen Knotentyp für die Instanz aus und geben die Anzahl der Shards für die Instanz an. Nachdem Sie die Instanz erstellt haben und sich die Kapazitätsanforderungen für Ihre Instanz ändern, müssen Sie die Instanz möglicherweise auf folgende Weise skalieren:
- Ändern Sie die Anzahl der Shards für die Instanz. Das ist horizontale Skalierung.
Sie können eine Instanz horizontal skalieren, indem Sie eine der folgenden Aktionen ausführen:
- Fügen Sie der Instanz Shards hinzu. Dadurch wird die Instanz herunterskaliert.
- Entfernen Sie Shards aus der Instanz. Die Instanz wird herunterskaliert.
- Ändern Sie den Knotentyp für Ihre Instanz. Das ist die vertikale Skalierung. Wenn Sie eine Instanz vertikal skalieren möchten, ändern Sie den Knotentyp der Instanz in einen der folgenden Knotentypen:
- Wechseln Sie zu einem größeren Knotentyp. Die Instanz wird hochskaliert.
- Wechseln Sie zu einem kleineren Knotentyp. Die Instanz wird herunterskaliert.
Clusterspezifikation
In diesem Abschnitt sehen Sie die Mindest- und Höchstkapazitäten für Cluster in Abhängigkeit von der Clusterform, dem Knotentyp und der Anzahl der Replikate.
Minimale beschreibbare Kapazität
Die beschreibbare Kapazität ist die Menge an Speicherplatz, die zum Schreiben von Schlüsseln verfügbar ist. Sie entspricht der Größe eines Instanzknotens. Je nach Knotentyp liegt die minimale beschreibbare Kapazität daher zwischen 1,4 GB und 110 GB. Die Mindestkapazität für Schreibvorgänge wird durch die Anzahl der von Ihnen ausgewählten Replikate nicht beeinflusst.
Maximale beschreibbare Kapazität
| Knotentyp und ‑größe | Maximale Kapazität bei einer Clusterform mit 250 primären Knoten und 0 Replikaten pro Knoten | Maximale Kapazität bei einer Clusterform von 125 primären Knoten und 1 Replikat pro Knoten | Maximale Kapazität bei einer Clusterform mit 83 primären Knoten und 2 Replikaten pro Knoten | Maximale Kapazität bei einer Clusterform mit 62 primären Knoten und 3 Replikaten pro Knoten | Maximale Kapazität bei einer Clusterform mit 50 primären Knoten und 4 Replikaten pro Knoten | Maximale Kapazität bei einer Clusterform mit 41 primären Knoten und 5 Replikaten pro Knoten |
|---|---|---|---|---|---|---|
| redis-mit gemeinsam genutztem Kern-nano – 1,4 GB | 350 GB | 175 GB | 116,2 GB | 86,8 GB | 70 GB | 57,4 GB |
| redis-standard-small – 6,5 GB | 1.625 GB | 812,5 GB | 539,5 GB | 403 GB | 325 GB | 266,5 GB |
| redis-highmem-medium – 13 GB | 3.250 GB | 1.625 GB | 1.079 GB | 806 GB | 650 GB | 533 GB |
| redis-highcpu-medium – 13 GB | 3.250 GB | 1.625 GB | 1.079 GB | 806 GB | 650 GB | 533 GB |
| redis-standard-large – 26 GB | 6.500 GB | 3.250 GB | 2.158 GB | 1.612 GB | 1.300 GB | 1.066 GB |
| redis-highmem-xlarge – 58 GB | 14.500 GB | 7.250 GB | 4.814 GB | 3.596 GB | 2.900 GB | 2.378 GB |
| redis-highmem-2xlarge – 110 GB | 27.500 GB | 13.750 GB | 9.130 GB | 6.820 GB | 5.500 GB | 4.510 GB |
Leistung
Mit dem OSS-Benchmarking-Tool „memtier“ in der Region us-central1 wurden 120.000 bis 130.000 Vorgänge pro Sekunde pro Knoten mit 2 vCPUs (redis-standard-small und redis-highmem-medium) mit Mikrosekundenlatenz und einer Datengröße von 1 KiB erzielt.
Wir empfehlen, eigene Benchmarks mit echten oder synthetischen Arbeitslasten durchzuführen, die Ihrem Produktions-Traffic ähneln. Außerdem empfehlen wir, Ihre Cluster mit einem Puffer (oder „Headroom“) für Arbeitslastspitzen oder unerwarteten Traffic zu dimensionieren. Weitere Informationen finden Sie unter Best Practices für Memorystore for Redis Cluster.
Cluster-Endpunkte
In diesem Abschnitt werden die beiden Endpunkte beschrieben, die jede Instanz hat.
Endpunkt der Erkennung
Jede Instanz hat einen Erkennungs-Endpunkt, mit dem sich Ihr Client verbindet. Sie besteht aus einer IP-Adresse und einer Portnummer. Eine Anleitung dazu, wie Sie den Discovery-Endpunkt Ihres Clusters finden, finden Sie unter Discovery-Endpunkt Ihres Clusters ansehen.
Ihr Client verwendet sie auch für die Knotenerkennung. Ihr Client verwendet den Discovery-Endpunkt, um die Clustertopologie Ihrer Instanz abzurufen, um OSS-Redis-Clusterclients zu starten und sie im stabilen Zustand auf dem neuesten Stand zu halten. Die resultierende Clustertopologie stellt Redis-Knotenendpunkte (IP- und Portkombinationen) bereit, die vom Redis-Clusterclient im Arbeitsspeicher zwischengespeichert werden können. Ihr Kunde kümmert sich dann automatisch um die Updates und Weiterleitungen. Es sind keine weiteren Änderungen an der Anwendung erforderlich. Informationen zum Client-Erkennungsverhalten und zu Best Practices finden Sie unter Client-Erkennung.
Der Discovery-Endpunkt ist hochverfügbar, da er von mehreren Redis-Knoten in mehreren Zonen unterstützt wird, um die Clustertopologie bereitzustellen. Die Bereitstellung der Topologie über den Endpunkt ist auch bei Ausfällen von Backend-Knoten oder Knotenaktualisierungen stabil.
Ihr Discovery-Endpunkt hat das folgende Verhalten:
Der Discovery-Endpunkt Ihres Clusters bleibt während des gesamten Lebenszyklus der Clusterinstanz unverändert, auch während der Wartung oder bei anderen Aktionen, die Sie ausführen, z. B. beim Skalieren oder Ändern der Anzahl der Replikate.
Redis-Knotenendpunkte können sich ändern und wiederverwendet werden, wenn im Laufe der Zeit Knoten hinzugefügt und entfernt werden. Im Idealfall sollten Sie einen Redis-Clusterclient verwenden, der diese Änderungen automatisch durch Topologieaktualisierungen und Weiterleitungen verarbeiten kann. Beispiele für Redis Cluster-Clients finden Sie unter Codebeispiele für Clientbibliotheken. Ihre Anwendung sollte keine Abhängigkeiten oder Annahmen haben, dass Knotenendpunkte für einen bestimmten Cluster unverändert bleiben.
Datenendpunkt
Zusätzlich zum Discovery-Endpunkt hat jeder Cluster einen Datenendpunkt. Dieser Endpunkt ist für Memorystore for Redis Cluster reserviert, um Ihren Client mit Knoten im Cluster zu verbinden. Stellen Sie daher keine direkte Verbindung zu diesem Endpunkt her.