Mail.ru கிளவுட் சொல்யூஷன்ஸ் பிளாட்ஃபார்மில் பிழை-சகிப்புத்தன்மை கொண்ட வலை கட்டமைப்பு எவ்வாறு செயல்படுத்தப்படுகிறது

வணக்கம், ஹப்ர்! நான் ஆர்டெம் கரமிஷேவ், சிஸ்டம் நிர்வாகக் குழுவின் தலைவர் Mail.Ru Cloud Solutions (MCS). கடந்த ஆண்டில் பல புதிய தயாரிப்புகளை அறிமுகப்படுத்தியுள்ளோம். API சேவைகள் எளிதில் அளவிடக்கூடியவை, தவறுகளை பொறுத்துக்கொள்ளக்கூடியவை மற்றும் பயனர் சுமையின் விரைவான வளர்ச்சிக்கு தயாராக இருப்பதை உறுதிசெய்ய விரும்புகிறோம். எங்கள் இயங்குதளம் OpenStack இல் செயல்படுத்தப்படுகிறது, மேலும் பிழை-சகிப்புத்தன்மை கொண்ட அமைப்பைப் பெறுவதற்கு நாம் என்ன கூறு தவறு சகிப்புத்தன்மை சிக்கல்களைத் தீர்க்க வேண்டும் என்பதை நான் உங்களுக்குச் சொல்ல விரும்புகிறேன். OpenStack இல் தயாரிப்புகளை உருவாக்குபவர்களுக்கும் இது சுவாரஸ்யமாக இருக்கும் என்று நினைக்கிறேன்.

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

இந்தக் கதையின் வீடியோ பதிப்பு, இதன் முதன்மை ஆதாரம், ஆல் ஏற்பாடு செய்யப்பட்ட Uptime day 4 மாநாட்டின் அறிக்கையாகும் இட்சும்மா, நீங்கள் பார்க்க முடியும் Uptime Community YouTube சேனலில்.

இயற்பியல் கட்டமைப்பின் நெகிழ்ச்சி

MCS கிளவுட்டின் பொதுப் பகுதியானது இப்போது இரண்டு அடுக்கு III தரவு மையங்களை அடிப்படையாகக் கொண்டது, அவற்றுக்கிடையே அதன் சொந்த டார்க் ஃபைபர் உள்ளது, வெவ்வேறு வழிகளில் இயற்பியல் மட்டத்தில் 200 Gbit/s செயல்திறன் உள்ளது. அடுக்கு III இயற்பியல் உள்கட்டமைப்பிற்கு தேவையான அளவு தவறு சகிப்புத்தன்மையை வழங்குகிறது.

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

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

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

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

இயற்பியல் உள்கட்டமைப்பின் மீள்தன்மை

பயன்பாட்டு நிலை தவறு சகிப்புத்தன்மைக்கு நாம் எதைப் பயன்படுத்துகிறோம்

எங்கள் சேவை பல ஓப்பன்சோர்ஸ் கூறுகளில் கட்டமைக்கப்பட்டுள்ளது.

ExaBGP BGP அடிப்படையிலான டைனமிக் ரூட்டிங் நெறிமுறையைப் பயன்படுத்தி பல செயல்பாடுகளைச் செயல்படுத்தும் ஒரு சேவையாகும். பயனர்கள் API ஐ அணுகும் எங்கள் ஏற்புப்பட்டியலில் உள்ள IP முகவரிகளை விளம்பரப்படுத்த நாங்கள் அதை தீவிரமாகப் பயன்படுத்துகிறோம்.

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

API பயன்பாடு - பைத்தானில் எழுதப்பட்ட ஒரு வலை பயன்பாடு, அதன் மூலம் பயனர் தனது உள்கட்டமைப்பு மற்றும் அவரது சேவையை நிர்வகிக்கிறார்.

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

நிலையான OpenStack பயன்பாட்டு கட்டமைப்பு

ஓபன்ஸ்டாக்கிற்காக உருவாக்கப்பட்ட பெரும்பாலான சேவைகள் ஒற்றை முன்னுதாரணத்தைப் பின்பற்ற முயற்சி செய்கின்றன. ஒரு சேவை பொதுவாக 2 பகுதிகளைக் கொண்டுள்ளது: API மற்றும் தொழிலாளர்கள் (பின்தளத்தில் செயல்படுத்துபவர்கள்). ஒரு விதியாக, API என்பது பைத்தானில் உள்ள ஒரு WSGI பயன்பாடாகும், இது ஒரு சுயாதீனமான செயல்முறையாக (டீமான்) அல்லது ஆயத்தமான Nginx அல்லது Apache இணைய சேவையகத்தைப் பயன்படுத்துகிறது. API ஆனது பயனர் கோரிக்கையைச் செயல்படுத்துகிறது மற்றும் செயல்பாட்டிற்கான பணியாளர் பயன்பாட்டிற்கு மேலதிக வழிமுறைகளை அனுப்புகிறது. பரிமாற்றம் ஒரு செய்தி தரகரைப் பயன்படுத்தி நிகழ்கிறது, பொதுவாக RabbitMQ, மற்றவை மோசமாக ஆதரிக்கப்படுகின்றன. செய்திகள் தரகரை அடையும் போது, ​​அவை தொழிலாளர்களால் செயலாக்கப்பட்டு, தேவைப்பட்டால், பதிலை அளிக்கும்.

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

பணியாளர் பயன்பாடுகளின் எண்ணிக்கை வரம்பற்றது, எனவே செயல்திறன் மற்றும் தவறு சகிப்புத்தன்மையை அதிகரிக்க ஏபிஐ எளிதாக பேலன்சர்களுக்குப் பின்னால் கிடைமட்டமாக அளவிட முடியும்.

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

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

முழு திட்டத்திலும் பலவீனமான புள்ளி RabbitMQ மற்றும் MariaDB ஆகும். அவர்களின் கட்டிடக்கலை ஒரு தனி கட்டுரைக்கு தகுதியானது, இந்த கட்டுரையில் நான் API தவறு சகிப்புத்தன்மையில் கவனம் செலுத்த விரும்புகிறேன்.

ஓபன்ஸ்டாக் அப்ளிகேஷன் ஆர்கிடெக்சர். மேகக்கணி தளத்தின் சமநிலை மற்றும் தவறு சகிப்புத்தன்மை

ExaBGPஐப் பயன்படுத்தி HAProxy balancerஐ தவறு-சகிப்புத்தன்மை கொண்டதாக மாற்றுதல்

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

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

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

ExaBGP+HAProxy திட்டம்

1. தேவையான மென்பொருளான ExaBGP மற்றும் HAProxy ஆகியவற்றை மூன்று சேவையகங்களில் நிறுவுகிறோம்.
2. ஒவ்வொரு சர்வரிலும் ஒரு லூப்பேக் இடைமுகத்தை உருவாக்குகிறோம்.
3. மூன்று சேவையகங்களிலும் இந்த இடைமுகத்திற்கு ஒரே வெள்ளை ஐபி முகவரியை நாங்கள் ஒதுக்குகிறோம்.
4. ஒரு வெள்ளை ஐபி முகவரி ExaBGP வழியாக இணையத்தில் விளம்பரப்படுத்தப்படுகிறது.

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

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

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

HAProxy பேலன்சர்களின் தவறு சகிப்புத்தன்மை

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

DNS மற்றும் BGP அடிப்படையில் சமநிலைப்படுத்துதல்

எங்கள் HAProxyக்கான சுமை சமநிலையின் சிக்கல் தீர்க்கப்படாமல் உள்ளது. இருப்பினும், நாங்கள் இங்கே செய்ததைப் போல, அதை மிகவும் எளிமையாக தீர்க்க முடியும்.

மூன்று சேவையகங்களை சமநிலைப்படுத்த உங்களுக்கு 3 வெள்ளை IP முகவரிகள் மற்றும் நல்ல பழைய DNS தேவைப்படும். இந்த முகவரிகள் ஒவ்வொன்றும் ஒவ்வொரு HAProxy இன் லூப்பேக் இடைமுகத்தில் தீர்மானிக்கப்பட்டு இணையத்தில் விளம்பரப்படுத்தப்படும்.

OpenStack இல், வளங்களை நிர்வகிக்க, ஒரு சேவை அடைவு பயன்படுத்தப்படுகிறது, இது ஒரு குறிப்பிட்ட சேவையின் இறுதிப்புள்ளி API ஐக் குறிப்பிடுகிறது. இந்த கோப்பகத்தில் நாங்கள் ஒரு டொமைன் பெயரை பதிவு செய்கிறோம் - public.infra.mail.ru, இது மூன்று வெவ்வேறு ஐபி முகவரிகளால் DNS மூலம் தீர்க்கப்படுகிறது. இதன் விளைவாக, டிஎன்எஸ் வழியாக மூன்று முகவரிகளுக்கு இடையில் சுமை விநியோகத்தைப் பெறுகிறோம்.

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

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

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

DNS + BGP அடிப்படையில் HAProxy ஐ சமநிலைப்படுத்துதல்

ExaBGP மற்றும் HAProxy இடையேயான தொடர்பு

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

எனவே, முந்தைய திட்டத்தை விரிவுபடுத்தி, ExaBGP மற்றும் HAProxy இடையே இதயத் துடிப்பை செயல்படுத்தினோம். இது ExaBGP மற்றும் HAProxy ஆகியவற்றுக்கு இடையேயான தொடர்புகளின் மென்பொருள் செயலாக்கமாகும், ExaBGP ஆனது பயன்பாடுகளின் நிலையைச் சரிபார்க்க தனிப்பயன் ஸ்கிரிப்ட்களைப் பயன்படுத்தும் போது.

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

HAProxy சுகாதார சோதனை

HAProxy Peers: அமர்வு ஒத்திசைவு

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

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

இந்த பொறிமுறையின் கிளையன்ட் அமர்வுகளைச் சேமிக்க HAProxy ஸ்டிக்-டேபிள்களைப் பயன்படுத்துகிறது. அவை கிளையண்டின் அசல் IP முகவரி, தேர்ந்தெடுக்கப்பட்ட இலக்கு முகவரி (பின்னணி) மற்றும் சில சேவைத் தகவலைச் சேமிக்கின்றன. பொதுவாக, மூல-ஐபி + இலக்கு-ஐபி ஜோடியைச் சேமிக்க ஸ்டிக் டேபிள்கள் பயன்படுத்தப்படுகின்றன, இது மற்றொரு பேலன்சருக்கு மாறும்போது பயனர் அமர்வு சூழலை மாற்ற முடியாத பயன்பாடுகளுக்கு குறிப்பாக பயனுள்ளதாக இருக்கும், எடுத்துக்காட்டாக, ரவுண்ட்ராபின் சமநிலை பயன்முறையில்.

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

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

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

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

மூன்று HAProxy நிகழ்வுகளுக்கு இடையே பியர் டேபிள்களின் இயக்கத்தை படம் திட்டவட்டமாக காட்டுகிறது, இதை எவ்வாறு கட்டமைக்க முடியும் என்பது குறித்து ஒரு கட்டமைப்பு முன்மொழியப்பட்டுள்ளது:

HAProxy Peers (அமர்வு ஒத்திசைவு)

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

ஒரே வாடிக்கையாளரிடமிருந்து ஒரே நேரத்தில் வரும் கோரிக்கைகளின் எண்ணிக்கையை வரம்பிடுதல்

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

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

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

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

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

பயனர்கள் கவனிக்காமல் உங்கள் கோட்பேஸை எவ்வாறு புதுப்பிப்பது

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

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

இந்த சிக்கலை தீர்க்க, பேலன்சரின் கட்டுப்பாடு மற்றும் சேவைகளை "சரியான" பணிநிறுத்தம் ஆகியவற்றை உறுதி செய்வது அவசியம்:

• HAProxy விஷயத்தில், கட்டுப்பாடு ஒரு புள்ளிவிவரக் கோப்பு மூலம் செய்யப்படுகிறது, இது அடிப்படையில் ஒரு சாக்கெட் மற்றும் HAProxy கட்டமைப்பில் வரையறுக்கப்படுகிறது. அதற்கு நீங்கள் stdio வழியாக கட்டளைகளை அனுப்பலாம். ஆனால் எங்களின் முக்கிய உள்ளமைவுக் கட்டுப்பாட்டுக் கருவி அன்சிபிள் ஆகும், எனவே இது HAProxy ஐ நிர்வகிப்பதற்கான உள்ளமைக்கப்பட்ட தொகுதியைக் கொண்டுள்ளது. நாங்கள் தீவிரமாகப் பயன்படுத்துகிறோம்.
• எங்களின் பெரும்பாலான API மற்றும் Engine சேவைகள் அழகான பணிநிறுத்தம் தொழில்நுட்பங்களை ஆதரிக்கின்றன: பணிநிறுத்தம் செய்யும் போது, ​​அவை http கோரிக்கையாக இருந்தாலும் அல்லது சில சேவைப் பணியாக இருந்தாலும் தற்போதைய பணி முடிவடையும் வரை காத்திருக்கின்றன. தொழிலாளிக்கும் இதேதான் நடக்கும். அது செய்துகொண்டிருக்கும் அனைத்துப் பணிகளையும் அறிந்து, அனைத்தையும் வெற்றிகரமாக முடித்தவுடன் முடிவடைகிறது.

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

1. டெவலப்பர் புதிய குறியீட்டு தொகுப்பை (எங்களுக்கு இது RPM ஆகும்), தேவ் சூழலில் சோதனை செய்து, கட்டத்தில் சோதனை செய்து, அதை நிலை களஞ்சியத்தில் விடுகிறார்.
2. டெவலப்பர் "கலைப்பொருட்களின்" மிக விரிவான விளக்கத்துடன் வரிசைப்படுத்துவதற்கான பணியை அமைக்கிறார்: புதிய தொகுப்பின் பதிப்பு, புதிய செயல்பாட்டின் விளக்கம் மற்றும் தேவைப்பட்டால் வரிசைப்படுத்தல் பற்றிய பிற விவரங்கள்.
3. கணினி நிர்வாகி புதுப்பிப்பைத் தொடங்குகிறார். அன்சிபிள் பிளேபுக்கைத் தொடங்குகிறது, இது பின்வருவனவற்றைச் செய்கிறது:
   • நிலை களஞ்சியத்திலிருந்து ஒரு தொகுப்பை எடுத்து, தயாரிப்பு களஞ்சியத்தில் தொகுப்பின் பதிப்பைப் புதுப்பிக்க அதைப் பயன்படுத்துகிறது.
   • புதுப்பிக்கப்பட்ட சேவையின் பின்தளங்களின் பட்டியலைத் தொகுக்கிறது.
   • HAProxy இல் புதுப்பிக்கப்பட வேண்டிய முதல் சேவையை நிறுத்தி, அதன் செயல்முறைகள் இயங்கும் வரை காத்திருக்கிறது. அழகான பணிநிறுத்தத்திற்கு நன்றி, தற்போதைய அனைத்து கிளையன்ட் கோரிக்கைகளும் வெற்றிகரமாக முடிவடையும் என்று நாங்கள் நம்புகிறோம்.
   • API மற்றும் பணியாளர்கள் முற்றிலும் நிறுத்தப்பட்டு, HAProxy முடக்கப்பட்ட பிறகு, குறியீடு புதுப்பிக்கப்படும்.
   • அன்சிபிள் சேவைகளை இயக்குகிறது.
   • ஒவ்வொரு சேவைக்கும், குறிப்பிட்ட சில "கைப்பிடிகள்" இழுக்கப்படுகின்றன, அவை பல முன் வரையறுக்கப்பட்ட முக்கிய சோதனைகளில் யூனிட் சோதனையைச் செய்கின்றன. புதிய குறியீட்டின் அடிப்படை சோதனை நடைபெறுகிறது.
   • முந்தைய கட்டத்தில் பிழைகள் எதுவும் காணப்படவில்லை என்றால், பின்தளம் செயல்படுத்தப்படும்.
   • அடுத்த பின்பக்கம் செல்லலாம்.
4. அனைத்து பின்தளங்களும் புதுப்பிக்கப்பட்ட பிறகு, செயல்பாட்டு சோதனைகள் தொடங்கப்படும். அவை காணவில்லை என்றால், டெவலப்பர் அவர் உருவாக்கிய எந்த புதிய செயல்பாட்டையும் பார்க்கிறார்.

இது வரிசைப்படுத்தலை நிறைவு செய்கிறது.

சேவை புதுப்பிப்பு சுழற்சி

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

முடிவுக்கு

பிழை-சகிப்புத்தன்மை கொண்ட WEB கட்டமைப்பைப் பற்றிய எனது சொந்த எண்ணங்களைப் பகிர்ந்துகொள்வதன் மூலம், அதன் முக்கியக் குறிப்புகளை மீண்டும் ஒருமுறை கவனிக்க விரும்புகிறேன்:

• உடல் தவறு சகிப்புத்தன்மை;
• நெட்வொர்க் தவறு சகிப்புத்தன்மை (பேலன்சர்கள், பிஜிபி);
• பயன்படுத்தப்படும் மற்றும் உருவாக்கப்பட்ட மென்பொருளின் தவறு சகிப்புத்தன்மை.

அனைவருக்கும் நிலையான இயக்க நேரம்!

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