Es empfiehlt sich, einen Plan zu erstellen, bevor Sie Ihre Anwendung entwickeln. Beginnen Sie damit, die primären Geschäftsziele zu definieren, Anforderungen zu sammeln, einen potenziellen Technologie-Stack zu evaluieren und Integrationen zu verstehen. Am Ende des Prozesses sollten Sie einen Überblick über die Referenzarchitektur Ihrer Anwendung haben, die als Blaupause für die Implementierung der Komponenten Ihrer Infrastruktur dient und definiert, wie Daten zwischen diesen Komponenten fließen.
In diesem Beispiel wird ein Datenbankdesign mit Galera for MySQL und MariaDB überprüft. Datenbanken sind geschäftskritische Komponenten vieler Anwendungen. Dieses wertvolle Gut ist auf Redundanz angewiesen, um die Arbeitslast aufrechtzuerhalten. Ein einziger Ausfallpunkt kann sich negativ auf den Geschäftsbetrieb, die Betriebszeitvereinbarungen und die allgemeine Benutzerfreundlichkeit auswirken.
Anhand von Referenzarchitekturen können Sie belastbare Datenbank- und Anwendungsimplementierungen erstellen, die horizontal (ohne Ausfallzeiten) skalierbar sind, wenn Ihr Unternehmen wächst.
Was ist eine Referenzarchitektur?
Referenzarchitekturen sind wiederverwendbare technische Diagramme, die allgemeine Designprinzipien und branchenübliche Best Practices für die Implementierung von Lösungen enthalten. Eine stark abstrahierte Cloud-Referenzarchitektur zeigt die Verbindungen zwischen den verschiedenen Recheninstanzen, Load Balancern, Speichern, softwaredefinierten Netzwerken usw. - der Wert Ihrer Datenbanken macht dies zu einem zentralen Bereich.
Datenbanken & Referenzarchitektur
Das Hauptziel besteht darin, Redundanz hinzuzufügen und zu verhindern, dass die Datenbank ein Single Point of Failure ist. Es gibt verschiedene Möglichkeiten, dieses Ziel zu erreichen, je nach den Einschränkungen der Anwendung und der Arbeitslast. So kann eine Anwendung beispielsweise besser abschneiden, wenn Lese- und Schreibvorgänge in einem primär-sekundären Replikationsmodell aufgeteilt werden. Für die Skalierung von Schreibvorgängen wäre eine Strategie mit mehreren Primaries erforderlich.
Weitere Überlegungen betreffen das Datenvolumen, die ACID-Konformität, das Failover-/Auswahlverfahren (manuell oder automatisch), die erwartete Anzahl von Client-Verbindungen und die gewählte Datenbanktechnologie. Diese Überlegungen prägen die Datenbanklösung und bilden das Gesamtbild, wie diese Teile in Ihrer Referenzarchitektur zusammenwirken.
Wann ist Galera zu verwenden?
Galera ist eine kostenlose und quelloffene Hochverfügbarkeits-Datenbanklösung, die einfach zu verwalten ist und nicht von einem einzigen Cloudanbieter abhängt. Wenn Ihre Datenbanktechnologie MySQL oder eine seiner Abspaltungen wie MariaDB oder Percona ist, empfehlen wir Galera als dauerhafte und portable Lösung.
Galera Cluster Vorteile
- Knotenausfälle - Verhindert Split-Brain-Bedingungen, indem ein gewichtetes Quorum zur Wahl einer primären Komponente im Falle von Knotenausfällen aufgerufen wird.
- Multi-Primary, Active-Active Cluster - Lesen und Schreiben auf jedem Knoten im Cluster.
- Datenkonsistenz - Verwendet eine zertifizierungsbasierte synchrone Replikation, um die ACID-Konformität zu gewährleisten.
- Automatische Knotenbereitstellung - Wenn ausgefallene Knoten wiederhergestellt werden oder wenn neue Knoten dem Cluster beitreten, werden sie automatisch mit dem Zustand der primären Komponente synchronisiert, indem State Snapshot Transfers (SST) oder Incremental State Transfers (IST) verwendet werden.
Galera Cluster Beschränkungen
- Keine MyISAM-Unterstützung - unterstützt nur die InnoDB-Engine. Schreibvorgänge in andere Tabellentypen, einschließlich Systemtabellen, werden nicht repliziert.
- Tabellenformatierung - Tabellen ohne Primärschlüssel können nicht gelöscht oder ordnungsgemäß repliziert werden.
- Logische Überlegungen - Die Anwendungslogik muss möglicherweise umgeschrieben werden, um die Verwendung von expliziten Tabellensperren zu vermeiden.
- Skalierbarkeit beim Schreiben - Alle Knoten müssen vor dem Commit bestätigen, dass sie schreiben können, daher nimmt die Schreibleistung ab, wenn der Cluster wächst. Wir empfehlen, die Größe des Clusters auf drei Knoten zu beschränken, um ein Quorum und eine optimale Schreibleistung zu gewährleisten.
Eliminieren Sie einzelne Fehlerquellen
Nehmen wir das Beispiel eines herkömmlichen LEMP-Stacks, bei dem die Anwendungssoftware und die Datenbank in Vorbereitung auf eine künftige Skalierung in verschiedene Recheninstanzen aufgeteilt wurden. Diese Konfiguration könnte wie folgt aussehen:
Die Trennung von Belangen ist ein bewährtes Verfahren und trägt zweifellos zur Skalierbarkeit bei, aber die fehlende Redundanz macht sowohl die Datenbank als auch die Anwendungsserver zu einem Single Point of Failure. Wir können diese Struktur verbessern, um diese Schwachstellen zu beseitigen und die gesamte Referenzarchitektur aufzubauen.
Einfache Galera-Cluster-Einrichtung mit VLAN & Cloud Firewalls
Ein Galera-Cluster erhöht die Datenbankebene auf drei Knoten mit synchroner Replikation zwischen ihnen. Wir können eine Linode VLAN verwenden, um den Replikationsverkehr von öffentlichen und gemeinsam genutzten privaten Netzwerken zu isolieren, und eine Cloud Firewall , um den Zugriff von außerhalb des VLAN zu beschränken. Die Galera-Knoten teilen sich eine schwebende IP-Adresse, so dass bei einem Ausfall eines Knotens ein anderer in der Lage ist, die Bedienung von Anfragen an den unwissenden Anwendungsserver zu übernehmen.
Die Datenbankschicht ist nun hochverfügbar. Als nächstes muss der Anwendungsserver angesprochen werden. Dieser Prozess ist einfach für zustandslos Anwendungen, aber zusätzliche Überlegungen müssen für Anwendungen angestellt werden, die zustandsabhängig. Je nachdem, wie der Status verwaltet wird, müssen Sie möglicherweise den Code umstrukturieren und/oder eine Dateireplikation mit Tools wie Unison oder Gluster implementieren. Für dieses Beispiel wird angenommen, dass der Anwendungsstatus mit Ausnahme der temporären Sitzungsdateien von der Datenbank verwaltet wird.
Lastausgleich und Anwendungsreplikation
Der Lastausgleich sorgt für eine hohe Verfügbarkeit und horizontale Skalierbarkeit Ihrer Anwendung, aber eine einzige Load Balancer-Instanz stellt auch einen einzigen Ausfallpunkt dar. Redundanz bleibt eine kritische Komponente dieser Implementierung. Linode NodeBalancers bietet eine hochverfügbare, sofort einsatzbereite Lösung zur Erleichterung der Session-Stickiness, der Zustandsüberwachung und der Verteilung von Client-Anfragen an eine Reihe von Backend-Anwendungs-Knoten.
Wenn ein Anwendungsserver ausfällt, leitet der NodeBalancer den Verkehr nur noch an den gesunden Knoten weiter. Sobald sich der kranke Knoten erholt hat, werden die Verbindungen wieder wie zuvor ausgeglichen. Dies erleichtert das Hinzufügen, Entfernen oder Aktualisieren von Anwendungsservern ohne Ausfallzeiten, und aufgrund der aktiv-aktiven Lösung von Galera kann jeder Anwendungsknoten auf jeden Datenbankknoten lesen/schreiben.
Linode's Solutions Engineering Team stellt Frameworks, Leitfäden und Tools wie dieses zur Verfügung, um Anwendungen mit Best Practices im Hinterkopf zu entwickeln. Lesen Sie mehr über die Hochverfügbarkeitsvorteile von Galera-Clustern. Wenn Sie bereit sind, mit der Entwicklung auf Linode zu beginnen, lesen Sie unseren Leitfaden zur Einrichtung von MariaDB-Clustern mit Galeria, Debian und Ubuntu.
Kommentare