Was sind die bewährten Methoden für die Ebenen Enterprise und Enterprise Flash
Hier sind die bewährten Methoden für die Verwendung der Enterprise- und Enterprise Flash-Ebenen von Azure Cache für Redis.
Zonenredundanz
Es wird dringend empfohlen, neue Caches in einer zonenredundanten Konfiguration bereitzustellen. Durch Zonenredundanz wird sichergestellt, dass Redis Enterprise-Knoten auf drei Verfügbarkeitszonen verteilt werden, was die Redundanz bei Ausfällen auf Rechenzentrumsebene verbessert. Die Verwendung von Zonenredundanz erhöht die Verfügbarkeit. Weitere Informationen finden Sie unter Service Level Agreements (SLA) for Online Services (Vereinbarungen zum Servicelevel (Service Level Agreements, SLAs) für Onlinedienste).
Zonenredundanz ist für den Enterprise-Tarif wichtig, da Ihre Cacheinstanz immer mindestens drei Knoten verwendet. Zwei Knoten sind Datenknoten, auf denen sich Ihre Daten befinden, und ein Knoten fungiert als Quorumknoten. Bei Erhöhung der Kapazität wird die Anzahl von Datenknoten in geradzahligen Schritten skaliert.
Ein weiterer Knoten ist der Quorumknoten. Dieser Knoten überwacht die Datenknoten und wählt im Falle eines Failovers automatisch den neuen primären Knoten aus. Zonenredundanz stellt sicher, dass die Knoten gleichmäßig auf drei Verfügbarkeitszonen verteilt werden, was die Wahrscheinlichkeit von Quorumverlusten minimiert. Der Quorumknoten wird Kunden nicht in Rechnung gestellt, und abgesehen von den Gebühren für die zoneninterne Bandbreite fallen für die Verwendung von Zonenredundanz keine weiteren Gebühren an.
Skalierung
In den Enterprise- und Enterprise Flash-Ebenen von Azure Cache für Redis empfehlen wir, die Skalierung über die horizontale Skalierung zu priorisieren. Priorisieren Sie die Skalierung, da die Enterprise-Ebenen auf Redis Enterprise basieren, das mehr CPU-Kerne in größeren virtuellen Computern nutzen kann.
Für die Tarife Basic, Standard und Premium, die auf Open-Source-Redis basieren, gilt dagegen die gegenteilige Empfehlung. In diesen Ebenen wird in den meisten Fällen die Priorisierung der horizontalen Skalierung über die Skalierung empfohlen.
Horizontales Partitionieren und CPU-Auslastung
In den Tarifen Basic, Standard und Premium von Azure Cache for Redis kann die Anzahl verwendeter virtueller CPUs (vCPUs) ganz einfach bestimmt werden. Jeder Redis-Knoten wird auf einer dedizierten VM ausgeführt. Der Redis-Serverprozess verfügt über einen einzelnen Thread und verwendet eine einzelne vCPU auf jedem Primär- und Replikatknoten. Die anderen vCPUs des virtuellen Computers werden weiterhin für andere Aktivitäten genutzt. Hierzu zählen unter anderem die Workflowkoordinierung für verschiedene Aufgaben, die Integritätsüberwachung und die TLS-Last.
Durch Clustering werden Daten auf mehr Knoten mit jeweils einem Shard pro Knoten verteilt. Wenn Sie die Anzahl von Shards erhöhen, erhöht sich die Anzahl verwendeter vCPUs linear (basierend auf der Anzahl von Shards im Cluster).
Redis Enterprise kann dagegen mehrere vCPUs für die eigentliche Redis-Instanz verwenden. Anders ausgedrückt: In allen Tarifen von Azure Cache for Redis können mehrere vCPUs für Hintergrund- und Überwachungsaufgaben genutzt werden, aber nur in den Enterprise- und Enterprise Flash-Tarifen können mehrere vCPUs pro virtuellem Computer für Redis-Shards verwendet werden. Die Tabellen enthalten die Anzahl effektiver vCPUs, die für einzelnen SKUs und Kapazitätskonfigurationen (also für die horizontale Skalierung) verwendet werden.
Die in den Tabellen angegebene Anzahl von vCPUs bezieht sich auf die primären Shards, nicht auf die Replikatshards. Shards sind nicht 1:1 der Anzahl von vCPUs zugeordnet. Die Tabellen veranschaulichen nur vCPUs, keine Shards. Einige Konfigurationen verwenden mehr Shards als verfügbare vCPUs, um die Leistung in bestimmten Verwendungsszenarien zu erhöhen.
E1
| Capacity | Effektive vCPUs |
|---|---|
| 2 | 1 (burstfähig) |
E5
| Capacity | Effektive vCPUs |
|---|---|
| 2 | 1 |
| 4 | 2 |
| 6 | 6 |
E10
| Capacity | Effektive vCPUs |
|---|---|
| 2 | 2 |
| 4 | 6 |
| 6 | 6 |
| 8 | 16 |
| 10 | 20 |
E20
| Capacity | Effektive vCPUs |
|---|---|
| 2 | 2 |
| 4 | 6 |
| 6 | 6 |
| 8 | 16 |
| 10 | 20 |
E50
| Capacity | Effektive vCPUs |
|---|---|
| 2 | 6 |
| 4 | 6 |
| 6 | 6 |
| 8 | 30 |
| 10 | 30 |
E100
| Capacity | Effektive vCPUs |
|---|---|
| 2 | 6 |
| 4 | 30 |
| 6 | 30 |
| 8 | 30 |
| 10 | 30 |
E200
| Capacity | Effektive vCPUs |
|---|---|
| 2 | 30 |
| 4 | 60 |
| 6 | 60 |
| 8 | 120 |
| 10 | 120 |
E400
| Capacity | Effektive vCPUs |
|---|---|
| 2 | 60 |
| 4 | 120 |
| 6 | 120 |
| 8 | 240 |
| 10 | 240 |
F300
| Capacity | Effektive vCPUs |
|---|---|
| 3 | 6 |
| 9 | 30 |
F700
| Capacity | Effektive vCPUs |
|---|---|
| 3 | 30 |
| 9 | 30 |
F1500
| Capacity | Effektive vCPUs |
|---|---|
| 3 | 30 |
| 9 | 90 |
Clustering im Enterprise-Tarif
Enterprise- und Enterprise Flash-Tarife verfügen im Gegensatz zu den Tarifen Basic, Standard und Premium standardmäßig über Clustering. Die Implementierung hängt von der ausgewählten Clusteringrichtlinie ab. Die Enterprise-Tarife bieten zwei Optionen für die Clusteringrichtlinie: OSS und Enterprise. Die Clusteringrichtlinie OSS wird für die meisten Anwendungen empfohlen, da sie einen höheren maximalen Durchsatz unterstützt. Jede Version hat aber gewisse Vor- und Nachteile.
Die Clusteringrichtlinie OSS implementiert die gleiche Redis-Cluster-API wie Open-Source-Redis. Die Redis-Cluster-API ermöglicht es dem Redis-Client, eine direkte Verbindung mit jedem Redis-Knoten herzustellen, was die Wartezeit minimiert und den Netzwerkdurchsatz optimiert. Dadurch wird eine nahezu lineare Skalierbarkeit erzielt, wenn der Cluster mit weiteren Knoten aufskaliert wird. Die OSS-Clusteringrichtlinie bietet im Allgemeinen die beste Wartezeit und Durchsatzleistung, setzt jedoch voraus, dass Ihre Clientbibliothek Redis-Clustering unterstützt. Außerdem kann die OSS-Clusteringrichtlinie nicht mit dem RediSearch-Modul verwendet werden.
Die Enterprise-Clusteringrichtlinie ist eine einfachere Konfiguration, die einen einzelnen Endpunkt für alle Clientverbindungen nutzt. Bei Verwendung der Enterprise-Clusteringrichtlinie werden alle Anforderungen an einen einzelnen Redis-Knoten weitergeleitet, der dann als Proxy fungiert und Anforderungen intern an den richtigen Knoten im Cluster weiterleitet. Der Vorteil dieses Ansatzes besteht darin, dass Redis-Clientbibliotheken das Redis-Clustering nicht unterstützen müssen, um mehrere Knoten nutzen zu können. Der Nachteil ist, dass ein einzelner Knoten als Proxy einen Engpass darstellen kann (entweder bei der Computeauslastung oder beim Netzwerkdurchsatz). Die Enterprise-Clusteringrichtlinie ist die einzige Richtlinie, die mit dem RediSearch-Modul verwendet werden kann.
Befehle mit mehreren Schlüsseln
Da die Enterprise-Tarife eine Clusterkonfiguration verwenden, werden für Befehle, die auf mehreren Schlüsseln basieren, möglicherweise Ausnahmen vom Typ CROSSSLOT angezeigt. Das Verhalten variiert je nach verwendeter Clusteringrichtlinie. Wenn Sie die OSS-Clusteringrichtlinie verwenden, müssen bei Befehlen mit mehreren Schlüsseln alle Schlüssel dem gleichen Hashslot zugeordnet werden.
Bei Verwendung der Enterprise-Clusteringrichtlinie treten ggf. auch Fehler vom Typ CROSSSLOT auf. Beim Enterprise-Clustering können nur folgende Befehle mit mehreren Schlüsseln slotübergreifend verwendet werden: DEL, MSET, MGET, EXISTS, UNLINK und TOUCH.
In Active-Active Datenbanken können Schreibbefehle mit mehreren Schlüsseln (DEL, MSET, UNLINK) nur für Schlüssel ausgeführt werden, die sich im selben Slot befinden. Die folgenden Befehle mit mehreren Schlüsseln sind jedoch slotsübergreifend in Active-Active Datenbanken zulässig: MGET, EXISTSund TOUCH. Weitere Informationen finden Sie im Artikel zum Datenbankclustering unter Multi-key operations (Vorgänge mit mehreren Schlüsseln).
Bewährte Methoden für Enterprise Flash
Die Dienstebene „Enterprise Flash“ verwendet sowohl NVMe-Flashspeicher als auch RAM. Da Flashspeicher kostengünstiger ist, können Sie mit der Dienstebene „Enterprise Flash“ einen Kompromiss zwischen Leistung und Preiseffizienz erzielen.
Bei Enterprise Flash-Instanzen befinden sich 20 % des Cachespeichers im RAM, während für die anderen 80 % Flashspeicher verwendet wird. Alle Schlüssel werden im RAM gespeichert, während die Werte entweder im Flashspeicher oder im RAM gespeichert werden können. Die Redis-Software bestimmt den Speicherort der Werte auf intelligente Weise. Heiße Werte, auf die häufig zugegriffen wird, werden im RAM gespeichert, während kalte Werte, die weniger häufig verwendet werden, im Flashspeicher gespeichert werden. Bevor Daten gelesen oder geschrieben werden, müssen sie in den RAM verschoben werden, wodurch sie zu heißen Daten werden.
Redis optimiert die Speichernutzung, um die bestmögliche Leistung zu erzielen. Daher belegt die Instanz zuerst den verfügbaren RAM, bevor Elemente dem Flashspeicher hinzugefügt werden. Das anfängliche Auffüllen des RAM hat einige Auswirkungen auf die Leistung:
- Beim Testen mit geringer Speichernutzung können eine bessere Leistung und kürzere Wartezeiten auftreten. Tests mit einer vollständigen Cache-Instanz können zu einer geringeren Leistung führen, da nur RAM in der Testphase mit geringer Arbeitsspeicherauslastung verwendet wird.
- Wenn Sie mehr Daten in den Cache schreiben, verringert sich der Anteil der Daten im RAM im Vergleich zum Flashspeicher, was in der Regel zu einer Abnahme der Wartezeit- und Durchsatzleistung führt.
Für die Dienstebene „Enterprise Flash“ geeignete Workloads
Workloads, die sich voraussichtlich gut für die Ausführung mit der Dienstebene „Enterprise Flash“ eignen, weisen oft die folgenden Merkmale auf:
- Leseintensiv mit einem hohen Anteil von Lesebefehlen gegenüber Schreibbefehlen
- Der Zugriff liegt schwerpunktmäßig auf einer Teilmenge von Schlüsseln, die deutlich häufiger verwendet werden als der Rest des Datasets.
- Relativ große Werte im Vergleich zu den Schlüsselnamen (Da Schlüsselnamen immer im RAM gespeichert werden, können große Werte einen Engpass für die Arbeitsspeichervergrößerung verursachen.)
Für die Ebene „Enterprise Flash“ nicht geeignete Workloads
Einige Workloads verfügen über Zugriffseigenschaften, die für das Design der Flash-Ebene weniger optimal sind:
- Schreibintensiv
- Zufällige oder einheitliche Datenzugriffsmuster im Großteil des Datasets.
- Lange Schlüsselnamen mit relativ kleinen Werten
Behandeln von Regionsausfällen mit aktiver Georeplikation
Die aktive Georeplikation ist ein leistungsstarkes Feature, mit dem Sie die Verfügbarkeit bei Verwendung der Enterprise-Tarife von Azure Cache for Redis erheblich verbessern können. Sie sollten Ihre Caches allerdings für einen möglichen Regionsausfall vorbereiten.
Hier finden Sie einige Tipps:
- Geben Sie im Voraus an, zu welchem anderen Cache in der Georeplikationsgruppe gewechselt werden soll, wenn eine Region ausfällt.
- Stellen Sie sicher, dass Firewalls so konfiguriert sind, dass alle Anwendungen und Clients auf den angegebenen Ausweichcache zugreifen können.
- Jeder Cache in der Georeplikationsgruppe verfügt über einen eigenen Zugriffsschlüssel. Bestimmen Sie, wie die Anwendung zu verschiedenen Zugriffsschlüsseln wechselt, wenn sie auf einen Backup-Cache zugreift.
- Wenn ein Cache in der Georeplikationsgruppe ausfällt, sammeln sich in allen Caches in der Georeplikationsgruppe Metadaten an. Die Metadaten können erst verworfen werden, wenn Schreibvorgänge wieder mit allen Caches synchronisiert werden können. Sie können die Ansammlung von Metadaten verhindern, indem Sie für den ausgefallenen Cache die Aufhebung der Verknüpfung erzwingen. Erwägen Sie die Überwachung des verfügbaren Arbeitsspeichers im Cache und die Aufhebung der Verknüpfung bei hoher Arbeitsspeicherauslastung (insbesondere bei schreibintensiven Workloads).
Sie können auch ein Trennschalter-Muster verwenden. Verwenden Sie das Muster, um Datenverkehr automatisch von einem Cache mit ausgefallener Region an einen Ausweichcache in der gleichen Georeplikationsgruppe umzuleiten. Verwenden Sie Azure-Dienste wie Azure Traffic Manager oder Azure Load Balancer, um die Umleitung zu ermöglichen.
Datenpersistenz im Vergleich zu Datensicherung
Das Feature Datenpersistenz der Enterprise- und Enterprise Flash-Tarife ist so konzipiert, dass im Falle eines Cacheausfalls automatisch ein schneller Wiederherstellungspunkt für Daten bereitgestellt wird. Die schnelle Wiederherstellung wird durch Speichern der RDB- oder AOF-Datei auf einem verwalteten Datenträger ermöglicht, der in die Cache-Instanz eingebunden wird. Persistenzdateien auf dem Datenträger sind für Benutzer nicht zugänglich.
Viele Kunden möchten die Persistenz nutzen, um regelmäßige Sicherungen der Daten in ihrem Cache durchzuführen. Wir raten jedoch davon ab, Datenpersistenz auf diese Weise zu verwenden. Verwenden Sie stattdessen das Feature Importieren/Exportieren. Sie können Kopien von Cachedaten im RDB-Format direkt in Ihr ausgewähltes Speicherkonto exportieren und den Datenexport mit der benötigten Frequenz auslösen. Der Export kann entweder über das Portal oder über die CLI, per PowerShell oder mithilfe von SDK-Tools ausgelöst werden.
E1-SKU-Einschränkungen
Die E1-SKU ist hauptsächlich für Entwicklungs-/Testszenarien vorgesehen. E1 wird auf kleineren burstfähigen VMs ausgeführt. Burstfähige VMs bieten eine variable Leistung, je nachdem, wie viel CPU-Ressourcen verbraucht werden. Im Gegensatz zu anderen Enterprise-SKU-Angeboten können Sie die E1-SKU nicht aufskalieren, obwohl es weiterhin möglich ist, auf eine größere SKU hochzuskalieren. Die E1-SKU unterstützt auch keine aktive Georeplikation.