ఆధునిక డేటా కేంద్రాలు వివిధ రకాల పర్యవేక్షణ ద్వారా కవర్ చేయబడిన వందల కొద్దీ క్రియాశీల పరికరాలను కలిగి ఉన్నాయి. కానీ చేతిలో ఖచ్చితమైన పర్యవేక్షణ ఉన్న పరిపూర్ణ ఇంజనీర్ కూడా కొన్ని నిమిషాల్లో నెట్‌వర్క్ వైఫల్యానికి సరిగ్గా స్పందించగలరు. నెక్స్ట్ హాప్ 2020 కాన్ఫరెన్స్‌లోని ఒక నివేదికలో, నేను ఒక ప్రత్యేకమైన ఫీచర్‌ని కలిగి ఉన్న డేటా సెంటర్ నెట్‌వర్క్ డిజైన్ మెథడాలజీని అందించాను - డేటా సెంటర్ మిల్లీసెకన్లలో స్వయంగా నయం అవుతుంది. మరింత ఖచ్చితంగా, ఇంజనీర్ ప్రశాంతంగా సమస్యను పరిష్కరిస్తాడు, అయితే సేవలు దానిని గమనించవు.
చాలా మంది నెట్‌వర్క్ ఇంజనీర్‌ల కోసం, డేటా సెంటర్ నెట్‌వర్క్ ర్యాక్‌లో స్విచ్‌తో ToRతో ప్రారంభమవుతుంది. ToR సాధారణంగా రెండు రకాల లింక్‌లను కలిగి ఉంటుంది. చిన్నపిల్లలు సర్వర్‌లకు వెళతారు, ఇతరులు - వాటిలో N రెట్లు ఎక్కువ ఉన్నాయి - మొదటి స్థాయి స్పైన్‌ల వైపు, అంటే దాని అప్‌లింక్‌లకు వెళ్లండి. అప్‌లింక్‌లు సాధారణంగా సమానంగా పరిగణించబడతాయి మరియు ప్రోటో, src_ip, dst_ip, src_port, dst_port వంటి 5-టుపుల్ హాష్ ఆధారంగా అప్‌లింక్‌ల మధ్య ట్రాఫిక్ బ్యాలెన్స్ చేయబడుతుంది. ఇక్కడ ఆశ్చర్యం లేదు.
తరువాత, విమానాల నిర్మాణం ఎలా ఉంటుంది? మొదటి స్థాయి వెన్నుముకలు ఒకదానికొకటి కనెక్ట్ చేయబడవు, కానీ సూపర్‌స్పిన్‌ల ద్వారా అనుసంధానించబడి ఉంటాయి. X అక్షరం సూపర్‌స్పిన్‌లకు బాధ్యత వహిస్తుంది, ఇది దాదాపు క్రాస్-కనెక్ట్ లాగా ఉంటుంది.
మరియు మరోవైపు, టోరి మొదటి స్థాయి యొక్క అన్ని వెన్నుముకలకు అనుసంధానించబడిందని స్పష్టమవుతుంది. ఈ చిత్రంలో ముఖ్యమైనది ఏమిటి? మనకు రాక్ లోపల పరస్పర చర్య ఉంటే, అప్పుడు పరస్పర చర్య ToR ద్వారా జరుగుతుంది. పరస్పర చర్య మాడ్యూల్ లోపలికి వెళితే, పరస్పర చర్య మొదటి స్థాయి వెన్నుముకల గుండా వెళుతుంది. పరస్పర చర్య ఇంటర్‌మోడ్యులర్‌గా ఉంటే - ఇక్కడ వలె, ToR 1 మరియు ToR 2 - అప్పుడు పరస్పర చర్య మొదటి మరియు రెండవ స్థాయిల వెన్నుముకల గుండా వెళుతుంది.
సిద్ధాంతపరంగా, అటువంటి నిర్మాణం సులభంగా కొలవదగినది. మనకు పోర్ట్ కెపాసిటీ, డేటా సెంటర్‌లో స్థలం రిజర్వ్ మరియు ముందుగా అమర్చబడిన ఫైబర్ ఉంటే, అప్పుడు విమానాల సంఖ్యను ఎల్లప్పుడూ పెంచవచ్చు, తద్వారా సిస్టమ్ యొక్క మొత్తం సామర్థ్యాన్ని పెంచుతుంది. కాగితంపై, దీన్ని చేయడం చాలా సులభం. నిజ జీవితంలో కూడా అలానే ఉంటుంది. కానీ నేటి కథ దాని గురించి కాదు.
సరైన తీర్మానాలు చేయాలని నేను కోరుకుంటున్నాను. డేటా సెంటర్‌లో మాకు చాలా మార్గాలు ఉన్నాయి. వారు షరతులతో స్వతంత్రంగా ఉంటారు. డేటా సెంటర్ లోపల ఒక మార్గం ToR లోపల మాత్రమే సాధ్యమవుతుంది. మాడ్యూల్ లోపల, మనకు విమానాల సంఖ్యకు సమానమైన మార్గాలు ఉన్నాయి. మాడ్యూళ్ల మధ్య ఉన్న మార్గాల సంఖ్య విమానాల సంఖ్య మరియు ప్రతి విమానంలోని సూపర్‌స్పిన్‌ల సంఖ్య యొక్క ఉత్పత్తికి సమానం. దీన్ని స్పష్టంగా చేయడానికి, స్కేల్ అనుభూతి చెందడానికి, నేను Yandex డేటా సెంటర్‌లలో ఒకదానికి చెల్లుబాటు అయ్యే సంఖ్యలను ఇస్తాను.
ఎనిమిది విమానాలు ఉన్నాయి, ఒక్కో విమానంలో 32 సూపర్‌స్పిన్‌లు ఉంటాయి. ఫలితంగా, మాడ్యూల్ లోపల ఎనిమిది మార్గాలు ఉన్నాయని మరియు ఇంటర్-మాడ్యూల్ ఇంటరాక్షన్‌తో వాటిలో ఇప్పటికే 256 ఉన్నాయి.
అంటే, మేము కుక్‌బుక్‌ను అభివృద్ధి చేస్తుంటే, తమను తాము నయం చేసుకునే తప్పులను తట్టుకునే డేటా సెంటర్‌లను ఎలా నిర్మించాలో తెలుసుకోవడానికి ప్రయత్నిస్తుంటే, ప్లానర్ ఆర్కిటెక్చర్ సరైన ఎంపిక. ఇది స్కేలింగ్ సమస్యను పరిష్కరించడానికి మిమ్మల్ని అనుమతిస్తుంది మరియు సిద్ధాంతపరంగా ఇది సులభం. అనేక స్వతంత్ర మార్గాలు ఉన్నాయి. ప్రశ్న మిగిలి ఉంది: అటువంటి నిర్మాణం వైఫల్యాలను ఎలా తట్టుకుంటుంది? వివిధ క్రాష్‌లు ఉన్నాయి. మరియు మేము ఇప్పుడు దీనిని చర్చిస్తాము.
మన సూపర్‌స్పిన్‌లలో ఒకరికి జబ్బు పడనివ్వండి. ఇక్కడ నేను రెండు విమానాల నిర్మాణానికి తిరిగి వచ్చాను. మేము వాటిని ఒక ఉదాహరణగా చూపుతాము ఎందుకంటే తక్కువ కదిలే భాగాలతో ఇక్కడ ఏమి జరుగుతుందో చూడటం సులభం అవుతుంది. X11 జబ్బు పడనివ్వండి. డేటా సెంటర్‌లలో ఉండే సేవలపై ఇది ఎలా ప్రభావం చూపుతుంది? వైఫల్యం వాస్తవానికి ఎలా కనిపిస్తుందనే దానిపై చాలా ఆధారపడి ఉంటుంది.
వైఫల్యం మంచిదైతే, అదే BFD యొక్క ఆటోమేషన్ స్థాయిలో అది క్యాచ్ చేయబడుతుంది, ఆటోమేషన్ సంతోషంగా సమస్య కీళ్లను ఉంచుతుంది మరియు సమస్యను వేరు చేస్తుంది, అప్పుడు ప్రతిదీ బాగానే ఉంటుంది. మాకు చాలా మార్గాలు ఉన్నాయి, ట్రాఫిక్ తక్షణమే ప్రత్యామ్నాయ మార్గాలకు మళ్లించబడుతుంది మరియు సేవలు దేనినీ గమనించవు. ఇదొక మంచి దృశ్యం.
మనకు నిరంతరం నష్టాలు ఉంటే, మరియు ఆటోమేషన్ సమస్యను గమనించకపోతే ఒక చెడ్డ దృశ్యం. ఇది అప్లికేషన్‌ను ఎలా ప్రభావితం చేస్తుందో అర్థం చేసుకోవడానికి, TCP ప్రోటోకాల్ ఎలా పనిచేస్తుందో చర్చించడానికి మేము కొంత సమయం గడపవలసి ఉంటుంది.
ఈ సమాచారంతో నేను ఎవరికీ షాక్ ఇవ్వనని ఆశిస్తున్నాను: TCP అనేది హ్యాండ్‌షేక్ ప్రోటోకాల్. అంటే, సరళమైన సందర్భంలో, పంపినవారు రెండు ప్యాకెట్లను పంపుతారు మరియు వాటిపై సంచిత యాక్ను అందుకుంటారు: "నేను రెండు ప్యాకెట్లను అందుకున్నాను."
ఆ తరువాత, అతను మరో రెండు ప్యాకెట్లను పంపుతాడు మరియు పరిస్థితి పునరావృతమవుతుంది. కొంత సరళీకరణ కోసం నేను ముందుగానే క్షమాపణలు కోరుతున్నాను. విండో (విమానంలో ప్యాకెట్ల సంఖ్య) రెండు ఉంటే ఈ దృశ్యం సరైనది. వాస్తవానికి, ఇది సాధారణంగా అవసరం లేదు. కానీ విండో పరిమాణం ద్వారా ప్యాకెట్ ఫార్వార్డింగ్ సందర్భం ప్రభావితం కాదు.
మనం ప్యాకేజీ 3ని కోల్పోతే ఏమి జరుగుతుంది? ఈ సందర్భంలో, గ్రహీత 1, 2 మరియు 4 ప్యాకెట్లను అందుకుంటారు. మరియు అతను SACK ఎంపికను ఉపయోగించి పంపినవారికి స్పష్టంగా తెలియజేస్తాడు: "మీకు తెలుసా, ముగ్గురు వచ్చారు, కానీ మధ్యలో పోయింది." అతను "Ack 2, SACK 4" అని చెప్పాడు.
ఈ సమయంలో పంపినవారు ఎలాంటి సమస్యలు లేకుండా పోగొట్టుకున్న ప్యాకెట్‌ను సరిగ్గా పునరావృతం చేస్తారు.
కానీ విండోలోని చివరి ప్యాకెట్ పోయినట్లయితే, పరిస్థితి చాలా భిన్నంగా కనిపిస్తుంది.
గ్రహీత మొదటి మూడు ప్యాకెట్లను అందుకుంటారు మరియు ముందుగా వేచి ఉండటం ప్రారంభిస్తారు. Linux కెర్నల్ యొక్క TCP స్టాక్‌లోని కొన్ని ఆప్టిమైజేషన్‌లకు ధన్యవాదాలు, ఇది చివరి ప్యాకెట్ లేదా అలాంటిదే అని ఫ్లాగ్‌లలో స్పష్టమైన సూచన లేనట్లయితే, ఇది జత చేసిన ప్యాకెట్ కోసం వేచి ఉంటుంది. ఇది ఆలస్యమైన ACK గడువు ముగిసే వరకు వేచి ఉండి, ఆపై మొదటి మూడు ప్యాకెట్‌లకు రసీదుని పంపుతుంది. కానీ ఇప్పుడు పంపిన వ్యక్తి వేచి ఉంటాడు. నాలుగో ప్యాకేజీ పోయిందో, రాబోతోందో అతనికి తెలియదు. మరియు నెట్‌వర్క్‌ను ఓవర్‌లోడ్ చేయకుండా ఉండటానికి, ప్యాకెట్ పోయిందని లేదా RTO గడువు ముగిసిందని స్పష్టమైన సూచన కోసం వేచి ఉండటానికి ప్రయత్నిస్తుంది.
RTO గడువు ఏమిటి? ఇది TCP స్టాక్ మరియు కొంత స్థిరంగా లెక్కించిన RTT నుండి గరిష్టం. ఈ స్థిరత్వం ఏమిటి, మనం ఇప్పుడు చర్చిస్తాము.
కానీ మనం మళ్లీ దురదృష్టవంతులైతే మరియు నాల్గవ ప్యాకెట్ మళ్లీ పోయినట్లయితే, RTO రెట్టింపు అవుతుంది. అంటే, ప్రతి విఫల ప్రయత్నం సమయం ముగిసే సమయానికి రెట్టింపు అవుతుంది.
ఈ బేస్ దేనికి సమానమో ఇప్పుడు చూద్దాం. డిఫాల్ట్‌గా, కనీస RTO 200 ms. డేటా ప్యాకేజీలకు ఇది కనీస RTO. SYN ప్యాకెట్ల కోసం ఇది భిన్నంగా ఉంటుంది, 1 సెకను. మీరు చూడగలిగినట్లుగా, ప్యాకెట్లను మళ్లీ పంపడానికి మొదటి ప్రయత్నం కూడా డేటా సెంటర్‌లోని RTT కంటే 100 రెట్లు ఎక్కువ సమయం పడుతుంది.
ఇప్పుడు మన దృష్టాంతానికి తిరిగి వెళ్ళు. సేవలో ఏమి జరుగుతోంది? సేవ ప్యాకెట్లను కోల్పోవడం ప్రారంభిస్తుంది. సేవ మొదట్లో అదృష్టవంతంగా ఉండనివ్వండి మరియు విండో మధ్యలో ఏదైనా కోల్పోతుంది, తర్వాత అది ఒక SACKని అందుకుంటుంది, కోల్పోయిన ప్యాకెట్లను మళ్లీ పంపుతుంది.
కానీ దురదృష్టం పునరావృతమైతే, మాకు RTO ఉంది. ఇక్కడ ముఖ్యమైనది ఏమిటి? అవును, మాకు నెట్‌వర్క్‌లో చాలా మార్గాలు ఉన్నాయి. కానీ ఒక నిర్దిష్ట TCP కనెక్షన్ యొక్క TCP ట్రాఫిక్ అదే విరిగిన స్టాక్ ద్వారా కొనసాగుతుంది. ప్యాకెట్ నష్టం, మా మ్యాజిక్ X11 దానంతట అదే బయటకు వెళ్లదు, సమస్యాత్మకం కాని ప్రాంతాలకు ట్రాఫిక్ ప్రవహించదు. మేము అదే విరిగిన స్టాక్ ద్వారా ప్యాకెట్‌ను డెలివరీ చేయడానికి ప్రయత్నిస్తున్నాము. ఇది క్యాస్కేడింగ్ వైఫల్యానికి దారి తీస్తుంది: డేటా సెంటర్ అనేది ఇంటరాక్టింగ్ అప్లికేషన్‌ల సమితి, మరియు ఈ అన్ని అప్లికేషన్‌ల యొక్క కొన్ని TCP కనెక్షన్‌లు క్షీణించడం ప్రారంభిస్తాయి - ఎందుకంటే సూపర్‌స్పిన్ DC లోపల ఉన్న అన్ని అప్లికేషన్‌లను ప్రభావితం చేస్తుంది. సామెత వలె: మీరు గుర్రానికి షూ చేయకపోతే, గుర్రం కుంటుపడుతుంది; గుర్రం కుంటుపడింది - నివేదిక అందించబడలేదు; సందేశం అందించబడలేదు - వారు యుద్ధంలో ఓడిపోయారు. సమస్య సంభవించిన క్షణం నుండి సేవలు అనుభూతి చెందడం ప్రారంభించే క్షీణత దశకు మాత్రమే ఇక్కడ గణన సెకన్లపాటు వెళుతుంది. దీని అర్థం వినియోగదారులు ఎక్కడా ఏదో స్వీకరించకపోవచ్చు.
ఒకదానికొకటి పూర్తి చేసే రెండు క్లాసిక్ పరిష్కారాలు ఉన్నాయి. మొదటిది స్ట్రాలు వేయడానికి మరియు సమస్యను పరిష్కరించడానికి ప్రయత్నిస్తున్న సేవలు: “TCP స్టాక్‌లో ఏదైనా సర్దుబాటు చేద్దాం. మరియు అంతర్గత ఆరోగ్య తనిఖీలతో అప్లికేషన్-స్థాయి గడువు ముగింపులు లేదా దీర్ఘకాల TCP సెషన్‌లను చేద్దాం. సమస్య ఏమిటంటే అటువంటి పరిష్కారాలు: a) అస్సలు స్కేల్ చేయవు; బి) చాలా పేలవంగా పరీక్షించబడింది. అంటే, సేవ అనుకోకుండా TCP స్టాక్‌ను కాన్ఫిగర్ చేసినప్పటికీ, అది మెరుగ్గా మారుతుంది, మొదట, ఇది అన్ని అప్లికేషన్‌లు మరియు అన్ని డేటా సెంటర్‌లకు వర్తించే అవకాశం లేదు మరియు రెండవది, చాలా మటుకు, సరిగ్గా ఏమి జరిగిందో మరియు ఏమి జరిగిందో అర్థం చేసుకోదు. కాదు. అంటే, ఇది పనిచేస్తుంది, కానీ ఇది పేలవంగా పనిచేస్తుంది మరియు స్కేల్ చేయదు. మరి నెట్‌వర్క్ సమస్య వస్తే ఎవరిని తప్పు పట్టాలి? వాస్తవానికి NOC. NOC ఏమి చేస్తుంది?
అనేక సేవలు NOCలో, పని ఇలా జరుగుతుందని నమ్ముతారు. కానీ నిజాయితీగా ఉండటానికి, మాత్రమే కాదు.
క్లాసికల్ పథకంలో NOC అనేక పర్యవేక్షణ అభివృద్ధిలో నిమగ్నమై ఉంది. ఇవి బ్లాక్ బాక్స్ మానిటరింగ్ మరియు వైట్ బాక్స్ మానిటరింగ్ రెండూ. స్పైన్‌ల బ్లాక్ బాక్స్-పర్యవేక్షణ ఉదాహరణ గురించి గత నెక్స్ట్ హాప్‌లో అలెగ్జాండర్ క్లిమెంకో. మార్గం ద్వారా, ఈ పర్యవేక్షణ పనిచేస్తుంది. కానీ ఖచ్చితమైన పర్యవేక్షణకు కూడా సమయం లాగ్ ఉంటుంది. సాధారణంగా ఇది చాలా నిమిషాలు. ఇది పనిచేసిన తర్వాత, డ్యూటీలో ఉన్న ఇంజనీర్‌లకు దాని ఆపరేషన్‌ను రెండుసార్లు తనిఖీ చేయడానికి, సమస్యను స్థానికీకరించడానికి మరియు సమస్య ఉన్న ప్రాంతాన్ని చల్లార్చడానికి సమయం కావాలి. అంటే, ఉత్తమ సందర్భంలో, సమస్య యొక్క చికిత్స 5 నిమిషాలు పడుతుంది, చెత్తగా 20 నిమిషాలు, నష్టాలు ఎక్కడ సంభవిస్తాయో వెంటనే స్పష్టంగా తెలియకపోతే. ఈ సమయంలో - 5 లేదా 20 నిమిషాలు - మా సేవలు దెబ్బతింటాయని స్పష్టంగా తెలుస్తుంది, ఇది బహుశా మంచిది కాదు.
మీరు ఏమి స్వీకరించాలనుకుంటున్నారు? మనకు చాలా దారులు ఉన్నాయి. మరియు దురదృష్టకర TCP ప్రవాహాలు అదే మార్గాన్ని ఉపయోగించడం కొనసాగించడం వలన సమస్యలు తలెత్తుతాయి. ఒకే TCP కనెక్షన్‌లో బహుళ మార్గాలను ఉపయోగించడానికి మమ్మల్ని అనుమతించేవి మాకు అవసరం. మన దగ్గర పరిష్కారం ఉన్నట్లు అనిపిస్తుంది. TCP ఉంది, దీనిని మల్టీపాత్ TCP అని పిలుస్తారు, అంటే అనేక మార్గాలకు TCP. నిజమే, ఇది పూర్తిగా భిన్నమైన పని కోసం అభివృద్ధి చేయబడింది - అనేక నెట్‌వర్క్ పరికరాలను కలిగి ఉన్న స్మార్ట్‌ఫోన్‌ల కోసం. బదిలీని పెంచడానికి లేదా ప్రాథమిక / బ్యాకప్ మోడ్‌ను చేయడానికి, అప్లికేషన్ కోసం అనేక థ్రెడ్‌లను (సెషన్‌లు) పారదర్శకంగా సృష్టించే ఒక మెకానిజం అభివృద్ధి చేయబడింది మరియు విఫలమైతే వాటి మధ్య మారడానికి మిమ్మల్ని అనుమతిస్తుంది. లేదా, నేను చెప్పినట్లుగా, బ్యాండ్‌విడ్త్‌ను పెంచండి.
కానీ ఇక్కడ ఒక స్వల్పభేదం ఉంది. అది ఏమిటో అర్థం చేసుకోవడానికి, మేము స్ట్రీమ్‌లను ఎలా సెటప్ చేయాలో చూడాలి.
థ్రెడ్‌లు వరుసగా సెట్ చేయబడ్డాయి. మొదటి స్ట్రీమ్ మొదట ఇన్‌స్టాల్ చేయబడింది. ఆ థ్రెడ్‌లో ఇప్పటికే అంగీకరించిన కుక్కీని ఉపయోగించి తదుపరి ప్రవాహాలు సెట్ చేయబడతాయి. మరియు ఇక్కడ సమస్య ఉంది.
సమస్య ఏమిటంటే, మొదటి థ్రెడ్ ఇన్‌స్టాల్ చేయకపోతే, రెండవ మరియు మూడవ థ్రెడ్‌లు ఎప్పటికీ రావు. అంటే, మల్టీపాత్ TCP మొదటి స్ట్రీమ్‌లో SYN ప్యాకెట్ నష్టాన్ని పరిష్కరించదు. మరియు SYN పోయినట్లయితే, మల్టీపాత్ TCP సాధారణ TCP అవుతుంది. కాబట్టి, డేటా సెంటర్ వాతావరణంలో, ఫ్యాక్టరీలో నష్టాల సమస్యను పరిష్కరించడంలో మరియు వైఫల్యం విషయంలో బహుళ మార్గాలను ఎలా ఉపయోగించాలో తెలుసుకోవడానికి ఇది మాకు సహాయం చేయదు.
మనకు ఏది సహాయం చేయగలదు? IPv6 ఫ్లో లేబుల్ హెడర్ ఫీల్డ్ మా తదుపరి కథనంలో ముఖ్యమైన ఫీల్డ్ అని మీలో కొందరు ఇప్పటికే పేరు నుండి ఊహించారు. నిజానికి, ఇది v6లో కనిపించే ఫీల్డ్, ఇది v4లో లేదు, దీనికి 20 బిట్‌లు పడుతుంది మరియు దీని వినియోగం గురించి చాలా కాలంగా వివాదం ఉంది. ఇది చాలా ఆసక్తికరంగా ఉంది - వివాదాలు ఉన్నాయి, RFC ఫ్రేమ్‌వర్క్‌లో ఏదో పరిష్కరించబడింది మరియు అదే సమయంలో, Linux కెర్నల్‌లో అమలు కనిపించింది, అది ఎక్కడా నమోదు చేయబడలేదు.
ఒక చిన్న విచారణలో మీరు నాతో చేరాలని నేను సూచిస్తున్నాను. గత కొన్ని సంవత్సరాలుగా Linux కెర్నల్‌లో ఏమి జరుగుతుందో చూద్దాం.
సంవత్సరం 2014. ఒక పెద్ద మరియు ప్రసిద్ధ కంపెనీకి చెందిన ఇంజనీర్ లైనక్స్ కెర్నల్ యొక్క కార్యాచరణకు సాకెట్ యొక్క హాష్‌పై ఫ్లో లేబుల్ విలువపై ఆధారపడటాన్ని జోడిస్తుంది. వారు ఇక్కడ ఏమి పరిష్కరించడానికి ప్రయత్నిస్తున్నారు? ఇది క్రింది సమస్యను చర్చించిన RFC 6438కి సంబంధించినది. డేటా సెంటర్ లోపల, IPv4 తరచుగా IPv6 ప్యాకెట్లలో నిక్షిప్తం చేయబడుతుంది, ఎందుకంటే కర్మాగారమే IPv6, కానీ IPv4 ఏదో ఒకవిధంగా ఇవ్వబడాలి. TCP లేదా UDPని పొందడానికి మరియు అక్కడ src_ports, dst_portsని కనుగొనడానికి రెండు IP హెడర్‌ల క్రింద చూడలేని స్విచ్‌లతో చాలా కాలంగా సమస్యలు ఉన్నాయి. మీరు మొదటి రెండు IP హెడర్‌లను పరిశీలిస్తే, హాష్ దాదాపుగా పరిష్కరించబడినట్లు తేలింది. దీన్ని నివారించడానికి, ఈ ఎన్‌క్యాప్సులేటెడ్ ట్రాఫిక్ యొక్క బ్యాలెన్సింగ్ సరిగ్గా పని చేసేలా, ఫ్లో లేబుల్ ఫీల్డ్ విలువకు 5-టుపుల్ ఎన్‌క్యాప్సులేటెడ్ ప్యాకెట్ నుండి హాష్‌ను జోడించాలని ప్రతిపాదించబడింది. ఇతర ఎన్‌క్యాప్సులేషన్ స్కీమ్‌ల కోసం, UDP కోసం, GRE కోసం ఇంచుమించు అదే జరిగింది, తరువాతి కాలంలో GRE కీ ఫీల్డ్ ఉపయోగించబడింది. ఒక మార్గం లేదా మరొకటి, ఇక్కడ లక్ష్యాలు స్పష్టంగా ఉన్నాయి. మరియు కనీసం ఆ సమయంలో వారు ఉపయోగకరంగా ఉన్నారు.
2015లో, అదే గౌరవనీయమైన ఇంజనీర్ నుండి కొత్త ప్యాచ్ వచ్చింది. అతను చాలా ఆసక్తికరమైనవాడు. ఇది క్రింది వాటిని చెబుతుంది - ప్రతికూల రూటింగ్ ఈవెంట్ విషయంలో మేము హాష్‌ను యాదృచ్ఛికంగా మారుస్తాము. ప్రతికూల రూటింగ్ ఈవెంట్ అంటే ఏమిటి? ఇది మేము ఇంతకుముందు చర్చించుకున్న RTO, అంటే విండో టెయిల్ కోల్పోవడం నిజంగా ప్రతికూలమైన సంఘటన. నిజమే, అది ఏమిటో ఊహించడం చాలా కష్టం.
2016, మరొక గౌరవనీయమైన సంస్థ, కూడా పెద్దది. ఇది చివరి క్రచ్‌లను అన్వయించి, మేము ఇంతకుముందు యాదృచ్ఛికంగా చేసిన హాష్ ఇప్పుడు ప్రతి SYN రీట్రాన్స్‌మిట్‌లో మరియు ప్రతి RTO సమయం ముగిసిన తర్వాత మార్చబడేలా చేస్తుంది. మరియు ఈ లేఖలో, మొదటి మరియు చివరిసారిగా, అంతిమ లక్ష్యం ధ్వనిస్తుంది - ఛానెల్‌ల నష్టం లేదా ఓవర్‌లోడ్ సందర్భంలో ట్రాఫిక్‌కు బహుళ మార్గాలను ఉపయోగించి సాఫ్ట్ రీరూటింగ్ అవకాశం ఉందని నిర్ధారించుకోవడం. వాస్తవానికి, ఆ తర్వాత చాలా ప్రచురణలు ఉన్నాయి, మీరు వాటిని సులభంగా కనుగొనవచ్చు.
కానప్పటికీ, మీరు చేయలేరు, ఎందుకంటే ఈ అంశంపై ఒక్క ప్రచురణ కూడా లేదు. కానీ మనకు తెలుసు!
మరియు ఏమి జరిగిందో మీకు పూర్తిగా అర్థం కాకపోతే, నేను ఇప్పుడు మీకు చెప్తాను.
ఏమి జరిగింది, Linux కెర్నల్‌కు ఏ కార్యాచరణ జోడించబడింది? ప్రతి RTO ఈవెంట్ తర్వాత txhash యాదృచ్ఛిక విలువకు మారుతుంది. ఇది రూటింగ్ యొక్క చాలా ప్రతికూల ఫలితం. హాష్ ఈ txhashపై ఆధారపడి ఉంటుంది మరియు ఫ్లో లేబుల్ skb హాష్‌పై ఆధారపడి ఉంటుంది. ఇక్కడ ఫంక్షన్‌లపై కొన్ని లెక్కలు ఉన్నాయి; అన్ని వివరాలను ఒకే స్లయిడ్‌లో ఉంచడం సాధ్యం కాదు. ఎవరైనా ఆసక్తిగా ఉంటే, మీరు కెర్నల్ కోడ్ ద్వారా వెళ్లి తనిఖీ చేయవచ్చు.
ఇక్కడ ముఖ్యమైనది ఏమిటి? ఫ్లో లేబుల్ ఫీల్డ్ విలువ ప్రతి RTO తర్వాత యాదృచ్ఛిక సంఖ్యకు మారుతుంది. ఇది మా దురదృష్టకర TCP స్ట్రీమ్‌ని ఎలా ప్రభావితం చేస్తుంది?
SACK విషయంలో, మేము తెలిసిన పోగొట్టుకున్న ప్యాకెట్‌ని మళ్లీ పంపడానికి ప్రయత్నిస్తున్నందున ఏమీ మారలేదు. ఇంతవరకు అంతా బాగనే ఉంది.
కానీ RTO విషయంలో, మేము ToRలో హాష్ ఫంక్షన్‌కు ఫ్లో లేబుల్‌ని జోడించినట్లయితే, ట్రాఫిక్ వేరే మార్గంలో పడుతుంది. మరియు ఎక్కువ విమానాలు, నిర్దిష్ట పరికరంలో క్రాష్ ద్వారా ప్రభావితం కాని మార్గాన్ని కనుగొనే అవకాశం ఉంది.
ఒక సమస్య మిగిలి ఉంది - RTO. మరొక మార్గం, వాస్తవానికి, కనుగొనబడింది, కానీ దానిపై చాలా సమయం గడుపుతారు. 200ms చాలా ఎక్కువ. రెండవది సాధారణంగా అడవి. ఇంతకు ముందు, నేను సేవలను కాన్ఫిగర్ చేసే గడువు ముగియడం గురించి మాట్లాడాను. కాబట్టి, సెకను అనేది సాధారణంగా అప్లికేషన్ స్థాయిలో సేవను సెటప్ చేసే సమయం ముగిసింది మరియు దీనిలో సేవ సాపేక్షంగా సరైనది. అంతేకాకుండా, నేను పునరావృతం చేస్తున్నాను, ఆధునిక డేటా సెంటర్‌లోని నిజమైన RTT దాదాపు 1 మిల్లీసెకన్లు.
RTO కాలవ్యవధి గురించి ఏమి చేయవచ్చు? డేటా ప్యాకెట్లు కోల్పోయినట్లయితే RTOకి బాధ్యత వహించే సమయం ముగియడం వినియోగదారు స్థలం నుండి సాపేక్షంగా సులభంగా కాన్ఫిగర్ చేయబడుతుంది: IP యుటిలిటీ ఉంది మరియు దాని పారామితులలో ఒకదానిలో అదే rto_min ఉంటుంది. వాస్తవానికి, మీరు RTOని ప్రపంచవ్యాప్తంగా మార్చాల్సిన అవసరం లేదు, కానీ ఇచ్చిన ప్రిఫిక్స్‌ల కోసం, అటువంటి మెకానిజం చాలా పని చేస్తుంది.
నిజమే, SYN_RTOతో ప్రతిదీ కొంత అధ్వాన్నంగా ఉంది. ఇది సహజంగా వ్రేలాడదీయబడింది. విలువ కోర్లో స్థిరంగా ఉంటుంది - 1 సెకను, మరియు అంతే. మీరు యూజర్ స్పేస్ నుండి దాన్ని చేరుకోలేరు. ఒకే ఒక మార్గం ఉంది.
eBPF సహాయం చేస్తుంది. సరళంగా చెప్పాలంటే, ఇవి చిన్న సి ప్రోగ్రామ్‌లు. వీటిని కెర్నల్ స్టాక్ మరియు TCP స్టాక్ అమలులో వేర్వేరు ప్రదేశాలలో హుక్స్‌లోకి చొప్పించవచ్చు, దానితో మీరు చాలా పెద్ద సంఖ్యలో సెట్టింగ్‌లను మార్చవచ్చు. సాధారణంగా, eBPF అనేది దీర్ఘకాలిక ధోరణి. డజన్ల కొద్దీ కొత్త sysctl పారామితులను కత్తిరించి, IP యుటిలిటీని విస్తరించడానికి బదులుగా, కదలిక eBPF దిశలో మరియు దాని కార్యాచరణను విస్తరిస్తుంది. eBPFతో, మీరు రద్దీ నియంత్రణలు మరియు అనేక ఇతర TCP సెట్టింగ్‌లను డైనమిక్‌గా మార్చవచ్చు.
కానీ దాని సహాయంతో మీరు SYN_RTO విలువలను ట్విస్ట్ చేయడం మాకు ముఖ్యం. మరియు బహిరంగంగా పోస్ట్ చేయబడిన ఉదాహరణ ఉంది: . ఇక్కడ ఏమి చేస్తారు? ఉదాహరణ పని చేస్తోంది, కానీ దానికదే చాలా కఠినమైనది. డేటా సెంటర్ లోపల మేము మొదటి 44 బిట్‌లను సరిపోల్చినట్లు ఇక్కడ భావించబడుతుంది, అవి సరిపోలితే, DC లోపల మనల్ని మనం కనుగొంటాము. మరియు ఈ సందర్భంలో, మేము SYN_RTO గడువు ముగింపు విలువను 4msకి మారుస్తాము. అదే పనిని మరింత సునాయాసంగా చేయవచ్చు. కానీ ఈ సాధారణ ఉదాహరణ చూపిస్తుంది a) సాధ్యం; బి) సాపేక్షంగా సులభం.
మనకు ఇప్పటికే ఏమి తెలుసు? ప్లానార్ ఆర్కిటెక్చర్ స్కేలింగ్‌ను అనుమతిస్తుంది, మేము ToRలో ఫ్లో లేబుల్‌ని ఆన్ చేసినప్పుడు మరియు సమస్యాత్మక ప్రాంతాల చుట్టూ ప్రవహించే అవకాశాన్ని పొందినప్పుడు అది మనకు చాలా ఉపయోగకరంగా ఉంటుంది. RTO మరియు SYN-RTO విలువలను తగ్గించడానికి ఉత్తమ మార్గం eBPF ప్రోగ్రామ్‌లను ఉపయోగించడం. ప్రశ్న మిగిలి ఉంది: బ్యాలెన్సింగ్ కోసం ఫ్లో లేబుల్‌ను ఉపయోగించడం సురక్షితమేనా? మరియు ఇక్కడ ఒక స్వల్పభేదాన్ని ఉంది.
మీకు నెట్‌వర్క్‌లో ఏదైనా కాస్ట్‌లో ఉండే సేవ ఉందని అనుకుందాం. దురదృష్టవశాత్తూ, ఏదైనా కాస్ట్ గురించి వివరంగా చెప్పడానికి నాకు సమయం లేదు, కానీ ఇది ఒకే IP చిరునామాలో విభిన్న భౌతిక సర్వర్లు అందుబాటులో ఉన్న పంపిణీ సేవ. మరియు ఇక్కడ సాధ్యమయ్యే సమస్య ఉంది: ఫ్యాక్టరీ గుండా ట్రాఫిక్ వెళ్లినప్పుడు మాత్రమే RTO ఈవెంట్ జరుగుతుంది. ఇది ToR బఫర్ స్థాయిలో కూడా సంభవించవచ్చు: ఒక ఇన్‌కాస్ట్ ఈవెంట్ సంభవించినప్పుడు, హోస్ట్ ఏదైనా చిందించినప్పుడు అది హోస్ట్‌లో కూడా సంభవించవచ్చు. ఒక RTO ఈవెంట్ సంభవించినప్పుడు మరియు అది ఫ్లో లేబుల్‌ను మార్చినప్పుడు. ఈ సందర్భంలో, ట్రాఫిక్ మరొక ఏకాస్ట్ ఉదాహరణకి వెళ్లవచ్చు. ఇది స్టేట్‌ఫుల్ ఏదైనా కాస్ట్ అని అనుకుందాం, ఇది కనెక్షన్ స్థితిని కలిగి ఉంది - ఇది L3 బ్యాలెన్సర్ లేదా మరేదైనా సేవ కావచ్చు. అప్పుడు సమస్య తలెత్తుతుంది, ఎందుకంటే RTO తర్వాత, TCP కనెక్షన్ సర్వర్‌కు వస్తుంది, దీనికి ఈ TCP కనెక్షన్ గురించి ఏమీ తెలియదు. మరియు మనకు ఏదైనా కాస్ట్ సర్వర్‌ల మధ్య స్టేట్ షేరింగ్ లేకపోతే, అటువంటి ట్రాఫిక్ తొలగించబడుతుంది మరియు TCP కనెక్షన్ విచ్ఛిన్నమవుతుంది.
ఇక్కడ ఏమి చేయవచ్చు? మీ నియంత్రిత వాతావరణంలో, మీరు ఫ్లో లేబుల్ బ్యాలెన్సింగ్‌ను ఎనేబుల్ చేసే చోట, ఏదైనా కాస్ట్ సర్వర్‌లను యాక్సెస్ చేస్తున్నప్పుడు మీరు ఫ్లో లేబుల్ విలువను పరిష్కరించాలి. అదే eBPF ప్రోగ్రామ్ ద్వారా దీన్ని చేయడం సులభమయిన మార్గం. కానీ ఇక్కడ చాలా ముఖ్యమైన విషయం ఉంది - మీరు డేటా సెంటర్ నెట్‌వర్క్‌ను ఆపరేట్ చేయకపోతే, టెలికాం ఆపరేటర్ అయితే ఏమి చేయాలి? ఇది మీ సమస్య కూడా: జునిపెర్ మరియు అరిస్టా యొక్క నిర్దిష్ట వెర్షన్‌లతో ప్రారంభించి, అవి డిఫాల్ట్‌గా హాష్ ఫంక్షన్‌లో ఫ్లో లేబుల్‌ని కలిగి ఉంటాయి - నిజం చెప్పాలంటే, ఎటువంటి కారణం లేకుండా నేను అర్థం చేసుకున్నాను. దీని వలన మీరు మీ నెట్‌వర్క్ ద్వారా వెళ్లే వినియోగదారుల నుండి TCP కనెక్షన్‌లను వదులుకోవచ్చు. అందువల్ల, ఈ ప్రదేశంలో మీ రూటర్ సెట్టింగ్‌లను తనిఖీ చేయాలని నేను బాగా సిఫార్సు చేస్తున్నాను.
ఒక మార్గం లేదా మరొకటి, మేము ప్రయోగాలకు వెళ్లడానికి సిద్ధంగా ఉన్నామని నాకు అనిపిస్తోంది.
మేము ToRలో ఫ్లో లేబుల్‌ని ఆన్ చేసినప్పుడు, ఏజెంట్ యొక్క eBPFని సిద్ధం చేసాము, ఇది ఇప్పుడు హోస్ట్‌లలో నివసిస్తుంది, మేము తదుపరి పెద్ద వైఫల్యం కోసం వేచి ఉండకూడదని, కానీ నియంత్రిత పేలుళ్లను నిర్వహించాలని నిర్ణయించుకున్నాము. మేము నాలుగు అప్‌లింక్‌లను కలిగి ఉన్న ToRని తీసుకున్నాము మరియు వాటిలో ఒకదానిపై డ్రాప్స్ చేసాము. వారు ఒక నియమాన్ని గీశారు, వారు చెప్పారు - ఇప్పుడు మీరు అన్ని ప్యాకెట్లను కోల్పోతున్నారు. మీరు ఎడమవైపు చూడగలిగినట్లుగా, మాకు ఒక్కో ప్యాకెట్ పర్యవేక్షణ ఉంది, ఇది 75%కి పడిపోయింది, అంటే 25% ప్యాకెట్లు పోతాయి. కుడివైపున ఈ ToR వెనుక ఉన్న సేవల గ్రాఫ్‌లు ఉన్నాయి. వాస్తవానికి, ఇవి రాక్ లోపల సర్వర్‌లతో కీళ్ల ట్రాఫిక్ గ్రాఫ్‌లు. మీరు గమనిస్తే, వారు మరింత దిగువకు మునిగిపోయారు. అవి ఎందుకు తక్కువగా మునిగిపోయాయి - 25% కాదు, కొన్ని సందర్భాల్లో 3-4 రెట్లు? TCP కనెక్షన్ దురదృష్టకరమైతే, అది విచ్ఛిన్నమైన ఇంటర్‌ఫేస్ ద్వారా చేరుకోవడానికి ప్రయత్నిస్తూనే ఉంటుంది. DC లోపల సేవ యొక్క సాధారణ ప్రవర్తన ద్వారా ఇది తీవ్రమవుతుంది - ఒక వినియోగదారు అభ్యర్థన కోసం, అంతర్గత సేవలకు N అభ్యర్థనలు రూపొందించబడతాయి మరియు ప్రతిస్పందన వినియోగదారుకు వెళ్తుంది, అన్ని డేటా మూలాధారాలు ప్రతిస్పందించినప్పుడు లేదా సమయం ముగిసినప్పుడు అప్లికేషన్ స్థాయి, ఇది ఇంకా కాన్ఫిగర్ చేయబడాలి. అంటే, ప్రతిదీ చాలా చాలా చెడ్డది.
ఇప్పుడు అదే ప్రయోగం, కానీ ఫ్లో లేబుల్ ప్రారంభించబడింది. మీరు చూడగలిగినట్లుగా, ఎడమ వైపున, మా బ్యాచ్ పర్యవేక్షణ అదే 25% తగ్గిపోయింది. ఇది ఖచ్చితంగా సరైనది, ఎందుకంటే దీనికి రీట్రాన్స్మిట్‌ల గురించి ఏమీ తెలియదు, ఇది ప్యాకెట్లను పంపుతుంది మరియు డెలివరీ చేయబడిన మరియు పోగొట్టుకున్న ప్యాకెట్ల సంఖ్య యొక్క నిష్పత్తిని గణిస్తుంది.
మరియు కుడి వైపున సేవల షెడ్యూల్ ఉంది. మీరు ఇక్కడ సమస్య ఉమ్మడి ప్రభావాన్ని కనుగొనలేరు. అదే మిల్లీసెకన్లలో ట్రాఫిక్ సమస్య ఉన్న ప్రాంతం నుండి సమస్యతో ప్రభావితం కాని మిగిలిన మూడు అప్‌లింక్‌లకు వెళ్లింది. మేము స్వయంగా నయం చేసే నెట్‌వర్క్‌ని పొందాము.
ఇది నా చివరి స్లయిడ్, స్టాక్ తీసుకోవాల్సిన సమయం. ఇప్పుడు, స్వీయ-స్వస్థత డేటా సెంటర్ నెట్‌వర్క్‌ను ఎలా నిర్మించాలో మీకు తెలుసని నేను ఆశిస్తున్నాను. మీరు Linux కెర్నల్ ఆర్కైవ్ ద్వారా వెళ్లి అక్కడ ప్రత్యేక పాచెస్ కోసం చూడవలసిన అవసరం లేదు, ఈ సందర్భంలో ఫ్లో లేబుల్ సమస్యను పరిష్కరిస్తుందని మీకు తెలుసు, కానీ మీరు ఈ విధానాన్ని జాగ్రత్తగా సంప్రదించాలి. మరియు మీరు క్యారియర్ అయితే, మీరు ఫ్లో లేబుల్‌ను హాష్ ఫంక్షన్‌గా ఉపయోగించకూడదని, లేకపోతే మీరు మీ వినియోగదారుల సెషన్‌లను విచ్ఛిన్నం చేస్తారని నేను మళ్లీ నొక్కి చెబుతున్నాను.
నెట్‌వర్క్ ఇంజనీర్‌ల కోసం, సంభావిత మార్పు జరగాలి: నెట్‌వర్క్ ToRతో ప్రారంభం కాదు, నెట్‌వర్క్ పరికరంతో కాదు, హోస్ట్‌తో. RTOని మార్చడానికి మరియు ఏదైనా కాస్ట్ సేవలకు సంబంధించిన ఫ్లో లేబుల్‌ని సరిచేయడానికి మేము eBPFని ఎలా ఉపయోగిస్తాము అనేది చాలా అద్భుతమైన ఉదాహరణ.
ఫ్లో లేబుల్ మెకానిక్ నియంత్రిత అడ్మినిస్ట్రేటివ్ సెగ్మెంట్‌లోని ఇతర ఉపయోగాలకు ఖచ్చితంగా సరిపోతుంది. ఇది డేటా సెంటర్‌ల మధ్య ట్రాఫిక్ కావచ్చు లేదా అవుట్‌గోయింగ్ ట్రాఫిక్‌ను నియంత్రించడానికి మీరు అలాంటి మెకానిక్‌లను ప్రత్యేక పద్ధతిలో ఉపయోగించవచ్చు. కానీ నేను దీని గురించి మాట్లాడుతాను, తదుపరిసారి నేను ఆశిస్తున్నాను. మీ దృష్టికి చాలా ధన్యవాదాలు.
మూలం: www.habr.com