టరాన్టూల్ కార్ట్రిడ్జ్: మూడు లైన్లలో లువా బ్యాకెండ్ షార్డింగ్

Mail.ru గ్రూప్‌లో మనకు టరాన్టూల్ ఉంది - ఇది లువాలోని అప్లికేషన్ సర్వర్, ఇది డేటాబేస్‌గా కూడా రెట్టింపు అవుతుంది (లేదా వైస్ వెర్సా?). ఇది వేగంగా మరియు చల్లగా ఉంటుంది, కానీ ఒక సర్వర్ యొక్క సామర్థ్యాలు ఇప్పటికీ అపరిమితంగా లేవు. వర్టికల్ స్కేలింగ్ కూడా దివ్యౌషధం కాదు, కాబట్టి టరాన్టూల్ క్షితిజ సమాంతర స్కేలింగ్ కోసం సాధనాలను కలిగి ఉంది - vshard మాడ్యూల్ [1]. ఇది అనేక సర్వర్‌లలో డేటాను షార్డ్ చేయడానికి మిమ్మల్ని అనుమతిస్తుంది, అయితే దాన్ని సెటప్ చేయడానికి మరియు వ్యాపార లాజిక్‌ను జోడించడానికి మీరు దానితో టింకర్ చేయాలి.

శుభవార్త: మేము కొన్ని పెద్ద షాట్‌లను సేకరించాము (ఉదా [2], [3]) మరియు ఈ సమస్యకు పరిష్కారాన్ని గణనీయంగా సులభతరం చేసే మరొక ఫ్రేమ్‌వర్క్‌ను సృష్టించింది.

టరాన్టూల్ కార్ట్రిడ్జ్ సంక్లిష్ట పంపిణీ వ్యవస్థలను అభివృద్ధి చేయడానికి కొత్త ఫ్రేమ్‌వర్క్. ఇది ఇన్‌ఫ్రాస్ట్రక్చర్ సమస్యలను పరిష్కరించడానికి బదులుగా వ్యాపార తర్కాన్ని వ్రాయడంపై దృష్టి పెట్టడానికి మిమ్మల్ని అనుమతిస్తుంది. కట్ క్రింద నేను ఈ ఫ్రేమ్‌వర్క్ ఎలా పనిచేస్తుందో మరియు దానిని ఉపయోగించి పంపిణీ చేయబడిన సేవలను ఎలా వ్రాయాలో మీకు చెప్తాను.

అసలు సమస్య ఏమిటి?

మాకు టరాన్టులా ఉంది, మాకు వర్షార్డ్ ఉంది - మీకు ఇంకా ఏమి కావాలి?

మొదట, ఇది సౌలభ్యం యొక్క విషయం. vshard కాన్ఫిగరేషన్ Lua పట్టికల ద్వారా కాన్ఫిగర్ చేయబడింది. బహుళ టరాన్టూల్ ప్రక్రియల పంపిణీ వ్యవస్థ సరిగ్గా పనిచేయాలంటే, కాన్ఫిగరేషన్ ప్రతిచోటా ఒకే విధంగా ఉండాలి. ఎవరూ దీన్ని మాన్యువల్‌గా చేయాలనుకోరు. అందువల్ల, అన్ని రకాల స్క్రిప్ట్‌లు, అన్సిబుల్ మరియు డిప్లాయ్‌మెంట్ సిస్టమ్‌లు ఉపయోగించబడతాయి.

కార్ట్రిడ్జ్ స్వయంగా vshard కాన్ఫిగరేషన్‌ను నిర్వహిస్తుంది, ఇది దాని ఆధారంగా చేస్తుంది స్వంత పంపిణీ కాన్ఫిగరేషన్. ఇది తప్పనిసరిగా ఒక సాధారణ YAML ఫైల్, దీని కాపీ ప్రతి టరాన్టూల్ ఉదాహరణలో నిల్వ చేయబడుతుంది. సరళీకరణ ఏమిటంటే, ఫ్రేమ్‌వర్క్ దాని కాన్ఫిగరేషన్‌ను పర్యవేక్షిస్తుంది మరియు ఇది ప్రతిచోటా ఒకేలా ఉండేలా చేస్తుంది.

రెండవది, ఇది మళ్ళీ సౌలభ్యం యొక్క విషయం. వ్యాపార తర్కం అభివృద్ధితో vshard కాన్ఫిగరేషన్‌కు ఎలాంటి సంబంధం లేదు మరియు ప్రోగ్రామర్‌ని అతని పని నుండి మాత్రమే దూరం చేస్తుంది. మేము ప్రాజెక్ట్ యొక్క నిర్మాణాన్ని చర్చించినప్పుడు, మేము చాలా తరచుగా వ్యక్తిగత భాగాలు మరియు వాటి పరస్పర చర్య గురించి మాట్లాడుతాము. క్లస్టర్‌ను 3 డేటా సెంటర్‌లకు రోల్ అవుట్ చేయడం గురించి ఆలోచించడం చాలా తొందరగా ఉంది.

మేము ఈ సమస్యలను పదే పదే పరిష్కరించాము మరియు ఏదో ఒక సమయంలో అప్లికేషన్‌తో దాని మొత్తం జీవిత చక్రంలో పని చేయడాన్ని సరళీకృతం చేసే విధానాన్ని అభివృద్ధి చేయగలిగాము: సృష్టి, అభివృద్ధి, పరీక్ష, CI/CD, నిర్వహణ.

కార్ట్రిడ్జ్ ప్రతి టరాన్టూల్ ప్రక్రియకు పాత్ర యొక్క భావనను పరిచయం చేస్తుంది. పాత్రలు అనేది డెవలపర్‌ను కోడ్ రాయడంపై దృష్టి పెట్టడానికి అనుమతించే ఒక భావన. ప్రాజెక్ట్‌లో అందుబాటులో ఉన్న అన్ని పాత్రలను ఒక టరాన్టూల్ ఉదాహరణలో అమలు చేయవచ్చు మరియు ఇది పరీక్షలకు సరిపోతుంది.

టరాన్టూల్ కార్ట్రిడ్జ్ యొక్క ముఖ్య లక్షణాలు:

• ఆటోమేటెడ్ క్లస్టర్ ఆర్కెస్ట్రేషన్;
• కొత్త పాత్రలను ఉపయోగించి అప్లికేషన్ యొక్క కార్యాచరణను విస్తరించడం;
• అభివృద్ధి మరియు విస్తరణ కోసం అప్లికేషన్ టెంప్లేట్;
• అంతర్నిర్మిత ఆటోమేటిక్ షార్డింగ్;
• లుయాటెస్ట్ టెస్టింగ్ ఫ్రేమ్‌వర్క్‌తో ఏకీకరణ;
• WebUI మరియు API ఉపయోగించి క్లస్టర్ నిర్వహణ;
• ప్యాకేజింగ్ మరియు విస్తరణ సాధనాలు.

హలో, ప్రపంచం!

ఫ్రేమ్‌వర్క్‌ను చూపించడానికి నేను వేచి ఉండలేను, కాబట్టి మేము ఆర్కిటెక్చర్ గురించి కథనాన్ని తర్వాత వదిలివేసి, సాధారణమైన దానితో ప్రారంభిస్తాము. టరాన్టూల్ ఇప్పటికే ఇన్‌స్టాల్ చేయబడిందని మేము అనుకుంటే, చేయాల్సిందల్లా మాత్రమే

$ tarantoolctl rocks install cartridge-cli
$ export PATH=$PWD/.rocks/bin/:$PATH

ఈ రెండు ఆదేశాలు కమాండ్ లైన్ యుటిలిటీలను ఇన్‌స్టాల్ చేస్తాయి మరియు టెంప్లేట్ నుండి మీ మొదటి అప్లికేషన్‌ను సృష్టించడానికి మిమ్మల్ని అనుమతిస్తాయి:

$ cartridge create --name myapp

మరియు ఇది మనకు లభిస్తుంది:

myapp/
├── .git/
├── .gitignore
├── app/roles/custom.lua
├── deps.sh
├── init.lua
├── myapp-scm-1.rockspec
├── test
│   ├── helper
│   │   ├── integration.lua
│   │   └── unit.lua
│   ├── helper.lua
│   ├── integration/api_test.lua
│   └── unit/sample_test.lua
└── tmp/

ఇది రెడీమేడ్ “హలో, వరల్డ్!”తో కూడిన జిట్ రిపోజిటరీ. అప్లికేషన్. మునుపు డిపెండెన్సీలను (ఫ్రేమ్‌వర్క్‌తో సహా) ఇన్‌స్టాల్ చేసిన వెంటనే దీన్ని అమలు చేయడానికి ప్రయత్నిద్దాం:

$ tarantoolctl rocks make
$ ./init.lua --http-port 8080

కాబట్టి, ఫ్యూచర్ షార్డ్ అప్లికేషన్ కోసం మాకు ఒక నోడ్ నడుస్తోంది. ఒక పరిశోధనాత్మక సామాన్యుడు వెంటనే వెబ్ ఇంటర్‌ఫేస్‌ను తెరవగలడు, మౌస్‌తో ఒక నోడ్ యొక్క క్లస్టర్‌ను కాన్ఫిగర్ చేయవచ్చు మరియు ఫలితాన్ని ఆస్వాదించవచ్చు, కానీ సంతోషించడం చాలా తొందరగా ఉంది. ఇప్పటివరకు, అప్లికేషన్ ఉపయోగకరంగా ఏమీ చేయలేదు, కాబట్టి నేను విస్తరణ గురించి మీకు తర్వాత చెబుతాను, కానీ ఇప్పుడు కోడ్ వ్రాయడానికి సమయం ఆసన్నమైంది.

అప్లికేషన్ అభివృద్ధి

ఒక్కసారి ఊహించుకోండి, మేము తప్పనిసరిగా డేటాను స్వీకరించే ప్రాజెక్ట్‌ను రూపొందిస్తున్నాము, దానిని సేవ్ చేయండి మరియు రోజుకు ఒకసారి నివేదికను రూపొందించండి.

మేము రేఖాచిత్రాన్ని గీయడం ప్రారంభించాము మరియు దానిపై మూడు భాగాలను ఉంచుతాము: గేట్‌వే, నిల్వ మరియు షెడ్యూలర్. మేము ఆర్కిటెక్చర్‌పై మరింత పని చేస్తున్నాము. మేము vshardని నిల్వగా ఉపయోగిస్తాము కాబట్టి, మేము స్కీమ్‌కి vshard-router మరియు vshard-స్టోరేజ్‌ని జోడిస్తాము. గేట్‌వే లేదా షెడ్యూలర్ నేరుగా నిల్వను యాక్సెస్ చేయదు; రూటర్ దాని కోసం, దాని కోసం సృష్టించబడింది.

ఈ రేఖాచిత్రం ఇప్పటికీ మేము ప్రాజెక్ట్‌లో ఏమి నిర్మించబోతున్నామో సరిగ్గా సూచించలేదు ఎందుకంటే భాగాలు వియుక్తంగా కనిపిస్తాయి. ఇది నిజమైన టరాన్టూల్‌లో ఎలా అంచనా వేయబడుతుందో మనం ఇంకా చూడాలి - ప్రాసెస్ ద్వారా మన భాగాలను సమూహపరుద్దాం.

vshard-router మరియు గేట్‌వేలను వేర్వేరు సందర్భాల్లో ఉంచడంలో పెద్దగా ప్రయోజనం లేదు. ఇది ఇప్పటికే రౌటర్ యొక్క బాధ్యత అయితే మనం మరోసారి నెట్‌వర్క్‌ను ఎందుకు సర్ఫ్ చేయాలి? వారు అదే ప్రక్రియలో అమలు చేయాలి. అంటే, గేట్‌వే మరియు vshard.router.cfg రెండూ ఒక ప్రాసెస్‌లో ప్రారంభించబడతాయి మరియు వాటిని స్థానికంగా ఇంటరాక్ట్ చేయనివ్వండి.

డిజైన్ దశలో, మూడు భాగాలతో పనిచేయడం సౌకర్యంగా ఉంది, కానీ నేను, డెవలపర్‌గా, కోడ్‌ను వ్రాసేటప్పుడు, టార్నాటూల్ యొక్క మూడు సందర్భాలను ప్రారంభించడం గురించి ఆలోచించడం ఇష్టం లేదు. నేను పరీక్షలను అమలు చేయాలి మరియు నేను గేట్‌వే సరిగ్గా వ్రాసానో లేదో తనిఖీ చేయాలి. లేదా నేను నా సహోద్యోగులకు ఒక లక్షణాన్ని ప్రదర్శించాలనుకుంటున్నాను. నేను మూడు కాపీలను అమలు చేయడానికి ఎందుకు ఇబ్బంది పడాలి? పాత్రల కాన్సెప్ట్ అలా పుట్టింది. పాత్ర అనేది ఒక సాధారణ లుయాష్ మాడ్యూల్, దీని జీవిత చక్రం క్యాట్రిడ్జ్ ద్వారా నిర్వహించబడుతుంది. ఈ ఉదాహరణలో వాటిలో నాలుగు ఉన్నాయి - గేట్‌వే, రూటర్, స్టోరేజ్, షెడ్యూలర్. మరో ప్రాజెక్ట్‌లో ఇంకా ఎక్కువ ఉండవచ్చు. అన్ని పాత్రలను ఒకే ప్రక్రియలో అమలు చేయవచ్చు మరియు ఇది సరిపోతుంది.

మరియు స్టేజింగ్ లేదా ఉత్పత్తికి విస్తరణ విషయానికి వస్తే, మేము హార్డ్‌వేర్ సామర్థ్యాలను బట్టి ప్రతి టరాన్టూల్ ప్రాసెస్‌కు దాని స్వంత పాత్రలను కేటాయిస్తాము:

టోపాలజీ నిర్వహణ

ఏ పాత్రలు ఎక్కడ నడుస్తున్నాయో సమాచారం తప్పనిసరిగా ఎక్కడో నిల్వ చేయబడాలి. మరియు ఇది "ఎక్కడో" పంపిణీ చేయబడిన కాన్ఫిగరేషన్, ఇది నేను ఇప్పటికే పైన పేర్కొన్నాను. దాని గురించి చాలా ముఖ్యమైన విషయం క్లస్టర్ టోపోలాజీ. ఇక్కడ 3 టరాన్టూల్ ప్రక్రియల యొక్క 5 ప్రతిరూపణ సమూహాలు ఉన్నాయి:

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

టోపోలాజీ విభాగంలో కూడా, ప్రతి రెప్లికేషన్ గ్రూప్ యొక్క నాయకుడు వంటి ముఖ్యమైన పరామితి సూచించబడుతుంది. సాధారణంగా ఇది రికార్డ్ చేయబడే కాపీ. మినహాయింపులు ఉన్నప్పటికీ మిగిలినవి చాలా తరచుగా చదవడానికి మాత్రమే. కొన్నిసార్లు ధైర్య డెవలపర్లు వైరుధ్యాలకు భయపడరు మరియు సమాంతరంగా అనేక ప్రతిరూపాలకు డేటాను వ్రాయగలరు, అయితే కొన్ని కార్యకలాపాలు ఉన్నాయి, ఏది ఏమైనా, రెండుసార్లు నిర్వహించకూడదు. దీనికి నాయకుడి గుర్తు ఉంది.

పాత్రల జీవితం

అటువంటి నిర్మాణంలో నైరూప్య పాత్ర ఉనికిలో ఉండాలంటే, ఫ్రేమ్‌వర్క్ వాటిని ఏదో ఒకవిధంగా నిర్వహించాలి. సహజంగానే, టరాన్టూల్ ప్రక్రియను పునఃప్రారంభించకుండా నియంత్రణ జరుగుతుంది. పాత్రలను నిర్వహించడానికి 4 కాల్‌బ్యాక్‌లు ఉన్నాయి. కార్ట్రిడ్జ్ దాని పంపిణీ కాన్ఫిగరేషన్‌లో వ్రాసినదానిపై ఆధారపడి వాటిని పిలుస్తుంది, తద్వారా నిర్దిష్ట పాత్రలకు కాన్ఫిగరేషన్‌ను వర్తింపజేస్తుంది.

function init()
function validate_config()
function apply_config()
function stop()

ప్రతి పాత్రకు ఒక విధి ఉంటుంది init. రోల్ ప్రారంభించబడినప్పుడు లేదా టరాన్టూల్ పునఃప్రారంభించబడినప్పుడు ఇది ఒకసారి పిలువబడుతుంది. ఇది అక్కడ సౌకర్యవంతంగా ఉంటుంది, ఉదాహరణకు, box.space.createని ప్రారంభించడం లేదా షెడ్యూలర్ నిర్దిష్ట సమయ వ్యవధిలో పని చేసే కొన్ని నేపథ్య ఫైబర్‌ని ప్రారంభించవచ్చు.

ఒక ఫంక్షన్ init సరిపోకపోవచ్చు. కార్ట్రిడ్జ్ టోపోలాజీని నిల్వ చేయడానికి ఉపయోగించే పంపిణీ కాన్ఫిగరేషన్‌ను ఉపయోగించుకోవడానికి పాత్రలను అనుమతిస్తుంది. మేము అదే కాన్ఫిగరేషన్‌లో కొత్త విభాగాన్ని ప్రకటించవచ్చు మరియు దానిలో వ్యాపార కాన్ఫిగరేషన్ యొక్క భాగాన్ని నిల్వ చేయవచ్చు. నా ఉదాహరణలో, ఇది షెడ్యూలర్ పాత్ర కోసం డేటా స్కీమా లేదా షెడ్యూల్ సెట్టింగ్‌లు కావచ్చు.

క్లస్టర్ కాల్స్ validate_config и apply_config పంపిణీ చేయబడిన కాన్ఫిగరేషన్ మారిన ప్రతిసారీ. రెండు-దశల కమిట్‌తో కాన్ఫిగరేషన్‌ను వర్తింపజేసినప్పుడు, క్లస్టర్ ప్రతి పాత్ర ఈ కొత్త కాన్ఫిగరేషన్‌ను అంగీకరించడానికి సిద్ధంగా ఉందో లేదో తనిఖీ చేస్తుంది మరియు అవసరమైతే, వినియోగదారుకు లోపాన్ని నివేదిస్తుంది. కాన్ఫిగరేషన్ సాధారణమని అందరూ అంగీకరించినప్పుడు, ది apply_config.

పాత్రలకు కూడా ఒక పద్ధతి ఉంటుంది stop, పాత్ర యొక్క అవుట్‌పుట్‌ను శుభ్రం చేయడానికి ఇది అవసరం. ఈ సర్వర్‌లో ఇకపై షెడ్యూలర్ అవసరం లేదని మేము చెబితే, అది ప్రారంభించిన ఆ ఫైబర్‌లను ఆపగలదు init.

పాత్రలు ఒకదానితో ఒకటి సంకర్షణ చెందుతాయి. మేము Luaలో ఫంక్షన్ కాల్‌లను వ్రాయడం అలవాటు చేసుకున్నాము, కానీ ఇచ్చిన ప్రక్రియలో మనకు అవసరమైన పాత్ర ఉండకపోవచ్చు. నెట్‌వర్క్ ద్వారా కాల్‌లను సులభతరం చేయడానికి, మేము rpc (రిమోట్ ప్రొసీజర్ కాల్) సహాయక మాడ్యూల్‌ని ఉపయోగిస్తాము, ఇది Tarantoolలో నిర్మించిన ప్రామాణిక నెట్‌బాక్స్ ఆధారంగా నిర్మించబడింది. ఉదాహరణకు, మీ గేట్‌వే ఒక రోజు వేచి ఉండకుండా ఇప్పుడే ఉద్యోగం చేయమని షెడ్యూలర్‌ను నేరుగా అడగాలనుకుంటే ఇది ఉపయోగకరంగా ఉంటుంది.

మరొక ముఖ్యమైన విషయం తప్పు సహనాన్ని నిర్ధారించడం. ఆరోగ్యాన్ని పర్యవేక్షించడానికి కార్ట్రిడ్జ్ SWIM ప్రోటోకాల్‌ను ఉపయోగిస్తుంది [4]. సంక్షిప్తంగా, ప్రక్రియలు UDP ద్వారా పరస్పరం "పుకార్లు" మార్పిడి చేసుకుంటాయి-ప్రతి ప్రక్రియ దాని పొరుగువారికి తాజా వార్తలను చెబుతుంది మరియు వారు ప్రతిస్పందిస్తారు. అకస్మాత్తుగా సమాధానం రాకపోతే, టరాన్టూల్ ఏదో తప్పు అని అనుమానించడం ప్రారంభిస్తుంది మరియు కొంతకాలం తర్వాత అది మరణాన్ని పఠిస్తుంది మరియు ఈ వార్త చుట్టూ ఉన్న ప్రతి ఒక్కరికీ చెప్పడం ప్రారంభిస్తుంది.

ఈ ప్రోటోకాల్ ఆధారంగా, కార్ట్రిడ్జ్ ఆటోమేటిక్ ఫెయిల్యూర్ ప్రాసెసింగ్‌ని నిర్వహిస్తుంది. ప్రతి ప్రక్రియ దాని వాతావరణాన్ని పర్యవేక్షిస్తుంది మరియు నాయకుడు అకస్మాత్తుగా ప్రతిస్పందించడం ఆపివేస్తే, ప్రతిరూపం దాని పాత్రను తీసుకోవచ్చు మరియు కార్ట్రిడ్జ్ తదనుగుణంగా నడుస్తున్న పాత్రలను కాన్ఫిగర్ చేస్తుంది.

మీరు ఇక్కడ జాగ్రత్తగా ఉండాలి, ఎందుకంటే తరచుగా ముందుకు వెనుకకు మారడం ప్రతిరూపణ సమయంలో డేటా వైరుధ్యాలకు దారి తీస్తుంది. అయితే, మీరు యాదృచ్ఛికంగా ఆటోమేటిక్ ఫెయిల్‌ఓవర్‌ని ప్రారంభించకూడదు. ఏమి జరుగుతుందో మనం స్పష్టంగా అర్థం చేసుకోవాలి మరియు నాయకుడిని పునరుద్ధరించిన తర్వాత మరియు కిరీటం అతనికి తిరిగి ఇచ్చిన తర్వాత ప్రతిరూపం విచ్ఛిన్నం కాదని నిర్ధారించుకోవాలి.

వీటన్నింటి నుండి, పాత్రలు మైక్రోసర్వీస్‌ల మాదిరిగానే ఉన్నాయని మీరు భావించవచ్చు. ఒక రకంగా చెప్పాలంటే, అవి కేవలం టరాన్టూల్ ప్రక్రియలలోని మాడ్యూల్స్‌గా మాత్రమే ఉంటాయి. కానీ అనేక ప్రాథమిక వ్యత్యాసాలు కూడా ఉన్నాయి. ముందుగా, అన్ని ప్రాజెక్ట్ పాత్రలు ఒకే కోడ్ బేస్‌లో ఉండాలి. మరియు అన్ని టరాన్టూల్ ప్రక్రియలు ఒకే కోడ్ బేస్ నుండి ప్రారంభించబడాలి, తద్వారా మేము షెడ్యూలర్‌ను ప్రారంభించేందుకు ప్రయత్నించినప్పుడు అలాంటి ఆశ్చర్యకరమైనవి ఉండవు, కానీ అది ఉనికిలో లేదు. అలాగే, మీరు కోడ్ సంస్కరణల్లో వ్యత్యాసాలను అనుమతించకూడదు, ఎందుకంటే అటువంటి పరిస్థితిలో సిస్టమ్ యొక్క ప్రవర్తనను అంచనా వేయడం మరియు డీబగ్ చేయడం చాలా కష్టం.

డాకర్‌లా కాకుండా, మనం పాత్ర "చిత్రం" మాత్రమే తీసుకోలేము, దానిని మరొక మెషీన్‌కి తీసుకెళ్లి అక్కడ అమలు చేయలేము. మా పాత్రలు డాకర్ కంటైనర్‌ల వలె వేరు చేయబడవు. అలాగే, మేము ఒకే సందర్భంలో రెండు ఒకే విధమైన పాత్రలను అమలు చేయలేము. ఒక పాత్ర ఉంది లేదా అది లేదు; ఒక కోణంలో, ఇది సింగిల్టన్. మరియు మూడవదిగా, పాత్రలు మొత్తం ప్రతిరూపణ సమూహంలో ఒకేలా ఉండాలి, లేకుంటే అది అసంబద్ధంగా ఉంటుంది - డేటా ఒకేలా ఉంటుంది, కానీ కాన్ఫిగరేషన్ భిన్నంగా ఉంటుంది.

విస్తరణ సాధనాలు

అప్లికేషన్‌లను అమలు చేయడంలో కార్ట్రిడ్జ్ ఎలా సహాయపడుతుందో చూపిస్తానని నేను వాగ్దానం చేసాను. ఇతరులకు జీవితాన్ని సులభతరం చేయడానికి, ఫ్రేమ్‌వర్క్ ప్యాకేజీలు RPM ప్యాకేజీలు:

$ cartridge pack rpm myapp -- упакует для нас ./myapp-0.1.0-1.rpm
$ sudo yum install ./myapp-0.1.0-1.rpm

ఇన్‌స్టాల్ చేయబడిన ప్యాకేజీ మీకు కావలసిన దాదాపు ప్రతిదీ కలిగి ఉంటుంది: అప్లికేషన్ మరియు ఇన్‌స్టాల్ చేయబడిన డిపెండెన్సీలు రెండూ. Tarantool కూడా RPM ప్యాకేజీ యొక్క డిపెండెన్సీగా సర్వర్‌లోకి చేరుకుంటుంది మరియు మా సేవ ప్రారంభించడానికి సిద్ధంగా ఉంది. ఇది systemd ద్వారా జరుగుతుంది, అయితే మొదట మీరు కొద్దిగా కాన్ఫిగరేషన్ వ్రాయాలి. కనిష్టంగా, ప్రతి ప్రక్రియ యొక్క URIని పేర్కొనండి. ఉదాహరణకు మూడు సరిపోతుంది.

$ sudo tee /etc/tarantool/conf.d/demo.yml <<CONFIG
myapp.router: {"advertise_uri": "localhost:3301", "http_port": 8080}
myapp.storage_A: {"advertise_uri": "localhost:3302", "http_enabled": False}
myapp.storage_B: {"advertise_uri": "localhost:3303", "http_enabled": False}
CONFIG

ఇక్కడ ఒక ఆసక్తికరమైన స్వల్పభేదం ఉంది. బైనరీ ప్రోటోకాల్ పోర్ట్‌ను పేర్కొనడానికి బదులుగా, మేము హోస్ట్ పేరుతో సహా ప్రక్రియ యొక్క మొత్తం పబ్లిక్ చిరునామాను పేర్కొంటాము. క్లస్టర్ నోడ్‌లు ఒకదానికొకటి ఎలా కనెక్ట్ అవ్వాలో తెలుసుకోవడానికి ఇది అవసరం. advertise_uri చిరునామాగా 0.0.0.0ని ఉపయోగించడం చెడ్డ ఆలోచన; ఇది బాహ్య IP చిరునామా అయి ఉండాలి, సాకెట్ బైండ్ కాదు. అది లేకుండా, ఏదీ పని చేయదు, కాబట్టి కార్ట్రిడ్జ్ తప్పు advertise_uriతో నోడ్‌ను ప్రారంభించనివ్వదు.

ఇప్పుడు కాన్ఫిగరేషన్ సిద్ధంగా ఉంది, మీరు ప్రక్రియలను ప్రారంభించవచ్చు. సాధారణ systemd యూనిట్ ఒకటి కంటే ఎక్కువ ప్రక్రియలను ప్రారంభించడానికి అనుమతించదు కాబట్టి, కార్ట్రిడ్జ్‌లోని అప్లికేషన్‌లు పిలవబడే వాటి ద్వారా ఇన్‌స్టాల్ చేయబడతాయి. తక్షణ యూనిట్లు ఇలా పని చేస్తాయి:

$ sudo systemctl start myapp@router
$ sudo systemctl start myapp@storage_A
$ sudo systemctl start myapp@storage_B

కాన్ఫిగరేషన్‌లో, మేము కార్ట్రిడ్జ్ వెబ్ ఇంటర్‌ఫేస్‌ను అందించే HTTP పోర్ట్‌ను పేర్కొన్నాము - 8080. దానికి వెళ్లి చూద్దాం:

ప్రక్రియలు నడుస్తున్నప్పటికీ, అవి ఇంకా కాన్ఫిగర్ చేయబడలేదని మేము చూస్తాము. గుళిక ఇంకా ఎవరితో పునరావృతం చేయాలో తెలియదు మరియు దాని స్వంత నిర్ణయం తీసుకోదు, కాబట్టి అది మా చర్యల కోసం వేచి ఉంది. కానీ మనకు చాలా ఎంపిక లేదు: కొత్త క్లస్టర్ యొక్క జీవితం మొదటి నోడ్ యొక్క కాన్ఫిగరేషన్‌తో ప్రారంభమవుతుంది. అప్పుడు మేము ఇతరులను క్లస్టర్‌కి జోడిస్తాము, వారికి పాత్రలను కేటాయిస్తాము మరియు ఈ సమయంలో విస్తరణ విజయవంతంగా పూర్తయినట్లు పరిగణించవచ్చు.

మీకు ఇష్టమైన పానీయాన్ని ఒక గ్లాసులో పోసి, సుదీర్ఘ పని వారం తర్వాత విశ్రాంతి తీసుకోండి. అప్లికేషన్ ఉపయోగించవచ్చు.

ఫలితాలు

ఫలితాలు ఏమిటి? దీన్ని ప్రయత్నించండి, ఉపయోగించండి, అభిప్రాయాన్ని తెలియజేయండి, Githubలో టిక్కెట్‌లను సృష్టించండి.

సూచనలు

[1] టరాన్టూల్ » 2.2 » రిఫరెన్స్ » రాక్స్ రిఫరెన్స్ » మాడ్యూల్ vshard

[2] మేము Tarantool ఆధారంగా Alfa-Bank యొక్క పెట్టుబడి వ్యాపారం యొక్క ప్రధాన భాగాన్ని ఎలా అమలు చేసాము

[3] కొత్త తరం బిల్లింగ్ ఆర్కిటెక్చర్: టరాన్టూల్‌కు మార్పుతో పరివర్తన

[4] స్విమ్ - క్లస్టర్ బిల్డింగ్ ప్రోటోకాల్

[5] GitHub - టరాన్టూల్/కాట్రిడ్జ్-క్లి

[6] GitHub - టరాన్టూల్/కాట్రిడ్జ్

మూలం: www.habr.com