Azure Cache for Redis zu STACKIT Valkey: Schritt für Schritt

Der Ablauf im Überblick

1. 01

   1. Die Caches in Terraform beschreiben

   Die Demo enthält ein virtuelles Netzwerk, ein Subnetz und zwei azurerm_redis_cache-Ressourcen: redis-shop-ratelimit (Standard, Familie C) und redis-shop-sessions (Premium, zwei Shards, zwei Zonen, RDB-Persistenz, in das Subnetz eingebunden).

2. 02

   2. Bewerten

   Beide Caches sind RECONFIGURE mit Konfidenz MEDIUM und dem Ziel Key Value Store. Die Klasse sagt: Der Dienst hat bei STACKIT ein Gegenstück, seine Konfiguration ist aber keine Kopie.

3. 03

   3. Den Entwurf lesen

   Je Cache schreibt die Engine eine stackit_valkey_instance und ein stackit_valkey_credential sowie eine sensible Ausgabe für das erzeugte Passwort.

4. 04

   4. Variablen füllen

   Planname, Valkey-Version und die Liste erlaubter Client-CIDRs sind Variablen ohne Standardwert. Die CIDR-Liste hat eine Validierung, die eine leere Liste ablehnt.

5. 05

   5. Entscheiden, was kein Gegenstück hat

   Sharding, rein privater Zugriff und das genaue Eviction-Verhalten sind Entscheidungen Ihrer Architekten, aufgeführt im Architektenbericht.

6. 06

   6. Die Daten planen

   Caches werden meist neu aufgebaut. Müssen die Daten mit, führt die Datei zum Datenumzug die Einheit auf und lässt das Verfahren offen.

Ein Standard-Cache wird zur Valkey-Instanz

Links: der Standard-Cache wie geschrieben. Rechts: die Blöcke des STACKIT-Terraform, das die Engine dafür geschrieben hat, ohne die Prüfkommentare, die in der Datei darüber stehen.

resource "azurerm_redis_cache" "ratelimit" {
  name                = "redis-shop-ratelimit"
  location            = azurerm_resource_group.cache.location
  resource_group_name = azurerm_resource_group.cache.name
  capacity            = 1
  family              = "C"
  sku_name            = "Standard"
  minimum_tls_version = "1.2"
}

resource "stackit_valkey_instance" "ratelimit" {
  project_id = var.project_id
  name       = "redis-shop-ratelimit"
  plan_name  = var.ratelimit_plan_name
  version    = var.ratelimit_version
  parameters = {
    sgw_acl = join(",", var.ratelimit_allowed_cidrs)
  }
}

resource "stackit_valkey_credential" "ratelimit" {
  project_id  = var.project_id
  instance_id = stackit_valkey_instance.ratelimit.instance_id
}

output "ratelimit_valkey_credential_password" {
  description = "The password STACKIT generated for the credential stackit_valkey_credential.ratelimit of azurerm_redis_cache.ratelimit. Sensitive: tofu output hides it from the plan, the state holds it in plain text."
  value       = stackit_valkey_credential.ratelimit.password
  sensitive   = true
}

• Größe und Familie werden nicht übernommen

  Kapazität 1 der Familie C wird nicht in einen Plan übersetzt. Der Entwurf führt plan_name als Variable und sagt, dass die Cache-Größe Ihre Wahl ist. Die Stufe zeigt, dass am Ziel ein Replica-Plan nötig ist, denn Hochverfügbarkeit ist bei STACKIT eine Frage des Plans.

• Die Zugriffsliste ersetzt die Netzwerkgrenze

  Die Variable für erlaubte CIDRs hat keinen Standardwert. Ohne Liste gilt bei STACKIT die Standard-Zugriffsliste, die Adressbereiche von STACKIT-Kunden allgemein umfasst. Der Entwurf lehnt deshalb eine leere Liste ab.

• Das Passwort wird erzeugt

  Die Credential-Ressource liefert Host, Port, Benutzer und Passwort. Der Entwurf gibt das Passwort nur als sensible Ausgabe frei und legt kein Secret dafür an: Sie lesen es nach dem Apply aus und geben es vor dem Cutover an die Clients.

Ein Premium-Cache mit Shards, Zonen und Persistenz

Aus demselben Lauf. Dieser Cache setzt fast alles, wonach Ihre Architekten fragen würden. Der Zielentwurf enthält Instanz, Zugriffsliste und Credential; was mit dem Rest geschieht, zeigt die Tabelle darunter.

resource "azurerm_redis_cache" "sessions" {
  name                          = "redis-shop-sessions"
  location                      = azurerm_resource_group.cache.location
  resource_group_name           = azurerm_resource_group.cache.name
  capacity                      = 1
  family                        = "P"
  sku_name                      = "Premium"
  non_ssl_port_enabled          = false
  minimum_tls_version           = "1.2"
  public_network_access_enabled = false
  subnet_id                     = azurerm_subnet.cache.id
  shard_count                   = 2
  zones                         = ["1", "2"]

  redis_configuration {
    maxmemory_policy      = "allkeys-lru"
    rdb_backup_enabled    = true
    rdb_backup_frequency  = 60
    rdb_backup_max_snapshot_count = 1
    rdb_storage_connection_string = var.rdb_connection_string
  }
}

resource "stackit_valkey_instance" "sessions" {
  project_id = var.project_id
  name       = "redis-shop-sessions"
  plan_name  = var.sessions_plan_name
  version    = var.sessions_version
  parameters = {
    sgw_acl = join(",", var.sessions_allowed_cidrs)
  }
}

resource "stackit_valkey_credential" "sessions" {
  project_id  = var.project_id
  instance_id = stackit_valkey_instance.sessions.instance_id
}

• Zehn offene Punkte bei einem Cache

  Der Architektenbericht überlässt für diesen Cache 10 kritische Punkte einer Person (dahinter stehen 12 Quell-Eigenschaften: Erreichbarkeit, Backup-Einstellungen, maxmemory-Richtlinie, Shard-Anzahl, SKU, Zonen, die Backup-Verbindungszeichenfolge, Standort, Name und Ressourcengruppe); beim Standard-Cache sind es 4. In diesem Unterschied steckt der Prüfaufwand.

• Aus „nur privat“ wird eine Zugriffsliste

  Eine Valkey-Instanz liegt nicht im Projektnetzwerk. Sie hat einen eigenen Hostnamen und eine eigene IPv4-Adresse und ist aus STACKIT-Adressbereichen und aus allem erreichbar, was Sie der Zugriffsliste hinzufügen. Der Bericht rät, sie auf die Ausgangsadressen der Anwendung zu verengen und nie für alle Adressen zu öffnen.

• Persistenz steht nicht im Block

  Der Bericht rät, die Snapshot-Frequenz in den Snapshot-Parameter zu übernehmen, doch der entworfene Block setzt nur die Zugriffsliste. Ergänzen Sie den Parameter von Hand, nachdem Sie die Frequenz gewählt haben.

Was aus den Azure-Redis-Einstellungen wird

Linke Spalte aus der Demo-Eingabe, mittlere aus der Dokumentation des STACKIT Key Value Store und dem Architektenbericht des Laufs, rechte aus dem Lauf.

Prüfungen, bevor sich der erste Client verbindet

• Replica-Plan, wo die Quelle Replikate hatte

  STACKIT beschreibt Single-Instanzen als nicht für den Produktivbetrieb gedacht, und der Instanztyp lässt sich später nicht ändern.

• Valkey-Version passt zu den Client-Bibliotheken

  STACKIT rät, die neueste Version zu wählen, die Ihre Clients unterstützen; schon kleine Versionsunterschiede können manche Clients an der Verbindung hindern.

• Zugriffsliste ist eng

  Nur die Ausgangsadressen der Anwendungen, nie 0.0.0.0/0.

• Clients nutzen TLS

  Verbindungszeichenfolgen beginnen mit rediss://, der Host stammt aus dem Credential.

• Eviction- und Ablaufverhalten ist getestet

  Die maxmemory-Richtlinie der Quelle ist eine offene Einstellung. Testen Sie das Cache-Verhalten der Anwendung unter Speicherdruck vor dem Cutover.

• Admin-Befehle sind ausprobiert

  Ein Kommentar im Entwurf vermerkt, dass bei einem Test in einem STACKIT-Projekt der Befehl CONFIG für einen Service-Key abgelehnt wurde. Verlässt sich ein Client oder Werkzeug darauf, klären Sie das vor dem Cutover.

Die Daten mitnehmen, oder nicht

Der Lauf führt beide Caches als zustandsbehaftete Einheiten mit unbekanntem Verfahren. Er überträgt nichts.

1. 01

   Neu aufbauen, wenn möglich

   Session- und Rate-Limit-Daten sind meist kurzlebig. Die Begründung der Zuordnung beider Einheiten sagt, dass Cache-Daten üblicherweise neu aufgebaut statt migriert werden. Lassen Sie den Verkehr die neue Instanz füllen.

2. 02

   Export aus Azure

   Import und Export von RDB-Snapshots gibt es bei Azure für die Stufen Premium und Enterprise, nicht für Basic und Standard. Der Standard-Cache der Demo hat keinen solchen Export; der Premium-Cache exportiert in einen Page Blob eines Storage Accounts.

3. 03

   Wiederherstellung bei STACKIT

   Die verwaltete Wiederherstellung von STACKIT zielt auf dieselbe Instanz und überschreibt sie. Um einen Snapshot in eine andere Instanz zu laden, laden Sie das Backup herunter, wofür ein Verschlüsselungsschlüssel nötig ist, und stellen es selbst wieder her.

4. 04

   Schlüssel live kopieren

   STACKIT veröffentlicht eine Anleitung, die Schlüssel kopiert, indem sie MIGRATE auf der Quelle ausführt; die Quelle schiebt sie direkt zum Ziel, geprüft wird mit INFO KEYSPACE und einem sortierten Schlüsselvergleich. Im Schnitt nennt sie etwa 50 Sekunden je GB. Von Azure aus funktioniert dieser Weg nicht: Microsoft führt MIGRATE unter den Befehlen, die Azure Cache for Redis sperrt. Für den Premium-Cache exportieren Sie stattdessen eine RDB-Datei; beim Standard-Cache bauen Sie neu auf oder kopieren mit einem clientseitigen Werkzeug.

5. 05

   Umstellen

   Schreibzugriffe auf die Quelle stoppen, kopieren, prüfen, Verbindungszeichenfolgen umstellen und die Quelle behalten, bis die Prüfungen bestanden sind. Diese Reihenfolge ist allgemeine Praxis, keine Ausgabe des Laufs.

Entscheidungen Ihrer Architekten

• Plan je Cache

  Single oder Replica, vCPU, RAM und Disk, aus tatsächlicher Datenmenge und Last. Die STACKIT-Planungsseite nennt für den RAM mindestens 125 % der Datenmenge und für die Disk etwa das Dreifache der Datenmenge, und ein Plan lässt sich vergrößern, aber nicht verkleinern.

• Sharding des Keyspace

  Entweder passt der Keyspace auf einen Primary, oder die Anwendung verteilt ihn auf mehrere Instanzen.

• Persistenz

  Snapshot-Frequenz, und ob eine Backup-Wiederherstellung ein Wiederanlaufpfad ist, auf den Sie sich verlassen.

• Erreichbarkeit

  Welche CIDRs die Instanz erreichen, und ob das für einen bisher privaten Cache vertretbar ist.

• Zeitpunkt

  Microsoft hat einen Auslaufplan für Azure Cache for Redis angekündigt und empfiehlt Azure Managed Redis. Ob der Weg direkt zu STACKIT führt, ist eine Plattformentscheidung, keine Cache-Einstellung.

Fragen zum Wechsel von Redis zu Valkey

Quellen

• Microsoft Learn: Daten in Azure Cache for Redis importieren und exportieren
• STACKIT-Dokumentation: Daten in eine neue Instanz migrieren (Key Value Store)
• STACKIT-Dokumentation: Instanzen sichern und wiederherstellen (Key Value Store)
• STACKIT-Dokumentation: Instanz planen (Key Value Store)
• Microsoft Learn: Azure Cache for Redis konfigurieren
• STACKIT-Dokumentation: Service-Pläne (Key Value Store)