కుబెర్నెటీస్‌కు రాబిట్‌ఎమ్‌క్యూ అతుకులు లేని వలస

RabbitMQ అనేది ఎర్లాంగ్‌లో వ్రాయబడిన సందేశ బ్రోకర్, ఇది బహుళ నోడ్‌లలో పూర్తి డేటా రెప్లికేషన్‌తో ఫెయిల్‌ఓవర్ క్లస్టర్‌ను నిర్వహించడానికి మిమ్మల్ని అనుమతిస్తుంది, ఇక్కడ ప్రతి నోడ్ అభ్యర్థనలను చదవడానికి మరియు వ్రాయడానికి సేవ చేయగలదు. ఉత్పత్తి ఆపరేషన్‌లో అనేక కుబెర్నెట్స్ క్లస్టర్‌లను కలిగి ఉన్నందున, మేము పెద్ద సంఖ్యలో RabbitMQ ఇన్‌స్టాలేషన్‌లకు మద్దతిస్తాము మరియు పనికిరాని సమయం లేకుండా డేటాను ఒక క్లస్టర్ నుండి మరొక క్లస్టర్‌కు తరలించాల్సిన అవసరాన్ని ఎదుర్కొంటున్నాము.

మాకు కనీసం రెండు సందర్భాల్లో ఈ ఆపరేషన్ అవసరం:

1. కుబెర్నెటీస్‌లో లేని RabbitMQ క్లస్టర్ నుండి డేటాను కొత్త - ఇప్పటికే "కుబెర్నెటైజ్ చేయబడిన" (అంటే K8s పాడ్‌లలో పనిచేస్తున్నది) - క్లస్టర్‌కి బదిలీ చేయడం.
2. ఒక నేమ్‌స్పేస్ నుండి మరొక నేమ్‌స్పేస్‌కి కుబెర్నెట్స్‌లోని RabbitMQ వలస (ఉదాహరణకు, సర్క్యూట్‌లు నేమ్‌స్పేస్‌ల ద్వారా వేరు చేయబడితే, ఒక సర్క్యూట్ నుండి మరొక సర్క్యూట్‌కు ఇన్‌ఫ్రాస్ట్రక్చర్‌ను బదిలీ చేయడానికి).

వ్యాసంలో ప్రతిపాదించబడిన రెసిపీ పరిస్థితులపై దృష్టి పెట్టింది (కానీ వాటికి పరిమితం కాదు) దీనిలో పాత RabbitMQ క్లస్టర్ (ఉదాహరణకు, 3 నోడ్‌ల) ఉంది, ఇది ఇప్పటికే K8 లలో లేదా కొన్ని పాత సర్వర్‌లలో ఉంది. Kubernetes (ఇప్పటికే అక్కడ లేదా భవిష్యత్తులో) హోస్ట్ చేసిన అప్లికేషన్ దానితో పని చేస్తుంది:

... మరియు మేము దానిని కుబెర్నెట్స్‌లోని కొత్త ఉత్పత్తికి తరలించే పనిని ఎదుర్కొంటున్నాము.

మొదట, వలసకు సంబంధించిన సాధారణ విధానం వివరించబడుతుంది మరియు ఆ తర్వాత దాని అమలు యొక్క సాంకేతిక వివరాలు వివరించబడతాయి.

మైగ్రేషన్ అల్గోరిథం

పాత RabbitMQ ఇన్‌స్టాలేషన్‌లో అధిక లభ్యత మోడ్ ప్రారంభించబడిందో లేదో తనిఖీ చేయడం ఏదైనా చర్యకు ముందు మొదటి, ప్రాథమిక దశ.HA) కారణం స్పష్టంగా ఉంది - మేము ఏ డేటాను కోల్పోకూడదనుకుంటున్నాము. ఈ తనిఖీని నిర్వహించడానికి, మీరు RabbitMQ అడ్మిన్ ప్యానెల్‌కి వెళ్లి, అడ్మిన్ → విధానాల ట్యాబ్‌లో విలువ సెట్ చేయబడిందని నిర్ధారించుకోండి ha-mode: all:

తదుపరి దశ Kubernetes పాడ్‌లలో కొత్త RabbitMQ క్లస్టర్‌ను పెంచడం (మా విషయంలో, ఉదాహరణకు, 3 నోడ్‌లను కలిగి ఉంటుంది, కానీ వాటి సంఖ్య భిన్నంగా ఉండవచ్చు).

దీని తర్వాత, మేము పాత మరియు కొత్త RabbitMQ క్లస్టర్‌లను విలీనం చేస్తాము, ఒకే క్లస్టర్‌ను (6 నోడ్‌లలో) పొందుతాము:

పాత మరియు కొత్త RabbitMQ క్లస్టర్‌ల మధ్య డేటా సింక్రొనైజేషన్ ప్రక్రియ ప్రారంభించబడింది. క్లస్టర్‌లోని అన్ని నోడ్‌ల మధ్య మొత్తం డేటా సమకాలీకరించబడిన తర్వాత, మేము కొత్త క్లస్టర్‌ని ఉపయోగించడానికి అప్లికేషన్‌ను మార్చవచ్చు:

ఈ ఆపరేషన్ల తర్వాత, RabbitMQ క్లస్టర్ నుండి పాత నోడ్‌లను తీసివేయడం సరిపోతుంది మరియు తరలింపు పూర్తయినట్లు పరిగణించవచ్చు:

మేము ఈ పథకాన్ని ఉత్పత్తిలో చాలాసార్లు ఉపయోగించాము. అయినప్పటికీ, మా స్వంత సౌలభ్యం కోసం, మేము దీన్ని బహుళ కుబెర్నెట్స్ క్లస్టర్‌లలో ప్రామాణిక RMQ కాన్ఫిగరేషన్‌లను పంపిణీ చేసే ప్రత్యేక సిస్టమ్‌లో అమలు చేసాము. (ఆసక్తి ఉన్నవారికి: మేము మాట్లాడుతున్నాము addon-operatorదాని గురించి మేము ఇటీవలే చెప్పారు). ప్రతిపాదిత పరిష్కారాన్ని చర్యలో ప్రయత్నించడానికి ఎవరైనా వారి ఇన్‌స్టాలేషన్‌లపై దరఖాస్తు చేసుకోగల వ్యక్తిగత సూచనలను మేము క్రింద ప్రదర్శిస్తాము.

ఆచరణలో ప్రయత్నిద్దాం

అవసరాలు

వివరాలు చాలా సులభం:

1. కుబెర్నెటెస్ క్లస్టర్ (మినీక్యూబ్ కూడా పని చేస్తుంది);
2. RabbitMQ క్లస్టర్ (బేర్ మెటల్‌పై అమర్చవచ్చు మరియు అధికారిక హెల్మ్ చార్ట్ నుండి కుబెర్నెట్స్‌లో సాధారణ క్లస్టర్‌గా తయారు చేయవచ్చు).

దిగువ ఉదాహరణ కోసం, నేను కుబెర్నెటెస్‌కు RMQని ఉపయోగించాను మరియు దానికి కాల్ చేసాను rmq-old.

స్టాండ్ తయారీ

1. హెల్మ్ చార్ట్‌ని డౌన్‌లోడ్ చేసి, దాన్ని కొద్దిగా సవరించండి:

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. 6 నోడ్‌ల RMQ క్లస్టర్ సిద్ధంగా ఉంది:

సందేశాలు అన్ని నోడ్‌ల మధ్య సమకాలీకరించబడినప్పుడు మీరు వేచి ఉండాలి. సందేశ సమకాలీకరణ సమయం క్లస్టర్ అమలు చేయబడిన హార్డ్‌వేర్ సామర్థ్యంపై మరియు సందేశాల సంఖ్యపై ఆధారపడి ఉంటుందని ఊహించడం కష్టం కాదు. వివరించిన దృష్టాంతంలో, వాటిలో 10 మాత్రమే ఉన్నాయి, కాబట్టి డేటా తక్షణమే సమకాలీకరించబడింది, కానీ తగినంత పెద్ద సంఖ్యలో సందేశాలతో, సమకాలీకరణ గంటల పాటు కొనసాగుతుంది.

కాబట్టి, సమకాలీకరణ స్థితి:

ఇది +5 అంటే సందేశాలు ఇప్పటికే ఉన్నాయి మరింత 5 నోడ్‌లపై (ఫీల్డ్‌లో సూచించినవి తప్ప Node) అందువలన, సమకాలీకరణ విజయవంతమైంది.

4. అప్లికేషన్‌లోని RMQ చిరునామాను కొత్త క్లస్టర్‌కి మార్చడమే మిగిలి ఉంది (ఇక్కడ నిర్దిష్ట చర్యలు మీరు ఉపయోగిస్తున్న టెక్నాలజీ స్టాక్ మరియు ఇతర అప్లికేషన్ ప్రత్యేకతలపై ఆధారపడి ఉంటాయి), ఆ తర్వాత మీరు పాతదానికి వీడ్కోలు చెప్పవచ్చు.

చివరి ఆపరేషన్ కోసం (అంటే ఇప్పటికే после అప్లికేషన్‌ను కొత్త క్లస్టర్‌కి మార్చడం) ప్రతి నోడ్‌కి వెళ్లండి పాత క్లస్టర్ మరియు ఆదేశాలను అమలు చేయండి:

rabbitmqctl stop_app
rabbitmqctl reset

క్లస్టర్ పాత నోడ్‌ల గురించి "మర్చిపోయింది": మీరు పాత RMQని తొలగించవచ్చు, ఆ సమయంలో తరలింపు పూర్తవుతుంది.

వ్యాఖ్య: మీరు సర్టిఫికేట్‌లతో RMQని ఉపయోగిస్తే, ప్రాథమికంగా ఏమీ మారదు - కదిలే ప్రక్రియ సరిగ్గా అదే విధంగా నిర్వహించబడుతుంది.

కనుగొన్న

మేము RabbitMQని తరలించాల్సిన అవసరం వచ్చినప్పుడు లేదా కొత్త క్లస్టర్‌కు తరలించాల్సిన అవసరం వచ్చినప్పుడు వివరించిన పథకం దాదాపు అన్ని సందర్భాల్లో అనుకూలంగా ఉంటుంది.

మా విషయంలో, అనేక ప్రదేశాల నుండి RMQని యాక్సెస్ చేసినప్పుడు ఒక్కసారి మాత్రమే ఇబ్బందులు తలెత్తాయి మరియు RMQ చిరునామాను ప్రతిచోటా కొత్తదానికి మార్చడానికి మాకు అవకాశం లేదు. మేము అదే నేమ్‌స్పేస్‌లో అదే నేమ్‌స్పేస్‌లో కొత్త RMQని ప్రారంభించాము, తద్వారా ఇది ఇప్పటికే ఉన్న సేవలు మరియు ప్రవేశాల పరిధిలోకి వస్తుంది మరియు పాడ్‌ను ప్రారంభించేటప్పుడు మేము చేతితో లేబుల్‌లను మార్చాము, అభ్యర్థనలు రాకుండా ప్రారంభంలో వాటిని తీసివేసాము. RMQ ఖాళీ, మరియు సందేశాలు సమకాలీకరించబడిన తర్వాత వాటిని తిరిగి జోడించడం.

మార్చబడిన కాన్ఫిగరేషన్‌తో కొత్త వెర్షన్‌కి RabbitMQని అప్‌డేట్ చేస్తున్నప్పుడు మేము అదే వ్యూహాన్ని ఉపయోగించాము - ప్రతిదీ గడియారంలా పని చేస్తుంది.

PS

ఈ మెటీరియల్ యొక్క తార్కిక కొనసాగింపుగా, మేము MongoDB (హార్డ్‌వేర్ సర్వర్ నుండి Kubernetesకి వలస) మరియు MySQL (మేము Kubernetes లోపల ఈ DBMSని ఎలా సిద్ధం చేస్తాము) గురించి కథనాలను సిద్ధం చేస్తున్నాము. అవి రాబోయే నెలల్లో ప్రచురించబడతాయి.

PPS

మా బ్లాగులో కూడా చదవండి:

• «డేటాబేస్‌లు మరియు కుబెర్నెట్స్ (సమీక్ష మరియు వీడియో నివేదిక)";
• «K8s చిట్కాలు & ఉపాయాలు: పెద్ద డేటాబేస్‌ల కోసం బూట్‌స్ట్రాప్‌ను వేగవంతం చేయడం".

మూలం: www.habr.com