Skalieren einer Azure Cache for Redis-Instanz

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.	Prämie	Enterprise und Enterprise Flash
Hochskalieren	Ja	Ja	Ja
Herunterskalieren	Ja	Ja	Nein
Aufskalieren	Nein	Ja	Ja
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. Mit mehreren vCPUs kann das Hochskalieren und das Aufskalieren in diesen Ebenen hilfreich sein, um die Serverlast zu reduzieren.
• 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. Um festzustellen, wie viel Bandbreite auf der Serverseite verwendet wird, aktivieren Sie die Metriken „Cache Read“ (Cache-Lesevorgänge) und „Cache Write“ (Cache-Schreibvorgänge). 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.
• Interne Defender-Scans
  • Während auf den VMs interne Defender-Scans ausgeführt werden, sehen Sie möglicherweise in C0- und C1-Standardcaches kurze Spitzen bei der Serverlast, die nicht durch eine Zunahme der Cacheanforderungen verursacht werden. Sie sehen eine höhere Wartezeit für Anforderungen, während interne Defender-Scans ein paar Mal pro Tag auf diesen Ebenen ausgeführt werden. Caches auf den Ebenen C0 und C1 weisen nur einen einzigen Kern für Multitasking auf und teilen die Arbeit der Bereitstellung von internen Defender-Scans und Redis-Anforderungen auf. Sie können den Effekt reduzieren, indem Sie auf ein Angebot einer höherer Ebene mit mehreren CPU-Kernen skalieren, z. B. C2.
  • Die erhöhte Cachegröße auf den höheren Ebenen trägt dazu bei, etwaige Wartezeitprobleme zu beheben. Außerdem haben Sie auf C2-Ebene Unterstützung für bis zu 2 000 Clientverbindungen.

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) abskaliert werden. Allerdings ist ein Abskalieren auf eine beliebige andere Größe innerhalb desselben Tarifs möglich. Beispielsweise können Sie von „C5 Standard“ auf „C1 Standard“ abskalieren.
• 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-Ebene ist der Support für das Aufskalieren auf bis zu 10 Shards allgemein verfügbar. 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 Basic, Standard und Premium

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.

   

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

   

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

   

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.capacity-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 nach oben oder unten skalieren (z. B. mithilfe von PowerShell oder Azure CLI), werden alle maxmemory-reserved oder maxfragmentationmemory-reserved werden als Teil der Updateanforderung ignoriert. Nur Ihre Skalierungsänderung wird berücksichtigt. Sie können diese Speichereinstellungen aktualisieren, nachdem der Skalierungsvorgang abgeschlossen ist.

Aufskalieren und Abskalieren – nur Premium

Erstellen eines neuen Caches, der mithilfe von Clustering aufskaliert wird

Das Clustering wird während der Cacheerstellung über den Arbeitsbereich aktiviert, wenn Sie einen neuen Azure Cache for Redis erstellen.

1. Verwenden Sie dieErstellen eines Open-Source-Redis-Caches-Schnellstartanleitung, um mit der Erstellung eines neuen Caches mit dem Azure-Portal zu beginnen.

2. Konfigurieren Sie auf der Registerkarte Erweitert für eine Premium-Cache-Instanz die Einstellungen für einen Nicht-TLS-Port, das Clustering und die Datenpersistenz. Zum Aktivieren des Clusterings klicken Sie auf Aktivieren.

   

   Sie können bis zu 30 Shards im Cluster haben. Nachdem Sie auf Aktivieren geklickt haben, verschieben Sie den Schieberegler, oder geben Sie eine Zahl zwischen 1 und 30 für die Shardanzahl ein und wählen Sie OK aus.

   Jeder Shard ist ein Paar aus primärem Cache/Replikatcache, das von Azure verwaltet wird. Die Gesamtgröße des Caches wird durch Multiplikation der Anzahl der Shards mit der im Tarif ausgewählten Cachegröße berechnet.

   

   Nach der Erstellung des Caches können Sie eine Verbindung mit dem Cache herstellen und ihn genauso wie einen nicht geclusterten Cache verwenden. Redis verteilt die Daten auf alle Cache-Shards. Wenn die Diagnose aktiviert ist, werden Metriken für jeden Shard separat erfasst und können im Azure-Cache für Redis mithilfe des Menüs "Ressource" angezeigt werden.

3. Schließen Sie die Erstellung des Caches mithilfe der Schnellstartanleitung ab.

Es dauert eine Weile, bis der Cache erstellt wird. Sie können den Fortschritt auf der Seite Übersicht von Azure Cache for Redis überwachen. Wenn Wird ausgeführt als Status angezeigt wird, ist der Cache einsatzbereit.

Hinweis

Es gibt einige geringfügige Unterschiede, die in Ihrer Clientanwendung erforderlich sind, wenn das Clustering konfiguriert ist. Weitere Informationen finden Sie unter Muss ich Änderungen an meiner Clientanwendung vornehmen, um Clustering verwenden zu können?

Beispielcode zum Arbeiten mit Clustering mit dem StackExchange.Redis-Client finden Sie im clustering.cs-Teil des Hello World-Beispiels.

Abskalieren oder Aufskalieren eines ausgeführten Premium-Caches

Wenn Sie die Clustergröße in einem zuvor erstellten Premium-Cache ändern möchten und die Ausführung bereits mit aktiviertem Clustering erfolgt, wählen Sie im Ressourcenmenü die Option Clustergröße aus.

Verwenden Sie den Schieberegler, oder geben Sie im Textfeld Shardanzahl eine Zahl zwischen 1 und 30 ein, um die Clustergröße zu ändern. Wählen Sie dann OK aus, um die Änderung zu speichern.

Wenn Sie den Cluster vergrößern, erhöht sich der maximale Durchsatz, und der Cache vergrößert sich. Die Vergrößerung des Clusters führt nicht zu einer Erhöhung der maximalen Anzahl der für Clients verfügbaren Verbindungen.

Aufskalieren und Abskalieren mittels PowerShell

Sie können Ihre Azure Cache for Redis-Instanzen mithilfe von PowerShell aufskalieren, indem Sie das Cmdlet Set-AzRedisCache verwenden, wenn die Eigenschaft ShardCount geändert wird. Das folgende Beispiel zeigt, wie Sie einen Cache mit dem Namen myCache aufskalieren, um drei Shards zu verwenden (d. a. aufskalieren um den Faktor 3)

   Set-AzRedisCache -ResourceGroupName myGroup -Name myCache -ShardCount 3

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

Aufskalieren und Abskalieren mithilfe der Azure CLI

Rufen Sie den Befehl az redis update auf und verwenden Sie die Eigenschaft shard-count, um Ihre Azure Cache for Redis-Instanzen mithilfe der Azure CLI zu skalieren. Das folgende Beispiel zeigt, wie Sie einen Cache mit dem Namen myCache aufskalieren, um drei Shards zu verwenden (d. a. aufskalieren um den Faktor 3).

az redis update --cluster-name myCache --resource-group myGroup --set shard-count=3

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 nach oben oder unten skalieren (z. B. mithilfe von PowerShell oder Azure CLI), werden alle maxmemory-reserved oder maxfragmentationmemory-reserved werden als Teil der Updateanforderung ignoriert. Nur Ihre Skalierungsänderung wird berücksichtigt. Sie können diese Speichereinstellungen aktualisieren, nachdem der Skalierungsvorgang abgeschlossen ist.

Hinweis

Bei der Skalierung eines Clusters wird der Befehl MIGRATE ausgeführt, der sehr teuer ist. Für minimale Auswirkungen sollten Sie diesen Vorgang während der Zeiten geringer Auslastung ausführen. Während des Migrationsprozesses sehen Sie einen Anstieg der Serverlast. Das Skalieren eines Clusters ist ein langer Prozess und die benötigte Zeit hängt von der Anzahl der Schlüssel und der Größe der Werte ab, die diesen Schlüsseln zugeordnet sind.

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.

   

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

   Wichtig

   Sie können derzeit nur hochskalieren. Sie können nicht nach unten skalieren.

   

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 die Abskalierung nicht ausführen.

   

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

   

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?
• Muss ich nach dem Skalieren den Namen oder die Zugriffsschlüssel für den Cache ändern?
• Wie funktioniert die Skalierung?
• Verliere ich während der Skalierung Daten aus meinem Cache?
• Kann ich nach der Skalierung alle Features der Premium-Ebene verwenden?
• Hat die Skalierung Auswirkungen auf meine benutzerdefinierte Einstellung für Datenbanken?
• Ist mein Cache während der Skalierung verfügbar?
• Gibt es Skalierungseinschränkungen bei Verwendung der Georeplikation?
• Vorgänge, die nicht unterstützt werden
• Wie lange dauert die Skalierung?
• Woher weiß ich, dass die Skalierung abgeschlossen ist?
• Muss ich Änderungen an meiner Clientanwendung vornehmen, um das Clustering verwenden zu können?
• Wie sind Schlüssel in einem Cluster verteilt?
• Was ist die maximale Cachegröße, die ich erstellen kann?
• Wird das Clustering auf allen Redis-Clients unterstützt?
• Wie stelle ich eine Verbindung mit dem Cache her, wenn das Clustering aktiviert ist?
• Kann ich direkt eine Verbindung mit den einzelnen Shards des Caches herstellen?
• Kann ich das Clustering für einen bereits erstellten Cache konfigurieren?
• Kann ich das Clustering für einen Basic- oder Standard-Cache konfigurieren?
• 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?
• Was ist der Unterschied zwischen OSS-Clustering und Enterprise Clustering in Caches auf Enterprise-Ebene?
• Wie viele Shards verwenden Caches der Enterprise-Ebene?

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, der Cachename und die Schlüssel ändern sich während eines Skalierungsvorgangs nicht.

Wie funktioniert die Skalierung?

• Wenn Sie einen Basic-Cache auf eine andere Größe skalieren, wird der Cache 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.
• Beim Skalieren oder Migrieren des Caches zu einem anderen Cluster kann sich die zugrunde liegende IP-Adresse des Caches ä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 NSGs oder Firewalls zu konfigurieren, die Datenverkehr zum Cache zulassen, kann Ihre Anwendung nach aktualisierung des DNS-Eintrags Probleme beim Herstellen einer Verbindung 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 ursprüngliche Datengröße die neue kleinere Größe ü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:

• Einfügen virtueller Netzwerke
• 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 mein 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 mit einigen Einschränkungen skalieren. Alle Caches in einer Georeplikationsgruppe müssen die gleiche Größe und Kapazität aufweisen. Weitere Informationen finden Sie unter Konfigurieren der aktiven Georeplikation für Azure Cache für Redis-Instanzen.

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. Die folgenden Faktoren können sich darauf auswirken, wie lange die Skalierung dauert:

• Datenmenge: Größere Datenmengen dauern länger, bis sie repliziert werden.
• Hohe Schreibanforderungen: Eine höhere Anzahl von Schreibvorgängen bedeutet, dass mehr Daten über Knoten oder Shards repliziert werden.
• Hohe Serverlast: Höhere Serverlast bedeutet, dass der Redis-Server ausgelastet ist und begrenzte CPU-Zyklen für die vollständige Datenumverteilung verfügbar sind.

Das Skalieren eines Caches ist keine triviale Aktion und kann lange dauern. Es kann ein bis zwei Stunden dauern, einen Cache mit ein bis zwei Shards zu skalieren, wenn er nicht stark ausgelastet ist. Wenn Sie mehr Scherben haben, erhöht sich die Zeit für die Skalierung nicht linear.

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 Ihre Clientanwendung mehrere Datenbanken verwendet und versucht, eine andere Datenbank als Null zu lesen oder zu schreiben, tritt die folgende Ausnahme auf: 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.

  Andere Clients haben möglicherweise andere Anforderungen. Weitere Informationen finden Sie unter "Alle Redis-Clients unterstützen Clustering" .

• 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 Auffinden von Schlüsseln in derselben Shard finden Sie unter Wie werden 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 Clustering mit den Redis ASP.NET Sitzungszustands- und Ausgabezwischenspeicherungsanbietern verwenden" .

Wichtig

Wenn Sie die Ebenen Enterprise oder Enterprise FLash verwenden, haben Sie die Wahl des OSS-Clustermodus oder des Unternehmensclustermodus. 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.

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 Clusteringmodus herstellen muss, und es definiert auch neue Fehlerantworten wie MOVED und CROSSSLOTS. Wenn Sie versuchen, eine Clientbibliothek zu verwenden, die das Clustering mit einem Clustermodus-Cache nicht unterstützt, kann dies zu zahlreichen MOVED-Umleitungsfehlern führen oder Ihre Anwendung funktionsunfähig machen, wenn Sie Multi-Key-Anfragen über verschiedene Slots hinweg ausführen.

Hinweis

Wenn Sie StackExchange.Redis als Client verwenden, überprüfen Sie, ob Sie die neueste Version von StackExchange.Redis 1.0.481 oder höher verwenden, damit 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 https://redis.io (Ausprobieren des Clusters) auf .

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 ist, oder nachdem Sie das Clustering zum ersten Mal aktivieren.

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?

• Redis-Ausgabecacheanbieter: Keine Änderungen erforderlich.
• Redis-Sitzungszustandsanbieter: Zum Verwenden des Clusterings müssen Sie RedisSessionStateProvider 2.0.1 oder höher verwenden. Andernfalls wird eine Ausnahme ausgelöst, wobei es sich um einen Breaking Change handelt. Weitere Informationen finden Sie unter v2.0.0 Breaking Change Details (v2.0.0 – Details zu unterbrechenden Änderungen).

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.

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.

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-Konfiguration.

Nächste Schritte

• Konfigurieren der Einstellung „maxmemory-reserved“
• Bewährte Methoden zum Skalieren