நாம் ஒரு ஒற்றைப் பயன்பாட்டிலிருந்து மைக்ரோ சர்வீஸ் கட்டமைப்பிற்கு மாறும்போது, புதிய சவால்களை எதிர்கொள்கிறோம்.
ஒரு ஒற்றைப் பயன்பாட்டில், கணினியின் எந்தப் பகுதியில் பிழை ஏற்பட்டது என்பதைத் தீர்மானிப்பது பொதுவாக மிகவும் எளிதானது. பெரும்பாலும், சிக்கல் மோனோலித்தின் குறியீட்டில் அல்லது தரவுத்தளத்தில் உள்ளது. ஆனால் மைக்ரோ சர்வீஸ் கட்டமைப்பில் ஒரு சிக்கலைத் தேடத் தொடங்கும் போது, எல்லாம் தெளிவாகத் தெரியவில்லை. தொடக்கத்திலிருந்து முடிவு வரை கோரிக்கை எடுத்த முழுப் பாதையையும் நாம் கண்டறிந்து நூற்றுக்கணக்கான மைக்ரோ சர்வீஸ்களில் இருந்து அதைத் தேர்ந்தெடுக்க வேண்டும். மேலும், அவர்களில் பலர் தங்கள் சொந்த சேமிப்பக வசதிகளையும் கொண்டுள்ளனர், இது தருக்க பிழைகள், அத்துடன் செயல்திறன் மற்றும் தவறு சகிப்புத்தன்மை ஆகியவற்றில் சிக்கல்களை ஏற்படுத்தும்.
இதுபோன்ற சிக்கல்களைச் சமாளிக்க உதவும் ஒரு கருவியை நான் நீண்ட காலமாகத் தேடிக்கொண்டிருக்கிறேன் (இதைப் பற்றி நான் ஹப்ரேயில் எழுதினேன்:
விநியோகிக்கப்பட்ட டிரேசிங் என்பது விநியோகிக்கப்பட்ட அமைப்புகளில் பிழைகளைக் கண்டறிவதற்கான பொதுவான தீர்வாகும். ஆனால் நெட்வொர்க் தொடர்புகளைப் பற்றிய தகவல்களைச் சேகரிப்பதற்கான இந்த அணுகுமுறை கணினியில் இன்னும் செயல்படுத்தப்படவில்லை, அல்லது, மோசமாக, கணினியின் ஒரு பகுதியில் இது ஏற்கனவே சரியாக வேலை செய்கிறது, ஆனால் அது பழைய சேவைகளில் சேர்க்கப்படவில்லை என்பதால், அது ஒரு பகுதியாக இல்லை. ? ஒரு பிரச்சனைக்கான சரியான மூல காரணத்தை தீர்மானிக்க, கணினியில் என்ன நடக்கிறது என்பது பற்றிய முழுமையான படத்தை வைத்திருப்பது அவசியம். முக்கிய வணிக-முக்கியமான பாதைகளில் எந்த மைக்ரோ சர்வீஸ்கள் ஈடுபட்டுள்ளன என்பதைப் புரிந்துகொள்வது மிகவும் முக்கியம்.
இங்கே சர்வீஸ் மெஷ் அணுகுமுறை எங்கள் உதவிக்கு வரலாம், இது சேவைகள் செயல்படுவதை விட குறைவான அளவில் நெட்வொர்க் தகவல்களைச் சேகரிப்பதற்கான அனைத்து இயந்திரங்களையும் கையாளும். இந்த அணுகுமுறை அனைத்து போக்குவரத்தையும் இடைமறித்து அதை பறக்கும்போது பகுப்பாய்வு செய்ய அனுமதிக்கிறது. மேலும், பயன்பாடுகள் அதைப் பற்றி எதுவும் தெரிந்து கொள்ள வேண்டியதில்லை.
சேவை கண்ணி அணுகுமுறை
சேவை மெஷ் அணுகுமுறையின் முக்கிய யோசனை நெட்வொர்க்கில் மற்றொரு உள்கட்டமைப்பு அடுக்கைச் சேர்ப்பதாகும், இது சேவைகளுக்கு இடையேயான தொடர்புடன் எதையும் செய்ய அனுமதிக்கும். பெரும்பாலான செயலாக்கங்கள் பின்வருமாறு செயல்படுகின்றன: ஒவ்வொரு மைக்ரோ சர்வீஸிலும் ஒரு வெளிப்படையான ப்ராக்ஸியுடன் கூடிய கூடுதல் சைட்கார் கொள்கலன் சேர்க்கப்படுகிறது, இதன் மூலம் சேவையின் அனைத்து உள்வரும் மற்றும் வெளிச்செல்லும் போக்குவரத்து அனுப்பப்படுகிறது. வாடிக்கையாளர் சமநிலைப்படுத்துதல், பாதுகாப்புக் கொள்கைகளைப் பயன்படுத்துதல், கோரிக்கைகளின் எண்ணிக்கையில் கட்டுப்பாடுகளை விதித்தல் மற்றும் உற்பத்தியில் சேவைகளின் தொடர்பு பற்றிய முக்கியமான தகவல்களைச் சேகரிக்கும் இடம் இதுவாகும்.
தீர்வுகளை
இந்த அணுகுமுறையில் ஏற்கனவே பல செயலாக்கங்கள் உள்ளன:
இதன் விளைவாக, இப்போது நமக்குத் தேவையான திறன்களைப் பற்றி நாங்கள் சரியாகப் பார்த்தோம், மேலும் இதுபோன்ற தீர்வுகளை நாங்கள் செயல்படுத்தத் தொடங்கியதற்கான முக்கிய காரணம் முழு அமைப்பிலிருந்தும் டிரேசிங் தகவல்களை வெளிப்படையாகச் சேகரிக்கும் திறன் என்று முடிவு செய்தோம். சேவைகளின் தொடர்புகளின் மீது கட்டுப்பாட்டைக் கொண்டிருக்கவும், சேவைகளுக்கு இடையே மாற்றப்படும் தலைப்புகளில் பல்வேறு கையாளுதல்களைச் செய்யவும் நாங்கள் விரும்புகிறோம்.
இதன் விளைவாக, நாங்கள் எங்கள் முடிவுக்கு வந்தோம்:
நேத்ரமேஷ்
புதிய தீர்வின் முக்கிய குறிக்கோள்கள் குறைந்த வள மேல்நிலை மற்றும் உயர் செயல்திறன் ஆகும். முக்கிய அம்சங்களில், எங்கள் ஜெகர் அமைப்புக்கு ட்ரேசிங் ஸ்பான்களை வெளிப்படையாக அனுப்ப நாங்கள் உடனடியாக விரும்பினோம்.
இன்று, பெரும்பாலான கிளவுட் தீர்வுகள் கோலாங்கில் செயல்படுத்தப்படுகின்றன. மற்றும், நிச்சயமாக, இதற்கு காரணங்கள் உள்ளன. கோலாங்கில் நெட்வொர்க் பயன்பாடுகளை எழுதுவது I/O உடன் ஒத்திசைவின்றி வேலை செய்கிறது மற்றும் தேவைக்கேற்ப கோர்கள் முழுவதும் அளவிடுவது வசதியானது மற்றும் மிகவும் எளிமையானது. மேலும், மிகவும் முக்கியமானது என்னவென்றால், இந்த சிக்கலை தீர்க்க செயல்திறன் போதுமானது. அதனால்தான் நாங்களும் கோலாங்கைத் தேர்ந்தெடுத்தோம்.
உற்பத்தித்
அதிகபட்ச உற்பத்தித்திறனை அடைவதில் எங்கள் முயற்சிகளை நாங்கள் கவனம் செலுத்தியுள்ளோம். சேவையின் ஒவ்வொரு நிகழ்விற்கும் அடுத்ததாக பயன்படுத்தப்படும் தீர்வுக்கு, RAM மற்றும் CPU நேரத்தின் சிறிய நுகர்வு தேவைப்படுகிறது. மற்றும், நிச்சயமாக, பதில் தாமதம் சிறியதாக இருக்க வேண்டும்.
என்ன முடிவு கிடைத்தது என்று பார்ப்போம்.
ரேம்
Netramesh ~10Mb ட்ராஃபிக் இல்லாமல் பயன்படுத்துகிறது மற்றும் 50Mb அதிகபட்சமாக ஒரு நிகழ்வுக்கு 10000 RPS வரை ஏற்றுகிறது.
Istio தூதர் ப்ராக்ஸி எப்போதும் ஆயிரக்கணக்கான நிகழ்வுகளுடன் எங்கள் கிளஸ்டர்களில் ~300Mb பயன்படுத்துகிறது. இது முழு கிளஸ்டருக்கும் அளவிட அனுமதிக்காது.
Netramesh மூலம் நினைவக நுகர்வில் ~10x குறைப்பு கிடைத்தது.
சிபியு
CPU பயன்பாடு சுமையின் கீழ் ஒப்பீட்டளவில் சமமாக உள்ளது. இது சைட்காருக்கான ஒரு யூனிட் நேரத்திற்கான கோரிக்கைகளின் எண்ணிக்கையைப் பொறுத்தது. உச்சநிலையில் வினாடிக்கு 3000 கோரிக்கைகளில் மதிப்புகள்:
இன்னும் ஒரு முக்கியமான விஷயம் உள்ளது: Netramesh - ஒரு கட்டுப்பாட்டு விமானம் இல்லாமல் மற்றும் சுமை இல்லாமல் ஒரு தீர்வு CPU நேரத்தை எடுத்துக்கொள்ளாது. இஸ்டியோவுடன், சைட்கார்கள் எப்போதும் சேவை முடிவுப் புள்ளிகளைப் புதுப்பிக்கும். இதன் விளைவாக, இந்த படத்தை சுமை இல்லாமல் பார்க்கலாம்:
சேவைகளுக்கு இடையேயான தொடர்புக்கு HTTP/1ஐப் பயன்படுத்துகிறோம். தூதர் மூலம் ப்ராக்ஸி செய்யும் போது இஸ்டியோவின் மறுமொழி நேரம் 5-10ms வரை அதிகரித்தது, இது ஒரு மில்லி வினாடியில் பதிலளிக்கத் தயாராக இருக்கும் சேவைகளுக்கு மிகவும் அதிகம். Netramesh உடன் இந்த நேரம் 0.5-2ms ஆக குறைந்துள்ளது.
அளவீடல்
ஒவ்வொரு ப்ராக்ஸியும் நுகரும் சிறிய அளவிலான வளங்கள் ஒவ்வொரு சேவைக்கும் அடுத்ததாக அதை வைக்க உதவுகிறது. நேத்ரமேஷ் வேண்டுமென்றே ஒவ்வொரு சைட்காரையும் இலகுவாக வைத்திருக்க ஒரு கட்டுப்பாட்டு விமான கூறு இல்லாமல் உருவாக்கப்பட்டது. பெரும்பாலும் சர்வீஸ் மெஷ் தீர்வுகளில், கட்டுப்பாட்டு விமானம் ஒவ்வொரு பக்க காருக்கும் சேவை கண்டுபிடிப்பு தகவலை விநியோகிக்கிறது. அதனுடன் காலக்கெடு மற்றும் சமநிலை அமைப்புகள் பற்றிய தகவலும் வருகிறது. இவை அனைத்தும் நிறைய பயனுள்ள விஷயங்களைச் செய்ய உங்களை அனுமதிக்கிறது, ஆனால், துரதிர்ஷ்டவசமாக, இது சைட்கார்களின் அளவைக் குறைக்கிறது.
சேவை கண்டுபிடிப்பு
நேத்ரமேஷ் சேவை கண்டுபிடிப்புக்கான கூடுதல் வழிமுறைகள் எதையும் சேர்க்கவில்லை. அனைத்து போக்குவரத்தும் நேத்ரா சைட்கார் மூலம் வெளிப்படையானது.
Netramesh HTTP/1 பயன்பாட்டு நெறிமுறையை ஆதரிக்கிறது. அதை வரையறுக்க, போர்ட்களின் கட்டமைக்கக்கூடிய பட்டியல் பயன்படுத்தப்படுகிறது. பொதுவாக, கணினியில் HTTP தொடர்பு ஏற்படும் பல துறைமுகங்கள் உள்ளன. எடுத்துக்காட்டாக, சேவைகள் மற்றும் வெளிப்புற கோரிக்கைகளுக்கு இடையிலான தொடர்புக்கு 80, 8890, 8080 ஐப் பயன்படுத்துகிறோம். இந்த விஷயத்தில், சூழல் மாறியைப் பயன்படுத்தி அவற்றை அமைக்கலாம். NETRA_HTTP_PORTS
.
நீங்கள் குபெர்னெட்ஸை ஒரு ஆர்கெஸ்ட்ரேட்டராகப் பயன்படுத்தினால் மற்றும் சேவைகளுக்கு இடையே உள்ள கிளஸ்டர் தகவல்தொடர்புக்கான அதன் சேவை நிறுவன பொறிமுறையை நீங்கள் பயன்படுத்தினால், அதன் வழிமுறை அப்படியே இருக்கும். முதலில், மைக்ரோ சர்வீஸ் kube-dns ஐப் பயன்படுத்தி ஒரு சேவை IP முகவரியைப் பெற்று, அதனுடன் ஒரு புதிய இணைப்பைத் திறக்கிறது. இந்த இணைப்பு முதலில் உள்ளூர் நெட்ரா-சைட்காருடன் நிறுவப்பட்டது மற்றும் அனைத்து TCP பாக்கெட்டுகளும் ஆரம்பத்தில் நேத்ராவை வந்தடையும். அடுத்து, நெட்ரா-சைட்கார் அசல் இலக்குடன் ஒரு தொடர்பை ஏற்படுத்துகிறது. முனையில் உள்ள பாட் ஐபியில் உள்ள NAT, நேத்ரா இல்லாமல் அப்படியே உள்ளது.
விநியோகிக்கப்பட்ட டிரேசிங் மற்றும் சூழல் பகிர்தல்
HTTP இடைவினைகள் பற்றி ட்ரேசிங் ஸ்பான்களை அனுப்ப தேவையான செயல்பாட்டை Netramesh வழங்குகிறது. Netra-sidecar HTTP நெறிமுறையை அலசுகிறது, கோரிக்கை தாமதங்களை அளவிடுகிறது மற்றும் HTTP தலைப்புகளில் இருந்து தேவையான தகவலைப் பிரித்தெடுக்கிறது. இறுதியில், ஒரே ஜெகர் அமைப்பில் அனைத்து தடயங்களையும் பெறுகிறோம். நுணுக்கமான உள்ளமைவுக்கு, அதிகாரப்பூர்வ நூலகத்தால் வழங்கப்படும் சூழல் மாறிகளையும் நீங்கள் பயன்படுத்தலாம்.
ஆனால் ஒரு பிரச்சனை இருக்கிறது. சேவைகள் ஒரு சிறப்பு uber தலைப்பை உருவாக்கி அனுப்பும் வரை, கணினியில் இணைக்கப்பட்ட ட்ரேசிங் ஸ்பான்களைப் பார்க்க மாட்டோம். மேலும், பிரச்சனைகளுக்கான காரணத்தை நாம் விரைவாகக் கண்டறிய வேண்டியது இதுதான். இங்கே மீண்டும் நேத்ரமேஷுக்கு ஒரு தீர்வு இருக்கிறது. ப்ராக்ஸிகள் HTTP தலைப்புகளைப் படித்து, அவற்றில் uber ட்ரேஸ் ஐடி இல்லை என்றால், ஒன்றை உருவாக்கவும். நேத்ரமேஷ் உள்வரும் மற்றும் வெளிச்செல்லும் கோரிக்கைகள் பற்றிய தகவல்களை ஒரு பக்க காரில் சேமித்து, தேவையான வெளிச்செல்லும் கோரிக்கை தலைப்புகளுடன் அவற்றைச் செறிவூட்டுவதன் மூலம் அவற்றைப் பொருத்துகிறார். சேவைகளில் நீங்கள் செய்ய வேண்டியது ஒரு தலைப்பை மட்டும் அனுப்புவதுதான் X-Request-Id
, இது சூழல் மாறியைப் பயன்படுத்தி கட்டமைக்கப்படலாம் NETRA_HTTP_REQUEST_ID_HEADER_NAME
. Netramesh இல் சூழலின் அளவைக் கட்டுப்படுத்த, பின்வரும் சூழல் மாறிகளை அமைக்கலாம்: NETRA_TRACING_CONTEXT_EXPIRATION_MILLISECONDS
(சூழல் சேமிக்கப்படும் நேரம்) மற்றும் NETRA_TRACING_CONTEXT_CLEANUP_INTERVAL
(சூழல் சுத்தம் செய்யும் அதிர்வெண்).
சிறப்பு அமர்வு டோக்கனைக் குறிப்பதன் மூலம் உங்கள் கணினியில் பல பாதைகளை இணைக்கவும் முடியும். Netra நீங்கள் நிறுவ அனுமதிக்கிறது HTTP_HEADER_TAG_MAP
HTTP தலைப்புகளை தொடர்புடைய டிரேசிங் ஸ்பான் குறிச்சொற்களாக மாற்ற. இது சோதனைக்கு மிகவும் பயனுள்ளதாக இருக்கும். செயல்பாட்டு சோதனையில் தேர்ச்சி பெற்ற பிறகு, தொடர்புடைய அமர்வு விசையால் வடிகட்டுவதன் மூலம் கணினியின் எந்தப் பகுதி பாதிக்கப்பட்டது என்பதை நீங்கள் பார்க்கலாம்.
கோரிக்கை மூலத்தைத் தீர்மானித்தல்
கோரிக்கை எங்கிருந்து வந்தது என்பதைத் தீர்மானிக்க, மூலத்துடன் ஒரு தலைப்பைத் தானாகச் சேர்க்கும் செயல்பாட்டைப் பயன்படுத்தலாம். சூழல் மாறியைப் பயன்படுத்துதல் NETRA_HTTP_X_SOURCE_HEADER_NAME
தானாக நிறுவப்படும் தலைப்பு பெயரை நீங்கள் குறிப்பிடலாம். பயன்படுத்தி NETRA_HTTP_X_SOURCE_VALUE
வெளிச்செல்லும் அனைத்து கோரிக்கைகளுக்கும் X-மூல தலைப்பு அமைக்கப்படும் மதிப்பை நீங்கள் அமைக்கலாம்.
இது இந்த பயனுள்ள தலைப்பின் விநியோகத்தை நெட்வொர்க் முழுவதும் ஒரே சீராக விநியோகிக்க அனுமதிக்கிறது. நீங்கள் அதை சேவைகளில் பயன்படுத்தலாம் மற்றும் பதிவுகள் மற்றும் அளவீடுகளில் சேர்க்கலாம்.
ட்ராஃபிக் ரூட்டிங் மற்றும் நேத்ரமேஷ் இன்டர்னல்கள்
Netramesh இரண்டு முக்கிய கூறுகளைக் கொண்டுள்ளது. முதல், netra-init, போக்குவரத்தை இடைமறிக்க நெட்வொர்க் விதிகளை அமைக்கிறது. அவர் பயன்படுத்துகிறார் INBOUND_INTERCEPT_PORTS, OUTBOUND_INTERCEPT_PORTS
.
கருவி ஒரு சுவாரஸ்யமான அம்சத்தையும் கொண்டுள்ளது - நிகழ்தகவு ரூட்டிங். ட்ரேசிங் ஸ்பான்களை சேகரிப்பதற்காக நீங்கள் பிரத்தியேகமாக Netramesh ஐப் பயன்படுத்தினால், உற்பத்திச் சூழலில் நீங்கள் வளங்களைச் சேமிக்கலாம் மற்றும் மாறிகளைப் பயன்படுத்தி நிகழ்தகவு வழியை இயக்கலாம். NETRA_INBOUND_PROBABILITY
и NETRA_OUTBOUND_PROBABILITY
(0 முதல் 1 வரை). இயல்புநிலை மதிப்பு 1 (அனைத்து போக்குவரத்தும் இடைமறிக்கப்பட்டது).
வெற்றிகரமான இடைமறிப்புக்குப் பிறகு, நேத்ரா சைட்கார் புதிய இணைப்பை ஏற்றுக்கொண்டு பயன்படுத்துகிறது SO_ORIGINAL_DST
அசல் இலக்கைப் பெற சாக்கெட் விருப்பம். நேத்ரா பின்னர் அசல் IP முகவரிக்கு ஒரு புதிய இணைப்பைத் திறந்து, கட்சிகளுக்கு இடையே இருவழி TCP தொடர்பை நிறுவுகிறது, கடந்து செல்லும் அனைத்து போக்குவரத்தையும் கேட்கிறது. போர்ட் HTTP என வரையறுக்கப்பட்டால், நேத்ரா அதை அலசவும் கண்டுபிடிக்கவும் முயற்சிக்கிறது. HTTP பாகுபடுத்தல் தோல்வியுற்றால், நேத்ரா மீண்டும் TCP க்கு வந்து பைட்டுகளை வெளிப்படையாக ப்ராக்ஸி செய்கிறது.
சார்பு வரைபடத்தை உருவாக்குதல்
ஜெகரில் அதிக அளவு டிரேசிங் தகவலைப் பெற்ற பிறகு, கணினியில் உள்ள தொடர்புகளின் முழுமையான வரைபடத்தைப் பெற விரும்புகிறேன். ஆனால் உங்கள் சிஸ்டம் மிகவும் ஏற்றப்பட்டு, ஒரு நாளைக்கு பில்லியன் கணக்கான டிரேசிங் ஸ்பான்கள் குவிந்தால், அவற்றை ஒருங்கிணைப்பது அவ்வளவு எளிதான காரியமாக இருக்காது. இதைச் செய்ய அதிகாரப்பூர்வ வழி உள்ளது:
ட்ரேசிங் ஸ்பான்களைச் சேமிக்க நீங்கள் எலாஸ்டிக் தேடலைப் பயன்படுத்துகிறீர்கள் என்றால், நீங்கள் பயன்படுத்தலாம்
Netramesh ஐ எவ்வாறு பயன்படுத்துவது
எந்த ஆர்கெஸ்ட்ரேட்டரை இயக்கும் எந்த சேவையிலும் நேத்ராவை எளிதாக சேர்க்க முடியும். நீங்கள் ஒரு உதாரணத்தைக் காணலாம்
இந்த நேரத்தில், சேவைகளுக்கு பக்கவாட்டு கார்களை தானாக செயல்படுத்தும் திறன் நேத்ராவிடம் இல்லை, ஆனால் செயல்படுத்துவதற்கான திட்டங்கள் உள்ளன.
நேத்ரமேஷின் எதிர்காலம்
முக்கிய இலக்கு
எதிர்காலத்தில், HTTP தவிர மற்ற பயன்பாட்டு அடுக்கு நெறிமுறைகளை Netramesh ஆதரிக்கும். L7 ரூட்டிங் எதிர்காலத்தில் கிடைக்கும்.
இதே போன்ற பிரச்சனைகளை நீங்கள் சந்தித்தால் Netramesh ஐப் பயன்படுத்தவும் மற்றும் கேள்விகள் மற்றும் பரிந்துரைகளுடன் எங்களுக்கு எழுதவும்.
ஆதாரம்: www.habr.com