මාධ්‍ය අන්තර්ගතයකින් තොරව නවීන වෙබය සිතාගත නොහැකි තරම්ය: සෑම ආච්චි කෙනෙකුටම පාහේ ස්මාර්ට් ජංගම දුරකතනයක් ඇත, සෑම කෙනෙකුම සමාජ ජාල වල සිටින අතර නඩත්තු කිරීමේ අක්රිය කාලය සමාගම් සඳහා මිල අධික වේ. සමාගමේ කතාවේ පිටපතක් මෙන්න ඇය දෘඩාංග විසඳුමක් භාවිතා කරමින් ඡායාරූප බෙදා හැරීම සංවිධානය කළ ආකාරය, ක්‍රියාවලියේදී ඇය මුහුණ දුන් කාර්ය සාධන ගැටළු මොනවාද, ඒවාට හේතු වූ දේ සහ මෙම ගැටළු Nginx මත පදනම් වූ මෘදුකාංග විසඳුමක් භාවිතයෙන් විසඳා ගත් ආකාරය, සියලු මට්ටම්වල වැරදි ඉවසීම සහතික කරයි () ඔලෙග්ගේ කතාවේ කතුවරුන්ට අපි ස්තූතිවන්ත වෙමු සමුළුවේදී ඔවුන්ගේ අත්දැකීම් බෙදාගත් එෆිමෝවා සහ ඇලෙක්සැන්ඩ්‍රා ඩිමෝවා .
— අපි ඡායාරූප ගබඩා කරන ආකාරය සහ හැඹිලිගත කරන ආකාරය පිළිබඳ කුඩා හැඳින්වීමකින් පටන් ගනිමු. අපි ඒවා ගබඩා කරන ස්ථරයක් සහ අපි ඡායාරූප හැඹිලිගත කරන ස්ථරයක් ඇත. ඒ අතරම, අපට ඉහළ උපක්‍රම අනුපාතයක් ලබා ගැනීමට සහ ගබඩා කිරීමේ බර අඩු කිරීමට අවශ්ය නම්, තනි පරිශීලකයෙකුගේ සෑම ඡායාරූපයක්ම එක් හැඹිලි සේවාදායකයක තිබීම අපට වැදගත් වේ. එසේ නොමැති නම්, අපට සේවාදායකයන් ඇති තරම් වාර ගණනක් තැටි ස්ථාපනය කිරීමට සිදුවනු ඇත. අපගේ උපක්‍රම අනුපාතය 99% ක් පමණ වේ, එනම්, අපි අපගේ ගබඩාවේ බර 100 ගුණයකින් අඩු කරමින් සිටිමු, මෙය සිදු කිරීම සඳහා, මීට වසර 10 කට පෙර, මේ සියල්ල ගොඩනඟන විට, අපට සේවාදායකයන් 50 ක් තිබුණි. ඒ අනුව, මෙම ඡායාරූප සැපයීම සඳහා, අපට මෙම සේවාදායකයන් සපයන බාහිර වසම් 50ක් අවශ්ය විය.
ස්වාභාවිකවම, ප්‍රශ්නය වහාම පැන නැගුනි: අපගේ එක් සේවාදායකයක් ක්රියා විරහිත වී ලබා ගත නොහැකි වුවහොත්, අපට අහිමි වන්නේ ගමනාගමනයෙන් කුමන කොටසද? අපි වෙළඳපොලේ ඇති දේ දෙස බලා අපගේ සියලු ගැටලු විසඳන පරිදි දෘඩාංග කැබැල්ලක් මිලදී ගැනීමට තීරණය කළෙමු. තේරීම F5-ජාල සමාගමේ විසඳුම මත වැටුණි (මාර්ගය වන විට, මෑතකදී NGINX, Inc මිලදී ගන්නා ලදී): BIG-IP දේශීය රථවාහන කළමනාකරු.
මෙම දෘඪාංග කැබැල්ල (LTM) කරන්නේ කුමක්ද: එය යකඩ රවුටරයක් වන අතර එහි බාහිර වරායන්හි යකඩ අතිරික්තයක් ඇති කරන අතර ජාල ස්ථලකය මත පදනම්ව ගමනාගමනය කිරීමට ඔබට ඉඩ සලසයි, සමහර සැකසුම් මත, සහ සෞඛ්ය පරීක්ෂාවන් සිදු කරයි. මෙම දෘඩාංග කෑල්ල වැඩසටහන්ගත කළ හැකි බව අපට වැදගත් විය. ඒ අනුව, නිශ්චිත හැඹිලියකින් නිශ්චිත පරිශීලකයෙකුගේ ඡායාරූප සේවය කරන ආකාරය පිළිබඳ තර්කනය අපට විස්තර කළ හැකිය. ඒක මොන වගේද? එක ඩොමේන් එකක, එක IP එකක ඉන්ටර්නෙට් බලල, ssl offload කරන, http request parses කරන, IRule එකෙන් cache number එකක් තෝරල, එතනට Traffic යන්න දෙන Hardware කෑල්ලක් තියෙනවා. ඒත් එක්කම සෞඛ්ය පරීක්ෂණ කරනවා, සමහර යන්ත්‍ර නැති උනොත් අපි ඒක හැදුවේ එක බැකප් සර්වර් එකකට ට්‍රැෆික් යන විදියට. වින්‍යාස කිරීමේ දෘෂ්ටි කෝණයකින්, ඇත්ත වශයෙන්ම, සමහර සූක්ෂ්මතා ඇත, නමුත් පොදුවේ සියල්ල තරමක් සරල ය: අපි කාඩ්පතක් ලියාපදිංචි කරමු, ජාලයේ අපගේ IP වෙත නිශ්චිත අංකයක ලිපි හුවමාරුව, අපි වරාය 80 ට සවන් දෙන බව අපි කියමු. සහ 443, අපි පවසන්නේ සේවාදායකය නොමැති නම්, ඔබ උපස්ථ එක වෙත ගමනාගමනය යැවිය යුතු බවයි, මෙම අවස්ථාවේදී 35 වන අතර, මෙම ගෘහ නිර්මාණ ශිල්පය විසුරුවා හැරිය යුතු ආකාරය පිළිබඳ තර්ක සමූහයක් අපි විස්තර කරමු. එකම ගැටළුව වූයේ දෘඪාංග වැඩසටහන්ගත කර ඇති භාෂාව Tcl වීමයි. යමෙක් මෙය මතක තබා ගන්නේ නම්... මෙම භාෂාව ක්‍රමලේඛනයට පහසු භාෂාවකට වඩා ලිවීමට පමණි:
අපට ලැබුණේ කුමක්ද? අපගේ යටිතල පහසුකම් ඉහළ මට්ටමක පවතින බව සහතික කරන, අපගේ සියලු ගමනාගමන මාර්ග සපයන, සෞඛ්ය ප්‍රතිලාභ ලබා දෙන සහ සාධාරණව ක්රියා කරන දෘඪාංග කැබැල්ලක් අපට ලැබුණි. එපමණක් නොව, එය සෑහෙන කාලයක් තිස්සේ ක්රියා කරයි: පසුගිය වසර 10 තුළ ඒ ගැන පැමිණිලි නොමැත. 2018 ආරම්භය වන විට, අපි දැනටමත් තත්පරයකට ඡායාරූප 80k පමණ යවමු. මෙය අපගේ දත්ත මධ්‍යස්ථාන දෙකෙන්ම ගිගාබිට් 80ක පමණ තදබදයකි.
කෙසේ වුවද…
2018 ආරම්භයේදී, අපි ප්‍රස්ථාරවල කැත පින්තූරයක් දුටුවෙමු: ඡායාරූප යැවීමට ගත වූ කාලය පැහැදිලිවම වැඩි වී ඇත. ඒ වගේම ඒක අපිට ගැලපෙන එක නැවැත්තුවා. ගැටළුව වන්නේ මෙම හැසිරීම දර්ශනය වූයේ තදබදයේ උච්චතම අවස්ථාවන්හිදී පමණි - අපගේ සමාගම සඳහා මෙය ඉරිදා සිට සඳුදා දක්වා රාත්‍රියයි. නමුත් ඉතිරි කාලය තුළ පද්ධතිය සුපුරුදු පරිදි හැසිරුණු අතර, අසාර්ථක වීමේ සලකුණු නොමැත.
කෙසේ වෙතත්, ගැටලුව විසඳිය යුතුව තිබුණි. අපි හැකි බාධක හඳුනාගෙන ඒවා ඉවත් කිරීමට පටන් ගත්තෙමු. පළමුවෙන්ම, ඇත්ත වශයෙන්ම, අපි බාහිර උඩුගත කිරීම් පුළුල් කර, අභ්‍යන්තර උඩුගත කිරීම් පිළිබඳ සම්පූර්ණ විගණනයක් සිදු කර, හැකි සෑම බාධකයක්ම සොයා ගත්තෙමු. නමුත් මේ සියල්ල පැහැදිලි ප්රතිඵලයක් ලබා දුන්නේ නැත, ගැටලුව අතුරුදහන් නොවේ.
විය හැකි තවත් බාධාවක් වූයේ ඡායාරූප හැඹිලිවල ක්‍රියාකාරිත්වයයි. සමහර විට ගැටලුව ඔවුන් මත පවතින බව අපි තීරණය කළෙමු. හොඳයි, අපි කාර්ය සාධනය පුළුල් කළා - ඡායාරූප හැඹිලි මත ප්රධාන වශයෙන් ජාල වරායන්. නමුත් නැවතත් පැහැදිලි දියුණුවක් දක්නට නොලැබුණි. අවසානයේදී, අපි LTM හි ක්‍රියාකාරිත්වය කෙරෙහි දැඩි අවධානයක් යොමු කළ අතර, මෙහිදී අපි ප්‍රස්ථාරවල දුක්ඛිත පින්තූරයක් දුටුවෙමු: සියලුම CPU වල පැටවීම සුමටව යාමට පටන් ගනී, නමුත් හදිසියේම සානුවකට පැමිණේ. ඒ අතරම, LTM සෞඛ්ය පරීක්ෂණ සහ උඩුගත කිරීම්වලට ප්‍රමාණවත් ලෙස ප්‍රතිචාර දැක්වීම නතර කරන අතර ඒවා අහඹු ලෙස අක්රිය කිරීමට පටන් ගනී, එය බරපතල කාර්ය සාධන පිරිහීමට තුඩු දෙයි.
එනම්, අපි ගැටලුවේ මූලාශ්රය හඳුනාගෙන ඇත, බාධකය හඳුනාගෙන ඇත. අප කරන්නේ කුමක්ද යන්න තීරණය කිරීමට ඉතිරිව ඇත.
අපට කළ හැකි පළමු, වඩාත්ම පැහැදිලි දෙය නම් කෙසේ හෝ LTM නවීකරණය කිරීමයි. නමුත් මෙහි සමහර සූක්ෂ්මතා ඇත, මෙම දෘඩාංගය තරමක් අද්විතීය බැවින්, ඔබ ළඟම ඇති සුපිරි වෙළඳසැලට ගොස් එය මිලදී නොගනු ඇත. මෙය වෙනම කොන්ත්රාත්තුවක්, වෙනම බලපත්ර කොන්ත්රාත්තුවක් වන අතර, එය බොහෝ කාලයක් ගතවනු ඇත. දෙවන විකල්පය නම්, ඔබ ගැන සිතීම ආරම්භ කිරීම, ඔබේම සංරචක භාවිතයෙන් ඔබේම විසඳුමක් ඉදිරිපත් කිරීම, වඩාත් සුදුසු විවෘත ප්රවේශ වැඩසටහනක් භාවිතා කිරීමයි. ඉතිරිව ඇත්තේ පරිශීලකයින්ට ප්‍රමාණවත් ඡායාරූප නොලැබුණු නිසා අපි මේ සඳහා හරියටම තෝරා ගන්නේ කුමක්ද සහ මෙම ගැටළුව විසඳීම සඳහා කොපමණ කාලයක් ගත කරනවාද යන්න තීරණය කිරීමයි. ඒ නිසා අපි මේ සියල්ල ඉතා ඉක්මනින් කළ යුතුයි කියලා කෙනෙක් ඊයේ කියන්න පුළුවන්.
කාර්යය "හැකි ඉක්මනින් යමක් කරන්න සහ අප සතුව ඇති දෘඩාංග භාවිතා කරන්න" ලෙස පෙනෙන බැවින්, අප සිතූ පළමු දෙය නම්, ඉතා බලවත් නොවන යන්ත්‍ර කිහිපයක් ඉදිරිපසින් ඉවත් කර, Nginx එහි තැබීමයි, එය සමඟ අපි කරන්නේ කෙසේදැයි අපි දනිමු. වැඩ කර දෘඪාංග භාවිතා කළ එකම තර්කය ක්‍රියාත්මක කිරීමට උත්සාහ කරන්න. එනම්, ඇත්ත වශයෙන්ම, අපි අපගේ දෘඩාංග අත්හැර, අපට වින්යාසගත කළ යුතු තවත් සේවාදායකයන් 4 ක් ස්ථාපනය කර, ඒවා සඳහා බාහිර වසම් නිර්මාණය කර, එය වසර 10 කට පෙර තිබූ ආකාරයටම ... මෙම යන්ත්‍ර වැටුණහොත් අපට ලබා ගැනීමේ හැකියාව ටිකක් අහිමි විය, නමුත් තවමත් අඩු, ඔවුන් දේශීයව අපගේ පරිශීලකයින්ගේ ගැටලුව විසඳා ඇත.
ඒ අනුව, තර්කනය එලෙසම පවතී: අපි Nginx ස්ථාපනය කරමු, එය SSL-Offload කළ හැකිය, අපට කෙසේ හෝ routing logic වැඩසටහන්ගත කළ හැකිය, වින්‍යාසය තුළ සෞඛ්ය-පරීක්ෂා කිරීම් සහ අපට පෙර තිබූ තර්කනය අනුපිටපත් කළ හැකිය.
අපි configs ලියන්න වාඩි වෙමු. මුලදී සෑම දෙයක්ම ඉතා සරල බව පෙනෙන්නට තිබුණත්, අවාසනාවකට මෙන්, සෑම කාර්යයක් සඳහාම අත්පොත් සොයා ගැනීම ඉතා අපහසුය. එබැවින්, “ඡායාරූප සඳහා Nginx වින්‍යාස කරන්නේ කෙසේද” ගූගල් කිරීම අපි නිර්දේශ නොකරමු: නිල ලේඛන වෙත යොමු වීම වඩා හොඳය, එය ස්පර්ශ කළ යුත්තේ කුමන සැකසුම්ද යන්න පෙන්වයි. නමුත් නිශ්චිත පරාමිතිය ඔබම තෝරා ගැනීම වඩා හොඳය. හොඳයි, එවිට සෑම දෙයක්ම සරලයි: අපි අප සතුව ඇති සේවාදායකයන් විස්තර කරමු, අපි සහතික විස්තර කරමු ... නමුත් වඩාත්ම සිත්ගන්නා කරුණ නම්, ඇත්ත වශයෙන්ම, මාර්ගගත කිරීමේ තර්කනයමයි.
මුලදී අපට පෙනුනේ අපි සරලව අපගේ ස්ථානය විස්තර කරන බවත්, එහි ඇති අපගේ ඡායාරූප හැඹිලි අංකයට ගැළපෙන බවත්, අපගේ අත් හෝ උත්පාදක යන්ත්‍රයක් භාවිතා කර අපට උඩුගත කිරීම් කීයක් අවශ්ය දැයි විස්තර කරන බවත්, එක් එක් උඩු ගංවතුර තුළ අපි ගමනාගමනය කළ යුතු සේවාදායකය සඳහන් කරන බවයි. යන්න, සහ උපස්ථ සේවාදායකයක් - ප්රධාන සේවාදායකය නොමැති නම්:
නමුත්, බොහෝ විට, සෑම දෙයක්ම ඉතා සරල නම්, අපි කිසිවක් නොකියා ගෙදර යන්නෙමු. අවාසනාවකට, පෙරනිමි Nginx සැකසුම් සමඟ, සාමාන්‍යයෙන්, වසර ගණනාවක් සංවර්ධනය කර ඇති අතර මෙම අවස්ථාව සඳහා සම්පූර්ණයෙන්ම සුදුසු නොවේ... වින්‍යාසය මේ ආකාරයෙන් පෙනේ: සමහර උඩුගත සේවාදායකයකට ඉල්ලීම් දෝෂයක් හෝ කල් ඉකුත්වීමක් තිබේ නම්, Nginx සැමවිටම ඊළඟ එකට ගමනාගමනය මාරු කරයි. එපමනක් නොව, පළමු අසාර්ථක වීමෙන් පසුව, තත්පර 10 ක් ඇතුළත, වැරදීමකින් සහ කල් ඉකුත්වීමෙන් සේවාදායකය ද අක්රිය වනු ඇත - මෙය කිසිදු ආකාරයකින් වින්යාසගත කළ නොහැක. එනම්, අපි upstream directive හි කල් ඉකුත් වීමේ විකල්පය ඉවත් කළහොත් හෝ නැවත සකසන්නේ නම්, Nginx මෙම ඉල්ලීම ක්‍රියාවට නංවන්නේ නැති අතර ඉතා හොඳ නොවන දෝෂයකින් ප්‍රතිචාර දක්වනු ඇතත්, සේවාදායකය වසා දමනු ඇත.
මෙය වළක්වා ගැනීම සඳහා, අපි කරුණු දෙකක් කළෙමු:
අ) ඔවුන් මෙය අතින් සිදු කිරීම Nginx හට තහනම් කර ඇත - සහ අවාසනාවකට, මෙය කළ හැකි එකම ක්‍රමය වන්නේ max fails සැකසුම් සරලව සැකසීමයි.
ආ) වෙනත් ව්‍යාපෘති වලදී අපි පසුබිම් සෞඛ්ය පරීක්ෂා කිරීමට ඉඩ සලසන මොඩියුලයක් භාවිතා කරන බව අපට මතකයි - ඒ අනුව, හදිසි අනතුරකදී අක්රිය කාලය අවම වන පරිදි අපි නිතර සෞඛ්ය පරීක්ෂා කළෙමු.
අවාසනාවකට මෙන්, මෙයද නොවේ, මක්නිසාද යත්, මෙම යෝජනා ක්‍රමයේ ක්‍රියාකාරිත්වයේ පළමු සති දෙකෙහි වචනාර්ථයෙන් පෙන්නුම් කළේ TCP සෞඛ්ය පරීක්ෂාව ද විශ්වාස කළ නොහැකි දෙයක් බවයි: උඩුගං බලා සේවාදායකයේ එය Nginx හෝ D-state හි Nginx නොවිය හැක. මෙම අවස්ථාවේදී කර්නලය සම්බන්ධතාවය පිළිගනී, සෞඛ්ය පරීක්ෂාව සමත් වනු ඇත, නමුත් ක්රියා නොකරනු ඇත. එමනිසා, අපි මෙය වහාම සෞඛ්ය පිරික්සුම් http සමඟ ප්‍රතිස්ථාපනය කර, විශේෂිත එකක් සෑදුවෙමු, එය 200 ආපසු ලබා දෙන්නේ නම්, මෙම ස්ක්‍රිප්ට් එකේ සියල්ල ක්‍රියාත්මක වේ. ඔබට අමතර තර්කයක් කළ හැකිය - උදාහරණයක් ලෙස, හැඹිලි සේවාදායකයන් සම්බන්ධයෙන්, ගොනු පද්ධතිය නිවැරදිව සවි කර ඇත්දැයි පරීක්ෂා කරන්න:
මේ මොහොතේ පරිපථය දෘඩාංග කළ දේ සම්පූර්ණයෙන්ම පුනරුච්චාරණය කිරීම හැර මෙය අපට ගැලපේ. ඒත් අපිට ඕන වුණේ මීට වඩා හොඳට කරන්න. මීට පෙර, අපට එක් උපස්ථ සේවාදායකයක් තිබූ අතර මෙය බොහෝ විට එතරම් හොඳ නැත, මන්ද ඔබට සේවාදායකයන් සියයක් තිබේ නම්, එකවර කිහිපයක් අසමත් වූ විට, එක් උපස්ථ සේවාදායකයක් බර සමඟ සාර්ථකව කටයුතු කිරීමට අපහසුය. එබැවින්, සියලුම සේවාදායකයන් හරහා වෙන් කිරීම බෙදා හැරීමට අපි තීරණය කළෙමු: අපි සරලව තවත් වෙනම උඩුගත කිරීමක් සාදා, ඔවුන්ට සේවය කළ හැකි බරට අනුකූලව යම් පරාමිතීන් සමඟ එහි සියලුම සේවාදායකයන් ලියා, අප සතුව පෙර තිබූ සෞඛ්ය පරීක්ෂාවන්ම එකතු කළෙමු:
එක් upstream එකක් තුළ තවත් upstream එකකට යාමට නොහැකි නිසා, අපි නිවැරදි, අවශ්ය ඡායාරූප හැඹිලිය සරලව පටිගත කළ ප්රධාන උඩු ප්‍රවාහය නොමැති නම්, අපි දෝෂ_පිටුව හරහා ආපසු හැරීමට ගිය බව සහතික කර ගැනීම අවශ්ය විය. අපි උපස්ථ උඩු ප්‍රවාහයට ගිය තැන:
වචනාර්ථයෙන් සේවාදායකයන් හතරක් එකතු කිරීමෙන් අපට ලැබුණේ මෙයයි: අපි භාරයේ කොටසක් ප්‍රතිස්ථාපනය කළෙමු - අපි එය LTM වෙතින් මෙම සේවාදායකයන්ට ඉවත් කර, සම්මත දෘඩාංග සහ මෘදුකාංග භාවිතා කරමින් එම තර්කය එහි ක්‍රියාත්මක කර, මෙම සේවාදායකයන්ට හැකි ප්‍රසාද දීමනාව වහාම ලබා ගත්තෙමු. ඒවා අවශ්ය ප්‍රමාණයට සරලව සැපයිය හැකි නිසා පරිමාණය කළ යුතුය. හොඳයි, එකම සෘණාත්මක දෙය නම් අපට බාහිර පරිශීලකයින් සඳහා ඉහළ ලබා ගැනීමේ හැකියාව අහිමි වීමයි. නමුත් ඒ මොහොතේම අපට මේක බිල්ලට දෙන්න සිදු වුණා, ඒ ප්‍රශ්නය වහා විසඳිය යුතු නිසා. ඉතින්, අපි බරෙන් කොටසක් ඉවත් කළෙමු, ඒ වන විට එය 40% ක් පමණ විය, LTM ට හොඳක් දැනුණි, සහ ගැටලුව ආරම්භ වී සති දෙකකට පසුව, අපි තත්පරයකට ඉල්ලීම් 45k නොව 55k යැවීමට පටන් ගත්තෙමු. ඇත්ත වශයෙන්ම, අපි 20% කින් වර්ධනය වී ඇත - මෙය පැහැදිලිවම අපි පරිශීලකයාට ලබා නොදුන් ගමනාගමනයයි. ඊට පසු, ඔවුන් ඉතිරි ගැටළුව විසඳන්නේ කෙසේද යන්න ගැන සිතීමට පටන් ගත්හ - ඉහළ බාහිර ප්‍රවේශ්‍යතාවය සහතික කිරීම සඳහා.
අපට යම් විරාමයක් ඇති වූ අතර, මේ සඳහා අප භාවිතා කරන විසඳුම කුමක්දැයි අපි සාකච්ඡා කළෙමු. DNS භාවිතා කරමින් විශ්වසනීයත්වය සහතික කිරීම සඳහා යෝජනා තිබුනා, ගෙදර ලියන ලද ස්ක්‍රිප්ට් කිහිපයක්, ගතික රවුටින් ප්‍රොටෝකෝල භාවිතා කරමින් ... බොහෝ විකල්ප ඇත, නමුත් සැබවින්ම විශ්වාසදායක ඡායාරූප බෙදා හැරීම සඳහා, ඔබ මෙය නිරීක්ෂණය කරන වෙනත් ස්ථරයක් හඳුන්වා දිය යුතු බව දැනටමත් පැහැදිලි විය. . අපි මේ යන්ත්‍රවලට කිව්වේ ෆොටෝ ඩිරෙක්ටර් කියලා. අපි විශ්වාසය තැබූ මෘදුකාංගය Keepalived:
ආරම්භ කිරීමට, Keepalived සමන්විත වන්නේ කුමක් ද? පළමුවැන්න නම් ජාලකරුවන්ට බහුලව දන්නා VRRP ප්‍රොටෝකෝලය, සේවාලාභීන් සම්බන්ධ වන බාහිර IP ලිපිනයට වැරදි ඉවසීමක් සපයන ජාල උපකරණ මත පිහිටා ඇත. දෙවන කොටස IPVS, IP අතථ්‍ය සේවාදායකය, ඡායාරූප රවුටර අතර සමතුලිත කිරීම සහ මෙම මට්ටමේ දෝෂ ඉවසීම සහතික කිරීම සඳහා වේ. සහ තෙවන - සෞඛ්ය පරීක්ෂාවන්.
අපි පළමු කොටස සමඟ ආරම්භ කරමු: VRRP - එය පෙනෙන්නේ කෙසේද? සේවාදායකයන් සම්බන්ධ වන dns badoocdn.com හි ප්‍රවේශයක් ඇති යම් අතථ්‍ය IP එකක් ඇත. යම් අවස්ථාවක, අපට එක් සේවාදායකයක IP ලිපිනයක් තිබේ. Keepalived පැකට් VRRP ප්‍රොටෝකෝලය භාවිතයෙන් සේවාදායකයන් අතර ක්‍රියාත්මක වන අතර, ප්‍රධානියා රේඩාර් වෙතින් අතුරුදහන් වුවහොත් - සේවාදායකය නැවත ආරම්භ කර හෝ වෙනත් දෙයක් නම්, උපස්ථ සේවාදායකය ස්වයංක්‍රීයව මෙම IP ලිපිනය ලබා ගනී - අතින් ක්රියා අවශ්ය නොවේ. ස්වාමියා සහ උපස්ථය අතර වෙනස ප්රධාන වශයෙන් ප්‍රමුඛතාවයයි: එය වැඩි වන තරමට යන්ත්‍රය ප්‍රධානියා බවට පත්වීමේ අවස්ථාව වැඩි වේ. ඉතා විශාල වාසියක් නම්, ඔබට සේවාදායකයේම IP ලිපින වින්‍යාස කිරීමට අවශ්ය නොවීම, ඒවා වින්‍යාසය තුළ විස්තර කිරීම ප්‍රමාණවත් වන අතර, IP ලිපින සඳහා අභිරුචි මාර්ගගත කිරීමේ නීති කිහිපයක් අවශ්ය නම්, මෙය කෙලින්ම වින්‍යාසය තුළ විස්තර කර ඇත, VRRP පැකේජයේ විස්තර කර ඇති ආකාරයටම වාක්‍ය ඛණ්ඩය. ඔබට නුහුරු නුපුරුදු දේවල් හමු නොවනු ඇත.
මෙය ප්රායෝගිකව පෙනෙන්නේ කෙසේද? එක් සේවාදායකයක් අසමත් වුවහොත් කුමක් සිදුවේද? මාස්ටර් අතුරුදහන් වූ වහාම, අපගේ උපස්ථය වෙළඳ දැන්වීම් ලැබීම නතර කර ස්වයංක්‍රීයව ප්‍රධානියා බවට පත්වේ. ටික වේලාවකට පසු, අපි මාස්ටර් අලුත්වැඩියා කර, නැවත පණ ගැන්වීම, Keepalived ඉහළ නැංවීම - දැන්වීම් උපස්ථයට වඩා ඉහළ ප්‍රමුඛතාවයකින් පැමිණේ, සහ උපස්ථය ස්වයංක්‍රීයව ආපසු හැරේ, IP ලිපින ඉවත් කරයි, අතින් ක්රියා කිරීම අවශ්ය නොවේ.
මේ අනුව, අපි බාහිර IP ලිපිනයේ වැරදි ඉවසීම සහතික කර ඇත. මීළඟ කොටස නම් බාහිර IP ලිපිනයේ සිට දැනටමත් අවසන් කරන ඡායාරූප රවුටර දක්වා ගමනාගමනය කෙසේ හෝ සමතුලිත කිරීමයි. සමතුලිත ප්‍රොටෝකෝල සමඟ සෑම දෙයක්ම ඉතා පැහැදිලිය. මෙය සරල රවුන්ඩ් රොබින් එකක් හෝ තරමක් සංකීර්ණ දේවල්, wrr, ලැයිස්තු සම්බන්ධතාවය සහ යනාදියයි. මෙය මූලික වශයෙන් ලේඛනගතව විස්තර කර ඇත, විශේෂ කිසිවක් නොමැත. නමුත් බෙදා හැරීමේ ක්‍රමය ... මෙන්න අපි ඔවුන්ගෙන් එකක් තෝරා ගත්තේ මන්දැයි අපි සමීපව බලමු. ඒවා නම් NAT, Direct Routing සහ TUN ය. කාරණය නම් අපි වහාම අඩවි වලින් ගිගාබිට් 100 ක ගමනාගමනය ලබා දීමට සැලසුම් කළෙමු. ඔබ ඇස්තමේන්තු කරන්නේ නම්, ඔබට ගිගාබිට් කාඩ්පත් 10 ක් අවශ්ය වේ, හරිද? එක් සේවාදායකයක් තුළ ගිගාබිට් කාඩ්පත් 10 ක් දැනටමත් අවම වශයෙන් අපගේ "සම්මත උපකරණ" සංකල්පයෙන් ඔබ්බට ගොස් ඇත. ඊට පස්සේ අපිට මතක් වුණා අපි ට්‍රැෆික් ටිකක් දෙන්නේ නැහැ, අපි ඡායාරූප දෙනවා කියලා.
විශේෂත්වය කුමක්ද? - පැමිණෙන සහ පිටතට යන ගමනාගමනය අතර විශාල වෙනසක්. එන ගමනාගමනය ඉතා කුඩායි, පිටතට යන ගමනාගමනය ඉතා විශාලයි:
මෙම ප්‍රස්ථාර දෙස බැලුවහොත් ඔබට පෙනෙන්නේ අධ්‍යක්ෂකවරයාට තත්පරයට 200 MB පමණ ලැබෙන මේ මොහොතේ මෙය ඉතා සාමාන්‍ය දිනයක් බවයි. අපි තත්පරයකට 4,500 MB ආපසු ලබා දෙන්නෙමු, අපගේ අනුපාතය ආසන්න වශයෙන් 1/22 වේ. සේවක සේවාදායකයන් 22 කට පිටතට යන ගමනාගමනය සම්පූර්ණයෙන්ම සැපයීමට, අපට අවශ්ය වන්නේ මෙම සම්බන්ධතාවය පිළිගන්නා එකක් පමණක් බව දැනටමත් පැහැදිලිය. සෘජු මාර්ගගත කිරීමේ ඇල්ගොරිතම අපගේ ආධාරයට පැමිණෙන්නේ මෙහිදීය.
ඒක මොන වගේද? අපගේ ඡායාරූප අධ්යක්ෂ, ඔහුගේ වගුව අනුව, ඡායාරූප රවුටර වෙත සම්බන්ධතා සම්ප්රේෂණය කරයි. නමුත් ඡායාරූප රවුටර අන්තර්ජාලය වෙත ආපසු ගමනාගමනය යවයි, එය සේවාදායකයා වෙත යවන්න, එය ඡායාරූප අධ්‍යක්ෂවරයා හරහා ආපසු නොයනු ඇත, මේ අනුව, අවම යන්ත්‍ර ගණනකින්, අපි සම්පූර්ණ දෝෂ ඉවසීම සහ සියලු ගමනාගමනය පොම්ප කිරීම සහතික කරමු. වින්‍යාසය තුළ එය මේ ආකාරයෙන් පෙනේ: අපි ඇල්ගොරිතම නියම කරමු, අපගේ නඩුවේදී එය සරල rr වේ, සෘජු මාර්ගගත කිරීමේ ක්‍රමය සපයන අතර පසුව සියලුම සැබෑ සේවාදායකයන් ලැයිස්තුගත කිරීමට පටන් ගනී, ඒවායින් කීයක් තිබේද යන්න. මෙම තදබදය තීරණය කරනු ඇත. අපට එහි තවත් සේවාදායකයන් එකක් හෝ දෙකක් තිබේ නම්, හෝ සේවාදායකයන් කිහිපයක් තිබේ නම්, එවැනි අවශ්‍යතාවයක් පැන නගී - අපි මෙම කොටස වින්‍යාසයට එකතු කරන අතර ඕනෑවට වඩා කරදර නොවන්න. සැබෑ සේවාදායකයන්ගේ පැත්තෙන්, ඡායාරූප රවුටරයේ පැත්තෙන්, මෙම ක්‍රමයට වඩාත්ම අවම වින්‍යාසය අවශ්ය වේ, එය ප්‍රලේඛනයේ පරිපූර්ණ ලෙස විස්තර කර ඇති අතර එහි අන්තරායන් නොමැත.
විශේෂයෙන් හොඳ දෙය නම්, එවැනි විසඳුමක් දේශීය ජාලයේ රැඩිකල් ප්‍රතිනිර්මාණය කිරීමක් අදහස් නොකරයි; මෙය අපට වැදගත් විය; අපට මෙය අවම පිරිවැයකින් විසඳා ගැනීමට සිදු විය. බැලුවොත් , එතකොට අපි බලමු ඒක මොන වගේද කියලා. මෙන්න අපට නිශ්චිත අතථ්‍ය සේවාදායකයක් ඇත, 443 වරායේ, සවන් දෙයි, සම්බන්ධතාවය පිළිගනී, සියලුම ක්‍රියාකාරී සේවාදායකයන් ලැයිස්තුගත කර ඇත, සහ සම්බන්ධතාවය ලබා දීම හෝ ගැනීම එකම බව ඔබට දැක ගත හැකිය. අපි එකම අතථ්‍ය සේවාදායකයේ සංඛ්‍යාලේඛන දෙස බැලුවහොත්, අපට එන පැකට්, එන සම්බන්ධතා ඇත, නමුත් පිටතට යන ඒවා කිසිසේත් නැත. පිටතට යන සම්බන්ධතා කෙලින්ම සේවාදායකයා වෙත යයි. හරි, අපට එය අසමතුලිත කිරීමට හැකි විය. දැන්, අපේ ෆොටෝ රවුටරයක් අසාර්ථක වුවහොත් කුමක් සිදුවේද? සියල්ලට පසු, යකඩ යකඩ ය. එය කර්නල් භීතියට යා හැකිය, එය කැඩී යා හැක, බල සැපයුම දැවී යා හැක. කිසිවක්. සෞඛ්ය පරීක්ෂණ අවශ්ය වන්නේ එබැවිනි. ඒවා ව්‍යාපාරික තර්කනය පවා පරීක්ෂා කරන සමහර ගෙදර-ලිඛිත ස්ක්‍රිප්ට් දක්වා වරාය විවෘතව ඇති ආකාරය හෝ වඩාත් සංකීර්ණ දෙයක් පරීක්ෂා කිරීම තරම් සරල විය හැකිය.
අපි අතරමග කොතැනක හෝ නතර විය: අපට නිශ්චිත ස්ථානයකට https ඉල්ලීමක් තිබේ, ස්ක්‍රිප්ටය ලෙස හැඳින්වේ, එය 200 වැනි ප්‍රතිචාරයක් සමඟ ප්‍රතිචාර දක්වන්නේ නම්, මෙම සේවාදායකය සමඟ සියල්ල හොඳින් ඇති බවත්, එය සජීවී බවත්, තරමක් ක්‍රියාත්මක කළ හැකි බවත් අපි විශ්වාස කරමු. පහසුවෙන්.
මෙය නැවතත්, ප්රායෝගිකව පෙනෙන්නේ කෙසේද? නඩත්තු කිරීම සඳහා සේවාදායකය අක්රිය කරමු - උදාහරණයක් ලෙස BIOS දැල්වීම. ලොග් වලදී, අපට වහාම කල් ඉකුත්වීමක් ඇත, අපි පළමු පේළිය දකිමු, පසුව උත්සාහ තුනකින් පසුව එය "අසාර්ථක" ලෙස සලකුණු කර ඇති අතර, එය ලැයිස්තුවෙන් සරලව ඉවත් කරනු ලැබේ.
දෙවන හැසිරීම් විකල්පය ද හැකි ය, VS සරලව ශුන්‍යයට සකසා ඇති විට, නමුත් ඡායාරූපය ආපසු ලබා දෙන්නේ නම්, මෙය හොඳින් ක්රියා නොකරයි. සේවාදායකය පැමිණේ, Nginx එතැනින් ආරම්භ වේ, සෞඛ්ය පරීක්ෂාව වහාම සම්බන්ධතාවය ක්‍රියාත්මක වන බවත්, සියල්ල හොඳින් බවත්, සේවාදායකය අපගේ ලැයිස්තුවේ දිස්වන බවත්, භාරය වහාම එයට යෙදීමට පටන් ගනී. රාජකාරි පරිපාලකගෙන් අතින් ක්‍රියාමාර්ග අවශ්ය නොවේ. රාත්‍රියේ සේවාදායකය නැවත ආරම්භ විය - අධීක්ෂණ දෙපාර්තමේන්තුව රාත්‍රියේ මේ ගැන අපට කතා නොකරයි. මෙය සිදු වූ බවත්, සියල්ල හොඳින් බවත් ඔවුන් ඔබට දන්වයි.
එබැවින්, තරමක් සරල ආකාරයකින්, කුඩා සේවාදායක සංඛ්‍යාවක ආධාරයෙන්, අපි බාහිර දෝෂ ඉවසීමේ ගැටලුව විසඳා ගත්තෙමු.
කීමට ඉතිරිව ඇත්තේ මේ සියල්ල, ඇත්ත වශයෙන්ම, නිරීක්ෂණය කළ යුතු බවයි. වෙනමම, Keepalivede, බොහෝ කලකට පෙර ලියන ලද මෘදුකාංගයක් ලෙස, DBus, SMTP, SNMP සහ සම්මත Zabbix හරහා චෙක්පත් භාවිතා කරමින් එය නිරීක්ෂණය කිරීමට ක්‍රම රාශියක් ඇති බව සටහන් කළ යුතුය. ඊට අමතරව, සෑම කිවිසුම් යාමකටම පාහේ ලිපි ලියන්නේ කෙසේදැයි ඔහුම දන්නා අතර, අවංකව කිවහොත්, යම් අවස්ථාවක දී අපි එය ක්රියා විරහිත කිරීමට පවා සිතුවෙමු, මන්ද ඔහු ඕනෑම මාර්ග තදබදයකට, මාරු වීමට, සෑම IP සම්බන්ධතාවයකටම ලිපි රාශියක් ලියන බැවිනි. සහ යනාදි . ඇත්ත වශයෙන්ම, සේවාදායකයන් විශාල ප්‍රමාණයක් තිබේ නම්, ඔබට මෙම අකුරුවලින් ඔබව යටපත් කළ හැකිය. අපි සම්මත ක්‍රම භාවිතා කරමින් ඡායාරූප රවුටරවල nginx නිරීක්ෂණය කරන අතර දෘඩාංග අධීක්ෂණය පහව ගොස් නැත. ඇත්ත වශයෙන්ම, අපි තවත් කරුණු දෙකකට උපදෙස් දෙන්නෙමු: පළමුව, බාහිර සෞඛ්ය පරීක්ෂාවන් සහ ලබා ගත හැකි බව, මන්ද සෑම දෙයක්ම ක්‍රියාත්මක වුවද, ඇත්ත වශයෙන්ම, බාහිර සපයන්නන් සමඟ ඇති ගැටළු නිසා හෝ වඩාත් සංකීර්ණ දෙයක් නිසා පරිශීලකයින්ට ඡායාරූප නොලැබෙනු ඇත. සෑම විටම වෙනත් ජාලයක, ඇමේසන් හෝ වෙනත් ස්ථානයක, ඔබේ සේවාදායකයන් පිටත සිට ping කළ හැකි වෙනම යන්ත්‍රයක් තබා ගැනීම වටී, එමෙන්ම උපක්‍රමශීලී යන්ත්‍ර ඉගෙනීම කරන්නේ කෙසේදැයි දන්නා අය සඳහා විෂමතා හඳුනාගැනීම හෝ භාවිතා කිරීම වටී. සරල අධීක්ෂණය, අවම වශයෙන් ඉල්ලීම් තියුනු ලෙස පහත වැටී තිබේද, නැතහොත්, ඊට වෙනස්ව, වැඩි වී තිබේද යන්න සොයා බැලීම සඳහා. එය ප්රයෝජනවත් විය හැකිය.
අපි සාරාංශ කරමු: ඇත්ත වශයෙන්ම, අපි, යම් අවස්ථාවක දී අපට ගැලපෙන පරිදි නතර වූ යකඩ ආවරණ විසඳුම වෙනුවට, සෑම දෙයක්ම එක හා සමානව කරන තරමක් සරල පද්ධතියකින්, එනම්, එය HTTPS ගමනාගමනය අවසන් කිරීම සහ තවදුරටත් ස්මාර්ට් මාර්ගගත කිරීම සපයයි. අවශ්ය සෞඛ්ය පරීක්ෂණ. අපි මෙම පද්ධතියේ ස්ථායිතාව වැඩි කර ඇත, එනම්, සෑම ස්ථරයක් සඳහාම අපට තවමත් ඉහළ ලබා ගැනීමේ හැකියාවක් ඇත, තවද අපට ප්‍රසාද දීමනාව තිබේ, ඒ සියල්ල එක් එක් ස්ථරයේ පරිමාණය කිරීම තරමක් පහසු ය, මන්ද එය සම්මත මෘදුකාංග සහිත සම්මත දෘඩාංග වේ, එනම්. , හැකි ගැටළු හඳුනා ගැනීම අපි සරල කර ඇත.
අපි අවසන් කළේ කුමක් ද? 2018 ජනවාරි නිවාඩු කාලය තුළ අපට ගැටලුවක් ඇති විය. අපි මෙම යෝජනා ක්‍රමය ක්‍රියාත්මක කළ පළමු මාස හය තුළ, LTM වෙතින් සියලුම මාර්ග තදබදය ඉවත් කිරීම සඳහා අපි එය සියලු ගමනාගමනය දක්වා පුළුල් කළෙමු, අපි එක් දත්ත මධ්‍යස්ථානයක ගිගාබිට් 40 සිට ගිගාබිට් 60 දක්වා ගමනාගමනය තුළ පමණක් වර්ධනය වූ අතර ඒ සමඟම මුළු 2018 වසරටම තත්පරයට තුන් ගුණයකින් වැඩි ඡායාරූප යැවීමට හැකි විය.
මූලාශ්රය: www.habr.com