Architektur von MariaDB

STACKIT MariaDB bietet ein vollständig verwaltetes Self-Service-Deployment von MariaDB mit flexibler Dimensionierung, Hochverfügbarkeit, automatisierten Sicherungen und dem Klonen von Instanzen. So wird es implementiert:

Eine Instanz wird durch ihren Typ, die Anzahl der vCPUs, den Speicher, den zugrunde liegenden Speicher und das Networking definiert. Mehr darüber erfahren Sie unter Instanzen für MariaDB erstellen und verwalten.

Instanzebene

Auf der Instanzebene definieren Sie, auf wie vielen Knoten Ihre Instanz läuft. Die Eigenschaft Typ legt fest, ob es sich bei einer Instanz um eine Einzelinstanz oder ein Replica Set handelt. Ein Replica Set besteht aus 3 Knoten für die Ausfallsicherheit in der Produktion und ist als Galera Cluster implementiert. Alle drei Knoten sind ein vollständiges Abbild voneinander und agieren als Active-Active. Unter Cluster-Setup finden Sie Einzelheiten zur Implementierung der Hochverfügbarkeit bei STACKIT. STACKIT bezeichnet die Skalierung auf dieser Ebene als horizontale Skalierung.

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

Knotenebene

Auf der Knotenebene steuern Sie die Größe jedes Knotens in der Instanz und seines Speichers. Ein Knoten ist durch die Anzahl seiner vCPUs, seinen Speicher und den mit ihm verbundenen Speicher gekennzeichnet. STACKIT bezeichnet die Skalierung auf dieser Ebene als vertikale Skalierung.

Bei STACKIT MariaDB wird die Anzahl der vCPUs, die Größe des Speichers und der Festplatte durch einen Plan bestimmt. Unter Servicepläne finden Sie alle verfügbaren Pläne.

Ihre Instanz hat eine Downtime, nachdem Sie einen Parameter außer der ACL und dem Festplattenschwellenwert geändert haben.

Netzwerk

Jede Instanz hat ihren eigenen Hostnamen und eine IPv4-Adresse. Standardmäßig ist sie nur aus vordefinierten STACKIT Adressbereichen erreichbar. Mit dem Parameter ACL können Sie benutzerdefinierte IPv4-Einzeladressen und -bereiche hinzufügen, von denen aus die Instanz erreichbar sein soll.

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 14 Tage lang aufbewahrt.

Monitoring und Observability

Jeder bestellte Dienst kann über einen Observability-Dienst überwacht werden. Um das Monitoring für Ihre MariaDB-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 MariaDB FAQ unter der Frage „Welcher STACKIT Observability-Tarif ist für die MariaDB-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
• Überwachung von Performance-Metriken und Logs
• Wiederherstellen von Sicherungen

Trennung des Deployments

MariaDB-Dienste, die über Cloud Foundry erstellt wurden, und solche, die über das STACKIT Portal/CLI erstellt wurden, sind vollständig getrennt. Dienste, die in einer Umgebung erstellt wurden, 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/CLI erstellt wurden, müssen auch im STACKIT Portal/CLI verwaltet/gelöscht werden. Im STACKIT Portal werden eventuell einige (nicht alle) Dienste angezeigt, die mit Cloud Foundry erstellt wurden (insbes. 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/CLI erstellt und müssen von dort aus verwaltet werden, auch wenn in Cloud Foundry Verwaltungsoptionen angezeigt werden. Aus technischen Gründen ist es nicht möglich, einen Dienst in Cloud Foundry zu erstellen und über das STACKIT Portal/CLI zu löschen oder umgekehrt.