ஒன்-கிளவுட் - ஒட்னோக்ளாஸ்னிகியில் உள்ள தரவு மைய நிலை OS

ஐயோ, மக்களே! என் பெயர் ஒலெக் அனஸ்டாசியேவ், நான் பிளாட்ஃபார்ம் குழுவில் ஒட்னோக்ளாஸ்னிகியில் வேலை செய்கிறேன். என்னைத் தவிர, ஒட்னோக்ளாஸ்னிகியில் நிறைய வன்பொருள் வேலை செய்கிறது. எங்களிடம் 500 ஆயிரத்துக்கும் மேற்பட்ட சேவையகங்களுடன் சுமார் 8 ரேக்குகளுடன் நான்கு தரவு மையங்கள் உள்ளன. ஒரு குறிப்பிட்ட கட்டத்தில், ஒரு புதிய மேலாண்மை அமைப்பின் அறிமுகம், உபகரணங்களை மிகவும் திறமையாக ஏற்றுவதற்கும், அணுகல் நிர்வாகத்தை எளிதாக்குவதற்கும், கணினி வளங்களின் (மறு) விநியோகத்தை தானியங்குபடுத்துவதற்கும், புதிய சேவைகளின் துவக்கத்தை விரைவுபடுத்துவதற்கும், பதில்களை விரைவுபடுத்துவதற்கும் அனுமதிக்கும் என்பதை நாங்கள் உணர்ந்தோம். பெரிய அளவிலான விபத்துகளுக்கு.

அதில் என்ன வந்தது?

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

பயனர் கோரிக்கைகள் பிரதான போர்ட்டலின் முனைகளிலும் பெறப்படுகின்றன www.ok.ru, மற்றும் பிறவற்றில், எடுத்துக்காட்டாக இசை API முனைகளில். வணிக தர்க்கத்தை செயலாக்க, அவர்கள் பயன்பாட்டு சேவையகத்தை அழைக்கிறார்கள், இது கோரிக்கையைச் செயலாக்கும்போது, ​​​​தேவையான சிறப்பு மைக்ரோ சர்வீஸ்களை அழைக்கிறது - ஒரு வரைபடம் (சமூக இணைப்புகளின் வரைபடம்), பயனர்-கேச் (பயனர் சுயவிவரங்களின் தற்காலிக சேமிப்பு) போன்றவை.

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

அது ஏன்? இந்த அணுகுமுறை பல நன்மைகளைக் கொண்டுள்ளது:

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

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

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

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

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

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

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

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

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

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

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

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

உங்களிடம் 8 ஆயிரம் சேவையகங்கள் மற்றும் 8-16 ஆயிரம் கொள்கலன்கள் இருக்கும்போது கொள்கலன்களை கைமுறையாக விநியோகிப்பது ஒரு விருப்பமல்ல.

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

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

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

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

ரஸ்ப்ரேடலேனி ரெசுர்சோவ்

இப்போது பல கூட்டாளிகளுக்கு மிகவும் சிக்கலான வள ஒதுக்கீட்டின் சிக்கலைப் பார்ப்போம்.

ஒரு கிளவுட்டில் உள்ள கணினி வளம்:

• ஒரு குறிப்பிட்ட பணியால் பயன்படுத்தப்படும் செயலி சக்தியின் அளவு.
• பணிக்கு கிடைக்கும் நினைவகத்தின் அளவு.
• நெட்வொர்க் போக்குவரத்து. ஒவ்வொரு கூட்டாளிகளும் வரையறுக்கப்பட்ட அலைவரிசையுடன் ஒரு குறிப்பிட்ட பிணைய இடைமுகத்தைக் கொண்டுள்ளனர், எனவே அவை நெட்வொர்க்கில் அனுப்பும் தரவின் அளவைக் கணக்கில் எடுத்துக் கொள்ளாமல் பணிகளை விநியோகிக்க முடியாது.
• வட்டுகள். கூடுதலாக, வெளிப்படையாக, இந்த பணிகளுக்கான இடத்திற்கு, நாங்கள் வட்டு வகையையும் ஒதுக்குகிறோம்: HDD அல்லது SSD. வட்டுகள் ஒரு வினாடிக்கு வரையறுக்கப்பட்ட கோரிக்கைகளை வழங்க முடியும் - IOPS. எனவே, ஒரு வட்டு கையாளக்கூடியதை விட அதிகமான IOPS ஐ உருவாக்கும் பணிகளுக்கு, நாங்கள் "சுழல்களை" ஒதுக்குகிறோம் - அதாவது, பணிக்காக பிரத்தியேகமாக ஒதுக்கப்பட்ட வட்டு சாதனங்கள்.

சில சேவைகளுக்கு, எடுத்துக்காட்டாக, பயனர் தற்காலிக சேமிப்பிற்கு, நாம் நுகரப்படும் ஆதாரங்களை இந்த வழியில் பதிவு செய்யலாம்: 400 செயலி கோர்கள், 2,5 TB நினைவகம், இரு திசைகளிலும் 50 Gbit/s டிராஃபிக், 6 TB HDD இடம் 100 சுழல்களில் அமைந்துள்ளது. அல்லது இது போன்ற மிகவும் பழக்கமான வடிவத்தில்:

alloc:
    cpu: 400
    mem: 2500
    lan_in: 50g
    lan_out: 50g
    hdd:100x6T

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

கூறுகளின் தொடர்புகளின் மிகவும் எளிமைப்படுத்தப்பட்ட வரைபடத்திற்குத் திரும்புவோம், மேலும் விவரங்களுடன் அதை மீண்டும் வரைவோம் - இது போன்றது:

உங்கள் கண்களைக் கவரும்:

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

படத்தை மீண்டும் வரைவோம்:

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

கூடுதல் வரிகளை அகற்றுவதன் மூலம், எங்கள் படத்தின் ஒவ்வொரு முனையையும் ஒரு தட்டையான வடிவத்தில் எழுதலாம்: group1.web.front, api.music.front, user-cache.cache.

இப்படித்தான் “படிநிலை வரிசை” என்ற கருத்துக்கு வருகிறோம். இதற்கு "group1.web.front" போன்ற பெயர் உள்ளது. வளங்கள் மற்றும் பயனர் உரிமைகளுக்கான ஒதுக்கீடு அதற்கு ஒதுக்கப்பட்டுள்ளது. DevOps இன் நபருக்கு வரிசையில் சேவையை அனுப்புவதற்கான உரிமையை நாங்கள் வழங்குவோம், அத்தகைய பணியாளர் வரிசையில் ஏதாவது ஒன்றைத் தொடங்கலாம், மேலும் OpsDev இன் நபருக்கு நிர்வாக உரிமைகள் இருக்கும், இப்போது அவர் வரிசையை நிர்வகிக்கலாம், அங்கு நபர்களை நியமிக்கலாம், இந்த நபர்களுக்கு உரிமைகளை வழங்குதல் போன்றவை. இந்த வரிசையில் இயங்கும் சேவைகள் வரிசையின் ஒதுக்கீட்டிற்குள் இயங்கும். அனைத்து சேவைகளையும் ஒரே நேரத்தில் செயல்படுத்த வரிசையின் கம்ப்யூட்டிங் ஒதுக்கீடு போதுமானதாக இல்லை என்றால், அவை வரிசையாக செயல்படுத்தப்படும், இதனால் வரிசையே உருவாகும்.

சேவைகளை இன்னும் விரிவாகப் பார்ப்போம். ஒரு சேவைக்கு முழுத் தகுதியான பெயர் உள்ளது, அதில் எப்போதும் வரிசையின் பெயர் இருக்கும். பின்னர் முன் இணைய சேவைக்கு பெயர் இருக்கும் சரி-web.group1.web.front. அது அணுகும் பயன்பாட்டு சேவையக சேவை அழைக்கப்படும் ok-app.group1.web.front. ஒவ்வொரு சேவைக்கும் ஒரு மேனிஃபெஸ்ட் உள்ளது, இது குறிப்பிட்ட கணினிகளில் வைப்பதற்கு தேவையான அனைத்து தகவல்களையும் குறிப்பிடுகிறது: இந்த பணி எவ்வளவு வளங்களை பயன்படுத்துகிறது, அதற்கு என்ன கட்டமைப்பு தேவை, எத்தனை பிரதிகள் இருக்க வேண்டும், இந்த சேவையின் தோல்விகளைக் கையாளும் பண்புகள். சேவை நேரடியாக இயந்திரங்களில் வைக்கப்பட்ட பிறகு, அதன் நிகழ்வுகள் தோன்றும். அவை சந்தேகத்திற்கு இடமின்றி பெயரிடப்பட்டுள்ளன - நிகழ்வு எண் மற்றும் சேவைப் பெயராக: 1.ok-web.group1.web.front, 2.ok-web.group1.web.front, …

இது மிகவும் வசதியானது: இயங்கும் கொள்கலனின் பெயரை மட்டும் பார்த்து, உடனடியாக நிறைய கண்டுபிடிக்க முடியும்.

இந்த நிகழ்வுகள் உண்மையில் என்ன செய்கின்றன என்பதை இப்போது கூர்ந்து கவனிப்போம்: பணிகள்.

பணி தனிமைப்படுத்தல் வகுப்புகள்

சரி (மற்றும், அநேகமாக, எல்லா இடங்களிலும்) உள்ள அனைத்து பணிகளையும் குழுக்களாக பிரிக்கலாம்:

• குறுகிய தாமதப் பணிகள் - தயாரிப்பு. அத்தகைய பணிகள் மற்றும் சேவைகளுக்கு, பதில் தாமதம் (தாமதம்) மிகவும் முக்கியமானது, ஒவ்வொரு கோரிக்கையும் கணினியால் எவ்வளவு விரைவாக செயலாக்கப்படும். பணிகளின் எடுத்துக்காட்டுகள்: இணைய முனைகள், தற்காலிக சேமிப்புகள், பயன்பாட்டு சேவையகங்கள், OLTP சேமிப்பு போன்றவை.
• கணக்கீடு சிக்கல்கள் - தொகுதி. இங்கே, ஒவ்வொரு குறிப்பிட்ட கோரிக்கையின் செயலாக்க வேகம் முக்கியமல்ல. அவர்களைப் பொறுத்தவரை, இந்த பணி ஒரு குறிப்பிட்ட (நீண்ட) காலத்தில் (செயல்திறன்) எத்தனை கணக்கீடுகளைச் செய்யும் என்பது முக்கியம். இவை MapReduce, Hadoop, machine learning, statistics போன்ற எந்தப் பணிகளாகவும் இருக்கும்.
• பின்னணி பணிகள் - செயலற்றவை. அத்தகைய பணிகளுக்கு, தாமதம் அல்லது செயல்திறன் மிக முக்கியமானவை அல்ல. இதில் பல்வேறு சோதனைகள், இடம்பெயர்வுகள், மறுகணக்கீடுகள் மற்றும் தரவை ஒரு வடிவமைப்பிலிருந்து மற்றொரு வடிவத்திற்கு மாற்றுதல் ஆகியவை அடங்கும். ஒருபுறம், அவை கணக்கிடப்பட்டதைப் போலவே இருக்கின்றன, மறுபுறம், அவை எவ்வளவு விரைவாக முடிக்கப்படுகின்றன என்பது எங்களுக்கு முக்கியமல்ல.

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

குறுகிய தாமத பணிகள். அத்தகைய பணியானது இதைப் போன்ற CPU நுகர்வு முறையைக் கொண்டிருக்கும்:

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

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

alloc: cpu = 4 (max)

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

கணக்கீட்டு பணிகள். அவற்றின் வடிவம் சற்று வித்தியாசமாக இருக்கும்:

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

alloc: cpu = [1,*)

"தயவுசெய்து அதை ஒரு மினியன் மீது வைக்கவும், அங்கு குறைந்தபட்சம் ஒரு இலவச கோர் இருக்கும், பின்னர் எத்தனையோ அவை அனைத்தையும் விழுங்கும்."

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

ஆனால் அதை எப்படி செய்வது?

முதலில், prod மற்றும் அதன் ஒதுக்கீடு: cpu = 4. நாம் நான்கு கோர்களை முன்பதிவு செய்ய வேண்டும். டோக்கர் ரன்னில் இதை இரண்டு வழிகளில் செய்யலாம்:

• விருப்பத்தைப் பயன்படுத்துதல் --cpuset=1-4, அதாவது இயந்திரத்தில் நான்கு குறிப்பிட்ட கோர்களை பணிக்கு ஒதுக்கவும்.
• பயன் --cpuquota=400_000 --cpuperiod=100_000, செயலி நேரத்திற்கு ஒரு ஒதுக்கீட்டை ஒதுக்கவும், அதாவது ஒவ்வொரு 100 ms நிகழ் நேரத்திலும் பணியானது 400 ms க்கு மேல் செயலி நேரத்தைப் பயன்படுத்துவதில்லை என்பதைக் குறிக்கிறது. அதே நான்கு கோர்கள் பெறப்படுகின்றன.

ஆனால் இந்த முறைகளில் எது பொருத்தமானது?

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

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

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

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

• SCHED_OTHER
  இயல்பாக, லினக்ஸ் கணினியில் உள்ள அனைத்து சாதாரண பயனர் செயல்முறைகளும் பெறுகின்றன.
• SCHED_BATCH
  வள-தீவிர செயல்முறைகளுக்காக வடிவமைக்கப்பட்டுள்ளது. செயலியில் பணியை வைக்கும் போது, ​​செயல்படுத்தும் அபராதம் அறிமுகப்படுத்தப்படுகிறது: SCHED_OTHER உடனான பணியை தற்போது பயன்படுத்தினால், அத்தகைய பணி செயலி ஆதாரங்களைப் பெறுவதற்கான வாய்ப்புகள் குறைவு.
• SCHED_IDLE
  மிகக் குறைந்த முன்னுரிமை கொண்ட பின்னணி செயல்முறை, நல்ல -19 ஐ விடவும் குறைவாக உள்ளது. நாங்கள் திறந்த மூல நூலகத்தைப் பயன்படுத்துகிறோம் ஒன்று-நியோ, அழைப்பதன் மூலம் கொள்கலனைத் தொடங்கும் போது தேவையான கொள்கையை அமைப்பதற்காக

one.nio.os.Proc.sched_setscheduler( pid, Proc.SCHED_IDLE )

ஆனால் நீங்கள் ஜாவாவில் நிரல் செய்யாவிட்டாலும், chrt கட்டளையைப் பயன்படுத்தி இதைச் செய்யலாம்:

chrt -i 0 $pid

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

காப்பு வகுப்பு
ஒதுக்கீடு உதாரணம்
டோக்கர் ரன் விருப்பங்கள்
sched_setscheduler chrt*

ப்ரொடக்ஷன்
cpu = 4
--cpuquota=400000 --cpuperiod=100000
SCHED_OTHER

தொகுதி
Cpu = [1, *)
--cpushares=1024
SCHED_BATCH

பணியின்றி
Cpu= [2, *)
--cpushares=2048
SCHED_IDLE

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

ஆனால் பணிகள் செயலியை மட்டுமல்ல, போக்குவரத்தையும் பயன்படுத்துகின்றன, இது செயலி வளங்களின் தவறான ஒதுக்கீட்டை விட நெட்வொர்க் பணியின் தாமதத்தை பாதிக்கிறது. எனவே, இயற்கையாகவே போக்குவரத்திற்கு அதே படத்தைப் பெற விரும்புகிறோம். அதாவது, ஒரு தயாரிப்பு பணி சில பாக்கெட்டுகளை நெட்வொர்க்கிற்கு அனுப்பும் போது, ​​அதிகபட்ச வேகத்தை கட்டுப்படுத்துகிறோம் (சூத்திரம் ஒதுக்கீடு: lan=[*,500mbps) ), எந்த தயாரிப்பு மூலம் இதைச் செய்யலாம். தொகுதிக்கு நாங்கள் குறைந்தபட்ச செயல்திறனுக்கு மட்டுமே உத்தரவாதம் அளிக்கிறோம், ஆனால் அதிகபட்சத்தை (சூத்திரம் ஒதுக்கீடு: lan=[10Mbps,*) ) இந்த வழக்கில், தயாரிப்பு போக்குவரத்து தொகுதி பணிகளை விட முன்னுரிமை பெற வேண்டும்.
இங்கே Docker இல் நாம் பயன்படுத்தக்கூடிய எந்த primitives இல்லை. ஆனால் அது எங்கள் உதவிக்கு வருகிறது லினக்ஸ் போக்குவரத்து கட்டுப்பாடு. ஒழுக்கத்தின் உதவியுடன் நாம் விரும்பிய முடிவை அடைய முடிந்தது படிநிலை நியாயமான சேவை வளைவு. அதன் உதவியுடன், நாங்கள் இரண்டு வகை போக்குவரத்தை வேறுபடுத்துகிறோம்: அதிக முன்னுரிமை தயாரிப்பு மற்றும் குறைந்த முன்னுரிமை தொகுதி/சும்மா. இதன் விளைவாக, வெளிச்செல்லும் போக்குவரத்திற்கான உள்ளமைவு பின்வருமாறு:

இங்கே 1:0 என்பது hsfc துறையின் "ரூட் qdisc" ஆகும்; 1:1 - hsfc குழந்தை வகுப்பு, மொத்த அலைவரிசை வரம்பு 8 ஜிபிட்/வி, இதன் கீழ் அனைத்து கொள்கலன்களின் குழந்தை வகுப்புகளும் வைக்கப்படுகின்றன; 1:2 - hsfc சைல்டு கிளாஸ் என்பது "டைனமிக்" வரம்புடன் கூடிய அனைத்து தொகுதி மற்றும் செயலற்ற பணிகளுக்கும் பொதுவானது, இது கீழே விவாதிக்கப்படுகிறது. மீதமுள்ள hsfc சைல்டு கிளாஸ்கள், 450 மற்றும் 400 Mbit/s என்ற வரம்புகளுடன் தற்போது இயங்கும் ப்ராட் கன்டெய்னர்களுக்கான பிரத்யேக வகுப்புகளாகும். ஒவ்வொரு hsfc வகுப்பிற்கும் லினக்ஸ் கர்னல் பதிப்பைப் பொறுத்து, டிராஃபிக் வெடிப்பின் போது பாக்கெட் இழப்பைத் தவிர்க்க, qdisc வரிசை fq அல்லது fq_codel ஒதுக்கப்பட்டுள்ளது.

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

சோதனைகளின் போது, ​​1:2 வகை முன்னுரிமையற்ற தொகுதி/செயல்பாட்டு போக்குவரத்தை மினியன் மெஷின்களில் குறிப்பிட்ட இலவசப் பாதைக்கு மிகாமல் கட்டுப்படுத்தும் போது hsfc சிறந்த முடிவுகளைக் காட்டுகிறது என்பதை நாங்கள் கண்டறிந்தோம். இல்லையெனில், முன்னுரிமை இல்லாத போக்குவரத்து, தயாரிப்பு பணிகளின் தாமதத்தில் அதிக தாக்கத்தை ஏற்படுத்துகிறது. miniond ஒவ்வொரு நொடியும் இலவச அலைவரிசையின் தற்போதைய அளவை தீர்மானிக்கிறது, கொடுக்கப்பட்ட மினியனின் அனைத்து தயாரிப்பு பணிகளின் சராசரி போக்குவரத்து நுகர்வு அளவிடும் மற்றும் பிணைய இடைமுக அலைவரிசையிலிருந்து கழித்தல் ஒரு சிறிய விளிம்புடன், அதாவது.

உள்வரும் மற்றும் வெளிச்செல்லும் போக்குவரத்திற்கு இசைக்குழுக்கள் சுயாதீனமாக வரையறுக்கப்படுகின்றன. மேலும் புதிய மதிப்புகளின் படி, miniond முன்னுரிமையற்ற வகுப்பு வரம்பை 1:2 மறுகட்டமைக்கிறது.

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

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

கூடுதல் வரிகள் மீண்டும் அகற்றப்பட்டவுடன், முழு சேவைப் பெயரின் முடிவில் பணி தனிமைப்படுத்தல் வகுப்பைச் சேர்ப்பதன் மூலம் எங்கள் சேவைப் பெயர்களை நாம் புகழ்ச்சியாக எழுதலாம்: web.front.prod, catalog.music.batch, மின்மாற்றி.இசை.சும்மா.

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

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

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

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

கூடுதலாக, நாங்கள் இதுவரை TCP போக்குவரத்திற்கு முன்னுரிமை அளிப்பதில் உள்ள சிக்கலை மட்டுமே தீர்க்க முடிந்தது: hsfc அணுகுமுறை UDP க்கு வேலை செய்யாது. TCP ட்ராஃபிக்கின் விஷயத்தில் கூட, தொகுதி பணி அதிக ட்ராஃபிக்கை உருவாக்கினால், இது தயாரிப்பு பணியின் தாமதத்தில் சுமார் 10% அதிகரிப்பு அளிக்கிறது.

தவறு சகிப்புத்தன்மை

ஒட்னோக்ளாஸ்னிகியின் தவறு சகிப்புத்தன்மையை மேம்படுத்துவது ஒரு கிளவுட்டை உருவாக்கும் போது இலக்குகளில் ஒன்றாகும். எனவே, தோல்விகள் மற்றும் விபத்துகளின் சாத்தியமான காட்சிகளை இன்னும் விரிவாகக் கருத்தில் கொள்ள விரும்புகிறேன். ஒரு எளிய காட்சியுடன் தொடங்குவோம் - ஒரு கொள்கலன் தோல்வி.

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

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

ஒரு முழு ஊழியரும் கிடைக்கவில்லை என்றால் நீங்கள் என்ன செய்ய முடியும்?

வெளிப்படையாக, கொள்கலனை மற்றொரு கணினியில் இயக்கவும். இங்குள்ள சுவாரஸ்யமான பகுதி என்னவென்றால், கொள்கலனுக்கு ஒதுக்கப்பட்ட IP முகவரி(கள்) என்ன ஆகும்.

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

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

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

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

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

எனவே, சேவைப் பெயரை அதன் ஐபி முகவரிகளின் பட்டியலில் மேப்பிங் செய்வது மிகவும் அரிதாகவே மாறுகிறது. கட்டுரையின் தொடக்கத்தில் நாங்கள் குறிப்பிட்ட சேவை நிகழ்வுகளின் பெயர்களை நீங்கள் மீண்டும் பார்த்தால் (1.ok-web.group1.web.front.prod, 2.ok-web.group1.web.front.prod, …), அவை DNS இல் பயன்படுத்தப்படும் FQDNகளை ஒத்திருப்பதைக் கவனிப்போம். அது சரி, சேவை நிகழ்வுகளின் பெயர்களை அவற்றின் ஐபி முகவரிகளுக்கு வரைபடமாக்க, நாங்கள் டிஎன்எஸ் நெறிமுறையைப் பயன்படுத்துகிறோம். மேலும், இந்த DNS அனைத்து கொள்கலன்களின் அனைத்து முன்பதிவு செய்யப்பட்ட IP முகவரிகளையும் வழங்குகிறது - இயங்கும் மற்றும் நிறுத்தப்பட்ட இரண்டும் (மூன்று பிரதிகள் பயன்படுத்தப்படுகின்றன என்று வைத்துக்கொள்வோம், மேலும் எங்களிடம் ஐந்து முகவரிகள் ஒதுக்கப்பட்டுள்ளன - ஐந்தும் திருப்பித் தரப்படும்). வாடிக்கையாளர்கள், இந்தத் தகவலைப் பெற்ற பிறகு, அனைத்து ஐந்து பிரதிகளுடனும் ஒரு இணைப்பை நிறுவ முயற்சிப்பார்கள் - இதனால் வேலை செய்பவர்களைத் தீர்மானிக்கவும். கிடைப்பதைத் தீர்மானிப்பதற்கான இந்த விருப்பம் மிகவும் நம்பகமானது; இது டிஎன்எஸ் அல்லது சர்வீஸ் டிஸ்கவரியை உள்ளடக்காது, அதாவது இந்த அமைப்புகளின் தகவல் மற்றும் தவறு சகிப்புத்தன்மையின் பொருத்தத்தை உறுதி செய்வதில் கடினமான சிக்கல்கள் எதுவும் இல்லை. மேலும், முழு போர்ட்டலின் செயல்பாடும் சார்ந்திருக்கும் முக்கியமான சேவைகளில், நாம் DNS ஐப் பயன்படுத்த முடியாது, ஆனால் IP முகவரிகளை உள்ளமைவில் உள்ளிடவும்.

கொள்கலன்களுக்குப் பின்னால் இத்தகைய ஐபி பரிமாற்றத்தை செயல்படுத்துவது அற்பமானது அல்ல - மேலும் இது எவ்வாறு செயல்படுகிறது என்பதை பின்வரும் எடுத்துக்காட்டில் பார்ப்போம்:

ஒரு கிளவுட் மாஸ்டர் minion M1 க்கு இயக்க கட்டளை கொடுக்கிறார் என்று வைத்துக்கொள்வோம் 1.ok-web.group1.web.front.prod முகவரி 1.1.1.1 உடன். ஒரு பணியாளரிடம் வேலை செய்கிறார் பறவை, இது இந்த முகவரியை சிறப்பு சேவையகங்களுக்கு விளம்பரப்படுத்துகிறது பாதை பிரதிபலிப்பான். பிந்தையது பிணைய வன்பொருளுடன் BGP அமர்வைக் கொண்டுள்ளது, அதில் M1.1.1.1 இல் முகவரி 1 இன் வழி மொழிபெயர்க்கப்பட்டுள்ளது. M1 லினக்ஸைப் பயன்படுத்தி கொள்கலனுக்குள் பாக்கெட்டுகளை வழிநடத்துகிறது. மூன்று வழி பிரதிபலிப்பான் சேவையகங்கள் உள்ளன, ஏனெனில் இது ஒரு கிளவுட் உள்கட்டமைப்பின் மிக முக்கியமான பகுதியாகும் - அவை இல்லாமல், ஒரு கிளவுட்டில் உள்ள பிணையம் இயங்காது. மூன்றும் ஒரே நேரத்தில் தோல்வியடையும் வாய்ப்பைக் குறைக்க, தரவு மையத்தின் வெவ்வேறு அறைகளில் முடிந்தால் அவற்றை வெவ்வேறு அடுக்குகளில் வைக்கிறோம்.

இப்போது ஒரு கிளவுட் மாஸ்டருக்கும் M1 மினியனுக்கும் இடையிலான தொடர்பு துண்டிக்கப்பட்டது என்று வைத்துக் கொள்வோம். ஒரு கிளவுட் மாஸ்டர் இப்போது M1 முற்றிலும் தோல்வியடைந்தது என்ற அனுமானத்தில் செயல்படும். அதாவது, இது M2 மினியனுக்கு தொடங்குவதற்கான கட்டளையை வழங்கும் web.group1.web.front.prod அதே முகவரியுடன் 1.1.1.1. இப்போது 1.1.1.1 க்கு நெட்வொர்க்கில் இரண்டு முரண்பட்ட வழிகள் உள்ளன: M1 மற்றும் M2 இல். இத்தகைய முரண்பாடுகளைத் தீர்க்க, BGP அறிவிப்பில் குறிப்பிடப்பட்டுள்ள மல்டி எக்சிட் டிஸ்க்ரிமினேட்டரைப் பயன்படுத்துகிறோம். இது விளம்பரப்படுத்தப்பட்ட பாதையின் எடையைக் காட்டும் எண். முரண்பட்ட வழிகளில், குறைந்த MED மதிப்பைக் கொண்ட பாதை தேர்ந்தெடுக்கப்படும். ஒரு கிளவுட் மாஸ்டர் MED ஐ கொள்கலன் IP முகவரிகளின் ஒருங்கிணைந்த பகுதியாக ஆதரிக்கிறது. முதல் முறையாக, முகவரி போதுமான அளவு பெரிய MED = 1 உடன் எழுதப்பட்டுள்ளது. அத்தகைய அவசர கொள்கலன் பரிமாற்றத்தின் சூழ்நிலையில், மாஸ்டர் MED ஐக் குறைக்கிறார், மேலும் MED = உடன் 000 முகவரியை விளம்பரப்படுத்துவதற்கான கட்டளையை M000 ஏற்கனவே பெறும். 2. M1.1.1.1 இல் இயங்கும் நிகழ்வானது இந்த வழக்கில் எந்த தொடர்பும் இல்லை, மேலும் மாஸ்டருடனான தொடர்பை மீட்டெடுக்கும் வரை அவரது எதிர்கால விதி நமக்கு சிறிதும் ஆர்வமில்லை, அப்போது அவர் பழையபடி நிறுத்தப்படும்.

செயலிழக்கிறது

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

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

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

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

இதற்கெல்லாம் நீங்கள் என்ன செய்ய முடியும்?

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

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

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

தயாரிப்பில் அதிக முன்னுரிமைகளை வழங்குகிறோம், 0; தொகுப்பில் - கொஞ்சம் குறைவாக, 100; செயலற்ற நிலையில் - இன்னும் குறைவாக, 200. முன்னுரிமைகள் படிநிலையாகப் பயன்படுத்தப்படுகின்றன. படிநிலையில் குறைவாக உள்ள அனைத்து பணிகளுக்கும் தொடர்புடைய முன்னுரிமை இருக்கும். ப்ரோடிற்குள் உள்ள தற்காலிகச் சேமிப்புகளை முன்முனைகளுக்கு முன் தொடங்க வேண்டும் எனில், கேச் = 0 மற்றும் முன் துணை வரிசைகள் = 1 க்கு முன்னுரிமைகளை வழங்குவோம். உதாரணமாக, முதன்மை போர்ட்டல் முதலில் முன்னணியில் இருந்து தொடங்கப்பட வேண்டும், மேலும் இசை முன்பக்கம் மட்டும் தொடங்க வேண்டும். பின்னர், நாம் பிந்தையவற்றுக்கு குறைந்த முன்னுரிமையை ஒதுக்கலாம் - 10.

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

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

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

முழு DC விபத்துக்கள்

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

யாரும் #உயிருடன் ட்வீட் செய்வதைத் தடுக்க இதைத்தான் செய்கிறோம்.

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

இந்த அணுகுமுறை உடல் தோல்வியிலிருந்து பாதுகாப்பது மட்டுமல்லாமல், ஆபரேட்டர் பிழையிலிருந்தும் பாதுகாக்க முடியும்.

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

முடிவுகளை

ஒரு மேகத்தின் தனித்துவமான அம்சங்கள்:

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

அடிக்கடி கேட்கப்படும் கேள்விகள்

நாம் ஏன் ஒரு ஆயத்த தீர்வை எடுக்கவில்லை?

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

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

கடைசி வரிகளைப் படித்தவர்களுக்கு, உங்கள் பொறுமைக்கும் கவனத்திற்கும் நன்றி!

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