Bereitstellen eines Valkey-Clusters auf Azure Kubernetes Service (AKS)

In diesem Artikel überprüfen wir die Herausforderungen der ordnungsgemäßen Verwendung von Azure-Verfügbarkeitszonen beim Ausführen eines Valkey-Clusters auf AKS, teilen einige Überlegungen zur Skalierung und schlagen eine Lösung vor.

Wichtig

Open-Source-Software wird überall in AKS-Dokumenten und -Beispielen erwähnt. Software, die Sie bereitstellen, ist von AKS-Vereinbarungen zum Servicelevel, der eingeschränkten Garantie und dem Azure-Support ausgeschlossen. Wenn Sie Open-Source-Technologie zusammen mit AKS nutzen, nutzen Sie die Supportoptionen, die von den jeweiligen Communitys und Projektbetreuenden angeboten werden, um einen Plan zu entwickeln.

Das GitHub-Repository von Ray beschreibt z. B. mehrere Plattformen, die in Antwortzeit, Zweck und Supportebene variieren.

Microsoft übernimmt die Verantwortung für die Erstellung der Open-Source-Pakete, die wir in AKS bereitstellen. Diese Verantwortung schließt den vollständigen Besitz des Build-, Scan-, Signatur-, Validierungs- und Hotfixprozesses sowie die Kontrolle über die Binärdateien in Containerimages ein. Weitere Informationen finden Sie unter Sicherheitsrisikomanagement für AKS und AKS-Supportabdeckung.

Was ist Valkey?

Valkey ist eine Verzweigung des Redis-Projekts, das seine ursprüngliche Open-Source-Lizenz behält. Valkey ist eine Hochleistungsdatenbank, die einen Key-Value-Datenspeicher unterstützt und die Sie für Caching, Sitzungsspeicher, Nachrichtenwarteschlangen und vieles mehr verwenden können. Ein Valkey-Cluster verfügt über mehrere Knoten, die für das Hosten Ihrer Valkey-Datenspeicher verantwortlich sind. Valkey teilt die Daten in kleinere Portionen auf und verteilt sie auf die Knotenpunkte. In einem vereinfachten Valkey-Cluster, der aus drei primären Knoten besteht, unterstützt ein einzelner Replikatknoten jeden Knoten, um grundlegende Failoverfunktionen zu ermöglichen. Die Daten werden über die Knoten verteilt, sodass der Cluster weiterhin funktioniert, auch wenn einer der Knoten fehlschlägt.

Weitere Informationen finden Sie in der Valkey-Dokumentation.

Übersicht über die Valkey-Lösung

Ziel dieser Lösung ist die Bereitstellung von Valkey auf AKS mit der gleichen Serviceebene wie der Azure Cache für Redis Premium-Stufe.

In der folgenden Tabelle sind die wichtigsten Features der Azure Cache für Redis Premium-Stufe und die vorgeschlagene Valkey-Lösung aufgeführt:

Azure Cache für Redis Premium-Stufe	Valkey-Lösung
Arbeitsspeicher bis zu 1,2 TB	Verwenden von drei Valkey-Primärdateien, die auf der Standard_E64_v5-SKU ausgeführt werden.
Replikation	Hinzufügen mindestens eines Replikat-Pod pro primärem Pod.
Zonenredundanz	Platzieren von primären und Replikat-Pods in verschiedenen Verfügbarkeitszonen.

Wir erstellen zwei unterschiedliche StatefulSet Ressourcen: eine für die Valkey-Primärdateien und eine für die Replikate. Die spec.affinity der StatefulSet-API platziert die primären Pods in zwei unterschiedlichen Verfügbarkeitszonen und die Replikat-Pods in einer anderen, dritten, Verfügbarkeitszone. Dieser Ansatz stellt sicher, dass sich ein einzelner Zonenfehler nicht auf die Verfügbarkeit eines Valkey-Shards auswirkt.

Hinweis

Beachten Sie, dass sich die in diesem Artikel vorgeschlagene Lösung von der Valkey-Dokumentation unterscheidet, in der Cluster-Pods zu einem einzelnen StatefulSetgehören, und die spec.affinity nur sicherstellen, dass die Pods auf verschiedenen Knoten platziert werden. Die in der Valkey-Dokumentation dargestellte automatische Valkey-Clusterinitialisierung stellt nicht sicher, dass die primären und Replikat-Pods für denselben Shard in verschiedenen Verfügbarkeitszonen platziert werden.

Nächste Schritte

Erstellen der Infrastrukturressourcen zum Ausführen eines Valkey-Clusters auf AKS

Beitragende

Microsoft pflegt diesen Artikel. Die folgenden Mitwirkenden haben es ursprünglich geschrieben:

• Nelly Kiboi | Servicetechnikerin
• Saverio Proto | Principal Customer Experience Engineer
• Don High | Principal Customer Engineer
• LaBrina Loving | Principal Service Engineer
• Ken Kilty | Principal TPM
• Russell de Pina | Principal TPM
• Colin Mixon | Produktmanager
• Ketan Chawda | Senior Customer Engineer
• Naveed Kharadi | Customer Experience Engineer
• Erin Schaffer | Content Developer 2