{"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\/sv\/blog\/administrirovanie\/besprostojnaya-migratsiya-rabbitmq-v-kubernetes","title":{"rendered":"En utmanande migrering av RabbitMQ till Kubernetes","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"En
\n
\nRabbitMQ \u2013 en med Erlang skrivna meddelandebroker som m\u00f6jligg\u00f6r att skapa en fel-tolerant kluster med full datareplication \u00f6ver flera noder, d\u00e4r varje nod kan hantera l\u00e4s- och skrivf\u00f6rfr\u00e5gningar. Med m\u00e5nga kluster Kubernetes i produktion st\u00f6der vi ett stort antal RabbitMQ-installationer och har st\u00f6tt p\u00e5 behovet av att migrera data fr\u00e5n ett kluster till ett annat utan driftstopp.<\/a><\/noindex><\/p>\n

Denna operation var n\u00f6dv\u00e4ndig f\u00f6r oss i minst tv\u00e5 fall:<\/p>\n

    \n
  1. \u00d6verf\u00f6ring av data fr\u00e5n ett RabbitMQ-kluster som inte \u00e4r i Kubernetes till ett nytt \u2013 redan \"kuberneteserat\" (d.v.s. som fungerar i K8s-poddar) \u2013 kluster.<\/li>\n
  2. Migrering av RabbitMQ inom Kubernetes fr\u00e5n ett namespace till ett annat (t.ex. om konturerna \u00e4r avgr\u00e4nsade av namnrymder, f\u00f6r att \u00f6verf\u00f6ra infrastrukturen fr\u00e5n ett kontur till ett annat).<\/li>\n<\/ol>\n

    \nReceptet som f\u00f6resl\u00e5s i artikeln \u00e4r inriktat p\u00e5 situationer (men begr\u00e4nsas inte till dem) d\u00e4r det finns ett gammalt RabbitMQ-kluster (t.ex. med 3 noder) som antingen redan \u00e4r i K8s eller p\u00e5 n\u00e5gra gamla servrar. Ett applikation arbetar med detta, som \u00e4r placerad i Kubernetes (redan d\u00e4r eller i framtiden):<\/p>\n

    \"En
    \n
    \n\u2026 och vi st\u00e5r inf\u00f6r uppgiften att migrera den till en ny produktion i Kubernetes.<\/p>\n

    F\u00f6rst kommer den allm\u00e4nna metoden f\u00f6r sj\u00e4lva migreringen att beskrivas, och f\u00f6rst d\u00e4refter tekniska detaljer f\u00f6r dess genomf\u00f6rande.<\/p>\n

    Migreringsalgoritm<\/h2>\n

    \nDet f\u00f6rsta, prelimin\u00e4ra steget innan n\u00e5gra \u00e5tg\u00e4rder \u2013 kontrollera att den gamla RabbitMQ-installationen har h\u00f6g tillg\u00e4nglighet aktiverad (HA<\/a><\/noindex>). Anledningen \u00e4r uppenbar \u2013 vi vill ju inte f\u00f6rlora n\u00e5gra data. F\u00f6r att genomf\u00f6ra denna kontroll kan du g\u00e5 in i RabbitMQ:s adminpanel och under fliken Admin \u2192 Policies kontrollera att v\u00e4rdet \u00e4r inst\u00e4llt p\u00e5 ha-mode: all<\/code>:<\/p>\n

    \"En
    \n
    \nN\u00e4sta steg \u2013 vi uppr\u00e4ttar ett nytt RabbitMQ-kluster i K8s-poddar (i v\u00e5rt fall till exempel med 3 noder, men antalet kan vara annat).<\/p>\n

    D\u00e4refter sl\u00e5r vi samman det gamla och det nya RabbitMQ-klustret, vilket ger oss ett enda kluster (med 6 noder):<\/p>\n

    \"En
    \n
    \nProcessen f\u00f6r datasykronisering mellan det gamla och det nya RabbitMQ-klustret initieras. N\u00e4r alla data har synkroniserats mellan alla noder i klustret kan vi byta applikationen till att anv\u00e4nda det nya klustret:<\/p>\n

    \"En
    \n
    \nEfter dessa operationer r\u00e4cker det att ta bort de gamla noderna fr\u00e5n RabbitMQ-klustret, och flytten kan anses vara avslutad:<\/p>\n

    \"En
    \n
    \nDenna l\u00f6sning har vi anv\u00e4nt flera g\u00e5nger i v\u00e5r produktion. Men f\u00f6r v\u00e5r egen bekv\u00e4mlighet har vi implementerat den inom en specialiserad system, som sprider standardkonfigurationer av RMQ p\u00e5 flera Kubernetes-kluster. (f\u00f6r dem som \u00e4r nyfikna: det handlar om     addon-operator<\/a><\/noindex>, om vilken vi nyligen ber\u00e4ttade vi<\/a><\/noindex>)<\/i>. Nedan kommer separata instruktioner att presenteras som var och en kan till\u00e4mpa p\u00e5 sina installationer f\u00f6r att prova den f\u00f6reslagna l\u00f6sningen i praktiken.<\/p>\n

    Testar i praktiken<\/h2>\n

    <\/p>\n

    Krav<\/h3>\n

    \nSpecifikationerna \u00e4r mycket enkla:<\/p>\n

      \n
    1. Kubernetes-kluster (minikube fungerar ocks\u00e5);<\/li>\n
    2. RabbitMQ-kluster (kan \u00e4ven distribueras p\u00e5 bare metal och skapas som ett vanligt kluster i Kubernetes fr\u00e5n den officiella Helm-diagrammet).<\/li>\n<\/ol>\n

      \nF\u00f6r exemplet nedan har jag distribuerat RMQ i Kubernetes och kallat den rmq-old<\/code>.<\/p>\n

      F\u00f6rberedelse av stand<\/h3>\n

      \n1. Ladda ner Helm-diagrammet och redigera det lite:<\/p>\n

      helm fetch --untar stable\/rabbitmq-ha<\/code><\/pre>\n
      \nF\u00f6r bekv\u00e4mlighetens skull anger vi l\u00f6senordet, ErlangCookie<\/code> och g\u00f6r en policy ha-all<\/code>, s\u00e5 att k\u00f6erna som standard synkroniseras mellan alla noder i RMQ-klustret:<\/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. Installera diagrammet:<\/p>\n
      helm install . --name rmq-old --namespace rmq-old<\/code><\/pre>\n
      \n3. G\u00e5 in i RabbitMQ-administrationsgr\u00e4nssnittet, skapa en ny k\u00f6 och l\u00e4gg till n\u00e5gra meddelanden. De kommer att beh\u00f6vas f\u00f6r att vi efter migrationen ska kunna s\u00e4kerst\u00e4lla att alla data har bevarats och att vi inte har f\u00f6rlorat n\u00e5got:<\/p>\n
      \"En
      \n
      \nTeststandet \u00e4r klart: vi har en 'gammal' RabbitMQ med data som beh\u00f6ver flyttas.<\/p>\n
      Migration av RabbitMQ-kluster<\/h3>\n
      \n1. F\u00f6rst ska vi distribuera en ny RabbitMQ i annan<\/b> namnrymden med samma<\/b> ErlangCookie<\/code> och l\u00f6senord f\u00f6r anv\u00e4ndaren. F\u00f6r detta g\u00f6r vi de ovan beskrivna operationerna, \u00e4ndrar den slutliga installationskommandot f\u00f6r RMQ till f\u00f6ljande:<\/p>\n
      helm install . --name rmq-new --namespace rmq-new<\/code><\/pre>\n
      \n2. Nu beh\u00f6ver den nya klustern sammanfogas med den gamla. F\u00f6r detta g\u00e5r vi in i varje av pod'arna ny<\/b> RabbitMQ och k\u00f6r kommandona:<\/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
      \nI variabeln OLD_RMQ<\/code> \u00e4r adressen till en av noderna i den gamla<\/b> RMQ-klustret.<\/p>\n
      Dessa kommandon kommer att stoppa den aktuella noden ny<\/b> i RMQ-klustret, koppla den till det gamla klustret och starta den igen.<\/p>\n
      3. RMQ-klustret med 6 noder \u00e4r klart:<\/p>\n
      \"En
      \n
      \nDu m\u00e5ste v\u00e4nta tills meddelandena synkroniseras mellan alla noder. Det \u00e4r inte sv\u00e5rt att gissa att tiden f\u00f6r meddelandesynkronisering beror p\u00e5 kapaciteten hos den h\u00e5rdvara d\u00e4r klustret \u00e4r implementerat och antalet meddelanden. I det beskrivna scenariot finns det totalt 10 meddelanden, s\u00e5 datan synkroniserades omedelbart, men med ett tillr\u00e4ckligt stort antal meddelanden kan synkroniseringen ta timmar.<\/p>\n
      S\u00e5, status f\u00f6r synkronisering:<\/p>\n
      \"En
      \n
      \nH\u00e4r +5<\/code> betyder att meddelandena redan finns om<\/b> p\u00e5 5 noder (f\u00f6rutom den som anges i f\u00e4ltet Node<\/code>). D\u00e4rmed har synkroniseringen genomf\u00f6rts framg\u00e5ngsrikt.<\/p>\n
      4. Det \u00e5terst\u00e5r bara att v\u00e4xla applikationens RMQ-adress till det nya klustret (specifika \u00e5tg\u00e4rder h\u00e4r beror p\u00e5 vilken teknikstack du anv\u00e4nder och andra specifika egenskaper hos applikationen), efter vilket du kan s\u00e4ga adj\u00f6 till det gamla.<\/p>\n
      F\u00f6r den sista operationen (dvs. efter<\/b> v\u00e4xling av applikationen till det nya klustret), g\u00e5r vi in p\u00e5 varje nod i den gamla<\/b> i klustret och utf\u00f6r kommandona:<\/p>\n
      rabbitmqctl stop_app\nrabbitmqctl reset<\/code><\/pre>\n
      \nKlustret har \"gl\u00f6mt\" de gamla noderna: du kan ta bort den gamla RMQ, och flytten kommer att vara avslutad.<\/p>\n
      Anm\u00e4rkning<\/b>: Om du anv\u00e4nder RMQ med certifikat f\u00f6r\u00e4ndras ingenting principiellt \u2014 flyttprocessen kommer att genomf\u00f6ras p\u00e5 precis samma s\u00e4tt.<\/i><\/p>\n
      Slutsatser<\/h2>\n
      \nDet beskrivna schemat passar praktiskt taget f\u00f6r alla situationer n\u00e4r vi beh\u00f6ver flytta RabbitMQ eller helt enkelt flytta till ett nytt kluster.<\/p>\n
      I v\u00e5rt fall uppstod sv\u00e5righeter bara en g\u00e5ng, n\u00e4r RMQ anropades fr\u00e5n m\u00e5nga st\u00e4llen och vi inte hade m\u00f6jlighet att \u00e4ndra RMQ-adressen \u00f6verallt. D\u00e5 startade vi en ny RMQ i samma namespaces med samma etiketter, s\u00e5 att den skulle matcha de redan existerande tj\u00e4nsterna och Ingressarna, och n\u00e4r vi startade podden manipulerade vi etiketter manuellt, tog bort dem i b\u00f6rjan s\u00e5 att ingen f\u00f6rfr\u00e5gan hamnade p\u00e5 den tomma RMQ, och lade tillbaka dem efter synkronisering av meddelanden.<\/p>\n
      Samma strategi till\u00e4mpade vi vid uppgradering av RabbitMQ till en ny version med \u00e4ndrad konfiguration \u2014 allt fungerade som en klocka.<\/p>\n
      P.S.<\/h2>\n
      \nSom en logisk forts\u00e4ttning p\u00e5 detta material f\u00f6rbereder vi artiklar om MongoDB (migration fr\u00e5n en fysisk server till Kubernetes) och MySQL (hur vi f\u00f6rbereder denna DBMS inom Kubernetes). De kommer att publiceras inom de kommande m\u00e5naderna.<\/p>\n
      P.P.S.<\/h2>\n
      \nL\u00e4s \u00e4ven i v\u00e5r blogg:<\/p>\n