Architektur von Redis

STACKIT Redis bietet ein vollständig verwaltetes Self-Service-Deployment von Redis mit flexibler Dimensionierung, Hochverfügbarkeit, automatisierten Sicherungen und Klonen von Instanzen. Es ist folgendermaßen implementiert:

Eine Instanz wird durch ihren Typ, die Anzahl der vCPUs, dem Speicher, dem zugrunde liegenden Massenspeicher und die Vernetzung definiert. Mehr darüber erfahren Sie unter Erstellen und Verwalten von Instanzen.

Instanzebene

Auf der Instanzebene legen Sie fest, auf wie vielen Knoten Ihre Instanz läuft. Die Eigenschaft Typ definiert, ob es sich bei einer Instanz um eine Einzelinstanz oder einen Replikasatz handelt. Ein Replikasatz besteht aus 3 Knoten für die Ausfallsicherheit in der Produktion und ist als Cluster implementiert. Alle drei Knoten sind also eine vollständige Spiegelung voneinander und agieren als Active-Active. STACKIT bezeichnet die Skalierung auf dieser Ebene als horizontale Skalierung.

Sie können den Typ nach dem Erstellen Ihrer Instanz nicht mehr ändern.

Knotenebene (Node-Ebene)

Auf der Knotenebene steuern Sie, wie jeder Knoten in der Instanz und sein Speicher dimensioniert sind. Ein Knoten ist durch seine Anzahl an vCPUs, seinen Speicher und den damit verbundenen Massenspeicher gekennzeichnet. STACKIT bezeichnet die Skalierung auf dieser Ebene als vertikale Skalierung.

Bei Redis wird die Anzahl der vCPUs, die Größe des Speichers und des Massenspeichers durch einen Plan bestimmt. Unter Servicepläne finden Sie eine Referenz über alle verfügbaren Pläne.

Ihre Instanz wird nach der Änderung eines beliebigen Parameters, außer ACL und Disk-Threshold, eine Downtime haben.

Vernetzung

Jede Instanz hat einen eigenen Hostnamen und eine IPv4-Adresse. Standardmäßig ist sie nur aus vordefinierten STACKIT Adressbereichen erreichbar. Mit dem ACL-Bereichs-IP-Parameter können Sie benutzerdefinierte IPv4-Einzeladressen und -Bereiche hinzufügen, von denen aus die Instanz erreicht werden kann.

Sicherung

Sie verwalten Ihre Sicherungen auf der Instanzebene. Das System erstellt alle 4 Stunden eine Sicherung. Unabhängig davon können Sie auch jederzeit manuelle Sicherungen planen. Alle Sicherungen werden für 14 Tage aufbewahrt.

Monitoring und Observability

Jeder bestellte Dienst kann über einen Observability-Dienst überwacht werden. Um das Monitoring für Ihre Redis-Instanz zu aktivieren, müssen Sie bei der Bereitstellung oder über ein Update Ihre Observability-Instanz-ID (monitoring_instance_id) angeben und den Parameter enable_monitoring auf true setzen.

Stellen Sie sicher, dass Sie einen unterstützten Tarif verwenden: Ihre STACKIT Observability-Instanz muss einen Tarif mit ausreichender Kapazität zum Speichern von Metriken haben. Eine detaillierte Liste der unterstützten Tarife finden Sie in den Redis FAQ unter der Frage „Welcher STACKIT Observability-Tarif ist für die Redis-Integration erforderlich?”

Nach dem Anwenden der Änderungen verwendet der Service Broker die Observability-API, um die Instanz zu registrieren. Der Wrapper erstellt Zugangsdaten für die maschinelle Kommunikation (sichtbar als Service Key mit dem Präfix monitoring_), die ausschließlich von Observability für das Monitoring verwendet werden. Die Verbindungs-URL wird sicher an die Observability-Instanz übertragen.

Auf der Observability-Seite verwendet Telegraf diese Zugangsdaten, um sicher auf Ihre Datenbank zuzugreifen und die Metriken abzurufen. Sie können dann Metriken, die mit dem entsprechenden Dienst versehen sind, aus Ihrer Thanos-Quelle direkt im Grafana-Dashboard Ihrer Observability-Instanz sehen.

Verwaltung

• Sie verwalten Instanzen mit dem STACKIT Portal, der STACKIT CLI, den STACKIT APIs, Terraform oder Cloud Foundry:
  • Bereitstellen neuer Instanzen
  • Ändern von Instanzen
  • Monitoring von Performance-Metriken und Logs
  • Wiederherstellen von Sicherungen

Trennung des Deployments

RabbitMQ-Dienste, die über Cloud Foundry erstellt wurden, und solche, die über das STACKIT Portal/die CLI erstellt wurden, sind vollständig getrennt. In einer Umgebung erstellte Dienste müssen in derselben Umgebung verwaltet und gelöscht werden – eine umgebungsübergreifende Verwaltung wird aus technischen Gründen nicht unterstützt.

Dienste müssen immer in der Umgebung verwaltet werden, in der sie erstellt wurden.

• Dienste, die im STACKIT Portal/in der CLI erstellt wurden, müssen auch im STACKIT Portal/in der CLI verwaltet/gelöscht werden. Im STACKIT Portal werden eventuell einige (nicht alle) Dienste angezeigt, die mit Cloud Foundry erstellt wurden (insb. die Flex-Datenbanken).
• Dienste, die mit Cloud Foundry erstellt wurden, müssen mit Cloud Foundry verwaltet/gelöscht werden.

Dienste, die in Cloud Foundry als Teil einer Organisation mit dem Präfix stackit_portal_prod_ angezeigt werden, wurden über das STACKIT Portal/die CLI erstellt und müssen von dort aus verwaltet werden, auch wenn Verwaltungsoptionen in Cloud Foundry angezeigt werden. Aus technischen Gründen ist es nicht möglich, einen Dienst in Cloud Foundry zu erstellen und ihn über das STACKIT Portal/die CLI zu löschen oder umgekehrt.