හෙලෝ, හබ්ර්! මම පද්ධති පරිපාලන කණ්ඩායමේ ප්රධානියා වන Artem Karamyshev . පසුගිය වසර තුළ අපි නව නිෂ්පාදන දියත් කර ඇත. API සේවා පහසුවෙන් පරිමාණය කළ හැකි, දෝෂ-ඉවසන සහ පරිශීලක පැටවීමේ වේගවත් වර්ධනයක් සඳහා සූදානම් බව සහතික කිරීමට අපට අවශ්ය විය. අපගේ වේදිකාව OpenStack මත ක්රියාත්මක වන අතර, දෝෂ-ඉවසන පද්ධතියක් ලබා ගැනීම සඳහා අපට විසඳිය යුතු සංරචක දෝෂ ඉවසීමේ ගැටළු මොනවාදැයි ඔබට පැවසීමට මට අවශ්යය. OpenStack හි නිෂ්පාදන සංවර්ධනය කරන අයටද මෙය සිත්ගන්නාසුළු වනු ඇතැයි මම සිතමි.
වේදිකාවක සමස්ත දෝෂ ඉවසීම එහි සංරචකවල ඔරොත්තු දීමේ හැකියාවෙන් සමන්විත වේ. එබැවින් අපි අවදානම් හඳුනාගෙන ඒවා වසා දැමූ සියලුම මට්ටම් ක්රමයෙන් හරහා යමු.
විසින් සංවිධානය කරන ලද Uptime day 4 සම්මන්ත්රණයේ වාර්තාවක් වන මෙම කතාවේ වීඩියෝ අනුවාදය, එහි මූලික මූලාශ්රය විය , ඔබට දැකිය හැකිය .
භෞතික ගෘහ නිර්මාණ ශිල්පයේ ඔරොත්තු දීමේ හැකියාව
MCS වලාකුළෙහි පොදු කොටස දැන් III මට්ටමේ දත්ත මධ්යස්ථාන දෙකක පදනම් වී ඇත, ඒවා අතර එහිම අඳුරු තන්තු ඇත, විවිධ මාර්ගවලින් භෞතික මට්ටමින් වෙන් කර ඇත, 200 Gbit/s ප්රතිදානයක් ඇත. III ස්ථරය භෞතික යටිතල ව්යුහය සඳහා අවශ්ය වැරදි ඉවසීමේ මට්ටම සපයයි.
අඳුරු තන්තු භෞතික හා තාර්කික මට්ටම් දෙකෙහිම වෙන් කර ඇත. නාලිකා වෙන් කිරීමේ ක්රියාවලිය පුනරාවර්තනය විය, ගැටළු මතු වූ අතර අපි දත්ත මධ්යස්ථාන අතර සන්නිවේදනය නිරන්තරයෙන් වැඩිදියුණු කරමින් සිටිමු.
උදාහරණයක් ලෙස, බොහෝ කලකට පෙර, එක් දත්ත මධ්යස්ථානයක් අසල ළිඳක වැඩ කරමින් සිටියදී, කැණීම් යන්ත්රයක් පයිප්පයක් කැඩී ගිය අතර, මෙම පයිප්පය තුළ ප්රධාන සහ උපස්ථ ඔප්ටිකල් කේබලයක් තිබුණි. දත්ත මධ්යස්ථානය සමඟ අපගේ වැරදි-ඉවසන සන්නිවේදන නාලිකාව ළිඳ තුළ එක් අවස්ථාවක අවදානමට ලක් විය. ඒ අනුව යටිතල පහසුකම්වලින් කොටසක් අපට අහිමි වී තිබෙනවා. අපි නිගමනවලට එළඹුණු අතර යාබද ළිඳෙහි අතිරේක දෘෂ්ටි ස්ථාපනය කිරීම ඇතුළු ක්රියාමාර්ග ගණනාවක් ගත්තා.
දත්ත මධ්යස්ථානවල අපි අපගේ උපසර්ග BGP හරහා විකාශනය කරන සන්නිවේදන සපයන්නන් සිටින ස්ථාන තිබේ. එක් එක් ජාල දිශාව සඳහා, හොඳම මෙට්රික් තෝරා ගනු ලැබේ, එමඟින් විවිධ සේවාදායකයින්ට හොඳම සම්බන්ධතා ගුණාත්මක භාවය ලබා දීමට ඉඩ සලසයි. එක් සැපයුම්කරුවෙකු හරහා සන්නිවේදනය අඩු වුවහොත්, පවතින සැපයුම්කරුවන් හරහා අපි අපගේ මාර්ගගත කිරීම නැවත ගොඩනඟමු.
සැපයුම්කරුවෙකු අසමත් වුවහොත්, අපි ස්වයංක්රීයව ඊළඟ එකට මාරු වන්නෙමු. එක් දත්ත මධ්යස්ථානයක් අසාර්ථක වූ විට, දෙවන දත්ත මධ්යස්ථානයේ අපගේ සේවාවන්හි කැඩපත් පිටපතක් අප සතුව ඇත, එය සම්පූර්ණ භාරයම භාර ගනී.
භෞතික යටිතල පහසුකම්වල ඔරොත්තු දීමේ හැකියාව
යෙදුම් මට්ටමේ වැරදි ඉවසීම සඳහා අප භාවිතා කරන දේ
අපගේ සේවාව විවෘත මූලාශ්ර සංරචක ගණනාවක් මත ගොඩනගා ඇත.
ExaBGP යනු BGP මත පදනම් වූ ගතික රවුටින් ප්රොටෝකෝලය භාවිතයෙන් කාර්යයන් ගණනාවක් ක්රියාත්මක කරන සේවාවකි. පරිශීලකයින් API වෙත ප්රවේශ වන අපගේ සුදු ලැයිස්තුගත IP ලිපින ප්රචාරණය කිරීමට අපි එය සක්රියව භාවිතා කරමු.
HAProxy OSI ආකෘතියේ විවිධ මට්ටම්වල ඉතා නම්යශීලී ගමනාගමන සමතුලිත නීති වින්යාස කිරීමට ඔබට ඉඩ සලසන අධි-බර සමතුලිතයකි. අපි එය සියලු සේවාවන් ඉදිරියේ සමතුලිත කිරීමට භාවිතා කරමු: දත්ත සමුදායන්, පණිවිඩ තැරැව්කරුවන්, API සේවා, වෙබ් සේවා, අපගේ අභ්යන්තර ව්යාපෘති - සියල්ල HAProxy පිටුපස ඇත.
API යෙදුම — පරිශීලකයා ඔහුගේ යටිතල පහසුකම් සහ ඔහුගේ සේවාව කළමනාකරණය කරන python වලින් ලියා ඇති වෙබ් යෙදුමකි.
සේවක අයදුම්පත (මෙතැන් සිට සරලව සේවකයා) - OpenStack සේවාවන්හි, මෙය ඔබට යටිතල ව්යුහයට API විධාන විකාශනය කිරීමට ඉඩ සලසන යටිතල ව්යුහාත්මක ඩීමන් වේ. උදාහරණයක් ලෙස, තැටි සෑදීම සේවකයා තුළ සිදු වන අතර, නිර්මාණ ඉල්ලීම යෙදුම් API තුළ සිදු වේ.
සම්මත OpenStack යෙදුම් ගෘහ නිර්මාණ ශිල්පය
OpenStack සඳහා සංවර්ධනය කරන ලද බොහෝ සේවාවන් තනි සුසමාදර්ශයක් අනුගමනය කිරීමට උත්සාහ කරයි. සේවාවක් සාමාන්යයෙන් කොටස් 2 කින් සමන්විත වේ: API සහ කම්කරුවන් (පසුපස ක්රියාත්මක කරන්නන්). රීතියක් ලෙස, API යනු python හි WSGI යෙදුමකි, එය ස්වාධීන ක්රියාවලියක් (ඩේමන්) ලෙස හෝ සූදානම් කළ Nginx හෝ Apache වෙබ් සේවාදායකයක් භාවිතයෙන් දියත් කෙරේ. API පරිශීලක ඉල්ලීම ක්රියාවට නංවන අතර ක්රියාත්මක කිරීම සඳහා සේවක යෙදුමට වැඩිදුර උපදෙස් ලබා දෙයි. හුවමාරුව සිදුවන්නේ පණිවිඩ තැරැව්කරුවෙකු භාවිතයෙන්, සාමාන්යයෙන් RabbitMQ, අනෙක් ඒවාට දුර්වල ලෙස සහාය දක්වයි. පණිවිඩ තැරැව්කරු වෙත ළඟා වූ විට, ඒවා කම්කරුවන් විසින් සකස් කරනු ලබන අතර, අවශ්ය නම්, ප්රතිචාරයක් ලබා දෙන්න.
මෙම සුසමාදර්ශය අසාර්ථක වීමේ හුදකලා පොදු කරුණු ඇතුළත් වේ: RabbitMQ සහ දත්ත සමුදාය. නමුත් RabbitMQ එක් සේවාවක් තුළ හුදකලා වන අතර, න්යායාත්මකව, එක් එක් සේවාව සඳහා තනි පුද්ගල විය හැකිය. එබැවින් MCS හි අපි මෙම සේවාවන් හැකිතාක් වෙන් කරමු; එක් එක් ව්යාපෘතිය සඳහා අපි වෙනම දත්ත සමුදායක්, වෙනම RabbitMQ නිර්මාණය කරමු. මෙම ප්රවේශය හොඳයි, මන්ද සමහර අවදානම් ස්ථානවල අනතුරක් සිදු වූ විට, සම්පූර්ණ සේවාවම බිඳ වැටෙන්නේ නැත, නමුත් එයින් කොටසක් පමණි.
සේවක යෙදුම් සංඛ්යාව අසීමිතයි, එබැවින් කාර්ය සාධනය සහ දෝෂ ඉවසීම වැඩි කිරීම සඳහා API හට සමතුලිතයන් පිටුපසින් තිරස් අතට පහසුවෙන් පරිමාණය කළ හැක.
APIs සහ කම්කරුවන් අතර සංකීර්ණ අනුක්රමික මෙහෙයුම් සිදුවන විට සමහර සේවාවන්ට සේවාව තුළ සම්බන්ධීකරණය අවශ්ය වේ. මෙම අවස්ථාවෙහිදී, තනි සම්බන්ධීකරණ මධ්යස්ථානයක් භාවිතා කරනු ලැබේ, Redis, Memcache, etcd වැනි පොකුරු පද්ධතියක්, මෙම කාර්යය ඔහුට පවරා ඇති බව තවත් සේවකයෙකුට පැවසීමට ඉඩ සලසයි ("කරුණාකර එය ගන්න එපා"). අපි etcd භාවිතා කරනවා. රීතියක් ලෙස, කම්කරුවන් දත්ත සමුදාය සමඟ ක්රියාකාරීව සන්නිවේදනය කරයි, එහි සිට තොරතුරු ලිවීම සහ කියවීම. අපි mariadb දත්ත සමුදායක් ලෙස භාවිතා කරමු, එය බහුමාස්ටර් පොකුරක් තුළ පිහිටා ඇත.
මෙම සම්භාව්ය තනි සේවාව OpenStack සඳහා සාමාන්යයෙන් පිළිගත් ආකාරයට සංවිධානය කර ඇත. එය සංවෘත පද්ධතියක් ලෙස සැලකිය හැකිය, ඒ සඳහා පරිමාණය සහ වැරදි ඉවසීමේ ක්රම බෙහෙවින් පැහැදිලිය. උදාහරණයක් ලෙස, API දෝෂ ඉවසීම සඳහා, ඔවුන් ඉදිරිපිට සමතුලිතතාවයක් තැබීම ප්රමාණවත්ය. පරිමාණ කම්කරුවන් සාක්ෂාත් කරගනු ලබන්නේ ඔවුන්ගේ සංඛ්යාව වැඩි කිරීමෙනි.
සම්පූර්ණ යෝජනා ක්රමයේ දුර්වල ස්ථානය RabbitMQ සහ MariaDB වේ. ඔවුන්ගේ ගෘහ නිර්මාණ ශිල්පය වෙනම ලිපියක් ලැබිය යුතුය.මෙම ලිපියෙන් මට අවධානය යොමු කිරීමට අවශ්ය වන්නේ API දෝෂ ඉවසීමයි.
Openstack යෙදුම් ගෘහ නිර්මාණ ශිල්පය. වලාකුළු වේදිකාවේ සමතුලිතතාවය සහ වැරදි ඉවසීම
ExaBGP භාවිතයෙන් HAProxy balancer දෝෂ-ඉවසන බවට පත් කිරීම
අපගේ API පරිමාණය කළ හැකි, වේගවත් සහ දෝෂ-ඉවසිය හැකි බවට පත් කිරීම සඳහා, අපි ඒවා ඉදිරියෙන් load balancer එකක් තබමු. අපි HAProxy තෝරා ගත්තෙමු. මගේ මතය අනුව, එය අපගේ කාර්යය සඳහා අවශ්ය සියලු ලක්ෂණ ඇත: OSI මට්ටම් කිහිපයක සමතුලිත කිරීම, කළමනාකරණ අතුරු මුහුණතක්, නම්යශීලීභාවය සහ පරිමාණය, සමබර කිරීමේ ක්රම විශාල සංඛ්යාවක්, සැසි වගු සඳහා සහාය.
විසඳිය යුතු පළමු ගැටළුව වූයේ සමතුලිතයාගේ වැරදි ඉවසීමයි. සමතුලිතයක් ස්ථාපනය කිරීම අසාර්ථක වීමේ ලක්ෂ්යයක් ද නිර්මාණය කරයි: සමතුලිතය බිඳී සේවාව බිඳ වැටේ. මෙය සිදුවීම වලක්වා ගැනීම සඳහා, අපි ExaBGP සමඟ එක්ව HAProxy භාවිතා කළෙමු.
ExaBGP සේවාවක තත්වය පරීක්ෂා කිරීම සඳහා යාන්ත්රණයක් ක්රියාත්මක කිරීමට ඔබට ඉඩ සලසයි. අපි HAProxy හි ක්රියාකාරීත්වය පරීක්ෂා කිරීමට මෙම යාන්ත්රණය භාවිතා කළ අතර, ගැටළු ඇති විට, BGP වෙතින් HAProxy සේවාව අක්රිය කරන්න.
ExaBGP+HAProxy යෝජනා ක්රමය
- අපි අවශ්ය මෘදුකාංග වන ExaBGP සහ HAProxy සේවාදායක තුනක ස්ථාපනය කරමු.
- අපි සෑම සේවාදායකයකම ලූප්බැක් අතුරුමුහුණතක් සාදන්නෙමු.
- සර්වර් තුනේම අපි මෙම අතුරු මුහුණතට එකම සුදු IP ලිපිනය ලබා දෙමු.
- සුදු IP ලිපිනයක් ExaBGP හරහා අන්තර්ජාලයට ප්රචාරණය කෙරේ.
සේවාදායක තුනෙන්ම එකම IP ලිපිනය ප්රචාරණය කිරීමෙන් දෝෂ ඉවසීම සාක්ෂාත් කරගනු ලැබේ. ජාල දෘෂ්ටි කෝණයකින්, එකම ලිපිනය විවිධ මීළඟ හොප් තුනකින් ප්රවේශ විය හැකිය. රවුටරය සමාන මාර්ග තුනක් දකියි, එහිම මෙට්රික් මත පදනම්ව ඒවායින් ඉහළම ප්රමුඛතාවය තෝරා ගනී (මෙය සාමාන්යයෙන් එකම විකල්පය වේ), සහ ගමනාගමනය යන්නේ එක් සේවාදායකයකට පමණි.
HAProxy හි ක්රියාකාරිත්වයේ ගැටළු හෝ සේවාදායකයේ අසමත් වීමකදී, ExaBGP මාර්ගය නිවේදනය කිරීම නවත්වන අතර ගමනාගමනය සුමටව වෙනත් සේවාදායකයකට මාරු වේ.
මේ අනුව, අපි සමතුලිතතාවයේ වැරදි ඉවසීම ලබා ගත්තෙමු.
HAProxy balancers වල වැරදි ඉවසීම
යෝජනා ක්රමය අසම්පූර්ණ විය: අපි HAProxy වෙන් කර ගන්නේ කෙසේදැයි ඉගෙන ගත්තෙමු, නමුත් සේවා තුළ බර බෙදා හරින ආකාරය ඉගෙන ගත්තේ නැත. එමනිසා, අපි මෙම යෝජනා ක්රමය ටිකක් පුළුල් කළෙමු: අපි සුදු IP ලිපින කිහිපයක් අතර තුලනය කිරීමට ඉදිරියට ගියෙමු.
DNS සහ BGP මත පදනම් වූ තුලනය
අපගේ HAProxy සඳහා බර තුලනය කිරීමේ ගැටළුව නොවිසඳී ඇත. කෙසේ වෙතත්, අප මෙහි කළ පරිදි එය ඉතා සරලව විසඳිය හැකිය.
සේවාදායකයන් තුනක් තුලනය කිරීමට ඔබට සුදු IP ලිපින 3ක් සහ හොඳ පැරණි DNS අවශ්ය වේ. මෙම සෑම ලිපිනයක්ම HAProxy හි loopback අතුරුමුහුණත මත තීරණය කර අන්තර්ජාලයට ප්රචාරණය කෙරේ.
OpenStack හි, සම්පත් කළමනාකරණය කිරීම සඳහා, සේවා නාමාවලියක් භාවිතා කරනු ලැබේ, එය යම් සේවාවක අවසාන ලක්ෂ්ය API නියම කරයි. මෙම නාමාවලියෙහි අපි වසම් නාමයක් ලියාපදිංචි කරමු - public.infra.mail.ru, විවිධ IP ලිපින තුනකින් DNS හරහා විසඳනු ලැබේ. ප්රතිඵලයක් වශයෙන්, DNS හරහා ලිපින තුනක් අතර බර බෙදා හැරීමක් අපට ලැබේ.
නමුත් සුදු IP ලිපින නිවේදනය කිරීමේදී අපි සේවාදායක තේරීමේ ප්රමුඛතා පාලනය නොකරන බැවින් මෙය තවමත් සමතුලිත නොවේ. සාමාන්යයෙන්, IP ලිපින ජ්යෙෂ්ඨත්වය මත පදනම්ව තෝරාගනු ලබන්නේ එක් සේවාදායකයක් පමණක් වන අතර, BGP හි ප්රමිතික නිශ්චිතව දක්වා නොමැති නිසා අනෙක් දෙක අක්රිය වනු ඇත.
අපි විවිධ ප්රමිතික සමඟ ExaBGP හරහා මාර්ග යැවීමට පටන් ගත්තෙමු. සෑම සමතුලිතයෙක්ම සුදු IP ලිපින තුනම ප්රචාරණය කරයි, නමුත් ඒවායින් එකක්, මෙම සමතුලිතකය සඳහා ප්රධාන එක, අවම මෙට්රික් සමඟ ප්රචාරණය කෙරේ. එබැවින් සමතුලිතයන් තුනම ක්රියාත්මක වන විට, පළමු IP ලිපිනයට ලැබෙන ඇමතුම් පළමු සමතුලිතයට ද, දෙවැන්නට දෙවැන්නට ද, තුන්වන සිට තුන්වනට ද ඇමතුම් ලැබේ.
එක බැලන්සර් එකක් වැටුනම මොකද වෙන්නේ? කිසියම් සමතුලිතයක් අසමත් වුවහොත්, එහි ප්රධාන ලිපිනය තවමත් අනෙක් දෙකෙන් ප්රචාරණය කර ඇති අතර ඒවා අතර ගමනාගමනය නැවත බෙදා හරිනු ලැබේ. මේ අනුව, අපි පරිශීලකයාට DNS හරහා එකවර IP ලිපින කිහිපයක් ලබා දෙන්නෙමු. DNS සහ විවිධ ප්රමිතික මගින් සමතුලිත කිරීම මගින්, සමතුලිතයන් තුනම හරහා බර ඒකාකාර බෙදා හැරීමක් අපට ලැබේ. ඒ අතරම අපි වැරදි ඉවසීම නැති කර නොගනිමු.
DNS + BGP මත පදනම්ව HAProxy තුලනය කිරීම
ExaBGP සහ HAProxy අතර අන්තර්ක්රියා
එබැවින්, මාර්ග ප්රකාශ කිරීම නැවැත්වීම මත පදනම්ව, සේවාදායකය ඉවත් වුවහොත් අපි දෝෂ ඉවසීම ක්රියාත්මක කළෙමු. නමුත් HAProxy සේවාදායක අසාර්ථකත්වය හැර වෙනත් හේතු නිසා වසා දැමිය හැක: පරිපාලන දෝෂ, සේවාව තුළ ඇති අසාර්ථකත්වය. මෙම අවස්ථා වලදීද බරට යටින් කැඩුණු සමතුලිතකය ඉවත් කිරීමට අපට අවශ්ය වන අතර අපට වෙනත් යාන්ත්රණයක් අවශ්ය වේ.
එබැවින්, පෙර යෝජනා ක්රමය පුළුල් කරමින්, අපි ExaBGP සහ HAProxy අතර හෘද ස්පන්දනය ක්රියාත්මක කළෙමු. මෙය ExaBGP සහ HAProxy අතර අන්තර්ක්රියා මෘදුකාංග ක්රියාත්මක කිරීමකි, ExaBGP විසින් යෙදුම්වල තත්ත්වය පරීක්ෂා කිරීමට අභිරුචි ස්ක්රිප්ට් භාවිතා කරන විට.
මෙය සිදු කිරීම සඳහා, ඔබට HAProxy හි තත්ත්වය පරීක්ෂා කළ හැකි ExaBGP වින්යාසය තුළ සෞඛ්ය පරීක්ෂකයක් වින්යාසගත කළ යුතුය. අපගේ නඩුවේදී, අපි සෞඛ්ය පසුබිම HAProxy හි වින්යාස කළ අතර, ExaBGP පැත්තෙන් අපි සරල GET ඉල්ලීමක් සමඟ පරීක්ෂා කරන්නෙමු. නිවේදනය සිදු වීම නතර වුවහොත්, HAProxy බොහෝ දුරට ක්රියා නොකරන අතර එය ප්රචාරණය කිරීමට අවශ්ය නොවේ.
HAProxy සෞඛ්ය පරීක්ෂාව
HAProxy Peers: සැසි සමමුහුර්තකරණය
ඊළඟට කළ යුත්තේ සැසි සමමුහුර්ත කිරීමයි. බෙදා හරින ලද සමතුලිතයන් හරහා වැඩ කරන විට, සේවාදායක සැසි පිළිබඳ තොරතුරු ගබඩා කිරීම සංවිධානය කිරීම අපහසු වේ. නමුත් HAProxy යනු විවිධ HAProxy ක්රියාවලීන් අතර සැසි වගු මාරු කිරීමේ හැකියාව - Peers ක්රියාකාරිත්වය හේතුවෙන් මෙය කළ හැකි සමතුලිතයන් කිහිපයෙන් එකකි.
විවිධ සමතුලිත ක්රම තිබේ: වැනි සරල ඒවා , සහ දිගු, සේවාලාභියාගේ සැසිය මතක තබා ගන්නා විට, සහ සෑම අවස්ථාවකදීම ඔහු පෙර සේම එකම සේවාදායකයේ අවසන් වේ. අපට අවශ්ය වූයේ දෙවැනි විකල්පය ක්රියාත්මක කිරීමටයි.
HAProxy මෙම යාන්ත්රණයේ සේවාදායක සැසි සුරැකීමට ස්ටික්-මේස භාවිතා කරයි. ඔවුන් සේවාදායකයාගේ මුල් IP ලිපිනය, තෝරාගත් ඉලක්ක ලිපිනය (පසුපස) සහ සමහර සේවා තොරතුරු සුරකියි. සාමාන්යයෙන්, ප්රභව-IP + ගමනාන්තය-IP යුගලයක් ගබඩා කිරීමට කූරු වගු භාවිතා කරයි, එය වෙනත් සමතුලිතයකට මාරු වන විට පරිශීලක සැසි සන්දර්භය මාරු කළ නොහැකි යෙදුම් සඳහා විශේෂයෙන් ප්රයෝජනවත් වේ, උදාහරණයක් ලෙස, රවුන්ඩ් රොබින් සමතුලිත ප්රකාරයේදී.
කූරු මේසයක් විවිධ HAProxy ක්රියාවලි අතර ගමන් කිරීමට උගන්වන්නේ නම් (ඒ අතර සමතුලිත වීම සිදු වේ), අපගේ සමතුලිත කරන්නන්ට කූරු මේස එක් සංචිතයක් සමඟ වැඩ කිරීමට හැකි වේ. මෙමගින් එක් සමතුලිතයෙකු අසමත් වුවහොත් සේවාලාභියාගේ ජාලය බාධාවකින් තොරව මාරු කිරීමට හැකි වනු ඇත; සේවාදායක සැසි සමඟ වැඩ කිරීම කලින් තෝරාගත් පසුපෙළ මතම දිගටම කරගෙන යනු ඇත.
නිසි ක්රියාකාරීත්වය සඳහා, සැසිය ස්ථාපිත කරන ලද සමතුලිතයේ මූලාශ්ර IP ලිපිනයෙහි ගැටළුව විසඳිය යුතුය. අපගේ නඩුවේදී, මෙය loopback අතුරුමුහුණතෙහි ගතික ලිපිනයකි.
සම වයසේ මිතුරන්ගේ නිවැරදි වැඩ සාක්ෂාත් කරගනු ලබන්නේ යම් යම් කොන්දේසි යටතේ පමණි. එනම්, TCP කල් ඉකුත්වීම් ප්රමාණවත් තරම් විශාල විය යුතුය නැතහොත් TCP සැසිය අවසන් කිරීමට කාලය නොමැති වන පරිදි මාරුවීම ප්රමාණවත් තරම් වේගවත් විය යුතුය. කෙසේ වෙතත්, එය බාධාවකින් තොරව මාරු වීමට ඉඩ සලසයි.
IaaS හි අපට එම තාක්ෂණයම භාවිතයෙන් ගොඩනඟන ලද සේවාවක් තිබේ. මෙය , එය ඔක්ටේවියා ලෙස හැඳින්වේ. එය HAProxy ක්රියාවලි දෙකක් මත පදනම් වන අතර මුලින් සම වයසේ මිතුරන් සඳහා සහය ඇතුළත් වේ. ඔවුන් මෙම සේවාවේ විශිෂ්ට බව ඔප්පු කර ඇත.
පින්තූරයේ ක්රමානුකුලව HAProxy අවස්ථා තුනක් අතර සම වයස් වගු වල චලනය පෙන්නුම් කරයි, මෙය වින්යාස කළ හැකි ආකාරය පිළිබඳ වින්යාසයක් යෝජනා කෙරේ:
HAProxy Peers (සැසි සමමුහුර්තකරණය)
ඔබ එකම යෝජනා ක්රමය ක්රියාත්මක කරන්නේ නම්, එහි ක්රියාකාරිත්වය ප්රවේශමෙන් පරීක්ෂා කළ යුතුය. එය 100% ක්ම එකම ආකාරයකින් ක්රියාත්මක වන බව සත්යයක් නොවේ. නමුත් ඔබට සේවාදායකයාගේ මූලාශ්ර IP මතක තබා ගැනීමට අවශ්ය වූ විට අවම වශයෙන් ඔබට ස්ටික් මේස අහිමි නොවනු ඇත.
එකම සේවාදායකයාගෙන් එකවර ඉල්ලීම් ගණන සීමා කිරීම
අපගේ API ඇතුළුව, ප්රසිද්ධියේ ලබා ගත හැකි ඕනෑම සේවාවක්, ඉල්ලීම් හිම කුණාටු වලට යටත් විය හැක. පරිශීලක දෝෂවල සිට ඉලක්කගත ප්රහාර දක්වා ඒවාට හේතු සම්පූර්ණයෙන්ම වෙනස් විය හැකිය. අපි වරින් වර IP ලිපින මගින් DDoSed කරනු ලැබේ. සේවාදායකයින් බොහෝ විට ඔවුන්ගේ ස්ක්රිප්ට් වල වැරදි සිදු කරන අතර අපට කුඩා-ඩීඩීඕඑස් ලබා දෙයි.
එක් ආකාරයකින් හෝ වෙනත් ආකාරයකින් අමතර ආරක්ෂාවක් සැපයිය යුතුය. පැහැදිලි විසඳුම වන්නේ API ඉල්ලීම් ගණන සීමා කිරීම සහ අනිෂ්ට ඉල්ලීම් සැකසීමේ CPU කාලය නාස්ති නොකිරීමයි.
එවැනි සීමා කිරීම් ක්රියාත්මක කිරීම සඳහා, අපි HAProxy පදනම මත සංවිධානය කරන ලද අනුපාත සීමාවන් භාවිතා කරමු, එම කූරු වගු භාවිතා කරමු. සීමාවන් සැකසීම ඉතා සරල වන අතර API වෙත ඉල්ලීම් ගණනින් පරිශීලකයා සීමා කිරීමට ඔබට ඉඩ සලසයි. ඇල්ගොරිතම ඉල්ලීම් කරන මූලාශ්ර IP මතක තබා ගන්නා අතර එක් පරිශීලකයෙකුගෙන් එකවර ඉල්ලීම් ගණන සීමා කරයි. ඇත්ත වශයෙන්ම, අපි එක් එක් සේවාව සඳහා සාමාන්ය API පැටවුම් පැතිකඩ ගණනය කර මෙම අගය ≈ 10 ගුණයක සීමාවක් සකසන්නෙමු. අපි දිගටම තත්වය සමීපව නිරීක්ෂණය කරමින් අපගේ ඇඟිල්ල ස්පන්දනය කරන්නෙමු.
මෙය ප්රායෝගිකව පෙනෙන්නේ කෙසේද? ස්වයංක්රීය පරිමාණය කිරීමට අපගේ API නිතිපතා භාවිතා කරන සේවාදායකයින් අප සතුව ඇත. ඔවුන් උදේට ආසන්න වශයෙන් දෙතුන් සියයක් පමණ අථත්ය යන්ත්ර නිර්මාණය කර සවස් වන විට ඒවා මකා දමයි. OpenStack සඳහා, PaaS සේවාවන් සමඟින් අතථ්ය යන්ත්රයක් නිර්මාණය කිරීම සඳහා අවම වශයෙන් API ඉල්ලීම් 1000ක් අවශ්ය වේ, මන්ද සේවා අතර අන්තර්ක්රියා ද API හරහා සිදු වේ.
එවැනි කාර්යයන් මාරු කිරීම තරමක් විශාල බරක් ඇති කරයි. අපි මෙම භාරය තක්සේරු කර, දෛනික මුදුන් එකතු කර, ඒවා දස ගුණයකින් වැඩි කළ අතර, මෙය අපගේ ගාස්තු සීමාව බවට පත් විය. අපි ස්පන්දනය මත ඇඟිල්ල තබා ගන්නෙමු. අපි නිතරම දකින බොට් සහ ස්කෑනර් අප වෙත ධාවනය කළ හැකි සීජීඒ ස්ක්රිප්ට් තිබේදැයි බැලීමට උත්සාහ කරන, අපි ඒවා ක්රියාකාරීව කපා දමමු.
පරිශීලකයන් නොදැනුවත්ව ඔබේ කේත පදනම යාවත්කාලීන කරන්නේ කෙසේද
අපි කේත යෙදවීමේ ක්රියාවලි මට්ටමින් දෝෂ ඉවසීම ද ක්රියාත්මක කරමු. පෙරළීමේදී දෝෂ ඇති විය හැකි නමුත්, සේවා ලබා ගැනීමේ හැකියාව මත ඒවායේ බලපෑම අවම කර ගත හැක.
අපි නිරතුරුවම අපගේ සේවාවන් යාවත්කාලීන කරන අතර පරිශීලකයින්ට බලපෑම් නොකර කේත පදනම යාවත්කාලීන කර ඇති බවට සහතික විය යුතුය. HAProxy හි කළමනාකරණ හැකියාවන් සහ අපගේ සේවාවන්හි Graceful Shutdown ක්රියාත්මක කිරීම භාවිතයෙන් මෙම ගැටළුව විසඳීමට අපි සමත් විය.
මෙම ගැටළුව විසඳීම සඳහා, සමතුලිතතාවය පාලනය කිරීම සහ සේවා “නිවැරදි” වසා දැමීම සහතික කිරීම අවශ්ය විය:
- HAProxy වලදී, පාලනය සිදු කරනු ලබන්නේ සංඛ්යාලේඛන ගොනුවක් හරහා වන අතර, එය අත්යවශ්යයෙන්ම සොකට් එකක් වන අතර එය HAProxy වින්යාසය තුළ අර්ථ දක්වා ඇත. ඔබට stdio හරහා එයට විධාන යැවිය හැක. නමුත් අපගේ ප්රධාන වින්යාස පාලන මෙවලම ඇන්සිබල් වේ, එබැවින් එයට HAProxy කළමනාකරණය සඳහා ගොඩනඟන ලද මොඩියුලයක් ඇත. අපි ක්රියාකාරීව භාවිතා කරන.
- අපගේ API සහ Engine සේවාවන් බොහොමයක් අලංකාර වසා දැමීමේ තාක්ෂණයට සහය දක්වයි: වසා දැමීමේදී, http ඉල්ලීමක් හෝ යම් සේවා කාර්යයක් වේවා, වත්මන් කාර්යය සම්පූර්ණ වන තෙක් ඔවුන් බලා සිටියි. සේවකයා සම්බන්ධයෙන් ද එයම සිදු වේ. එය තමන් කරන සියලුම කාර්යයන් දන්නා අතර එය සියල්ල සාර්ථකව නිම කළ විට අවසන් වේ.
මෙම කරුණු දෙකට ස්තූතියි, අපගේ යෙදවීම සඳහා ආරක්ෂිත ඇල්ගොරිතම මෙලෙස පෙනේ.
- සංවර්ධකයා නව කේත පැකේජයක් එක්රැස් කරයි (අපට මෙය RPM වේ), එය dev පරිසරය තුළ පරීක්ෂා කරයි, එය අදියරේදී පරීක්ෂා කරයි, සහ එය අදියර ගබඩාවේ තබයි.
- සංවර්ධකයා "කෞතුක වස්තු" පිළිබඳ වඩාත් සවිස්තරාත්මක විස්තරය සමඟ යෙදවීම සඳහා කාර්යය සකසයි: නව පැකේජයේ අනුවාදය, නව ක්රියාකාරීත්වය පිළිබඳ විස්තරයක් සහ අවශ්ය නම් යෙදවීම පිළිබඳ වෙනත් විස්තර.
- පද්ධති පරිපාලකයා යාවත්කාලීන කිරීම ආරම්භ කරයි. Ansible playbook දියත් කරයි, එය පහත සඳහන් දේ කරයි:
- අදියර ගබඩාවෙන් පැකේජයක් ගෙන නිෂ්පාදන ගබඩාවේ ඇති පැකේජයේ අනුවාදය යාවත්කාලීන කිරීමට එය භාවිතා කරයි.
- යාවත්කාලීන සේවාවේ පසුපෙළ ලැයිස්තුවක් සම්පාදනය කරයි.
- HAProxy හි යාවත්කාලීන කළ යුතු පළමු සේවාව වසා දමා එහි ක්රියාවලි ධාවනය අවසන් වන තෙක් බලා සිටී. විචිත්රවත් වසා දැමීම්වලට ස්තුතිවන්ත වන්න, දැනට පවතින සියලුම සේවාදායක ඉල්ලීම් සාර්ථකව සම්පූර්ණ වන බව අපට විශ්වාසයි.
- API සහ කම්කරුවන් සම්පූර්ණයෙන්ම නතර කර, HAProxy අක්රිය කළ පසු, කේතය යාවත්කාලීන වේ.
- ඇන්සිබල් සේවා ධාවනය කරයි.
- සෑම සේවාවක් සඳහාම, නිශ්චිත "හැන්ඩ්ල්" ඇදගෙන යනු ලබන අතර, එය පෙර-නිශ්චිත ප්රධාන පරීක්ෂණ ගණනාවක ඒකක පරීක්ෂණ සිදු කරයි. නව කේතයේ මූලික පරීක්ෂාවක් සිදු වේ.
- පෙර පියවරේදී කිසිදු දෝෂයක් හමු නොවූයේ නම්, පසුපෙළ සක්රිය වේ.
- අපි ඊළඟ පසුපෙළට යමු.
- සියලුම පසුබිම් යාවත්කාලීන කිරීමෙන් පසුව, ක්රියාකාරී පරීක්ෂණ දියත් කරනු ලැබේ. ඒවා අස්ථානගත වී ඇත්නම්, සංවර්ධකයා ඔහු විසින් නිර්මාණය කරන ලද ඕනෑම නව ක්රියාකාරිත්වයක් දෙස බලයි.
මෙය යෙදවීම සම්පූර්ණ කරයි.
සේවා යාවත්කාලීන චක්රය
අපිට එක නීතියක් නැත්නම් මේ ක්රමය ක්රියාත්මක වෙන්නේ නැහැ. අපි සටනේදී පැරණි සහ නව අනුවාද දෙකටම සහාය දෙමු. කල්තියා, මෘදුකාංග සංවර්ධනය කිරීමේ අදියරේදී, සේවා දත්ත ගබඩාවේ වෙනස්කම් ඇති වුවද, ඒවා පෙර කේතය නොකැඩී ඇති බව නියම කර ඇත. එහි ප්රතිඵලයක් වශයෙන්, කේත පදනම ක්රමයෙන් යාවත්කාලීන වේ.
නිගමනය
දෝෂ ඉවසිය හැකි WEB ගෘහනිර්මාණ ශිල්පයක් පිළිබඳ මගේම අදහස් බෙදා ගනිමින්, එහි ප්රධාන කරුණු නැවත වරක් සටහන් කිරීමට මම කැමැත්තෙමි:
- ශාරීරික වැරදි ඉවසීම;
- ජාල දෝෂ ඉවසීම (ශේෂයන්, BGP);
- භාවිතා කරන සහ සංවර්ධනය කරන ලද මෘදුකාංගයේ වැරදි ඉවසීම.
සියලු දෙනාටම ස්ථාවර අතිකාල!
මූලාශ්රය: www.habr.com
