இணைப்பு கண்காணிப்பு (“contrack”) என்பது லினக்ஸ் கர்னல் நெட்வொர்க்கிங் ஸ்டேக்கின் முக்கிய அம்சமாகும். இது கர்னலை அனைத்து தருக்க பிணைய இணைப்புகள் அல்லது ஓட்டங்களைக் கண்காணிக்க அனுமதிக்கிறது மற்றும் அதன் மூலம் ஒவ்வொரு ஓட்டத்தையும் உருவாக்கும் அனைத்து பாக்கெட்டுகளையும் அடையாளம் காண அனுமதிக்கிறது.
Conntrack என்பது ஒரு முக்கியமான கர்னல் அம்சமாகும், இது சில அடிப்படை நிகழ்வுகளில் பயன்படுத்தப்படுகிறது:
- NAT ஆனது conntrack இலிருந்து தகவலை நம்பியுள்ளது, எனவே அது ஒரே ஸ்ட்ரீமில் இருந்து அனைத்து பாக்கெட்டுகளையும் சமமாக நடத்த முடியும். எடுத்துக்காட்டாக, குபெர்னெட்டஸ் சேவையை ஒரு பாட் அணுகும் போது, க்யூப்-ப்ராக்ஸி லோட் பேலன்சர், கிளஸ்டருக்குள் உள்ள ஒரு குறிப்பிட்ட பாட்க்கு போக்குவரத்தை வழிநடத்த NAT ஐப் பயன்படுத்துகிறது. கொடுக்கப்பட்ட இணைப்பிற்கு, IP சேவைக்கான அனைத்து பாக்கெட்டுகளும் ஒரே பாட்க்கு அனுப்பப்பட வேண்டும் என்றும், பேக்கென்ட் பாட் மூலம் திரும்பிய பாக்கெட்டுகள் கோரிக்கை வந்த பாட்க்கு மீண்டும் NAT செய்யப்பட வேண்டும் என்றும் Conntrack பதிவு செய்கிறது.
- காலிகோ போன்ற ஸ்டேட்ஃபுல் ஃபயர்வால்கள் கனெக்ட்ட்ராக் முதல் "பதிலளிப்பு" டிராஃபிக்கை அனுமதிப்பட்டியலுக்கு அனுப்பும் தகவலை நம்பியுள்ளன. பதிலளிப்பு போக்குவரத்தை வெளிப்படையாக அனுமதிக்கும் கொள்கையை எழுதாமல் "எந்தவொரு தொலைநிலை ஐபி முகவரியுடன் இணைக்க எனது பாட் அனுமதிக்கும்" என்று பிணையக் கொள்கையை எழுத இது உங்களை அனுமதிக்கிறது. (இது இல்லாமல், "எந்த ஐபியிலிருந்தும் பாக்கெட்டுகளை எனது பாட்க்கு அனுமதி" விதியை நீங்கள் மிகவும் குறைவான பாதுகாப்பைச் சேர்க்க வேண்டும்.)
கூடுதலாக, கன்ட்ராக் பொதுவாக கணினி செயல்திறனை மேம்படுத்துகிறது (CPU நுகர்வு மற்றும் பாக்கெட் தாமதத்தை குறைப்பதன் மூலம்) ஸ்ட்ரீமில் முதல் பாக்கெட் மட்டுமே.
அதை என்ன செய்ய வேண்டும் என்பதை தீர்மானிக்க முழு பிணைய அடுக்கையும் பார்க்க வேண்டும். இடுகையைப் பார்க்கவும்""இது எவ்வாறு செயல்படுகிறது என்பதற்கான உதாரணத்தைப் பார்க்கவும்.
இருப்பினும், கான்ட்ராக் அதன் வரம்புகளைக் கொண்டுள்ளது ...
அப்படியென்றால் எங்கே எல்லாம் தவறு நேர்ந்தது?
கான்ட்ராக் அட்டவணையானது கட்டமைக்கக்கூடிய அதிகபட்ச அளவைக் கொண்டுள்ளது, மேலும் அது நிரம்பினால், இணைப்புகள் பொதுவாக நிராகரிக்கப்படவோ அல்லது கைவிடப்படவோ தொடங்கும். பெரும்பாலான பயன்பாடுகளின் போக்குவரத்தைக் கையாள அட்டவணையில் போதுமான இடம் உள்ளது, மேலும் இது ஒரு பிரச்சனையாக இருக்காது. இருப்பினும், கான்ட்ராக் அட்டவணையைப் பயன்படுத்துவதை நீங்கள் கருத்தில் கொள்ள விரும்பும் சில காட்சிகள் உள்ளன:
- உங்கள் சர்வர் அதிக எண்ணிக்கையிலான ஒரே நேரத்தில் செயலில் உள்ள இணைப்புகளைக் கையாளுகிறது என்பது மிகவும் வெளிப்படையான நிகழ்வு. எடுத்துக்காட்டாக, உங்கள் கான்ட்ராக் அட்டவணை 128k உள்ளீடுகளுக்காக கட்டமைக்கப்பட்டிருந்தாலும், உங்களிடம் >128k ஒரே நேரத்தில் இணைப்புகள் இருந்தால், நீங்கள் சிக்கலில் சிக்குவீர்கள்!
- சற்று குறைவான வெளிப்படையான வழக்கு: உங்கள் சர்வர் ஒரு வினாடிக்கு அதிக எண்ணிக்கையிலான இணைப்புகளை செயல்படுத்தினால். இணைப்புகள் குறுகிய காலமாக இருந்தாலும், அவை சில காலத்திற்கு லினக்ஸால் தொடர்ந்து கண்காணிக்கப்படும் (இயல்புநிலையாக 120 வி). எடுத்துக்காட்டாக, உங்கள் கான்ட்ராக் அட்டவணை 128k உள்ளீடுகளுக்காக கட்டமைக்கப்பட்டிருந்தால், நீங்கள் ஒரு வினாடிக்கு 1100 இணைப்புகளைக் கையாள முயற்சிக்கிறீர்கள் என்றால், இணைப்புகள் மிகக் குறுகிய காலமே (128k/120s = 1092 இணைப்புகள்/வி) இருந்தாலும், அவை கான்ட்ராக் அட்டவணையின் அளவை மீறும். )
இந்த வகைகளில் பல முக்கிய வகையான பயன்பாடுகள் உள்ளன. கூடுதலாக, உங்களிடம் பல மோசமான நடிகர்கள் இருந்தால், உங்கள் சேவையகத்தின் இணைப்பு அட்டவணையை அரை-திறந்த இணைப்புகளுடன் நிரப்புவது சேவை மறுப்பு (DOS) தாக்குதலின் ஒரு பகுதியாகப் பயன்படுத்தப்படலாம். இரண்டு சந்தர்ப்பங்களிலும், கான்ட்ராக் உங்கள் கணினியில் ஒரு தடையாக இருக்கலாம். சில சந்தர்ப்பங்களில், கான்ட்ராக் அட்டவணை அளவுருக்களை சரிசெய்வது உங்கள் தேவைகளைப் பூர்த்தி செய்ய போதுமானதாக இருக்கலாம் - அளவை அதிகரிப்பதன் மூலம் அல்லது கான்ட்ராக் காலக்கெடுவைக் குறைப்பதன் மூலம் (ஆனால் நீங்கள் அதைத் தவறாகச் செய்தால், நீங்கள் நிறைய சிக்கல்களைச் சந்திக்க நேரிடும்). மற்ற சந்தர்ப்பங்களில், ஆக்கிரமிப்பு போக்குவரத்திற்கு கான்ட்ராக்கைத் தவிர்ப்பது அவசியம்.
உண்மையான உதாரணம்
ஒரு குறிப்பிட்ட உதாரணத்தைக் கொடுப்போம்: நாங்கள் பணிபுரிந்த ஒரு பெரிய SaaS வழங்குநர் ஹோஸ்ட்களில் (மெய்நிகர் இயந்திரங்கள் அல்ல) பல மெம்கேச் செய்யப்பட்ட சேவையகங்களைக் கொண்டிருந்தார், அவை ஒவ்வொன்றும் வினாடிக்கு 50K+ குறுகிய கால இணைப்புகளைச் செயல்படுத்துகின்றன.
அவர்கள் கான்ட்ராக் உள்ளமைவை பரிசோதித்தனர், அட்டவணை அளவுகளை அதிகரித்து, கண்காணிப்பு நேரத்தைக் குறைத்தனர், ஆனால் கட்டமைப்பு நம்பகத்தன்மையற்றது, ரேம் நுகர்வு கணிசமாக அதிகரித்தது, இது ஒரு பிரச்சனையாக இருந்தது (ஜிபைட்களின் வரிசையில்!), மற்றும் இணைப்புகள் மிகக் குறைவாக இருந்ததால் கான்ட்ராக் செய்யவில்லை. அதன் வழக்கமான செயல்திறன் நன்மையை உருவாக்கவும் (குறைக்கப்பட்ட நுகர்வு CPU அல்லது பாக்கெட் தாமதம்).
அவர்கள் மாற்றாக காலிகோவை நோக்கி திரும்பினர். காலிகோ நெட்வொர்க் கொள்கைகள் சில வகையான போக்குவரத்திற்கு (doNotTrack கொள்கை விருப்பத்தைப் பயன்படுத்தி) கான்ட்ராக்கைப் பயன்படுத்தாமல் இருக்க அனுமதிக்கின்றன. இது அவர்களுக்குத் தேவையான செயல்திறனின் அளவையும், மேலும் காலிகோ வழங்கிய கூடுதல் பாதுகாப்பையும் வழங்கியது.
கான்ட்ராக் பைபாஸ் செய்ய நீங்கள் எவ்வளவு தூரம் செல்ல வேண்டும்?
- கண்காணிப்பு நெட்வொர்க் கொள்கைகள் பொதுவாக சமச்சீராக இருக்க வேண்டும். SaaS வழங்குநரைப் பொறுத்தவரை: அவர்களின் பயன்பாடுகள் பாதுகாக்கப்பட்ட மண்டலத்திற்குள் இயங்கின, எனவே, பிணையக் கொள்கையைப் பயன்படுத்தி, memcached அணுக அனுமதிக்கப்பட்ட பிற குறிப்பிட்ட பயன்பாடுகளின் போக்குவரத்தை அவர்கள் அனுமதிப்பட்டியலில் சேர்க்கலாம்.
- டூ-நாட்-ட்ராக் கொள்கை இணைப்பின் திசையை கணக்கில் எடுத்துக்கொள்ளாது. எனவே, memcached சேவையகம் ஹேக் செய்யப்பட்டால், நீங்கள் கோட்பாட்டளவில் எந்த memcached கிளையண்ட்டுடனும் இணைக்க முயற்சி செய்யலாம், அது சரியான மூல போர்ட்டைப் பயன்படுத்தும் வரை. இருப்பினும், உங்கள் மெம்கேச் செய்யப்பட்ட வாடிக்கையாளர்களுக்கான நெட்வொர்க் கொள்கையை நீங்கள் சரியாக வரையறுத்திருந்தால், இந்த இணைப்பு முயற்சிகள் கிளையன்ட் பக்கத்தில் நிராகரிக்கப்படும்.
- ஒரு ஃப்ளோவில் முதல் பாக்கெட்டுக்கு மட்டுமே பயன்படுத்தப்படும் சாதாரண பாலிசிகளுக்கு மாறாக, டிராக்-நாட்-ட்ராக் கொள்கை ஒவ்வொரு பாக்கெட்டிற்கும் பயன்படுத்தப்படுகிறது. ஒவ்வொரு பாக்கெட்டிற்கும் பாலிசி பயன்படுத்தப்பட வேண்டும் என்பதால் இது ஒரு பாக்கெட்டுக்கான CPU நுகர்வு அதிகரிக்கலாம். ஆனால் குறுகிய கால இணைப்புகளுக்கு, கான்ட்ராக் செயலாக்கத்திற்கான வள நுகர்வு குறைப்பதன் மூலம் இந்த செலவு சமப்படுத்தப்படுகிறது. எடுத்துக்காட்டாக, SaaS வழங்குநரின் விஷயத்தில், ஒவ்வொரு இணைப்புக்கான பாக்கெட்டுகளின் எண்ணிக்கை மிகவும் சிறியதாக இருந்தது, எனவே ஒவ்வொரு பாக்கெட்டிற்கும் கொள்கைகளைப் பயன்படுத்தும்போது கூடுதல் CPU நுகர்வு நியாயமானது.
சோதனையைத் தொடங்குவோம்
ஒரு மெம்கேச் செய்யப்பட்ட சர்வர் மற்றும் ரிமோட் நோட்களில் இயங்கும் பல மெம்கேச் செய்யப்பட்ட கிளையன்ட் பாட்கள் மூலம் ஒரு பாட் மீது சோதனையை நடத்தினோம், இதன் மூலம் வினாடிக்கு அதிக எண்ணிக்கையிலான இணைப்புகளை இயக்க முடியும். மெம்கேச் செய்யப்பட்ட சர்வர் பாட் கொண்ட சர்வரில் 8 கோர்கள் மற்றும் கான்ட்ராக் டேபிளில் 512 கே உள்ளீடுகள் இருந்தன (ஹோஸ்டுக்கான நிலையான கட்டமைக்கப்பட்ட டேபிள் அளவு).
செயல்திறன் வேறுபாட்டை நாங்கள் அளந்தோம்: நெட்வொர்க் கொள்கை இல்லை; வழக்கமான காலிகோ கொள்கையுடன்; மற்றும் காலிகோ டூ-நாட்-ட்ராக் கொள்கை.
முதல் சோதனைக்கு, இணைப்புகளின் எண்ணிக்கையை வினாடிக்கு 4.000 ஆக அமைத்துள்ளோம், எனவே CPU நுகர்வு வித்தியாசத்தில் கவனம் செலுத்தலாம். கொள்கை மற்றும் வழக்கமான கொள்கை ஆகியவற்றுக்கு இடையே குறிப்பிடத்தக்க வேறுபாடுகள் எதுவும் இல்லை, ஆனால் CPU நுகர்வு சுமார் 20% அதிகரித்துள்ளது:
இரண்டாவது சோதனையில், எங்கள் கிளையன்ட்கள் உருவாக்கக்கூடிய பல இணைப்புகளை நாங்கள் தொடங்கினோம் மற்றும் எங்களின் மெம்கேச் செய்யப்பட்ட சர்வர் கையாளக்கூடிய ஒரு வினாடிக்கு அதிகபட்ச இணைப்புகளின் எண்ணிக்கையை அளந்தோம். எதிர்பார்த்தபடி, "நோ பாலிசி" மற்றும் "ரெகுலர் பாலிசி" ஆகிய இரண்டும் ஒரு வினாடிக்கு 4,000 இணைப்புகளுக்கு மேல் (512k / 120s = 4,369 இணைப்புகள்/வி) இணைப்பு வரம்பை எட்டியது. கண்காணிக்க வேண்டாம் என்ற கொள்கையுடன், எங்கள் வாடிக்கையாளர்கள் எந்த பிரச்சனையும் இல்லாமல் ஒரு நொடிக்கு 60,000 இணைப்புகளை அனுப்பியுள்ளனர். அதிக வாடிக்கையாளர்களைச் சேர்ப்பதன் மூலம் இந்த எண்ணிக்கையை அதிகரிக்க முடியும் என்பதில் உறுதியாக உள்ளோம், ஆனால் இந்தக் கட்டுரையின் கருத்தை விளக்குவதற்கு இந்த எண்கள் ஏற்கனவே போதுமானதாக இருப்பதாக நாங்கள் உணர்கிறோம்!
முடிவுக்கு
Conntrack ஒரு முக்கியமான கர்னல் அம்சமாகும். அவர் தனது வேலையை கச்சிதமாக செய்கிறார். இது பெரும்பாலும் முக்கிய கணினி கூறுகளால் பயன்படுத்தப்படுகிறது. இருப்பினும், சில குறிப்பிட்ட சூழ்நிலைகளில், கான்ட்ராக் காரணமாக ஏற்படும் நெரிசல் அது வழங்கும் சாதாரண நன்மைகளை விட அதிகமாக உள்ளது. இந்தச் சூழ்நிலையில், நெட்வொர்க் பாதுகாப்பை அதிகரிக்கும் அதே வேளையில் கான்ட்ராக் பயன்பாட்டைத் தேர்ந்தெடுத்து முடக்க காலிகோ நெட்வொர்க் கொள்கைகள் பயன்படுத்தப்படலாம். மற்ற எல்லா ட்ராஃபிக்கிலும், கான்ட்ராக் உங்கள் நண்பராகத் தொடர்கிறது!
எங்கள் வலைப்பதிவில் உள்ள மற்ற கட்டுரைகளையும் படிக்கவும்:
ஆதாரம்: www.habr.com