Freigeben über

Skalieren einer Azure Managed Redis-Instanz (Vorschau)

  • Artikel

Azure Managed Redis (Vorschau) verfügt über verschiedene SKU- und Dienstebenenangebote, die Flexibilität bei der Auswahl der Cachegröße und -leistung bieten. Sie können bis zu einer größeren Arbeitsspeichergröße skalieren oder auf eine Ebene mit einer höheren Berechnungsleistung ändern. 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 nahezu dieselben Features aufweist, wird die Skalierung in der Regel nur verwendet, um Speicher- und Leistungsmerkmale zu ändern.

Wichtig

Derzeit wird nur die Skalierung auf größere Speichergrößen oder eine höhere Leistungsstufe unterstützt. Das Herunterskalieren von Speichergrößen oder auf eine weniger leistungsfähige Ebene wird noch nicht unterstützt.

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.

  • 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 zur Community-Edition von Redis, die nur eine einzelne vCPU verwenden kann, verwendet Azure Managed Redis den Redis Enterprise-Stapel, der mehrere vCPUs verwenden kann. Dies 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.

Drei Leistungsstufen sind für Daten im Arbeitsspeicher vorgesehen:

  • Arbeitsspeicheroptimiert. Ideal für speicherintensive Anwendungsfälle, die ein hohes Verhältnis von Arbeitsspeicher zu vCPU (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.
  • Ausgewogen (Arbeitsspeicher + Compute). Diese Leistungsstufe bietet ein ausgewogenes Verhältnis von Arbeitsspeicher zu vCPU (4:1) und ist damit ideal für Standardworkloads geeignet. Diese Leistungsstufe bietet ein gutes Gleichgewicht zwischen Arbeitsspeicher und Computeressourcen.
  • Für Compute optimiert. Entwickelt für leistungsintensive Workloads, die einen maximalen Durchsatz mit einem geringen Verhältnis von Arbeitsspeicher zu vCPU (2:1) erfordern. Diese Ebene ist ideal für Anwendungen, die die höchste Leistung erfordern.

Eine Leistungsstufe speichert Daten sowohl im Arbeitsspeicher als auch auf dem Datenträger:

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

Ebenen und SKUs auf einen Blick

Tabelle mit den verschiedenen Speicher- und vCPU-Konfigurationen für jede SKU und Ebene von Azure Managed Redis.

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

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 Managed Redis

  • Sie können nicht von den Stufen Arbeitsspeicheroptimiert, Ausgewogen oder Für Compute optimiert auf die Stufe Flash-Optimiert skalieren oder umgekehrt.
  • Sie können nicht von einer SKU mit weniger vCPUs herunterskalieren. (Übergreifend über Ebenen oder innerhalb einer Leiste.)
  • Sie können nicht auf eine kleinere Speichergröße skalieren, auch wenn sie über die gleichen oder mehr vCPUs verfügt.
  • 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 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.
  • Das Skalieren einer Instanz in einer Georeplikationsgruppe hat einige weitere Einschränkungen. Weitere Informationen finden Sie unter „Gibt es Skalierungseinschränkungen bei der Georeplikation?“.

Schritte zur Skalierung

Tipp

Sie können sowohl die Arbeitsspeichergröße als auch die Leistungsebene in einem Vorgang ändern.

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 zeigt ausgewählte Option „Skalieren“ im Menü „Ressource“ für einen Enterprise-Cache.

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

    Wichtig

    Wenn Sie eine SKU auswählen, die nicht skaliert werden kann, ist die Option Speichern deaktiviert. Lesen Sie die Voraussetzungen/Einschränkungen für die Skalierung von Azure Managed Redis, um Details zu den zulässigen Skalierungsoptionen zu erhalten.

    Screenshot zeigt die Enterprise-Ebenen im Arbeitsbereich.

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

    Screenshot zeigt Benachrichtigung zum Skalieren eines Enterprise-Caches.

  4. 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 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 myGroup -Name myCache -Sku ComputeOptimized_X20

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 "myCache" --resource-group "myGroup" --sku "ComputeOptimized_X20"

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. Informationen zum Herabskalieren auf eine niedrigere Leistungsstufe oder eine kleinere Speichergröße finden Sie unter Voraussetzungen/Einschränkungen für die Skalierung von Azure Managed Redis.

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 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 einen ähnlichen Failover durch, bevor er neu bereitgestellt wird. Dies ähnelt dem Prozess, der während des Patchings oder eines Fehlers eines der Cacheknoten auftritt.
  • Bei der Skalierung auf eine Instanz mit mehr vCPUs 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 eine kleinere Speicherstufe herunterskalieren, können Daten verloren gehen, wenn die Datengröße die neue kleinere Größe überschreitet, wenn der Cache herunterskaliert wird. Wenn Daten beim Herunterskalieren verloren gehen, werden die Schlüssel mithilfe der Entfernungsrichtlinie allkeys-lru entfernt.
  • 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 der 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?

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 Georepliationsgruppe einige weitere Schritte. Anweisungen finden Sie unter Instanzen in einer Georeplikationsgruppe skalieren.

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 Wird ausgeführt.

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.

Was ist der Unterschied zwischen den OSS- und Enterprise-Clusterrichtlinien?

Die OSS-Clusterrichtlinie ist identisch mit dem Clustering-Ansatz, der in der Community Edition Redis verwendet wird. In der Regel ist die OSS-Clusterrichtlinie leistungsfähiger. Die Enterprise-Clusterrichtlinie implementiert Clustering, sodass sie einem Client als nicht gruppierte Redis-Instanz angezeigt wird. Dieser Ansatz kann weniger leistungsfähig sein, kann jedoch Clientkompatibilitätsprobleme verhindern. Es ist derzeit nicht möglich, zwischen Clusterrichtlinien in einer ausgeführten Instanz zu wechseln. Weitere Informationen finden Sie unter Clusterrichtlinie.

Nächste Schritte