Mail.ru క్లౌడ్ సొల్యూషన్స్ ప్లాట్‌ఫారమ్‌లో తప్పు-తట్టుకునే వెబ్ ఆర్కిటెక్చర్ ఎలా అమలు చేయబడుతుంది

హలో, హబ్ర్! నేను ఆర్టెమ్ కరామిషెవ్, సిస్టమ్ అడ్మినిస్ట్రేషన్ టీమ్ హెడ్ Mail.Ru క్లౌడ్ సొల్యూషన్స్ (MCS). మేము గత సంవత్సరంలో అనేక కొత్త ఉత్పత్తిని ప్రారంభించాము. API సేవలు సులువుగా స్కేలబుల్‌గా, లోపాలను తట్టుకోగలవని మరియు వినియోగదారు లోడ్‌లో వేగవంతమైన వృద్ధికి సిద్ధంగా ఉన్నాయని మేము నిర్ధారించాలనుకుంటున్నాము. మా ప్లాట్‌ఫారమ్ ఓపెన్‌స్టాక్‌లో అమలు చేయబడింది మరియు తప్పు-తట్టుకునే సిస్టమ్‌ను పొందడానికి మేము ఏ కాంపోనెంట్ ఫాల్ట్ టాలరెన్స్ సమస్యలను పరిష్కరించాలో నేను మీకు చెప్పాలనుకుంటున్నాను. ఓపెన్‌స్టాక్‌లో ఉత్పత్తులను అభివృద్ధి చేసే వారికి ఇది ఆసక్తికరంగా ఉంటుందని నేను భావిస్తున్నాను.

ప్లాట్‌ఫారమ్ యొక్క మొత్తం తప్పు సహనం దాని భాగాల యొక్క స్థితిస్థాపకతను కలిగి ఉంటుంది. కాబట్టి మేము ప్రమాదాలను గుర్తించిన మరియు వాటిని మూసివేసిన అన్ని స్థాయిల ద్వారా క్రమంగా వెళ్తాము.

ఈ కథనం యొక్క వీడియో వెర్షన్, దీని యొక్క ప్రాథమిక మూలం అప్‌టైమ్ డే 4 కాన్ఫరెన్స్‌లో నిర్వహించబడిన నివేదిక ITSumma, మీరు చూడగలరు అప్‌టైమ్ కమ్యూనిటీ YouTube ఛానెల్‌లో.

భౌతిక నిర్మాణం యొక్క స్థితిస్థాపకత

MCS క్లౌడ్ యొక్క పబ్లిక్ భాగం ఇప్పుడు రెండు టైర్ III డేటా సెంటర్‌లలో ఉంది, వాటి మధ్య దాని స్వంత డార్క్ ఫైబర్ ఉంది, భౌతిక స్థాయిలో వివిధ మార్గాల ద్వారా రిజర్వ్ చేయబడింది, 200 Gbit/s నిర్గమాంశం. టైర్ III ఫిజికల్ ఇన్‌ఫ్రాస్ట్రక్చర్‌కు అవసరమైన స్థాయి లోపాలను తట్టుకునే స్థాయిని అందిస్తుంది.

డార్క్ ఫైబర్ భౌతిక మరియు తార్కిక స్థాయిలలో రిజర్వ్ చేయబడింది. ఛానెల్ రిజర్వేషన్ ప్రక్రియ పునరావృతమైంది, సమస్యలు తలెత్తాయి మరియు మేము డేటా కేంద్రాల మధ్య కమ్యూనికేషన్‌ను నిరంతరం మెరుగుపరుస్తున్నాము.

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

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

ప్రొవైడర్ విఫలమైతే, మేము ఆటోమేటిక్‌గా తదుపరి దానికి మారుతాము. డేటా సెంటర్‌లలో ఒకటి విఫలమైన సందర్భంలో, మేము రెండవ డేటా సెంటర్‌లో మా సేవల యొక్క మిర్రర్ కాపీని కలిగి ఉన్నాము, ఇది మొత్తం లోడ్‌ను తీసుకుంటుంది.

భౌతిక అవస్థాపన యొక్క స్థితిస్థాపకత

అప్లికేషన్-లెవల్ ఫాల్ట్ టాలరెన్స్ కోసం మేము ఏమి ఉపయోగిస్తాము

మా సేవ అనేక ఓపెన్‌సోర్స్ భాగాలపై నిర్మించబడింది.

ExaBGP BGP-ఆధారిత డైనమిక్ రూటింగ్ ప్రోటోకాల్‌ని ఉపయోగించి అనేక ఫంక్షన్‌లను అమలు చేసే సేవ. వినియోగదారులు APIని యాక్సెస్ చేసే మా వైట్‌లిస్ట్ చేసిన IP చిరునామాలను ప్రచారం చేయడానికి మేము దీన్ని చురుకుగా ఉపయోగిస్తాము.

HAProxy OSI మోడల్ యొక్క వివిధ స్థాయిలలో చాలా సౌకర్యవంతమైన ట్రాఫిక్ బ్యాలెన్సింగ్ నియమాలను కాన్ఫిగర్ చేయడానికి మిమ్మల్ని అనుమతించే అధిక-లోడ్ బాలన్సర్. మేము అన్ని సేవల ముందు బ్యాలెన్స్ చేయడానికి దీన్ని ఉపయోగిస్తాము: డేటాబేస్‌లు, సందేశ బ్రోకర్లు, API సేవలు, వెబ్ సేవలు, మా అంతర్గత ప్రాజెక్ట్‌లు - ప్రతిదీ HAProxy వెనుక ఉంది.

API అప్లికేషన్ — పైథాన్‌లో వ్రాయబడిన వెబ్ అప్లికేషన్, దానితో వినియోగదారు తన మౌలిక సదుపాయాలను మరియు అతని సేవను నిర్వహిస్తారు.

వర్కర్ అప్లికేషన్ (ఇకపై కేవలం వర్కర్) - ఓపెన్‌స్టాక్ సేవల్లో, ఇది ఇన్‌ఫ్రాస్ట్రక్చర్ డెమోన్, ఇది ఇన్‌ఫ్రాస్ట్రక్చర్‌కు API ఆదేశాలను ప్రసారం చేయడానికి మిమ్మల్ని అనుమతిస్తుంది. ఉదాహరణకు, డిస్క్ సృష్టి వర్కర్‌లో జరుగుతుంది మరియు సృష్టి అభ్యర్థన అప్లికేషన్ APIలో జరుగుతుంది.

ప్రామాణిక ఓపెన్‌స్టాక్ అప్లికేషన్ ఆర్కిటెక్చర్

OpenStack కోసం అభివృద్ధి చేయబడిన చాలా సేవలు ఒకే నమూనాను అనుసరించడానికి ప్రయత్నిస్తాయి. సేవ సాధారణంగా 2 భాగాలను కలిగి ఉంటుంది: API మరియు కార్మికులు (బ్యాకెండ్ ఎగ్జిక్యూటర్లు). నియమం ప్రకారం, API అనేది పైథాన్‌లోని WSGI అప్లికేషన్, ఇది స్వతంత్ర ప్రక్రియగా (డెమన్) లేదా రెడీమేడ్ Nginx లేదా Apache వెబ్ సర్వర్‌ని ఉపయోగించి ప్రారంభించబడుతుంది. API వినియోగదారు అభ్యర్థనను ప్రాసెస్ చేస్తుంది మరియు అమలు కోసం వర్కర్ అప్లికేషన్‌కు తదుపరి సూచనలను పంపుతుంది. బదిలీ అనేది మెసేజ్ బ్రోకర్‌ని ఉపయోగించి జరుగుతుంది, సాధారణంగా RabbitMQ, ఇతరులకు సరైన మద్దతు లేదు. సందేశాలు బ్రోకర్‌కు చేరినప్పుడు, వాటిని కార్మికులు ప్రాసెస్ చేస్తారు మరియు అవసరమైతే, ప్రతిస్పందనను అందించండి.

ఈ నమూనా వైఫల్యం యొక్క వివిక్త సాధారణ పాయింట్లను కలిగి ఉంటుంది: RabbitMQ మరియు డేటాబేస్. కానీ RabbitMQ ఒక సేవలో వేరుచేయబడింది మరియు సిద్ధాంతపరంగా, ప్రతి సేవకు వ్యక్తిగతంగా ఉంటుంది. కాబట్టి MCS వద్ద మేము ఈ సేవలను వీలైనంత వరకు వేరు చేస్తాము; ప్రతి వ్యక్తిగత ప్రాజెక్ట్ కోసం మేము ప్రత్యేక డేటాబేస్, ప్రత్యేక RabbitMQని సృష్టిస్తాము. ఈ విధానం మంచిది ఎందుకంటే కొన్ని హాని కలిగించే పాయింట్ల వద్ద ప్రమాదం జరిగినప్పుడు, మొత్తం సేవ విచ్ఛిన్నం కాదు, కానీ దానిలో కొంత భాగం మాత్రమే.

వర్కర్ అప్లికేషన్‌ల సంఖ్య అపరిమితంగా ఉంటుంది, కాబట్టి API పనితీరును మరియు తప్పును తట్టుకునే సామర్థ్యాన్ని పెంచడానికి బ్యాలెన్సర్‌ల వెనుక క్షితిజ సమాంతరంగా స్కేల్ చేయగలదు.

APIలు మరియు కార్మికుల మధ్య సంక్లిష్టమైన సీక్వెన్షియల్ కార్యకలాపాలు జరిగినప్పుడు కొన్ని సేవలకు సేవలో సమన్వయం అవసరం. ఈ సందర్భంలో, ఒకే కోఆర్డినేషన్ సెంటర్ ఉపయోగించబడుతుంది, Redis, Memcache, etcd వంటి క్లస్టర్ సిస్టమ్, ఈ పని తనకు కేటాయించబడిందని మరొకరికి చెప్పడానికి అనుమతిస్తుంది ("దయచేసి దానిని తీసుకోకండి"). మేము etcd ఉపయోగిస్తాము. నియమం ప్రకారం, కార్మికులు డేటాబేస్తో చురుకుగా కమ్యూనికేట్ చేస్తారు, అక్కడ నుండి సమాచారాన్ని వ్రాయండి మరియు చదవండి. మేము mariadbని డేటాబేస్‌గా ఉపయోగిస్తాము, ఇది మల్టీమాస్టర్ క్లస్టర్‌లో ఉంది.

ఈ క్లాసిక్ సింగిల్ సర్వీస్ ఓపెన్‌స్టాక్ కోసం సాధారణంగా ఆమోదించబడిన పద్ధతిలో నిర్వహించబడుతుంది. ఇది ఒక క్లోజ్డ్ సిస్టమ్‌గా పరిగణించబడుతుంది, దీని కోసం స్కేలింగ్ మరియు తప్పు సహనం యొక్క పద్ధతులు చాలా స్పష్టంగా ఉన్నాయి. ఉదాహరణకు, API తప్పు సహనం కోసం, వాటి ముందు బ్యాలెన్సర్‌ను ఉంచడం సరిపోతుంది. స్కేలింగ్ కార్మికులు వారి సంఖ్యను పెంచడం ద్వారా సాధించవచ్చు.

మొత్తం పథకంలో బలహీనమైన అంశం RabbitMQ మరియు MariaDB. వారి ఆర్కిటెక్చర్ ప్రత్యేక కథనానికి అర్హమైనది. ఈ కథనంలో నేను API తప్పు సహనంపై దృష్టి పెట్టాలనుకుంటున్నాను.

ఓపెన్‌స్టాక్ అప్లికేషన్ ఆర్కిటెక్చర్. క్లౌడ్ ప్లాట్‌ఫారమ్ యొక్క బ్యాలెన్సింగ్ మరియు ఫాల్ట్ టాలరెన్స్

ExaBGPని ఉపయోగించి HAProxy balancer‌ని తప్పు-తట్టుకునేలా చేయడం

మా APIలను స్కేలబుల్, వేగవంతమైన మరియు తప్పులను తట్టుకునేలా చేయడానికి, మేము వాటి ముందు లోడ్ బ్యాలెన్సర్‌ను ఉంచాము. మేము HAProxyని ఎంచుకున్నాము. నా అభిప్రాయం ప్రకారం, ఇది మా పనికి అవసరమైన అన్ని లక్షణాలను కలిగి ఉంది: అనేక OSI స్థాయిలలో బ్యాలెన్సింగ్, నిర్వహణ ఇంటర్‌ఫేస్, వశ్యత మరియు స్కేలబిలిటీ, పెద్ద సంఖ్యలో బ్యాలెన్సింగ్ పద్ధతులు, సెషన్ టేబుల్‌లకు మద్దతు.

పరిష్కరించాల్సిన మొదటి సమస్య బ్యాలెన్సర్ యొక్క తప్పు సహనం. కేవలం బ్యాలెన్సర్‌ను ఇన్‌స్టాల్ చేయడం కూడా వైఫల్యాన్ని సృష్టిస్తుంది: బ్యాలెన్సర్ విచ్ఛిన్నమవుతుంది మరియు సేవ క్రాష్ అవుతుంది. ఇది జరగకుండా నిరోధించడానికి, మేము ExaBGPతో కలిపి HAProxyని ఉపయోగించాము.

ExaBGP సేవ యొక్క స్థితిని తనిఖీ చేయడానికి ఒక యంత్రాంగాన్ని అమలు చేయడానికి మిమ్మల్ని అనుమతిస్తుంది. మేము HAProxy యొక్క కార్యాచరణను తనిఖీ చేయడానికి ఈ మెకానిజమ్‌ని ఉపయోగించాము మరియు సమస్యలు ఉన్నట్లయితే, BGP నుండి HAProxy సేవను నిలిపివేయండి.

ExaBGP+HAProxy పథకం

1. మేము మూడు సర్వర్‌లలో అవసరమైన సాఫ్ట్‌వేర్, ExaBGP మరియు HAProxyని ఇన్‌స్టాల్ చేస్తాము.
2. మేము ప్రతి సర్వర్‌లో లూప్‌బ్యాక్ ఇంటర్‌ఫేస్‌ను సృష్టిస్తాము.
3. మూడు సర్వర్‌లలో మేము ఈ ఇంటర్‌ఫేస్‌కు ఒకే తెలుపు IP చిరునామాను కేటాయిస్తాము.
4. ExaBGP ద్వారా తెల్లటి IP చిరునామా ఇంటర్నెట్‌లో ప్రచారం చేయబడుతుంది.

మూడు సర్వర్‌ల నుండి ఒకే IP చిరునామాను ప్రకటించడం ద్వారా తప్పు సహనం సాధించబడుతుంది. నెట్‌వర్క్ పాయింట్ ఆఫ్ వ్యూ నుండి, ఒకే చిరునామా మూడు వేర్వేరు తదుపరి హాప్‌ల నుండి యాక్సెస్ చేయబడుతుంది. రూటర్ మూడు సారూప్య మార్గాలను చూస్తుంది, దాని స్వంత మెట్రిక్ (ఇది సాధారణంగా అదే ఎంపిక) ఆధారంగా వాటిలో అత్యధిక ప్రాధాన్యతను ఎంచుకుంటుంది మరియు ట్రాఫిక్ సర్వర్‌లలో ఒకదానికి మాత్రమే వెళుతుంది.

HAProxy యొక్క ఆపరేషన్‌లో సమస్యలు లేదా సర్వర్ వైఫల్యం సంభవించినప్పుడు, ExaBGP మార్గాన్ని ప్రకటించడాన్ని ఆపివేస్తుంది మరియు ట్రాఫిక్ సజావుగా మరొక సర్వర్‌కు మారుతుంది.

అందువలన, మేము బాలన్సర్ యొక్క తప్పు సహనాన్ని సాధించాము.

HAProxy balancers యొక్క తప్పు సహనం

పథకం అసంపూర్ణంగా మారింది: మేము HAProxyని ఎలా రిజర్వ్ చేయాలో నేర్చుకున్నాము, కానీ సేవల్లో లోడ్‌ను ఎలా పంపిణీ చేయాలో నేర్చుకోలేదు. అందువల్ల, మేము ఈ పథకాన్ని కొద్దిగా విస్తరించాము: మేము అనేక తెల్లని IP చిరునామాల మధ్య బ్యాలెన్సింగ్‌కు వెళ్లాము.

DNS ప్లస్ BGP ఆధారంగా బ్యాలెన్సింగ్

మా HAProxy కోసం లోడ్ బ్యాలెన్సింగ్ సమస్య పరిష్కరించబడలేదు. అయితే, మేము ఇక్కడ చేసినట్లుగా ఇది చాలా సరళంగా పరిష్కరించబడుతుంది.

మూడు సర్వర్‌లను బ్యాలెన్స్ చేయడానికి మీకు 3 తెలుపు IP చిరునామాలు మరియు మంచి పాత DNS అవసరం. ఈ చిరునామాలలో ప్రతి ఒక్కటి ప్రతి HAProxy యొక్క లూప్‌బ్యాక్ ఇంటర్‌ఫేస్‌లో నిర్ణయించబడుతుంది మరియు ఇంటర్నెట్‌కు ప్రచారం చేయబడుతుంది.

OpenStackలో, వనరులను నిర్వహించడానికి, సేవా డైరెక్టరీ ఉపయోగించబడుతుంది, ఇది నిర్దిష్ట సేవ యొక్క ముగింపు APIని నిర్దేశిస్తుంది. ఈ డైరెక్టరీలో మేము డొమైన్ పేరును నమోదు చేస్తాము - public.infra.mail.ru, ఇది మూడు వేర్వేరు IP చిరునామాల ద్వారా DNS ద్వారా పరిష్కరించబడుతుంది. ఫలితంగా, మేము DNS ద్వారా మూడు చిరునామాల మధ్య లోడ్ పంపిణీని పొందుతాము.

కానీ తెలుపు IP చిరునామాలను ప్రకటించేటప్పుడు మేము సర్వర్ ఎంపిక ప్రాధాన్యతలను నియంత్రించలేము, ఇది ఇంకా బ్యాలెన్స్ చేయడం లేదు. సాధారణంగా, IP చిరునామా సీనియారిటీ ఆధారంగా ఒక సర్వర్ మాత్రమే ఎంపిక చేయబడుతుంది మరియు BGPలో కొలమానాలు ఏవీ పేర్కొనబడనందున మిగిలిన రెండు నిష్క్రియంగా ఉంటాయి.

మేము వివిధ కొలమానాలతో ExaBGP ద్వారా మార్గాలను పంపడం ప్రారంభించాము. ప్రతి బాలన్సర్ మూడు తెలుపు IP చిరునామాలను ప్రచారం చేస్తుంది, కానీ వాటిలో ఒకటి, ఈ బ్యాలెన్సర్‌కు ప్రధానమైనది, కనీస మెట్రిక్‌తో ప్రచారం చేయబడుతుంది. కాబట్టి మూడు బ్యాలెన్సర్‌లు పని చేస్తున్నప్పుడు, మొదటి IP చిరునామాకు కాల్‌లు మొదటి బ్యాలెన్సర్‌కు వెళ్తాయి, రెండవ దానికి కాల్‌లు మరియు మూడవ దానికి కాల్‌లు.

బ్యాలెన్సర్‌లలో ఒకరు పడిపోయినప్పుడు ఏమి జరుగుతుంది? ఏదైనా బ్యాలెన్సర్ విఫలమైతే, దాని ప్రధాన చిరునామా మిగిలిన రెండింటి నుండి ఇప్పటికీ ప్రచారం చేయబడుతుంది మరియు వాటి మధ్య ట్రాఫిక్ పునఃపంపిణీ చేయబడుతుంది. అందువలన, మేము DNS ద్వారా వినియోగదారుకు ఒకేసారి అనేక IP చిరునామాలను అందిస్తాము. DNS మరియు విభిన్న మెట్రిక్‌ల ద్వారా బ్యాలెన్స్ చేయడం ద్వారా, మేము మూడు బ్యాలెన్సర్‌లలో లోడ్ యొక్క సమాన పంపిణీని పొందుతాము. మరియు అదే సమయంలో మేము తప్పు సహనాన్ని కోల్పోము.

DNS + BGP ఆధారంగా HAProxyని బ్యాలెన్స్ చేస్తోంది

ExaBGP మరియు HAProxy మధ్య పరస్పర చర్య

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

అందువల్ల, మునుపటి పథకాన్ని విస్తరిస్తూ, మేము ExaBGP మరియు HAProxy మధ్య హృదయ స్పందనను అమలు చేసాము. అప్లికేషన్‌ల స్థితిని తనిఖీ చేయడానికి ExaBGP అనుకూల స్క్రిప్ట్‌లను ఉపయోగించినప్పుడు, ఇది ExaBGP మరియు HAProxy మధ్య పరస్పర చర్య యొక్క సాఫ్ట్‌వేర్ అమలు.

దీన్ని చేయడానికి, మీరు HAProxy స్థితిని తనిఖీ చేయగల ExaBGP కాన్ఫిగర్‌లో హెల్త్ చెకర్‌ను కాన్ఫిగర్ చేయాలి. మా విషయంలో, మేము ఆరోగ్య బ్యాకెండ్‌ను HAProxyలో కాన్ఫిగర్ చేసాము మరియు ExaBGP వైపు నుండి మేము సాధారణ GET అభ్యర్థనతో తనిఖీ చేస్తాము. ప్రకటన జరగడం ఆగిపోయినట్లయితే, HAProxy ఎక్కువగా పని చేయదు మరియు దానిని ప్రచారం చేయవలసిన అవసరం లేదు.

HAProxy ఆరోగ్య తనిఖీ

HAProxy పీర్స్: సెషన్ సింక్రొనైజేషన్

సెషన్‌లను సమకాలీకరించడం తదుపరి విషయం. పంపిణీ చేయబడిన బాలన్సర్ల ద్వారా పని చేస్తున్నప్పుడు, క్లయింట్ సెషన్ల గురించి సమాచారాన్ని నిల్వ చేయడం కష్టం. కానీ పీర్స్ ఫంక్షనాలిటీ కారణంగా దీన్ని చేయగల కొన్ని బ్యాలెన్సర్‌లలో HAProxy ఒకటి - వివిధ HAProxy ప్రక్రియల మధ్య సెషన్ టేబుల్‌లను బదిలీ చేయగల సామర్థ్యం.

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

HAProxy ఈ మెకానిజం యొక్క క్లయింట్ సెషన్‌లను సేవ్ చేయడానికి స్టిక్-టేబుల్‌లను ఉపయోగిస్తుంది. వారు క్లయింట్ యొక్క అసలు IP చిరునామా, ఎంచుకున్న లక్ష్య చిరునామా (బ్యాకెండ్) మరియు కొంత సేవా సమాచారాన్ని సేవ్ చేస్తారు. సాధారణంగా, స్టిక్ టేబుల్‌లు సోర్స్-IP + డెస్టినేషన్-IP జతని నిల్వ చేయడానికి ఉపయోగించబడతాయి, ఇది మరొక బ్యాలెన్సర్‌కు మారేటప్పుడు వినియోగదారు సెషన్ సందర్భాన్ని బదిలీ చేయలేని అప్లికేషన్‌లకు ప్రత్యేకంగా ఉపయోగపడుతుంది, ఉదాహరణకు, రౌండ్‌రాబిన్ బ్యాలెన్సింగ్ మోడ్‌లో.

వివిధ HAProxy ప్రక్రియల మధ్య (బ్యాలన్సింగ్ జరుగుతుంది) మధ్య కదలడానికి స్టిక్ టేబుల్ నేర్పితే, మా బ్యాలెన్సర్‌లు ఒక పూల్ స్టిక్ టేబుల్‌లతో పని చేయగలుగుతారు. బ్యాలెన్సర్‌లలో ఒకటి విఫలమైతే క్లయింట్ నెట్‌వర్క్‌ను సజావుగా మార్చడం ఇది సాధ్యపడుతుంది; క్లయింట్ సెషన్‌లతో పని ఇంతకు ముందు ఎంచుకున్న అదే బ్యాకెండ్‌లలో కొనసాగుతుంది.

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

సహచరుల సరైన పని కొన్ని పరిస్థితులలో మాత్రమే సాధించబడుతుంది. అంటే, TCP సమయం ముగిసే సమయాలు తగినంతగా ఉండాలి లేదా మారడం తగినంత వేగంగా ఉండాలి, తద్వారా TCP సెషన్‌ను ముగించడానికి సమయం ఉండదు. అయితే, ఇది అతుకులు లేకుండా మారడానికి అనుమతిస్తుంది.

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

చిత్రం మూడు HAProxy ఉదంతాల మధ్య పీర్ పట్టికల కదలికను క్రమపద్ధతిలో చూపుతుంది, దీన్ని ఎలా కాన్ఫిగర్ చేయాలి అనే దానిపై కాన్ఫిగర్ ప్రతిపాదించబడింది:

HAProxy పీర్స్ (సెషన్ సింక్రొనైజేషన్)

మీరు అదే పథకాన్ని అమలు చేస్తే, దాని ఆపరేషన్ జాగ్రత్తగా పరీక్షించబడాలి. ఇది 100% సమయం అదే విధంగా పని చేస్తుందనేది వాస్తవం కాదు. మీరు క్లయింట్ యొక్క మూలం IPని గుర్తుంచుకోవాల్సిన అవసరం వచ్చినప్పుడు కనీసం మీరు స్టిక్ టేబుల్‌లను కోల్పోరు.

ఒకే క్లయింట్ నుండి ఏకకాల అభ్యర్థనల సంఖ్యను పరిమితం చేయడం

మా APIలతో సహా పబ్లిక్‌గా అందుబాటులో ఉన్న ఏవైనా సేవలు అభ్యర్థనల హిమపాతాలకు లోబడి ఉండవచ్చు. వినియోగదారు లోపాల నుండి లక్ష్య దాడుల వరకు వాటికి కారణాలు పూర్తిగా భిన్నంగా ఉంటాయి. మేము IP చిరునామాల ద్వారా కాలానుగుణంగా DDoSed చేస్తాము. క్లయింట్లు తరచుగా వారి స్క్రిప్ట్‌లలో తప్పులు చేస్తారు మరియు మాకు చిన్న-DDoSలను అందిస్తారు.

ఒక మార్గం లేదా మరొకటి, అదనపు రక్షణను అందించాలి. స్పష్టమైన పరిష్కారం API అభ్యర్థనల సంఖ్యను పరిమితం చేయడం మరియు హానికరమైన అభ్యర్థనలను ప్రాసెస్ చేయడంలో CPU సమయాన్ని వృథా చేయకూడదు.

అటువంటి పరిమితులను అమలు చేయడానికి, మేము HAProxy ఆధారంగా నిర్వహించబడే రేటు పరిమితులను ఉపయోగిస్తాము, అదే స్టిక్ టేబుల్‌లను ఉపయోగిస్తాము. పరిమితులను సెటప్ చేయడం చాలా సులభం మరియు APIకి అభ్యర్థనల సంఖ్య ద్వారా వినియోగదారుని పరిమితం చేయడానికి మిమ్మల్ని అనుమతిస్తుంది. అల్గోరిథం అభ్యర్థనలు చేసిన సోర్స్ IPని గుర్తుంచుకుంటుంది మరియు ఒక వినియోగదారు నుండి ఏకకాల అభ్యర్థనల సంఖ్యను పరిమితం చేస్తుంది. వాస్తవానికి, మేము ప్రతి సేవకు సగటు API లోడ్ ప్రొఫైల్‌ను లెక్కించాము మరియు ఈ విలువకు ≈ 10 రెట్లు పరిమితిని సెట్ చేసాము. మేము పరిస్థితిని నిశితంగా పర్యవేక్షిస్తూనే ఉంటాము మరియు మా వేలును పల్స్‌లో ఉంచుతాము.

ఇది ఆచరణలో ఎలా కనిపిస్తుంది? మా ఆటోస్కేలింగ్ APIలను ఎల్లవేళలా ఉపయోగించే కస్టమర్‌లు మా వద్ద ఉన్నారు. వారు ఉదయం సుమారు రెండు నుండి మూడు వందల వర్చువల్ మిషన్లను సృష్టించి, సాయంత్రం వాటిని తొలగిస్తారు. OpenStack కోసం, PaaS సేవలతో పాటు వర్చువల్ మెషీన్‌ను సృష్టించడానికి కనీసం 1000 API అభ్యర్థనలు అవసరం, ఎందుకంటే సేవల మధ్య పరస్పర చర్య API ద్వారా కూడా జరుగుతుంది.

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

వినియోగదారులు గమనించకుండా మీ కోడ్‌బేస్‌ను ఎలా అప్‌డేట్ చేయాలి

మేము కోడ్ విస్తరణ ప్రక్రియల స్థాయిలో తప్పు సహనాన్ని కూడా అమలు చేస్తాము. రోల్‌అవుట్‌ల సమయంలో అవాంతరాలు ఉండవచ్చు, కానీ సేవా లభ్యతపై వాటి ప్రభావాన్ని తగ్గించవచ్చు.

మేము మా సేవలను నిరంతరం అప్‌డేట్ చేస్తాము మరియు వినియోగదారులను ప్రభావితం చేయకుండా కోడ్‌బేస్ అప్‌డేట్ చేయబడిందని నిర్ధారించుకోవాలి. మేము HAProxy యొక్క నిర్వహణ సామర్థ్యాలను మరియు మా సేవల్లో గ్రేస్‌ఫుల్ షట్‌డౌన్ అమలును ఉపయోగించి ఈ సమస్యను పరిష్కరించగలిగాము.

ఈ సమస్యను పరిష్కరించడానికి, బ్యాలెన్సర్ నియంత్రణ మరియు సేవల "సరైన" షట్‌డౌన్‌ను నిర్ధారించడం అవసరం:

• HAProxy విషయంలో, నియంత్రణ అనేది గణాంకాల ఫైల్ ద్వారా నిర్వహించబడుతుంది, ఇది తప్పనిసరిగా సాకెట్ మరియు HAProxy కాన్ఫిగర్‌లో నిర్వచించబడింది. మీరు stdio ద్వారా దీనికి ఆదేశాలను పంపవచ్చు. కానీ మా ప్రధాన కాన్ఫిగరేషన్ నియంత్రణ సాధనం అన్‌సిబుల్, కాబట్టి ఇది HAProxyని నిర్వహించడానికి అంతర్నిర్మిత మాడ్యూల్‌ను కలిగి ఉంది. మేము చురుకుగా ఉపయోగించేవి.
• మా API మరియు ఇంజిన్ సేవల్లో చాలా వరకు ఆకర్షణీయమైన షట్‌డౌన్ సాంకేతికతలకు మద్దతిస్తాయి: షట్ డౌన్ చేసినప్పుడు, అవి http అభ్యర్థన లేదా ఏదైనా సేవా కార్యం అయిన ప్రస్తుత పని పూర్తయ్యే వరకు వేచి ఉంటాయి. కార్మికుడి విషయంలో కూడా అదే జరుగుతుంది. ఇది తాను చేస్తున్న అన్ని పనులను తెలుసుకుంటుంది మరియు ప్రతిదీ విజయవంతంగా పూర్తి చేసిన తర్వాత ముగుస్తుంది.

ఈ రెండు పాయింట్లకు ధన్యవాదాలు, మా విస్తరణ కోసం సురక్షిత అల్గోరిథం ఇలా కనిపిస్తుంది.

1. డెవలపర్ కొత్త కోడ్ ప్యాకేజీని సమీకరించారు (మనకు ఇది RPM), దానిని dev వాతావరణంలో పరీక్షిస్తుంది, దశలో పరీక్షిస్తుంది మరియు స్టేజ్ రిపోజిటరీలో వదిలివేస్తుంది.
2. డెవలపర్ "కళాఖండాలు" యొక్క అత్యంత వివరణాత్మక వర్ణనతో విస్తరణ కోసం పనిని సెట్ చేస్తాడు: కొత్త ప్యాకేజీ యొక్క సంస్కరణ, కొత్త కార్యాచరణ యొక్క వివరణ మరియు అవసరమైతే విస్తరణ గురించి ఇతర వివరాలు.
3. సిస్టమ్ అడ్మినిస్ట్రేటర్ నవీకరణను ప్రారంభిస్తాడు. అన్సిబుల్ ప్లేబుక్‌ను ప్రారంభిస్తుంది, ఇది క్రింది వాటిని చేస్తుంది:
   • స్టేజ్ రిపోజిటరీ నుండి ప్యాకేజీని తీసుకుంటుంది మరియు ఉత్పత్తి రిపోజిటరీలో ప్యాకేజీ సంస్కరణను నవీకరించడానికి దాన్ని ఉపయోగిస్తుంది.
   • నవీకరించబడిన సేవ యొక్క బ్యాకెండ్‌ల జాబితాను కంపైల్ చేస్తుంది.
   • HAProxyలో అప్‌డేట్ చేయాల్సిన మొదటి సర్వీస్‌ను మూసివేస్తుంది మరియు దాని ప్రాసెస్‌లు రన్ అయ్యే వరకు వేచి ఉంటుంది. అందమైన షట్‌డౌన్‌కు ధన్యవాదాలు, ప్రస్తుత క్లయింట్ అభ్యర్థనలన్నీ విజయవంతంగా పూర్తవుతాయని మేము విశ్వసిస్తున్నాము.
   • API మరియు వర్కర్లు పూర్తిగా నిలిపివేయబడిన తర్వాత మరియు HAProxy ఆఫ్ చేయబడిన తర్వాత, కోడ్ నవీకరించబడుతుంది.
   • అన్సిబుల్ సేవలను నడుపుతుంది.
   • ప్రతి సేవ కోసం, నిర్దిష్ట "హ్యాండిల్స్" లాగబడతాయి, ఇవి ముందుగా నిర్వచించబడిన అనేక కీ పరీక్షలలో యూనిట్ పరీక్షను నిర్వహిస్తాయి. కొత్త కోడ్ యొక్క ప్రాథమిక తనిఖీ జరుగుతుంది.
   • మునుపటి దశలో లోపాలు కనుగొనబడకపోతే, బ్యాకెండ్ సక్రియం చేయబడుతుంది.
   • తదుపరి బ్యాకెండ్‌కి వెళ్దాం.
4. అన్ని బ్యాకెండ్‌లు నవీకరించబడిన తర్వాత, ఫంక్షనల్ పరీక్షలు ప్రారంభించబడతాయి. అవి తప్పిపోయినట్లయితే, డెవలపర్ అతను సృష్టించిన ఏదైనా కొత్త కార్యాచరణను చూస్తాడు.

ఇది విస్తరణను పూర్తి చేస్తుంది.

సేవా నవీకరణ చక్రం

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

తీర్మానం

తప్పు-తట్టుకునే వెబ్ ఆర్కిటెక్చర్ గురించి నా స్వంత ఆలోచనలను పంచుకుంటూ, నేను దాని ముఖ్య అంశాలను మరోసారి గమనించాలనుకుంటున్నాను:

• శారీరక తప్పు సహనం;
• నెట్వర్క్ తప్పు సహనం (బ్యాలెన్సర్లు, BGP);
• ఉపయోగించిన మరియు అభివృద్ధి చేసిన సాఫ్ట్‌వేర్ యొక్క తప్పు సహనం.

ప్రతి ఒక్కరికీ స్థిరమైన సమయము!

మూలం: www.habr.com