Teilen über

Skalieren einer Azure Managed Redis-Instanz

  • Gilt für: ✅ Azure Managed Redis

Azure Managed Redis verfügt über verschiedene SKU- und Tierangebote, die Flexibilität bei der Auswahl der Cachegröße und -leistung bieten. Sie können bis auf eine größere Arbeitsspeichergröße skalieren oder auf eine Ebene mit einer höheren Berechnungsleistung ändern. Sie können auch auf eine kleinere oder geeignetere Ebene nach unten skalieren. Dieser Artikel zeigt Ihnen, wie Sie Ihren Cache mithilfe des Azure-Portals und mit Tools wie Azure PowerShell und der Azure-Befehlszeilenschnittstelle skalieren.

Hinweis

Da jede Ebene von Azure Managed Redis fast dieselben Features aufweist, wird die Skalierung in der Regel nur verwendet, um Speicher- und Leistungsmerkmale zu ändern. Die Skalierung georeplizierter Azure Managed Redis-Caches verbleibt in der öffentlichen Vorschau.

Skalierungstypen

Azure Managed Redis unterstützt die Skalierung in zwei Dimensionen:

  • Arbeitsspeicher Durch die Erhöhung des Arbeitsspeichers wird die Redis-Instanz vergrößert, sodass Sie mehr Daten speichern können. Wenn Sie den Arbeitsspeicher verringern, müssen Sie sicherstellen, dass die aktuelle Speicherauslastung kleiner als die neue Arbeitsspeichergröße ist, die Sie verwenden möchten.

  • vCPUs Azure Managed Redis bietet drei Ebenen (Arbeitsspeicheroptimiert, Ausgewogen und Für Compute optimiert), die eine zunehmende Anzahl von vCPUs für jede Speicherstufe aufweisen. Die Skalierung auf eine Ebene mit mehr vCPUs erhöht die Leistung Ihrer Instanz, ohne dass Sie den Arbeitsspeicher erhöhen müssen. Im Gegensatz zu den Stufen "Basic", "Standard" und "Premium" von Azure Cache für Redis, die nur eine einzelne vCPU verwenden, verwendet Azure Managed Redis den Redis Enterprise-Stapel. Der Redis Enterprise-Stapel kann mehrere vCPUs verwenden, was bedeutet, dass die Anzahl der von Ihrer Redis-Instanz verwendeten vCPUs direkt mit der Leistung von Durchsatz und Latenz korreliert.

Leistungsstufen

Es gibt vier Stufen von Azure Managed Redis, die jeweils mit unterschiedlichen Leistungsmerkmalen und Preisniveaus verfügbar sind.

Von Bedeutung

Alle Speicherebenen, die mehr als 235 GB Speicherplatz verwenden, befinden sich in der öffentlichen Vorschau, einschließlich speicheroptimierter M350 und höher, ausgewogener B350 und höher und rechenoptimierter X350 und höher. Alle diese Ebenen und höher befinden sich in der öffentlichen Vorschau.

Alle für Flash optimierten Ebenen befinden sich in der öffentlichen Vorschau.

Stufen und SKUs auf einen Blick

Es gibt drei Ebenen, die Daten im Arbeitsspeicher speichern:

  • Speicher optimiert Ideal für speicherintensive Anwendungsfälle, die ein hohes Speicher-zu-vCPU-Verhältnis (8:1) erfordern, aber nicht die höchste Durchsatzleistung benötigen. Diese Leistungsstufe bietet einen niedrigeren Preispunkt für Szenarien, in denen weniger Verarbeitungsleistung oder Durchsatz erforderlich ist, was eine hervorragende Wahl für Entwicklungs- und Testumgebungen darstellt.

  • Ausgeglichen (Speicher + Compute): Dies bietet ein ausgewogenes Verhältnis von Speicher zu vCPU (4:1) und ist damit ideal für Standardworkloads. Diese Stufe bietet ein gutes Gleichgewicht zwischen Arbeitsspeicher und Computeressourcen.

  • Für Compute optimiert: Entwickelt für leistungsintensive Workloads, die einen maximalen Durchsatz erfordern, mit einem geringen Verhältnis von Arbeitsspeicher zu vCPU (2:1). Diese Leistungsstufe ist ideal für Anwendungen, die die höchste Leistung erfordern.

    Abbildung einer Tabelle, die einen Vergleich von SKUs und Stufen zeigt.

Dies ist die Ebene, die Daten sowohl im Arbeitsspeicher als auch auf dem Datenträger speichert:

  • Flash optimiert (Vorschau) Ermöglicht Redis-Clustern das automatische Verschieben von weniger häufig aufgerufenen Daten aus dem Arbeitsspeicher (RAM) in den NVMe-Speicher. Dies reduziert die Leistung, ermöglicht aber eine kostengünstige Skalierung von Caches mit großen Datasets.

    Ein Bild einer Tabelle, die Flash-optimierte Ebenen in einer Tabelle mit dem Speicherverbrauch zeigt.

Leistung (Durchsatz und Latenz)

Leistungstests und weitere Informationen zum Messen der Leistung jeder SKU und -Ebene finden Sie unter Leistungstests mit Azure Managed Redis

Zeitpunkt für die Skalierung

Sie können mithilfe der Überwachungsfunktionen von Azure Managed 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.

  • CPU
    • Eine hohe Redis-CPU-Auslastung bedeutet, dass der Redis-Server nicht mit den Anforderungen aller Clients Schritt halten kann. Durch die Skalierung auf mehr vCPUs können Anforderungen über mehrere Redis-Prozesse verteilt werden. Die Skalierung hilft auch bei der Verteilung der TLS-Verschlüsselung/Entschlüsselung und der Verbindung/Trennung, wodurch Cache-Instanzen mithilfe von TLS beschleunigt werden.
  • 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. Wenn Sie den Arbeitsspeicher verringern, müssen Sie sicherstellen, dass die Speicherauslastung des aktuellen Caches niedriger ist als die neue Speichergröße, die Sie verwenden möchten. Sie können einen großen Datensatz nicht in eine kleinere Cachegröße einfügen.
  • 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 eine Skalierung auf eine höhere Speichergröße oder Leistungsstufe erwägen.
    • Weitere Informationen zu Verbindungsgrenzwerten in Abhängigkeit von der Cachegröße finden Sie unter Leistungstests mit Azure Managed 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 die Skalierung auf eine höhere Leistungsstufe oder eine größere Cachegröße in Betracht ziehen.
    • Die Auswahl der Clusterrichtlinie wirkt sich auf die verfügbare Netzwerkbandbreite aus. Im Allgemeinen verfügt die OSS-Clusterrichtlinie über eine höhere Netzwerkbandbreite als die Enterprise-Clusterrichtlinie. Weitere Informationen finden Sie unter Clusterrichtlinie
    • Weitere Informationen zur verfügbaren Netzwerkbandbreite in Abhängigkeit von der Cachegröße finden Sie unter Leistungstests mit Azure Managed Redis.

Weitere Informationen dazu, wie Sie ermitteln, welcher Cachetarif geeignet ist, finden Sie unter Auswählen der richtigen Ebene.

Weitere Informationen zum Optimieren des Skalierungsprozesses finden Sie in den bewährten Methoden für die Skalierung.

Einschränkungen der Skalierung von Azure Managed Redis

  • Sie können nicht von den Stufen Arbeitsspeicheroptimiert, Ausgewogen oder Für Compute optimiert auf die Stufe Flash-Optimiert skalieren oder umgekehrt.
  • Wenn Sie den Speicher für Ihre Redis-Instanz verringern, sollte die aktuelle Speicherauslastung Ihrer Redis-Instanz kleiner als die beabsichtigte neue Speichergröße sein. Weitere Informationen finden Sie unter Was geschieht mit meinen Daten, wenn ich auf eine kleinere Speichergröße skaliere?.
  • Wenn Sie den Arbeitsspeicher oder die vCPU für Ihre Redis-Instanz reduzieren, können Sie nur auf SKUs skalieren, die über eine vCPU- und Shardkonfiguration verfügen, die mit der Konfiguration in Ihrer aktuellen Instanz kompatibel ist.
  • In einigen Fällen kann sich die zugrunde liegende IP-Adresse der Redis-Instanz ändern. Die DNS-Einträge für die Instanz werden geändert und sind für die meisten Anwendungen transparent. Wenn Sie jedoch eine IP-Adresse verwenden, um die Verbindung mit Ihrer Redis-Instanz zu konfigurieren, oder um NSGs oder Firewalls zu konfigurieren, die Datenverkehr zur Redis-Instanz zulassen, kann ihre Anwendung einige Zeit nach aktualisierung des DNS-Eintrags Probleme beim Herstellen einer Verbindung haben.
  • Das Skalieren einer Instanz in einer Georeplikationsgruppe hat einige weitere Einschränkungen. Weitere Informationen finden Sie unter „Gibt es Skalierungseinschränkungen bei der Georeplikation?“.
  • Wenn Sie eine Skalierung nach unten ausführen, können Sie nur auf bestimmte Ebenen skalieren. Weitere Informationen finden Sie unter Warum kann nur ich auf eine Teilmenge kleinerer SKUs herunterskalieren?.

Schritte zur Skalierung

In diesem Abschnitt wird beschrieben, wie Sie einen Azure Managed Redis-Cache skalieren.

Skalieren mithilfe des Azure-Portals

Hinweis

Die Skalierung georeplizierter Azure Managed Redis-Caches verbleibt in der öffentlichen Vorschau.

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

  2. Um Ihre vCPUs zu skalieren, wählen Sie einen anderen Cachetyp und dann " Speichern" aus.

    Von Bedeutung

    Wenn Sie eine SKU auswählen, die nicht skaliert werden kann, ist die Option " Speichern " deaktiviert. Ausführliche Informationen dazu, welche Skalierungsoptionen zulässig sind, erfahren Sie im Abschnitt "Einschränkungen der Skalierung von Azure Managed Redis ".

  3. Wenn die Skalierung abgeschlossen ist, ändert sich der Status von "Skalierung " in " Ausführen ", wenn der Abschnitt "Übersicht" des Menüs "Ressource" angezeigt wird.

Skalieren mithilfe von PowerShell

Sie können Ihre Azure Managed Redis-Instanzen mit PowerShell skalieren, indem Sie das Cmdlet Update-AzRedisEnterpriseCache verwenden. Sie können die Sku-Eigenschaft ändern, um die benötigte Ebene und SKU auszuwählen. Das folgende Beispiel zeigt, wie Sie einen Cache mit Namen myCache auf eine für Compute optimierte X20-Instanz (24 GB) skalieren.

   Update-AzRedisEnterpriseCache -ResourceGroupName <your-group> -Name <your-cache-name> -Sku <sku-name>

Skalieren über die Azure-Befehlszeilenschnittstelle

Rufen Sie den Befehl az redisenterprise update auf, um Ihre Azure Managed Redis-Instanzen mithilfe der Azure CLI zu skalieren. Sie können die sku-Eigenschaft ändern, um die benötigte Ebene und SKU auszuwählen. Das folgende Beispiel zeigt, wie Sie einen Cache mit Namen myCache auf eine für Compute optimierte X20-Instanz (24 GB) skalieren.

az redisenterprise update --cluster-name <your-cache-name> --resource-group <your-resource-group> --sku <name-of-sku>

Häufig gestellte Fragen zur Skalierung

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

Kann ich innerhalb oder über Ebenen hinweg skalieren?

Sie können immer auf eine höhere Leistungsstufe mit derselben Speichergröße oder auf eine größere Speichergröße innerhalb derselben Leistungsebene skalieren. Für die Skalierung auf eine niedrigere Leistungsstufe oder eine kleinere Speichergröße empfehlen wir, die REST-API "listskusforscaling" auszuführen, um die Liste der SKUs abzurufen, auf die Sie skalieren können.

az redisenterprise list-skus-for-scaling --cluster-name <your-redis-instance> --resource-group <your-resource-group>

Was geschieht mit meinen Daten, wenn ich auf eine kleinere Speichergröße skaliere?

Sie können nur dann auf eine kleinere Speichergröße skalieren, wenn die aktuelle Speicherauslastung kleiner als die beabsichtigte kleinere Arbeitsspeichergröße ist. Wenn die aktuelle Speicherauslastung höher als die beabsichtigte kleinere Größe ist, schlägt die Skalierungsanforderung fehl. Sie können die aktuelle Speicherauslastung verringern, indem Sie unerwünschte Schlüsselwertpaare gelöscht oder den Leerenvorgang ausführen.

az redisenterprise database flush --cluster-name <your-redis-instance> --resource-group <your-resource-group>

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

Nein, Der Cachename und die Zugriffstasten werden während eines Skalierungsvorgangs nicht geändert.

Wie funktioniert die Skalierung?

  • Wenn Sie eine Redis-Instanz skalieren, wird einer der Knoten im Redis-Cluster heruntergefahren und in der neuen Größe neu bereitgestellt. Dann werden die Daten übertragen und der andere Knoten führt als nächstes einen ähnlichen Failover durch, bevor er neu bereitgestellt wird. Das Herunterfahren und die Wiederbereitstellung ähneln dem Prozess, der beim Patchen oder bei einem Ausfall eines der Knoten eines Caches auftritt.
  • Wenn Sie eine Instanz mit mehr vCPUs skalieren, werden neue Shards bereitgestellt und dem Redis-Servercluster hinzugefügt. Die Daten werden dann über alle Shards hinweg neu horizontal partitioniert.

Weitere Informationen dazu, wie Azure Managed Redis Sharding behandelt, finden Sie unter Sharding-Konfiguration.

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

  • Wenn der Modus für hohe Verfügbarkeit aktiviert ist, sollten alle Daten während der Skalierung beibehalten werden.
  • Wenn Sie auf einen kleineren Speichergrad skalieren, müssen Sie sicherstellen, dass die aktuelle Speicherauslastung kleiner als die beabsichtigte neue Speichergröße ist. Wenn die aktuelle Speicherauslastung mehr als die beabsichtigte SKU-Speichergröße ist, können Sie die Daten mit dem Flush-Vorgang leeren oder manuell schlüsselwerte auswählen, die gelöscht werden sollen.
  • Wenn der Modus für hohe Verfügbarkeit deaktiviert ist, gehen alle Daten verloren, und der Cache ist während des Skalierungsvorgangs nicht verfügbar.

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

  • Azure Managed Redis-Instanzen mit aktiviertem Hochverfügbarkeitsmodus bleiben während des Skalierungsvorgangs verfügbar. Verbindungsblips können jedoch beim Skalieren dieser Caches auftreten. Diese Verbindungsunterbrechungen sind üblicherweise kurz sein, und die Redis-Clients können in der Regel ihre Verbindung sofort erneut herstellen.
  • Wenn der Modus für hohe Verfügbarkeit deaktiviert ist, ist die Azure Managed Redis-Instanz während der Skalierungsvorgänge offline.

Gibt es Skalierungseinschränkungen bei Verwendung der Georeplikation?

Die Skalierung georeplizierter Caches befindet sich in der öffentlichen Vorschau. Wenn die aktive Georeplikation konfiguriert ist, können Sie die Cachegrößen in einer Georeplikationsgruppe nicht kombinieren und abgleichen. Daher erfordert die Skalierung der Caches in einer Georeplikationsgruppe einige weitere Schritte. Anweisungen finden Sie unter Instanzen in einer Georeplikationsgruppe skalieren.

Die Skalierung auf eine kleinere Speichergröße oder kleinere Shardanzahl wird für geo replizierte Caches nicht unterstützt. Weitere Informationen finden Sie unter Wie viele Shards jede Azure Managed Redis SKU verwendet, um die Shards in Ihrem Cluster zu ermitteln.

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 CPU-Auslastung: Eine höhere CPU-Auslastung bedeutet, dass der Redis-Server ausgelastet ist und nur begrenzte CPU-Zyklen verfügbar sind, um die Datenneuverteilung abzuschließen

Wenn Sie eine Instanz ohne Daten skalieren, dauert es im Allgemeinen etwa 10 Minuten.

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 Running, wenn Sie die Übersicht im Menü "Ressource" ansehen.

Verwendet Azure Managed Redis Clustering?

Im Gegensatz zu Azure Cache for Redis verwendet Azure Managed Redis Clustering auf allen Ebenen und SKUs. Clustering ermöglicht erhebliche Leistungsoptimierungen. Jede SKU von Azure Managed Redis ist für eine optimierte Anzahl von Shards für die Anzahl der verfügbaren vCPUs konfiguriert. Die Anzahl der Shards kann nicht von der benutzenden Person konfiguriert werden.

Wie viele Shards verwendet jede Azure Managed Redis-SKU?

Da Azure Managed Redis auf der Redis Enterprise-Software läuft, können Shards in einer dichteren Konfiguration als in Community-Redis verwendet werden. Informationen zur spezifischen Anzahl von Shards, die in jeder SKU verwendet werden, finden Sie unter Sharding-Konfiguration.

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.

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, die als Flash-optimierte A4500-Instanz bezeichnet wird. Azure Cache for Redis: Preise.

Warum kann nur ich auf eine Teilmenge kleinerer SKUs herunterskalieren?

Um die Kompatibilität mit der Anzahl der Shards und vCPU aufrechtzuerhalten, dürfen Sie nur auf bestimmte SKUs herunterskalieren. Sie können sehen, auf welche SKUs Ihre Redis-Instanz herunterskalieren kann, indem Sie die verfügbaren Optionen im Abschnitt "Skalierung" des Azure-Portals überprüfen. Sie können auch den folgenden CLI-Befehl ausführen.

Sie können sehen, auf welche SKUs Ihre Redis-Instanz herunterskalieren kann, indem Sie die verfügbaren Optionen im Abschnitt "Skalierung" des Azure-Portals überprüfen.

az redisenterprise list-skus-for-scaling --cluster-name <your-redis-instance> --resource-group <your-resource-group>

Kann die Clusteringrichtlinie nach der Auswahl von OSS oder Enterprise Cluster geändert werden?

Nachdem Sie beim Erstellen eines Caches eine Clusterrichtlinie auf OSSCluster oder EnterpriseCluster festgelegt haben, können Sie sie nicht mehr ändern. Um zu einer anderen Clusteringrichtlinie zu wechseln, müssen Sie den Redis-Cache löschen und mit der gewünschten Konfiguration neu erstellen. Nur Caches mit der Richtlinie "Nichtcluster" können nach der Bereitstellung in eine gruppierte Konfiguration aktualisiert werden.

Verwandte Inhalte

  • Last updated on