நவீன தரவு மையங்களில் நூற்றுக்கணக்கான செயலில் உள்ள சாதனங்கள் நிறுவப்பட்டுள்ளன, பல்வேறு வகையான கண்காணிப்புகள் உள்ளன. ஆனால் ஒரு சிறந்த பொறியாளர் கூட சரியான கண்காணிப்புடன் ஒரு சில நிமிடங்களில் நெட்வொர்க் தோல்விக்கு சரியாக பதிலளிக்க முடியும். நெக்ஸ்ட் ஹாப் 2020 மாநாட்டில் ஒரு அறிக்கையில், நான் DC நெட்வொர்க் வடிவமைப்பு முறையை முன்வைத்தேன், இது ஒரு தனித்துவமான அம்சத்தைக் கொண்டுள்ளது - தரவு மையம் மில்லி விநாடிகளில் தன்னைத்தானே குணப்படுத்துகிறது. இன்னும் துல்லியமாக, பொறியாளர் அமைதியாக சிக்கலை சரிசெய்கிறார், அதே நேரத்தில் சேவைகள் அதை கவனிக்கவில்லை.
பல நெட்வொர்க் பொறியாளர்களுக்கு, டேட்டா சென்டர் நெட்வொர்க், நிச்சயமாக, ToR உடன், ரேக்கில் ஒரு சுவிட்ச் மூலம் தொடங்குகிறது. ToR பொதுவாக இரண்டு வகையான இணைப்புகளைக் கொண்டுள்ளது. சிறியவை சேவையகங்களுக்குச் செல்கின்றன, மற்றவை - அவற்றில் N மடங்கு அதிகமாக உள்ளன - முதல் நிலையின் முதுகெலும்புகளை நோக்கி, அதாவது அதன் இணைப்புகளுக்குச் செல்கின்றன. அப்லிங்க்கள் பொதுவாக சமமாகக் கருதப்படுகின்றன, மேலும் 5-டூப்ளின் ஹாஷ் அடிப்படையில் அப்லிங்க்களுக்கு இடையிலான போக்குவரத்து சமநிலைப்படுத்தப்படுகிறது, இதில் புரோட்டோ, src_ip, dst_ip, src_port, dst_port ஆகியவை அடங்கும். இங்கே ஆச்சரியங்கள் இல்லை.
அடுத்து, திட்ட கட்டமைப்பு எப்படி இருக்கும்? முதல் நிலையின் முதுகெலும்புகள் ஒன்றோடொன்று இணைக்கப்படவில்லை, ஆனால் அவை சூப்பர்ஸ்பைன்கள் மூலம் இணைக்கப்பட்டுள்ளன. X எழுத்து சூப்பர்ஸ்பைன்களுக்கு பொறுப்பாகும்; இது கிட்டத்தட்ட ஒரு குறுக்கு இணைப்பு போன்றது.
மறுபுறம், டோரி முதல் நிலை அனைத்து முதுகெலும்புகளுடன் இணைக்கப்பட்டுள்ளது என்பது தெளிவாகிறது. இந்த படத்தில் முக்கியமானது என்ன? ரேக்கிற்குள் நாம் தொடர்பு கொண்டால், தொடர்பு, நிச்சயமாக, ToR வழியாக செல்கிறது. தொகுதிக்குள் தொடர்பு ஏற்பட்டால், முதல் நிலை முதுகெலும்புகள் மூலம் தொடர்பு ஏற்படுகிறது. தொடர்பு இடைநிலையாக இருந்தால் - இங்கே, ToR 1 மற்றும் ToR 2 - பின்னர் தொடர்பு முதல் மற்றும் இரண்டாவது நிலைகளின் முதுகெலும்புகள் வழியாக செல்லும்.
கோட்பாட்டில், அத்தகைய கட்டிடக்கலை எளிதில் அளவிடக்கூடியது. எங்களிடம் போர்ட் திறன், டேட்டா சென்டரில் ஸ்பேர் ஸ்பேஸ் மற்றும் ப்ரீ-லேட் ஃபைபர் இருந்தால், லேன்களின் எண்ணிக்கையை எப்பொழுதும் அதிகரிக்கலாம், அதன் மூலம் அமைப்பின் ஒட்டுமொத்த திறனை அதிகரிக்கும். காகிதத்தில் இதைச் செய்வது மிகவும் எளிதானது. வாழ்க்கையில் இப்படித்தான் இருக்கும். ஆனால் இன்றைய கதை அதைப் பற்றியது அல்ல.
சரியான முடிவுகள் எடுக்கப்பட வேண்டும் என்று நான் விரும்புகிறேன். தரவு மையத்திற்குள் பல பாதைகள் உள்ளன. அவர்கள் நிபந்தனையுடன் சுதந்திரமானவர்கள். தரவு மையத்திற்குள் ஒரு பாதை ToR க்குள் மட்டுமே சாத்தியமாகும். தொகுதியின் உள்ளே, பாதைகளின் எண்ணிக்கைக்கு சமமான பாதைகளின் எண்ணிக்கை உள்ளது. தொகுதிகளுக்கு இடையே உள்ள பாதைகளின் எண்ணிக்கை, ஒவ்வொரு விமானத்திலும் உள்ள விமானங்களின் எண்ணிக்கை மற்றும் சூப்பர் ஸ்பைன்களின் எண்ணிக்கை ஆகியவற்றின் பெருக்கத்திற்கு சமம். அதை தெளிவுபடுத்த, அளவின் உணர்வைப் பெற, Yandex தரவு மையங்களில் ஒன்றிற்கு செல்லுபடியாகும் எண்களை தருகிறேன்.
எட்டு விமானங்கள் உள்ளன, ஒவ்வொரு விமானத்திலும் 32 சூப்பர்ஸ்பைன்கள் உள்ளன. இதன் விளைவாக, தொகுதிக்குள் எட்டு பாதைகள் உள்ளன, மேலும் இடைநிலை தொடர்புடன் அவற்றில் ஏற்கனவே 256 உள்ளன.
அதாவது, நாங்கள் குக்புக்கை உருவாக்குகிறோம் என்றால், தங்களைத் தாங்களே குணப்படுத்திக் கொள்ளும் தவறு-சகிப்புத் தரவு மையங்களை எவ்வாறு உருவாக்குவது என்பதைக் கற்றுக் கொள்ள முயற்சிக்கிறோம் என்றால், பிளானர் கட்டிடக்கலை சரியான தேர்வாகும். இது அளவிடுதல் சிக்கலை தீர்க்கிறது, மேலும் கோட்பாட்டில் இது எளிதானது. பல சுதந்திரமான பாதைகள் உள்ளன. கேள்வி எஞ்சியுள்ளது: அத்தகைய கட்டிடக்கலை எவ்வாறு தோல்விகளைத் தக்கவைக்கிறது? பல்வேறு தோல்விகள் உள்ளன. மேலும் இதை இப்போது விவாதிப்போம்.
எங்கள் சூப்பர்ஸ்பைன்களில் ஒன்று "நோய்வாய்ப்படட்டும்". இங்கே நான் இரண்டு விமான கட்டிடக்கலைக்கு திரும்பினேன். இவைகளை உதாரணமாகக் கூறுவோம், ஏனெனில் குறைவான நகரும் பாகங்களில் என்ன நடக்கிறது என்பதைப் பார்ப்பது எளிதாக இருக்கும். X11 நோய்வாய்ப்படட்டும். தரவு மையங்களுக்குள் இருக்கும் சேவைகளை இது எவ்வாறு பாதிக்கும்? தோல்வி உண்மையில் எப்படி இருக்கும் என்பதைப் பொறுத்தது.
தோல்வி நன்றாக இருந்தால், அதே BFD-யின் ஆட்டோமேஷன் மட்டத்தில் பிடிபட்டால், ஆட்டோமேஷன் மகிழ்ச்சியுடன் சிக்கல் மூட்டுகளை வைத்து சிக்கலைத் தனிமைப்படுத்துகிறது, பின்னர் எல்லாம் நன்றாக இருக்கிறது. எங்களிடம் பல பாதைகள் உள்ளன, போக்குவரத்து உடனடியாக மாற்று வழிகளுக்கு மாற்றப்படுகிறது, மேலும் சேவைகள் எதையும் கவனிக்காது. இது ஒரு நல்ல ஸ்கிரிப்ட்.
நமக்கு நிலையான இழப்புகள் இருந்தால், மற்றும் ஆட்டோமேஷன் சிக்கலை கவனிக்கவில்லை என்றால் ஒரு மோசமான சூழ்நிலை. இது ஒரு பயன்பாட்டை எவ்வாறு பாதிக்கிறது என்பதைப் புரிந்து கொள்ள, TCP எவ்வாறு செயல்படுகிறது என்பதைப் பற்றி விவாதிக்க சிறிது நேரம் செலவிட வேண்டும்.
இந்தத் தகவலைக் கொண்டு நான் யாரையும் அதிர்ச்சியடையச் செய்யவில்லை என்று நம்புகிறேன்: TCP என்பது ஒரு பரிமாற்ற உறுதிப்படுத்தல் நெறிமுறை. அதாவது, எளிமையான வழக்கில், அனுப்புநர் இரண்டு பாக்கெட்டுகளை அனுப்புகிறார் மற்றும் அவற்றில் ஒரு ஒட்டுமொத்த ஏக்கைப் பெறுகிறார்: "நான் இரண்டு பாக்கெட்டுகளைப் பெற்றேன்."
அதன் பிறகு, அவர் மேலும் இரண்டு பாக்கெட்டுகளை அனுப்புவார், மேலும் நிலைமை மீண்டும் வரும். சில எளிமைப்படுத்தலுக்கு முன்கூட்டியே மன்னிப்பு கேட்டுக்கொள்கிறேன். சாளரம் (விமானத்தில் உள்ள பாக்கெட்டுகளின் எண்ணிக்கை) இரண்டாக இருந்தால் இந்த சூழ்நிலை சரியாக இருக்கும். நிச்சயமாக, பொது வழக்கில் இது அவசியம் இல்லை. ஆனால் சாளர அளவு பாக்கெட் பகிர்தல் சூழலை பாதிக்காது.
பாக்கெட் 3 ஐ இழந்தால் என்ன நடக்கும்? இந்த வழக்கில், பெறுநர் 1, 2 மற்றும் 4 பாக்கெட்டுகளைப் பெறுவார். மேலும் அவர் SACK விருப்பத்தைப் பயன்படுத்தி அனுப்புநரிடம் வெளிப்படையாகக் கூறுவார்: "உங்களுக்குத் தெரியும், மூன்று வந்துவிட்டது, ஆனால் நடுப்பகுதி தொலைந்து விட்டது." அவர் கூறுகிறார், "அக் 2, சாக் 4."
இந்த நேரத்தில், அனுப்புநர் எந்த பிரச்சனையும் இல்லாமல் இழந்த பாக்கெட்டை சரியாக மீண்டும் செய்கிறார்.
ஆனால் சாளரத்தின் கடைசி பாக்கெட் தொலைந்துவிட்டால், நிலைமை முற்றிலும் மாறுபட்டதாக இருக்கும்.
பெறுநர் முதல் மூன்று பாக்கெட்டுகளைப் பெறுகிறார், முதலில் காத்திருக்கத் தொடங்குகிறார். லினக்ஸ் கர்னலின் TCP ஸ்டேக்கில் உள்ள சில மேம்படுத்தல்களுக்கு நன்றி, கொடிகள் இது கடைசி பாக்கெட் அல்லது அது போன்ற ஏதாவது ஒன்றை வெளிப்படையாகக் குறிப்பிடும் வரை, அது ஒரு ஜோடி பாக்கெட்டுக்காக காத்திருக்கும். இது தாமதமான ACK காலாவதியாகும் வரை காத்திருந்து முதல் மூன்று பாக்கெட்டுகளுக்கு ஒப்புகையை அனுப்பும். ஆனால் இப்போது அனுப்புபவர் காத்திருப்பார். நான்காவது தொகுப்பு தொலைந்துவிட்டதா அல்லது வரப்போகிறதா என்பது அவருக்குத் தெரியாது. நெட்வொர்க்கை ஓவர்லோட் செய்யாமல் இருக்க, பாக்கெட் தொலைந்துவிட்டதா அல்லது ஆர்டிஓ காலாவதியாகும் என்பதற்கான வெளிப்படையான அறிகுறிக்காக காத்திருக்க முயற்சிக்கும்.
RTO காலக்கெடு என்றால் என்ன? இது TCP ஸ்டாக் மற்றும் சில மாறிலி மூலம் கணக்கிடப்படும் RTT இன் அதிகபட்சமாகும். இது என்ன வகையான நிலையானது, இப்போது நாம் விவாதிப்போம்.
ஆனால் முக்கியமான விஷயம் என்னவென்றால், நாம் மீண்டும் துரதிர்ஷ்டவசமாகி, நான்காவது பாக்கெட் மீண்டும் தொலைந்துவிட்டால், RTO இரட்டிப்பாகும். அதாவது, ஒவ்வொரு தோல்வியுற்ற முயற்சியும் நேரத்தை இரட்டிப்பாக்குகிறது.
இப்போது இந்த அடிப்படை எதற்கு சமம் என்று பார்ப்போம். இயல்பாக, குறைந்தபட்ச RTO 200 ms ஆகும். இது தரவு தொகுப்புகளுக்கான குறைந்தபட்ச RTO ஆகும். SYN பாக்கெட்டுகளுக்கு இது வேறுபட்டது, 1 வினாடி. நீங்கள் பார்க்க முடியும் என, பாக்கெட்டுகளை மீண்டும் அனுப்புவதற்கான முதல் முயற்சி கூட தரவு மையத்தில் உள்ள RTTயை விட 100 மடங்கு அதிக நேரம் எடுக்கும்.
இப்போது நமது காட்சிக்கு வருவோம். சேவையில் என்ன நடக்கிறது? சேவை பாக்கெட்டுகளை இழக்கத் தொடங்குகிறது. சேவையானது முதலில் நிபந்தனையுடன் அதிர்ஷ்டமாக இருக்கட்டும் மற்றும் சாளரத்தின் நடுவில் எதையாவது இழக்கட்டும், பின்னர் அது ஒரு SACK ஐப் பெற்று தொலைந்த பாக்கெட்டுகளை மீண்டும் அனுப்புகிறது.
ஆனால் துரதிர்ஷ்டம் மீண்டும் நடந்தால், எங்களிடம் ஒரு ஆர்.டி.ஓ. இங்கே என்ன முக்கியம்? ஆம், எங்கள் நெட்வொர்க்கில் நிறைய பாதைகள் உள்ளன. ஆனால் ஒரு குறிப்பிட்ட TCP இணைப்பின் TCP ட்ராஃபிக் அதே உடைந்த அடுக்கின் வழியாகச் செல்லும். பாக்கெட் இழப்புகள், எங்களுடைய இந்த மாயாஜால X11 தானாகவே வெளியேறாது, சிக்கல் இல்லாத பகுதிகளுக்கு போக்குவரத்துக்கு வழிவகுக்காது. அதே உடைந்த ஸ்டாக் மூலம் பாக்கெட்டை வழங்க முயற்சிக்கிறோம். இது ஒரு அடுக்கு தோல்விக்கு வழிவகுக்கிறது: தரவு மையம் என்பது ஊடாடும் பயன்பாடுகளின் தொகுப்பாகும், மேலும் இந்த எல்லா பயன்பாடுகளின் சில TCP இணைப்புகளும் சிதையத் தொடங்குகின்றன - ஏனெனில் சூப்பர்ஸ்பைன் தரவு மையத்திற்குள் இருக்கும் அனைத்து பயன்பாடுகளையும் பாதிக்கிறது. பழமொழி சொல்வது போல்: நீங்கள் குதிரைக்கு காலணி போடவில்லை என்றால், குதிரை முடமாகிவிட்டது; குதிரை நொண்டிச் சென்றது - அறிக்கை வழங்கப்படவில்லை; அறிக்கை வழங்கப்படவில்லை - நாங்கள் போரை இழந்தோம். பிரச்சனை எழும் தருணத்திலிருந்து சேவைகள் உணரத் தொடங்கும் சீரழிவு நிலைக்கு இங்கு மட்டுமே எண்ணிக்கை வினாடிகளில் உள்ளது. இதன் பொருள் பயனர்கள் எங்காவது எதையாவது இழக்க நேரிடலாம்.
ஒருவருக்கொருவர் பூர்த்தி செய்யும் இரண்டு உன்னதமான தீர்வுகள் உள்ளன. முதலாவது, ஸ்ட்ராவை வைத்து சிக்கலைத் தீர்க்க முயற்சிக்கும் சேவைகள்: “டிசிபி ஸ்டேக்கில் ஏதாவது மாற்றுவோம். பயன்பாட்டு நிலை அல்லது நீண்ட கால டிசிபி அமர்வுகளில் உள்ளக சுகாதார சோதனைகளுடன் காலக்கெடுவை செய்வோம்." பிரச்சனை என்னவென்றால், அத்தகைய தீர்வுகள்: அ) அளவிடவே இல்லை; b) மிகவும் மோசமாக சரிபார்க்கப்பட்டது. அதாவது, சேவையானது தற்செயலாக TCP ஸ்டேக்கை சிறந்த முறையில் கட்டமைத்தாலும், முதலாவதாக, அனைத்து பயன்பாடுகளுக்கும் அனைத்து தரவு மையங்களுக்கும் இது பொருந்தாது, இரண்டாவதாக, பெரும்பாலும், அது செய்யப்பட்டது என்பதை அது புரிந்து கொள்ளாது. சரியாக, மற்றும் என்ன இல்லை. அதாவது, அது வேலை செய்கிறது, ஆனால் அது மோசமாக வேலை செய்கிறது மற்றும் அளவிடாது. மேலும் நெட்வொர்க் பிரச்சனை என்றால், யார் குற்றம் சொல்ல வேண்டும்? நிச்சயமாக, என்ஓசி. NOC என்ன செய்கிறது?
பல சேவைகள் NOC இல் இது போன்ற ஏதாவது நடக்கும் என்று நம்புகிறார்கள். ஆனால் நேர்மையாக இருக்க வேண்டும், அது மட்டுமல்ல.
கிளாசிக்கல் திட்டத்தில் NOC பல கண்காணிப்பு அமைப்புகளின் வளர்ச்சியில் ஈடுபட்டுள்ளது. இவை கருப்பு பெட்டி மற்றும் வெள்ளை பெட்டி கண்காணிப்பு. கருப்பு பெட்டி முதுகெலும்பு கண்காணிப்பு உதாரணம் பற்றி கடைசி அடுத்த ஹாப்பில் அலெக்சாண்டர் கிளிமென்கோ. மூலம், இந்த கண்காணிப்பு வேலை செய்கிறது. ஆனால் சிறந்த கண்காணிப்புக்கு கூட கால தாமதம் இருக்கும். பொதுவாக இது சில நிமிடங்கள் ஆகும். அது செயலிழந்த பிறகு, பணியில் இருக்கும் பொறியாளர்கள் அதன் செயல்பாட்டை இருமுறை சரிபார்த்து, சிக்கலை உள்ளூர்மயமாக்கி, சிக்கல் பகுதியை அணைக்க நேரம் தேவைப்படுகிறது. அதாவது, சிறந்த வழக்கில், பிரச்சனைக்கு சிகிச்சையளிப்பது 5 நிமிடங்கள் எடுக்கும், மோசமான நிலையில், 20 நிமிடங்கள், இழப்புகள் எங்கே ஏற்படுகின்றன என்பது உடனடியாகத் தெரியவில்லை என்றால். இந்த நேரத்தில் - 5 அல்லது 20 நிமிடங்கள் - எங்கள் சேவைகள் தொடர்ந்து பாதிக்கப்படும் என்பது தெளிவாகிறது, இது நல்லதல்ல.
நீங்கள் உண்மையில் எதைப் பெற விரும்புகிறீர்கள்? எங்களிடம் பல வழிகள் உள்ளன. துரதிர்ஷ்டவசமான TCP ஓட்டங்கள் அதே வழியைத் தொடர்ந்து பயன்படுத்துவதால், சிக்கல்கள் துல்லியமாக எழுகின்றன. ஒரு TCP இணைப்பிற்குள் பல வழிகளைப் பயன்படுத்த அனுமதிக்கும் ஒன்று எங்களுக்குத் தேவை. எங்களிடம் ஒரு தீர்வு இருக்கிறது என்று தோன்றுகிறது. TCP உள்ளது, இது மல்டிபாத் TCP என்று அழைக்கப்படுகிறது, அதாவது பல பாதைகளுக்கான TCP. உண்மை, இது முற்றிலும் மாறுபட்ட பணிக்காக உருவாக்கப்பட்டது - பல நெட்வொர்க் சாதனங்களைக் கொண்ட ஸ்மார்ட்போன்களுக்கு. பரிமாற்றத்தை அதிகரிக்க அல்லது முதன்மை/காப்புப் பயன்முறையை உருவாக்க, பயன்பாட்டிற்கு வெளிப்படையான பல நூல்களை (அமர்வுகளை) உருவாக்கி, தோல்வி ஏற்பட்டால் அவற்றுக்கிடையே மாற உங்களை அனுமதிக்கும் ஒரு வழிமுறை உருவாக்கப்பட்டது. அல்லது, நான் சொன்னது போல், ஸ்ட்ரீக்கை அதிகரிக்கவும்.
ஆனால் இங்கே ஒரு நுணுக்கம் உள்ளது. அது என்ன என்பதைப் புரிந்து கொள்ள, நூல்கள் எவ்வாறு நிறுவப்படுகின்றன என்பதைப் பார்க்க வேண்டும்.
நூல்கள் தொடர்ச்சியாக நிறுவப்பட்டுள்ளன. முதல் நூல் முதலில் நிறுவப்பட்டது. அந்தத் தொடரில் ஏற்கனவே ஒப்புக்கொள்ளப்பட்ட குக்கீயைப் பயன்படுத்தி அடுத்தடுத்த இழைகள் அமைக்கப்படும். மற்றும் இங்கே பிரச்சனை.
பிரச்சனை என்னவென்றால், முதல் நூல் தன்னை நிலைநிறுத்திக் கொள்ளாவிட்டால், இரண்டாவது மற்றும் மூன்றாவது இழைகள் ஒருபோதும் எழாது. அதாவது, மல்டிபாத் TCP ஆனது முதல் ஓட்டத்தில் SYN பாக்கெட்டின் இழப்பை தீர்க்காது. SYN தொலைந்துவிட்டால், மல்டிபாத் TCP ஆனது வழக்கமான TCP ஆக மாறும். இதன் பொருள், தரவு மைய சூழலில் தொழிற்சாலையில் ஏற்படும் இழப்புகளின் சிக்கலைத் தீர்க்கவும், தோல்வி ஏற்பட்டால் பல பாதைகளைப் பயன்படுத்தவும் இது எங்களுக்கு உதவாது.
எது நமக்கு உதவும்? எங்கள் அடுத்த கதையில் IPv6 ஃப்ளோ லேபிள் தலைப்புப் புலம் முக்கியமானதாக இருக்கும் என்று உங்களில் சிலர் ஏற்கனவே தலைப்பிலிருந்து யூகித்திருக்கிறீர்கள். உண்மையில், இது v6 இல் தோன்றும் ஒரு புலம், இது v4 இல் இல்லை, இது 20 பிட்களை ஆக்கிரமித்துள்ளது, மேலும் நீண்ட காலமாக அதன் பயன்பாட்டில் சர்ச்சை உள்ளது. இது மிகவும் சுவாரஸ்யமானது - சர்ச்சைகள் இருந்தன, RFC க்குள் ஏதோ சரி செய்யப்பட்டது, அதே நேரத்தில் Linux கர்னலில் ஒரு செயல்படுத்தல் தோன்றியது, அது எங்கும் ஆவணப்படுத்தப்படவில்லை.
ஒரு சிறிய விசாரணைக்கு என்னுடன் செல்ல உங்களை அழைக்கிறேன். கடந்த சில ஆண்டுகளாக லினக்ஸ் கர்னலில் என்ன நடக்கிறது என்பதைப் பார்ப்போம்.
ஆண்டு 2014. ஒரு பெரிய மற்றும் மரியாதைக்குரிய நிறுவனத்தைச் சேர்ந்த ஒரு பொறியாளர், லினக்ஸ் கர்னலின் செயல்பாட்டிற்கு சாக்கெட் ஹாஷில் ஃப்ளோ லேபிள் மதிப்பின் சார்புநிலையைச் சேர்க்கிறார். அவர்கள் இங்கே என்ன செய்ய முயன்றார்கள்? இது RFC 6438 உடன் தொடர்புடையது, இது பின்வரும் சிக்கலைப் பற்றி விவாதித்தது. தரவு மையத்தின் உள்ளே, IPv4 பெரும்பாலும் IPv6 பாக்கெட்டுகளில் இணைக்கப்பட்டுள்ளது, ஏனெனில் தொழிற்சாலையே IPv6 ஆகும், ஆனால் IPv4 எப்படியாவது வெளியே கொடுக்கப்பட வேண்டும். TCP அல்லது UDP ஐப் பெறுவதற்கும், src_ports, dst_ports ஆகியவற்றைக் கண்டறிவதற்கும் இரண்டு IP தலைப்புகளின் கீழ் பார்க்க முடியாத சுவிட்சுகளில் நீண்ட காலமாக சிக்கல்கள் இருந்தன. முதல் இரண்டு ஐபி தலைப்புகளைப் பார்த்தால், ஹாஷ் கிட்டத்தட்ட சரி செய்யப்பட்டது. இதைத் தவிர்க்க, இந்த இணைக்கப்பட்ட போக்குவரத்தை சமநிலைப்படுத்துவது சரியாகச் செயல்படும் வகையில், 5-டுப்பிள் இணைக்கப்பட்ட பாக்கெட்டின் ஹாஷை ஃப்ளோ லேபிள் புலத்தின் மதிப்பில் சேர்க்க முன்மொழியப்பட்டது. தோராயமாக மற்ற இணைத்தல் திட்டங்களுக்கும், UDP க்கும், GRE க்கும், GRE கீ புலத்தைப் பயன்படுத்தியது. ஒரு வழி அல்லது வேறு, இங்கே இலக்குகள் தெளிவாக உள்ளன. குறைந்தபட்சம் அந்த நேரத்தில் அவை பயனுள்ளதாக இருந்தன.
2015 இல், அதே மரியாதைக்குரிய பொறியாளரிடமிருந்து ஒரு புதிய இணைப்பு வந்தது. அவர் மிகவும் சுவாரஸ்யமானவர். இது பின்வருவனவற்றைக் கூறுகிறது - எதிர்மறையான ரூட்டிங் நிகழ்வின் போது ஹாஷை ரேண்டம் செய்வோம். எதிர்மறையான ரூட்டிங் நிகழ்வு என்றால் என்ன? நாம் முன்பு விவாதித்த RTO இதுதான், அதாவது, சாளரத்தின் வால் இழப்பு உண்மையிலேயே எதிர்மறையான ஒரு நிகழ்வு. உண்மை, இதுதான் என்று யூகிப்பது ஒப்பீட்டளவில் கடினம்.
2016, மற்றொரு புகழ்பெற்ற நிறுவனம், பெரியது. இது கடைசி ஊன்றுகோலைப் பிரித்து, நாங்கள் முன்பு சீரற்ற முறையில் உருவாக்கிய ஹாஷ், இப்போது ஒவ்வொரு SYN மறுபரிமாற்றத்திற்கும் ஒவ்வொரு RTO காலக்கெடுவுக்குப் பிறகும் மாறுகிறது. இந்த கடிதத்தில், முதல் மற்றும் கடைசி முறையாக, இறுதி இலக்கு கூறப்பட்டுள்ளது - இழப்புகள் அல்லது சேனல் நெரிசல் ஏற்பட்டால் போக்குவரத்தை மென்மையாக மாற்றியமைத்து பல பாதைகளைப் பயன்படுத்தும் திறனை உறுதிசெய்வது. நிச்சயமாக, இதற்குப் பிறகு நிறைய வெளியீடுகள் இருந்தன, அவற்றை நீங்கள் எளிதாகக் காணலாம்.
இல்லை என்றாலும், உங்களால் முடியாது, ஏனெனில் இந்த தலைப்பில் ஒரு வெளியீடு கூட இல்லை. ஆனால் எங்களுக்கு தெரியும்!
என்ன செய்யப்பட்டது என்பதை நீங்கள் முழுமையாக புரிந்து கொள்ளவில்லை என்றால், நான் இப்போது உங்களுக்கு சொல்கிறேன்.
என்ன செய்யப்பட்டது, லினக்ஸ் கர்னலில் என்ன செயல்பாடு சேர்க்கப்பட்டது? ஒவ்வொரு RTO நிகழ்வுக்குப் பிறகும் txhash ஒரு சீரற்ற மதிப்பாக மாறுகிறது. இது ரூட்டிங் மிகவும் எதிர்மறையான விளைவு ஆகும். ஹாஷ் இந்த txhash ஐச் சார்ந்தது, மேலும் ஃப்ளோ லேபிள் skb ஹாஷைப் பொறுத்தது. இங்கே செயல்பாடுகளில் சில கணக்கீடுகள் உள்ளன; அனைத்து விவரங்களையும் ஒரு ஸ்லைடில் வைக்க முடியாது. யாராவது ஆர்வமாக இருந்தால், நீங்கள் கர்னல் குறியீட்டின் மூலம் சென்று சரிபார்க்கலாம்.
இங்கே என்ன முக்கியம்? ஓட்டம் லேபிள் புலத்தின் மதிப்பு ஒவ்வொரு ஆர்டிஓவிற்குப் பிறகும் சீரற்ற எண்ணாக மாறுகிறது. இது எங்கள் துரதிர்ஷ்டவசமான TCP ஸ்ட்ரீமை எவ்வாறு பாதிக்கிறது?
SACK ஏற்பட்டால், அறியப்பட்ட தொலைந்த பாக்கெட்டை மீண்டும் அனுப்ப முயற்சிப்பதால் எதுவும் மாறாது. இதுவரை மிகவும் நல்ல.
ஆனால் RTO விஷயத்தில், ToR இல் உள்ள ஹாஷ் செயல்பாட்டிற்கு ஃப்ளோ லேபிளைச் சேர்த்திருந்தால், போக்குவரத்து வேறு வழியில் செல்லலாம். மேலும் அதிக பாதைகள், ஒரு குறிப்பிட்ட சாதனத்தில் தோல்வியால் பாதிக்கப்படாத பாதையைக் கண்டறியும் வாய்ப்பு அதிகம்.
ஒரு சிக்கல் உள்ளது - RTO. நிச்சயமாக, மற்றொரு பாதை உள்ளது, ஆனால் இதில் நிறைய நேரம் வீணடிக்கப்படுகிறது. 200 எம்எஸ் என்பது அதிகம். ஒரு வினாடி முற்றிலும் காட்டுத்தனமானது. முன்னதாக, சேவைகள் கட்டமைக்கப்பட்ட காலக்கெடுவைப் பற்றி நான் பேசினேன். எனவே, வினாடி என்பது காலாவதியாகும், இது வழக்கமாக பயன்பாட்டு மட்டத்தில் சேவையால் கட்டமைக்கப்படுகிறது, மேலும் இதில் சேவை ஒப்பீட்டளவில் சரியாக இருக்கும். மேலும், நான் மீண்டும் சொல்கிறேன், நவீன தரவு மையத்தில் உள்ள உண்மையான RTT சுமார் 1 மில்லி வினாடி ஆகும்.
RTO காலக்கெடுவை நீங்கள் என்ன செய்யலாம்? தரவு பாக்கெட்டுகள் இழப்பு ஏற்பட்டால் RTO க்கு பொறுப்பான காலக்கெடு, பயனர் இடத்திலிருந்து ஒப்பீட்டளவில் எளிதாக உள்ளமைக்கப்படலாம்: ஒரு IP பயன்பாடு உள்ளது, மேலும் அதன் அளவுருக்களில் ஒன்றில் அதே rto_min உள்ளது. RTO, நிச்சயமாக, உலகளவில் அல்ல, ஆனால் கொடுக்கப்பட்ட முன்னொட்டுகளுக்கு, அத்தகைய பொறிமுறையானது மிகவும் செயல்படக்கூடியதாகத் தெரிகிறது.
உண்மை, SYN_RTO இல் எல்லாம் ஓரளவு மோசமாக உள்ளது. இது இயற்கையாகவே ஆணி அடிக்கப்படுகிறது. கர்னல் 1 வினாடியின் நிலையான மதிப்பைக் கொண்டுள்ளது, அவ்வளவுதான். பயனர் இடத்திலிருந்து நீங்கள் அங்கு செல்ல முடியாது. ஒரே ஒரு வழிதான் இருக்கிறது.
eBPF மீட்புக்கு வருகிறது. எளிமையாகச் சொல்வதென்றால், இவை சிறிய சி புரோகிராம்கள், கர்னல் ஸ்டாக் மற்றும் டிசிபி ஸ்டேக்கின் செயல்பாட்டில் வெவ்வேறு இடங்களில் உள்ள கொக்கிகளில் செருகப்படலாம், இதன் மூலம் நீங்கள் அதிக எண்ணிக்கையிலான அமைப்புகளை மாற்றலாம். பொதுவாக, eBPF ஒரு நீண்ட கால போக்கு. டஜன் கணக்கான புதிய sysctl அளவுருக்களை வெட்டி ஐபி பயன்பாட்டை விரிவுபடுத்துவதற்கு பதிலாக, இயக்கம் eBPF நோக்கி நகர்ந்து அதன் செயல்பாட்டை விரிவுபடுத்துகிறது. eBPF ஐப் பயன்படுத்தி, நீங்கள் நெரிசல் கட்டுப்பாடுகள் மற்றும் பல்வேறு TCP அமைப்புகளை மாறும் வகையில் மாற்றலாம்.
ஆனால் SYN_RTO மதிப்புகளை மாற்ற இதைப் பயன்படுத்தலாம் என்பது எங்களுக்கு முக்கியம். மேலும், பொதுவில் வெளியிடப்பட்ட உதாரணம் உள்ளது: . இங்கு என்ன செய்யப்பட்டுள்ளது? உதாரணம் வேலை செய்கிறது, ஆனால் அது மிகவும் கடினமானது. இங்கே தரவு மையத்திற்குள் நாம் முதல் 44 பிட்களை ஒப்பிடுகிறோம் என்று கருதப்படுகிறது; அவை பொருந்தினால், நாங்கள் தரவு மையத்திற்குள் இருக்கிறோம். இந்த வழக்கில் SYN_RTO காலாவதி மதிப்பை 4ms ஆக மாற்றுவோம். அதே பணியை மிக நேர்த்தியாக செய்ய முடியும். ஆனால் இந்த எளிய உதாரணம் இது சாத்தியம் என்பதை காட்டுகிறது; b) ஒப்பீட்டளவில் எளிமையானது.
நமக்கு ஏற்கனவே என்ன தெரியும்? ப்ளேன் ஆர்கிடெக்ச்சர் அளவிடுவதற்கு அனுமதிக்கிறது என்பது, ToR இல் ஃப்ளோ லேபிளை இயக்கி, சிக்கல் பகுதிகளைச் சுற்றிப் பாயும் திறனைப் பெறும்போது அது நமக்கு மிகவும் பயனுள்ளதாக இருக்கும். RTO மற்றும் SYN-RTO மதிப்புகளைக் குறைப்பதற்கான சிறந்த வழி eBPF நிரல்களைப் பயன்படுத்துவதாகும். கேள்வி எஞ்சியுள்ளது: சமநிலைப்படுத்த ஓட்ட லேபிளைப் பயன்படுத்துவது பாதுகாப்பானதா? மேலும் இங்கே ஒரு நுணுக்கம் உள்ளது.
உங்கள் நெட்வொர்க்கில் ஏதேனும் ஒரு சேவை உள்ளது என்று வைத்துக்கொள்வோம். துரதிர்ஷ்டவசமாக, Anycast என்றால் என்ன என்பதைப் பற்றி விரிவாகச் சொல்ல எனக்கு நேரம் இல்லை, ஆனால் இது ஒரே IP முகவரி வழியாக அணுகக்கூடிய வெவ்வேறு இயற்பியல் சேவையகங்களைக் கொண்ட விநியோகிக்கப்பட்ட சேவையாகும். இங்கே ஒரு சாத்தியமான சிக்கல் உள்ளது: RTO நிகழ்வு துணி வழியாக போக்குவரத்து கடந்து செல்லும் போது மட்டும் நிகழலாம். இது ToR இடையக நிலையிலும் நிகழலாம்: ஒரு இன்காஸ்ட் நிகழ்வு நிகழும்போது, ஹோஸ்ட் எதையாவது கொட்டும்போது அது ஹோஸ்டில் கூட நிகழலாம். ஆர்டிஓ நிகழ்வு நிகழும்போது அது ஓட்ட லேபிளை மாற்றும். இந்த வழக்கில், போக்குவரத்து வேறு எந்த நேரத்திலும் செல்லலாம். இது ஒரு ஸ்டேட்ஃபுல் அனிகாஸ்ட் என்று வைத்துக்கொள்வோம், இது ஒரு இணைப்பு நிலையைக் கொண்டுள்ளது - இது ஒரு L3 பேலன்சர் அல்லது வேறு ஏதேனும் சேவையாக இருக்கலாம். பின்னர் ஒரு சிக்கல் எழுகிறது, ஏனென்றால் RTO க்குப் பிறகு TCP இணைப்பு சேவையகத்திற்கு வருகிறது, இந்த TCP இணைப்பு பற்றி எதுவும் தெரியாது. எங்களிடம் ஏதேனும் காஸ்ட் சேவையகங்களுக்கு இடையே மாநில பகிர்வு இல்லை என்றால், அத்தகைய ட்ராஃபிக் கைவிடப்படும் மற்றும் TCP இணைப்பு உடைக்கப்படும்.
நீங்கள் இங்கே என்ன செய்ய முடியும்? உங்கள் கட்டுப்படுத்தப்பட்ட சூழலில், நீங்கள் ஃப்ளோ லேபிள் சமநிலையை இயக்கும் போது, ஏதேனும்காஸ்ட் சர்வர்களை அணுகும்போது, ஃப்ளோ லேபிளின் மதிப்பை நீங்கள் பதிவு செய்ய வேண்டும். அதே eBPF திட்டத்தின் மூலம் இதைச் செய்வது எளிதான வழி. ஆனால் இங்கே ஒரு மிக முக்கியமான விஷயம் உள்ளது - நீங்கள் ஒரு டேட்டா சென்டர் நெட்வொர்க்கை இயக்கவில்லை, ஆனால் டெலிகாம் ஆபரேட்டராக இருந்தால் என்ன செய்வது? இது உங்கள் பிரச்சனையும் கூட: ஜூனிபர் மற்றும் அரிஸ்டாவின் சில பதிப்புகளில் தொடங்கி, அவை ஹாஷ் செயல்பாடுகளில் இயல்பாகவே ஒரு ஃப்ளோ லேபிளைச் சேர்க்கின்றன - வெளிப்படையாக, ஒரு காரணத்திற்காக எனக்கு தெளிவாக இல்லை. இது உங்கள் நெட்வொர்க் வழியாகச் செல்லும் பயனர்களிடமிருந்து TCP இணைப்புகளை நீங்கள் கைவிடக்கூடும். எனவே உங்கள் திசைவி அமைப்புகளை இங்கே சரிபார்க்க நான் மிகவும் பரிந்துரைக்கிறேன்.
ஒரு வழி அல்லது வேறு, நாங்கள் சோதனைகளுக்கு செல்ல தயாராக இருக்கிறோம் என்று எனக்குத் தோன்றுகிறது.
ToR இல் ஃப்ளோ லேபிளை இயக்கியபோது, eBPF முகவரைத் தயார் செய்தோம், அது இப்போது ஹோஸ்ட்களில் உள்ளது, அடுத்த பெரிய தோல்விக்காக காத்திருக்காமல், கட்டுப்படுத்தப்பட்ட வெடிப்புகளை நடத்த முடிவு செய்தோம். நான்கு அப்லிங்க்களைக் கொண்ட ToRஐ எடுத்து, அவற்றில் ஒன்றில் சொட்டுகளை அமைத்தோம். அவர்கள் ஒரு விதியை வரைந்து சொன்னார்கள் - இப்போது நீங்கள் அனைத்து பாக்கெட்டுகளையும் இழக்கிறீர்கள். நீங்கள் இடதுபுறத்தில் பார்ப்பது போல், எங்களிடம் ஒரு பாக்கெட் கண்காணிப்பு உள்ளது, இது 75% ஆகக் குறைந்துள்ளது, அதாவது 25% பாக்கெட்டுகள் தொலைந்துவிட்டன. வலதுபுறத்தில் இந்த ToRக்கு பின்னால் வாழும் சேவைகளின் வரைபடங்கள் உள்ளன. அடிப்படையில், இவை ரேக்கிற்குள் இருக்கும் சேவையகங்களுடனான இடைமுகங்களின் போக்குவரத்து வரைபடங்கள். நீங்கள் பார்க்க முடியும் என, அவை இன்னும் கீழே மூழ்கின. அவை ஏன் குறைந்தன - 25% அல்ல, ஆனால் சில சந்தர்ப்பங்களில் 3-4 மடங்கு? TCP இணைப்பு துரதிர்ஷ்டவசமாக இருந்தால், அது உடைந்த சந்திப்பு வழியாக அடைய முயற்சிக்கிறது. DC க்குள் இருக்கும் சேவையின் வழக்கமான நடத்தையால் இது மோசமாகிறது - ஒரு பயனர் கோரிக்கைக்கு, உள் சேவைகளுக்கான N கோரிக்கைகள் உருவாக்கப்படுகின்றன, மேலும் எல்லா தரவு ஆதாரங்களும் பதிலளிக்கும் போது அல்லது பயன்பாட்டில் காலக்கெடு ஏற்படும் போது பதில் பயனருக்குச் செல்லும். நிலை, இது இன்னும் கட்டமைக்கப்பட வேண்டும். அதாவது, எல்லாம் மிக மிக மோசமானது.
இப்போது அதே சோதனை, ஆனால் ஃப்ளோ லேபிள் மதிப்பு இயக்கப்பட்டது. நீங்கள் பார்க்க முடியும் என, இடதுபுறத்தில் எங்கள் தொகுதி கண்காணிப்பு அதே 25% குறைந்துள்ளது. இது முற்றிலும் சரியானது, ஏனெனில் அதற்கு மறுபரிமாற்றம் பற்றி எதுவும் தெரியாது, இது பாக்கெட்டுகளை அனுப்புகிறது மற்றும் வழங்கப்பட்ட மற்றும் தொலைந்த பாக்கெட்டுகளின் எண்ணிக்கையின் விகிதத்தை கணக்கிடுகிறது.
மற்றும் வலதுபுறத்தில் சேவை அட்டவணை உள்ளது. பிரச்சனைக்குரிய மூட்டின் விளைவை நீங்கள் இங்கே காண முடியாது. அதே மில்லி விநாடிகளில், சிக்கல் பகுதியிலிருந்து சிக்கலால் பாதிக்கப்படாத மீதமுள்ள மூன்று மேல் இணைப்புகளுக்கு போக்குவரத்து சென்றது. தன்னைத்தானே குணப்படுத்திக் கொள்ளும் ஒரு நெட்வொர்க் எங்களிடம் உள்ளது.
இது எனது கடைசி ஸ்லைடு, சுருக்கமாக சொல்ல வேண்டிய நேரம். இப்போது, சுய-குணப்படுத்தும் தரவு மைய நெட்வொர்க்கை எவ்வாறு உருவாக்குவது என்பது உங்களுக்குத் தெரியும் என்று நம்புகிறேன். நீங்கள் லினக்ஸ் கர்னல் காப்பகத்திற்குச் சென்று அங்கு சிறப்பு இணைப்புகளைத் தேட வேண்டியதில்லை; இந்த விஷயத்தில் ஃப்ளோ லேபிள் சிக்கலைத் தீர்க்கிறது என்பதை நீங்கள் அறிவீர்கள், ஆனால் நீங்கள் இந்த பொறிமுறையை கவனமாக அணுக வேண்டும். நீங்கள் ஒரு டெலிகாம் ஆபரேட்டராக இருந்தால், ஃப்ளோ லேபிளை ஹாஷ் செயல்பாடாகப் பயன்படுத்தக்கூடாது, இல்லையெனில் உங்கள் பயனர்களின் அமர்வுகளை சீர்குலைப்பீர்கள் என்பதை மீண்டும் ஒருமுறை வலியுறுத்துகிறேன்.
நெட்வொர்க் பொறியாளர்கள் ஒரு கருத்தியல் மாற்றத்திற்கு உட்படுத்தப்பட வேண்டும்: நெட்வொர்க் ToR உடன் தொடங்கவில்லை, பிணைய சாதனத்துடன் அல்ல, ஆனால் ஹோஸ்டுடன் தொடங்குகிறது. ஆர்டிஓவை மாற்றுவதற்கும், ஏனிகாஸ்ட் சேவைகளுக்கான ஃப்ளோ லேபிளைச் சரிசெய்வதற்கும் eBPFஐ எவ்வாறு பயன்படுத்துகிறோம் என்பது மிகவும் குறிப்பிடத்தக்க உதாரணம்.
கட்டுப்படுத்தப்பட்ட நிர்வாகப் பிரிவில் உள்ள பிற பயன்பாடுகளுக்கு ஓட்ட லேபிள் இயக்கவியல் நிச்சயமாகப் பொருத்தமானது. இது தரவு மையங்களுக்கு இடையேயான போக்குவரமாக இருக்கலாம் அல்லது வெளிச்செல்லும் போக்குவரத்தை நிர்வகிக்க சிறப்பு வழியில் இத்தகைய இயக்கவியலைப் பயன்படுத்தலாம். ஆனால் இதைப் பற்றி நான் உங்களுக்கு சொல்கிறேன், நான் நம்புகிறேன், அடுத்த முறை. உங்கள் கவனத்திற்கு மிக்க நன்றி.
ஆதாரம்: www.habr.com