ஊடக உள்ளடக்கம் இல்லாமல் நவீன வலை கிட்டத்தட்ட சிந்திக்க முடியாதது: கிட்டத்தட்ட ஒவ்வொரு பாட்டிக்கும் ஸ்மார்ட்போன் உள்ளது, எல்லோரும் சமூக வலைப்பின்னல்களில் உள்ளனர், மற்றும் பராமரிப்பு வேலையில்லா நேரம் நிறுவனங்களுக்கு விலை உயர்ந்தது. நிறுவனத்தின் கதையின் டிரான்ஸ்கிரிப்ட் இங்கே ஹார்டுவேர் தீர்வைப் பயன்படுத்தி புகைப்படங்களை விநியோகத்தை அவர் எவ்வாறு ஏற்பாடு செய்தார், செயல்பாட்டில் என்ன செயல்திறன் சிக்கல்களை எதிர்கொண்டார், அவற்றை ஏற்படுத்தியது மற்றும் அனைத்து நிலைகளிலும் தவறு சகிப்புத்தன்மையை உறுதிசெய்து, Nginx அடிப்படையிலான மென்பொருள் தீர்வைப் பயன்படுத்தி இந்த சிக்கல்கள் எவ்வாறு தீர்க்கப்பட்டன என்பது பற்றி () ஓலெக் கதையின் ஆசிரியர்களுக்கு நன்றி மாநாட்டில் தங்கள் அனுபவத்தைப் பகிர்ந்து கொண்ட எஃபிமோவா மற்றும் அலெக்ஸாண்ட்ரா டிமோவா .
— புகைப்படங்களை எவ்வாறு சேமித்து சேமிப்போம் என்பது பற்றிய சிறிய அறிமுகத்துடன் ஆரம்பிக்கலாம். எங்களிடம் ஒரு அடுக்கு உள்ளது, அங்கு நாங்கள் அவற்றைச் சேமிக்கிறோம், மேலும் புகைப்படங்களைத் தற்காலிகமாக சேமிக்கும் ஒரு அடுக்கு உள்ளது. அதே நேரத்தில், அதிக ட்ரிக் ரேட்டை அடையவும், சேமிப்பகத்தின் சுமையை குறைக்கவும் விரும்பினால், ஒரு தனிப்பட்ட பயனரின் ஒவ்வொரு புகைப்படமும் ஒரு கேச்சிங் சர்வரில் இருப்பது நமக்கு முக்கியம். இல்லையெனில், நம்மிடம் அதிக சர்வர்கள் உள்ளதைப் போல பல மடங்கு அதிக வட்டுகளை நிறுவ வேண்டியிருக்கும். எங்களின் ட்ரிக் ரேட் சுமார் 99%, அதாவது, எங்கள் சேமிப்பகத்தின் சுமையை 100 மடங்கு குறைக்கிறோம், இதைச் செய்ய, 10 ஆண்டுகளுக்கு முன்பு, இவை அனைத்தும் கட்டமைக்கப்பட்டபோது, எங்களிடம் 50 சேவையகங்கள் இருந்தன. அதன்படி, இந்த புகைப்படங்களை வழங்க, இந்த சர்வர்கள் சேவை செய்யும் 50 வெளிப்புற டொமைன்கள் எங்களுக்குத் தேவை.
இயற்கையாகவே, கேள்வி உடனடியாக எழுந்தது: எங்கள் சேவையகங்களில் ஒன்று செயலிழந்து, கிடைக்காமல் போனால், போக்குவரத்தின் எந்தப் பகுதியை இழக்கிறோம்? சந்தையில் என்ன இருக்கிறது என்பதைப் பார்த்து, ஒரு வன்பொருள் வாங்க முடிவு செய்தோம், அது எங்கள் எல்லா பிரச்சனைகளையும் தீர்க்கும். தேர்வு F5-நெட்வொர்க் நிறுவனத்தின் தீர்வு மீது விழுந்தது (இது, சமீபத்தில் NGINX, Inc ஐ வாங்கியது): BIG-IP உள்ளூர் போக்குவரத்து மேலாளர்.
இந்த வன்பொருள் (எல்டிஎம்) என்ன செய்கிறது: இது ஒரு இரும்பு திசைவி ஆகும், இது அதன் வெளிப்புற துறைமுகங்களின் இரும்பு பணிநீக்கத்தை உருவாக்குகிறது மற்றும் நெட்வொர்க் டோபாலஜியின் அடிப்படையில் போக்குவரத்தை சில அமைப்புகளில் வழிநடத்த அனுமதிக்கிறது மற்றும் சுகாதார சோதனைகளை செய்கிறது. இந்த வன்பொருளை நிரலாக்க முடியும் என்பது எங்களுக்கு முக்கியமானது. அதன்படி, ஒரு குறிப்பிட்ட தற்காலிக சேமிப்பிலிருந்து ஒரு குறிப்பிட்ட பயனரின் புகைப்படங்கள் எவ்வாறு வழங்கப்படுகின்றன என்பதற்கான தர்க்கத்தை நாம் விவரிக்கலாம். அது பார்க்க எப்படி இருக்கிறது? ஒரு டொமைனில் இணையத்தைப் பார்க்கும் ஒரு வன்பொருள் உள்ளது, ஒரு IP, ssl ஆஃப்லோட் செய்கிறது, http கோரிக்கைகளை அலசுகிறது, IRule இலிருந்து ஒரு கேச் எண்ணைத் தேர்ந்தெடுத்து, எங்கு செல்ல வேண்டும், மேலும் போக்குவரத்தை அங்கு செல்ல அனுமதிக்கிறது. அதே நேரத்தில், இது சுகாதார சோதனைகளை செய்கிறது, மேலும் சில இயந்திரங்கள் கிடைக்காத பட்சத்தில், அந்த நேரத்தில் ட்ராஃபிக் ஒரு பேக்அப் சர்வருக்கு செல்லும்படி செய்தோம். ஒரு உள்ளமைவு பார்வையில், நிச்சயமாக, சில நுணுக்கங்கள் உள்ளன, ஆனால் பொதுவாக எல்லாம் மிகவும் எளிது: நாங்கள் ஒரு அட்டையை பதிவு செய்கிறோம், நெட்வொர்க்கில் எங்கள் ஐபிக்கு ஒரு குறிப்பிட்ட எண்ணின் கடிதப் பரிமாற்றம், நாங்கள் போர்ட்கள் 80 இல் கேட்போம் என்று கூறுகிறோம். மற்றும் 443, சேவையகம் கிடைக்கவில்லை என்றால், நீங்கள் ட்ராஃபிக்கை காப்புப்பிரதிக்கு அனுப்ப வேண்டும், இந்த வழக்கில் 35 வது, மேலும் இந்த கட்டமைப்பை எவ்வாறு பிரிக்க வேண்டும் என்பதற்கான தர்க்கத்தை நாங்கள் விவரிக்கிறோம். ஒரே பிரச்சனை என்னவென்றால், வன்பொருள் நிரல் செய்யப்பட்ட மொழி Tcl ஆகும். இதை யாராவது நினைவில் வைத்திருந்தால்... இந்த மொழி நிரலாக்கத்திற்கு வசதியான மொழியை விட எழுதுவதற்கு மட்டுமே.
நமக்கு என்ன கிடைத்தது? எங்கள் உள்கட்டமைப்பின் உயர் கிடைக்கும் தன்மையை உறுதிசெய்யும், எங்களின் அனைத்து போக்குவரத்திற்கும் வழித்தடங்கள், உடல்நலப் பலன்களை வழங்குதல் மற்றும் வேலை செய்யும் வன்பொருள் ஒன்றை நாங்கள் பெற்றுள்ளோம். மேலும், இது நீண்ட காலமாக வேலை செய்கிறது: கடந்த 10 ஆண்டுகளில் இது பற்றி எந்த புகாரும் இல்லை. 2018 ஆம் ஆண்டின் தொடக்கத்தில், நாங்கள் ஏற்கனவே வினாடிக்கு 80 புகைப்படங்களை அனுப்பியுள்ளோம். இது எங்களுடைய இரண்டு டேட்டா சென்டர்களில் இருந்தும் 80 ஜிகாபைட் டிராஃபிக் ஆகும்.
ஆனால்…
2018 ஆம் ஆண்டின் தொடக்கத்தில், அட்டவணையில் ஒரு அசிங்கமான படத்தைப் பார்த்தோம்: புகைப்படங்களை அனுப்ப எடுக்கும் நேரம் தெளிவாக அதிகரித்துள்ளது. அது எங்களுக்கு பொருத்தமாக நின்று விட்டது. பிரச்சனை என்னவென்றால், போக்குவரத்து நெரிசலின் போது மட்டுமே இந்த நடத்தை தெரியும் - எங்கள் நிறுவனத்திற்கு இது ஞாயிறு முதல் திங்கள் வரை இரவு. ஆனால் மீதமுள்ள நேரத்தில் கணினி வழக்கம் போல் செயல்பட்டது, தோல்விக்கான அறிகுறிகள் எதுவும் இல்லை.
ஆயினும்கூட, பிரச்சினை தீர்க்கப்பட வேண்டியிருந்தது. சாத்தியமான இடையூறுகளை நாங்கள் கண்டறிந்து அவற்றை அகற்றத் தொடங்கினோம். முதலில், நிச்சயமாக, வெளிப்புற இணைப்புகளை விரிவுபடுத்தினோம், உள் இணைப்புகளின் முழுமையான தணிக்கையை மேற்கொண்டோம், மேலும் சாத்தியமான அனைத்து இடையூறுகளையும் கண்டறிந்தோம். ஆனால் இவை அனைத்தும் ஒரு தெளிவான முடிவைக் கொடுக்கவில்லை, பிரச்சனை மறைந்துவிடவில்லை.
மற்றொரு சாத்தியமான இடையூறு புகைப்பட தற்காலிக சேமிப்புகளின் செயல்திறன் ஆகும். ஒருவேளை பிரச்சனை அவர்களிடமே இருக்கலாம் என்று முடிவு செய்தோம். சரி, நாங்கள் செயல்திறனை விரிவுபடுத்தினோம் - முக்கியமாக புகைப்பட கேச்களில் நெட்வொர்க் போர்ட்கள். ஆனால் மீண்டும் வெளிப்படையான முன்னேற்றம் காணப்படவில்லை. இறுதியில், LTM இன் செயல்திறனில் நாங்கள் அதிக கவனம் செலுத்தினோம், இங்கே வரைபடங்களில் ஒரு சோகமான படத்தைப் பார்த்தோம்: அனைத்து CPU களிலும் சுமை சீராக செல்லத் தொடங்குகிறது, ஆனால் திடீரென்று ஒரு பீடபூமிக்கு வருகிறது. அதே நேரத்தில், LTM ஆனது சுகாதார சோதனைகள் மற்றும் அப்லிங்க்களுக்கு போதுமான அளவில் பதிலளிப்பதை நிறுத்துகிறது மற்றும் அவற்றை தோராயமாக அணைக்கத் தொடங்குகிறது, இது தீவிர செயல்திறன் சிதைவுக்கு வழிவகுக்கிறது.
அதாவது, பிரச்சினையின் மூலத்தை நாங்கள் கண்டறிந்துள்ளோம், தடையை அடையாளம் கண்டுள்ளோம். நாம் என்ன செய்வோம் என்பதை தீர்மானிக்க வேண்டும்.
நாம் செய்யக்கூடிய முதல், மிகத் தெளிவான விஷயம், எப்படியாவது எல்டிஎம்மையே நவீனமயமாக்குவதுதான். ஆனால் இங்கே சில நுணுக்கங்கள் உள்ளன, ஏனெனில் இந்த வன்பொருள் மிகவும் தனித்துவமானது, நீங்கள் அருகிலுள்ள பல்பொருள் அங்காடிக்குச் சென்று அதை வாங்க மாட்டீர்கள். இது ஒரு தனி ஒப்பந்தம், ஒரு தனி உரிம ஒப்பந்தம், இதற்கு நிறைய நேரம் எடுக்கும். இரண்டாவது விருப்பம், நீங்களே சிந்திக்கத் தொடங்குங்கள், உங்கள் சொந்த கூறுகளைப் பயன்படுத்தி உங்கள் சொந்த தீர்வைக் கொண்டு வாருங்கள், முன்னுரிமை திறந்த அணுகல் நிரலைப் பயன்படுத்துங்கள். பயனர்கள் போதுமான புகைப்படங்களைப் பெறாததால், இதற்கு சரியாக எதைத் தேர்ந்தெடுப்போம் மற்றும் இந்த சிக்கலைத் தீர்ப்பதற்கு எவ்வளவு நேரம் செலவிடுவோம் என்பதைத் தீர்மானிப்பது மட்டுமே எஞ்சியுள்ளது. எனவே, இதையெல்லாம் நாம் மிக மிக விரைவாகச் செய்ய வேண்டும் என்று ஒருவர் நேற்று சொல்லலாம்.
"முடிந்தவரை விரைவாக ஏதாவது செய்யுங்கள், எங்களிடம் உள்ள வன்பொருளைப் பயன்படுத்துங்கள்" என்று பணி ஒலித்ததால், நாங்கள் முதலில் நினைத்தோம், முன்பக்கத்தில் இருந்து சில சக்திவாய்ந்த இயந்திரங்களை அகற்றி, Nginx ஐ அங்கே வைக்கவும், அதை எப்படி செய்வது என்பது எங்களுக்குத் தெரியும். வேலை செய்து, வன்பொருள் பயன்படுத்திய அதே தர்க்கத்தை செயல்படுத்த முயற்சிக்கவும். அதாவது, 4 வருடங்களுக்கு முன்பு எப்படி இருந்ததோ அதுபோலவே, எங்களின் ஹார்டுவேரை விட்டு, இன்னும் 10 சர்வர்களை நிறுவி, அவற்றுக்கான வெளிப்புற டொமைன்களை உருவாக்கினோம். இன்னும் குறைவாக, அவர்கள் உள்நாட்டில் எங்கள் பயனர்களின் பிரச்சனையை தீர்த்தனர்.
அதன்படி, தர்க்கம் அப்படியே உள்ளது: நாங்கள் Nginx ஐ நிறுவுகிறோம், அது SSL-ஆஃப்லோட் செய்ய முடியும், எப்படியாவது ரூட்டிங் லாஜிக், ஹெல்த்-செக் ஆகியவற்றை configs இல் நிரல் செய்து, முன்பு இருந்த தர்க்கத்தை நகலெடுக்கலாம்.
configs எழுத உட்காரலாம். முதலில் எல்லாம் மிகவும் எளிமையானது என்று தோன்றியது, ஆனால், துரதிர்ஷ்டவசமாக, ஒவ்வொரு பணிக்கும் கையேடுகளைக் கண்டுபிடிப்பது மிகவும் கடினம். எனவே, "புகைப்படங்களுக்கு Nginx ஐ எவ்வாறு கட்டமைப்பது" என்பதை வெறுமனே கூகிள் செய்வதை நாங்கள் பரிந்துரைக்கவில்லை: அதிகாரப்பூர்வ ஆவணத்தைப் பார்ப்பது நல்லது, இது எந்த அமைப்புகளைத் தொட வேண்டும் என்பதைக் காண்பிக்கும். ஆனால் குறிப்பிட்ட அளவுருவை நீங்களே தேர்வு செய்வது நல்லது. சரி, பின்னர் எல்லாம் எளிது: எங்களிடம் உள்ள சேவையகங்களை நாங்கள் விவரிக்கிறோம், சான்றிதழ்களை விவரிக்கிறோம் ... ஆனால் மிகவும் சுவாரஸ்யமான விஷயம், உண்மையில், ரூட்டிங் லாஜிக் தான்.
முதலில், நாங்கள் எங்கள் இருப்பிடத்தை எளிமையாக விவரிப்பதாகத் தோன்றியது, அதில் உள்ள எங்கள் புகைப்பட கேச் எண்ணைப் பொருத்துகிறோம், எங்கள் கைகள் அல்லது ஜெனரேட்டரைப் பயன்படுத்தி நமக்கு எத்தனை அப்ஸ்ட்ரீம்கள் தேவை என்பதை விவரிக்கிறோம், ஒவ்வொரு அப்ஸ்ட்ரீமிலும் டிராஃபிக் எந்த சேவையகத்தைக் குறிப்பிடுகிறோம். செல், மற்றும் ஒரு காப்பு சர்வர் - பிரதான சேவையகம் கிடைக்கவில்லை என்றால்:
ஆனால், அநேகமாக, எல்லாம் மிகவும் எளிமையானதாக இருந்தால், நாங்கள் வெறுமனே வீட்டிற்குச் சென்று எதுவும் சொல்லாமல் இருப்போம். துரதிர்ஷ்டவசமாக, இயல்புநிலை Nginx அமைப்புகளுடன், பொதுவாக, பல ஆண்டுகால வளர்ச்சியில் உருவாக்கப்பட்டு, இந்தச் சந்தர்ப்பத்திற்கு முற்றிலும் பொருந்தாதவை... config ஆனது இப்படித்தான் இருக்கும்: சில அப்ஸ்ட்ரீம் சர்வரில் கோரிக்கைப் பிழை அல்லது நேரம் முடிந்தால், Nginx எப்போதும் போக்குவரத்தை அடுத்த இடத்திற்கு மாற்றுகிறது. மேலும், முதல் தோல்விக்குப் பிறகு, 10 வினாடிகளுக்குள் சர்வர் தவறுதலாகவும் காலாவதியாகவும் அணைக்கப்படும் - இதை எந்த வகையிலும் உள்ளமைக்க முடியாது. அதாவது, அப்ஸ்ட்ரீம் உத்தரவில் காலாவதி விருப்பத்தை அகற்றினால் அல்லது மீட்டமைத்தால், Nginx இந்த கோரிக்கையைச் செயல்படுத்தாது மற்றும் சில நல்ல பிழையுடன் பதிலளிக்காது என்றாலும், சேவையகம் மூடப்படும்.
இதைத் தவிர்க்க, நாங்கள் இரண்டு விஷயங்களைச் செய்தோம்:
a) அவர்கள் Nginx ஐ கைமுறையாகச் செய்வதைத் தடைசெய்தனர் - துரதிர்ஷ்டவசமாக, இதைச் செய்வதற்கான ஒரே வழி அதிகபட்சம் தோல்வி அமைப்புகளை அமைப்பதுதான்.
b) பிற திட்டங்களில் பின்னணி சுகாதார சோதனைகளைச் செய்ய அனுமதிக்கும் ஒரு தொகுதியைப் பயன்படுத்துகிறோம் என்பதை நினைவில் கொள்கிறோம் - அதற்கேற்ப, விபத்து ஏற்பட்டால் வேலையில்லா நேரம் குறைவாக இருக்கும் வகையில் அடிக்கடி உடல்நலப் பரிசோதனைகளைச் செய்தோம்.
துரதிர்ஷ்டவசமாக, இது எல்லாம் இல்லை, ஏனெனில் இந்த திட்டத்தின் முதல் இரண்டு வார செயல்பாட்டில், TCP உடல்நலம் சரிபார்ப்பும் நம்பத்தகாத விஷயம் என்பதைக் காட்டுகிறது: அப்ஸ்ட்ரீம் சர்வரில் இது Nginx அல்லது D-state இல் Nginx ஆக இருக்காது. இந்த வழக்கில் கர்னல் இணைப்பை ஏற்கும், சுகாதார சோதனை கடந்துவிடும், ஆனால் வேலை செய்யாது. எனவே, இதை உடனடியாக ஹெல்த் செக் http என்று மாற்றி, குறிப்பிட்ட ஒன்றை உருவாக்கினோம், அது 200ஐக் கொடுத்தால், இந்த ஸ்கிரிப்ட்டில் எல்லாம் வேலை செய்யும். நீங்கள் கூடுதல் தர்க்கத்தைச் செய்யலாம் - எடுத்துக்காட்டாக, கேச்சிங் சர்வர்கள் விஷயத்தில், கோப்பு முறைமை சரியாக ஏற்றப்பட்டுள்ளதா என்பதைச் சரிபார்க்கவும்:
வன்பொருள் செய்ததை இந்த நேரத்தில் சுற்று முழுமையாக மீண்டும் செய்தது தவிர, இது எங்களுக்கு பொருந்தும். ஆனால் நாங்கள் சிறப்பாகச் செய்ய விரும்பினோம். முன்னதாக, எங்களிடம் ஒரு காப்புப்பிரதி சேவையகம் இருந்தது, இது மிகவும் நன்றாக இல்லை, ஏனென்றால் உங்களிடம் நூறு சேவையகங்கள் இருந்தால், ஒரே நேரத்தில் பல தோல்வியுற்றால், ஒரு காப்புப்பிரதி சேவையகம் சுமையைச் சமாளிக்க வாய்ப்பில்லை. எனவே, அனைத்து சேவையகங்களிலும் முன்பதிவை விநியோகிக்க முடிவு செய்தோம்: நாங்கள் வேறு ஒரு தனியான அப்ஸ்ட்ரீமை உருவாக்கி, அங்குள்ள அனைத்து சர்வர்களையும் அவர்கள் வழங்கக்கூடிய சுமைக்கு ஏற்ப குறிப்பிட்ட அளவுருக்களுடன் எழுதி, முன்பு எங்களிடம் இருந்த அதே சுகாதார சோதனைகளைச் சேர்த்துள்ளோம்:
ஒரு அப்ஸ்ட்ரீமிற்குள் மற்றொரு அப்ஸ்ட்ரீமிற்குச் செல்வது சாத்தியமில்லை என்பதால், சரியான, தேவையான புகைப்படத் தற்காலிகச் சேமிப்பை நாம் பதிவுசெய்த பிரதான அப்ஸ்ட்ரீம் கிடைக்கவில்லை என்றால், பிழை_பக்கம் வழியாக ஃபால்பேக்கிற்குச் சென்றோம். நாங்கள் காப்புப்பிரதி மேல்நிலைக்கு சென்ற இடம்:
உண்மையில் நான்கு சேவையகங்களைச் சேர்ப்பதன் மூலம், இது எங்களுக்குக் கிடைத்தது: நாங்கள் சுமையின் ஒரு பகுதியை மாற்றினோம் - நாங்கள் அதை LTM இலிருந்து இந்த சேவையகங்களுக்கு அகற்றி, நிலையான வன்பொருள் மற்றும் மென்பொருளைப் பயன்படுத்தி அதே தர்க்கத்தை அங்கு செயல்படுத்தினோம், மேலும் இந்த சேவையகங்கள் முடிந்த போனஸை உடனடியாகப் பெற்றோம். அளவிடப்படும், ஏனெனில் அவை தேவையான அளவு வழங்கப்படலாம். சரி, ஒரே எதிர்மறை என்னவென்றால், வெளிப்புற பயனர்களுக்கான அதிக கிடைக்கும் தன்மையை நாங்கள் இழந்துவிட்டோம். ஆனால் அந்த நேரத்தில் நாங்கள் இதை தியாகம் செய்ய வேண்டியிருந்தது, ஏனென்றால் பிரச்சினையை உடனடியாக தீர்க்க வேண்டியது அவசியம். எனவே, சுமையின் ஒரு பகுதியை நாங்கள் அகற்றினோம், அந்த நேரத்தில் அது சுமார் 40% ஆக இருந்தது, LTM நன்றாக இருந்தது, உண்மையில் சிக்கல் தொடங்கிய இரண்டு வாரங்களுக்குப் பிறகு, நாங்கள் வினாடிக்கு 45k கோரிக்கைகளை அனுப்பத் தொடங்கினோம், ஆனால் 55k. உண்மையில், நாங்கள் 20% வளர்ந்தோம் - இது தெளிவாக நாங்கள் பயனருக்கு வழங்காத போக்குவரத்து. அதன் பிறகு, மீதமுள்ள சிக்கலை எவ்வாறு தீர்ப்பது என்பது பற்றி அவர்கள் சிந்திக்கத் தொடங்கினர் - அதிக வெளிப்புற அணுகலை உறுதிப்படுத்த.
எங்களிடம் சிறிது இடைநிறுத்தம் இருந்தது, இதன் போது நாங்கள் இதற்கு என்ன தீர்வைப் பயன்படுத்துவோம் என்று விவாதித்தோம். DNS ஐப் பயன்படுத்தி நம்பகத்தன்மையை உறுதி செய்வதற்கான திட்டங்கள் இருந்தன, சில வீட்டில் எழுதப்பட்ட ஸ்கிரிப்ட்கள், டைனமிக் ரூட்டிங் நெறிமுறைகளைப் பயன்படுத்துதல் ... பல விருப்பங்கள் இருந்தன, ஆனால் உண்மையிலேயே நம்பகமான புகைப்படங்களை வழங்குவதற்கு, இதை கண்காணிக்கும் மற்றொரு லேயரை நீங்கள் அறிமுகப்படுத்த வேண்டும் என்பது ஏற்கனவே தெளிவாகிவிட்டது. . இந்த இயந்திரங்களை புகைப்பட இயக்குநர்கள் என்று அழைத்தோம். நாங்கள் நம்பியிருந்த மென்பொருள் Keepalived:
தொடங்குவதற்கு, Keepalived எதைக் கொண்டுள்ளது? முதலாவது VRRP நெறிமுறை, நெட்வொர்க்கர்களுக்கு பரவலாகத் தெரியும், இது வாடிக்கையாளர்கள் இணைக்கும் வெளிப்புற IP முகவரிக்கு தவறு சகிப்புத்தன்மையை வழங்கும் நெட்வொர்க் உபகரணங்களில் அமைந்துள்ளது. இரண்டாவது பகுதி IPVS, IP மெய்நிகர் சேவையகம், புகைப்பட ரவுட்டர்களுக்கு இடையில் சமநிலைப்படுத்துவதற்கும் இந்த மட்டத்தில் தவறு சகிப்புத்தன்மையை உறுதி செய்வதற்கும் ஆகும். மூன்றாவது - சுகாதார சோதனைகள்.
முதல் பகுதியுடன் ஆரம்பிக்கலாம்: VRRP - அது எப்படி இருக்கும்? ஒரு குறிப்பிட்ட மெய்நிகர் ஐபி உள்ளது, இது dns badoocdn.com இல் உள்ளீடு உள்ளது, அங்கு வாடிக்கையாளர்கள் இணைக்கின்றனர். ஒரு கட்டத்தில், ஒரு சர்வரில் எங்களிடம் ஐபி முகவரி உள்ளது. விஆர்ஆர்பி நெறிமுறையைப் பயன்படுத்தி சேவையகங்களுக்கிடையில் Keepalived பாக்கெட்டுகள் இயங்குகின்றன, மேலும் ரேடாரிலிருந்து மாஸ்டர் மறைந்துவிட்டால் - சேவையகம் மறுதொடக்கம் செய்யப்பட்டுள்ளது அல்லது வேறு ஏதேனும் இருந்தால், காப்புப்பிரதி சேவையகம் தானாகவே இந்த ஐபி முகவரியை எடுக்கும் - கைமுறை செயல்கள் தேவையில்லை. முதன்மை மற்றும் காப்புப்பிரதிக்கு இடையே உள்ள வேறுபாடு முக்கியமாக முன்னுரிமை: அது அதிகமாக இருந்தால், இயந்திரம் ஒரு மாஸ்டராக மாறும் வாய்ப்பு அதிகம். மிகப் பெரிய நன்மை என்னவென்றால், நீங்கள் சேவையகத்திலேயே ஐபி முகவரிகளை உள்ளமைக்க வேண்டிய அவசியமில்லை, அவற்றை உள்ளமைவில் விவரித்தால் போதும், மேலும் ஐபி முகவரிகளுக்கு சில தனிப்பயன் ரூட்டிங் விதிகள் தேவைப்பட்டால், இது நேரடியாக கட்டமைப்பில் விவரிக்கப்பட்டுள்ளது. VRRP தொகுப்பில் விவரிக்கப்பட்டுள்ள அதே தொடரியல். நீங்கள் அறிமுகமில்லாத விஷயங்களைச் சந்திக்க மாட்டீர்கள்.
இது நடைமுறையில் எப்படி இருக்கும்? சேவையகங்களில் ஒன்று தோல்வியுற்றால் என்ன ஆகும்? மாஸ்டர் மறைந்தவுடன், எங்கள் காப்புப்பிரதி விளம்பரங்களைப் பெறுவதை நிறுத்தி, தானாகவே மாஸ்டர் ஆகிறது. சிறிது நேரம் கழித்து, நாங்கள் மாஸ்டரை சரிசெய்தோம், மறுதொடக்கம் செய்தோம், Keepalived ஐ உயர்த்தினோம் - காப்புப்பிரதியை விட விளம்பரங்கள் அதிக முன்னுரிமையுடன் வருகின்றன, மேலும் காப்புப்பிரதி தானாகவே திரும்பும், IP முகவரிகளை நீக்குகிறது, கைமுறை செயல்கள் எதுவும் செய்ய வேண்டியதில்லை.
எனவே, வெளிப்புற ஐபி முகவரியின் தவறு சகிப்புத்தன்மையை நாங்கள் உறுதி செய்துள்ளோம். அடுத்த பகுதி, வெளிப்புற ஐபி முகவரியிலிருந்து ஏற்கனவே நிறுத்தப்படும் புகைப்பட ரவுட்டர்கள் வரை போக்குவரத்தை எப்படியாவது சமன் செய்வது. சமநிலை நெறிமுறைகளுடன் எல்லாம் மிகவும் தெளிவாக உள்ளது. இது ஒரு எளிய ரவுண்ட்-ராபின் அல்லது சற்று சிக்கலான விஷயங்கள், wrr, பட்டியல் இணைப்பு மற்றும் பல. இது அடிப்படையில் ஆவணத்தில் விவரிக்கப்பட்டுள்ளது, சிறப்பு எதுவும் இல்லை. ஆனால் டெலிவரி முறை... ஏன் அவற்றில் ஒன்றைத் தேர்ந்தெடுத்தோம் என்பதை இங்கே விரிவாகப் பார்ப்போம். இவை NAT, Direct Routing மற்றும் TUN. உண்மை என்னவென்றால், தளங்களிலிருந்து 100 ஜிகாபிட் போக்குவரத்தை உடனடியாக வழங்க திட்டமிட்டுள்ளோம். நீங்கள் மதிப்பிட்டால், உங்களுக்கு 10 ஜிகாபிட் கார்டுகள் தேவை, இல்லையா? ஒரு சேவையகத்தில் 10 ஜிகாபிட் கார்டுகள் ஏற்கனவே "நிலையான உபகரணங்கள்" என்ற எங்கள் கருத்துக்கு அப்பாற்பட்டவை. பின்னர் நாங்கள் சில போக்குவரத்தை மட்டும் கொடுக்கவில்லை, புகைப்படங்களை வழங்குகிறோம் என்பதை நினைவில் கொள்கிறோம்.
என்ன விசேஷம்? - உள்வரும் மற்றும் வெளிச்செல்லும் போக்குவரத்திற்கு இடையே மிகப்பெரிய வேறுபாடு. உள்வரும் போக்குவரத்து மிகவும் சிறியது, வெளிச்செல்லும் போக்குவரத்து மிகவும் பெரியது:
இந்த வரைபடங்களைப் பார்த்தால், இயக்குனர் வினாடிக்கு சுமார் 200 எம்பி பெறுகின்ற தருணத்தில், இது மிகவும் சாதாரணமான நாள். வினாடிக்கு 4,500 MB திரும்பக் கொடுக்கிறோம், எங்கள் விகிதம் தோராயமாக 1/22. 22 பணியாளர் சேவையகங்களுக்கு வெளிச்செல்லும் போக்குவரத்தை முழுமையாக வழங்க, இந்த இணைப்பை ஏற்கும் ஒன்று மட்டுமே எங்களுக்குத் தேவை என்பது ஏற்கனவே தெளிவாக உள்ளது. இங்குதான் நேரடி ரூட்டிங் அல்காரிதம் நம் உதவிக்கு வருகிறது.
அது பார்க்க எப்படி இருக்கிறது? எங்கள் புகைப்பட இயக்குனர், அவரது அட்டவணையின்படி, புகைப்பட திசைவிகளுக்கு இணைப்புகளை அனுப்புகிறார். ஆனால் புகைப்பட திசைவிகள் திரும்பும் போக்குவரத்தை நேரடியாக இணையத்திற்கு அனுப்புகின்றன, கிளையண்டிற்கு அனுப்புகின்றன, அது புகைப்பட இயக்குனர் மூலம் திரும்பிச் செல்லாது, எனவே, குறைந்தபட்ச எண்ணிக்கையிலான இயந்திரங்களுடன், முழுமையான தவறு சகிப்புத்தன்மை மற்றும் அனைத்து போக்குவரத்தையும் உந்தி உறுதிசெய்கிறோம். கட்டமைப்புகளில் இது போல் தெரிகிறது: நாங்கள் அல்காரிதத்தைக் குறிப்பிடுகிறோம், எங்கள் விஷயத்தில் இது ஒரு எளிய rr, நேரடி ரூட்டிங் முறையை வழங்கவும், பின்னர் அனைத்து உண்மையான சேவையகங்களையும் பட்டியலிடத் தொடங்குகிறோம், அவற்றில் எத்தனை உள்ளன. இது போக்குவரத்தை தீர்மானிக்கும். எங்களிடம் இன்னும் ஒன்று அல்லது இரண்டு சேவையகங்கள் அல்லது பல சேவையகங்கள் இருந்தால், அத்தகைய தேவை எழுகிறது - நாங்கள் இந்த பகுதியை கட்டமைப்பில் சேர்ப்போம், அதிகம் கவலைப்பட வேண்டாம். உண்மையான சேவையகங்களின் பக்கத்திலிருந்து, புகைப்பட திசைவியின் பக்கத்திலிருந்து, இந்த முறைக்கு மிகக் குறைந்த கட்டமைப்பு தேவைப்படுகிறது, இது ஆவணத்தில் சரியாக விவரிக்கப்பட்டுள்ளது, மேலும் அங்கு எந்த ஆபத்துகளும் இல்லை.
குறிப்பாக நல்ல விஷயம் என்னவென்றால், அத்தகைய தீர்வு உள்ளூர் நெட்வொர்க்கின் தீவிர மறுவடிவமைப்பைக் குறிக்கவில்லை; இது எங்களுக்கு முக்கியமானது; இதை நாங்கள் குறைந்த செலவில் தீர்க்க வேண்டியிருந்தது. நீங்கள் பார்த்தால் , பிறகு அது எப்படி இருக்கும் என்று பார்ப்போம். இங்கே எங்களிடம் ஒரு குறிப்பிட்ட மெய்நிகர் சேவையகம் உள்ளது, போர்ட் 443 இல், கேட்கிறது, இணைப்பை ஏற்றுக்கொள்கிறது, அனைத்து வேலை செய்யும் சேவையகங்களும் பட்டியலிடப்பட்டுள்ளன, மேலும் இணைப்பு, கொடுக்க அல்லது எடுக்க, அதே போல் இருப்பதை நீங்கள் பார்க்கலாம். அதே விர்ச்சுவல் சர்வரில் உள்ள புள்ளிவிவரங்களைப் பார்த்தால், எங்களிடம் உள்வரும் பாக்கெட்டுகள், உள்வரும் இணைப்புகள் உள்ளன, ஆனால் வெளிச்செல்லும் எதுவும் இல்லை. வெளிச்செல்லும் இணைப்புகள் நேரடியாக வாடிக்கையாளருக்குச் செல்லும். சரி, எங்களால் சமநிலையை மீற முடிந்தது. இப்போது, எங்கள் புகைப்பட ரவுட்டர்களில் ஒன்று தோல்வியுற்றால் என்ன ஆகும்? எல்லாவற்றிற்கும் மேலாக, இரும்பு இரும்பு. இது கர்னல் பீதியில் செல்லலாம், அது உடைந்து போகலாம், மின்சாரம் எரிந்து போகலாம். எதுவும். அதனால்தான் சுகாதார சோதனைகள் தேவைப்படுகின்றன. வணிக தர்க்கத்தை சரிபார்க்கும் சில வீட்டில் எழுதப்பட்ட ஸ்கிரிப்ட்கள் வரை, துறைமுகம் எவ்வாறு திறக்கப்பட்டுள்ளது அல்லது மிகவும் சிக்கலான ஒன்றைச் சரிபார்ப்பது போன்ற எளிமையானதாக இருக்கலாம்.
நடுவில் எங்கோ நிறுத்திவிட்டோம்: ஒரு குறிப்பிட்ட இடத்திற்கு எங்களிடம் https கோரிக்கை உள்ளது, ஸ்கிரிப்ட் என்று அழைக்கப்படுகிறது, அது 200வது பதிலுடன் பதிலளித்தால், இந்த சர்வரில் எல்லாம் நன்றாக இருக்கிறது, அது உயிருடன் உள்ளது மற்றும் அதை இயக்க முடியும் என்று நாங்கள் நம்புகிறோம். எளிதாக.
இது, மீண்டும், நடைமுறையில் எப்படி இருக்கிறது? பராமரிப்புக்காக சேவையகத்தை அணைப்போம் - எடுத்துக்காட்டாக, BIOS ஐ ஒளிரச் செய்வது. பதிவுகளில், எங்களுக்கு உடனடியாக ஒரு காலக்கெடு உள்ளது, முதல் வரியைப் பார்க்கிறோம், பின்னர் மூன்று முயற்சிகளுக்குப் பிறகு அது "தோல்வியுற்றது" எனக் குறிக்கப்படுகிறது, மேலும் அது பட்டியலிலிருந்து வெறுமனே அகற்றப்படும்.
இரண்டாவது நடத்தை விருப்பமும் சாத்தியமாகும், VS வெறுமனே பூஜ்ஜியமாக அமைக்கப்பட்டால், ஆனால் புகைப்படம் திரும்பினால், இது சரியாக வேலை செய்யாது. சேவையகம் வருகிறது, Nginx அங்கு தொடங்குகிறது, உடல்நலம் சரிபார்ப்பு உடனடியாக இணைப்பு வேலை செய்கிறது, எல்லாம் நன்றாக உள்ளது என்பதை புரிந்துகொள்கிறது, மேலும் சேவையகம் எங்கள் பட்டியலில் தோன்றும், மேலும் சுமை உடனடியாக அதைப் பயன்படுத்தத் தொடங்குகிறது. கடமை நிர்வாகியிடமிருந்து கைமுறையான நடவடிக்கைகள் எதுவும் தேவையில்லை. இரவில் சர்வர் மறுதொடக்கம் செய்யப்பட்டது - கண்காணிப்புத் துறை இதைப் பற்றி இரவில் எங்களை அழைப்பதில்லை. இது நடந்தது, எல்லாம் நன்றாக இருக்கிறது என்று அவர்கள் உங்களுக்குத் தெரிவிக்கிறார்கள்.
எனவே, மிகவும் எளிமையான முறையில், குறைந்த எண்ணிக்கையிலான சேவையகங்களின் உதவியுடன், வெளிப்புற தவறு சகிப்புத்தன்மையின் சிக்கலை நாங்கள் தீர்த்தோம்.
சொல்ல வேண்டியது என்னவென்றால், இவை அனைத்தும் நிச்சயமாக கண்காணிக்கப்பட வேண்டும். தனித்தனியாக, Keepalivede, நீண்ட காலத்திற்கு முன்பு எழுதப்பட்ட மென்பொருளாக, DBus, SMTP, SNMP மற்றும் நிலையான Zabbix வழியாக காசோலைகளைப் பயன்படுத்தி அதைக் கண்காணிக்க பல வழிகளைக் கொண்டுள்ளது என்பதை கவனத்தில் கொள்ள வேண்டும். கூடுதலாக, கிட்டத்தட்ட ஒவ்வொரு தும்மலுக்கும் கடிதங்களை எழுதுவது அவருக்குத் தெரியும், மேலும் நேர்மையாகச் சொல்வதானால், சில சமயங்களில் அதை அணைக்க நினைத்தோம், ஏனென்றால் அவர் எந்தவொரு போக்குவரத்து மாறுதலுக்கும், மாறுவதற்கும், ஒவ்வொரு ஐபி இணைப்பிற்கும் நிறைய கடிதங்களை எழுதுகிறார். மற்றும் பல . நிச்சயமாக, நிறைய சேவையகங்கள் இருந்தால், இந்த கடிதங்களால் உங்களை மூழ்கடிக்கலாம். நிலையான முறைகளைப் பயன்படுத்தி புகைப்பட திசைவிகளில் nginx ஐ நாங்கள் கண்காணிக்கிறோம், மேலும் வன்பொருள் கண்காணிப்பு மறைந்துவிடவில்லை. நிச்சயமாக, நாங்கள் இன்னும் இரண்டு விஷயங்களை அறிவுறுத்துவோம்: முதலாவதாக, வெளிப்புற சுகாதார சோதனைகள் மற்றும் கிடைக்கும் தன்மை, ஏனென்றால் எல்லாம் வேலை செய்தாலும், உண்மையில், வெளிப்புற வழங்குநர்களுடனான சிக்கல்கள் அல்லது மிகவும் சிக்கலான ஏதாவது காரணமாக பயனர்கள் புகைப்படங்களைப் பெறவில்லை. வேறொரு நெட்வொர்க்கில், அமேசானில் அல்லது வேறு எங்காவது, உங்கள் சேவையகங்களை வெளியில் இருந்து பிங் செய்யக்கூடிய ஒரு தனி இயந்திரத்தை வைத்திருப்பது எப்போதும் மதிப்புக்குரியது, மேலும் தந்திரமான இயந்திர கற்றல் அல்லது எளிய கண்காணிப்பு செய்யத் தெரிந்தவர்களுக்கு, ஒழுங்கின்மை கண்டறிதலைப் பயன்படுத்துவது மதிப்புக்குரியது. , குறைந்த பட்சம் கோரிக்கைகள் கடுமையாக குறைந்துவிட்டதா அல்லது அதற்கு மாறாக அதிகரித்ததா என்பதைக் கண்காணிக்க வேண்டும். இது பயனுள்ளதாகவும் இருக்கலாம்.
சுருக்கமாகச் சொல்வோம்: உண்மையில், நாங்கள் இரும்பு உறை தீர்வை மாற்றினோம், இது ஒரு கட்டத்தில் நமக்குப் பொருந்தாது, எல்லாவற்றையும் ஒரே மாதிரியாகச் செய்யும் மிகவும் எளிமையான அமைப்புடன், அதாவது, இது HTTPS போக்குவரத்தை நிறுத்துவதோடு மேலும் ஸ்மார்ட் ரூட்டிங் வழங்குகிறது. தேவையான சுகாதார சோதனைகள். இந்த அமைப்பின் ஸ்திரத்தன்மையை நாங்கள் அதிகரித்துள்ளோம், அதாவது, ஒவ்வொரு லேயருக்கும் இன்னும் அதிக அளவில் கிடைக்கும் தன்மையை நாங்கள் பெற்றுள்ளோம், மேலும் ஒவ்வொரு லேயரிலும் அனைத்தையும் அளவிடுவது மிகவும் எளிதானது என்ற போனஸ் எங்களிடம் உள்ளது, ஏனெனில் இது நிலையான மென்பொருளுடன் கூடிய நிலையான வன்பொருள், அதாவது. , சாத்தியமான சிக்கல்களைக் கண்டறிவதை எளிதாக்கியுள்ளோம்.
நாம் என்ன முடிவுக்கு வந்தோம்? 2018 ஜனவரி விடுமுறையின் போது எங்களுக்கு ஒரு பிரச்சனை ஏற்பட்டது. இந்தத் திட்டத்தைச் செயல்படுத்திய முதல் ஆறு மாதங்களில், LTM இலிருந்து அனைத்துப் போக்குவரத்தையும் அகற்றுவதற்காக, எல்லாப் போக்குவரத்திற்கும் இதை விரிவுபடுத்தினோம், ஒரு டேட்டா சென்டரில் 40 ஜிகாபிட்களில் இருந்து 60 ஜிகாபிட்கள் வரை டிராஃபிக்கில் மட்டுமே வளர்ந்தோம், அதே நேரத்தில் 2018 ஆம் ஆண்டு முழுவதும் வினாடிக்கு கிட்டத்தட்ட மூன்று மடங்கு அதிகமான புகைப்படங்களை அனுப்ப முடிந்தது.
ஆதாரம்: www.habr.com