Oracle Cloud Infrastructure-Dokumentation

In OCI-Cache in Shards unterteilte Cluster

OCI Cache unterstützt zwei Clustermodi, in Shards unterteilte Cluster und nicht in Shards unterteilte Cluster.

Nicht in Shards unterteilte Cluster werden mit einem primären Knoten und mindestens einem Replikatknoten konfiguriert, wobei die Daten auf jedem Knoten dupliziert werden. Bei diesem Clustermodus sind die Daten, die Sie speichern können, durch die für den Knoten konfigurierte Speichermenge mit maximal 500 GB Arbeitsspeicher pro Knoten begrenzt.

In Shards unterteilte Cluster haben drei oder mehr Shards, wobei die Daten über die Shards im Cluster aufgeteilt werden, sodass jedes Shard einen Teil der Daten enthält. Jeder Shard ist wie ein Cluster mit einem primären Knoten und bis zu vier Replikatknoten. In Shards unterteilte Cluster unterstützen Szenarios, in denen Sie mehr Daten speichern müssen als das Limit von 500 GB, da diese Cluster zwar immer noch auf den Arbeitsspeicher von 500 GB pro Knoten begrenzt sind, aber wirklich 500 GB pro Shard betragen.

In Shards unterteilte Cluster haben keine primären oder replizierten Endpunkte auf Clusterebene, wie es nicht in Shards unterteilte Cluster tun. Stattdessen verfügt jedes Shard über einen privaten Endpunkt, mit dem Sie eine Verbindung zum Cluster herstellen können. Weitere Informationen finden Sie unter Verbindungsdetails eines in OCI-Cache geteilten Clusters abrufen.

Einschränkungen und Überlegungen für in Shards unterteilte Cluster

Alle Valkey- und Redis-Clientbibliotheken, mit denen Sie eine Verbindung zu einem in Shards unterteilten Cluster herstellen, müssen Redis CLUSTER MODE mit Hostnamensunterstützung unterstützen.

  • Die Anzahl der pro Shard konfigurierten Knoten muss zwischen 1 und 5 liegen, wobei maximal 100 Knoten pro Cluster zulässig sind.
  • Die Anzahl der Shards pro Cluster muss eine ungleichmäßige Anzahl von 3 bis 99 sein, obwohl die maximale Anzahl der Shards von der Anzahl der pro Shard konfigurierten Knoten abhängt.
  • Die Arbeitsspeichermenge pro Knoten muss zwischen 2 und 500 GB liegen.
  • Alle Redis-Clientbibliotheken, mit denen Sie eine Verbindung zu einem in Shards unterteilten Cluster herstellen, müssen Redis CLUSTER MODE mit Hostnamenunterstützung unterstützen.
  • OCI-Cachecluster, die als nicht in Shards unterteilte Cluster erstellt wurden, können nicht in in in Shards unterteilte Cluster konvertiert werden und umgekehrt. OCI Cache bietet keine automatisierte Möglichkeit, Daten zwischen diesen Clustertypen zu verschieben.

In Shards unterteilte Cluster konfigurieren

Bei der Konfiguration eines in Shards unterteilten Clusters müssen Sie die Anforderungen berücksichtigen, die Sie bei der Entscheidung über das Gleichgewicht zwischen der Anzahl der Shards, der Anzahl der Knoten pro Shard und der Arbeitsspeichermenge pro Knoten unterstützen. Die Erhöhung der Anzahl der Knoten pro Shard ist eine gute Strategie, um die Lesekapazität eines Clusters zu erhöhen. Dies hilft jedoch nicht beim Speicher eines Clusters, es sei denn, Sie erhöhen den Arbeitsspeicher pro Knoten. Es hilft auch nicht bei der Schreibkapazität eines Clusters. Um die Schreibkapazität eines Clusters zu beeinträchtigen, erhöhen Sie die Anzahl der Shards.

Beispiel: Vergleichen Sie die beiden folgenden Szenarios:

  1. Das Cluster muss eine große Datenmenge speichern, aber keine großen Schreibvorgänge verarbeiten.
  2. Das Cluster muss viele Schreibvorgänge verarbeiten, aber keine große Datenmenge speichern.

In Szenario 1 würden Sie das Cluster so konfigurieren, dass es weniger Shards mit mehr Speicher pro Knoten als in Szenario 2 enthält. Bei Szenario 2 würden Sie das Cluster so konfigurieren, dass es eine größere Anzahl von Shards mit weniger Arbeitsspeicher pro Knoten aufweist.

Discovery-Endpunkt

Die Discovery-Endpunktfunktion wurde für in OCI Cache Shards unterteilte Cluster entwickelt und bietet einen stabilen, einzigen Endpunkt für Clientanwendungen, um eine Verbindung zum in Shards unterteilten Cachecluster herzustellen. Dieser Endpunkt abstrahiert die Komplexität der Verwaltung mehrerer Shard-Knoten, sodass Clientanwendungen mit dem OCI-Cache interagieren können, ohne die zugrunde liegende Shard-Topologie kennen zu müssen.

Jede Clusterinstanz verfügt über einen eindeutigen Discovery-Endpunkt, der aus einer Kombination aus einer IP-Adresse und einer Portnummer besteht. Der Discovery-Endpunkt dient als primärer Einstiegspunkt für Clientverbindungen und ist entscheidend für die nahtlose Knotenerkennung und Verwaltung der Clustertopologie.

Informationen zum Discovery-Endpunkt Ihres Clusters finden Sie unter Details eines OCI-Cacheclusters abrufen.
Hinweis

OCI Cache stellt den Discovery-Endpunkt nur für neu erstellte in Shards unterteilte Cluster bereit. Vorhandene in Shards unterteilte Cluster werden nicht automatisch mit einem Discovery-Endpunkt aktualisiert.

Discovery-Endpunkt verwenden

Um Ihren Redis- oder Valkey-Client (wie Salat oder Redisson) zu verbinden, konfigurieren Sie ihn so, dass er den vollqualifizierten Domainnamen (FQDN) des Discovery-Endpunkts verwendet. Dieser Endpunkt wird in eine private IP-Adresse in Ihrem virtuellen Cloud-Netzwerk (VCN) aufgelöst und leitet Anforderungen an einen Clusterknoten weiter.

Nach der Verbindung kann der Client die Clustertopologie abrufen, indem er Standardredis-Befehle wie #CLUSTER SLOTS oder #CLUSTER NODES ausführt. Diese Befehle geben Informationen zurück, einschließlich Knoten-IDs, Rollen, FQDNs oder IP-Adressen und Slot-Bereiche.

Danach kann der Client Folgendes ausführen:

  • Stellen Sie direkte Verbindungen zu den relevanten Knoten mit ihren FQDNs oder IP-Adressen her.
  • Führen Sie Redis- oder Valkey-Befehle aus (Beispiel: GET, SET).
  • Behalten Sie das aktuelle Routing bei, indem Sie die Topologie regelmäßig über den Discovery-Endpunkt aktualisieren.

Die meisten Verfahren für die Arbeit mit in Shards unterteilten Clustern sind die gleichen wie für die Arbeit mit nicht in Shards unterteilten Clustern, jedoch sind einige Verfahren unterschiedlich. Details zu Shard-Clustern finden Sie im Folgenden: