Skalieren einer Azure Cache for Redis-Instanz

  • Artikel

Für Azure Cache for Redis stehen verschiedene Dienstebenenangebote bereit, die Flexibilität bei der Auswahl von Cachegröße und Cachefunktionen bieten. Durch Skalierung können Sie Größe, Ebene und Anzahl der Knoten ändern, nachdem Sie eine Cache-Instanz erstellt haben, um die Anforderungen Ihrer Anwendung zu erfüllen. Dieser Artikel zeigt Ihnen, wie Sie Ihren Cache mithilfe des Azure-Portals und mit Tools wie Azure PowerShell und der Azure-Befehlszeilenschnittstelle skalieren.

Skalierungstypen

Es gibt grundsätzlich zwei Möglichkeiten, eine Azure Cache for Redis-Instanz zu skalieren:

  • Das Hochskalieren erhöht die Größe des virtuellen Computers (der VM), auf dem der Redis-Server ausgeführt wird, und fügt mehr Arbeitsspeicher, virtuelle CPUs (vCPUs) und Netzwerkbandbreite hinzu. Das Hochskalieren wird auch als vertikale Skalierung bezeichnet. Das Gegenteil von Hochskalieren ist das Herunterskalieren.

  • Das Aufskalieren teilt die Cache-Instanz in mehr Knoten gleicher Größe auf, wodurch der Arbeitsspeicher, die vCPUs und die Netzwerkbandbreite durch Parallelisierung erhöht werden. Das Aufskalieren wird auch als horizontale Skalierung oder Sharding bezeichnet. Das Gegenteil von Aufskalieren ist das Abskalieren. In der Redis-Community wird das Aufskalieren häufig als Clustering bezeichnet.

Umfang der Verfügbarkeit

Tarif Basic und Standard. Premium Enterprise und Enterprise Flash
Hochskalieren Yes Ja Ja (Vorschau)
Herunterskalieren Yes Ja Nein
Aufskalieren Nein Ja Ja (Vorschau)
Abskalieren Nein Ja Nein

Zeitpunkt für die Skalierung

Sie können mithilfe der Überwachungsfunktionen von Azure Cache for Redis die Integrität und Leistung Ihres Caches überwachen. Verwenden Sie diese Informationen, um zu bestimmen, wann der Cache skaliert werden soll.

Sie können die folgenden Metriken überwachen, um zu bestimmen, ob eine Skalierung notwendig ist.

  • Redis-Serverlast
    • Eine hohe Redis-Serverauslastung bedeutet, dass der Server nicht mit den Anforderungen aller Clients Schritt halten kann. Da ein Redis-Server ein Einzelthreadprozess ist, ist es in der Regel hilfreicher aufzuskalieren statt hochzuskalieren. Das Aufskalieren durch Aktivieren von Clustering hilft beim Verteilen von Overheadfunktionen auf mehrere Redis-Prozesse. Das Aufskalieren hilft auch bei der Verteilung der TLS-Verschlüsselung/Entschlüsselung und der Verbindung/Trennung, wodurch Cache-Instanzen mithilfe von TLS beschleunigt werden.
    • Das Hochskalieren kann weiterhin hilfreich sein, um die Serverlast zu reduzieren, da Hintergrundaufgaben die Vorteile von mehr vCPUs nutzen und den Thread für den Redis-Hauptserverprozess freigeben können.
    • Die Enterprise- und Enterprise Flash-Ebenen verwenden Redis Enterprise anstelle von Open Source Redis. Einer der Vorteile dieser Ebenen besteht darin, dass der Redis-Serverprozess mehrere vCPUs nutzen kann. Daher kann das Hochskalieren und das Aufskalieren auf diesen Ebenen hilfreich sein, um die Serverlast zu reduzieren. Weitere Informationen finden Sie unter Bewährte Methoden für die Enterprise- und Enterprise Flash-Ebenen von Azure Cache for Redis.
  • Speicherauslastung
    • Eine hohe Speicherauslastung zeigt an, dass Ihre Datengröße für die aktuelle Cachegröße zu groß ist. Erwägen Sie die Skalierung auf eine Cachegröße mit größerem Arbeitsspeicher. Hier ist entweder hochskalieren oder aufskalieren wirksam.
  • Clientverbindungen
    • Für jede Cachegröße ist die Anzahl der Clientverbindungen, die unterstützt werden können, begrenzt. Wenn Ihre Clientverbindungen dem Grenzwert für die Cachegröße nahe kommen, sollten Sie ein Hochskalieren auf eine höhere Ebene erwägen. Das Aufskalieren erhöht die Anzahl der unterstützten Clientverbindungen nicht erhöht.
    • Weitere Informationen zu Verbindungsgrenzwerten in Abhängigkeit von der Cachegröße finden Sie in den Preisen für Azure Cache for Redis.
  • Netzwerkbandbreite
    • Wenn der Redis-Server die verfügbare Bandbreite überschreitet, kann bei Clientanforderungen ein Timeout auftreten, weil der Server Daten nicht schnell genug an den Client pushen kann. Aktivieren Sie die Metriken „Cache Read“ (Cachelesevorgänge) und „Cache Write“ (Cacheschreibvorgänge) können, um festzustellen, wie viel Bandbreite auf der Serverseite verwendet wird. Wenn Ihr Redis-Server die verfügbare Netzwerkbandbreite überschreitet, sollten Sie ein Hochskalieren oder Aufskalieren auf eine größere Cachegröße mit höherer Netzwerkbandbreite in Betracht ziehen.
    • Bei Caches der Enterprise-Ebene, welche die Enterprise-Clusterrichtlinie verwenden, erhöht das Aufskalieren die Netzwerkbandbreite nicht.
    • Weitere Informationen zur verfügbaren Netzwerkbandbreite in Abhängigkeit von der Cachegröße finden Sie unter Häufig gestellte Fragen zur Planung von Azure Cache for Redis.

Weitere Informationen, wie Sie ermitteln, welcher Cachetarif geeignet ist, finden Sie unter Auswählen der richtigen Ebene und Häufig gestellte Fragen zur Planung von Azure Cache for Redis.

Hinweis

Weitere Informationen zum Optimieren des Skalierungsprozesses finden Sie im Leitfaden zu bewährten Methoden für die Skalierung

Voraussetzungen/Einschränkungen der Skalierung von Azure Cache for Redis

Sie können mit den folgenden Einschränkungen zu einem anderen Tarif Hochskalieren/Herunterskalieren:

  • Sie können keine Skalierung von einem höheren Tarif auf einen niedrigeren Tarif vornehmen.
    • Sie können von einem Enterprise- oder Enterprise Flash-Cache nicht auf eine andere Ebene herunterskalieren.
    • Eine Skalierung von einem Premium-Cache auf einen niedrigeren Standard- oder Basic-Cache ist nicht möglich.
    • Ein Standard-Cache kann nicht auf einen niedrigeren Basic-Cache skaliert werden.
  • Ein Basic-Cache kann auf einen Standard-Cache skaliert werden, die Größe kann jedoch nicht gleichzeitig geändert werden. Wenn Sie eine andere Größe benötigen, können Sie anschließend einen Skalierungsvorgang auf die gewünschte Größe durchführen.
  • Ein Basic-Cache kann nicht direkt auf einen Premium-Cache skaliert werden. Skalieren Sie zunächst in einem ersten Skalierungsvorgang von Basic auf Standard und dann im nächsten Skalierungsvorgang von Standard auf Premium.
  • Von einer größeren Größe kann nicht auf C0 (250 MB) herunterskaliert werden. Allerdings ist ein Herunterskalieren auf eine beliebige andere Größe innerhalb desselben Tarifs möglich. Beispielsweise können Sie von „C5 Standard“ auf „C1 Standard“ herunterskalieren.
  • Sie können von einem Premium-, Standard- oder Basic-Cache nicht auf einen Enterprise- oder Enterprise Flash-Cache hochskalieren.
  • Sie können nicht zwischen Enterprise und Enterprise Flash skalieren.

Sie können mit den folgenden Einschränkungen Aufskalieren/Abskalieren:

  • Das Aufskalieren wird nur für die Ebenen Premium, Enterprise und Enterprise Flash unterstützt.
  • Das Abskalieren wird nur in der Premium-Ebene unterstützt.
  • In der Premium-Ebene muss vor dem Hochskalieren oder Aufskalieren zuerst das Clustering aktiviert werden.
  • Auf der Premium-Stufe gibt es GA-Unterstützung für das Skalieren von bis zu 10 Shards. Die Unterstützung für bis zu 30 Shards befindet sich in der Vorschau. (Bei Caches mit zwei Replikaten beträgt der Shardgrenzwert 20. Bei drei Replikaten beträgt die Shardgrenze 15.)
  • Nur die Ebenen Enterprise und Enterprise Flash können gleichzeitig Hochskalieren und Aufskalieren.

Skalieren – Basic-, Standard- und Premium-Ebenen

Hochskalieren und Herunterskalieren mit dem Azure-Portal

  1. Zum Skalieren Ihres Caches browsen Sie zum Cache im Azure-Portal und wählen im Menü „Ressource“ den Eintrag Skalieren aus.

    Screenshot showing Scale on the resource menu.

  2. Wählen Sie im Arbeitsbereich einen Tarif aus und dann Auswählen.

    Screenshot showing the Azure Cache for Redis tiers.

  3. Während der Cache auf die neue Ebene skaliert, wird eine Skalierung des Redis-Cache-Benachrichtigung angezeigt.

    Screenshot showing the notification of scaling.

  4. Wenn die Skalierung abgeschlossen ist, ändert sich der Status von Wird skaliert zu Wird ausgeführt.

Hinweis

Wenn Sie einen Cache mit dem Portal hochskalieren oder herunterskalieren, werden die Einstellungen sowohl für maxmemory-reserved als auch für maxfragmentationmemory-reserved immer automatisch proportional zur Cachegröße skaliert. Wenn beispielsweise maxmemory-reserved für einen 6-GB-Cache auf 3 GB festgelegt ist und Sie eine Skalierung auf einen 12-GB-Cache vornehmen, werden die Einstellungen während der Skalierung automatisch auf 6 GB aktualisiert. Wenn Sie herunterskalieren, ist es umgekehrt.

Hochskalieren und Herunterskalieren mittels PowerShell

Sie können die Azure Cache for Redis-Instanzen mithilfe von PowerShell skalieren, indem Sie das Cmdlet Set-AzRedisCache verwenden, wenn die Eigenschaften Size oder Sku geändert werden. Das folgende Beispiel veranschaulicht, wie ein Cache mit Namen myCache zu einem 6-GB-Cache in der gleichen Ebene skaliert wird.

   Set-AzRedisCache -ResourceGroupName myGroup -Name myCache -Size 6GB

Weitere Informationen zum Skalieren mithilfe von PowerShell finden Sie unter Skalieren eines Azure Cache for Redis mit PowerShell.

Hochskalieren und Herunterskalieren mithilfe der Azure CLI

Rufen Sie den Befehl az redis update auf, um Ihre Azure Cache for Redis-Instanzen mithilfe der Azure CLI zu skalieren. Verwenden Sie die sku.capcity-Eigenschaft, um innerhalb einer Ebene zu skalieren, z. B. von einem Standard-C0- zu einem Standard C1-Cache:

az redis update --cluster-name myCache --resource-group myGroup --set "sku.capacity"="2"

Verwenden Sie die Eigenschaften „sku.name“ und „sku.family“, um auf eine andere Ebene hochzuskalieren, z. B. von einem Standard C1-Cache zu einem Premium P1-Cache:

az redis update --cluster-name myCache --resource-group myGroup --set "sku.name"="Premium" "sku.capacity"="1" "sku.family"="P"

Weitere Informationen zum Skalieren über die Azure-Befehlszeilenschnittstelle finden Sie unter Ändern der Einstellungen eines vorhandenen Azure Cache for Redis.

Hinweis

Wenn Sie einen Cache programmgesteuert hochskalieren oder herunterskalieren (d. h. mittels PowerShell oder Azure CLI), werden alle Werte für maxmemory-reserved oder maxfragmentationmemory-reserved als Teil der Aktualisierungsanforderung ignoriert. Nur Ihre Skalierungsänderung wird berücksichtigt. Sie können diese Speichereinstellungen aktualisieren, nachdem der Skalierungsvorgang abgeschlossen wurde.

Hochskalieren und Aufskalieren – Enterprise- und Enterprise Flash-Ebenen

Die Enterprise- und Enterprise Flash-Ebenen können in einem Vorgang hochskaliert und aufskaliert werden. Andere Ebenen erfordern separate Vorgänge für jede Aktion.

Achtung

Die Ebenen Enterprise und Enterprise Flash unterstützen die Vorgänge Herunterskalieren oder Abskalieren noch nicht.

Skalieren mithilfe des Azure-Portals

  1. Zum Skalieren Ihres Caches browsen Sie zum Cache im Azure-Portal und wählen im Menü „Ressource“ den Eintrag Skalieren aus.

    Screenshot showing Scale selected in the Resource menu for an Enterprise cache.

  2. Wählen Sie zum Hochskalieren einen anderen Cachetyp und dann Speichern aus.

    Wichtig

    Sie können derzeit nur hochskalieren. Sie können nicht herunterskalieren.

    Screenshot showing the Enterprise tiers in the working pane.

  3. Erhöhen Sie zum Aufskalieren den Schieberegler Kapazität. Die Kapazität erhöht sich in Inkrementen von zwei. Diese Zahl gibt an, wie viele zugrunde liegende Redis Enterprise-Knoten hinzugefügt werden. Diese Zahl ist immer ein Vielfaches von zwei, um Knoten widerzuspiegeln, die sowohl für primäre als auch für Replikatshards hinzugefügt werden.

    Wichtig

    Sie können derzeit nur aufskalieren und so die Kapazität erhöhen. Sie können nicht abskalieren.

    Screenshot showing Capacity in the working pane a red box around it.

  4. Während der Cache auf die neue Ebene skaliert, wird eine Skalierung des Redis-Cache-Benachrichtigung angezeigt.

    Screenshot showing notification of scaling an Enterprise cache.

  5. Wenn die Skalierung abgeschlossen ist, ändert sich der Status von Wird skaliert zu Wird ausgeführt.

Skalieren mithilfe von PowerShell

Sie können Ihre Azure Cache for Redis-Instanzen mit PowerShell skalieren, indem Sie das Cmdlet Update-AzRedisEnterpriseCache verwenden. Sie können die Sku-Eigenschaft ändern, um die Instanz hochzuskalieren. Sie können die Capacity-Eigenschaft ändern, um die Instanz aufzuskalieren. Das folgende Beispiel zeigt, wie Sie einen Cache mit Namen myCache auf eine Enterprise E20-Instanz (25 GB) mit einer Kapazität von 4 skalieren.

   Update-AzRedisEnterpriseCache -ResourceGroupName myGroup -Name myCache -Sku Enterprise_E20 -Capacity 4

Skalieren über die Azure-Befehlszeilenschnittstelle

Rufen Sie den Befehl az redisenterprise update auf, um Ihre Azure Cache for Redis-Instanzen mithilfe der Azure CLI zu skalieren. Sie können die sku-Eigenschaft ändern, um die Instanz hochzuskalieren. Sie können die capacity-Eigenschaft ändern, um die Instanz aufzuskalieren. Das folgende Beispiel zeigt, wie Sie einen Cache mit Namen myCache auf eine Enterprise E20-Instanz (25 GB) mit einer Kapazität von 4 skalieren.

az redisenterprise update --cluster-name "myCache" --resource-group "myGroup" --sku "Enterprise_E20" --capacity 4

Häufig gestellte Fragen zur Skalierung

Die folgende Liste enthält Antworten auf häufig gestellte Fragen zur Skalierung von Azure Cache for Redis-Instanzen.

Kann ich eine Skalierung auf einen Premium-Cache, aus diesem oder innerhalb von diesem vornehmen?

  • Eine Skalierung von einem Premium-Cache auf die niedrigeren Tarife Basic oder Standard ist nicht möglich.
  • Eine Skalierung von einem bestimmten Premium -Cachetarif zu einem anderen ist jedoch möglich.
  • Ein Basic-Cache kann nicht direkt auf einen Premium-Cache skaliert werden. Skalieren Sie zunächst in einem ersten Skalierungsvorgang von Basic auf Standard und dann in einem späteren Skalierungsvorgang von Standard auf Premium.
  • Sie können nicht von einem Premium-Cache auf einen Enterprise- oder Enterprise Flash-Cache skalieren.
  • Wenn Sie beim Erstellen des Premium-Cache die Clusterunterstützung aktiviert haben, können Sie die Clustergröße ändern. Wenn der Cache ohne aktiviertes Clustering erstellt wurde, können Sie das Clustering zu einem späteren Zeitpunkt konfigurieren.

Muss ich nach dem Skalieren den Namen oder die Zugriffsschlüssel für den Cache ändern?

Nein, Cachename und -schlüssel bleiben während eines Skalierungsvorgangs unverändert.

Wie funktioniert die Skalierung?

  • Wenn Sie einen Basic-Cache auf eine andere Größe skalieren, wird er heruntergefahren, und es wird ein neuer Cache mit der neuen Größe bereitgestellt. Während dieser Zeit ist der Cache nicht verfügbar, und alle Daten im Cache gehen verloren.
  • Wenn Sie einen Basic-Cache auf einen Standard-Cache skalieren, wird ein Replikatcache bereitgestellt, und die Daten werden aus dem primären Cache in den Replikatcache kopiert. Der Cache bleibt während des Skalierungsvorgangs verfügbar.
  • Wenn Sie einen Standard-, Premium-, Enterprise- oder Enterprise Flash-Cache auf eine andere Größe skalieren, wird eines der Replikate heruntergefahren und mit der neuen Größe erneut bereitgestellt, und die Daten werden übertragen. Anschließend führt das andere Replikat ein Failover durch, bevor es erneut bereitgestellt wird, ähnlich wie bei einem Ausfall eines der Cacheknoten.
  • Wenn Sie einen gruppierten Cache aufskalieren, werden neue Shards bereitgestellt und dem Redis-Servercluster hinzugefügt. Die Daten werden dann über alle Shards hinweg neu horizontal partitioniert.
  • Wenn Sie einen gruppierten Cache abskalieren, werden die Daten zuerst neu horizontal partitioniert, und anschließend wird die Clustergröße auf die Anzahl erforderlicher Shards reduziert.
  • In einigen Fällen, etwa beim Skalieren oder beim Migrieren des Cache zu einem anderen Cluster, kann sich die zugrunde liegende IP-Adresse des Cache ändern. Die DNS-Einträge für den Cache werden geändert und sind für die meisten Anwendungen transparent. Wenn Sie jedoch eine IP-Adresse verwenden, um die Verbindung mit Ihrem Cache zu konfigurieren, oder um NSGs zu konfigurieren, oder Firewalls, die Datenverkehr zum Cache zulassen, kann Ihre Anwendung nach der Aktualisierung des DNS-Eintrags Probleme mit der Verbindungsherstellung haben.

Verliere ich während der Skalierung Daten aus meinem Cache?

  • Wenn Sie einen Basic-Cache auf eine neue Größe skalieren, gehen alle Daten verloren, und der Cache ist während des Skalierungsvorgangs nicht verfügbar.
  • Wenn Sie einen Basic-Cache auf einen Standard-Cache skalieren, werden die Daten im Cache in der Regel beibehalten.
  • Wenn Sie einen Standard-, Premium-, Enterprise- oder Enterprise Flash-Cache auf eine größere Größe skalieren, werden in der Regel alle Daten beibehalten. Wenn Sie einen Standard- oder Premium-Cache auf eine kleinere Größe skalieren, können Daten verloren gehen, wenn die Datengröße die neue kleinere Größe beim Herunterskalieren überschreitet. Wenn Daten beim Herunterskalieren verloren gehen, werden die Schlüssel mithilfe der Entfernungsrichtlinie allkeys-lru entfernt.

Kann ich nach der Skalierung alle Features der Premium-Ebene verwenden?

Nein, einige Features können nur festgelegt werden, wenn Sie einen Cache in der Premium-Ebene erstellen, und sie sind nach der Skalierung nicht verfügbar.

Diese Features können nicht hinzugefügt werden, nachdem Sie den Premium-Cache erstellt haben:

  • VNet-Einschleusung
  • Hinzufügen von Zonenredundanz
  • Verwenden mehrerer Replikate pro primärer Instanz

Um eines dieser Features verwenden zu können, müssen Sie eine neuen Cache-Instanz in der Premium-Ebene erstellen.

Hat die Skalierung Auswirkungen auf meine benutzerdefinierte Einstellung für Datenbanken?

Wenn Sie bei der Cacheerstellung einen benutzerdefinierten Wert für die Einstellung databases konfiguriert haben, gelten bei einigen Tarifen andere Grenzwerte für Datenbanken. Hier sind einige Aspekte aufgeführt, die beim Skalieren in diesem Szenario wichtig sind:

  • Wenn Sie auf einen Tarif mit einem niedrigeren databases-Grenzwert skalieren als beim aktuellen Tarif:
    • Wenn Sie die Standardanzahl für databases verwenden (sie beträgt bei allen Tarifen 16), gehen keine Daten verloren.
    • Wenn Sie eine benutzerdefinierte Anzahl für databases verwenden, die innerhalb der Grenzwerte für den Tarif liegt, auf den Sie skalieren, wird diese databases-Einstellung beibehalten, und es gehen keine Daten verloren.
    • Wenn Sie eine benutzerdefinierte Anzahl für databases verwenden, die die Grenzwerte des neuen Tarifs überschreitet, wird die databases-Einstellung auf die Grenzwerte des neuen Tarifs herabgesetzt, und alle Daten in den entfernten Datenbanken gehen verloren.
  • Wenn Sie auf einen Tarif mit dem gleichen oder einem höheren databases-Grenzwert skalieren wie beim aktuellen Tarif, wird Ihre databases-Einstellung beibehalten, und es gehen keine Daten verloren.

Während Standard-, Premium-, Enterprise- und Enterprise Flash-Caches ein SLA für die Verfügbarkeit haben, gibt es kein SLA für Datenverluste.

Ist der Cache während der Skalierung verfügbar?

  • Standard-, Premium-, Enterprise- und Enterprise Flash-Caches bleiben während des Skalierungsvorgangs verfügbar. Es können jedoch Verbindungsunterbrechungen während der Skalierung dieser Caches auftreten, auch während der Skalierung von Basic- auf Standard-Caches. Diese Verbindungsunterbrechungen sollten voraussichtlich kurz sein, und die Redis-Clients können in der Regel ihre Verbindung sofort erneut herstellen.
  • Bei Enterprise- und Enterprise Flash-Caches mit aktiver Georeplikation kann die Skalierung nur einer Teilmenge der verknüpften Caches im Lauf der Zeit in einigen Fällen zu Problemen führen. Es wird empfohlen, alle Caches in der Georeplikationsgruppe wenn möglich zusammen zu skalieren.
  • Basic-Caches sind während der Skalierung auf eine andere Größe offline. Basic-Caches bleiben bei einer Skalierung von Basic auf Standard verfügbar, es können aber kurze Verbindungsunterbrechungen auftreten. Wenn Verbindungsunterbrechungen auftreten, können die Redis-Clients in der Regel ihre Verbindung sofort erneut herstellen.

Gibt es Skalierungseinschränkungen bei Verwendung der Georeplikation?

Wenn die passive Georeplikation konfiguriert ist, stellen Sie möglicherweise fest, dass Sie einen Cache nicht skalieren oder die Shards in einem Cluster nicht ändern können. Eine Georeplikationsverknüpfung zwischen zwei Caches hindert Sie an Skalierungsvorgängen oder an der Änderung der Anzahl von Shards in einem Cluster. Wenn Sie diese Befehle verwenden möchten, müssen Sie zuerst die Verknüpfung für den Cache aufheben. Weitere Informationen finden Sie unter Vorgehensweise zum Konfigurieren der Georeplikation für Azure Redis Cache.

Wenn die aktive Georeplikation konfiguriert ist, können Sie einen Cache nicht skalieren. Alle Caches in einer Georeplikationsgruppe müssen dieselbe Größe und Kapazität aufweisen.

Vorgänge, die nicht unterstützt werden

  • Sie können keine Skalierung von einem höheren Tarif auf einen niedrigeren Tarif vornehmen.
    • Eine Skalierung von einem Premium-Cache auf einen niedrigeren Standard- oder Basic-Cache ist nicht möglich.
    • Ein Standard-Cache kann nicht auf einen niedrigeren Basic-Cache skaliert werden.
  • Ein Basic-Cache kann auf einen Standard-Cache skaliert werden, die Größe kann jedoch nicht gleichzeitig geändert werden. Wenn Sie eine andere Größe benötigen, können Sie später einen Skalierungsvorgang auf die gewünschte Größe durchführen.
  • Ein Basic-Cache kann nicht direkt auf einen Premium-Cache skaliert werden. Skalieren Sie zunächst in einem ersten Skalierungsvorgang von Basic auf Standard und dann in einem späteren Vorgang von Standard auf Premium.
  • Sie können nicht von einem Premium-Cache auf einen Enterprise- oder Enterprise Flash-Cache skalieren.
  • Von einer größeren Größe kann nicht auf C0 (250 MB) herunterskaliert werden.

Wenn bei einem Skalierungsvorgang ein Fehler auftritt, versucht der Dienst, den Vorgang rückgängig zu machen, und der Cache wird auf die ursprüngliche Größe zurückgesetzt.

Wie lange dauert die Skalierung?

Die Skalierungsdauer hängt von einigen Faktoren ab. Hier sind einige Faktoren, die sich auf die Dauer der Skalierung auswirken können.

  • Datenmenge: Die Replikation größerer Datenmengen dauert länger.
  • Hohe Schreibanforderungen: Eine höhere Anzahl von Schreibvorgängen bedeutet, dass mehr Daten knoten- oder shardübergreifend repliziert werden.
  • Hohe Serverauslastung: Eine höhere Serverauslastung bedeutet, dass der Redis-Server ausgelastet ist und über begrenzte CPU-Zyklen verfügt, um die Neuverteilung der Daten abzuschließen.

Wenn Sie einen Cache ohne Daten skalieren, dauert es im Allgemeinen etwa 20 Minuten. Bei gruppierten Caches dauert die Skalierung ungefähr 20 Minuten pro Shard bei minimaler Datenmenge.

Woher weiß ich, dass die Skalierung abgeschlossen ist?

Im Azure-Portal können Sie den Fortschritt der Skalierung anzeigen. Wenn die Skalierung abgeschlossen ist, ändert sich der Status des Caches zu Wird ausgeführt.

Muss ich Änderungen an meiner Clientanwendung vornehmen, um das Clustering verwenden zu können?

  • Wenn das Clustering aktiviert ist, ist nur Datenbank 0 verfügbar. Wenn die Clientanwendung mehrere Datenbanken verwendet und versucht, eine andere Datenbank als Datenbank 0 zu lesen oder Schreibvorgänge dafür auszuführen, wird die folgende Ausnahme ausgelöst: Unhandled Exception: StackExchange.Redis.RedisConnectionException: ProtocolFailure on GET --->StackExchange.Redis.RedisCommandException: Multiple databases are not supported on this server; cannot switch to database: 6

    Weitere Informationen finden Sie unter Redis Cluster Specification - Implemented subset(Spezifikation für Redis-Cluster – implementierte Teilmenge).

  • Wenn Sie StackExchange.Redisnutzen, müssen Sie Version 1.0.481 oder höher verwenden. Sie stellen eine Verbindung mit dem Cache mit den gleichen Endpunkten, Ports und Schlüsseln her, die Sie auch für einen Cache verwenden, bei dem das Clustering deaktiviert ist. Der einzige Unterschied besteht darin, dass alle Lese- und Schreibvorgänge für Datenbank 0 erfolgen müssen.

    Für andere Clients gelten möglicherweise andere Anforderungen. Weitere Informationen finden Sie unter Wird das Clustering auf allen Redis-Clients unterstützt?

  • Wenn für Ihre Anwendung mehrere Schlüsselvorgänge zu einem einzelnen Befehl zusammengefasst sind, müssen sich alle Schlüssel in demselben Shard befinden. Informationen zum Suchen von Schlüsseln im gleichen Shard finden Sie unter Wie sind Schlüssel in einem Cluster verteilt?

  • Bei Verwendung des Redis ASP.NET-Sitzungszustandsanbieters müssen Sie Version 2.0.1 oder höher verwenden. Weitere Informationen finden Sie unter Kann ich das Clustering mit den Redis ASP.NET-Sitzungszustands- und -Ausgabezwischenspeicherungsanbietern verwenden?

Wichtig

Wenn Sie die Enterprise- oder Enterprise-FLash-Ebene verwenden, haben Sie die Wahl zwischen OSS-Clustermodus oder Enterprise-Clustermodus. Der OSS-Clustermodus entspricht dem Clustering auf der Premium-Ebene und entspricht der Spezifikation für Open Source-Clustering. Der Enterprise-Clustermodus kann weniger leistungsfähig sein, verwendet jedoch Redis Enterprise-Clustering, für das keine Clientänderungen erforderlich sind. Weitere Informationen finden Sie unter Clustering auf Enterprise.

Wie sind Schlüssel in einem Cluster verteilt?

Laut Redis-Dokumentation zum Schlüsselverteilungsmodell: Der Schlüsselbereich wird in 16 384 Slots aufgeteilt. Jeder Schlüssel wird gehasht und einem dieser Slots zugewiesen, die auf die Knoten des Clusters verteilt werden. Sie können konfigurieren, welcher Teil des Schlüssels gehasht ist, um sicherzustellen, dass mehrere Schlüssel in demselben Shard angeordnet sind. Verwenden Sie hierfür Hashtags.

  • Schlüssel mit einem Hashtag: Wenn ein Teil des Schlüssels in { und } gesetzt ist, wird nur dieser Teil des Schlüssels gehasht, um den Hashslot eines Schlüssels zu ermitteln. Die folgenden drei Schlüssel würden sich beispielsweise in demselben Shard befinden: {key}1, {key}2 und {key}3, da nur der key-Teil des Namens gehasht ist. Eine vollständige Liste mit den Spezifikationen für Schlüssel-Hashtags finden Sie unter Schlüssel-Hashtags.
  • Schlüssel ohne Hashtag: Der gesamte Schlüsselname wird für das Hashing verwendet, was zu einer statistisch gleichmäßigen Verteilung auf die Shards des Caches führt.

Zum Erzielen einer optimalen Leistung und eines hohen Durchsatzes empfehlen wir die gleichmäßige Verteilung der Schlüssel. Wenn Sie Schlüssel mit Hashtag verwenden, muss von der Anwendung sichergestellt werden, dass die Schlüssel gleichmäßig verteilt werden.

Weitere Informationen finden Sie unter Schlüsselverteilungsmodell, Redis Cluster-Daten-Sharding und Schlüssel-Hashtags.

Beispielcode zum Arbeiten mit Clustering und Suchen von Schlüsseln im gleichen Shard mit dem StackExchange.Redis-Client finden Sie im clustering.cs-Teil des Hello World-Beispiels (Hallo Welt).

Was ist die maximale Cachegröße, die ich erstellen kann?

Die größte Cachegröße, die Sie haben können, beträgt 4,5 TB. Dieses Ergebnis ist ein geclusterter F1500-Cache mit Kapazität 9. Weitere Informationen finden Sie unter Azure Cache for Redis – Preise.

Wird das Clustering auf allen Redis-Clients unterstützt?

Viele, aber nicht alle Clientbibliotheken unterstützen Redis-Clustering. Sehen Sie in der Dokumentation der Bibliothek, die Sie verwenden, nach, um zu überprüfen, ob Sie eine Bibliothek und Version verwenden, die Clustering unterstützen. „StackExchange.Redis“" ist eine Bibliothek, die in ihren neueren Versionen Clustering unterstützt. Weitere Informationen zu anderen Clients finden Sie im Redis Cluster Tutorial im Abschnitt Playing with the cluster (Arbeiten mit dem Cluster).

Das Redis-Clusteringprotokoll erfordert, dass jeder Client eine Verbindung mit jedem Shard direkt im Clustermodus herstellen muss, und definiert ferner neue Fehlerantworten wie „MOVED“ und „CROSSSLOTS“. Wenn Sie versuchen, eine Clientbibliothek, die kein Clustering unterstützt, mit einem Cache im Clustermodus zu verwenden, kann dies im Ergebnis zu zahlreichen MOVED-Umleitungsausnahmen führen oder einfach Ihre Anwendung beschädigen, wenn Sie slotübergreifende Anforderungen mit mehreren Schlüsseln ausführen.

Hinweis

Wenn Sie StackExchange.Redis als Client verwenden, müssen Sie überprüfen, dass Sie die aktuelle Version StackExchange.Redis 1.0.481 oder höher verwenden, damit das Clustering ordnungsgemäß funktioniert. Weitere Informationen zu allen mit MOVE-Ausnahmen finden Sie unter MOVE-Ausnahmen.

Wie stelle ich eine Verbindung mit dem Cache her, wenn das Clustering aktiviert ist?

Sie können eine Verbindung mit dem Cache mit den gleichen Endpunkten, Ports und Schlüsseln herstellen, die Sie auch für einen Cache verwenden, bei dem das Clustering nicht aktiviert ist. Redis verwaltet das Clustering auf dem Back-End, sodass es nicht über Ihren Client verwaltet werden muss.

Kann ich direkt eine Verbindung mit den einzelnen Shards des Caches herstellen?

Für das Clusteringprotokoll muss der Client die richtigen Shardverbindungen herstellen, weshalb der Client Freigabeverbindungen für Sie herstellen sollte. Allerdings besteht jeder Shard aus einem Paar aus primärem Cache und Replikatcache, die zusammen als Cacheinstanz bezeichnet werden. Mit dem Hilfsprogramm Redis-CLI im instabilen Branch des Redis-Repositorys auf GitHub können Sie eine Verbindung mit diesen Cache-Instanzen herstellen. Diese Version implementiert grundlegende Unterstützung, wenn sie mit dem Switch -c gestartet wird. Weitere Informationen finden Sie im Redis Cluster-Tutorial unter Playing with the cluster (Ausprobieren des Clusters) auf https://redis.io.

Sie müssen den -p-Switch verwenden, um den richtigen Port anzugeben, mit dem eine Verbindung hergestellt werden soll. Verwenden Sie den Befehl CLUSTER NODES, um die genauen Ports zu ermitteln, die für die primären und Replikatknoten verwendet werden. Die folgenden Portbereiche werden verwendet:

  • Für Nicht-TLS Caches auf Premium-Ebene sind Ports im 130XX-Bereich verfügbar
  • Für TLS-fähige Caches auf Premium-Ebene sind Ports im 150XX-Bereich verfügbar
  • Bei Enterprise- und Enterprise Flash-Caches, die OSS-Clustering verwenden, erfolgt die anfängliche Verbindung über Port 10000. Eine Verbindung mit einzelnen Knoten kann mittels Ports im 85xx-Bereich hergestellt werden. Die 85xx-Ports werden sich im Laufe der Zeit ändern und sollten nicht in Ihre Anwendung hartcodiert werden.

Kann ich das Clustering für einen bereits erstellten Cache konfigurieren?

Ja. Stellen Sie zunächst sicher, dass sich Ihr Cache auf der Premium-Ebene befindet, indem Sie ihn hochskalieren. Als Nächstes können Sie die Clusterkonfigurationsoptionen anzeigen, einschließlich einer Option zum Aktivieren von Clustern. Ändern Sie die Clustergröße, nachdem der Cache erstellt wurde, oder nachdem Sie das Clustering zum ersten Mal aktiviert haben.

Wichtig

Die Aktivierung des Clusterings lässt sich nicht rückgängig machen. Und ein Cache mit aktivierter Clusterunterstützung und nur einem Shard verhält sich anders als ein Cache derselben Größe ohne Clustering.

Alle Caches der Enterprise- und Enterprise Flash-Ebene sind immer geclustert.

Kann ich das Clustering für einen Basic- oder Standard-Cache konfigurieren?

Clustering ist nur für Premium-, Enterprise- und Enterprise Flash-Caches verfügbar.

Kann ich das Clustering mit den Redis ASP.NET-Sitzungszustands- und -Ausgabezwischenspeicherungsanbietern verwenden?

Bei Verwenden von StackExchange.Redis und Clustering erhalte ich MOVE-Ausnahmen. Was soll ich tun?

Wenn Sie StackExchange.Redis und Clustering verwenden und dabei MOVE -Ausnahmen erhalten, vergewissern Sie sich, dass Sie mindestens StackExchange.Redis 1.1.603 verwenden. Anweisungen zum Konfigurieren Ihrer .NET-Anwendungen für die Verwendung von StackExchange.Redis finden Sie unter Konfigurieren der Cacheclients.

Was ist der Unterschied zwischen OSS-Clustering und Enterprise-Clustering in Caches der Enterprise-Ebene?

Der OSS-Clustermodus entspricht dem Clustering auf der Premium-Ebene und entspricht der Spezifikation für Open Source-Clustering. Der Enterprise-Clustermodus kann weniger leistungsfähig sein, verwendet jedoch Redis Enterprise-Clustering, für das keine Clientänderungen erforderlich sind. Weitere Informationen finden Sie unter Clustering auf Enterprise.

Wie viele Shards verwenden Caches der Enterprise-Ebene?

Im Gegensatz zu Caches der Basic-, Standard- und Premium-Ebene können Enterprise- und Enterprise Flash-Caches mehrere Shards auf einem einzelnen Knoten nutzen. Weitere Informationen finden Sie unter Sharding und CPU-Auslastung.

Nächste Schritte