{"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\/nl\/blog\/administrirovanie\/besprostojnaya-migratsiya-rabbitmq-v-kubernetes","title":{"rendered":"Moeizame migratie van RabbitMQ naar Kubernetes","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Moeizame
\n
\nRabbitMQ \u2013 een op Erlang gebaseerde berichtenbroker die het mogelijk maakt om een fouttolerante clustering te organiseren met volledige datareplicatie over meerdere knooppunten, waarbij elk knooppunt verzoeken voor lezen en schrijven kan afhandelen. Met een breed scala aan Kubernetes-clusters in productie ondersteunen we talloze RabbitMQ-installaties en hebben we te maken gekregen met de noodzaak om gegevens van het ene cluster naar het andere te migreren zonder downtime.<\/a><\/noindex><\/p>\n

Deze operatie was voor ons noodzakelijk in minimaal twee gevallen:<\/p>\n

    \n
  1. Gegevensoverdracht van een RabbitMQ-cluster dat niet op Kubernetes draait, naar een nieuwe \u2013 al 'gekubernetiseerde' (d.w.z. functionerend in K8s-pods) \u2013 cluster.<\/li>\n
  2. Migratie van RabbitMQ binnen Kubernetes van de ene namespace naar de andere (bijvoorbeeld als de omgevingen zijn gescheiden door namespaces, voor het verplaatsen van infrastructuur van de ene omgeving naar de andere).<\/li>\n<\/ol>\n

    \nHet recept dat in dit artikel wordt voorgesteld, is gericht op situaties (maar zeker niet beperkt tot) waarin een oud RabbitMQ-cluster (bijvoorbeeld met 3 knooppunten) zich al dan niet in K8s bevindt, of op enkele oudere servers. Een applicatie die draait binnen Kubernetes (of daar binnenkomt) werkt ermee:<\/p>\n

    \"Moeizame
    \n
    \n\u2026 en we hebben de taak om het naar een nieuwe productie in Kubernetes te migreren.<\/p>\n

    Eerst wordt de algemene benadering van de migratie beschreven, gevolgd door de technische details van de uitvoering.<\/p>\n

    Migratie-algoritme<\/h2>\n

    \nDe eerste, voorbereidende stap voordat er enige acties worden ondernomen, is te controleren dat de oude RabbitMQ-installatie het hoogbeschikbaarheidsmodus heeft ingeschakeld (HA<\/a><\/noindex>). De reden is duidelijk \u2013 we willen namelijk geen gegevens verliezen. Om deze controle uit te voeren, kan men in de RabbitMQ-admininterface gaan en op het tabblad Admin \u2192 Policies controleren of de waarde is ingesteld op ha-mode: all<\/code>:<\/p>\n

    \"Moeizame
    \n
    \nDe volgende stap is het opzetten van een nieuwe RabbitMQ-cluster in K8s-pods (in ons geval bijvoorbeeld bestaande uit 3 knooppunten, maar hun aantal kan ook anders zijn).<\/p>\n

    Daarna combineren we de oude en nieuwe RabbitMQ-clusters, waardoor we \u00e9\u00e9n cluster (van 6 knooppunten) krijgen:<\/p>\n

    \"Moeizame
    \n
    \nHet proces van gegevenssynchronisatie tussen de oude en nieuwe RabbitMQ-clusters wordt geinitieerd. Zodra alle gegevens tussen alle knooppunten in het cluster zijn gesynchroniseerd, kunnen we de applicatie overschakelen op het gebruik van het nieuwe cluster:<\/p>\n

    \"Moeizame
    \n
    \nNa deze handelingen is het voldoende om de oude knooppunten uit de RabbitMQ-cluster te halen, en kan de verhuizing als voltooid worden beschouwd:<\/p>\n

    \"Moeizame
    \n
    \nDeze opstelling hebben we herhaaldelijk in onze productie gebruikt. Voor ons gemak hebben we het echter ge\u00efmplementeerd binnen een gespecialiseerd systeem dat standaardconfiguraties van RMQ verspreidt over meerdere Kubernetes-clusters. (voor degenen die nieuwsgierig zijn: het gaat om     addon-operator<\/a><\/noindex>, waar we recentelijk hebben we verteld<\/a><\/noindex>)<\/i>. Hieronder zullen afzonderlijke instructies worden weergegeven die iedereen op zijn eigen installaties kan toepassen om de voorgestelde oplossing in de praktijk uit te proberen.<\/p>\n

    Laten we het in de praktijk proberen<\/h2>\n

    <\/p>\n

    Vereisten<\/h3>\n

    \nDe gegevens zijn heel eenvoudig:<\/p>\n

      \n
    1. Kubernetes-cluster (minikube is ook geschikt);<\/li>\n
    2. Een RabbitMQ-cluster (dat kan worden uitgerold op bare metal, of zoals een gewoon cluster in Kubernetes uit de offici\u00eble Helm-chart).<\/li>\n<\/ol>\n

      \nVoor het onderstaande voorbeeld heb ik RMQ in Kubernetes uitgerold en het genoemd rmq-old<\/code>.<\/p>\n

      Voorbereiding van de testomgeving<\/h3>\n

      \n1. Download de Helm-chart en bewerk deze een beetje:<\/p>\n

      helm fetch --untar stable\/rabbitmq-ha<\/code><\/pre>\n
      \nVoor het gemak stellen we een wachtwoord in, ErlangCookie<\/code> en stellen we het beleid in op ha-all<\/code>, zodat de wachtrijen standaard synchroniseren tussen alle knooppunten van het RMQ-cluster:<\/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. Installeer de chart:<\/p>\n
      helm install . --name rmq-old --namespace rmq-old<\/code><\/pre>\n
      \n3. Ga naar de RabbitMQ-admin, maak een nieuwe wachtrij aan en voeg een paar berichten toe. Deze hebben we nodig om na de migratie te kunnen bevestigen dat alle gegevens behouden zijn en we niets verloren zijn:<\/p>\n
      \"Moeizame
      \n
      \nDe testomgeving is klaar: we hebben een 'oude' RabbitMQ met gegevens die we moeten overzetten.<\/p>\n
      Migratie van het RabbitMQ-cluster<\/h3>\n
      \n1. Laten we als eerste een nieuwe RabbitMQ uitrollen in een vriend<\/b> de namespace met dezelfde naam<\/b> ErlangCookie<\/code> en wachtwoord voor de gebruiker. Hiervoor voeren we de bovengenoemde stappen uit, waarbij we de eindopdracht voor de installatie van RMQ aanpassen naar het volgende:<\/p>\n
      helm install . --name rmq-new --namespace rmq-new<\/code><\/pre>\n
      \n2. Nu is het nodig om het nieuwe cluster te combineren met het oude. Daarom gaan we naar elk van de pod\u2019s nieuwe<\/b> RabbitMQ en voeren we de commando's uit:<\/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 de variabele OLD_RMQ<\/code> verwijst naar het adres van een van de knooppunten van het oude<\/b> RMQ-cluster.<\/p>\n
      Deze commando's zullen de huidige knoop nieuwe<\/b> van het RMQ-cluster stoppen, verbinden met het oude cluster en opnieuw opstarten.<\/p>\n
      3. Het RMQ-cluster met 6 knooppunten is gereed:<\/p>\n
      \"Moeizame
      \n
      \nWacht tot de berichten zijn gesynchroniseerd tussen alle knooppunten. Het is niet moeilijk te raden dat de tijd voor de synchronisatie van berichten afhangt van de kracht van de hardware waarop het cluster is ge\u00efmplementeerd en het aantal berichten. In het beschreven scenario zijn er slechts 10 berichten, dus de gegevens zijn onmiddellijk gesynchroniseerd, maar bij een groot aantal berichten kan de synchronisatie uren duren.<\/p>\n
      Dus, de status van de synchronisatie:<\/p>\n
      \"Moeizame
      \n
      \nHier +5<\/code> betekent dat de berichten al zijn nog<\/b> op 5 knooppunten (behalve die in het veld Node<\/code>). Daarom is de synchronisatie succesvol verlopen.<\/p>\n
      4. Het enige wat je nog hoeft te doen is het adres van RMQ in de applicatie om te schakelen naar het nieuwe cluster (specifieke stappen hiervoor zijn afhankelijk van de technologie-stack die je gebruikt en andere specificaties van de applicatie), waarna je afscheid kunt nemen van het oude.<\/p>\n
      Voor de laatste operatie (d.w.z. het worden toegevoegd na<\/b> overschakelen van de applicatie naar het nieuwe cluster) ga je naar elk knooppunt van het oude<\/b> van het cluster en voer je de commando's uit:<\/p>\n
      rabbitmqctl stop_app\nrabbitmqctl reset<\/code><\/pre>\n
      \nHet cluster \"vergeet\" de oude knooppunten: je kunt de oude RMQ verwijderen, waarmee de verhuizing is voltooid.<\/p>\n
      Opmerking<\/b>: Als je RMQ met certificaten gebruikt, verandert er principieel niets \u2014 het verhuisproces zal op dezelfde manier plaatsvinden.<\/i><\/p>\n
      Conclusies<\/h2>\n
      \nHet beschreven schema is praktisch geschikt voor alle gevallen waarin we RabbitMQ moeten verplaatsen of simpelweg naar een nieuw cluster moeten verhuizen.<\/p>\n
      In ons geval ontstonden er slechts moeilijkheden toen RMQ vanuit veel plekken werd aangesproken en we geen mogelijkheid hadden om overal het adres van RMQ naar het nieuwe te wijzigen. Toen hebben we een nieuwe RMQ opgezet in dezelfde namespace met dezelfde labels, zodat deze onder de reeds bestaande services en Ingress'en viel, en bij het starten van de pod hebben we de labels handmatig gemanipuleerd, ze in het begin verwijderd zodat er geen verzoeken naar de lege RMQ gingen, en ze weer toegevoegd na de synchronisatie van de berichten.<\/p>\n
      We hebben dezelfde strategie toegepast bij de upgrade van RabbitMQ naar een nieuwe versie met gewijzigde configuratie \u2014 alles werkte als een zonnetje.<\/p>\n
      P.S.<\/h2>\n
      \nAls logisch vervolg op dit materiaal bereiden we artikelen voor over MongoDB (migratie van een fysieke server naar Kubernetes) en MySQL (hoe we deze database binnen Kubernetes voorbereiden). Ze zullen binnen enkele maanden worden gepubliceerd.<\/p>\n
      P.P.S.<\/h2>\n
      \nLees ook op onze blog:<\/p>\n