Yandex.Cloudలో నెట్‌వర్క్ లోడ్ బ్యాలెన్సర్ యొక్క ఆర్కిటెక్చర్

హలో, నేను సెర్గీ ఎలాంట్సేవ్, నేను అభివృద్ధి చేస్తున్నాను నెట్వర్క్ లోడ్ బాలన్సర్ Yandex.Cloudలో. ఇంతకుముందు, నేను Yandex పోర్టల్ కోసం L7 బాలన్సర్ అభివృద్ధికి నాయకత్వం వహించాను - నేను ఏమి చేసినా అది బ్యాలెన్సర్‌గా మారుతుందని సహచరులు చమత్కరించారు. క్లౌడ్ ప్లాట్‌ఫారమ్‌లో లోడ్‌ను ఎలా నిర్వహించాలో, ఈ లక్ష్యాన్ని సాధించడానికి అనువైన సాధనంగా మనం ఏమి చూస్తామో మరియు ఈ సాధనాన్ని ఎలా నిర్మించాలో నేను హబ్ర్ రీడర్‌లకు చెబుతాను.

ముందుగా, కొన్ని నిబంధనలను పరిచయం చేద్దాం:

• VIP (వర్చువల్ IP) - బ్యాలెన్సర్ IP చిరునామా
• సర్వర్, బ్యాకెండ్, ఉదాహరణ - అప్లికేషన్‌ను అమలు చేస్తున్న వర్చువల్ మెషీన్
• RIP (రియల్ IP) - సర్వర్ IP చిరునామా
• ఆరోగ్య తనిఖీ - సర్వర్ సంసిద్ధతను తనిఖీ చేస్తోంది
• లభ్యత జోన్, AZ - డేటా సెంటర్‌లో ఐసోలేటెడ్ ఇన్‌ఫ్రాస్ట్రక్చర్
• ప్రాంతం - వివిధ AZల యూనియన్

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

ఒక లోడ్ బ్యాలెన్సర్ తరచుగా అది పనిచేసే OSI మోడల్ నుండి ప్రోటోకాల్ లేయర్ ద్వారా వర్గీకరించబడుతుంది. క్లౌడ్ బ్యాలెన్సర్ TCP స్థాయిలో పనిచేస్తుంది, ఇది నాల్గవ లేయర్, L4కి అనుగుణంగా ఉంటుంది.

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

డేటా విమానం

సరిహద్దు రౌటర్లు అని పిలువబడే ఖరీదైన పరికరాలపై ట్రాఫిక్ ముగుస్తుంది. తప్పు సహనాన్ని పెంచడానికి, అటువంటి అనేక పరికరాలు ఒక డేటా సెంటర్‌లో ఏకకాలంలో పనిచేస్తాయి. తర్వాత, ట్రాఫిక్ బ్యాలెన్సర్‌లకు వెళుతుంది, ఇది క్లయింట్‌ల కోసం BGP ద్వారా అన్ని AZలకు ఏదైనా IP చిరునామాలను ప్రకటిస్తుంది. 

ట్రాఫిక్ ECMP ద్వారా ప్రసారం చేయబడుతుంది - ఇది రౌటింగ్ వ్యూహం, దీని ప్రకారం లక్ష్యానికి సమానమైన అనేక మార్గాలు ఉండవచ్చు (మా విషయంలో, లక్ష్యం గమ్యం IP చిరునామా అవుతుంది) మరియు ప్యాకెట్‌లను వాటిలో దేనితోనైనా పంపవచ్చు. మేము కింది పథకం ప్రకారం అనేక లభ్యత జోన్‌లలో పని చేయడానికి కూడా మద్దతు ఇస్తున్నాము: మేము ప్రతి జోన్‌లో చిరునామాను ప్రచారం చేస్తాము, ట్రాఫిక్ సమీపంలోని ఒకదానికి వెళుతుంది మరియు దాని పరిమితులను దాటి వెళ్లదు. తర్వాత పోస్ట్‌లో ట్రాఫిక్‌కు ఏమి జరుగుతుందో మరింత వివరంగా పరిశీలిస్తాము.

కాన్ఫిగర్ విమానం

 
కాన్ఫిగర్ ప్లేన్‌లోని ముఖ్య భాగం API, దీని ద్వారా బ్యాలెన్సర్‌లతో ప్రాథమిక కార్యకలాపాలు నిర్వహించబడతాయి: సృష్టించడం, తొలగించడం, ఉదాహరణల కూర్పును మార్చడం, ఆరోగ్య తనిఖీ ఫలితాలను పొందడం మొదలైనవి. ఒకవైపు, ఇది REST API, మరియు ఇతర, మేము క్లౌడ్‌లో చాలా తరచుగా ఫ్రేమ్‌వర్క్ gRPCని ఉపయోగిస్తాము, కాబట్టి మేము RESTని gRPCకి “అనువదిస్తాము” ఆపై gRPCని మాత్రమే ఉపయోగిస్తాము. ఏదైనా అభ్యర్థన Yandex.Cloud కార్మికుల సాధారణ పూల్‌లో అమలు చేయబడిన అసమకాలిక idempotent టాస్క్‌ల శ్రేణిని సృష్టించడానికి దారితీస్తుంది. టాస్క్‌లు ఎప్పుడైనా సస్పెండ్ చేయబడి, ఆపై మళ్లీ ప్రారంభించబడే విధంగా వ్రాయబడ్డాయి. ఇది కార్యకలాపాల స్కేలబిలిటీ, రిపీటబిలిటీ మరియు లాగింగ్‌ని నిర్ధారిస్తుంది.

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

సేవ దాని స్థితిని Yandex డేటాబేస్‌లో నిల్వ చేస్తుంది, పంపిణీ చేయబడిన నిర్వహించబడే డేటాబేస్ మీరు త్వరలో ఉపయోగించగలరు. Yandex.Cloudలో, మేము ఇప్పటికే చెప్పారు, డాగ్ ఫుడ్ కాన్సెప్ట్ వర్తిస్తుంది: మన సేవలను మనమే ఉపయోగిస్తే, మా క్లయింట్లు కూడా వాటిని ఉపయోగించడానికి సంతోషిస్తారు. Yandex డేటాబేస్ అటువంటి భావన అమలుకు ఒక ఉదాహరణ. మేము మా డేటా మొత్తాన్ని YDBలో నిల్వ చేస్తాము మరియు డేటాబేస్ను నిర్వహించడం మరియు స్కేలింగ్ చేయడం గురించి మేము ఆలోచించాల్సిన అవసరం లేదు: ఈ సమస్యలు మాకు పరిష్కరించబడతాయి, మేము డేటాబేస్ను సేవగా ఉపయోగిస్తాము.

బాలన్సర్ కంట్రోలర్‌కి తిరిగి వెళ్దాం. దీని పని బ్యాలెన్సర్ గురించి సమాచారాన్ని సేవ్ చేయడం మరియు వర్చువల్ మెషీన్ యొక్క సంసిద్ధతను హెల్త్‌చెక్ కంట్రోలర్‌కు తనిఖీ చేయడానికి ఒక పనిని పంపడం.

ఆరోగ్య తనిఖీ నియంత్రిక

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

ఆరోగ్య తనిఖీల గురించి మరింత మాట్లాడుకుందాం. వాటిని అనేక తరగతులుగా విభజించవచ్చు. ఆడిట్‌లు విభిన్న విజయ ప్రమాణాలను కలిగి ఉన్నాయి. TCP తనిఖీలు నిర్ణీత సమయంలో విజయవంతంగా కనెక్షన్‌ని ఏర్పాటు చేయాలి. HTTP తనిఖీలకు విజయవంతమైన కనెక్షన్ మరియు 200 స్థితి కోడ్‌తో ప్రతిస్పందన రెండూ అవసరం.

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

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

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

వ్యత్యాసం ఏమిటంటే ఖాతాదారులు VIPకి అభ్యర్థనలు చేస్తారు, అయితే ఆరోగ్య తనిఖీలు ప్రతి వ్యక్తి RIPకి అభ్యర్థనలు చేస్తాయి. ఇక్కడ ఒక ఆసక్తికరమైన సమస్య తలెత్తుతుంది: మేము మా వినియోగదారులకు బూడిద IP నెట్‌వర్క్‌లలో వనరులను సృష్టించే అవకాశాన్ని ఇస్తాము. బ్యాలెన్సర్‌ల వెనుక తమ సేవలను దాచిపెట్టిన ఇద్దరు వేర్వేరు క్లౌడ్ యజమానులు ఉన్నట్లు ఊహించుకుందాం. వాటిలో ప్రతి ఒక్కటి 10.0.0.1/24 సబ్‌నెట్‌లో ఒకే చిరునామాలతో వనరులను కలిగి ఉన్నాయి. మీరు వాటిని ఏదో ఒకవిధంగా వేరు చేయగలగాలి మరియు ఇక్కడ మీరు Yandex.Cloud వర్చువల్ నెట్‌వర్క్ యొక్క నిర్మాణంలోకి ప్రవేశించాలి. లో మరిన్ని వివరాలను తెలుసుకోవడం మంచిది గురించి:క్లౌడ్ ఈవెంట్ నుండి వీడియో, నెట్‌వర్క్ బహుళ-లేయర్డ్ మరియు సబ్‌నెట్ ఐడి ద్వారా వేరు చేయగల సొరంగాలను కలిగి ఉండటం ఇప్పుడు మాకు ముఖ్యం.

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

రివర్స్ ట్రాఫిక్ అదే విధంగా సాగుతుంది: బ్యాలెన్సర్ గమ్యం ఆరోగ్య తనిఖీదారుల నుండి బూడిద నెట్‌వర్క్ అని చూస్తాడు మరియు IPv4ని IPv6కి మారుస్తుంది.

VPP - డేటా ప్లేన్ యొక్క గుండె

బ్యాలెన్సర్ నెట్‌వర్క్ ట్రాఫిక్ యొక్క బ్యాచ్ ప్రాసెసింగ్ కోసం సిస్కో నుండి ఫ్రేమ్‌వర్క్ అయిన వెక్టర్ ప్యాకెట్ ప్రాసెసింగ్ (VPP) సాంకేతికతను ఉపయోగించి అమలు చేయబడుతుంది. మా సందర్భంలో, ఫ్రేమ్‌వర్క్ యూజర్-స్పేస్ నెట్‌వర్క్ పరికర నిర్వహణ లైబ్రరీ పైన పనిచేస్తుంది - డేటా ప్లేన్ డెవలప్‌మెంట్ కిట్ (DPDK). ఇది అధిక ప్యాకెట్ ప్రాసెసింగ్ పనితీరును నిర్ధారిస్తుంది: కెర్నల్‌లో చాలా తక్కువ అంతరాయాలు సంభవిస్తాయి మరియు కెర్నల్ స్థలం మరియు వినియోగదారు స్థలం మధ్య సందర్భ స్విచ్‌లు లేవు. 

VPP మరింత ముందుకు వెళుతుంది మరియు ప్యాకేజీలను బ్యాచ్‌లుగా కలపడం ద్వారా సిస్టమ్ నుండి మరింత పనితీరును తగ్గిస్తుంది. ఆధునిక ప్రాసెసర్‌లలో కాష్‌లను దూకుడుగా ఉపయోగించడం వల్ల పనితీరు లాభాలు వస్తాయి. రెండు డేటా కాష్‌లు ఉపయోగించబడతాయి (ప్యాకెట్‌లు “వెక్టర్స్”లో ప్రాసెస్ చేయబడతాయి, డేటా ఒకదానికొకటి దగ్గరగా ఉంటుంది) మరియు ఇన్‌స్ట్రక్షన్ కాష్‌లు: VPPలో, ప్యాకెట్ ప్రాసెసింగ్ గ్రాఫ్‌ను అనుసరిస్తుంది, వీటిలో నోడ్‌లు ఒకే పనిని చేసే ఫంక్షన్‌లను కలిగి ఉంటాయి.

ఉదాహరణకు, VPPలో IP ప్యాకెట్ల ప్రాసెసింగ్ క్రింది క్రమంలో జరుగుతుంది: ముందుగా, ప్యాకెట్ హెడర్‌లు పార్సింగ్ నోడ్‌లో అన్వయించబడతాయి, ఆపై అవి నోడ్‌కి పంపబడతాయి, ఇది రూటింగ్ పట్టికల ప్రకారం ప్యాకెట్‌లను మరింత ముందుకు పంపుతుంది.

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

n_left_from = frame->n_vectors;
while (n_left_from > 0)
{
    vlib_get_next_frame (vm, node, next_index, to_next, n_left_to_next);
    // ...
    while (n_left_from >= 4 && n_left_to_next >= 2)
    {
        // processing multiple packets at once
        u32 next0 = SAMPLE_NEXT_INTERFACE_OUTPUT;
        u32 next1 = SAMPLE_NEXT_INTERFACE_OUTPUT;
        // ...
        /* Prefetch next iteration. */
        {
            vlib_buffer_t *p2, *p3;

            p2 = vlib_get_buffer (vm, from[2]);
            p3 = vlib_get_buffer (vm, from[3]);

            vlib_prefetch_buffer_header (p2, LOAD);
            vlib_prefetch_buffer_header (p3, LOAD);

            CLIB_PREFETCH (p2->data, CLIB_CACHE_LINE_BYTES, STORE);
            CLIB_PREFETCH (p3->data, CLIB_CACHE_LINE_BYTES, STORE);
        }
        // actually process data
        /* verify speculative enqueues, maybe switch current next frame */
        vlib_validate_buffer_enqueue_x2 (vm, node, next_index,
                to_next, n_left_to_next,
                bi0, bi1, next0, next1);
    }

    while (n_left_from > 0 && n_left_to_next > 0)
    {
        // processing packets by one
    }

    // processed batch
    vlib_put_next_frame (vm, node, next_index, n_left_to_next);
}

కాబట్టి, హెల్త్‌చెక్‌లు IPv6 ద్వారా VPPకి మాట్లాడతాయి, అది వాటిని IPv4గా మారుస్తుంది. ఇది గ్రాఫ్‌లోని నోడ్ ద్వారా చేయబడుతుంది, దీనిని మేము అల్గోరిథమిక్ NAT అని పిలుస్తాము. రివర్స్ ట్రాఫిక్ (మరియు IPv6 నుండి IPv4కి మార్చడం) కోసం అదే అల్గారిథమిక్ NAT నోడ్ ఉంది.

బ్యాలెన్సర్ క్లయింట్‌ల నుండి డైరెక్ట్ ట్రాఫిక్ గ్రాఫ్ నోడ్‌ల గుండా వెళుతుంది, ఇది బ్యాలెన్సింగ్‌ను స్వయంగా నిర్వహిస్తుంది. 

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

5-టుపుల్ హాష్ తదుపరి స్థిరమైన హ్యాషింగ్ నోడ్‌లో తక్కువ గణనను నిర్వహించడానికి మాకు సహాయపడుతుంది, అలాగే బ్యాలెన్సర్ వెనుక ఉన్న వనరుల జాబితా మార్పులను మెరుగ్గా నిర్వహించడంలో సహాయపడుతుంది. సెషన్ లేని ప్యాకెట్ బ్యాలెన్సర్ వద్దకు వచ్చినప్పుడు, అది స్థిరమైన హ్యాషింగ్ నోడ్‌కు పంపబడుతుంది. ఇక్కడే బ్యాలెన్సింగ్ స్థిరమైన హ్యాషింగ్‌ని ఉపయోగించి జరుగుతుంది: అందుబాటులో ఉన్న “లైవ్” వనరుల జాబితా నుండి మేము ఒక వనరుని ఎంచుకుంటాము. తరువాత, ప్యాకెట్‌లు NAT నోడ్‌కు పంపబడతాయి, ఇది వాస్తవానికి గమ్యస్థాన చిరునామాను భర్తీ చేస్తుంది మరియు చెక్‌సమ్‌లను తిరిగి గణిస్తుంది. మీరు చూడగలిగినట్లుగా, మేము VPP యొక్క నియమాలను అనుసరిస్తాము - ఇష్టపడటం ఇష్టం, ప్రాసెసర్ కాష్‌ల సామర్థ్యాన్ని పెంచడానికి ఇలాంటి గణనలను సమూహపరచడం.

స్థిరమైన హ్యాషింగ్

మేము దానిని ఎందుకు ఎంచుకున్నాము మరియు అది కూడా ఏమిటి? మొదట, మునుపటి పనిని పరిశీలిద్దాం - జాబితా నుండి వనరును ఎంచుకోవడం. 

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

స్థిరమైన హ్యాషింగ్ వివరించిన సమస్యను పరిష్కరిస్తుంది. ఈ భావనను వివరించడానికి సులభమైన మార్గం ఇది: మీరు హాష్ ద్వారా వనరులను పంపిణీ చేసే రింగ్‌ని కలిగి ఉన్నారని ఊహించుకోండి (ఉదాహరణకు, IP:port ద్వారా). ఒక వనరును ఎంచుకోవడం అనేది ఒక కోణం ద్వారా చక్రం తిప్పడం, ఇది ప్యాకెట్ యొక్క హాష్ ద్వారా నిర్ణయించబడుతుంది.

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

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

లోడ్ బ్యాలన్సర్-నోడ్ మరియు అసెంబుల్డ్ కాంపోనెంట్స్

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

ఏ సమస్యలు నివారించబడ్డాయి?

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

సమస్యలు మరియు పరిష్కారాలు

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

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

మైక్రోసర్వీస్ ఈవెంట్ ఆర్కిటెక్చర్ ఏకశిలా కంటే చాలా క్లిష్టంగా ఉంటుంది: డజన్ల కొద్దీ వేర్వేరు యంత్రాలపై లాగ్‌లను సేకరించడం చాలా సౌకర్యవంతంగా లేదు. ముగింపు: మీరు మైక్రోసర్వీస్ చేస్తే, వెంటనే ట్రేసింగ్ గురించి ఆలోచించండి.

మా ప్రణాళికలు

మేము ఇంటర్నల్ బ్యాలెన్సర్, IPv6 బ్యాలెన్సర్‌ని ప్రారంభిస్తాము, కుబెర్నెట్స్ స్క్రిప్ట్‌లకు మద్దతును జోడిస్తాము, మా సేవలను (ప్రస్తుతం హెల్త్‌చెక్-నోడ్ మరియు హెల్త్‌చెక్-ctrl మాత్రమే షార్డ్ చేయబడ్డాయి), కొత్త హెల్త్‌చెక్‌లను జోడిస్తాము మరియు చెక్‌ల స్మార్ట్ అగ్రిగేషన్‌ను కూడా అమలు చేస్తాము. మేము మా సేవలను మరింత స్వతంత్రంగా చేసే అవకాశాన్ని పరిశీలిస్తున్నాము - తద్వారా వారు ఒకరితో ఒకరు నేరుగా కమ్యూనికేట్ చేసుకోకుండా, మెసేజ్ క్యూని ఉపయోగిస్తున్నారు. SQS-అనుకూల సేవ ఇటీవల క్లౌడ్‌లో కనిపించింది Yandex సందేశ క్యూ.

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

మూలం: www.habr.com