RabbitMQ ist ein in Erlang geschriebener Nachrichtenbroker, der es Ihnen ermöglicht, einen Failover-Cluster mit vollständiger Datenreplikation über mehrere Knoten hinweg zu organisieren, wobei jeder Knoten Lese- und Schreibanforderungen bedienen kann. Da wir viele Kubernetes-Cluster im Produktionsbetrieb haben, unterstützen wir eine große Anzahl von RabbitMQ-Installationen und standen vor der Notwendigkeit, Daten ohne Ausfallzeiten von einem Cluster in einen anderen zu migrieren.
Wir brauchten diese Operation in mindestens zwei Fällen:
- Übertragen von Daten von einem RabbitMQ-Cluster, der sich nicht in Kubernetes befindet, in einen neuen – bereits „kubernetisierten“ (d. h. in K8s-Pods betriebenen) Cluster.
- Migration von RabbitMQ innerhalb von Kubernetes von einem Namespace zu einem anderen (z. B. wenn Schaltkreise durch Namespaces begrenzt sind, um die Infrastruktur von einem Schaltkreis auf einen anderen zu übertragen).
Das im Artikel vorgeschlagene Rezept konzentriert sich auf Situationen (ist jedoch keineswegs darauf beschränkt), in denen ein alter RabbitMQ-Cluster (z. B. mit 3 Knoten) vorhanden ist, der sich entweder bereits in K8s oder auf einigen alten Servern befindet. Eine auf Kubernetes gehostete Anwendung (bereits dort oder in Zukunft) funktioniert damit:
... und wir stehen vor der Aufgabe, es in die neue Produktion in Kubernetes zu migrieren.
Zunächst wird der allgemeine Ansatz zur Migration selbst beschrieben und anschließend werden die technischen Details ihrer Umsetzung beschrieben.
Migrationsalgorithmus
Der erste, vorläufige Schritt vor jeder Aktion besteht darin, zu überprüfen, ob der Hochverfügbarkeitsmodus in der alten RabbitMQ-Installation aktiviert ist (). Der Grund liegt auf der Hand: Wir wollen keine Daten verlieren. Um diese Prüfung durchzuführen, können Sie zum RabbitMQ-Administrationsbereich gehen und auf der Registerkarte Admin → Richtlinien sicherstellen, dass der Wert festgelegt ist ha-mode: all:
Der nächste Schritt besteht darin, einen neuen RabbitMQ-Cluster in Kubernetes-Pods zu erstellen (in unserem Fall beispielsweise bestehend aus 3 Knoten, deren Anzahl jedoch unterschiedlich sein kann).
Danach führen wir die alten und neuen RabbitMQ-Cluster zusammen und erhalten so einen einzelnen Cluster (aus 6 Knoten):
Der Prozess der Datensynchronisierung zwischen dem alten und dem neuen RabbitMQ-Cluster wird eingeleitet. Sobald alle Daten zwischen allen Knoten im Cluster synchronisiert sind, können wir die Anwendung auf die Verwendung des neuen Clusters umstellen:
Nach diesen Vorgängen reicht es aus, die alten Knoten aus dem RabbitMQ-Cluster zu entfernen, und der Umzug kann als abgeschlossen betrachtet werden:
Wir haben dieses Schema viele Male in der Produktion verwendet. Aus praktischen Gründen haben wir es jedoch in einem speziellen System implementiert, das Standard-RMQ-Konfigurationen auf mehrere Kubernetes-Cluster verteilt (Für die Neugierigen: Wir reden darüber worüber wir ). Im Folgenden stellen wir individuelle Anleitungen vor, die jeder auf seine Installationen anwenden kann, um die vorgeschlagene Lösung in der Praxis auszuprobieren.
Versuchen wir es in der Praxis
Bedarf
Die Details sind ganz einfach:
- Kubernetes-Cluster (Minikube funktioniert auch);
- RabbitMQ-Cluster (kann auf Bare Metal bereitgestellt und wie ein normaler Cluster in Kubernetes aus dem offiziellen Helm-Diagramm erstellt werden).
Für das folgende Beispiel habe ich RMQ auf Kubernetes bereitgestellt und aufgerufen rmq-old.
Standvorbereitung
1. Laden Sie das Helm-Diagramm herunter und bearbeiten Sie es ein wenig:
helm fetch --untar stable/rabbitmq-ha
Der Einfachheit halber legen wir ein Passwort fest, ErlangCookie und Politik machen ha-allsodass die Warteschlangen standardmäßig zwischen allen RMQ-Clusterknoten synchronisiert werden:
rabbitmqPassword: guest
rabbitmqErlangCookie: mae9joopaol7aiVu3eechei2waiGa2we
definitions:
policies: |-
{
"name": "ha-all",
"pattern": ".*",
"vhost": "/",
"definition": {
"ha-mode": "all",
"ha-sync-mode": "automatic",
"ha-sync-batch-size": 81920
}
}2. Installieren Sie das Diagramm:
helm install . --name rmq-old --namespace rmq-old3. Gehen Sie zum RabbitMQ-Administrationsbereich, erstellen Sie eine neue Warteschlange und fügen Sie mehrere Nachrichten hinzu. Sie werden benötigt, damit wir nach der Migration sicherstellen können, dass alle Daten erhalten bleiben und wir nichts verloren haben:
Der Prüfstand ist fertig: Wir haben den „alten“ RabbitMQ mit Daten, die übertragen werden müssen.
Migration eines RabbitMQ-Clusters
1. Lassen Sie uns zunächst das neue RabbitMQ bereitstellen другом Namensraum mit das selbe ErlangCookie und Passwort für den Benutzer. Dazu führen wir die oben beschriebenen Vorgänge aus und ändern den letzten Befehl zur Installation von RMQ wie folgt:
helm install . --name rmq-new --namespace rmq-new2. Jetzt müssen Sie den neuen Cluster mit dem alten zusammenführen. Gehen Sie dazu zu jedem der Pods neu RabbitMQ und führen Sie die Befehle aus:
export OLD_RMQ=rabbit@rmq-old-rabbitmq-ha-0.rmq-old-rabbitmq-ha-discovery.rmq-old.svc.cluster.local &&
rabbitmqctl stop_app &&
rabbitmqctl join_cluster $OLD_RMQ &&
rabbitmqctl start_app
In einer Variablen OLD_RMQ die Adresse eines der Knoten wurde gefunden alt RMQ-Cluster.
Diese Befehle stoppen den aktuellen Knoten neu RMQ-Cluster, hängen Sie ihn an den alten Cluster an und starten Sie ihn erneut.
3. Der RMQ-Cluster mit 6 Knoten ist bereit:
Sie müssen warten, während die Nachrichten zwischen allen Knoten synchronisiert werden. Es ist nicht schwer zu erraten, dass die Zeit für die Nachrichtensynchronisierung von der Kapazität der Hardware, auf der der Cluster bereitgestellt wird, und von der Anzahl der Nachrichten abhängt. Im beschriebenen Szenario sind es nur 10 davon, sodass die Daten sofort synchronisiert wurden. Bei einer ausreichend großen Anzahl von Nachrichten kann die Synchronisierung jedoch mehrere Stunden dauern.
Also der Synchronisationsstatus:
Hier +5 bedeutet, dass bereits Nachrichten eingegangen sind ещё auf 5 Knoten (außer was im Feld angegeben ist). Node). Somit war die Synchronisierung erfolgreich.
4. Jetzt müssen Sie nur noch die RMQ-Adresse in der Anwendung auf den neuen Cluster umstellen (die konkreten Aktionen hier hängen vom verwendeten Technologie-Stack und anderen Anwendungsspezifika ab) und können sich dann vom alten verabschieden.
Für den letzten Vorgang (also bereits nach (Umschalten der Anwendung auf einen neuen Cluster) gehen Sie zu jedem Knoten alt Cluster und führen Sie die Befehle aus:
rabbitmqctl stop_app
rabbitmqctl resetDer Cluster hat die alten Knoten „vergessen“: Sie können den alten RMQ löschen, woraufhin die Verschiebung abgeschlossen ist.
Beachten: Wenn Sie RMQ mit Zertifikaten verwenden, ändert sich grundsätzlich nichts – der Umzugsprozess wird genauso durchgeführt.
Befund
Das beschriebene Schema eignet sich für fast alle Fälle, in denen wir RabbitMQ migrieren oder einfach in einen neuen Cluster wechseln müssen.
In unserem Fall traten Schwierigkeiten nur einmal auf, als von vielen Orten aus auf RMQ zugegriffen wurde und wir nicht überall die Möglichkeit hatten, die RMQ-Adresse auf eine neue zu ändern. Dann haben wir einen neuen RMQ im selben Namespace mit denselben Labels gestartet, damit er unter bestehende Dienste und Ingresses fällt, und beim Starten des Pods haben wir die Labels manuell manipuliert und sie am Anfang entfernt, damit Anfragen nicht auf den Pod fallen Leeren Sie RMQ und fügen Sie sie wieder hinzu, nachdem die Nachrichten synchronisiert wurden.
Bei der Aktualisierung von RabbitMQ auf eine neue Version mit geänderter Konfiguration haben wir die gleiche Strategie angewendet – alles funktionierte wie am Schnürchen.
PS
Als logische Fortsetzung dieses Materials bereiten wir Artikel über MongoDB (Migration von einem Hardware-Server zu Kubernetes) und MySQL (wie wir dieses DBMS in Kubernetes vorbereiten) vor. Sie werden in den kommenden Monaten veröffentlicht.
PPS
Lesen Sie auch auf unserem Blog:
- «";
- «".
Source: habr.com