Entwicklung einer zuverlässigen Datenbank für die Certification Authority von Fastly
Bei diesem Blogpost handelt es sich um den letzten Teil einer Reihe von Beiträgen, die sich mit der Entwicklung von Certainly, der neuen, vertrauenswürdigen Certification Authority (CA) von Fastly, befassen. Über die architektonischen Entscheidungen, die bei der Entwicklung von Certainly getroffen werden mussten, haben wir ja bereits berichtet. Heute möchten wir uns genauer mit einer der größten Herausforderungen bei der Erstellung einer cloudähnlichen, kurzlebigen Umgebung befassen, in der Systeme regelmäßig und automatisch zerstört und neu zusammengefügt werden.
Wie bei jeder anderen CA bildet auch bei Certainly eine robuste, zuverlässige und widerstandsfähige Datenbank das Herzstück aller Abläufe. Die gut durchdachte Datenbankarchitektur von Certainly ermöglicht eine effiziente Speicherung und Abfrage von Zertifikatsdaten und bietet Skalierungsmöglichkeiten, um den wachsenden Ansprüchen von Unternehmen gerecht zu werden. Wir nutzen derzeit MariaDB in Verbindung mit der Datenbank-Engine InnoDB und einer aktiven Replikation zwischen den verschiedenen Rechenzentren. Die Replikation hilft uns, Datenredundanz zu erreichen, und gibt uns die Sicherheit, dass wir die Daten im Katastrophenfall problemlos wiederherstellen können. Dies war allerdings nicht immer der Fall. Vor der Einführung der Replikation mit MariaDB verließen wir uns auf das MariaDB Galera Cluster-Setup, das sich aber als mühsam, aufwendig und instabil erwies. Wir waren täglich mit neuen Problemen konfrontiert, die schließlich den Umstieg auf die Replikationsfunktion von MariaDB erforderlich machten. Hier einige Vorteile dieser Entscheidung:
1. Weniger Komplexität
Die aus mehreren primären Datenbanken bestehende Architektur des Galera Clusters erforderte eine ständige Kommunikation zwischen allen Datenbankknoten an sämtlichen Standorten, um einheitliche Daten und deren Synchronisierung zu gewährleisten. Die Replikation mit MariaDB basiert hingegen auf einem einzigen Primärsystem und mehreren Replikaten. Ein einziger Datenbankknoten, der als primäre Datenbank mit Schreibzugriff fungiert, vereinfacht die Einrichtung und Wartung erheblich. Außerdem ist die Konfiguration einfacher und der operative Aufwand geringer. Die geringere Komplexität hat zu einem deutlichen Rückgang von Warnmeldungen und Problemen geführt, was die Effektivität und Motivation des Certainly SRE-Teams wiederum signifikant erhöht hat.
2. Dynamische Skalierbarkeit
Bei der Vorbereitung auf den Launch mussten wir sicherstellen, dass unsere Lösung mit wachsender Nutzerbasis ausreichend skalierbar ist. Obwohl der Galera Cluster uns eine synchrone Replikation zwischen mehreren primären Datenbanken ermöglichte, unterlag er auch Einschränkungen. Das Hinzufügen neuer Knoten zu dem bestehenden Cluster war ein komplexer und zeitaufwendiger Prozess. Im Gegensatz dazu bietet uns die Replikation mit MariaDB genügend Flexibilität, um bei Bedarf neue Replikate mit Lesezugriff hinzuzufügen, ohne den Betrieb des vorhandenen Primärsystems zu beeinträchtigen. So können wir unsere Lesevorgänge horizontal skalieren, ohne dass dies eine Belastung für das Team darstellt.
3. Replikate nach Anwendungsfall
Dank des neuen Datenbankdesigns können wir je nach Anwendungsfall zusätzliche Replikate erstellen, z. B. für Lesevorgänge, Backups, Analysen und mehr. Im Gegensatz zu Galera wirkt sich das Hinzufügen oder Entfernen von Knoten nicht mehr auf den Betrieb aus, sodass die primäre Datenbank weiterhin effizient arbeiten kann.
4. Kurzlebigkeit
Bei Certainly wird das Konzept der Kurzlebigkeit großgeschrieben. Für unsere Datenbankknoten bedeutet das, dass sie in regelmäßigen Abständen von Grund auf neu erstellt werden. Nach allgemeiner Auffassung ist das Konzept der Kurzlebigkeit ausschließlich auf zustandslose Komponenten anwendbar und sind Datenbanken für die Speicherung und Erhaltung von Daten konzipiert. Wir haben versucht, diese Sichtweise mit unserem innovativen Infrastrukturdesign, das uns mehr Agilität, Skalierbarkeit und Ausfallsicherheit bietet, zu widerlegen. Wie bereits erwähnt, müssen die Knoten von Galera ständig miteinander kommunizieren, was nicht mit der kurzlebigen Natur unserer Infrastruktur vereinbar war. So kam es während der Rebuilds häufig vor, dass Knoten den Cluster verließen und ihm wieder beitraten, was Galera zur Neuberechnung des Quorums veranlasste. Gekoppelt mit diversen bekannten Faktoren wie Backups und Netzwerkkonnektivität sowie anderen nicht identifizierten Elementen führten diese Umstände dazu, dass Galera das Quorum verlor und häufiger als erwartet heruntergefahren wurde. Und wenn die Datenbank ausfällt, dann funktioniert auch Certainly nicht. Dank des neuen Designs können wir Replikate bei Rebuilds deaktivieren, ohne uns Sorgen über negative Auswirkungen auf den primären Knoten machen zu müssen. Dadurch ist das System zweifellos robuster.
5. Mühelose Failovers
Bei der Verwaltung von Failovers kommt die Open-Source-Lösung MariaDB Orchestrator zum Einsatz. Um Orchestrator herum haben wir spezielle Tools entwickelt, die bei Bedarf Funktionstests, Fehlererkennung, die Erkennung von Leistungsabfällen und Failover ermöglichen. Orchestrator bietet einen aktuellen und genauen Überblick über die Topologie des Datenbank-Clusters, einschließlich der Rollen der einzelnen Knoten (primär oder repliziert) und ihrer Beziehungen. Diese Informationen erleichtern uns die Failover-Verwaltung und die Instandhaltung der Datenbank. Außerdem tragen sie zu weniger Datenverlusten und Abweichungen beim Failover bei.
6. Flexibilität für künftige Anwendungsfälle
Unser aktuelles Datenbankdesign bietet uns die Flexibilität, mit der sich ständig weiterentwickelnden Public-Key-Infrastruktur (PKI) zu expandieren und uns zu verändern.
Zusammenfassend lässt sich sagen, dass der Wechsel von Galera zur Replikation mit MariaDB eine wichtige Entscheidung war, die uns eine bessere Skalierung, erhöhte Performance und operative Verbesserungen eingeräumt hat. Es war eine bewusste Entscheidung, mit der wir für neue Herausforderungen gut aufgestellt sind. Wir sind überzeugt, dass wir jetzt alle Tools zur Verfügung haben, die wir brauchen, um uns weiterzuentwickeln und unsere Reichweite auf den gesamten Globus auszudehnen.
