Azure Cache for Redis und optimaler Betrieb
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 für Anwendungen Datenzugriff mit hohem Durchsatz und geringer Wartezeit ermöglicht.
Bewährte Methoden zur Erzielung des optimalen Betriebs:
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 auszufü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 des optimalen Betriebs konfiguriert?
- Planen von Updates
- Überwachen Sie den Cache, und legen Sie Warnungen fest.
- Stellen Sie den Cache in einem VNET bereit.
- Verwenden Sie den richtigen Cachetyp (lokal, In-Role, verwaltet, Redis) in Ihrer Lösung.
- Konfigurieren Sie je nach geschäftlicher Anforderung die Datenpersistenz, um eine Kopie des Caches in Azure Storage zu speichern, oder verwenden Sie die Georeplikation.
- 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 zur Optimierung Ihrer Azure Cache for Redis-Konfiguration in Bezug auf den optimalen Betrieb:
| 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 ein ausreichend großer Adressraum für die Bereitstellung der Cacheknoten und Shards (Cluster) verfügbar ist. |
| Verwenden Sie den richtigen Cachetyp (lokal, In-Role, verwaltet, Redis) in Ihrer Lösung. | Verteilte Anwendungen stellen für das Zwischenspeichern von Daten meist eine oder beide der folgenden Strategien bereit: - Verwenden eines privaten Caches, in dem Daten lokal auf dem Computer gespeichert werden, auf dem eine Instanz der Anwendung oder des Diensts ausgeführt wird. - Verwenden eines freigegebenen Caches, der als gemeinsame Datenquelle für mehrere Prozesse und Computer dient. In beiden Fällen kann Zwischenspeichern vom Client und Server ausgeführt werden. Clientseitiges Zwischenspeichern erfolgt durch den Prozess, der die Benutzeroberfläche für ein System, z. B. einen Webbrowser oder eine Desktopanwendung, bereitstellt. Serverseitiges Zwischenspeichern erfolgt durch den Prozess, der Unternehmensdienste bereitstellt, die remote ausgeführt werden. |
| Konfigurieren Sie je nach geschäftlicher Anforderung die Datenpersistenz, um eine Kopie des Caches in Azure Storage zu speichern, oder verwenden Sie die Georeplikation. | 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. |
| 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'