இஸ்டியோ சர்க்யூட் பிரேக்கர்: தவறான கொள்கலன்களை முடக்குதல்

விடுமுறை முடிந்துவிட்டது, இஸ்டியோ சர்வீஸ் மெஷ் தொடரில் எங்களின் இரண்டாவது இடுகையுடன் திரும்பியுள்ளோம்.

இன்றைய தலைப்பு சர்க்யூட் பிரேக்கர் ஆகும், இது ரஷ்ய மின் பொறியியலில் மொழிபெயர்க்கப்பட்டுள்ளது "சர்க்யூட் பிரேக்கர்", பொதுவான மொழியில் - "சர்க்யூட் பிரேக்கர்". இஸ்டியோவில் மட்டுமே இந்த இயந்திரம் குறுகிய அல்லது அதிக சுமை கொண்ட சுற்றுகளை துண்டிக்காது, ஆனால் தவறான கொள்கலன்களை.

இது எவ்வாறு சிறப்பாகச் செயல்பட வேண்டும்

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

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

இது உண்மையில் எப்படி வேலை செய்கிறது

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

இஸ்டியோவில் பூல் எஜெக்ஷன் என்றால் என்ன

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

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

ஓபன்ஷிஃப்ட் இயங்குதளத்தில் குபெர்னெட்டஸில் இது எவ்வாறு செயல்படுகிறது என்பதைக் காட்ட, களஞ்சியத்தில் உள்ள எடுத்துக்காட்டில் இருந்து சாதாரணமாக வேலை செய்யும் மைக்ரோ சர்வீஸின் ஸ்கிரீன்ஷாட்டுடன் ஆரம்பிக்கலாம். Red Hat டெவலப்பர் டெமோஸ். இங்கே எங்களிடம் இரண்டு காய்கள் உள்ளன, v1 மற்றும் v2, ஒவ்வொன்றும் ஒரு கொள்கலனை இயக்குகிறது. இஸ்டியோ ரூட்டிங் விதிகள் பயன்படுத்தப்படாதபோது, ​​குபெர்னெட்டஸ் சீரான ரவுண்ட்-ராபின் ரூட்டிங்கை இயல்புநிலையாக மாற்றுகிறது:

தோல்விக்குத் தயாராகிறது

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

oc scale deployment recommendation-v2 --replicas=2 -n tutorial

இப்போது 50/50 விகிதத்தில் காய்களுக்கு இடையே போக்குவரத்து விநியோகிக்கப்படும் வகையில் ரூட்டிங் விதியை அமைத்துள்ளோம்.

இந்த விதியின் முடிவு எப்படி இருக்கும் என்பது இங்கே:

இந்தத் திரை 50/50 அல்ல, ஆனால் 14:9 என்று நீங்கள் தவறாகக் காணலாம், ஆனால் காலப்போக்கில் நிலைமை மேம்படும்.

ஒரு தடுமாற்றம்

இப்போது இரண்டு v2 கொள்கலன்களில் ஒன்றை முடக்கலாம், இதனால் எங்களிடம் ஒரு ஆரோக்கியமான v1 கொள்கலன், ஒரு ஆரோக்கியமான v2 கொள்கலன் மற்றும் ஒரு தவறான v2 கொள்கலன் உள்ளது:

கோளாறை சரிசெய்தல்

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

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

கட்டிடக்கலையை உருவாக்க ஆரம்பிக்கலாம்

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

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

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

கோட்பாட்டில் சர்க்யூட் பிரேக்கர்

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

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

நடைமுறையில் சர்க்யூட் பிரேக்கர்

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

siege -r 2 -c 20 -v customer-tutorial.$(minishift ip).nip.io

எல்லாம் வேலை செய்யத் தோன்றுகிறது, ஆனால் என்ன விலை? முதல் பார்வையில், எங்களிடம் 100% கிடைக்கும், ஆனால் உற்றுப் பாருங்கள் - அதிகபட்ச பரிவர்த்தனை காலம் 12 வினாடிகள். இது தெளிவாக ஒரு இடையூறு மற்றும் விரிவாக்கப்பட வேண்டும்.

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

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

சரி, எங்களிடம் சர்க்யூட் பிரேக்கர் உள்ளது, அடுத்து என்ன?

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

503 பிழைக்கு பதிலளிக்கும் பயன்பாட்டின் திறன் இன்னும் மூலக் குறியீடு மட்டத்தில் அமைக்கப்பட்டுள்ளது என்பதை நினைவில் கொள்க. சூழ்நிலையைப் பொறுத்து, சர்க்யூட் பிரேக்கரைப் பயன்படுத்துவதற்கு பல உத்திகள் உள்ளன.

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

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