{"id":33075,"date":"2019-10-31T21:50:35","date_gmt":"2019-10-31T18:50:35","guid":{"rendered":"https:\/\/prohoster.info\/blog\/besprostojnaya-migratsiya-rabbitmq-v-kubernetes\/"},"modified":"2019-10-31T21:50:35","modified_gmt":"2019-10-31T18:50:35","slug":"besprostojnaya-migratsiya-rabbitmq-v-kubernetes","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/besprostojnaya-migratsiya-rabbitmq-v-kubernetes","title":{"rendered":"Herausfordernde Migration von RabbitMQ in Kubernetes","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Herausfordernde
\n
\nRabbitMQ \u2013 ein in Erlang geschriebener Nachrichtendienst, der es erm\u00f6glicht, ein fehlertolerantes Cluster mit vollst\u00e4ndiger Datenreplikation \u00fcber mehrere Knoten zu organisieren, wobei jeder Knoten Lese- und Schreibanfragen bedienen kann. Mit zahlreichen Kubernetes-Clustern in der Produktionsnutzung unterst\u00fctzen wir eine Vielzahl von RabbitMQ-Installationen und standen vor der Notwendigkeit, Daten von einem Cluster in ein anderes zu migrieren, ohne dabei Ausfallzeiten zu verursachen.<\/a><\/noindex><\/p>\n

Diese Operation war f\u00fcr uns mindestens in zwei F\u00e4llen notwendig:<\/p>\n

    \n
  1. Die \u00dcbertragung von Daten aus einem RabbitMQ-Cluster, das sich nicht in Kubernetes befindet, in ein neues \u2013 bereits \u201ekubernetisiertes\u201c (d.h. funktionierend in K8s-Pods) \u2013 Cluster.<\/li>\n
  2. Die Migration von RabbitMQ innerhalb von Kubernetes von einem Namespace in einen anderen (zum Beispiel, wenn die Umgebungen durch Namensr\u00e4ume voneinander getrennt sind, um die Infrastruktur von einer Umgebung in eine andere zu verschieben).<\/li>\n<\/ol>\n

    \nDas in diesem Artikel vorgeschlagene Rezept richtet sich an Situationen (ist aber nicht darauf beschr\u00e4nkt), in denen ein altes RabbitMQ-Cluster (zum Beispiel aus 3 Knoten) entweder bereits in K8s oder auf \u00e4lteren Servern betrieben wird. Es arbeitet mit einer Anwendung, die in Kubernetes platziert ist (bereits dort oder perspektivisch):<\/p>\n

    \"Herausfordernde
    \n
    \n\u2026 und wir stehen vor der Aufgabe, es in die neue Produktion in Kubernetes zu migrieren.<\/p>\n

    Zuerst wird der allgemeine Ansatz f\u00fcr die Migration selbst beschrieben, gefolgt von den technischen Details zur Umsetzung.<\/p>\n

    Migrationsalgorithmus<\/h2>\n

    \nDer erste, vorbereitende Schritt vor jeglichen Ma\u00dfnahmen ist die \u00dcberpr\u00fcfung, dass in der alten RabbitMQ-Installation der Hochverf\u00fcgbarkeitsmodus aktiviert ist (HA<\/a><\/noindex>). Der Grund ist offensichtlich \u2013 wir m\u00f6chten schlie\u00dflich keine Daten verlieren. Um diese \u00dcberpr\u00fcfung durchzuf\u00fchren, kann man das Admin-Panel von RabbitMQ aufrufen und im Tab Admin \u2192 Policies sicherstellen, dass der Wert gesetzt ist. ha-mode: all<\/code>:<\/p>\n

    \"Herausfordernde
    \n
    \nDer n\u00e4chste Schritt besteht darin, einen neuen RabbitMQ-Cluster in den Pods von Kubernetes zu starten (in unserem Fall beispielsweise bestehend aus 3 Knoten, aber ihre Anzahl kann auch variieren).<\/p>\n

    Danach verbinden wir den alten und den neuen RabbitMQ-Cluster, um einen einzigen Cluster (bestehend aus 6 Knoten) zu erhalten:<\/p>\n

    \"Herausfordernde
    \n
    \nDer Prozess der Datensynchronisation zwischen dem alten und dem neuen RabbitMQ-Cluster wird initiiert. Nachdem alle Daten zwischen den Knoten im Cluster synchronisiert sind, k\u00f6nnen wir die Anwendung auf den neuen Cluster umschalten:<\/p>\n

    \"Herausfordernde
    \n
    \nNach diesen Vorg\u00e4ngen reicht es aus, die alten Knoten aus dem RabbitMQ-Cluster zu entfernen, und der Umzug kann als abgeschlossen betrachtet werden:<\/p>\n

    \"Herausfordernde
    \n
    \nDieses Schema haben wir mehrfach in unserer Produktionsumgebung verwendet. F\u00fcr unseren eigenen Komfort haben wir es jedoch in einem spezialisierten System implementiert, das Standardkonfigurationen von RMQ auf mehrere Kubernetes-Cluster verteilt. (f\u00fcr die Neugierigen: es geht um     addon-operator<\/a><\/noindex>, \u00fcber das wir vor Kurzem haben wir erz\u00e4hlt<\/a><\/noindex>)<\/i>. Im Folgenden werden einige Anleitungen pr\u00e4sentiert, die jeder auf seinen Installationen anwenden kann, um die vorgeschlagene L\u00f6sung in der Praxis auszuprobieren.<\/p>\n

    Praktisch testen<\/h2>\n

    <\/p>\n

    Anforderungen<\/h3>\n

    \nDie Voraussetzungen sind sehr einfach:<\/p>\n

      \n
    1. Kubernetes-Cluster (minikube ist auch geeignet);<\/li>\n
    2. RabbitMQ-Cluster (kann sowohl auf bare metal bereitgestellt werden als auch als herk\u00f6mmlicher Cluster in Kubernetes aus dem offiziellen Helm-Chart erstellt werden).<\/li>\n<\/ol>\n

      \nF\u00fcr das unten beschriebene Beispiel habe ich RMQ in Kubernetes bereitgestellt und es \" rmq-old<\/code>.<\/p>\n

      \" genannt.<\/h3>\n

      \nStandvorbereitung<\/p>\n

      1. Laden Sie das Helm-Chart herunter und bearbeiten Sie es ein wenig:<\/code><\/pre>\n
      \nhelm fetch --untar stable\/rabbitmq-ha Zur Vereinfachung setzen wir ein Passwort,<\/code> ErlangCookie und erstellen die Policy<\/code>, damit die Warteschlangen standardm\u00e4\u00dfig zwischen allen Knoten des RMQ-Clusters synchronisiert werden:<\/p>\n
      rabbitmqPassword: guest\nrabbitmqErlangCookie: mae9joopaol7aiVu3eechei2waiGa2we\ndefinitions:\npolicies: |-\n  {\n    \"name\": \"ha-all\",\n    \"pattern\": \".*\",\n    \"vhost\": \"\/\",\n    \"definition\": {\n      \"ha-mode\": \"all\",\n      \"ha-sync-mode\": \"automatic\",\n      \"ha-sync-batch-size\": 81920\n    }\n  }<\/code><\/pre>\n
      \n2. Chart installieren:<\/p>\n
      helm install . --name rmq-old --namespace rmq-old<\/code><\/pre>\n
      \n3. Melden Sie sich im RabbitMQ-Adminbereich an, erstellen Sie eine neue Warteschlange und f\u00fcgen Sie einige Nachrichten hinzu. Diese werden ben\u00f6tigt, um nach der Migration sicherzustellen, dass alle Daten erhalten geblieben sind und nichts verloren ging:<\/p>\n
      \"Herausfordernde
      \n
      \nDie Testumgebung ist bereit: Wir haben ein \u201ealtes\u201c RabbitMQ mit den Daten, die migriert werden m\u00fcssen.<\/p>\n
      Migration des RabbitMQ-Clusters<\/h3>\n
      \n1. Zuerst setzen wir ein neues RabbitMQ auf in einem Freund gesprochen<\/b> dem Namensraum mit den gleichen<\/b> Zur Vereinfachung setzen wir ein Passwort,<\/code> Benutzerdaten und Passwort. Dazu f\u00fchren wir die oben beschriebenen Schritte durch und \u00e4ndern den Installationsbefehl f\u00fcr RMQ wie folgt:<\/p>\n
      helm install . --name rmq-new --namespace rmq-new<\/code><\/pre>\n
      \n2. Jetzt ist es erforderlich, das neue Cluster mit dem alten zu verbinden. Gehen Sie dazu in jeden der Pods des neuen<\/b> RabbitMQ und f\u00fchren Sie die folgenden Befehle aus:<\/p>\n
      export OLD_RMQ=rabbit@rmq-old-rabbitmq-ha-0.rmq-old-rabbitmq-ha-discovery.rmq-old.svc.cluster.local && \n  rabbitmqctl stop_app && \n  rabbitmqctl join_cluster $OLD_RMQ && \n  rabbitmqctl start_app<\/code><\/pre>\n
      \nIn der Variablen OLD_RMQ<\/code> befindet sich die Adresse eines der Knoten des alten<\/b> RMQ-Clusters.<\/p>\n
      Diese Befehle stoppen den aktuellen Knoten des neuen<\/b> des RMQ-Clusters, f\u00fcgen ihn dem alten Cluster hinzu und starten ihn erneut.<\/p>\n
      3. Das RMQ-Cluster mit 6 Knoten ist bereit:<\/p>\n
      \"Herausfordernde
      \n
      \nEs ist notwendig, zu warten, bis die Nachrichten zwischen allen Knoten synchronisiert sind. Es ist leicht zu erraten, dass die Zeit f\u00fcr die Nachrichtensynchronisation von der Hardware-Performance des Clusters und der Anzahl der Nachrichten abh\u00e4ngt. In dem beschriebenen Szenario gibt es nur 10 Nachrichten, sodass die Daten sofort synchronisiert wurden, aber bei einer ausreichend hohen Anzahl von Nachrichten kann die Synchronisation Stunden in Anspruch nehmen.<\/p>\n
      Also, der Synchronisierungsstatus:<\/p>\n
      \"Herausfordernde
      \n
      \nHier +5<\/code> bedeutet, dass die Nachrichten bereits noch<\/b> auf 5 Knoten (au\u00dfer dem, der im Feld angegeben ist Knoten<\/code>). Somit war die Synchronisation erfolgreich.<\/p>\n
      4. Es bleibt nur noch, die RMQ-Adresse in der Anwendung auf den neuen Cluster umzuschalten (konkrete Schritte h\u00e4ngen hier von Ihrem verwendeten Technologie-Stack und spezifischen Eigenschaften der Anwendung ab), danach k\u00f6nnen Sie sich vom alten verabschieden.<\/p>\n
      F\u00fcr den letzten Schritt (d.h. das nach<\/b> Umschalten der Anwendung auf den neuen Cluster) gehen wir auf jeden Knoten des alten<\/b> des Clusters und f\u00fchren die Befehle aus:<\/p>\n
      rabbitmqctl stop_app\nrabbitmqctl reset<\/code><\/pre>\n
      \nDer Cluster hat die alten Knoten \u201evergessen\u201c: Sie k\u00f6nnen den alten RMQ l\u00f6schen, womit der Umzug abgeschlossen ist.<\/p>\n
      Hinweis<\/b>: Wenn Sie RMQ mit Zertifikaten verwenden, bleibt alles prinzipiell unver\u00e4ndert \u2013 der Migrationsprozess erfolgt genau wie zuvor.<\/i><\/p>\n
      Fazit<\/h2>\n
      \nDas beschriebene Schema eignet sich praktisch f\u00fcr alle Szenarien, in denen wir RabbitMQ umziehen oder einfach in ein neues Cluster wechseln m\u00fcssen.<\/p>\n
      In unserem Fall gab es nur einmal Schwierigkeiten, als RMQ von vielen Stellen gleichzeitig angesprochen wurde, und wir nicht \u00fcberall die RMQ-Adresse auf die neue \u00e4ndern konnten. In diesem Fall haben wir RMQ im gleichen Namensraum mit denselben Labels gestartet, damit es unter die bestehenden Dienste und Ingresses fiel, und bei der manuellen Pod-Bereitstellung haben wir die Labels vor\u00fcbergehend entfernt, sodass keine Anfragen an das leere RMQ gingen, und sie nach der Synchronisierung der Nachrichten wieder hinzugef\u00fcgt.<\/p>\n
      Die gleiche Strategie haben wir bei der Aktualisierung von RabbitMQ auf eine neue Version mit ge\u00e4nderter Konfiguration angewendet \u2013 alles lief einwandfrei.<\/p>\n
      P.S.<\/h2>\n
      \nAls logische Fortsetzung dieses Materials bereiten wir Artikel \u00fcber MongoDB (Migration von einem physischen Server zu Kubernetes) und MySQL (wie wir dieses DBMS innerhalb von Kubernetes vorbereiten) vor. Diese werden in den n\u00e4chsten Monaten ver\u00f6ffentlicht.<\/p>\n
      P.P.S.<\/h2>\n
      \nLesen Sie auch in unserem Blog:<\/p>\n