Yandex.Cloud இல் நெட்வொர்க் சுமை சமநிலையின் கட்டமைப்பு

வணக்கம், நான் செர்ஜி எலன்செவ், நான் வளர்கிறேன் பிணைய சுமை சமநிலை Yandex.Cloud இல். முன்னதாக, யாண்டெக்ஸ் போர்ட்டலுக்கான எல் 7 பேலன்சரின் வளர்ச்சியை நான் வழிநடத்தினேன் - நான் என்ன செய்தாலும் அது ஒரு சமநிலையாக மாறும் என்று சக ஊழியர்கள் கேலி செய்கிறார்கள். கிளவுட் பிளாட்ஃபார்மில் சுமையை எவ்வாறு நிர்வகிப்பது, இந்த இலக்கை அடைவதற்கான சிறந்த கருவியாக நாம் எதைப் பார்க்கிறோம், இந்தக் கருவியை உருவாக்குவதை நோக்கி எப்படி நகர்கிறோம் என்பதை ஹப்ர் வாசகர்களுக்கு நான் கூறுவேன்.

முதலில், சில விதிமுறைகளை அறிமுகப்படுத்துவோம்:

• விஐபி (மெய்நிகர் ஐபி) - சமநிலை ஐபி முகவரி
• சேவையகம், பின்தளம், நிகழ்வு - ஒரு பயன்பாட்டை இயக்கும் மெய்நிகர் இயந்திரம்
• RIP (உண்மையான IP) - சர்வர் ஐபி முகவரி
• சுகாதார சோதனை - சர்வர் தயார்நிலையை சரிபார்க்கிறது
• கிடைக்கும் மண்டலம், AZ - தரவு மையத்தில் தனிமைப்படுத்தப்பட்ட உள்கட்டமைப்பு
• பிராந்தியம் - வெவ்வேறு AZ களின் ஒன்றியம்

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

ஒரு சுமை சமநிலையானது பெரும்பாலும் அது இயங்கும் OSI மாதிரியிலிருந்து நெறிமுறை அடுக்கு மூலம் வகைப்படுத்தப்படுகிறது. கிளவுட் பேலன்சர் TCP மட்டத்தில் செயல்படுகிறது, இது நான்காவது அடுக்கு, L4 க்கு ஒத்திருக்கிறது.

கிளவுட் பேலன்சர் கட்டமைப்பின் மேலோட்டத்திற்கு செல்லலாம். விவரங்களின் அளவை படிப்படியாக அதிகரிப்போம். சமநிலை கூறுகளை மூன்று வகுப்புகளாகப் பிரிக்கிறோம். config விமான வகுப்பு பயனர் தொடர்புக்கு பொறுப்பாகும் மற்றும் கணினியின் இலக்கு நிலையை சேமிக்கிறது. கட்டுப்பாட்டு விமானம் கணினியின் தற்போதைய நிலையைச் சேமித்து, டேட்டா பிளேன் வகுப்பிலிருந்து அமைப்புகளை நிர்வகிக்கிறது, அவை வாடிக்கையாளர்களிடமிருந்து உங்கள் நிகழ்வுகளுக்கு போக்குவரத்தை வழங்குவதற்கு நேரடியாகப் பொறுப்பாகும்.

தரவு விமானம்

எல்லை திசைவிகள் எனப்படும் விலையுயர்ந்த சாதனங்களில் போக்குவரத்து முடிவடைகிறது. தவறு சகிப்புத்தன்மையை அதிகரிக்க, ஒரு தரவு மையத்தில் இதுபோன்ற பல சாதனங்கள் ஒரே நேரத்தில் இயங்குகின்றன. அடுத்து, ட்ராஃபிக் பேலன்சர்களுக்குச் செல்கிறது, இது வாடிக்கையாளர்களுக்கு BGP வழியாக அனைத்து AZ களுக்கும் ஏதேனும் IP முகவரிகளை அறிவிக்கிறது. 

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

கட்டமைப்பு விமானம்

 
கட்டமைப்பு விமானத்தின் முக்கிய கூறு API ஆகும், இதன் மூலம் பேலன்சர்களுடன் அடிப்படை செயல்பாடுகள் செய்யப்படுகின்றன: உருவாக்குதல், நீக்குதல், நிகழ்வுகளின் கலவையை மாற்றுதல், சுகாதார சோதனை முடிவுகளைப் பெறுதல் போன்றவை. ஒருபுறம், இது ஒரு REST API, மற்றும் மற்றவை, கிளவுட்டில் உள்ள நாங்கள் அடிக்கடி gRPC கட்டமைப்பைப் பயன்படுத்துகிறோம், எனவே REST ஐ gRPC க்கு "மொழிபெயர்த்து" gRPC ஐ மட்டுமே பயன்படுத்துகிறோம். எந்தவொரு கோரிக்கையும் Yandex.Cloud தொழிலாளர்களின் பொதுவான தொகுப்பில் செயல்படுத்தப்படும் ஒத்திசைவற்ற ஐடெம்போடென்ட் பணிகளின் வரிசையை உருவாக்க வழிவகுக்கிறது. பணிகள் எந்த நேரத்திலும் இடைநிறுத்தப்பட்டு மறுதொடக்கம் செய்யக்கூடிய வகையில் எழுதப்பட்டுள்ளன. இது செயல்பாடுகளின் அளவிடுதல், மீண்டும் நிகழ்தல் மற்றும் பதிவு செய்தல் ஆகியவற்றை உறுதி செய்கிறது.

இதன் விளைவாக, கோவில் எழுதப்பட்ட பேலன்சர் சர்வீஸ் கன்ட்ரோலரிடம் ஏபிஐயின் பணி கோரிக்கையை வைக்கும். இது பேலன்சர்களைச் சேர்க்கலாம் மற்றும் அகற்றலாம், பின்தளங்கள் மற்றும் அமைப்புகளின் கலவையை மாற்றலாம். 

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

பேலன்சர் கன்ட்ரோலருக்குத் திரும்புவோம். சமநிலையைப் பற்றிய தகவல்களைச் சேமித்து, மெய்நிகர் இயந்திரத்தின் தயார்நிலையை ஹெல்த் செக் கன்ட்ரோலருக்குச் சரிபார்க்க ஒரு பணியை அனுப்புவதே இதன் பணி.

சுகாதார சோதனை கட்டுப்படுத்தி

இது காசோலை விதிகளை மாற்றுவதற்கான கோரிக்கைகளைப் பெறுகிறது, அவற்றை YDB இல் சேமிக்கிறது, ஹெல்ட்செக் முனைகளில் பணிகளை விநியோகிக்கிறது மற்றும் முடிவுகளை ஒருங்கிணைக்கிறது, பின்னர் அவை தரவுத்தளத்தில் சேமிக்கப்பட்டு லோட்பேலன்சர் கட்டுப்படுத்திக்கு அனுப்பப்படும். இதையொட்டி, தரவுத் தளத்தில் உள்ள கிளஸ்டரின் கலவையை loadbalancer-node க்கு மாற்றுவதற்கான கோரிக்கையை அனுப்புகிறது, அதை நான் கீழே விவாதிப்பேன்.

சுகாதார சோதனைகள் பற்றி மேலும் பேசலாம். அவற்றை பல வகுப்புகளாகப் பிரிக்கலாம். தணிக்கைகள் வெவ்வேறு வெற்றி அளவுகோல்களைக் கொண்டுள்ளன. TCP காசோலைகள் ஒரு குறிப்பிட்ட நேரத்திற்குள் இணைப்பை வெற்றிகரமாக நிறுவ வேண்டும். HTTP சரிபார்ப்புகளுக்கு வெற்றிகரமான இணைப்பு மற்றும் 200 நிலைக் குறியீட்டுடன் பதில் இரண்டும் தேவை.

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

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

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

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

குவாசி-ஐபிவி6 முகவரிகள் என அழைக்கப்படுவதைப் பயன்படுத்தி ஹெல்த்செக் முனைகள் பேலன்சர்களைத் தொடர்பு கொள்கின்றன. அரை-முகவரி என்பது IPv6 முகவரியாகும், அதில் IPv4 முகவரி மற்றும் பயனர் சப்நெட் ஐடி உட்பொதிக்கப்பட்டுள்ளது. டிராஃபிக் பேலன்சரை அடைகிறது, அது அதிலிருந்து IPv4 ஆதார முகவரியைப் பிரித்தெடுத்து, IPv6 ஐ IPv4 உடன் மாற்றி, பாக்கெட்டை பயனரின் நெட்வொர்க்கிற்கு அனுப்புகிறது.

தலைகீழ் ட்ராஃபிக் அதே வழியில் செல்கிறது: ஹெல்த் செக்கர்களிடமிருந்து சேருமிடம் ஒரு சாம்பல் நெட்வொர்க் என்பதை சமநிலையாளர் பார்த்து, IPv4 ஐ IPv6 ஆக மாற்றுகிறார்.

VPP - தரவு விமானத்தின் இதயம்

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

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

எடுத்துக்காட்டாக, VPP இல் ஐபி பாக்கெட்டுகளின் செயலாக்கம் பின்வரும் வரிசையில் நிகழ்கிறது: முதலில், பாக்கெட் தலைப்புகள் பாகுபடுத்தும் முனையில் பாகுபடுத்தப்படுகின்றன, பின்னர் அவை முனைக்கு அனுப்பப்படுகின்றன, இது ரூட்டிங் அட்டவணைகளின்படி பாக்கெட்டுகளை மேலும் அனுப்புகிறது.

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

n_left_from = frame->n_vectors;
while (n_left_from > 0)
{
    vlib_get_next_frame (vm, node, next_index, to_next, n_left_to_next);
    // ...
    while (n_left_from >= 4 && n_left_to_next >= 2)
    {
        // processing multiple packets at once
        u32 next0 = SAMPLE_NEXT_INTERFACE_OUTPUT;
        u32 next1 = SAMPLE_NEXT_INTERFACE_OUTPUT;
        // ...
        /* Prefetch next iteration. */
        {
            vlib_buffer_t *p2, *p3;

            p2 = vlib_get_buffer (vm, from[2]);
            p3 = vlib_get_buffer (vm, from[3]);

            vlib_prefetch_buffer_header (p2, LOAD);
            vlib_prefetch_buffer_header (p3, LOAD);

            CLIB_PREFETCH (p2->data, CLIB_CACHE_LINE_BYTES, STORE);
            CLIB_PREFETCH (p3->data, CLIB_CACHE_LINE_BYTES, STORE);
        }
        // actually process data
        /* verify speculative enqueues, maybe switch current next frame */
        vlib_validate_buffer_enqueue_x2 (vm, node, next_index,
                to_next, n_left_to_next,
                bi0, bi1, next0, next1);
    }

    while (n_left_from > 0 && n_left_to_next > 0)
    {
        // processing packets by one
    }

    // processed batch
    vlib_put_next_frame (vm, node, next_index, n_left_to_next);
}

எனவே, Healthchecks IPv6ஐ VPPக்கு பேசுகிறது, அது IPv4 ஆக மாற்றுகிறது. இது வரைபடத்தில் உள்ள ஒரு முனையால் செய்யப்படுகிறது, இதை நாம் அல்காரிதம் NAT என்று அழைக்கிறோம். தலைகீழ் போக்குவரத்திற்கு (மற்றும் IPv6 இலிருந்து IPv4 க்கு மாற்றவும்) அதே அல்காரிதம் NAT முனை உள்ளது.

சமநிலை வாடிக்கையாளர்களிடமிருந்து நேரடி போக்குவரத்து வரைபட முனைகள் வழியாக செல்கிறது, இது சமநிலையை தானே செய்கிறது. 

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

5-டூப்பிள் ஹாஷ், அடுத்தடுத்த நிலையான ஹேஷிங் முனையில் குறைவான கணக்கீடுகளைச் செய்ய உதவுகிறது, அத்துடன் பேலன்சருக்குப் பின்னால் உள்ள வளப் பட்டியல் மாற்றங்களை சிறப்பாகக் கையாளுகிறது. அமர்வு இல்லாத ஒரு பாக்கெட் பேலன்சருக்கு வரும்போது, ​​அது நிலையான ஹாஷிங் முனைக்கு அனுப்பப்படும். நிலையான ஹாஷிங்கைப் பயன்படுத்தி சமநிலைப்படுத்துவது இங்குதான்: கிடைக்கக்கூடிய "நேரடி" ஆதாரங்களின் பட்டியலிலிருந்து ஒரு வளத்தைத் தேர்ந்தெடுக்கிறோம். அடுத்து, பாக்கெட்டுகள் NAT முனைக்கு அனுப்பப்படும், இது உண்மையில் இலக்கு முகவரியை மாற்றுகிறது மற்றும் செக்சம்களை மீண்டும் கணக்கிடுகிறது. நீங்கள் பார்க்க முடியும் என, VPP இன் விதிகளை நாங்கள் பின்பற்றுகிறோம் - விரும்புவதை விரும்புகிறோம், செயலி தற்காலிக சேமிப்புகளின் செயல்திறனை அதிகரிக்க ஒத்த கணக்கீடுகளை தொகுக்கிறோம்.

நிலையான ஹாஷிங்

நாம் ஏன் அதைத் தேர்ந்தெடுத்தோம், அது என்ன? முதலில், முந்தைய பணியைக் கருத்தில் கொள்வோம் - பட்டியலிலிருந்து ஒரு ஆதாரத்தைத் தேர்ந்தெடுப்பது. 

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

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

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

சமநிலை மற்றும் வளங்களுக்கு இடையேயான நேரடி போக்குவரத்திற்கு என்ன நடக்கிறது என்பதை நாங்கள் பார்த்தோம். இப்போது திரும்பும் போக்குவரத்தைப் பார்ப்போம். இது காசோலை டிராஃபிக்கைப் போன்ற அதே முறையைப் பின்பற்றுகிறது - அல்காரிதமிக் NAT மூலம், அதாவது கிளையன்ட் ட்ராஃபிக்கிற்கான தலைகீழ் NAT 44 மற்றும் ஹெல்த் செக் ட்ராஃபிக்கிற்கு NAT 46 மூலம். நாங்கள் எங்கள் சொந்த திட்டத்தை கடைபிடிக்கிறோம்: நாங்கள் சுகாதார சோதனை போக்குவரத்து மற்றும் உண்மையான பயனர் போக்குவரத்தை ஒருங்கிணைக்கிறோம்.

லோட்பேலன்சர்-நோட் மற்றும் அசெம்பிள் செய்யப்பட்ட கூறுகள்

VPP இல் உள்ள பேலன்சர்கள் மற்றும் வளங்களின் கலவை உள்ளூர் சேவை - loadbalancer-node மூலம் தெரிவிக்கப்படுகிறது. இது லோட்பேலன்சர்-கண்ட்ரோலரிலிருந்து நிகழ்வுகளின் ஸ்ட்ரீமுக்கு குழுசேருகிறது மற்றும் தற்போதைய VPP நிலைக்கும் கட்டுப்படுத்தியிலிருந்து பெறப்பட்ட இலக்கு நிலைக்கும் இடையே உள்ள வித்தியாசத்தை திட்டமிட முடியும். நாங்கள் ஒரு மூடிய அமைப்பைப் பெறுகிறோம்: API இலிருந்து நிகழ்வுகள் பேலன்சர் கன்ட்ரோலருக்கு வருகின்றன, இது வளங்களின் "வாழ்க்கையை" சரிபார்க்க ஹெல்த் செக் கன்ட்ரோலருக்கு பணிகளை ஒதுக்குகிறது. இது, ஹெல்த் செக்-நோடில் பணிகளை ஒதுக்கி, முடிவுகளை ஒருங்கிணைக்கிறது, அதன் பிறகு அது மீண்டும் பேலன்சர் கன்ட்ரோலருக்கு அனுப்புகிறது. லோட்பேலன்சர்-நோட் கன்ட்ரோலரில் இருந்து நிகழ்வுகளுக்கு சந்தா செலுத்துகிறது மற்றும் VPP இன் நிலையை மாற்றுகிறது. அத்தகைய அமைப்பில், ஒவ்வொரு சேவையும் அண்டை சேவைகளைப் பற்றி தேவையானதை மட்டுமே அறிந்திருக்கிறது. இணைப்புகளின் எண்ணிக்கை குறைவாக உள்ளது, மேலும் வெவ்வேறு பிரிவுகளை சுயாதீனமாக இயக்க மற்றும் அளவிடும் திறன் எங்களிடம் உள்ளது.

என்ன சிக்கல்கள் தவிர்க்கப்பட்டன?

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

சிக்கல்கள் மற்றும் தீர்வுகள்

எது நன்றாக வேலை செய்யவில்லை? Go தானியங்கி நினைவக மேலாண்மை உள்ளது, ஆனால் நினைவக கசிவுகள் இன்னும் நடக்கும். அவற்றைக் கையாள்வதற்கான எளிதான வழி, goroutines ஐ இயக்கி, அவற்றை நிறுத்த நினைவில் வைத்துக்கொள்ள வேண்டும். டேக்அவே: உங்கள் Go நிரல்களின் நினைவக நுகர்வுகளைப் பாருங்கள். பெரும்பாலும் ஒரு நல்ல காட்டி goroutines எண்ணிக்கை. இந்தக் கதையில் ஒரு பிளஸ் உள்ளது: Go இல் இயக்க நேரத் தரவைப் பெறுவது எளிது - நினைவக நுகர்வு, இயங்கும் goroutineகளின் எண்ணிக்கை மற்றும் பல அளவுருக்கள்.

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

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

எங்கள் திட்டங்கள்

நாங்கள் ஒரு இன்டர்னல் பேலன்சர், ஐபிவி6 பேலன்சரைத் தொடங்குவோம், குபெர்னெட்டஸ் ஸ்கிரிப்ட்டுகளுக்கான ஆதரவைச் சேர்ப்போம், எங்கள் சேவைகளைத் தொடர்ந்து பிரிப்போம் (தற்போது ஹெல்த் செக்-நோட் மற்றும் ஹெல்த் செக்-சிடிஆர்எல் மட்டுமே துண்டிக்கப்பட்டுள்ளன), புதிய ஹெல்த் செக்குகளைச் சேர்ப்போம், மேலும் காசோலைகளின் ஸ்மார்ட் ஒருங்கிணைப்பையும் செயல்படுத்துவோம். எங்கள் சேவைகளை இன்னும் சுதந்திரமானதாக மாற்றுவதற்கான சாத்தியக்கூறுகளை நாங்கள் பரிசீலித்து வருகிறோம் - அதனால் அவர்கள் ஒருவருக்கொருவர் நேரடியாக தொடர்பு கொள்ளாமல், ஒரு செய்தி வரிசையைப் பயன்படுத்துகின்றனர். SQS-இணக்கமான சேவை சமீபத்தில் கிளவுட்டில் தோன்றியது யாண்டெக்ஸ் செய்தி வரிசை.

சமீபத்தில், யாண்டெக்ஸ் லோட் பேலன்சரின் பொது வெளியீடு நடந்தது. ஆராயுங்கள் ஆவணங்கள் சேவைக்கு, உங்களுக்கு வசதியான வகையில் பேலன்சர்களை நிர்வகிக்கவும் மற்றும் உங்கள் திட்டங்களின் தவறு சகிப்புத்தன்மையை அதிகரிக்கவும்!

ஆதாரம்: www.habr.com