Hybride Umgebungen, in denen sich ein Teil der Datenbankinfrastruktur lokal und ein Teil in einer Public Cloud befindet, sind keine Seltenheit. Es kann verschiedene Gründe für die Verwendung eines solchen Setups geben – Skalierbarkeit, Flexibilität, Hochverfügbarkeit, Notfallwiederherstellung. Wie kann man dieses Setup richtig implementieren? Dies kann eine Herausforderung sein, da Sie mehrere Teile eines Puzzles berücksichtigen müssen, die zusammenpassen müssen. Dieser Blog soll Ihnen einige Einblicke geben, wie ein solches Setup aussehen kann.
Konnektivität
Wir gehen hier nicht ins Detail, da es viele Möglichkeiten gibt, die Konnektivität zwischen Ihrem On-Prem-Setup und der Public Cloud einzurichten. Dies hängt von Ihrer vorhandenen Infrastruktur, der Public Cloud, die Sie verwenden möchten, und vielen anderen Faktoren ab. Eine Reihe von Optionen kann mit BGP-fähigen Routern beginnen, über Hardware-VPN, Software-VPN bis hin zu SSH-Tunneln, um Ihr Netzwerk vorübergehend mit den Instanzen in einer öffentlichen Cloud zu verbinden. Was wichtig ist, was auch immer Sie tun werden, das Endergebnis sollte eine vollständige und transparente Konnektivität von Ihrem lokalen Netzwerk zu den Instanzen sein, die sich in der öffentlichen Cloud befinden.
Überlegungen zur Hochverfügbarkeit
Die MySQL-Replikation ist eine großartige Möglichkeit, hochverfügbare Systeme zu erstellen, ist jedoch mit erheblichen Einschränkungen verbunden. Die Hauptsache, die es zu berücksichtigen gilt, ist der Schreiber – Sie können nur einen Ort haben, an den Sie Ihre Schreibarbeiten schicken können – den Meister. Egal, wie Sie die gesamte Umgebung gestalten möchten, Sie müssen sich die Platzierung des Masters genau überlegen. Höchstwahrscheinlich möchten Sie, dass es Teil der Umgebung ist, die die Anwendungshosts enthält. Betrachten wir das folgende Setup:
Wir haben ein lokales Setup mit drei MySQL-Knoten und zwei zusätzlichen Slaves sich in der öffentlichen Cloud befinden und als Disaster-Recovery-Mittel für das Unternehmen fungieren, ist es ziemlich klar, dass der beschreibbare Knoten mit den Anwendungshosts im privaten Teil der Cloud zusammengelegt werden sollte. Wir möchten die Latenz für die wichtigsten Verbindungen so gering wie möglich halten.
Diese Art von Design konzentriert sich auf die Verfügbarkeit der Datenbanken - wenn die Knoten, die sich auf Prem befinden, nicht verfügbar sind, können Anwendungshosts möglicherweise eine Verbindung zum entfernten Teil der Setup-Datenbankknoten herstellen in der öffentlichen Cloud. Idealerweise würden Sie dafür eine Art Proxy verwenden – ProxySQL ist eine der Lösungen, die die Topologie nachverfolgen und je nach Bedarf basierend auf der vorhandenen Replikationskette neu konfigurieren können.
Wenn Sie eher ein Aktiv-Aktiv-Setup in Betracht ziehen möchten, bei dem Sie sowohl private als auch öffentliche Anwendungsknoten haben, müssen Sie einige Kompromisse eingehen, da die Schreibvorgänge über das WAN übertragen werden müssen. von der öffentlichen zur privaten Cloud (oder umgekehrt, wenn Sie an Ihrem Hauptstandort in der öffentlichen Cloud arbeiten).
Auch hier ist ProxySQL der Proxy der Wahl. Was großartig ist, ProxySQL kann als ProxySQL-Cluster konfiguriert werden, wodurch sichergestellt wird, dass die in einem Knoten eingeführten Konfigurationsänderungen auf die verbleibenden ProxySQL-Knoten repliziert werden.
Fehlerbehandlung
Betrachten wir ein paar Fehlerszenarien. Vor allem müssen wir bedenken, dass die asynchrone MySQL-Replikation nicht Cluster-fähig ist, daher muss die Netzwerkaufteilung manuell gehandhabt werden – es liegt am Benutzer, die Entscheidung zu treffen und den Schalter zu ziehen, um einen davon zu befördern die Slaves in der verfügbaren Umgebung. Es ist auch Sache des Benutzers, sicherzustellen, dass sich die Umgebung, die die Netzwerkverbindung verloren hat, so verhält, wie sie sollte, und nicht weiter betrieben wird.
Wenn der private Teil der Cloud nicht mehr verfügbar ist, wie wir bereits erwähnt haben, sind manuelle Maßnahmen erforderlich, um einen der Slaves zu einem neuen Master zu machen. Dann wird der Datenverkehr aller verbleibenden Webanwendungsserver in der öffentlichen Cloud unter Verwendung von lokalem ProxySQL an den neuen Master und alle verbleibenden Slaves umgeleitet. Da wir andererseits drei von fünf MySQL-Knoten verloren haben, möchten wir das Setup der öffentlichen Cloud skalieren – ClusterControl kann Ihnen dabei helfen, effizient zusätzliche Knoten zu Ihrem Cluster hinzuzufügen.
Ein anderes Szenario könnte sein, dass der Writer abgestürzt ist, während die Konnektivität zwischen unserem On-Prem-Setup und der öffentlichen Cloud einwandfrei funktioniert.
In einem solchen Szenario wollen wir einen der Sklaven zum neuen Meister befördern. Abhängig von den Anforderungen möchten wir möglicherweise auch, dass der neue Master zwischen Knoten in einem bestimmten Teil der Umgebung heraufgestuft wird. ClusterControl kann die Knoten für das Failover auf die Whitelist oder Blacklist setzen, um sicherzustellen, dass Sie die volle Kontrolle über den Failover-Prozess haben und auswählen können, welche Knoten in welcher Reihenfolge als Kandidaten für einen neuen Master betrachtet werden sollen.
Wir hoffen, dass Ihnen dieser Blog eine Vorstellung davon gegeben hat, wie das Hybrid-Cloud-Setup für die MySQL-Replikation funktioniert und wie es Sie im Falle von Datenbank- oder Netzwerkausfällen schützen kann.
