🥇 RabbitMQ-ի սահուն միգրացիան Kubernetes

RabbitMQ-ը հաղորդագրության միջնորդ է, որը գրված է Erlang-ում, որը թույլ է տալիս կազմակերպել ֆայլերի կլաստեր՝ տվյալների ամբողջական վերարտադրմամբ բազմաթիվ հանգույցներում, որտեղ յուրաքանչյուր հանգույց կարող է սպասարկել կարդալու և գրելու հարցումները: Ունենալով Kubernetes-ի բազմաթիվ կլաստերներ արտադրական շահագործման մեջ՝ մենք աջակցում ենք RabbitMQ-ի մեծ թվով տեղադրումներին և բախվել ենք տվյալների մի կլաստերից մյուսը տեղափոխելու անհրաժեշտությանը՝ առանց ընդհատումների:

Այս վիրահատությունը մեզ անհրաժեշտ էր առնվազն երկու դեպքում.

Տվյալների փոխանցում RabbitMQ կլաստերից, որը գտնվում է Kubernetes-ում, նոր՝ արդեն «kubernetized» (այսինքն՝ գործող K8s pods-ում)՝ կլաստեր:
RabbitMQ-ի միգրացիան Kubernetes-ի ներսում մի անվանատարածքից մյուսը (օրինակ, եթե սխեմաները սահմանազատված են անվանատարածքներով, ապա ենթակառուցվածքը մի շղթայից մյուսը փոխանցելու համար):

Հոդվածում առաջարկվող բաղադրատոմսը կենտրոնացած է իրավիճակների վրա (բայց բոլորովին չի սահմանափակվում դրանցով), որոնցում կա հին RabbitMQ կլաստեր (օրինակ՝ 3 հանգույցներից), որը գտնվում է կամ արդեն K8-ներում կամ որոշ հին սերվերների վրա: Դրա հետ աշխատում է Kubernetes-ում տեղակայված հավելվածը (արդեն այնտեղ կամ ապագայում).

... և մենք խնդիր ունենք այն տեղափոխել Կուբերնետեսի նոր արտադրություն:

Սկզբում կնկարագրվի բուն միգրացիայի նկատմամբ ընդհանուր մոտեցումը, որից հետո կնկարագրվեն դրա իրականացման տեխնիկական մանրամասները։

Միգրացիայի ալգորիթմ

Առաջին, նախնական փուլը ցանկացած գործողությունից առաջ ստուգելն է, որ բարձր հասանելիության ռեժիմը միացված է հին RabbitMQ տեղադրման մեջ (HA) Պատճառն ակնհայտ է՝ մենք չենք ցանկանում կորցնել որևէ տվյալ։ Այս ստուգումն իրականացնելու համար կարող եք գնալ RabbitMQ ադմինիստրատորի վահանակ և Admin → Policies ներդիրում համոզվեք, որ արժեքը սահմանված է: ha-mode: all:

Հաջորդ քայլը նոր RabbitMQ կլաստերի բարձրացումն է Kubernetes pods-ում (մեր դեպքում, օրինակ, բաղկացած է 3 հանգույցից, բայց դրանց թիվը կարող է տարբեր լինել):

Դրանից հետո մենք միավորում ենք հին և նոր RabbitMQ կլաստերները՝ ստանալով մեկ կլաստեր (6 հանգույցներից).

Սկսվել է տվյալների համաժամացման գործընթացը հին և նոր RabbitMQ կլաստերների միջև: Երբ բոլոր տվյալները համաժամեցվեն կլաստերի բոլոր հանգույցների միջև, մենք կարող ենք հավելվածը փոխել նոր կլաստերն օգտագործելու համար.

Այս գործողություններից հետո բավական է հեռացնել հին հանգույցները RabbitMQ կլաստերից, և այդ քայլը կարելի է ավարտված համարել.

Մենք այս սխեման բազմիցս օգտագործել ենք արտադրության մեջ։ Այնուամենայնիվ, մեր հարմարության համար մենք այն իրականացրեցինք մասնագիտացված համակարգում, որը բաշխում է ստանդարտ RMQ կազմաձևերը բազմաթիվ Kubernetes կլաստերներում: (հետաքրքրասերների համար. մենք խոսում ենք հավելում-օպերատորորի մասին մենք վերջերս ասաց). Ստորև մենք կներկայացնենք անհատական հրահանգներ, որոնք յուրաքանչյուր ոք կարող է կիրառել իր տեղադրումների վրա՝ առաջարկված լուծումը գործողության մեջ փորձելու համար:

Փորձենք դա գործնականում

Պահանջներ

Մանրամասները շատ պարզ են.

Kubernetes կլաստեր (minikube-ը նույնպես կաշխատի);
RabbitMQ կլաստեր (կարելի է տեղակայվել մերկ մետաղի վրա և կազմել սովորական կլաստերի պես Kubernetes-ում Helm-ի պաշտոնական աղյուսակից):

Ստորև բերված օրինակի համար ես RMQ-ն տեղակայեցի Kubernetes-ում և անվանեցի այն rmq-old.

Ստենդի պատրաստում

1. Ներբեռնեք Helm աղյուսակը և մի փոքր խմբագրեք այն.

helm fetch --untar stable/rabbitmq-ha

Հարմարության համար մենք գաղտնաբառ ենք սահմանել, ErlangCookie ու քաղաքականություն արա ha-allայնպես, որ լռելյայնորեն հերթերը համաժամանակացվում են RMQ կլաստերի բոլոր հանգույցների միջև.

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. Տեղադրեք աղյուսակը.

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

3. Գնացեք RabbitMQ ադմինիստրատորի վահանակ, ստեղծեք նոր հերթ և ավելացրեք մի քանի հաղորդագրություն: Դրանք անհրաժեշտ կլինեն, որպեսզի միգրացիայից հետո մենք կարողանանք համոզվել, որ բոլոր տվյալները պահպանված են, և մենք ոչինչ չենք կորցրել.

Փորձարկման նստարանը պատրաստ է. մենք ունենք «հին» RabbitMQ տվյալների փոխանցման կարիք:

RabbitMQ կլաստերի տեղափոխում

1. Նախ, եկեք տեղակայենք նոր RabbitMQ-ն другом անվանատարածքի հետ նույնը ErlangCookie և օգտվողի գաղտնաբառը: Դա անելու համար մենք կկատարենք վերը նկարագրված գործողությունները՝ փոխելով RMQ-ի տեղադրման վերջնական հրամանը հետևյալի.

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

2. Այժմ դուք պետք է միաձուլեք նոր կլաստերը հինի հետ: Դա անելու համար գնացեք պատիճներից յուրաքանչյուրին նոր RabbitMQ և կատարեք հրամանները.

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

Փոփոխականի մեջ OLD_RMQ հայտնաբերվել է հանգույցներից մեկի հասցեն հին RMQ կլաստեր:

Այս հրամանները կդադարեցնեն ընթացիկ հանգույցը նոր RMQ կլաստեր, կցեք այն հին կլաստերին և նորից գործարկեք:

3. RMQ 6 հանգույցների կլաստերը պատրաստ է.

Դուք պետք է սպասեք, մինչև հաղորդագրությունները համաժամեցվեն բոլոր հանգույցների միջև: Դժվար չէ կռահել, որ հաղորդագրությունների համաժամացման ժամանակը կախված է սարքաշարի հզորությունից, որի վրա տեղակայված է կլաստերը և հաղորդագրությունների քանակից: Նկարագրված սցենարում դրանցից ընդամենը 10-ն է, ուստի տվյալները ակնթարթորեն համաժամացվել են, բայց բավականաչափ մեծ թվով հաղորդագրությունների դեպքում համաժամացումը կարող է տևել ժամեր:

Այսպիսով, համաժամացման կարգավիճակը.

Այստեղ +5 նշանակում է, որ հաղորդագրություններն արդեն մուտքագրված են ավելին 5 հանգույցների վրա (բացառությամբ դաշտում նշվածի Node) Այսպիսով, համաժամացումը հաջող էր:

4. Մնում է հավելվածի RMQ հասցեն փոխարկել նոր կլաստերի (այստեղ կոնկրետ գործողությունները կախված են ձեր օգտագործած տեխնոլոգիական փաթեթից և հավելվածի այլ առանձնահատկություններից), որից հետո կարող եք հրաժեշտ տալ հինին:

Վերջին գործողության համար (այսինքն արդեն այն բանից հետո հավելվածը փոխարկելով նոր կլաստերի) գնալ յուրաքանչյուր հանգույց հին խմբավորել և կատարել հրամանները.

rabbitmqctl stop_app
rabbitmqctl reset

Կլաստերը «մոռացել է» հին հանգույցների մասին. դուք կարող եք ջնջել հին RMQ-ն, այդ պահին քայլը կավարտվի:

ՆշումԵթե դուք օգտագործում եք RMQ վկայագրերով, ապա սկզբունքորեն ոչինչ չի փոխվում. շարժման գործընթացը կիրականացվի ճիշտ նույնը:

Արդյունքները

Նկարագրված սխեման հարմար է գրեթե բոլոր դեպքերի համար, երբ մենք պետք է տեղափոխենք RabbitMQ կամ պարզապես տեղափոխվենք նոր կլաստեր:

Մեր դեպքում դժվարություններ առաջացան միայն մեկ անգամ, երբ RMQ-ին մուտք գործեցին շատ տեղերից, և մենք հնարավորություն չունեինք ամենուր RMQ հասցեն փոխել նորով։ Այնուհետև մենք գործարկեցինք նոր RMQ նույն անվանատարածքում՝ նույն պիտակներով, որպեսզի այն ընկնի գոյություն ունեցող ծառայությունների և Ingresses-ի տակ, իսկ pod-ը գործարկելիս մենք ձեռքով մանիպուլյացիա արեցինք պիտակները՝ սկզբից հանելով դրանք, որպեսզի հարցումները չընկնեն դատարկ RMQ-ն և դրանք նորից ավելացնել հաղորդագրությունների համաժամանակացումից հետո:

Մենք օգտագործեցինք նույն ռազմավարությունը, երբ RabbitMQ-ն թարմացնում էինք փոխված կոնֆիգուրացիան նոր տարբերակով. ամեն ինչ աշխատում էր ժամացույցի պես:

PS

Որպես այս նյութի տրամաբանական շարունակություն՝ մենք հոդվածներ ենք պատրաստում MongoDB-ի (միգրացիա ապարատային սերվերից Kubernetes) և MySQL-ի մասին (ինչպես ենք պատրաստում այս DBMS-ը Kubernetes-ի ներսում): Դրանք կհրապարակվեն առաջիկա ամիսներին։

PPS

Կարդացեք նաև մեր բլոգում.

Source: www.habr.com

RabbitMQ-ի անխափան միգրացիան Kubernetes