Problemfri migrering af RabbitMQ til Kubernetes

RabbitMQ er en meddelelsesmægler skrevet i Erlang, der giver dig mulighed for at organisere en failover-klynge med fuld datareplikering på tværs af flere noder, hvor hver node kan servicere læse- og skriveanmodninger. Med mange Kubernetes-klynger i produktionsdrift understøtter vi et stort antal RabbitMQ-installationer og stod over for behovet for at migrere data fra en klynge til en anden uden nedetid.

Vi havde brug for denne operation i mindst to tilfælde:

1. Overførsel af data fra en RabbitMQ-klynge, der ikke er placeret i Kubernetes, til en ny - allerede "kubernetiseret" (dvs. opererer i K8s-pods) - klynge.
2. Migrering af RabbitMQ i Kubernetes fra et navneområde til et andet (for eksempel, hvis kredsløb er afgrænset af navnerum, så for at overføre infrastruktur fra et kredsløb til et andet).

Den opskrift, der foreslås i artiklen, er fokuseret på situationer (men er slet ikke begrænset til dem), hvor der er en gammel RabbitMQ-klynge (for eksempel med 3 noder), placeret enten allerede i K8s eller på nogle gamle servere. En applikation, der hostes på Kubernetes (allerede der eller i fremtiden) fungerer med den:

... og vi står over for opgaven med at migrere den til den nye produktion i Kubernetes.

Først vil den generelle tilgang til selve migreringen blive beskrevet, og derefter vil de tekniske detaljer om dens implementering blive beskrevet.

Migrationsalgoritme

Den første, foreløbige, fase før enhver handling er at kontrollere, at høj tilgængelighedstilstand er aktiveret i den gamle RabbitMQ-installation (HA). Årsagen er indlysende - vi ønsker ikke at miste nogen data. For at udføre denne kontrol kan du gå til RabbitMQ-administrationspanelet og på fanen Admin → Politikker sørge for, at værdien er indstillet ha-mode: all:

Det næste trin er at rejse en ny RabbitMQ-klynge i Kubernetes pods (i vores tilfælde, for eksempel bestående af 3 noder, men deres antal kan være anderledes).

Herefter fusionerer vi de gamle og nye RabbitMQ-klynger og opnår en enkelt klynge (af 6 noder):

Processen med datasynkronisering mellem de gamle og nye RabbitMQ-klynger påbegyndes. Når alle data er synkroniseret mellem alle noder i klyngen, kan vi skifte applikationen til at bruge den nye klynge:

Efter disse operationer er det nok at fjerne de gamle noder fra RabbitMQ-klyngen, og flytningen kan betragtes som fuldført:

Vi har brugt denne ordning mange gange i produktionen. Men for vores egen bekvemmelighed implementerede vi det i et specialiseret system, der distribuerer standard RMQ-konfigurationer på tværs af flere Kubernetes-klynger (for dem, der er nysgerrige: vi taler om addon-operatørom hvilket vi netop fortalt). Nedenfor vil vi præsentere individuelle instruktioner, som alle kan anvende på deres installationer for at prøve den foreslåede løsning i aktion.

Lad os prøve det i praksis

Krav

Detaljerne er meget enkle:

1. Kubernetes klynge (minikube vil også fungere);
2. RabbitMQ-klynge (kan installeres på bart metal og laves som en almindelig klynge i Kubernetes fra det officielle Helm-diagram).

For eksemplet nedenfor installerede jeg RMQ til Kubernetes og kaldte det rmq-old.

Klargøring af stand

1. Download Helm-diagrammet og rediger det lidt:

helm fetch --untar stable/rabbitmq-ha

For nemheds skyld sætter vi en adgangskode, ErlangCookie og lave politik ha-allså som standard er køerne synkroniseret mellem 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-administrationspanelet, opret en ny kø og tilføj flere beskeder. De vil være nødvendige, så vi efter migreringen kan sikre, at alle data er bevaret, og at vi ikke har mistet noget:

Testbænken er klar: Vi har den "gamle" RabbitMQ med data, der skal overføres.

Migrering af en RabbitMQ-klynge

1. Lad os først implementere den nye RabbitMQ i ven navneområde med samme ErlangCookie og adgangskode til brugeren. For at gøre dette vil vi udføre de operationer, der er beskrevet ovenfor, og ændre den sidste kommando til installation af RMQ til følgende:

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

2. Nu skal du flette den nye klynge med den gamle. For at gøre dette skal du gå til hver af bælgerne ny RabbitMQ og udfør kommandoerne:

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 på en af ​​noderne er fundet gammel RMQ klynge.

Disse kommandoer vil stoppe den aktuelle node ny RMQ-klynge, vedhæft den til den gamle klynge og start den igen.

3. RMQ-klynge med 6 noder er klar:

Du skal vente, mens beskeder synkroniseres mellem alle noder. Det er ikke svært at gætte, at meddelelsessynkroniseringstiden afhænger af kapaciteten af ​​den hardware, som klyngen er installeret på, og af antallet af meddelelser. I det beskrevne scenarie er der kun 10 af dem, så dataene blev synkroniseret med det samme, men med et tilstrækkeligt stort antal beskeder kan synkronisering vare i timevis.

Så synkroniseringsstatus:

Her +5 betyder, at beskeder allerede er inde mere på 5 noder (undtagen hvad der er angivet i feltet Node). Synkroniseringen lykkedes således.

4. Tilbage er kun at skifte RMQ-adressen i applikationen til den nye klynge (de specifikke handlinger her afhænger af den teknologistack, du bruger, og andre applikationsspecifikationer), hvorefter du kan sige farvel til den gamle.

For den sidste operation (dvs. allerede efter skifter applikationen til en ny klynge) gå til hver node gammel klynge og udfør kommandoerne:

rabbitmqctl stop_app
rabbitmqctl reset

Klyngen "glemte" de gamle noder: du kan slette den gamle RMQ, hvorefter flytningen vil blive fuldført.

Bemærk: Hvis du bruger RMQ med certifikater, så ændres intet fundamentalt - flytteprocessen vil blive udført nøjagtigt ens.

Fund

Det beskrevne skema er velegnet til næsten alle tilfælde, hvor vi skal migrere RabbitMQ eller blot flytte til en ny klynge.

I vores tilfælde opstod der kun vanskeligheder én gang, da RMQ blev tilgået mange steder fra, og vi havde ikke mulighed for at ændre RMQ-adressen til en ny alle steder. Derefter lancerede vi en ny RMQ i det samme navneområde med de samme etiketter, så det ville falde ind under eksisterende tjenester og Ingresses, og da vi lancerede poden, manipulerede vi etiketterne i hånden og fjernede dem i begyndelsen, så anmodninger ikke faldt på tomme RMQ, og tilføje dem igen, efter at beskederne er synkroniseret.

Vi brugte samme strategi, da vi opdaterede RabbitMQ til en ny version med en ændret konfiguration - alt fungerede som et ur.

PS

Som en logisk fortsættelse af dette materiale er vi ved at forberede artikler om MongoDB (migrering fra en hardwareserver til Kubernetes) og MySQL (hvordan vi forbereder denne DBMS inde i Kubernetes). De vil blive offentliggjort i de kommende måneder.

PPS

Læs også på vores blog:

• «Databaser og Kubernetes (gennemgang og videorapport)";
• «K8s tips og tricks: Fremskyndelse af bootstrap til store databaser'.

Kilde: www.habr.com