Azure Cache for Redis und Zuverlässigkeit
Azure Cache for Redis verfügt über einen auf der Redis-Software (Remote Dictionary Server) basierenden In-Memory-Datenspeicher. Ein sicherer Datencache und Messagingbroker, der Anwendungen Datenzugriff mit hohem Durchsatz und geringer Wartezeit bietet.
Zu den wichtigsten Konzepten und bewährten Methoden, die die Zuverlässigkeit unterstützen, gehören:
Die folgenden Abschnitte enthalten Entwurfsüberlegungen, eine Konfigurationsprüfliste und empfohlene Konfigurationsoptionen speziell für Azure Cache for Redis.
Überlegungen zum Entwurf
Die Vereinbarung zum Servicelevel (SLA) für Azure Cache for Redis deckt nur Caches im Standard- und Premium-Tarif ab. Der Basic-Tarif ist nicht abgedeckt.
Redis ist ein In-Memory-Cache für Schlüssel-Wert-Paare und verfügt standardmäßig über Hochverfügbarkeit (High Availability, HA), mit Ausnahme des Basic-Tarifs. Es gibt drei Tarife für Azure Cache for Redis:
Basic: Für Produktionsworkloads nicht zu empfehlen. Der Basic-Tarif eignet sich ideal für:
- Einzelner Knoten
- Mehrere Größen
- Entwicklung
- Test
- Nicht kritische Workloads
Standard: Ein replizierter Cache in einer Primär- und Sekundärkonfiguration mit zwei Knoten, die von Microsoft verwaltet wird, mit Hochverfügbarkeits-SLA.
Premium: Umfasst alle Features des Standard-Tarifs und die folgenden zusätzlichen Features:
- Schnellere Hardware und Leistung im Vergleich zum Basic- oder Standard-Tarif.
- Größerer Cache, bis zu
120GB. - Datenpersistenz, einschließlich Redis Database File (RDB) und Append Only File (AOF).
- VNET-Unterstützung
- Clustering
- Georeplikation: Ein sekundärer Cache befindet sich in einer anderen Region und repliziert Daten aus dem primären Cache für die Notfallwiederherstellung. Um ein Failover auf den sekundären Cache durchzuführen, muss die Verknüpfung der Caches manuell aufgehoben werden, und dann steht der sekundäre Cache für Schreibvorgänge zur Verfügung. Die Anwendung, die in Redis schreibt, muss mit der Verbindungszeichenfolge des sekundären Caches aktualisiert werden.
- Verfügbarkeitszonen: Stellen Sie den Cache und die Replikate über Verfügbarkeitszonen hinweg bereit.
Hinweis
Standardmäßig verfügt jede Bereitstellung über ein Replikat pro Shard. Persistenz, Clustering und Georeplikation sind derzeit bei Bereitstellungen mit mehreren Replikaten deaktiviert. Ihre Knoten werden gleichmäßig auf alle Zonen verteilt. Sie sollten über eine Replikatanzahl verfügen, die größer oder gleich der Anzahl von Zonen ist.
- Import und Export
Microsoft garantiert für mindestens 99.9% der Zeit, dass Kunden über Konnektivität zwischen den Cacheendpunkten und dem Internetgateway von Microsoft verfügen.
Checkliste
Haben Sie Azure Cache for Redis unter Berücksichtigung der Resilienz konfiguriert?
- Planen von Updates
- Überwachen Sie den Cache, und legen Sie Warnungen fest.
- Stellen Sie den Cache in einem VNet bereit.
- Werten Sie eine Partitionierungsstrategie im Redis-Cache aus.
- Konfigurieren Sie die Datenpersistenz, um eine Kopie des Caches in Azure Storage zu speichern, oder verwenden Sie die Georeplikation in Abhängigkeit von der Unternehmensanforderung.
- Implementieren Sie Wiederholungsrichtlinien im Kontext Ihrer Azure Redis Cache-Instanz.
- Verwenden Sie eine statische oder Singleton-Implementierung des Verbindungsmultiplexers mit Redis, und befolgen Sie den Leitfaden zu den bewährten Methoden.
- Lesen Sie auch Verwalten von Azure Cache for Redis.
Konfigurationsempfehlungen
In der folgenden Tabelle finden Sie Empfehlungen zum Optimieren der Dienstzuverlässigkeit Ihrer Azure Cache for Redis-Konfiguration:
| Empfehlung | BESCHREIBUNG |
|---|---|
| Planen von Updates | Planen Sie die Tage und Uhrzeiten, zu denen Redis Server-Updates auf den Cache angewendet werden (ohne Azure-Updates oder Updates für das VM-Betriebssystem). |
| Überwachen Sie den Cache, und legen Sie Warnungen fest. | Legen Sie Warnungen für Ausnahmen, hohe CPU- und Arbeitsspeicherauslastung, Serverauslastung sowie entfernte Schlüssel fest, um Erkenntnisse darüber zu erhalten, wann der Cache skaliert werden soll. Wenn der Cache skaliert werden muss, ist der Zeitpunkt der erforderlichen Skalierung wichtig, da die CPU-Auslastung während des Skalierungsereignisses für die Migration der Daten erhöht wird. |
| Stellen Sie den Cache in einem VNET bereit. | Verleiht dem Kunden mehr Kontrolle über den Datenverkehr, der eine Verbindung mit dem Cache herstellen kann. Stellen Sie sicher, dass für das Subnetz ausreichend Adressraum verfügbar ist, um die Cacheknoten und Shards (Cluster) bereitzustellen. |
| Werten Sie eine Partitionierungsstrategie im Redis-Cache aus. | Die Partitionierung eines Redis-Datenspeichers umfasst das instanzenübergreifende Aufteilen von Daten für den Redis-Server. Jede Instanz bildet eine einzelne Partition. Azure Redis Cache abstrahiert die Redis-Dienste hinter einer Fassade und macht sie nicht direkt verfügbar. Die einfachste Methode zum Implementieren der Partitionierung ist es, mehrere Azure Redis Cache-Instanzen zu erstellen und die Daten auf diese Instanzen zu verteilen. Sie können jedem Datenelement einen Bezeichner (Partitionsschlüssel) zuordnen, der angibt, in welchem Cache es gespeichert ist. Die Logik der Clientanwendung kann diesen Bezeichner dann zum Weiterleiten von Anforderungen an die entsprechende Partition verwenden. Dieses Schema ist einfach, aber wenn sich das Partitionierungsschema ändert (z. B. durch Erstellen weiterer Azure Redis Cache-Instanzen), müssen Clientanwendungen möglicherweise neu konfiguriert werden. |
| Konfigurieren Sie die Datenpersistenz, um eine Kopie des Caches in Azure Storage zu speichern, oder verwenden Sie die Georeplikation in Abhängigkeit von der Unternehmensanforderung. | Datenpersistenz: Wenn Master und Replikat neu gestartet werden, werden die Daten automatisch aus dem Speicherkonto geladen. Georeplikation: Die Verknüpfung des sekundären Caches mit dem primären Cache muss aufgehoben werden. Der sekundäre Cache wird jetzt zum primären Cache und kann Schreibvorgänge empfangen. |
| Implementieren Sie Wiederholungsrichtlinien im Kontext Ihrer Azure Redis Cache-Instanz. | Die meisten Azure-Dienste und Client-SDKs enthalten einen Wiederholungsmechanismus. Diese Mechanismen unterscheiden sich, da jeder Dienst unterschiedliche Merkmale und Anforderungen aufweist. Jeder Wiederholungsmechanismus ist auf einen bestimmten Dienst abgestimmt. |
| Lesen Sie auch Verwalten von Azure Cache for Redis. | Erfahren Sie, wie Datenverluste bei Neustarts des Caches auftreten können und wie Sie die Anwendung auf Resilienz testen. |
Quellartefakte
Verwenden Sie die folgende Abfrage, um Redis-Instanzen zu identifizieren, für die nicht der Premium-Tarif verwendet wird:
Resources
| where type == 'microsoft.cache/redis'
| where properties.sku.name != 'Premium'