{"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":"Komplexe Migration von RabbitMQ in Kubernetes","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Komplexe
\n
\nRabbitMQ \u2013 ein auf Erlang basierender Nachrichtenbroker, der es erm\u00f6glicht, ein ausfallsicheres Cluster mit vollst\u00e4ndiger Datenreplikation \u00fcber mehrere Knoten zu organisieren, wobei jeder Knoten Lese- und Schreibanfragen bedienen kann. Mit einer Vielzahl von Kubernetes-Clustern im Produktionsbetrieb unterst\u00fctzen wir zahlreiche RabbitMQ-Installationen und stehen vor der Herausforderung, Daten von einem Cluster zu einem anderen ohne Ausfallzeiten zu migrieren.<\/a><\/noindex><\/p>\n

Diese Operation war f\u00fcr uns in mindestens 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, bereits \u201ekubernetisiertes\u201c Cluster (d.h. das in K8s-Pods funktioniert).<\/li>\n
  2. Die Migration von RabbitMQ innerhalb von Kubernetes von einem Namespace in einen anderen (z.B. wenn die Grenzen durch Namensr\u00e4ume getrennt sind, um Infrastruktur von einem Bereich in einen anderen zu \u00fcbertragen).<\/li>\n<\/ol>\n

    \nDas in diesem Artikel vorgeschlagene Rezept richtet sich an Situationen (aber ist keineswegs darauf beschr\u00e4nkt), in denen ein altes RabbitMQ-Cluster (z.B. aus 3 Knoten) vorhanden ist, das entweder bereits in K8s ist oder auf alten Servern l\u00e4uft. Damit arbeitet eine Anwendung, die in Kubernetes gehostet wird (bereits dort oder in der Zukunft):<\/p>\n

    \"Komplexe
    \n
    \n\u2026 und wir stehen vor der Aufgabe, diese in ein neues Produktionsumfeld in Kubernetes zu migrieren.<\/p>\n

    Zun\u00e4chst wird der allgemeine Ansatz zur Migration beschrieben, gefolgt von den technischen Details zur Umsetzung.<\/p>\n

    Migrationsalgorithmus<\/h2>\n

    \nDer erste, vorbereitende Schritt vor irgendwelchen 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 wollen schlie\u00dflich keine Daten verlieren. Um diese \u00dcberpr\u00fcfung durchzuf\u00fchren, kann man das RabbitMQ-Admin-Panel aufrufen und im Reiter Admin \u2192 Policies \u00fcberpr\u00fcfen, ob der Wert eingestellt ist. ha-mode: all<\/code>:<\/p>\n

    \"Komplexe
    \n
    \nDer n\u00e4chste Schritt besteht darin, ein neues RabbitMQ-Cluster in K8s-Pods einzurichten (in unserem Fall zum Beispiel aus 3 Knoten, aber die Anzahl kann auch anders sein).<\/p>\n

    Anschlie\u00dfend verbinden wir das alte und das neue RabbitMQ-Cluster zu einem einzigen Cluster (aus 6 Knoten):<\/p>\n

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

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

    \"Komplexe
    \n
    \nDieses Schema haben wir mehrfach in unserer Produktion angewendet. F\u00fcr unsere eigene Bequemlichkeit haben wir es jedoch im Rahmen eines spezialisierten Systems implementiert, das Standardkonfigurationen von RMQ auf vielen Kubernetes-Clustern verteilt. (f\u00fcr diejenigen, die es interessiert: es geht um     Addon-Operator<\/a><\/noindex>, \u00fcber die wir vor kurzem haben wir berichtet<\/a><\/noindex>)<\/i>. Im Folgenden werden einzeln ausgew\u00e4hlte Anweisungen pr\u00e4sentiert, die jeder auf seinen Installationen anwenden kann, um die vorgeschlagene L\u00f6sung in der Praxis auszuprobieren.<\/p>\n

    Praktischer Versuch<\/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 als auch als gew\u00f6hnlicher Cluster in Kubernetes aus dem offiziellen Helm-Chart bereitgestellt werden).<\/li>\n<\/ol>\n

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

      \" genannt.<\/h3>\n

      \nStandausbereitung<\/p>\n

      1. Wir laden das Helm-Chart herunter und bearbeiten es ein wenig:<\/code><\/pre>\n
      \nhelm fetch --untar stable\/rabbitmq-ha F\u00fcr die Bequemlichkeit setzen wir das Passwort,<\/code> ErlangCookie und erstellen eine Policy<\/code>ha-all, um sicherzustellen, dass 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. Wir installieren das Chart:<\/p>\n
      helm install . --name rmq-old --namespace rmq-old<\/code><\/pre>\n
      \n3. Wir gehen ins RabbitMQ-Adminpanel, erstellen eine neue Warteschlange und f\u00fcgen einige Nachrichten hinzu. Diese werden ben\u00f6tigt, um sicherzustellen, dass nach der Migration alle Daten erhalten geblieben sind und nichts verloren gegangen ist:<\/p>\n
      \"Komplexe
      \n
      \nDer Teststand ist bereit: Wir haben ein \"altes\" RabbitMQ mit den Daten, die migriert werden m\u00fcssen.<\/p>\n
      Migration des RabbitMQ-Clusters<\/h3>\n
      \n1. Zun\u00e4chst lassen wir ein neues RabbitMQ im Freund beraten<\/b> Namespace mit denselben<\/b> F\u00fcr die Bequemlichkeit setzen wir das Passwort,<\/code> Und Passwort f\u00fcr den Benutzer. Dazu f\u00fchren wir die oben beschriebenen Schritte aus und \u00e4ndern den Endbefehl zur Installation von RMQ auf den folgenden:<\/p>\n
      helm install . --name rmq-new --namespace rmq-new<\/code><\/pre>\n
      \n2. Jetzt m\u00fcssen wir das neue Cluster mit dem alten verbinden. Dazu gehen wir in jeden der Pods neu<\/b> von RabbitMQ und f\u00fchren 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> ist die Adresse eines der Knoten des alten<\/b> RMQ-Clusters.<\/p>\n
      Diese Befehle stoppen den aktuellen Knoten neu<\/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
      \"Komplexe
      \n
      \nEs ist notwendig, zu warten, bis die Nachrichten zwischen allen Knoten synchronisiert sind. Es ist nicht schwer zu erraten, dass die Zeit f\u00fcr die Nachrichtensynchronisierung von der Hardwareleistung des Clusters abh\u00e4ngt und von der Anzahl der Nachrichten. In dem beschriebenen Szenario gibt es insgesamt 10 Nachrichten, daher wurden die Daten sofort synchronisiert, aber bei einer ausreichend hohen Anzahl von Nachrichten kann die Synchronisierung Stunden dauern.<\/p>\n
      Also, der Synchronisierungsstatus:<\/p>\n
      \"Komplexe
      \n
      \nHier +5<\/code> bedeutet, dass die Nachrichten bereits noch<\/b> auf 5 Knoten (au\u00dfer dem, der im Feld angegeben ist Node<\/code>). Somit war die Synchronisation erfolgreich.<\/p>\n
      4. Es bleibt nur, die Adresse RMQ in der Anwendung auf das neue Cluster umzuschalten (die spezifischen Schritte h\u00e4ngen hier von dem Tech-Stack ab, den Sie verwenden, und anderen Besonderheiten der Anwendung), danach k\u00f6nnen Sie sich von der alten verabschieden.<\/p>\n
      F\u00fcr den letzten Schritt (d.h. das nach<\/b> Umschalten der Anwendung auf das neue 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 \"vergessen\": der alte RMQ kann entfernt werden, damit der Umzug abgeschlossen ist.<\/p>\n
      Hinweis<\/b>: Wenn Sie RMQ mit Zertifikaten verwenden, \u00e4ndert sich grundlegend nichts \u2014 der Umzug erfolgt genau so.<\/i><\/p>\n
      Das DBMS Tarantool ist ein attraktives, zukunftstr\u00e4chtiges Produkt zur Erstellung von hochbelasteten Anwendungen.<\/h2>\n
      \nDas beschriebene Schema passt praktisch f\u00fcr alle F\u00e4lle, in denen wir RabbitMQ \u00fcbertragen oder einfach in ein neues Cluster umziehen m\u00fcssen.<\/p>\n
      In unserem Fall gab es Schwierigkeiten nur einmal, als auf RMQ von vielen Stellen zugegriffen wurde und wir nicht die M\u00f6glichkeit hatten, \u00fcberall die RMQ-Adresse auf die neue zu \u00e4ndern. In diesem Fall starteten wir den neuen RMQ im gleichen Namensraum mit denselben Labels, damit er unter bestehenden Diensten und Ingresses erfasst wurde, und beim manuellen Starten des Pods manipulierten wir die Labels, indem wir sie zu Beginn entfernten, damit keine Anfragen an den leeren RMQ gesendet wurden, und f\u00fcgten sie nach der Synchronisierung der Nachrichten wieder hinzu.<\/p>\n
      Die gleiche Strategie wandten wir bei der Aktualisierung von RabbitMQ auf eine neue Version mit ge\u00e4nderter Konfiguration an \u2013 alles funktionierte wie am Schn\u00fcrchen.<\/p>\n
      P.S.<\/h2>\n
      \nAls logische Fortsetzung dieses Materials bereiten wir Artikel \u00fcber MongoDB (Migration von einem physischen Server nach Kubernetes) und MySQL (wie wir diese DB innerhalb von Kubernetes vorbereiten) vor. Sie werden in den kommenden Monaten ver\u00f6ffentlicht.<\/p>\n
      P.P.S.<\/h2>\n
      \nLesen Sie auch in unserem Blog:<\/p>\n