RabbitMQ:n saumaton siirto Kubernetesiin

RabbitMQ on Erlang-kielellä kirjoitettu viestinvälittäjä, jonka avulla voit järjestää vikasietoklusterin täydellä tietojen replikaatiolla useiden solmujen välillä, jossa jokainen solmu voi palvella luku- ja kirjoituspyyntöjä. Koska tuotantotoiminnassa on useita Kubernetes-klustereita, tuemme suurta määrää RabbitMQ-asennuksia ja kohtasimme tarpeen siirtää tietoja klusterista toiseen ilman seisokkeja.

Tarvitsimme tämän toimenpiteen ainakin kahdessa tapauksessa:

1. Tietojen siirtäminen RabbitMQ-klusterista, joka ei sijaitse Kubernetesissa, uuteen – jo "kubernetoituun" (eli joka toimii K8s-podissa) -klusteriin.
2. RabbitMQ:n siirto Kubernetesissa yhdestä nimiavaruudesta toiseen (esimerkiksi jos piirit on rajattu nimiavaruuksilla, niin infrastruktuurin siirtämiseksi piiristä toiseen).

Artikkelissa ehdotettu resepti keskittyy tilanteisiin (mutta ei suinkaan rajoitu niihin), joissa on olemassa vanha RabbitMQ-klusteri (esimerkiksi 3 solmun), joka sijaitsee joko jo K8:ssa tai jollain vanhoilla palvelimilla. Kubernetesissa isännöity sovellus (jo olemassa tai tulevaisuudessa) toimii sen kanssa:

... ja meillä on tehtävä siirtää se uuteen tuotantoon Kubernetesissa.

Ensin kuvataan yleinen lähestymistapa itse migraatioon ja sen jälkeen sen toteuttamisen tekniset yksityiskohdat.

Siirtymisalgoritmi

Ensimmäinen, alustava vaihe ennen toimenpiteitä on tarkistaa, että korkean käytettävyyden tila on käytössä vanhassa RabbitMQ-asennuksessa (HA). Syy on ilmeinen - emme halua menettää tietoja. Voit suorittaa tämän tarkistuksen siirtymällä RabbitMQ-hallintapaneeliin ja varmistamalla Järjestelmänvalvoja → Käytännöt -välilehdellä, että arvo on asetettu ha-mode: all:

Seuraava askel on nostaa uusi RabbitMQ-klusteri Kubernetes-paloihin (meidän tapauksessamme esimerkiksi 3 solmusta, mutta niiden lukumäärä voi olla erilainen).

Tämän jälkeen yhdistämme vanhat ja uudet RabbitMQ-klusterit, jolloin saadaan yksi klusteri (6 solmua):

Tietojen synkronointiprosessi vanhan ja uuden RabbitMQ-klusterin välillä käynnistetään. Kun kaikki tiedot on synkronoitu klusterin kaikkien solmujen välillä, voimme vaihtaa sovelluksen käyttämään uutta klusteria:

Näiden toimintojen jälkeen riittää, että poistat vanhat solmut RabbitMQ-klusterista, ja siirtoa voidaan pitää valmiina:

Olemme käyttäneet tuota järjestelmää monta kertaa tuotannossa. Oman mukavuuden vuoksi otimme sen käyttöön erikoistuneessa järjestelmässä, joka jakaa vakio-RMQ-kokoonpanot useille Kubernetes-klustereille. (niille, jotka ovat uteliaita: puhumme addon-operaattorijosta me kerrottiin äsken). Alla esittelemme yksittäisiä ohjeita, joita kuka tahansa voi soveltaa asennuksiinsa kokeillakseen ehdotettua ratkaisua käytännössä.

Kokeillaan käytännössä

Vaatimukset

Yksityiskohdat ovat hyvin yksinkertaisia:

1. Kubernetes-klusteri (minikube toimii myös);
2. RabbitMQ-klusteri (voidaan ottaa käyttöön paljaalla metallilla ja tehdä kuin tavallinen klusteri Kubernetesissa virallisesta Helm-kaaviosta).

Alla olevassa esimerkissä otin RMQ:n käyttöön Kubernetesiin ja kutsuin sitä rmq-old.

Jalustan valmistelu

1. Lataa ruorikaavio ja muokkaa sitä hieman:

helm fetch --untar stable/rabbitmq-ha

Mukavuuden vuoksi asetimme salasanan, ErlangCookie ja tehdä politiikkaa ha-allniin, että oletusarvoisesti jonot synkronoidaan RMQ-klusterin kaikkien solmujen välillä:

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. Asenna kaavio:

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

3. Siirry RabbitMQ-hallintapaneeliin, luo uusi jono ja lisää useita viestejä. Niitä tarvitaan, jotta voimme varmistaa siirron jälkeen, että kaikki tiedot säilyvät, emmekä ole menettäneet mitään:

Testipenkki on valmis: meillä on "vanha" RabbitMQ, jossa on siirrettävää dataa.

RabbitMQ-klusterin siirto

1. Otetaan ensin käyttöön uusi RabbitMQ muut nimiavaruus kanssa sama ErlangCookie ja salasana käyttäjälle. Tätä varten suoritamme yllä kuvatut toiminnot muuttamalla RMQ:n asennuksen viimeisen komennon seuraavaksi:

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

2. Nyt sinun on yhdistettävä uusi klusteri vanhaan. Voit tehdä tämän siirtymällä kuhunkin koteloon uusi RabbitMQ ja suorita komennot:

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

Muuttujassa OLD_RMQ yhden solmun osoite löytyy vanha RMQ-klusteri.

Nämä komennot pysäyttävät nykyisen solmun uusi RMQ-klusteri, liitä se vanhaan klusteriin ja käynnistä se uudelleen.

3. Kuuden solmun RMQ-klusteri on valmis:

Sinun on odotettava, kunnes viestit synkronoidaan kaikkien solmujen välillä. Ei ole vaikea arvata, että viestien synkronointiaika riippuu sen laitteiston kapasiteetista, johon klusteri on asennettu, ja viestien määrästä. Kuvatussa skenaariossa niitä on vain 10, joten tiedot synkronoituivat välittömästi, mutta riittävän suurella viestimäärällä synkronointi voi kestää tunteja.

Joten synkronoinnin tila:

Täällä +5 tarkoittaa, että viestit ovat jo saapuneet lisää 5 solmussa (paitsi mitä kentässä on ilmoitettu Node). Synkronointi siis onnistui.

4. Jäljelle jää vain vaihtaa sovelluksen RMQ-osoite uuteen klusteriin (kohtaiset toiminnot riippuvat käyttämästäsi teknologiapinosta ja muista sovellusspesifikaatioista), minkä jälkeen voit sanoa hyvästit vanhalle.

Viimeiseen operaatioon (eli jo jälkeen sovelluksen vaihtaminen uuteen klusteriin) siirry kuhunkin solmuun vanha klusteri ja suorita komennot:

rabbitmqctl stop_app
rabbitmqctl reset

Klusteri "unohti" vanhat solmut: voit poistaa vanhan RMQ:n, jolloin siirto valmistuu.

Huomata: Jos käytät RMQ:ta varmenteiden kanssa, mikään ei muutu olennaisesti - siirtoprosessi suoritetaan täsmälleen samalla tavalla.

Tulokset

Kuvattu menetelmä sopii melkein kaikkiin tapauksiin, joissa meidän on siirrettävä RabbitMQ tai yksinkertaisesti siirryttävä uuteen klusteriin.

Meidän tapauksessamme vaikeuksia esiintyi vain kerran, kun RMQ:ta haettiin monesta paikasta, eikä meillä ollut mahdollisuutta vaihtaa RMQ-osoitetta uuteen kaikkialla. Sitten lanseerasimme uuden RMQ:n samaan nimiavaruuteen samoilla nimiöillä, jotta se kuuluisi olemassa olevien palvelujen ja Ingressien alle, ja podia käynnistettäessä manipuloimme tunnisteita käsin poistamalla ne alussa, jotta pyynnöt eivät joutuisi tyhjennä RMQ ja lisää ne takaisin, kun viestit on synkronoitu.

Käytimme samaa strategiaa, kun päivitimme RabbitMQ:n uuteen versioon, jossa oli muutettu kokoonpano - kaikki toimi kuin kello.

PS.

Loogisena jatkona tälle materiaalille valmistelemme artikkeleita MongoDB:stä (migraatio laitteistopalvelimelta Kubernetesiin) ja MySQL:stä (kuinka valmistamme tämän DBMS:n Kubernetesiin). Ne julkaistaan ​​lähikuukausina.

PPS

Lue myös blogistamme:

• «Tietokannat ja Kubernetes (arvostelu ja videoraportti)";
• «K8s-vinkkejä ja temppuja: Bootstrapin nopeuttaminen suurille tietokantoille'.

Lähde: will.com