Sømløs migrering av RabbitMQ til Kubernetes

RabbitMQ er en meldingsmegler skrevet i Erlang som lar deg organisere en failover-klynge med full datareplikering på tvers av flere noder, hvor hver node kan betjene lese- og skriveforespørsler. Med mange Kubernetes-klynger i produksjonsdrift støtter vi et stort antall RabbitMQ-installasjoner og ble møtt med behovet for å migrere data fra en klynge til en annen uten nedetid.

Vi trengte denne operasjonen i minst to tilfeller:

1. Overføring av data fra en RabbitMQ-klynge som ikke er lokalisert i Kubernetes til en ny – allerede «kubernetisert» (dvs. opererer i K8s-pods) – klynge.
2. Migrering av RabbitMQ i Kubernetes fra ett navneområde til et annet (for eksempel hvis kretser er avgrenset av navnerom, så for å overføre infrastruktur fra en krets til en annen).

Oppskriften som er foreslått i artikkelen er fokusert på situasjoner (men er overhodet ikke begrenset til dem) der det er en gammel RabbitMQ-klynge (for eksempel med 3 noder), lokalisert enten allerede i K8s eller på noen gamle servere. En applikasjon som er vert på Kubernetes (allerede der eller i fremtiden) fungerer med den:

... og vi står overfor oppgaven med å migrere den til den nye produksjonen i Kubernetes.

Først vil den generelle tilnærmingen til selve migreringen bli beskrevet, og etter det vil de tekniske detaljene for implementeringen bli beskrevet.

Migrasjonsalgoritme

Det første, foreløpige, trinnet før enhver handling er å sjekke at høy tilgjengelighetsmodus er aktivert i den gamle RabbitMQ-installasjonen (HA). Årsaken er åpenbar - vi ønsker ikke å miste noen data. For å utføre denne kontrollen, kan du gå til RabbitMQ admin panel og i Admin → Policy-fanen sørge for at verdien er satt ha-mode: all:

Det neste trinnet er å heve en ny RabbitMQ-klynge i Kubernetes-pods (i vårt tilfelle, for eksempel bestående av 3 noder, men antallet kan være forskjellig).

Etter dette slår vi sammen de gamle og nye RabbitMQ-klyngene, og oppnår en enkelt klynge (av 6 noder):

Prosessen med datasynkronisering mellom de gamle og nye RabbitMQ-klyngene er igangsatt. Når alle data er synkronisert mellom alle noder i klyngen, kan vi bytte applikasjonen til å bruke den nye klyngen:

Etter disse operasjonene er det nok å fjerne de gamle nodene fra RabbitMQ-klyngen, og flyttingen kan betraktes som fullført:

Vi har brukt denne ordningen mange ganger i produksjonen. Men for vår egen bekvemmelighet implementerte vi det i et spesialisert system som distribuerer standard RMQ-konfigurasjoner på tvers av flere Kubernetes-klynger (for de som er nysgjerrige: vi snakker om addon-operatørsom vi nylig fortalt). Nedenfor vil vi presentere individuelle instruksjoner som alle kan bruke på sine installasjoner for å prøve den foreslåtte løsningen i praksis.

La oss prøve det i praksis

Krav

Detaljene er veldig enkle:

1. Kubernetes cluster (minikube vil også fungere);
2. RabbitMQ-klynge (kan utplasseres på bart metall og lages som en vanlig klynge i Kubernetes fra det offisielle Helm-diagrammet).

For eksempelet nedenfor distribuerte jeg RMQ til Kubernetes og kalte det rmq-old.

Klargjøring av stand

1. Last ned Helm-diagrammet og rediger det litt:

helm fetch --untar stable/rabbitmq-ha

For enkelhets skyld angir vi et passord, ErlangCookie og lage politikk ha-allslik at som standard er køene synkronisert mellom alle noder i RMQ-klyngen:

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. Installer diagrammet:

helm install . --name rmq-old --namespace rmq-old

3. Gå til RabbitMQ-administrasjonspanelet, lag en ny kø og legg til flere meldinger. De vil være nødvendige slik at vi etter migrering kan sørge for at alle dataene er bevart og at vi ikke har mistet noe:

Testbenken er klar: vi har den "gamle" RabbitMQ med data som må overføres.

Migrering av en RabbitMQ-klynge

1. La oss først distribuere den nye RabbitMQ i venn navneområde med samme ErlangCookie og passord for brukeren. For å gjøre dette, vil vi utføre operasjonene beskrevet ovenfor, og endre den siste kommandoen for å installere RMQ til følgende:

helm install . --name rmq-new --namespace rmq-new

2. Nå må du slå sammen den nye klyngen med den gamle. For å gjøre dette, gå til hver av podene ny RabbitMQ og utfør kommandoene:

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

I en variabel OLD_RMQ adressen til en av nodene er funnet gammel RMQ-klynge.

Disse kommandoene vil stoppe gjeldende node ny RMQ-klyngen, fest den til den gamle klyngen og start den på nytt.

3. RMQ-klynge med 6 noder er klar:

Du må vente mens meldinger synkroniseres mellom alle noder. Det er ikke vanskelig å gjette at meldingssynkroniseringstiden avhenger av kapasiteten til maskinvaren som klyngen er distribuert på og av antall meldinger. I det beskrevne scenariet er det bare 10 av dem, så dataene ble synkronisert umiddelbart, men med et tilstrekkelig stort antall meldinger kan synkronisering vare i timevis.

Så, synkroniseringsstatusen:

Her +5 betyr at meldinger allerede er inne mer på 5 noder (bortsett fra det som er angitt i feltet Node). Dermed var synkroniseringen vellykket.

4. Alt som gjenstår er å bytte RMQ-adressen i applikasjonen til den nye klyngen (de spesifikke handlingene her avhenger av teknologistabelen du bruker og andre applikasjonsspesifikasjoner), hvoretter du kan si farvel til den gamle.

For den siste operasjonen (dvs. allerede etter bytte applikasjonen til en ny klynge) gå til hver node gammel klynge og utfør kommandoene:

rabbitmqctl stop_app
rabbitmqctl reset

Klyngen "glemte" de gamle nodene: du kan slette den gamle RMQ, på hvilket tidspunkt flyttingen vil bli fullført.

Note: Hvis du bruker RMQ med sertifikater, endres ingenting fundamentalt - flytteprosessen vil bli utført nøyaktig på samme måte.

Funn

Det beskrevne opplegget passer for nesten alle tilfeller når vi trenger å migrere RabbitMQ eller bare flytte til en ny klynge.

I vårt tilfelle oppsto vanskeligheter bare én gang, da RMQ ble aksessert fra mange steder, og vi hadde ikke mulighet til å endre RMQ-adressen til en ny overalt. Deretter lanserte vi en ny RMQ i samme navneområde med de samme etikettene, slik at den skulle falle inn under eksisterende tjenester og Ingresses, og da vi lanserte poden, manipulerte vi etikettene for hånd, og fjernet dem i begynnelsen slik at forespørsler ikke skulle falle på tom RMQ, og legger dem til igjen etter at meldingene er synkronisert.

Vi brukte samme strategi når vi oppdaterte RabbitMQ til en ny versjon med endret konfigurasjon – alt fungerte som en klokke.

PS

Som en logisk fortsettelse av dette materialet, forbereder vi artikler om MongoDB (migrering fra en maskinvareserver til Kubernetes) og MySQL (hvordan vi forbereder denne DBMS inne i Kubernetes). De vil bli publisert i løpet av de neste månedene.

PPS

Les også på bloggen vår:

• «Databaser og Kubernetes (gjennomgang og videorapport)";
• «K8s tips og triks: Fremskynde oppstartstrap for store databaser'.

Kilde: www.habr.com