One-Cloud - Odnoklassniki හි දත්ත මධ්‍යස්ථාන මට්ටමේ OS

අහෝ, මිනිසුන්! මගේ නම Oleg Anastasyev, මම Platform කණ්ඩායමේ Odnoklassniki හි වැඩ කරනවා. මට අමතරව, Odnoklassniki හි බොහෝ දෘඩාංග වැඩ කරයි. අපට සේවාදායක 500 දහසකට වඩා වැඩි රාක්ක 8 ක් පමණ ඇති දත්ත මධ්‍යස්ථාන හතරක් ඇත. යම් අවස්ථාවක, නව කළමනාකරණ පද්ධතියක් හඳුන්වාදීම මඟින් උපකරණ වඩාත් කාර්යක්ෂමව පැටවීමට, ප්‍රවේශ කළමනාකරණයට පහසුකම් සැලසීමට, පරිගණක සම්පත් (නැවත) බෙදා හැරීමට ස්වයංක්‍රීය කිරීමට, නව සේවා දියත් කිරීම වේගවත් කිරීමට සහ ප්‍රතිචාර වේගවත් කිරීමට අපට ඉඩ සැලසෙන බව අපි තේරුම් ගත්තෙමු. මහා පරිමාණ අනතුරු වලට.

එයින් සිදු වූයේ කුමක්ද?

මම සහ දෘඪාංග සමූහයක් හැරුණු විට, මෙම දෘඩාංග සමඟ වැඩ කරන අය ද සිටිති: දත්ත මධ්‍යස්ථානවල සෘජුවම පිහිටා ඇති ඉංජිනේරුවන්; ජාල මෘදුකාංග සකසන ජාලකරුවන්; යටිතල පහසුකම් ඔරොත්තු දීමේ හැකියාව සපයන පරිපාලකයින්, හෝ SREs; සහ සංවර්ධන කණ්ඩායම්, ඒ සෑම එකක්ම ද්වාරයෙහි කාර්යයන්හි කොටසක් සඳහා වගකිව යුතුය. ඔවුන් නිර්මාණය කරන මෘදුකාංගය ක්‍රියා කරන්නේ මෙවැනි දෙයක්.

ප්‍රධාන ද්වාරයෙහි ඉදිරිපස දෙකෙන්ම පරිශීලක ඉල්ලීම් ලැබේ www.ok.ru, සහ අනෙකුත් මත, උදාහරණයක් ලෙස සංගීත API පෙරමුණු මත. ව්‍යාපාර තර්කනය සැකසීමට, ඔවුන් යෙදුම් සේවාදායකය අමතනු ලබන අතර, ඉල්ලීම සැකසීමේදී අවශ්‍ය විශේෂිත ක්ෂුද්‍ර සේවා කැඳවයි - එක් ප්‍රස්ථාරය (සමාජ සම්බන්ධතා ප්‍රස්ථාරය), පරිශීලක-හැඹිලිය (පරිශීලක පැතිකඩවල හැඹිලිය) යනාදිය.

මෙම සෑම සේවාවක්ම බොහෝ යන්ත්‍රවල යොදවා ඇති අතර, ඒ සෑම එකක්ම මොඩියුලවල ක්‍රියාකාරිත්වය, ඒවායේ ක්‍රියාකාරිත්වය සහ තාක්ෂණික සංවර්ධනය සඳහා වගකිව යුතු සංවර්ධකයින් සිටී. මෙම සියලුම සේවාවන් දෘඪාංග සේවාදායකයන් මත ධාවනය වන අතර මෑතක් වන තුරුම අපි එක් සේවාදායකයකට හරියටම එක් කාර්යයක් දියත් කළෙමු, එනම් එය නිශ්චිත කාර්යයක් සඳහා විශේෂිත විය.

ඇයි ඒ? මෙම ප්රවේශය වාසි කිහිපයක් ඇත:

• සහනයක් ලැබුවා මහා කළමනාකරණය. අපි හිතමු යම් කාර්යයක් සඳහා පුස්තකාල කිහිපයක්, සැකසුම් කිහිපයක් අවශ්‍ය වේ. ඉන්පසු සේවාදායකය හරියටම එක් නිශ්චිත කණ්ඩායමකට පවරා ඇත, මෙම කණ්ඩායම සඳහා cfengine ප්‍රතිපත්තිය විස්තර කර ඇත (හෝ එය දැනටමත් විස්තර කර ඇත), සහ මෙම වින්‍යාසය මධ්‍යගතව සහ ස්වයංක්‍රීයව මෙම කණ්ඩායමේ සියලුම සේවාදායකයන් වෙත විහිදේ.
• සරල කර ඇත රෝග නිර්ණය. ඔබ මධ්‍යම ප්‍රොසෙසරයේ වැඩිවන බර දෙස බලා මෙම බර ජනනය කළ හැක්කේ මෙම දෘඩාංග ප්‍රොසෙසරයේ ක්‍රියාත්මක වන කාර්යයෙන් පමණක් බව ඔබ තේරුම් ගත් බව කියමු. දොස් පැවරිය යුතු අයෙකු සෙවීම ඉතා ඉක්මනින් අවසන් වේ.
• සරල කර ඇත අධීක්ෂණය. සේවාදායකයේ යම් දෙයක් වැරදියි නම්, මොනිටරය එය වාර්තා කරයි, ඔබ දොස් පැවරිය යුත්තේ කවුරුන්ද යන්න හරියටම දනී.

අනුරූ කිහිපයකින් සමන්විත සේවාවක් සේවාදායක කිහිපයක් වෙන් කර ඇත - එක් එක් සඳහා එකක්. එවිට සේවාව සඳහා පරිගණක සම්පත ඉතා සරලව වෙන් කරනු ලැබේ: සේවාව සතුව ඇති සේවාදායකයන් සංඛ්යාව, එය පරිභෝජනය කළ හැකි උපරිම සම්පත් ප්රමාණය. මෙහි "පහසු" යන්නෙන් අදහස් වන්නේ එය භාවිතා කිරීමට පහසු බව නොවේ, නමුත් සම්පත් වෙන් කිරීම අතින් සිදු වේ.

මෙම ප්රවේශය ද අපට කිරීමට ඉඩ ලබා දුන්නේය විශේෂිත යකඩ සැකසුම් මෙම සේවාදායකයේ ක්රියාත්මක වන කාර්යයක් සඳහා. කාර්යය විශාල දත්ත ප්‍රමාණයක් ගබඩා කරන්නේ නම්, අපි තැටි 4 ක් සහිත චැසියක් සහිත 38U සේවාදායකයක් භාවිතා කරමු. කාර්යය සම්පූර්ණයෙන්ම ගණනය කිරීම නම්, අපට ලාභදායී 1U සේවාදායකයක් මිලදී ගත හැකිය. මෙය ගණනය කිරීමේ කාර්යක්ෂම වේ. වෙනත් දේ අතර, මෙම ප්රවේශය අපට එක් මිත්රශීලී සමාජ ජාලයක් සමඟ සැසඳිය හැකි බරක් සහිත හතර ගුණයකින් අඩු යන්ත්ර භාවිතා කිරීමට ඉඩ සලසයි.

පරිගණක සම්පත් භාවිතයේ එවැනි කාර්යක්ෂමතාවයක් ආර්ථික කාර්යක්ෂමතාවයක් සහතික කළ යුතුය, අපි වඩාත්ම මිල අධික දෙය සේවාදායකයන් යන පදනමෙන් ඉදිරියට ගියහොත්. දිගු කලක් තිස්සේ දෘඪාංග වඩාත්ම මිල අධික වූ අතර, දෘඪාංගවල මිල අඩු කිරීම සඳහා අපි විශාල උත්සාහයක් දැරූ අතර, දෘඪාංග විශ්වාසනීය අවශ්යතා අඩු කිරීම සඳහා වැරදි ඉවසීමේ ඇල්ගොරිතම ඉදිරිපත් කරමු. අද අපි සේවාදායකයේ මිල තීරණාත්මක වීම නතර කර ඇති අවස්ථාවට පැමිණ ඇත. ඔබ නවතම exotics නොසලකන්නේ නම්, රාක්කයේ ඇති සේවාදායකයන්ගේ නිශ්චිත වින්‍යාසය වැදගත් නොවේ. දැන් අපට තවත් ගැටළුවක් තිබේ - දත්ත මධ්‍යස්ථානයේ සේවාදායකයා විසින් අල්ලාගෙන සිටින ඉඩෙහි මිල, එනම් රාක්කයේ ඉඩ.

මෙය එසේ බව වටහා ගත් අපි රාක්ක භාවිතා කරන ආකාරය ගණනය කිරීමට තීරණය කළෙමු.
අපි ආර්ථිකමය වශයෙන් සාධාරණීකරණය කළ හැකි ඒවායින් බලවත්ම සේවාදායකයේ මිල ලබා ගත්තෙමු, එවැනි සේවාදායකයන් කොපමණ ප්‍රමාණයක් රාක්කවල තැබිය හැකිද, පැරණි මාදිලියේ “එක් සේවාදායකයක් = එක් කාර්යයක්” මත පදනම්ව අපි ඒවා මත කොපමණ කාර්යයන් ක්‍රියාත්මක කරනවාද සහ කොපමණ ප්‍රමාණයක් ගණනය කළෙමු. කාර්යයන් සඳහා උපකරණ භාවිතා කළ හැකිය. ඔවුන් ගණන් කර කඳුළු සැලූහ. රාක්ක භාවිතා කිරීමේදී අපගේ කාර්යක්ෂමතාව 11% ක් පමණ වන බව පෙනී ගියේය. නිගමනය පැහැදිලිය: අපි දත්ත මධ්යස්ථාන භාවිතා කිරීමේ කාර්යක්ෂමතාව වැඩි කළ යුතුය. විසඳුම පැහැදිලි බව පෙනේ: ඔබට එක් සේවාදායකයක එකවර කාර්යයන් කිහිපයක් ක්‍රියාත්මක කළ යුතුය. නමුත් දුෂ්කරතා ආරම්භ වන්නේ මෙහිදීය.

ස්කන්ධ වින්‍යාසය නාටකාකාර ලෙස වඩාත් සංකීර්ණ වේ - දැන් ඕනෑම එක් කණ්ඩායමක් සේවාදායකයකට පැවරිය නොහැක. සියල්ලට පසු, දැන් එක් සේවාදායකයක් මත විවිධ විධානවල කාර්යයන් කිහිපයක් දියත් කළ හැකිය. මීට අමතරව, විවිධ යෙදුම් සඳහා වින්‍යාසය පරස්පර විය හැක. රෝග විනිශ්චය ද වඩාත් සංකීර්ණ වේ: සේවාදායකයක CPU හෝ තැටි පරිභෝජනය වැඩි වී ඇති බව ඔබ දුටුවහොත්, කරදර ඇති කරන්නේ කුමන කාර්යයදැයි ඔබ නොදනී.

නමුත් ප්රධාන දෙය වන්නේ එකම යන්ත්රයේ ක්රියාත්මක වන කාර්යයන් අතර හුදකලා නොවීමයි. මෙන්න, උදාහරණයක් ලෙස, එකම සේවාදායකයේ වෙනත් පරිගණක යෙදුමක් දියත් කිරීමට පෙර සහ පසුව සේවාදායක කාර්යයක සාමාන්‍ය ප්‍රතිචාර කාලය පිළිබඳ ප්‍රස්ථාරයකි, පළමු එකට සම්බන්ධ නොවේ - ප්‍රධාන කාර්යයේ ප්‍රතිචාර කාලය සැලකිය යුතු ලෙස වැඩි වී ඇත.

නිසැකවම, ඔබ බහාලුම්වල හෝ අතථ්‍ය යන්ත්‍රවල කාර්යයන් ක්‍රියාත්මක කළ යුතුය. අපගේ කාර්යයන් සියල්ලම පාහේ එක් OS (Linux) යටතේ ක්‍රියාත්මක වන බැවින් හෝ එයට අනුවර්තනය වී ඇති බැවින්, අපට විවිධ මෙහෙයුම් පද්ධති සඳහා සහය දැක්වීමට අවශ්‍ය නොවේ. ඒ අනුව, අථත්‍යකරණය අවශ්‍ය නොවේ; අමතර පොදු කාර්ය නිසා, එය බහාලුම්කරණයට වඩා අඩු කාර්යක්ෂම වනු ඇත.

සෘජුවම සේවාදායකයන් මත කාර්යයන් ධාවනය කිරීම සඳහා බහාලුම් ක්‍රියාත්මක කිරීමක් ලෙස, ඩොකර් හොඳ අපේක්ෂකයෙකි: ගොනු පද්ධති රූප එකිනෙකට පරස්පර වින්‍යාසයන් සමඟ ගැටලු හොඳින් විසඳයි. රූප ස්තර කිහිපයකින් සමන්විත විය හැකි බැවින්, ඒවා යටිතල ව්‍යුහය මත යෙදවීමට අවශ්‍ය දත්ත ප්‍රමාණය සැලකිය යුතු ලෙස අඩු කිරීමට, පොදු කොටස් වෙනම මූලික ස්ථරවලට වෙන් කිරීමට අපට ඉඩ සලසයි. එවිට මූලික (සහ වඩාත්ම විශාල) ස්ථර සමස්ත යටිතල ව්‍යුහය පුරා තරමක් ඉක්මනින් හැඹිලිගත වනු ඇති අතර විවිධ ආකාරයේ යෙදුම් සහ අනුවාද ලබා දීමට කුඩා ස්ථර පමණක් මාරු කිරීමට අවශ්‍ය වේ.

තවද, Docker හි සූදානම් කළ රෙජිස්ට්‍රියක් සහ රූප ටැග් කිරීම මඟින් අපට නිෂ්පාදනයට කේතය අනුවාදනය කිරීම සහ බෙදා හැරීම සඳහා සූදානම් කළ ප්‍රාථමිකයන් ලබා දේ.

ඩොකර්, වෙනත් ඕනෑම සමාන තාක්‍ෂණයක් මෙන්, අපට පෙට්ටියෙන් පිටත යම් මට්ටමක බහාලුම් හුදකලා කිරීමක් සපයයි. උදාහරණයක් ලෙස, මතක හුදකලා කිරීම - සෑම බහාලුමකටම යන්ත්‍ර මතකය භාවිතා කිරීමේ සීමාවක් ලබා දී ඇති අතර ඉන් ඔබ්බට එය පරිභෝජනය නොකරයි. CPU භාවිතය මත පදනම්ව ඔබට බහාලුම් හුදකලා කළ හැකිය. කෙසේ වෙතත්, අප සඳහා, සම්මත පරිවාරක ප්රමාණවත් නොවීය. නමුත් ඒ ගැන වැඩි විස්තර පහතින්.

සේවාදායකයන් මත බහාලුම් සෘජුව ධාවනය කිරීම ගැටලුවේ කොටසක් පමණි. අනෙක් කොටස සේවාදායකයන් මත බහාලුම් සත්කාරකත්වයට සම්බන්ධ වේ. කුමන සේවාදායකයේ කුමන බහාලුම් තැබිය හැකිද යන්න ඔබ තේරුම් ගත යුතුය. මෙය එතරම් පහසු කාර්යයක් නොවේ, මන්ද ඒවායේ වේගය අඩු නොකර හැකි තරම් ඝන ලෙස සර්වර් මත බහාලුම් තැබිය යුතු බැවිනි. වැරදි ඉවසීමේ දෘෂ්ටි කෝණයකින් එවැනි ස්ථානගත කිරීම ද අපහසු විය හැකිය. බොහෝ විට අපට එකම සේවාවේ අනුරූ විවිධ රාක්කවල හෝ දත්ත මධ්‍යස්ථානයේ විවිධ කාමරවල තැබීමට අවශ්‍ය වේ, එවිට රාක්කයක් හෝ කාමරයක් අසමත් වුවහොත්, අපට සියලුම සේවා අනුරූ ක්ෂණිකව අහිමි නොවේ.

ඔබට සේවාදායකයන් 8 දහසක් සහ බහාලුම් 8-16 දහසක් ඇති විට බහාලුම් අතින් බෙදා හැරීම විකල්පයක් නොවේ.

ඊට අමතරව, අපට අවශ්‍ය වූයේ පරිපාලකයෙකුගේ සහය නොමැතිව, ඔවුන්ගේ සේවාවන් නිෂ්පාදනයේදීම සත්කාරකත්වය සැපයීමට හැකි වන පරිදි, සම්පත් වෙන් කිරීමේදී සංවර්ධකයින්ට වැඩි ස්වාධීනත්වයක් ලබා දීමටයි. ඒ අතරම, යම් සුළු සේවාවක් අපගේ දත්ත මධ්‍යස්ථානවල සියලු සම්පත් පරිභෝජනය නොකරන ලෙස පාලනය පවත්වා ගැනීමට අපට අවශ්‍ය විය.

නිසැකවම, අපට මෙය ස්වයංක්‍රීයව කරන පාලන ස්ථරයක් අවශ්‍ය වේ.

එබැවින් අපි සියලු ගෘහ නිර්මාණ ශිල්පීන් අගය කරන සරල සහ තේරුම්ගත හැකි පින්තූරයකට පැමිණියෙමු: වර්ග තුනක්.

one-Cloud masters යනු වලාකුළු වාද්‍ය වෘන්දයට වගකිව යුතු අසාර්ථක පොකුරකි. සංවර්ධකයා මාස්ටර් වෙත මැනිෆෙස්ටයක් යවයි, එහි සේවාව සත්කාරකත්වය සැපයීමට අවශ්‍ය සියලු තොරතුරු අඩංගු වේ. එය මත පදනම්ව, මාස්ටර් විසින් තෝරාගත් මිනියන් (කන්ටේනර් ධාවනය කිරීමට නිර්මාණය කර ඇති යන්ත්ර) වෙත විධාන ලබා දෙයි. සගයන් සතුව අපගේ නියෝජිතයා ඇත, එය විධානය ලබාගෙන, එහි විධාන ඩොකර් වෙත නිකුත් කරයි, සහ ඩොකර් අනුරූප කන්ටේනරය දියත් කිරීමට ලිනක්ස් කර්නලය වින්‍යාස කරයි. විධාන ක්‍රියාත්මක කිරීමට අමතරව, නියෝජිතයා මිනියන් යන්ත්‍රයේ සහ එය මත ක්‍රියාත්මක වන බහාලුම් දෙකෙහිම තත්වයේ වෙනස්කම් පිළිබඳව ස්වාමියා වෙත අඛණ්ඩව වාර්තා කරයි.

සම්පත් වෙන් කිරීම

දැන් අපි බොහෝ සගයන් සඳහා වඩාත් සංකීර්ණ සම්පත් වෙන් කිරීමේ ගැටලුව දෙස බලමු.

එක් වලාකුළක පරිගණක සම්පතක් වන්නේ:

• නිශ්චිත කාර්යයක් විසින් පරිභෝජනය කරන ලද ප්රොසෙසරයේ බලය ප්රමාණය.
• කාර්යය සඳහා පවතින මතක ප්රමාණය.
• ජාල ගමනාගමනය. සෑම සගයෙකුටම සීමිත කලාප පළලක් සහිත නිශ්චිත ජාල අතුරු මුහුණතක් ඇත, එබැවින් ඔවුන් ජාලය හරහා සම්ප්‍රේෂණය කරන දත්ත ප්‍රමාණය සැලකිල්ලට නොගෙන කාර්යයන් බෙදා හැරීම කළ නොහැක.
• තැටි. මීට අමතරව, පැහැදිලිවම, මෙම කාර්යයන් සඳහා අවකාශය සඳහා, අපි තැටි වර්ගය ද වෙන් කරමු: HDD හෝ SSD. තැටි වලට තත්පරයකට සීමිත ඉල්ලීම් සංඛ්‍යාවක් ලබා දිය හැක - IOPS. එබැවින්, තනි තැටියකට හැසිරවිය හැකි ප්‍රමාණයට වඩා වැඩි IOPS ජනනය කරන කාර්යයන් සඳහා, අපි “ස්පින්ඩල්” ද වෙන් කරමු - එනම්, කාර්යය සඳහා පමණක් වෙන් කළ යුතු තැටි උපාංග.

එවිට යම් සේවාවක් සඳහා, උදාහරණයක් ලෙස පරිශීලක-හැඹිලි සඳහා, අපට පරිභෝජනය කරන ලද සම්පත් මේ ආකාරයෙන් වාර්තා කළ හැකිය: ප්‍රොසෙසර් කෝර් 400 ක්, මතකය 2,5 TB, දෙපැත්තටම 50 Gbit / s ගමනාගමනය, ස්පින්ඩල් 6 මත පිහිටා ඇති HDD ඉඩ 100 TB . නැතහොත් මෙවැනි වඩාත් හුරුපුරුදු ස්වරූපයෙන්:

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

පරිශීලක-හැඹිලි සේවා සම්පත් නිෂ්පාදන යටිතල ව්‍යුහයේ පවතින සියලුම සම්පත් වලින් කොටසක් පමණක් පරිභෝජනය කරයි. එමනිසා, මට හදිසියේම, ක්‍රියාකරුගේ දෝෂයක් නිසා හෝ නැත, පරිශීලක-හැඹිලිය එයට වෙන් කර ඇති ප්‍රමාණයට වඩා වැඩි සම්පත් පරිභෝජනය නොකරන බවට සහතික වීමට මට අවශ්‍යය. එනම් සම්පත් සීමා කළ යුතුයි. නමුත් අපට කෝටාව බැඳිය හැක්කේ කුමක් ද?

සංරචක අන්තර්ක්‍රියා කරන ආකාරය සහ එය වැඩි විස්තර සහිතව නැවත අඳින ආකාරය පිළිබඳ අපගේ සරල කළ රූප සටහන වෙත ආපසු යමු - මේ වගේ:

ඔබේ ඇසට හසු වන දේ:

• වෙබ් ඉදිරිපස සහ සංගීතය එකම යෙදුම් සේවාදායකයේ හුදකලා පොකුරු භාවිතා කරයි.
• මෙම පොකුරු අයත් වන තාර්කික ස්ථර අපට වෙන්කර හඳුනාගත හැකිය: පෙරමුනු, හැඹිලි, දත්ත ගබඩා කිරීම සහ කළමනාකරණ ස්ථරය.
• ඉදිරිපස කොටස විෂමජාතීය; එය විවිධ ක්‍රියාකාරී උප පද්ධති වලින් සමන්විත වේ.
• හැඹිලි ද ඒවා හැඹිලිගත කරන උප පද්ධතිය පුරා විසිරී යා හැක.

අපි නැවතත් පින්තූරය නැවත අඳිමු:

බාහ්! ඔව්, අපි ධූරාවලියක් දකිනවා! මෙයින් අදහස් කරන්නේ ඔබට සම්පත් විශාල කොටස් වශයෙන් බෙදා හැරිය හැකි බවයි: ක්‍රියාකාරී උප පද්ධතියට (පින්තූරයේ "සංගීතය" වැනි) අනුරූප වන මෙම ධුරාවලියේ නෝඩයකට වගකිවයුතු සංවර්ධකයෙකු පවරන්න සහ ධූරාවලියේ එකම මට්ටමට කෝටාවක් අමුණන්න. කළමනාකරණයේ පහසුව සඳහා වඩාත් නම්‍යශීලී ලෙස සේවාවන් සංවිධානය කිරීමට මෙම ධුරාවලිය අපට ඉඩ සලසයි. උදාහරණයක් ලෙස, අපි සියලුම වෙබය බෙදාහරින්නෙමු, මෙය ඉතා විශාල සේවාදායකයන් සමූහයක් වන බැවින්, කුඩා කණ්ඩායම් කිහිපයකට, පින්තූරයේ group1, group2 ලෙස පෙන්වා ඇත.

අමතර රේඛා ඉවත් කිරීමෙන්, අපගේ පින්තූරයේ සෑම නෝඩයක්ම පැතලි ආකාරයෙන් ලිවිය හැකිය: group1.web.front, api.music.ඉදිරිපස, user-cache.cache.

"ධූරාවලි පෝලිම්" යන සංකල්පයට අප පැමිණෙන්නේ එලෙසිනි. ඒකට "group1.web.front" වගේ නමක් තියෙනවා. සම්පත් සහ පරිශීලක අයිතිවාසිකම් සඳහා කෝටාවක් එයට පවරා ඇත. අපි DevOps හි පුද්ගලයාට පෝලිමට සේවාවක් යැවීමට අයිතිය ලබා දෙන්නෙමු, එවැනි සේවකයෙකුට පෝලිමේ යමක් දියත් කළ හැකි අතර, OpsDev හි පුද්ගලයාට පරිපාලක අයිතිවාසිකම් ඇත, දැන් ඔහුට පෝලිම කළමනාකරණය කළ හැකිය, එහි පුද්ගලයින් පැවරිය හැකිය, මෙම පුද්ගලයින්ට අයිතිවාසිකම් ලබා දීම යනාදිය. මෙම පෝලිමේ ක්‍රියාත්මක වන සේවාවන් පෝලිමේ කෝටාව තුළ ක්‍රියාත්මක වේ. සියලුම සේවාවන් එකවර ක්‍රියාත්මක කිරීමට පෝලිමේ පරිගණක කෝටාව ප්‍රමාණවත් නොවන්නේ නම්, ඒවා අනුපිළිවෙලින් ක්‍රියාත්මක වන අතර එමඟින් පෝලිම සෑදේ.

සේවාවන් දෙස සමීපව බලමු. සේවාවකට සම්පූර්ණ සුදුසුකම් ලත් නමක් ඇත, එයට සෑම විටම පෝලිමේ නම ඇතුළත් වේ. එවිට ඉදිරිපස වෙබ් සේවාවට නම ලැබෙනු ඇත ok-web.group1.web.front. තවද එය ප්‍රවේශ වන යෙදුම් සේවාදායක සේවාව කැඳවනු ලැබේ ok-app.group1.web.front. සෑම සේවාවකටම මැනිෆෙස්ට් එකක් ඇත, එය නිශ්චිත යන්ත්‍රවල ස්ථානගත කිරීම සඳහා අවශ්‍ය සියලු තොරතුරු සඳහන් කරයි: මෙම කාර්යය කොපමණ සම්පත් පරිභෝජනය කරයි, ඒ සඳහා අවශ්‍ය වින්‍යාසය, කොපමණ අනුරූ තිබිය යුතුද, මෙම සේවාවේ අසාර්ථකත්වය හැසිරවීමේ ගුණාංග. සේවාව සෘජුවම යන්ත්‍ර මත තැබූ පසු, එහි අවස්ථා දිස්වේ. ඒවා නොපැහැදිලි ලෙස නම් කර ඇත - උදාහරණ අංකය සහ සේවා නාමය ලෙස: 1.ok-web.group1.web.front, 2.ok-web.group1.web.front, …

මෙය ඉතා පහසු ය: ධාවන කන්ටේනරයේ නම පමණක් බැලීමෙන්, අපට වහාම බොහෝ දේ සොයාගත හැකිය.

දැන් අපි මෙම අවස්ථා ඇත්ත වශයෙන්ම ඉටු කරන්නේ කුමක්ද යන්න දෙස සමීපව බලමු: කාර්යයන්.

කාර්ය හුදකලා පන්ති

OK හි ඇති සියලුම කාර්යයන් (සහ, බොහෝ විට, සෑම තැනකම) කණ්ඩායම් වලට බෙදිය හැකිය:

• කෙටි ප්‍රමාද කාර්ය - prod. එවැනි කාර්යයන් සහ සේවාවන් සඳහා, ප්‍රතිචාර ප්‍රමාදය (ප්‍රමාදය) ඉතා වැදගත් වේ, එක් එක් ඉල්ලීම් පද්ධතිය විසින් කෙතරම් ඉක්මනින් ක්‍රියාවට නංවනු ඇත්ද. කාර්යයන් සඳහා උදාහරණ: වෙබ් පෙරමුණු, හැඹිලි, යෙදුම් සේවාදායක, OLTP ආචයනය, ආදිය.
• ගණනය කිරීමේ ගැටළු - කණ්ඩායම. මෙහිදී, එක් එක් විශේෂිත ඉල්ලීම් සැකසීමේ වේගය වැදගත් නොවේ. ඔවුන් සඳහා, මෙම කාර්යය නිශ්චිත (දිගු) කාල පරිච්ඡේදයක් තුළ කොපමණ ගණනය කිරීම් සිදු කරයිද යන්න වැදගත් වේ (ඵලදායිතාවය). මේවා MapReduce, Hadoop, machine learning, statistics හි ඕනෑම කාර්යයක් වනු ඇත.
• පසුබිම් කාර්යයන් - නිෂ්ක්‍රීය. එවැනි කාර්යයන් සඳහා, ප්‍රමාදය හෝ ප්‍රතිදානය ඉතා වැදගත් නොවේ. මෙයට විවිධ පරීක්ෂණ, සංක්‍රමණය, නැවත ගණනය කිරීම් සහ දත්ත එක් ආකෘතියකින් තවත් ආකෘතියකට පරිවර්තනය කිරීම ඇතුළත් වේ. එක් අතකින්, ඒවා ගණනය කළ ඒවාට සමාන ය, අනෙක් අතට, ඒවා කෙතරම් ඉක්මනින් සම්පූර්ණ කර ඇත්ද යන්න අපට වැදගත් නොවේ.

එවැනි කාර්යයන් සම්පත් පරිභෝජනය කරන්නේ කෙසේදැයි බලමු, උදාහරණයක් ලෙස, මධ්යම ප්රොසෙසරය.

කෙටි ප්රමාද කාර්යයන්. එවැනි කාර්යයකට මෙයට සමාන CPU පරිභෝජන රටාවක් ඇත:

සැකසීම සඳහා පරිශීලකයාගෙන් ඉල්ලීමක් ලැබේ, කාර්යය පවතින සියලුම CPU හරයන් භාවිතා කිරීමට පටන් ගනී, එය සකසයි, ප්‍රතිචාරයක් ලබා දෙයි, ඊළඟ ඉල්ලීම සඳහා රැඳී සිට නතර වේ. ඊළඟ ඉල්ලීම පැමිණියේය - නැවතත් අපි එහි තිබූ සියල්ල තෝරාගෙන, එය ගණනය කර, ඊළඟ එක එනතෙක් බලා සිටිමු.

එවැනි කාර්යයක් සඳහා අවම ප්‍රමාදය සහතික කිරීම සඳහා, අපි එය පරිභෝජනය කරන උපරිම සම්පත් ලබා ගත යුතු අතර, මිනියන් (කාර්යය ක්‍රියාත්මක කරන යන්ත්‍රය) මත අවශ්‍ය හර ගණන වෙන් කළ යුතුය. එවිට අපගේ ගැටලුව සඳහා වෙන් කිරීමේ සූත්‍රය පහත පරිදි වේ:

alloc: cpu = 4 (max)

සහ අප සතුව මධ්‍ය 16 ක් සහිත කුඩා යන්ත්‍රයක් තිබේ නම්, හරියටම එවැනි කාර්යයන් හතරක් එය මත තැබිය හැකිය. එවැනි කාර්යයන්හි සාමාන්‍ය ප්‍රොසෙසර පරිභෝජනය බොහෝ විට ඉතා අඩු බව අපි විශේෂයෙන් සටහන් කරමු - එය පැහැදිලිය, මන්ද කාර්යය කාලයෙන් සැලකිය යුතු කොටසක් ඉල්ලීමක් සඳහා බලා සිටින අතර කිසිවක් නොකරන බැවිනි.

ගණනය කිරීමේ කාර්යයන්. ඔවුන්ගේ රටාව තරමක් වෙනස් වනු ඇත:

එවැනි කාර්යයන් සඳහා සාමාන්ය CPU සම්පත් පරිභෝජනය තරමක් ඉහළ ය. බොහෝ විට අපට ගණනය කිරීමේ කාර්යයක් නිශ්චිත කාලයක් තුළ සම්පූර්ණ කිරීමට අවශ්‍ය වේ, එබැවින් සම්පූර්ණ ගණනය කිරීම පිළිගත හැකි කාලයකින් අවසන් වන පරිදි එයට අවශ්‍ය අවම ප්‍රොසෙසර සංඛ්‍යාව වෙන් කරවා ගත යුතුය. එහි වෙන් කිරීමේ සූත්‍රය මේ ආකාරයෙන් පෙනෙනු ඇත:

alloc: cpu = [1,*)

"කරුණාකර එය අවම වශයෙන් එක් නිදහස් හරයක් ඇති මිනියන් මත තබන්න, එවිට ඇති තරම්, එය සියල්ල ගිල දමනු ඇත."

මෙහිදී කෙටි ප්‍රමාදයක් සහිත කාර්යයන්ට වඩා භාවිතයේ කාර්යක්ෂමතාව දැනටමත් වඩා හොඳය. නමුත් ඔබ එක් කුඩා යන්ත්‍රයක් මත කාර්යයන් දෙකම ඒකාබද්ධ කර එහි සම්පත් යන අතරතුර බෙදා හරින්නේ නම් ලාභය වඩා විශාල වනු ඇත. කෙටි ප්‍රමාදයක් සහිත කාර්යයක් සඳහා ප්‍රොසෙසරයක් අවශ්‍ය වූ විට, එය වහාම එය ලබා ගන්නා අතර, සම්පත් තවදුරටත් අවශ්‍ය නොවන විට, ඒවා ගණනය කිරීමේ කාර්යයට මාරු කරනු ලැබේ, එනම් මෙවැනි දෙයක්:

නමුත් එය එසේ කරන්නේ කෙසේද?

පළමුව, අපි prod සහ එහි වෙන් කිරීම බලමු: cpu = 4. අපි cores හතරක් වෙන් කර ගත යුතුයි. ඩොකර් ධාවනයේදී මෙය ආකාර දෙකකින් කළ හැකිය:

• විකල්පය භාවිතා කිරීම --cpuset=1-4, එනම් කාර්යය සඳහා යන්ත්රයේ නිශ්චිත හර හතරක් වෙන් කරන්න.
• භාවිතා කරන්න --cpuquota=400_000 --cpuperiod=100_000, ප්‍රොසෙසර කාලය සඳහා කෝටාවක් පවරන්න, එනම් සෑම තථ්‍ය කාලීන 100 ms කාර්යය සඳහා ප්‍රොසෙසර කාලය ms 400 ට වඩා වැය නොවන බව දක්වන්න. එම හරය හතරම ලබා ගනී.

නමුත් මෙම ක්‍රමවලින් සුදුසු වන්නේ කුමක්ද?

cpuset ඉතා ආකර්ෂණීය පෙනුමක්. කාර්යයට කැප වූ හර හතරක් ඇත, එයින් අදහස් කරන්නේ ප්‍රොසෙසර හැඹිලි හැකි තරම් කාර්යක්ෂමව ක්‍රියා කරන බවයි. මෙයට ද අවාසියක් ඇත: මෙහෙයුම් පද්ධතිය වෙනුවට යන්ත්‍රයේ බාන ලද හරය හරහා ගණනය කිරීම් බෙදා හැරීමේ කාර්යය අපට භාර ගැනීමට සිදුවනු ඇත, මෙය තරමක් සුළු නොවන කාර්යයකි, විශේෂයෙන් අපි කණ්ඩායම් කාර්යයන් එවැනි එකක් මත තැබීමට උත්සාහ කරන්නේ නම්. යන්ත්රය. කෝටාව සහිත විකල්පය මෙහි වඩාත් සුදුසු බව පරීක්ෂණ මගින් පෙන්වා දී ඇත: මේ ආකාරයෙන් වත්මන් මොහොතේ කාර්යය ඉටු කිරීම සඳහා හරය තෝරාගැනීමේදී මෙහෙයුම් පද්ධතියට වැඩි නිදහසක් ඇති අතර ප්‍රොසෙසර කාලය වඩාත් කාර්යක්ෂමව බෙදා හරිනු ලැබේ.

අවම මධ්‍ය සංඛ්‍යාව මත පදනම්ව Docker හි වෙන් කිරීම් කරන්නේ කෙසේදැයි සොයා බලමු. කණ්ඩායම් කාර්යයන් සඳහා කෝටාව තවදුරටත් අදාළ නොවේ, උපරිම සීමා කිරීමට අවශ්‍ය නොවන නිසා, අවමය සහතික කිරීම පමණක් ප්‍රමාණවත් වේ. තවද මෙහි විකල්පය හොඳින් ගැලපේ docker run --cpushares.

කණ්ඩායමකට අවම වශයෙන් එක් හරයක් සඳහා සහතිකයක් අවශ්‍ය නම්, අපි සඳහන් කරන බවට අපි එකඟ වෙමු --cpushares=1024, සහ අවම වශයෙන් හර දෙකක් තිබේ නම්, අපි දක්වන්නෙමු --cpushares=2048. Cpu කොටස් ප්‍රොසෙසරයේ කාලය ප්‍රමාණවත් ලෙස බෙදා හැරීමට කිසිදු ආකාරයකින් බාධා නොකරයි. මේ අනුව, prod දැනට එහි හර හතරම භාවිතා නොකරන්නේ නම්, කණ්ඩායම් කාර්යයන් සීමා කිරීමට කිසිවක් නොමැති අතර, ඔවුන්ට අමතර ප්‍රොසෙසර කාලය භාවිතා කළ හැක. නමුත් ප්‍රොසෙසර හිඟයක් පවතින අවස්ථාවක, prod එහි හර හතරම පරිභෝජනය කර එහි කෝටාවට ළඟා වී ඇත්නම්, ඉතිරි ප්‍රොසෙසර කාලය cpushares වලට සමානුපාතිකව බෙදනු ලැබේ, එනම් නිදහස් මධ්‍ය තුනක තත්වයක් තුළ, එකක් වනු ඇත. cpushares 1024 ක් සහිත කාර්යයකට ලබා දී ඇති අතර, ඉතිරි දෙක cpushares 2048 ක් සහිත කාර්යයකට ලබා දෙනු ඇත.

නමුත් කෝටා සහ කොටස් භාවිතා කිරීම ප්රමාණවත් නොවේ. ප්‍රොසෙසර කාලය වෙන් කිරීමේදී කණ්ඩායම් කාර්යයකට වඩා කෙටි ප්‍රමාදයක් සහිත කාර්යයකට ප්‍රමුඛතාවය ලැබෙන බවට අපි සහතික විය යුතුය. එවැනි ප්‍රමුඛතාවයකින් තොරව, කණ්ඩායම් කාර්යය ප්‍රොඩ්ට අවශ්‍ය වන මොහොතේ සියලුම ප්‍රොසෙසර කාලය ගත වේ. Docker ධාවනයේදී බහාලුම් ප්‍රමුඛතා විකල්ප නොමැත, නමුත් Linux CPU උපලේඛන ප්‍රතිපත්ති ප්‍රයෝජනවත් වේ. ඔබට ඔවුන් ගැන විස්තරාත්මකව කියවිය හැකිය මෙහි, සහ මෙම ලිපියේ රාමුව තුළ අපි කෙටියෙන් ඒවා හරහා යන්නෙමු:

• SCHED_OTHER
  පෙරනිමියෙන්, ලිනක්ස් යන්ත්‍රයක සියලුම සාමාන්‍ය පරිශීලක ක්‍රියාවලි ලැබේ.
• SCHED_BATCH
  සම්පත්-දැඩි ක්රියාවලීන් සඳහා නිර්මාණය කර ඇත. ප්‍රොසෙසරයක් මත කාර්යයක් තැබීමේදී, ඊනියා සක්‍රීය කිරීමේ දඩයක් හඳුන්වා දෙනු ලැබේ: එවැනි කාර්යයක් දැනට SCHED_OTHER සමඟ කාර්යයක් විසින් භාවිතා කරන්නේ නම්, ප්‍රොසෙසර සම්පත් ලැබීමට ඇති ඉඩකඩ අඩුය.
• SCHED_IDLE
  ඉතා අඩු ප්‍රමුඛතාවයක් සහිත පසුබිම් ක්‍රියාවලියක්, ලස්සන -19 ට වඩා අඩුය. අපි අපගේ විවෘත මූලාශ්‍ර පුස්තකාලය භාවිතා කරමු one-nio, ඇමතීමෙන් කන්ටේනරය ආරම්භ කිරීමේදී අවශ්‍ය ප්‍රතිපත්තිය සැකසීම සඳහා

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

නමුත් ඔබ ජාවා හි ක්‍රමලේඛනය නොකළත්, chrt විධානය භාවිතයෙන් එකම දේ කළ හැකිය:

chrt -i 0 $pid

පැහැදිලිකම සඳහා අපගේ සියලුම හුදකලා මට්ටම් එක වගුවකට සාරාංශ කරමු:

පරිවාරක පන්තිය
උදාහරණය වෙන් කරන්න
ඩොකර් ධාවන විකල්ප
sched_setscheduler chrt*

Prod
cpu = 4
--cpuquota=400000 --cpuperiod=100000
SCHED_OTHER

කණ්ඩායම
Cpu = [1, *)
--cpushares=1024
SCHED_BATCH

භාවිතයට අවශ්ය නොවන
Cpu= [2, *)
--cpushares=2048
SCHED_IDLE

*ඔබ කන්ටේනරයක් ඇතුලේ සිට chrt කරන්නේ නම්, ඔබට sys_nice හැකියාව අවශ්‍ය විය හැක, මන්ද පෙරනිමියෙන් Docker මෙම හැකියාව කන්ටේනරය ආරම්භ කිරීමේදී ඉවත් කරයි.

නමුත් කාර්යයන් ප්‍රොසෙසරය පමණක් නොව ගමනාගමනය ද පරිභෝජනය කරයි, එය ප්‍රොසෙසර සම්පත් වැරදි ලෙස බෙදා හැරීමට වඩා ජාල කාර්යයක ප්‍රමාදයට බලපායි. එමනිසා, අපට ස්වභාවයෙන්ම ගමනාගමනය සඳහා එකම පින්තූරයක් ලබා ගැනීමට අවශ්‍යය. එනම්, නිෂ්පාදන කාර්යයක් ජාලයට පැකට් කිහිපයක් යවන විට, අපි උපරිම වේගය සීමා කරමු (සූත්රය වෙන්: lan=[*,500mbps) ), මෙය කළ හැක්කේ කුමන නිෂ්පාදන සමඟද? කණ්ඩායම සඳහා අපි අවම ප්‍රතිදානය පමණක් සහතික කරමු, නමුත් උපරිමය සීමා නොකරන්න (සූත්‍රය වෙන්: lan=[10Mbps,*) ) මෙම අවස්ථාවෙහිදී, කණ්ඩායම් කාර්යයන්ට වඩා නිෂ්පාදන ගමනාගමනයට ප්‍රමුඛත්වය ලැබිය යුතුය.
මෙහිදී Docker සතුව අපට භාවිතා කළ හැකි ප්‍රාථමික කිසිවක් නොමැත. නමුත් එය අපගේ උපකාරයට පැමිණේ ලිනක්ස් ගමනාගමන පාලනය. විනය පිහිටෙන් අපේක්ෂිත ප්‍රතිඵලය ලබා ගැනීමට අපට හැකි විය ධූරාවලි සාධාරණ සේවා වක්‍රය. එහි උපකාරයෙන්, අපි රථවාහන පන්ති දෙකක් වෙන්කර හඳුනා ගනිමු: ඉහළ ප්‍රමුඛතා නිෂ්පාදන සහ අඩු ප්‍රමුඛතා කණ්ඩායම/නිෂ්ක්‍රීය. ප්රතිඵලයක් වශයෙන්, පිටතට යන ගමනාගමනය සඳහා වින්යාසය පහත පරිදි වේ:

මෙහි 1:0 යනු hsfc විනයෙහි "root qdisc" වේ; 1:1 - 8 Gbit/s ක සම්පූර්ණ කලාප පළල සීමාවක් සහිත hsfc ළමා පන්තිය, ඒ යටතේ සියලුම බහාලුම්වල ළමා පන්ති තබා ඇත; 1:2 - hsfc ළමා පන්තිය "ගතික" සීමාවක් සහිත සියලුම කණ්ඩායම් සහ නිෂ්ක්‍රීය කාර්යයන් සඳහා පොදු වේ, එය පහත සාකච්ඡා කෙරේ. ඉතිරි hsfc ළමා පන්ති දැනට ක්‍රියාත්මක වන නිෂ්පාදන බහාලුම් සඳහා වෙන් වූ පන්ති වන අතර ඒවායේ මැනිෆෙස්ටයට අනුරූප වන සීමාවන් - 450 සහ 400 Mbit/s. සෑම hsfc පන්තියකටම qdisc පෝලිම් fq හෝ fq_codel, Linux kernel අනුවාදය මත පදනම්ව, රථවාහන පිපිරීම් වලදී පැකට් අහිමි වීම වැළැක්වීම සඳහා පවරා ඇත.

සාමාන්‍යයෙන්, tc විනය මඟින් පිටතට යන ගමනාගමනයට පමණක් ප්‍රමුඛත්වය දීමට සේවය කරයි. නමුත් අපට එන ගමනාගමනයටද ප්‍රමුඛත්වය දීමට අවශ්‍යයි - සියල්ලට පසු, සමහර කණ්ඩායම් කාර්යයට සම්පූර්ණ එන නාලිකාව පහසුවෙන් තෝරා ගත හැකිය, උදාහරණයක් ලෙස, සිතියම්&අඩු කිරීම සඳහා විශාල ආදාන දත්ත සමූහයක් ලබා ගැනීම. මේ සඳහා අපි මොඩියුලය භාවිතා කරමු ifb, එය එක් එක් ජාල අතුරුමුහුණත සඳහා ifbX අතථ්‍ය අතුරුමුහුණතක් නිර්මාණය කරන අතර අතුරු මුහුණතේ සිට එන ගමනාගමනය ifbX මත පිටතට යන ගමනාගමනය වෙත හරවා යවයි. තවද, ifbX සඳහා, පිටතට යන ගමනාගමනය පාලනය කිරීමට එකම විෂයයන් ක්‍රියා කරයි, ඒ සඳහා hsfc වින්‍යාසය බෙහෙවින් සමාන වනු ඇත:

අත්හදා බැලීම් අතරතුර, මිනියන් යන්ත්‍රවල 1:2 පන්තියේ ප්‍රමුඛතා නොවන කණ්ඩායම/නිෂ්ක්‍රීය ගමනාගමනය නිශ්චිත නිදහස් මංතීරුවකට වඩා සීමා වූ විට hsfc හොඳම ප්‍රතිඵල පෙන්වන බව අපි සොයා ගත්තෙමු. එසේ නොමැති නම්, ප්‍රමුඛතා නොවන ගමනාගමනය නිෂ්පාදන කාර්යයන්වල ප්‍රමාදයට වැඩි බලපෑමක් ඇති කරයි. miniond සෑම තත්පරයකම වත්මන් නිදහස් කලාප පළල ප්‍රමාණය තීරණය කරයි, දී ඇති මිනියන්ගේ සියලුම නිෂ්පාදන කාර්යයන්හි සාමාන්‍ය ගමනාගමන පරිභෝජනය මැනීම සහ ජාල අතුරුමුහුණත් කලාප පළලෙන් එය අඩු කිරීම කුඩා ආන්තිකය සමඟ, i.e.

එන සහ පිටතට යන ගමනාගමනය සඳහා බෑන්ඩ් ස්වාධීනව අර්ථ දක්වා ඇත. තවද නව අගයන් අනුව, miniond විසින් ප්‍රමුඛතා නොවන පන්ති සීමාව 1:2 නැවත සකස් කරයි.

මේ අනුව, අපි හුදකලා පන්ති තුනම ක්‍රියාත්මක කළෙමු: prod, batch සහ idle. මෙම පන්ති කාර්ය සාධන ලක්ෂණ කෙරෙහි බෙහෙවින් බලපායි. එමනිසා, අපි මෙම ගුණාංගය ධූරාවලියේ ඉහළින්ම තැබීමට තීරණය කළෙමු, එවිට ධූරාවලි පෝලිමේ නම දෙස බලන විට අප කටයුතු කරන්නේ කුමක් දැයි වහාම පැහැදිලි වනු ඇත:

අපේ සියලු මිතුරන් වෙබ් и සංගීත පෙරමුණු පසුව prod යටතේ ධුරාවලියේ තබා ඇත. උදාහරණයක් ලෙස, කණ්ඩායම යටතේ, අපි සේවාව තබමු සංගීත නාමාවලිය, එය ඔඩ්නොක්ලාස්නිකි වෙත උඩුගත කරන ලද mp3 ගොනු කට්ටලයකින් කාලානුරූපී ගීත නාමාවලියක් සම්පාදනය කරයි. idle යටතේ ඇති සේවාවක උදාහරණයක් වනු ඇත සංගීත ට්රාන්ස්ෆෝමර්, සංගීත පරිමාවේ මට්ටම සාමාන්‍යකරණය කරයි.

අමතර රේඛා නැවත ඉවත් කිරීමත් සමඟ, සම්පූර්ණ සේවා නාමයේ අවසානයට කාර්ය හුදකලා පන්තිය එක් කිරීමෙන් අපට අපගේ සේවා නම් පැතලි ලෙස ලිවිය හැකිය: web.front.prod, catalog.music.batch, ට්‍රාන්ස්ෆෝමර්.සංගීතය.නිෂ්ක්‍රීය.

දැන්, සේවාවේ නම දෙස බලන විට, එය ඉටු කරන කාර්යය පමණක් නොව, එහි හුදකලා පන්තිය, එනම් එහි විවේචනාත්මක බව යනාදිය ද අපට වැටහේ.

සෑම දෙයක්ම විශිෂ්ටයි, නමුත් එක් තිත්ත ඇත්තක් තිබේ. එක් යන්ත්‍රයක් මත ක්‍රියාත්මක වන කාර්යයන් සම්පූර්ණයෙන්ම හුදකලා කළ නොහැක.

අපි සාක්ෂාත් කර ගැනීමට සමත් වූ දේ: කණ්ඩායම දැඩි ලෙස පරිභෝජනය කරන්නේ නම් පමණි CPU සම්පත්, එවිට බිල්ට්-ඉන් Linux CPU උපලේඛනය එහි කාර්යය ඉතා හොඳින් ඉටු කරයි, සහ නිෂ්පාදන කාර්යයට ප්‍රායෝගිකව කිසිදු බලපෑමක් නැත. නමුත් මෙම කණ්ඩායම් කාර්යය මතකය සමඟ ක්රියාකාරීව වැඩ කිරීමට පටන් ගනී නම්, අන්යෝන්ය බලපෑම දැනටමත් පෙනේ. මෙය සිදු වන්නේ ප්‍රොඩ් කර්තව්‍යය ප්‍රොසෙසරයේ මතක හැඹිලි වලින් “සෝදා” ඇති බැවිනි - එහි ප්‍රතිඵලයක් ලෙස, හැඹිලි මග හැරීම් වැඩි වන අතර ප්‍රොසෙසරය ප්‍රොඩ් කාර්යය වඩාත් සෙමින් සකසයි. එවැනි කණ්ඩායම් කාර්යයක් මඟින් අපගේ සාමාන්‍ය නිෂ්පාදන කන්ටේනරයේ ප්‍රමාදය 10% කින් වැඩි කළ හැකිය.

නවීන ජාල කාඩ්පත් පැකට් වල අභ්‍යන්තර පෝලිමක් තිබීම හේතුවෙන් ගමනාගමනය හුදකලා කිරීම වඩාත් අපහසු වේ. කණ්ඩායම් කාර්යයේ පැකට්ටුව මුලින්ම එහි පැමිණෙන්නේ නම්, එය කේබලය හරහා සම්ප්‍රේෂණය වන පළමු එක වනු ඇත, ඒ ගැන කිසිවක් කළ නොහැක.

මීට අමතරව, අපි මෙතෙක් කළමනාකරණය කර ඇත්තේ TCP ගමනාගමනයට ප්‍රමුඛත්වය දීමේ ගැටලුව විසඳීමට පමණි: hsfc ප්‍රවේශය UDP සඳහා ක්‍රියා නොකරයි. ඒවගේම TCP Traffic වලදි වුනත්, batch task එක නිසා ගොඩක් ට්‍රැෆික් එනවා නම්, මේකෙන් prod task එකේ delay එකේ 10%ක විතර වැඩිවීමක් ලැබෙනවා.

වැරදි ඉවසීම

එක් වලාකුළක් සංවර්ධනය කිරීමේදී එක් ඉලක්කයක් වූයේ ඔඩ්නොක්ලාස්නිකිගේ වැරදි ඉවසීම වැඩි දියුණු කිරීමයි. එමනිසා, ඊළඟට මම අසාර්ථකත්වයන් සහ අනතුරු පිළිබඳ වඩාත් විස්තරාත්මකව සලකා බැලීමට කැමැත්තෙමි. අපි සරල අවස්ථාවක් සමඟ ආරම්භ කරමු - බහාලුම් අසමත් වීම.

කන්ටේනරයම ක්රම කිහිපයකින් අසමත් විය හැක. මෙය මැනිෆෙස්ටයේ යම් ආකාරයක අත්හදා බැලීමක්, දෝෂයක් හෝ දෝෂයක් විය හැකිය, එම නිසා ප්‍රොඩ් කාර්යය මැනිෆෙස්ටයේ දක්වා ඇති ප්‍රමාණයට වඩා වැඩි සම්පත් පරිභෝජනය කිරීමට පටන් ගනී. අපට නඩුවක් තිබුණි: සංවර්ධකයෙකු එක් සංකීර්ණ ඇල්ගොරිතමයක් ක්‍රියාත්මක කර, එය බොහෝ වාරයක් නැවත සකස් කර, තමා ගැනම සිතා බලා කෙතරම් ව්‍යාකූල වූවාද යත්, අවසානයේ ගැටලුව ඉතා සුළු නොවන ලූපයකට ගියේය. නිෂ්පාදන කාර්යයට එකම මිනියන් මත සිටින අනෙක් සියල්ලන්ට වඩා ඉහළ ප්‍රමුඛතාවයක් ඇති බැවින්, එය පවතින සියලුම ප්‍රොසෙසර සම්පත් පරිභෝජනය කිරීමට පටන් ගත්තේය. මෙම තත්වය තුළ, හුදකලා කිරීම හෝ ඒ වෙනුවට CPU කාල කෝටාව දවස ඉතිරි කළේය. කාර්යයකට කෝටාවක් වෙන් කළහොත්, එම කාර්යය වැඩිපුර පරිභෝජනය නොකරයි. එම නිසා, එකම යන්ත්රය මත ධාවනය වූ කණ්ඩායම සහ අනෙකුත් නිෂ්පාදන කාර්යයන් කිසිවක් නොදැක්කා.

විය හැකි දෙවන ගැටළුව වන්නේ කන්ටේනරය වැටීමයි. තවද මෙහි නැවත ආරම්භ කිරීමේ ප්‍රතිපත්ති අපව සුරකියි, හැමෝම ඒවා දන්නවා, ඩොකර් විසින්ම විශිෂ්ට කාර්යයක් කරයි. සෑම නිෂ්පාදනයක්ම පාහේ සෑම විටම නැවත ආරම්භ කිරීමේ ප්‍රතිපත්තියක් ඇත. සමහර විට අපි කණ්ඩායම් කාර්යයන් සඳහා හෝ නිෂ්පාදන බහාලුම් නිදොස් කිරීම සඳහා on_failure භාවිතා කරමු.

සම්පූර්ණ සේවකයෙකු නොමැති නම් ඔබට කුමක් කළ හැකිද?

පැහැදිලිවම, වෙනත් යන්ත්රයක කන්ටේනරය ධාවනය කරන්න. මෙහි ඇති සිත්ගන්නා කොටස වන්නේ බහාලුමට පවරා ඇති IP ලිපිනයට (es) සිදු වන්නේ කුමක්ද යන්නයි.

මෙම බහාලුම් ක්‍රියාත්මක වන කුඩා යන්ත්‍රවලට සමාන IP ලිපින අපට කන්ටේනර්වලට පැවරිය හැකිය. ඉන්පසුව, කන්ටේනරය වෙනත් යන්ත්‍රයක දියත් කරන විට, එහි IP ලිපිනය වෙනස් වන අතර, කන්ටේනරය චලනය වී ඇති බව සියලුම සේවාදායකයින් තේරුම් ගත යුතු අතර, දැන් ඔවුන්ට වෙනම සේවා සොයාගැනීමේ සේවාවක් අවශ්‍ය වන වෙනත් ලිපිනයකට යා යුතුය.

සේවා සොයාගැනීම පහසුය. සේවා රෙජිස්ට්රි සංවිධානය කිරීම සඳහා විවිධ මට්ටමේ වැරදි ඉවසීමේ වෙළඳපොලේ බොහෝ විසඳුම් තිබේ. බොහෝ විට එවැනි විසඳුම් බර සමතුලිතතා තර්කනය ක්රියාත්මක කරයි, KV ආචයනය ආකාරයෙන් අතිරේක වින්යාසය ගබඩා කිරීම ආදිය.
කෙසේ වෙතත්, අපි වෙනම රෙජිස්ට්‍රියක් ක්‍රියාත්මක කිරීමේ අවශ්‍යතාවය මඟහරවා ගැනීමට කැමැත්තෙමු, මන්ද මෙයින් අදහස් කරන්නේ නිෂ්පාදනයේ සියලුම සේවාවන් භාවිතා කරන තීරණාත්මක පද්ධතියක් හඳුන්වා දීමයි. මෙයින් අදහස් කරන්නේ මෙය අසාර්ථක වීමේ විභව ලක්ෂ්‍යයක් වන අතර, ඔබ ඉතා වැරදි-ඉවසන විසඳුමක් තෝරා ගැනීමට හෝ සංවර්ධනය කිරීමට අවශ්‍ය වන අතර, එය පැහැදිලිවම ඉතා දුෂ්කර, කාලය ගතවන සහ මිල අධික වේ.

සහ තවත් එක් විශාල අඩුපාඩුවක්: අපගේ පැරණි යටිතල පහසුකම් නව එකක් සමඟ වැඩ කිරීමට නම්, යම් ආකාරයක සේවා සොයාගැනීම් පද්ධතියක් භාවිතා කිරීම සඳහා අපට සියලු කාර්යයන් නැවත ලිවීමට සිදුවේ. වැඩ ගොඩක් ඇති අතර, සමහර ස්ථානවල එය OS කර්නල් මට්ටමේ හෝ සෘජුවම දෘඪාංග සමඟ වැඩ කරන පහත් මට්ටමේ උපාංග සම්බන්ධයෙන් පාහේ කළ නොහැක්කකි. වැනි ස්ථාපිත විසඳුම් රටා භාවිතයෙන් මෙම ක්‍රියාකාරීත්වය ක්‍රියාත්මක කිරීම පැති කාර් සමහර ස්ථානවල අමතර බරක් අදහස් වනු ඇත, අනෙක් ඒවා - මෙහෙයුමේ සංකූලතාවයක් සහ අතිරේක අසාර්ථක අවස්ථා. අපට දේවල් සංකීර්ණ කිරීමට අවශ්‍ය නොවීය, එබැවින් අපි Service Discovery භාවිත කිරීම විකල්ප කිරීමට තීරණය කළෙමු.

එක් වලාකුළක් තුළ, IP බහාලුම අනුගමනය කරයි, එනම් එක් එක් කාර්ය අවස්ථාවට තමන්ගේම IP ලිපිනයක් ඇත. මෙම ලිපිනය "ස්ථිතික" වේ: සේවාව මුලින්ම වලාකුළට යවන විට එය එක් එක් අවස්ථාවට පවරනු ලැබේ. සේවාවකට එහි ජීවිත කාලය තුළ වෙනස් අවස්ථා ගණනක් තිබුනේ නම්, අවසානයේ උපරිම අවස්ථා ඇති තරම් IP ලිපින ප්‍රමාණයක් එයට පවරනු ලැබේ.

පසුව, මෙම ලිපින වෙනස් නොවේ: ඒවා එක් වරක් පවරනු ලබන අතර නිෂ්පාදනයේ සේවා කාලය පුරාවටම පවතී. IP ලිපින ජාලය හරහා බහාලුම් අනුගමනය කරයි. කන්ටේනරය වෙනත් සගයෙකු වෙත මාරු කරන්නේ නම්, ලිපිනය එය අනුගමනය කරනු ඇත.

මේ අනුව, සේවා නාමයක් එහි IP ලිපින ලැයිස්තුවට සිතියම්ගත කිරීම ඉතා කලාතුරකින් වෙනස් වේ. ලිපියේ ආරම්භයේ අප සඳහන් කළ සේවා අවස්ථා වල නම් ඔබ නැවත බැලුවහොත් (1.ok-web.group1.web.front.prod, 2.ok-web.group1.web.front.prod, …), ඒවා DNS හි භාවිතා වන FQDN වලට සමාන බව අපි දකිමු. ඒක හරි, සේවා අවස්ථා වල නම් ඒවායේ IP ලිපින වලට සිතියම්ගත කිරීමට, අපි DNS ප්‍රොටෝකෝලය භාවිතා කරමු. එපමනක් නොව, මෙම DNS සියලුම බහාලුම්වල සියලුම වෙන් කර ඇති IP ලිපින ආපසු ලබා දෙයි - ධාවනය සහ නතර කිරීම යන දෙකම (අපි කියමු අනුපිටපත් තුනක් භාවිතා කර ඇති අතර, අපට එහි ලිපින පහක් වෙන් කර ඇත - පහම ආපසු ලබා දෙනු ඇත). සේවාදායකයින්, මෙම තොරතුරු ලැබුණු පසු, අනුරූ පහම සමඟ සම්බන්ධතාවයක් ඇති කර ගැනීමට උත්සාහ කරනු ඇත - ඒ අනුව වැඩ කරන ඒවා තීරණය කරන්න. ලබා ගත හැකි බව තීරණය කිරීම සඳහා මෙම විකල්පය වඩා විශ්වාසදායක ය; එයට DNS හෝ සේවා සොයාගැනීම් සම්බන්ධ නොවේ, එයින් අදහස් කරන්නේ තොරතුරු වල අදාළත්වය සහ මෙම පද්ධතිවල වැරදි ඉවසීම සහතික කිරීමේදී විසඳීමට අපහසු ගැටළු නොමැති බවයි. එපමණක් නොව, සමස්ත ද්වාරයෙහි ක්‍රියාකාරිත්වය රඳා පවතින තීරණාත්මක සේවාවන්හි, අපට කිසිසේත් DNS භාවිතා කළ නොහැක, නමුත් වින්‍යාසයට IP ලිපින ඇතුළත් කරන්න.

බහාලුම් පිටුපස එවැනි IP හුවමාරුව ක්‍රියාත්මක කිරීම සුළුපටු නොවන දෙයක් විය හැකිය - පහත උදාහරණය සමඟ එය ක්‍රියා කරන ආකාරය අපි බලමු:

අපි කියමු one-Cloud master එක minion M1 ට run කරන්න විධානය දෙනවා කියලා 1.ok-web.group1.web.front.prod ලිපිනය 1.1.1.1 සමඟ. මිනියන් මත වැඩ කරයි කුරුල්ලා, මෙම ලිපිනය විශේෂ සේවාදායකයන් වෙත ප්‍රචාරණය කරයි මාර්ග පරාවර්තකය. දෙවැන්නාට ජාල දෘඩාංග සමඟ BGP සැසියක් ඇත, M1.1.1.1 හි 1 ලිපිනයේ මාර්ගය පරිවර්තනය කර ඇත. M1 Linux භාවිතයෙන් බහාලුම් තුළ පැකට් ගමන් කරයි. මාර්ග පරාවර්තක සේවාදායකයන් තුනක් ඇත, මෙය එක් වලාකුළු යටිතල ව්‍යුහයේ ඉතා තීරණාත්මක කොටසක් වන බැවින් - ඒවා නොමැතිව, එක් වලාකුළක ජාලය ක්‍රියා නොකරනු ඇත. අපි ඒවා විවිධ රාක්කවල තබමු, හැකි නම්, දත්ත මධ්‍යස්ථානයේ විවිධ කාමරවල පිහිටා ඇති අතර, තුනම එකවර අසමත් වීමේ සම්භාවිතාව අඩු කරන්න.

දැන් අපි හිතමු one-Cloud master සහ M1 minion අතර සම්බන්ධය නැතිවෙලා කියලා. M1 සම්පූර්ණයෙන්ම අසාර්ථක වී ඇතැයි යන උපකල්පනය මත One-Cloud master දැන් ක්‍රියා කරනු ඇත. එනම්, එය දියත් කිරීමට M2 minion වෙත විධානය ලබා දෙනු ඇත web.group1.web.front.prod එකම ලිපිනය 1.1.1.1 සමඟ. දැන් අපට 1.1.1.1 සඳහා ජාලයේ ගැටුම් මාර්ග දෙකක් තිබේ: M1 සහ M2 මත. එවැනි ගැටුම් නිරාකරණය කිරීම සඳහා, අපි BGP නිවේදනයේ දක්වා ඇති බහු පිටවීමේ වෙනස්කම් කරන්නා භාවිතා කරමු. මෙය ප්‍රචාරණය කරන ලද මාර්ගයේ බර පෙන්වන අංකයකි. පරස්පර මාර්ග අතරින්, අඩු MED අගය සහිත මාර්ගය තෝරා ගනු ලැබේ. එක්-වලාකුළු මාස්ටර් බහාලුම් IP ලිපිනවල අනිවාර්ය අංගයක් ලෙස MED සඳහා සහය දක්වයි. පළමු වතාවට, ලිපිනය ප්රමාණවත් තරම් විශාල MED = 1 කින් ලියා ඇත.එවැනි හදිසි බහාලුම් මාරු කිරීමේ තත්ත්වය තුළ, ස්වාමියා MED අඩු කරයි, සහ M000 = සමඟ ලිපිනය 000 ප්රචාරය කිරීමට විධානය දැනටමත් ලැබෙනු ඇත. 2. M1.1.1.1 මත ධාවනය වන අවස්ථාව මෙම අවස්ථාවේ දී කිසිදු සම්බන්ධයක් නොමැති අතර, ස්වාමියා සමඟ ඇති සම්බන්ධය යථා තත්ත්වයට පත් කරන තෙක් ඔහුගේ ඉදිරි ඉරණම අපට එතරම් උනන්දුවක් නොදක්වයි, එවිට ඔහු පැරණි ගත කිරීමක් මෙන් නතර වනු ඇත.

අනතුරු

සියලුම දත්ත මධ්‍යස්ථාන කළමනාකරණ පද්ධති සෑම විටම සුළු අසාර්ථකත්වයන් පිළිගත හැකි ලෙස හසුරුවයි. බහාලුම් පිටාර ගැලීම සෑම තැනකම පාහේ සම්මතයකි.

දත්ත මධ්‍යස්ථානයක කාමර එකක හෝ වැඩි ගණනක විදුලිය ඇනහිටීමක් වැනි හදිසි අවස්ථාවකදී අප කටයුතු කරන්නේ කෙසේදැයි බලමු.

දත්ත මධ්‍යස්ථාන කළමනාකරණ පද්ධතියක් සඳහා අනතුරක් යන්නෙන් අදහස් කරන්නේ කුමක්ද? පළමුවෙන්ම, මෙය බොහෝ යන්ත්‍රවල එක් වරක් දැවැන්ත අසාර්ථකත්වයක් වන අතර පාලන පද්ධතියට එකවර බහාලුම් රාශියක් සංක්‍රමණය කළ යුතුය. නමුත් ව්‍යසනය ඉතා විශාල නම්, දත්ත මධ්‍යස්ථානයේ සම්පත් ධාරිතාව බරෙන් 100% ට වඩා පහත වැටෙන බැවින්, සියලු කාර්යයන් වෙනත් සගයන් වෙත නැවත ලබා දිය නොහැක.

බොහෝ විට අනතුරු සිදුවන්නේ පාලක ස්ථරයේ අසමත් වීමෙනි. එහි උපකරණවල අසමත් වීම නිසා මෙය සිදුවිය හැකි නමුත් බොහෝ විට අනතුරු පරීක්ෂාවට ලක් නොවීම සහ වැඩි බරක් හේතුවෙන් පාලන ස්ථරයම වැටේ.

මේ සියල්ල ගැන ඔබට කුමක් කළ හැකිද?

මහා සංක්‍රමණ යන්නෙන් අදහස් වන්නේ යටිතල ව්‍යූහය තුළ විශාල ක්‍රියාකාරකම්, සංක්‍රමණ සහ යෙදවීම් සිදු වන බවයි. සෑම සංක්‍රමණයකටම බහාලූම් අනුරූ මිනියන් වෙත ලබා දීමට සහ අසුරීමට, බහාලුම් දියත් කිරීමට සහ ආරම්භ කිරීමට, යනාදිය සඳහා යම් කාලයක් ගත විය හැක. එබැවින්, අඩු වැදගත් කාර්යයන්ට පෙර වඩා වැදගත් කාර්යයන් දියත් කිරීම යෝග්‍ය වේ.

අපට හුරුපුරුදු සේවාවල ධුරාවලිය දෙස නැවත බලමු සහ අපට පළමුව ක්‍රියාත්මක කිරීමට අවශ්‍ය කාර්යයන් තීරණය කිරීමට උත්සාහ කරමු.

ඇත්ත වශයෙන්ම, මේවා පරිශීලක ඉල්ලීම් සැකසීමට සෘජුවම සම්බන්ධ වන ක්‍රියාවලීන් වේ, එනම් නිෂ්පාදන. අපි මෙය පෙන්වා දෙන්නෙමු ස්ථානගත කිරීමේ ප්රමුඛත්වය - පෝලිමට පැවරිය හැකි අංකයක්. පෝලිමකට ඉහළ ප්‍රමුඛතාවයක් තිබේ නම්, එහි සේවාවන් පළමුව තබා ඇත.

නිෂ්පාදනයේදී අපි ඉහළ ප්‍රමුඛතා පවරමු, 0; කණ්ඩායම මත - ටිකක් අඩු, 100; නිෂ්ක්‍රීයව - ඊටත් වඩා අඩු, 200. ප්‍රමුඛතා ධූරාවලි ලෙස යොදනු ලැබේ. ධූරාවලියේ පහළ සියලුම කාර්යයන් සඳහා අනුරූප ප්‍රමුඛතාවයක් ඇත. අපට ප්‍රොඩ් ඇතුළත හැඹිලි ඉදිරිපසවලට පෙර දියත් කිරීමට අවශ්‍ය නම්, අපි හැඹිලි = 0 සහ ඉදිරිපස උප පෝලිම් = 1 වෙත ප්‍රමුඛතා පවරමු. උදාහරණයක් ලෙස, අපට අවශ්‍ය නම්, ප්‍රධාන ද්වාරය පළමුව පෙරමුණෙන් දියත් කළ යුතු අතර, සංගීත පෙරමුණ පමණි. පසුව, පසුව අපට දෙවැන්නට අඩු ප්‍රමුඛතාවයක් ලබා දිය හැකිය - 10.

ඊළඟ ගැටලුව සම්පත් හිඟකමයි. එබැවින්, උපකරණ විශාල ප්‍රමාණයක්, දත්ත මධ්‍යස්ථානයේ සම්පූර්ණ ශාලා අසාර්ථක වූ අතර, අපි බොහෝ සේවාවන් නැවත ආරම්භ කළ අතර දැන් සෑම කෙනෙකුටම ප්‍රමාණවත් සම්පත් නොමැත. ප්‍රධාන තීරනාත්මක සේවාවන් ක්‍රියාත්මක කිරීම සඳහා කැප කළ යුතු කාර්යයන් ඔබ තීරණය කළ යුතුය.

ස්ථානගත කිරීමේ ප්‍රමුඛතාවය මෙන් නොව, අපට සියලු කණ්ඩායම් කාර්යයන් අවිචාරවත් ලෙස කැප කළ නොහැක; ඒවායින් සමහරක් ද්වාරයෙහි ක්‍රියාකාරිත්වය සඳහා වැදගත් වේ. ඒ නිසා, අපි වෙනම ඉස්මතු කර ඇත පූර්වාරක්ෂාව ප්රමුඛත්වය කාර්යයන්. ස්ථානගත කළ විට, වැඩි ප්‍රමුඛතා කාර්යයක්, නිදහස් සගයන් නොමැති නම්, අඩු ප්‍රමුඛතා කාර්යයක්, එනම් නැවැත්විය හැක. මෙම අවස්ථාවේ දී, අඩු ප්‍රමුඛතාවයක් සහිත කාර්යයක් බොහෝ විට ස්ථානගතව පවතිනු ඇත, එනම් ප්‍රමාණවත් නිදහස් සම්පත් සහිත ඒ සඳහා සුදුසු සගයකු තවදුරටත් නොසිටිනු ඇත.

අපගේ ධූරාවලිය තුළ, 200 ට සමාන idle සඳහා ප්‍රමුඛතාවයක් සඳහන් කිරීම මඟින් ප්‍රොඩ් සහ කණ්ඩායම් කාර්යයන් නිෂ්ක්‍රීය කාර්යයන් පෙරීම හෝ නැවැත්වීම, නමුත් එකිනෙක නොව, පූර්වාපේක්‍ෂණ ප්‍රමුඛතාවයක් නියම කිරීම ඉතා සරල ය. ස්ථානගත කිරීමේ ප්‍රමුඛතාවයේ දී මෙන්ම, අපි වඩාත් සංකීර්ණ නීති විස්තර කිරීම සඳහා අපගේ ධුරාවලිය භාවිතා කළ හැක. උදාහරණයක් ලෙස, අපට ප්‍රධාන වෙබ් ද්වාරය සඳහා ප්‍රමාණවත් සම්පත් නොමැති නම්, අපි සංගීත ශ්‍රිතය කැප කරන බව පෙන්වා දෙමු, අනුරූප නෝඩ් සඳහා ප්‍රමුඛතාවය අඩු: 10.

සම්පූර්ණ DC අනතුරු

සම්පූර්ණ දත්ත මධ්‍යස්ථානය අසාර්ථක විය හැක්කේ ඇයි? මූලද්රව්යය. හොඳ පෝස්ට් එකක් වුණා සුළි කුණාටුව දත්ත මධ්‍යස්ථානයේ වැඩකටයුතුවලට බලපෑවේය. මූලද්‍රව්‍ය වරෙක බහුවිධයේ දෘෂ්ටි විද්‍යාව පුළුස්සා දැමූ නිවාස නොමැති පුද්ගලයින් ලෙස සැලකිය හැකි අතර දත්ත මධ්‍යස්ථානය වෙනත් වෙබ් අඩවි සමඟ සම්බන්ධතා සම්පූර්ණයෙන්ම නැති විය. අසාර්ථක වීමට හේතුව මානව සාධකයක් ද විය හැකිය: ක්රියාකරු විසින් සම්පූර්ණ දත්ත මධ්යස්ථානය වැටෙනු ඇති එවැනි විධානයක් නිකුත් කරනු ඇත. විශාල දෝෂයක් නිසා මෙය සිදු විය හැකිය. සාමාන්‍යයෙන් දත්ත මධ්‍යස්ථාන කඩා වැටීම සාමාන්‍ය දෙයක් නොවේ. මෙය අපට සෑම මාස කිහිපයකට වරක් සිදු වේ.

ඒවගේම අපි කරන්නේ #සජීවීව ට්වීට් කරන එක වලක්වන්න.

පළමු උපාය මාර්ගය හුදකලා වීමයි. එක් එක් වලාකුළු අවස්ථාවක් හුදකලා කර ඇති අතර එක් දත්ත මධ්‍යස්ථානයක පමණක් යන්ත්‍ර කළමනාකරණය කළ හැකිය. එනම්, දෝෂ හෝ වැරදි ක්‍රියාකරු විධානයන් හේතුවෙන් වලාකුළක් නැතිවීම එක් දත්ත මධ්‍යස්ථානයක් පමණක් අහිමි වීමයි. අපි මේ සඳහා සූදානම්: සියලුම දත්ත මධ්‍යස්ථානවල යෙදුමේ සහ දත්තවල අනුරූ පිහිටා ඇති අතිරික්ත ප්‍රතිපත්තියක් අප සතුව ඇත. අපි වැරදි-ඉවසන දත්ත සමුදායන් භාවිතා කරන අතර අසාර්ථක වීම් සඳහා වරින් වර පරීක්ෂා කරන්නෙමු.
අද සිට අපට දත්ත මධ්‍යස්ථාන හතරක් ඇත, එයින් අදහස් කරන්නේ එක් වලාකුළක වෙනම, සම්පූර්ණයෙන්ම හුදකලා වූ අවස්ථා හතරකි.

මෙම ප්රවේශය භෞතික අසමත් වීමෙන් ආරක්ෂා කිරීම පමණක් නොව, ක්රියාකරුගේ දෝෂ වලින් ආරක්ෂා විය හැක.

මානව සාධකය සමඟ තවත් කුමක් කළ හැකිද? ක්‍රියාකරුවෙකු වලාකුළට කිසියම් අමුතු හෝ භයානක විධානයක් ලබා දුන් විට, ඔහු කෙතරම් හොඳින් සිතුවාදැයි බැලීමට කුඩා ගැටලුවක් විසඳීමට හදිසියේම ඔහුගෙන් ඉල්ලා සිටිය හැක. උදාහරණයක් ලෙස, මෙය බොහෝ අනුරූ වල යම් ආකාරයක ස්කන්ධ නැවතුමක් නම් හෝ අමුතු විධානයක් නම් - අනුරූ ගණන අඩු කිරීම හෝ රූපයේ නම වෙනස් කිරීම, නව මැනිෆෙස්ටයේ අනුවාද අංකය පමණක් නොවේ.

ප්රතිඵල

එක් වලාකුළක සුවිශේෂී ලක්ෂණ:

• සේවා සහ බහාලුම් සඳහා ධූරාවලි සහ දෘශ්‍ය නම් කිරීමේ යෝජනා ක්‍රමය, කාර්යය කුමක්ද, එය සම්බන්ධ වන්නේ කුමක්ද සහ එය ක්‍රියා කරන්නේ කෙසේද සහ එයට වගකිව යුත්තේ කවුරුන්ද යන්න ඉතා ඉක්මනින් සොයා ගැනීමට ඔබට ඉඩ සලසයි.
• අපි අපේ අයදුම් කරනවා නිෂ්පාදන සහ කණ්ඩායම ඒකාබද්ධ කිරීමේ තාක්ෂණයයන්ත්‍ර බෙදාගැනීමේ කාර්යක්ෂමතාව වැඩි දියුණු කිරීම සඳහා මිනියන් මත කාර්යයන්. cpuset වෙනුවට අපි CPU කෝටා, කොටස්, CPU උපලේඛන ප්‍රතිපත්ති සහ Linux QoS භාවිතා කරමු.
• එකම යන්ත්‍රයක ධාවනය වන බහාලුම් සම්පූර්ණයෙන්ම හුදකලා කිරීමට නොහැකි වූ නමුත් ඒවායේ අන්‍යෝන්‍ය බලපෑම 20% තුළ පවතී.
• සේවා ධුරාවලියකට සංවිධානය කිරීම භාවිතයෙන් ස්වයංක්‍රීය ආපදා ප්‍රතිසාධනය සඳහා උපකාරී වේ ස්ථානගත කිරීම සහ පූර්වාරක්ෂාව ප්රමුඛතා.

නිති අසන පැණ

අපි සූදානම් කළ විසඳුමක් නොගත්තේ ඇයි?

• කාර්ය හුදකලාවේ විවිධ පන්තිවලට මිනියන් මත තැබූ විට විවිධ තර්ක අවශ්‍ය වේ. නිපැයුම් කාර්යයන් හුදෙක් සම්පත් වෙන් කිරීමෙන් තැබිය හැකි නම්, කුඩා යන්ත්‍රවල සම්පත්වල සත්‍ය ප්‍රයෝජනය නිරීක්ෂණය කරමින් කණ්ඩායම් සහ නිෂ්ක්‍රීය කාර්යයන් තැබිය යුතුය.
• කාර්යයන් මගින් පරිභෝජනය කරන සම්පත් සැලකිල්ලට ගැනීමේ අවශ්‍යතාවය, වැනි:
  • ජාල කලාප පළල;
  • වර්ග සහ තැටි "ස්පින්ඩල්".
• හදිසි ප්‍රතිචාර දැක්වීමේදී සේවාවන්හි ප්‍රමුඛතා දැක්වීමේ අවශ්‍යතාවය, සම්පත් සඳහා වන විධානවල අයිතිවාසිකම් සහ කෝටාවන්, එක් වලාකුළක ධූරාවලි පෝලිම් භාවිතයෙන් විසඳනු ලැබේ.
• හදිසි අනතුරු සහ සිද්ධීන් සඳහා ප්‍රතිචාර දැක්වීමේ කාලය අඩු කිරීම සඳහා බහාලුම් මානව නම් කිරීමේ අවශ්‍යතාවය
• සේවා සොයාගැනීමේ එක් වරක් පුළුල් ලෙස ක්‍රියාත්මක කිරීමේ නොහැකියාව; දෘඪාංග ධාරකවල සත්කාරකත්වය දරන කාර්යයන් සමඟ දිගු කාලයක් සහජීවනයෙන් සිටීමේ අවශ්‍යතාවය - බහාලුම් පහත සඳහන් “ස්ථිතික” IP ලිපින මගින් විසඳනු ලබන දෙයක් සහ එහි ප්‍රතිඵලයක් ලෙස විශාල ජාල යටිතල ව්‍යුහයක් සමඟ අද්විතීය ඒකාබද්ධ වීමේ අවශ්‍යතාවය.

මෙම සියලු කාර්යයන් සඳහා අපට ගැලපෙන පරිදි පවතින විසඳුම්වල සැලකිය යුතු වෙනස් කිරීම් අවශ්‍ය වන අතර, වැඩ ප්‍රමාණය තක්සේරු කිරීමෙන්, ආසන්න වශයෙන් එකම ශ්‍රම පිරිවැය සමඟ අපගේම විසඳුම සකස් කළ හැකි බව අපි තේරුම් ගත්තෙමු. නමුත් ඔබේ විසඳුම ක්‍රියාත්මක කිරීමට සහ සංවර්ධනය කිරීමට වඩාත් පහසු වනු ඇත - අපට අවශ්‍ය නොවන ක්‍රියාකාරීත්වයට සහාය වන අනවශ්‍ය වියුක්තයන් එහි අඩංගු නොවේ.

අවසාන පේළි කියවන අයට, ඔබේ ඉවසීමට සහ අවධානයට ස්තූතියි!

මූලාශ්රය: www.habr.com