Roblox கிளவுடில் நெட்வொர்க் பாக்கெட் இழப்பு மற்றும் தாமதக் கண்காணிப்பு

ராப்ளாக்ஸ் நெட்வொர்க் இன்ஜினியரிங் குழு, உலகம் முழுவதும் பரவியுள்ள தரவு மையம் மற்றும் பாயிண்ட் ஆஃப் பிரசென்ஸ் (POP) தளங்களுடன் ஒரு பெரிய, வேகமாக வளர்ந்து வரும் நெட்வொர்க்கைப் பராமரிக்கிறது. ராப்ளாக்ஸ் தளத்தில் ஒரு சிறந்த பயனர் அனுபவத்தை வழங்குவது இந்த நெட்வொர்க்கின் செயல்திறன் மற்றும் நம்பகத்தன்மையைச் சார்ந்துள்ளது. நெட்வொர்க் ஆபரேட்டர்கள் நெட்வொர்க்கில் உள்ள சிக்கல்களைத் தீர்க்கவும் கண்டறியவும், மற்றும் நெட்வொர்க் செயல்திறனைக் கண்காணிக்கவும் முடிவது மிகவும் முக்கியமானது. வலைப்பின்னல் கண்காணிப்பு என்பது பொதுவாக சாதன புள்ளிவிவரங்கள், பிழை அளவீடுகள் மற்றும் சிஸ்லாக்ஸை (syslogs) அவ்வப்போது சேகரித்து, அவற்றை ஒரு காலத் தொடர் அல்லது பதிவுத் தரவுத்தளத்தில் சேமிப்பதன் மூலம் அடையப்படுகிறது. இந்தத் தரவுகள் SNMP, நெட்கான்ஃப், ரெஸ்ட் ஏபிஐ-கள் அல்லது ஸ்ட்ரீமிங் டெலிமெட்ரி போன்ற நிலையான நெறிமுறைகளைப் பயன்படுத்தி, புஷ் அல்லது புல் மாதிரி மூலம் சேகரிக்கப்படுகின்றன.

கேட்ஜெட் டெலிமெட்ரி மூலம் மட்டுமே நெட்வொர்க் கோளாறு கண்டறிதலில் பல குறைபாடுகள் உள்ளன, ஏனெனில் இது ஒரு செயலற்ற கண்காணிப்பு நுட்பமாகும். இது, நெட்வொர்க் முனைகள் (nodes) அசாதாரணமான சூழ்நிலைகள் ஏற்பட்டவுடன் அவற்றை அடையாளம் கண்டு தெரிவிக்கும் திறனைச் சார்ந்துள்ளது. கேட்ஜெட் எப்போதும் தரவைத் திரும்பத் தெரிவிக்காமல் இருக்கலாம் அல்லது சில சந்தர்ப்பங்களில், அதன் அனைத்து சுகாதார புள்ளிவிவரங்களும் வழக்கமான டெலிமெட்ரி சேகரிப்பு முறைகளுக்கு வெளிப்படுத்தப்படாமல் இருக்கலாம். கூடுதலாக, நெட்வொர்க் கேட்ஜெட்டுகள் சில நேரங்களில் தவறான தரவை வழங்கலாம் அல்லது மௌனமாக டிராஃபிக்கை பிளாக்-ஹோல் செய்யலாம். சாதன டெலிமெட்ரியின் ஒரு முக்கிய வரம்பு என்னவென்றால், அது நெட்வொர்க்கின் எண்ட்-டு-எண்ட் சென்றடைதல், பாக்கெட் விடுதல் மற்றும் தாமத புள்ளிவிவரங்கள் ஆகியவற்றைப் பற்றி மிகக் குறைந்த பார்வையையே வழங்குகிறது.

கீழே உள்ள படங்களில் காட்டப்பட்டுள்ளபடி, ஒரு மெஷ் முழுவதும் தொகுக்கப்பட்ட ப்ராப்களை (probes) தவறாமல் அனுப்புவது, ஒரு நெட்வொர்க்கைத் தீவிரமாகக் கண்காணிக்க ஒரு சிறந்த வழியாகும்.

உற்பத்தி நிறுத்தங்களுக்கான பிழைதிருத்தத்தின் போது, நெட்வொர்க் ஆபரேட்டர்களிடம், "நெட்வொர்க் பேக்கேட்களைத் தவறவிடுகிறதா?" அல்லது "சேவை இணைப்பைப் பாதிக்கும் ஏதேனும் நெட்வொர்க் கோளாறு நீடிக்கிறதா?" போன்ற கேள்விகள் அடிக்கடி கேட்கப்படுகின்றன. வரலாற்று பேக்கேட் இழப்பு மற்றும் தாமதத் தரவுகளுக்கான அணுகல் இல்லாமல் இந்த வகையான கேள்விக்கு பதிலளிக்க, அவர்கள் நெட்வொர்க்கில் உள்ள ஒரு பெரிய அளவிலான இணைப்புகள் மற்றும் முனைகளை ஆராய வேண்டியிருக்கும்.

நம்பகமான மற்றும் அளவிடக்கூடிய நெட்வொர்க் மெஷ் கண்காணிப்பு அமைப்பை வடிவமைத்தல்

பேக்கெட் இழப்பு அல்லது தாமத உச்சங்களைக் கண்டறிவதில் ஒரு பிளாக் பாக்ஸ் நெட்வொர்க் கண்காணிப்பு அமைப்பு பயனுள்ளதாக இருக்க, அது நெட்வொர்க்கின் வெவ்வேறு பகுதிகளில் தொடர்ச்சியான சோதனைகளை மேற்கொள்ள வேண்டும். தரவு மைய நெட்வொர்க்குகள் பயனர் போக்குவரத்திற்காக நோட்களுக்கு இடையேயான அனைத்து இணைப்புகளையும் பயன்படுத்துகின்றன. உற்பத்தி நெட்வொர்க் சாதனங்கள் BGP-ஐ இயக்கி, பல சம-செலவு பாதைகளில் போக்குவரத்தை சுமை சமநிலைப்படுத்துகின்றன. நெட்வொர்க் அமைவியலில் ஏற்படும் மாற்றங்கள் சாதாரண சூழ்நிலைகளில் வழித்தட அட்டவணைப் புதுப்பிப்புகள் மூலம் பொதுவாக வினாடிகளுக்குள் பிரதிபலிக்கப்படுகின்றன. இணைய பாக்கெட் இழப்பைத் துல்லியமாக அளவிட, சோதனைச் துடுப்புகள் (test probes) அனைத்து இணையதள முனைகளையும் இணைப்புகளையும் உள்ளடக்கி, முடிந்தவரை பல பாதைகளில் பயணிக்க வேண்டும். உலகம் முழுவதும் பல தளங்களில் பரவியுள்ள எங்கள் பெரிய வலையமைப்பைப் போல, ஒவ்வொரு ஜோடி முனைகள் அல்லது ரேக்குகளுக்கு இடையில் சோதனை செய்வது விரிவாக்கக்கூடியதாக (scalable) இருக்காது. பார்வைத் தன்மையின் (visibility) தரத்தில் சமரசம் செய்யாத, நாங்கள் தேர்ந்தெடுத்த நீடித்த தீர்வு என்னவென்றால், ஒவ்வொரு தளத்திலும் உள்ள ரேக்குகளுக்கு இடையில் N² மெஷ் ஒன்றையும், அனைத்து தளங்களிலும் N² மெஷ் ஒன்றையும் சோதனை செய்வதாகும்.

நெட்வொர்க்கை நாம் எதனால் சோதிக்கிறோம்?

சோதனை ஊடுருவிகள் உற்பத்தி நெட்வொர்க்கில் செல்லும் நேரடி டிராஃபிக்கைப் போலவே செயல்பட வேண்டும். எங்கள் நெட்வொர்க்கில் உள்ள பெரும்பாலான டிராஃபிக் TCP, UDP அல்லது HTTP வகையைச் சேர்ந்தது, மேலும் இவற்றில் ஒவ்வொன்றையும் ஊடுருவல்களுக்குப் பயன்படுத்தலாம். TCP ஊடுருவலில் உள்ள ஒரு சிக்கல் என்னவென்றால், ஒரு பெரிய நெட்வொர்க்கைக் கண்காணிக்கத் தேவையான இணைப்புகளின் எண்ணிக்கைக்கு ஏற்ப அளவிட, இது போதுமான அளவு இலகுவானதாக இல்லை. TCP-இல் உள்ள மற்றொரு சிக்கல் என்னவென்றால், அதன் உள்ளமைக்கப்பட்ட ஓட்டக் கட்டுப்பாடு மற்றும் சறுக்கு ஜன்னல் அடிப்படையிலான பரிமாற்றங்கள், ஒரு கணக்கெடுப்பு அனுப்பும் விகிதத்தை மாறுபடச் செய்கின்றன. இது தற்காலிக பாக்கெட் துண்டிப்புகளை அளவிடுவதற்கோ அல்லது கண்டறிவதற்கோ ஏற்றதல்ல. பிங் மற்றும் டிரேசரூட் ஆகியவற்றால் பயன்படுத்தப்படும் ICMP, பொதுவாக சேவையகங்கள் அல்லது நெட்வொர்க் முனைகளில் விகித-வரம்புக்குட்பட்டது. இது பயன்படுத்தக்கூடிய ICMP கணக்கெடுப்புகளின் மொத்த விகிதத்தை வரம்புகிறது. HTTP கோரிக்கைகள் பயன்பாட்டு அடுக்கில் (application layer) உயர் நிலையில் உள்ளன, மேலும் அவை சர்வர் அல்லது பயன்பாட்டு செயல்திறன் போன்ற வலையமைப்புக்கு வெளியே உள்ள சில காரணிகளைச் சார்ந்துள்ளன. HTTP, முடிவுகளில் ஒரு கூடுதல் மாறியைச் சேர்க்கிறது, அதைத் தனிமைப்படுத்துவது கடினம். OSI அடுக்குகள் 4 மற்றும் அதற்குக் கீழே முதன்மையாகச் செயல்படும் அடிப்படை வலையமைப்பு உள்கட்டமைப்பின் செயல்திறனைக் கண்காணிப்பதே இந்த அமைப்பின் நோக்கமாகும். இந்தக் காரணங்களுக்காகவும், எங்கள் வலையமைப்பில் இது முதன்மைப் போக்குவரத்து அடுக்கு நெறிமுறையாக (transport layer protocol) இருப்பதாலும் நாங்கள் UDP ப்ராப்களைத் தேர்ந்தெடுத்தோம்.

நாம் எங்கிருந்து ப்ரோப் செய்கிறோம்?

ஒரு பெரிய மொத்த ப்ரோப் விகிதத்தை அடைவதற்கும், அதிக எண்ணிக்கையிலான நெட்வொர்க் பாதைகளை உள்ளடக்குவதற்கும் ஒரு வழி, ப்ரோப்களை அனுப்ப முடிந்தவரை பல கணக்கீட்டு முனைகளைப் பயன்படுத்துவதாகும். இதற்கு இரண்டு நன்மைகள் உள்ளன: இது ப்ரோப்களை உருவாக்கும் அமைப்புகளில் சுமையைப் பகிர உதவுகிறது, மேலும் அவற்றைக் கொண்டு செல்லும் நெட்வொர்க் போர்ட்களின் எண்ணிக்கையை விரிவுபடுத்துகிறது. இருப்பினும், இதற்கு மிகவும் நிலையான மற்றும் ஹோஸ்ட் அமைப்பின் வளங்களில் முடிந்தவரை மெல்லியதாக இருக்கும் ஒரு ஏஜென்ட் தேவைப்படுகிறது. அதே நேரத்தில், ஹோஸ்ட் கணினியில் உள்ள CPU, நினைவகம் அல்லது I/O பயன்பாட்டு ஏற்ற இறக்கங்களால் பாதிக்கப்படாமல், பல பாதைகளில் பாக்கெட் இழப்பு மற்றும் தாமதத்தை துல்லியமாக அளவிடக்கூடியதாக ஏஜென்ட் இருக்க வேண்டும். ஏஜென்ட், இலகுவாகவும் மற்றும் உயர் செயல்திறன் கொண்டதாகவும் இருப்பதற்கான இந்த நுட்பமான சமநிலையை தொடர்ந்து பேண வேண்டும்.

இணைய இழப்பு மற்றும் தாமதத்தை நாம் எவ்வாறு அளவிடுவது?

இது ஒரே ஆய்வுகளின் (probes) ஓட்டத்தில் ஒரு அற்பமான கணக்கீடாகத் தோன்றலாம், இருப்பினும், பெரிய அளவில் செயல்படும்போது உடனடியாகத் தெரியாத சில சவால்கள் எழுகின்றன. இத்தகைய பெரிய வலையமைப்பை விரிவாக்க, ஏஜென்ட் ஒரே நேரத்தில் பல ஓட்டங்களில் நேர முத்திரைகளுடன் (timestamps) வேகமான மற்றும் துல்லியமான அனுப்புதல் (Tx) மற்றும் பெறுதல் (Rx) பாக்கெட் எண்ணிக்கையைக் கணக்கிட வேண்டும். ஏஜென்ட்டை இயக்கும் ஹோஸ்ட்டின் சிபியு (CPU) வேலையாக இருக்கும்போது அல்லது அதன் நெட்வொர்க் பஃப்பர்கள் நிரம்பி வழியும் போது இழக்கப்பட்ட பேக்கேஜ்களை நெட்வொர்க் இழப்பு அளவீடுகள் சேர்க்காமல் இருப்பது முக்கியம். நெட்வொர்க் தாமதத்தை, ப்ராப்கள் வயர் அல்லது இடைநிலை நெட்வொர்க் முனைகளில் இருந்த மொத்த நேரத்தைக் கொண்டு கணக்கிட வேண்டும், அதே நேரத்தில் I/O பஃப்பர்களில் காத்திருந்த நேரம் மற்றும் ஏஜென்ட் செயல்முறை OS திட்டமிடலுக்காகக் காத்திருந்த நேரத்தை இதில் சேர்க்காமல் தவிர்க்க வேண்டும்.

Roblox-இன் பிங் மெஷ் அமைப்பு

பொது மற்றும் தனியார் கிளவுட் உள்கட்டமைப்பின் வளர்ச்சியிலிருந்து, பிளாக் பாக்ஸ் நெட்வொர்க் இழப்பு மற்றும் தாமதத்தைக் கண்காணிப்பதற்கான தேவை இருந்து வருகிறது. எங்கள் பெரிய நெட்வொர்க்கிற்கு ஏற்ப அளவிடக்கூடிய, உடனடியாகப் பயன்படுத்தக்கூடிய ஒரு தீர்வைக் கண்டுபிடிப்பது கடினமாக உள்ளது. பல பெரிய கிளவுட் ஆபரேட்டர்கள் மற்றும் நெட்வொர்க் கருவி வழங்குநர்கள், நெட்வொர்க் இழப்பு மற்றும் தாமதத்தைக் கண்காணிக்க தங்களின் சொந்த தீர்வுகளை வடிவமைத்துள்ளனர். நாங்கள் பொதுவில் கிடைக்கும் சில கருவிகளை முயற்சித்தோம், ஆனால் நெட்வொர்க் செயல்திறனில் வரையறுக்கப்பட்ட பார்வையை மட்டுமே பெறும் அதே வேளையில், நிலைத்தன்மை மற்றும் அளவிடுதலில் சிக்கல்களைச் சந்தித்தோம். இது, குறைந்த மேலாண்மைச் சுமையுடன் குறைந்த அதிர்வெண் பிழைகளைச் சிறப்பாகக் கண்டறிய உதவும் எங்கள் சொந்த மெஷ் கண்காணிப்பு அமைப்பை உருவாக்க வழிவகுத்தது. எங்கள் அமைப்பின் சில சிறப்பம்சங்கள்:

• எங்கள் அமைப்பின் அனைத்து கூறுகளையும் செயல்படுத்த Go-ஐத் தேர்ந்தெடுத்தோம், மேலும் அது குறைந்தபட்ச அமைப்பு வளங்களைப் பயன்படுத்தும் அதே வேளையில் உயர் செயல்திறனை அடைய உதவியது.
• எங்கள் ஏஜென்ட்கள் மிகவும் நிலையானவை மற்றும் டிராஃபிக், கேச்சிங், மற்றும் அப்ளிகேஷன் சர்வர்கள் போன்ற Roblox தளத்தில் முக்கியமான சேவைகளைச் செய்யும் ஹோஸ்ட்கள் உட்பட, பரந்த அளவிலான உற்பத்தி ஹோஸ்ட்களில் இயங்கக்கூடியவை.
• லினக்ஸ் sendmmsg() மற்றும் recvmmsg() சிஸ்டம் அழைப்புகளின் மீது Go ராப்பர் செயல்பாடுகளைப் பயன்படுத்தி பேக்கேட் I/O செயல்பாடுகளைத் தொகுப்பாகச் செய்ய இந்த ஏஜென்ட் உகந்ததாக்கப்பட்டுள்ளது, இது குறைந்த மேலாண்மைச் செலவில் அதிக எண்ணிக்கையிலான ப்ரோப்களை அனுப்ப உதவுகிறது. எங்கள் வரிசைப்படுத்தலில் உள்ள ஒவ்வொரு ஏஜென்ட்டும் ஒரே நேரத்தில் 100 பிற ஹோஸ்ட்களுக்கு, வினாடிக்கு 100 பேக்கேட்டுகள் (PPS) என்ற விகிதத்தில் ப்ரோப்களை அனுப்புகிறது. ஏஜென்ட் ஒவ்வொரு வினாடியும் ஒவ்வொரு சேருமிடத்திற்கும் பேக்கேட் பர்ஸ்ட்களை அனுப்புகிறது.
• புரோப்கள் ஒவ்வொரு இலக்கிற்கும் IP ஹெட்டரில் வெவ்வேறு சேவை வகை (TOS) புல மதிப்புகளைக் கொண்டு செல்கின்றன, மேலும் நெட்வொர்க்கில் ஏற்படும் பாக்கெட் இழப்பு மற்றும் தாமதத்திற்காக அவை தனித்தனியாகக் கணக்கிடப்படுகின்றன. ஒவ்வொரு பாக்கெட் பர்ஸ்ட்டிலும் மற்ற எல்லா இலக்குகளுக்கும் பல TOS மதிப்புகளின் கலவை அடங்கும். இது வெவ்வேறு சேவைத் தரம் (QoS) வகுப்புகளுக்கான நெட்வொர்க் செயல்திறனைக் கண்காணிக்க உதவுகிறது.
• ஒவ்வொரு ப்ரோப் பாதையிலும் நிமிடத்திற்கு 6000 பேக்கேஜ்களில் 1 பேக்கேஜ் என்ற அளவிலான நெட்வொர்க் டிராப்களை கூட ஏஜென்ட் கண்டறிய முடியும். BGP ஃபிளாப் போன்ற நிகழ்வுகளின் போது ஏற்படும், நெட்வொர்க்கின் கோர் அல்லது எட்ஜில் 1 வினாடிக்கும் குறைவாக நீடிக்கும் பேக்கேஜ் இழப்பைக் கண்டறிய முடியும்.
• பிழைகளே துள்ளல்களுக்குக் காரணமாக இருக்கும்போது, ஆய்வுப் பொதித் துள்ளல் விளக்கப்படங்கள், நெட்வொர்க் சாதன இடைமுகப் பிழை விகிதங்களைப் போலவே இருக்கும். நெட்வொர்க்கில் கண்டறிவது கடினமான போக்குவரத்து பிளாக்-ஹோலிங் பிழைகளைக் கண்டறிய எங்களால் முடிந்துள்ளது.
• நெட்வொர்க் தாமத அளவீடுகளில் உயர் துல்லியத்தை அடைய, ஏஜென்ட்கள் NIC கெர்னல் ரீட் டைம்ஸ்டாம்ப்களைப் பயன்படுத்துகின்றன. ஹோஸ்ட் OS திட்டமிடல் தாமதம் மற்றும் நெட்வொர்க் கடிகார விலகலை விலக்கி, ஒரு நிலையான 50–100 மைக்ரோவினாடி இன்ட்ரா-சைட் சுற்றுப்பயண தாமதத்தை அளவிட முடியும்.
• குறைந்த சிபியு பயன்பாடு மற்றும் நினைவகம். உச்சபட்ச அனுப்புதல் மற்றும் பெறுதல் விகிதங்களில் (ஒவ்வொன்றும் 5 kpps) ஏஜென்ட் ஒரு சிங்கிள் கோரின் 25% க்கும் குறைவாகவே பயன்படுத்துகிறது. பயன்படுத்தப்படும் பெரும்பாலான ஏஜென்ட்கள் ஒரு கோரின் சுமார் 5% மட்டுமே பயன்படுத்துகின்றன. ஏஜென்ட்டின் Tx மற்றும் Rx பாக்கெட் பஃபர்கள் மற்றும் கவுண்டர்களை நிர்வகிக்க 10MB ஹீப் மெமரி மட்டுமே தேவைப்படுகிறது. நெட்வொர்க் வளரும்போது, வரம்புகளை மாற்றுவதன் மூலமோ அல்லது கூடுதல் ஏஜென்ட்களைச் சேர்ப்பதன் மூலமோ நாம் செங்குத்தாகவோ கிடைமட்டமாகவோ அளவிடலாம்.
• ஹோஸ்ட் சிஸ்டம் அழுத்தத்தில் இருக்கும்போது ஏஜென்ட் பாதிக்கப்படுவது அரிது. பல சந்தர்ப்பங்களில் ஹோஸ்ட் சிபியு சுமை 99% நெருங்கியபோதும் நாங்கள் துல்லியமான முடிவுகளைப் பெற்றுள்ளோம்.
• ஒவ்வொரு ஏஜென்ட்டின் ஆரோக்கியத்தைக் கண்காணிக்க, டெலிமெட்ரி சேகரிக்கப்படுகிறது. ஹோஸ்ட் சிஸ்டம் ரீபூட் செய்யப்படும்போது, ஏஜென்ட் செயல்முறை மீண்டும் தொடங்கும் போது, அல்லது சாக்கெட் பஃப்பர்கள் நிரம்பி வழிவதால் பாக்கெட்டுகள் விடுபடும்போது போன்ற சிக்கலான சூழ்நிலைகளை ஏஜென்ட்கள் கண்டறிய முடியும்.

நெட்வொர்க் சோதனையில் அதிக எண்ணிக்கையிலான நோட்கள் பங்கேற்பதைப் பராமரிக்க, ஏஜெண்ட்கள் செஃப் (Chef) மூலம் பலதரப்பட்ட சர்வர் கிளஸ்டர்களில் வரிசைப்படுத்தப்படுகின்றன. ஏஜென்ட் பைனரி லினக்ஸில் systemd மூலம் இயக்கப்பட்டு நிர்வகிக்கப்படுகிறது, இதனால் ஹோஸ்ட் ரீபூட் அல்லது ஏஜென்ட் மேம்படுத்தலுக்குப் பிறகு அது தானாகவே மீண்டும் தொடங்கும். ஏஜெண்ட்களில் ஏதேனும் ஒன்று செயலிழக்கும்போதோ அல்லது புதியவை வரும்போதோ, மெஷ் ஸ்கெஜூலர் தேவைக்கேற்ப ஸ்ட்ரீம்களைத் தானாகவே கண்டறிந்து சரிசெய்கிறது. எங்கள் திட்டமிடுநர் பயன்பாடு, இன்ட்ரா-பாட், இன்ட்ரா-சைட் மற்றும் இன்டர்-சைட் ஆய்வுகளுக்கான இலக்குகளை ஒதுக்குவதற்கு முன்பு, புதிய முகவர்கள் மற்றும் சேவையகத்தின் ஆரோக்கிய நிலையைக் கண்டறிய, சாதனப் பட்டியலையும் ஒரு சேவை கண்டறிதல் அமைப்பையும் குறிப்பிட்ட இடைவெளியில் பின்தொடர்கிறது. சோதனைத் துடுப்புகளை அனுப்பும் ஒவ்வொரு ஏஜென்ட்டுக்கும் இலக்கு ஹோஸ்ட் பட்டியலைத் தெரிவிக்க ஒரு செய்திப் பேருந்து பயன்படுத்தப்படுகிறது. ஒரு குறிப்பிட்ட ரேக்கில் தொடங்கும் அல்லது முடியும் தனிப்பட்ட ஸ்ட்ரீம்கள், அந்த ரேக்கிற்குள் கிடைக்கும் அனைத்து ஏஜென்டுகளிடையே விநியோகிக்கப்படுகின்றன. கீழே உள்ள படங்களில் காட்டப்பட்டுள்ளபடி, எங்கள் நெட்வொர்க் கட்டமைப்பிற்குள் அதிக எண்ணிக்கையிலான சம மதிப்பு பாதைகளைச் செயல்படுத்த இது எங்களுக்கு உதவுகிறது.

எங்கள் முதல் வரிசையில் 150 ஏஜெண்ட்களுடன் தொடங்கினோம், இப்போது வெற்றிகரமாக 10 மடங்கு விரிவுபடுத்தியுள்ளோம். இந்த மெஷ், உலகம் முழுவதும் பரவியுள்ள 25 தளங்களை இணைக்கும் எங்கள் முதுகெலும்பை உள்ளடக்கியுள்ளது. எங்களின் முதன்மை தரவு மையங்களில் ஒன்றில், 200-க்கும் மேற்பட்ட ரேக்குகளை உள்ளடக்கிய ஒரு இன்ட்ரா-சைட் மெஷ் உள்ளது, இது சுமார் 33,000 ஸ்ட்ரீம்களை ஒருங்கிணைத்து 1.65 Mpps ப்ரோப் விகிதத்தை அடையும். ஒவ்வொரு ரேக்கும் மற்ற ரேக்குகளிலிருந்து 5–10 kpps ப்ரோப்களைப் பெறுகிறது. ஸ்கெஜூலர் பயன்பாடு கணக்கிட்டு, வெவ்வேறு தளங்களில் உள்ள எங்களின் அனைத்து ஏஜென்ட்களிலும் 35,000-க்கும் மேற்பட்ட இலக்குகளை சமமாக விநியோகிக்கிறது.

தரவு சேகரிப்பு மற்றும் காட்சிப்படுத்தல்

நாங்கள் ஒரு தனி சேகரிப்புப் பயன்பாட்டை (collector application) இயக்குகிறோம், இது அனைத்து பிங் மெஷ் ஏஜென்ட்களிடமிருந்தும் பேக்கேட் இழப்பு மற்றும் தாமத முடிவுகளை அவ்வப்போது சேகரிக்கிறது. இந்தத் தரவு, சேகரிப்பான் (collector) இடத்தில் உள்ளூர்மாகச் சேமிக்கப்பட்ட சுகாதார நிலைகளின் (health states) அடிப்படையில் செல்லாத முடிவுகளைத் தானாகவே வடிகட்டுகிறது. உதாரணமாக, சுகாதாரச் சோதனைகளுக்கு (health checks) பதிலளிக்காத ஒரு சர்வரில் இயங்கும் ஏஜென்ட் அல்லது புதிதாக மறுதொடக்கம் செய்யப்பட்ட (rebooted) ஒரு சர்வரில் இருந்து வரும் முடிவுகளை நாங்கள் நீக்குகிறோம். எங்கள் சேகரிப்பான் 1,500-க்கும் மேற்பட்ட முனைகளிலிருந்து ஒத்திசைவாக முடிவுகளைக் கேட்டு, வடிகட்டி, பின்னர் அந்தத் தரவை 2 வினாடிகளுக்குள் ஒரு காலவரிசைத் தரவுத்தளத்தில் சேர்க்கும் திறன் கொண்டது.

ஒருங்கிணைக்கப்பட்ட மற்றும் ஒவ்வொரு ஸ்ட்ரீம் முடிவுகளும் கிராஃபானா டாஷ்போர்டுகளின் உதவியுடன் காட்சிப்படுத்தப்படுகின்றன. ஹீட்மேப் கட்டங்களைப் பெரிய தரவுத் தொகுப்புகளுடன் பயன்படுத்துவது கடினமாக இருக்கலாம், குறிப்பாக எங்கள் பெரிய தரவு மைய தளத்திற்கு. ஆயிரக்கணக்கான முடிவுகளில், பொதுவாக ஒரு சிலவாக இருக்கும், அதிக தனிப்பட்ட பாக்கெட் இழப்பைக் கொண்ட பாதைகளைக் காட்ட நாங்கள் ஒரு ப்ரோமிதியஸ் topk() வினவலைப் பயன்படுத்துகிறோம். சேகரிப்பான் அடிக்கடி கணக்கெடுக்கும் ஏஜென்ட் மற்றும் ஹோஸ்ட் சிஸ்டம் ஆரோக்கிய புள்ளிவிவரங்களுடன் முடிவுகள் விரிவாக சரிபார்க்கப்படுகின்றன. பேக்கெட் இழப்பு மாறுபாடுகள் எவ்வளவு பெரியதாக இருந்தாலும், ஒவ்வொரு தனிப்பட்ட முடிவிலும் இது எங்களுக்கு உயர் மட்ட நம்பிக்கையை அளிக்கிறது. தனிப்பட்ட முடிவுகளை ஒன்றாகப் பார்க்கும்போது, நெட்வொர்க் கோளாறு எங்கே ஏற்பட்டது என்பது குறித்த துப்புகளை எங்களுக்கு வழங்க முடியும். எங்கள் மெஷ் கண்காணிப்பு அமைப்பால் பிடிக்கப்பட்ட சில பேக்கெட் இழப்பு எடுத்துக்காட்டுகள் கீழே காட்டப்பட்டுள்ளன.

சுருக்கம் மற்றும் அடுத்தகட்ட நடவடிக்கைகள்

எங்கள் பிங் மெஷ் அமைப்பு, நெட்வொர்க் இன்ஜினியரிங் குழுவிற்கு ஆரம்பம் முதல் இறுதி வரையிலான பாக்கெட் இழப்பு மற்றும் தாமதத்தைக் கண்காணிக்க ஒரு சக்திவாய்ந்த கருவியாக இருந்து வருகிறது. "நெட்வொர்க் பாக்கெட்டுகளைத் தவறவிடுகிறதா?" என்ற கேள்விக்கு உடனடியாக பதிலளிக்க இந்தத் தரவைப் பயன்படுத்தலாம். எங்கள் அனுபவத்தின் அடிப்படையில், வாடிக்கையாளர்களுக்குப் பெரிய தாக்கத்தை ஏற்படுத்தும் நெட்வொர்க் சம்பவங்கள் பொதுவாக சாதனத்தின் டெலிமெட்ரி கண்காணிப்பு அமைப்பால் கண்டறியப்பட்டு எச்சரிக்கப்படுகின்றன. வலையமைப்பு பஃப்ரிங் அல்லது தனிப்பட்ட போக்குவரத்து பிளாக்-ஹோலிங் போன்ற, குறைந்த தாக்கத்தை ஏற்படுத்தும் ஆனால் சிக்கல்களை ஏற்படுத்தக்கூடிய பிரச்சினைகள் இந்த அமைப்பின் மூலம் வெளிச்சத்திற்குக் கொண்டுவரப்படுகின்றன.

எங்கள் அமைப்பு ராப்லாக்ஸ் கிளவுட் நெட்வொர்க்கின் ஒட்டுமொத்த நம்பகத்தன்மை குறித்த தகவல்களையும் வழங்க முடியும். எங்கள் முக்கிய தரவு மையங்களில் ஒன்றில், நெட்வொர்க்கின் ஆரோக்கியத்தை நிமிடத்திற்கு 100 மில்லியனுக்கும் அதிகமான ப்ரோப்கள் கண்காணிக்கின்றன, மேலும் நிமிடத்திற்கு 50-க்கும் அதிகமான பேக்கெட் இழப்பு எண்ணிக்கையை நாங்கள் அரிதாகவே காண்கிறோம். இது எங்கள் தரவு மைய நெட்வொர்க்கிலிருந்து சுமார் 6 9-கள் நம்பகத்தன்மையை (99.9999%) குறிக்கிறது. பெரும்பாலும், 100 மில்லியன் பேக்கேஜ்களில் எந்த பேக்கேஜ் இழப்பும் கவனிக்கப்படுவதில்லை. குறிப்பிடத்தக்க அளவு பேக்கேஜ்கள் இழக்கப்படும்போது, பேக்கேஜ் இழப்பு எங்கே மற்றும் எவ்வளவு நேரம் ஏற்பட்டது என்பது குறித்த தகவல்களை இந்த அமைப்பு வழங்குகிறது. ஒரு தானியங்கி சரிசெய்தல் இயந்திரம் வலையமைப்பைத் தானாகவே சரிசெய்கிறது மற்றும் பயனர் போக்குவரத்தை வலையமைப்பில் உள்ள வேறு பாதை வழியாகத் திருப்பியனுப்புவதன் மூலம் அது மேலும் இழப்புகளைச் சந்திப்பதைத் தடுக்கிறது. ராப்ளக்ஸில் உள்ள நெட்வொர்க்கிங் குழு மிகவும் நம்பகமான கிளவுட் நெட்வொர்க்கை உருவாக்கியுள்ளது.

எதிர்காலத்தில், சாதன டெலிமெட்ரி, சிஸ்லாக்ஸ் மற்றும் பிற தரவுத் தொகுப்புகளிலிருந்து வரும் தரவுகளைத் தொடர்புபடுத்த ஒரு பகுப்பாய்வு இயந்திரத்தைப் பயன்படுத்த நாங்கள் உத்தேசித்துள்ளோம். பின்னர், நெட்வொர்க் கோளாறு எங்கு ஏற்பட்டது என்பதைக் கண்டறிய உதவுவதற்காக, அதை பிங் மெஷ் தரவுகளுடன் ஒப்பிடத் திட்டமிட்டுள்ளோம். ராப்லாக்ஸின் கிளவுட் நெட்வொர்க் தொடர்ந்து விரிவடைந்து உருவாகும்போது, IPv6 மற்றும் ஜம்போ ஃபிரேம்களைச் சேர்ப்பதற்கும், தளங்களுக்கு இடையிலான உள்ளடக்கத்தை அதிகரிக்க மேலும் ஏஜென்ட்களைச் சேர்ப்பதற்கும் எங்கள் ஆய்வு வழிமுறைகளை மேம்படுத்தத் திட்டமிட்டுள்ளோம்.