Yandex.Cloud හි ජාල පැටවුම් සමතුලිතයක ගෘහ නිර්මාණ ශිල්පය

හෙලෝ, මම සර්ජි එලන්සෙව්, මම සංවර්ධනය කරමි ජාල පැටවුම් ශේෂය Yandex.Cloud හි. මීට පෙර, මම Yandex ද්වාරය සඳහා L7 balancer සංවර්ධනය කිරීමට නායකත්වය දුන්නෙමි - සගයන් විහිළු කරන්නේ මා කුමක් කළත් එය සමතුලිතයෙකු බවට පත්වන බවයි. මම Habr පාඨකයන්ට වලාකුළු වේදිකාවක බර කළමනාකරණය කරන්නේ කෙසේද, මෙම ඉලක්කය සාක්ෂාත් කර ගැනීම සඳහා සුදුසුම මෙවලම ලෙස අප දකින දේ සහ මෙම මෙවලම ගොඩනැගීමට අප ගමන් කරන්නේ කෙසේද යන්න කියමි.

පළමුව, අපි කොන්දේසි කිහිපයක් හඳුන්වා දෙමු:

• VIP (Virtual IP) - balancer IP ලිපිනය
• Server, backend, instance - යෙදුමක් ධාවනය වන අතථ්‍ය යන්ත්‍රයක්
• RIP (සැබෑ IP) - සේවාදායක IP ලිපිනය
• සෞඛ්‍ය පරීක්ෂාව - සේවාදායක සූදානම පරීක්ෂා කිරීම
• ලබා ගත හැකි කලාපය, AZ - දත්ත මධ්‍යස්ථානයක හුදකලා යටිතල පහසුකම්
• කලාපය - විවිධ AZs එකමුතුවකි

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

බර සමතුලිතයක් බොහෝ විට එය ක්‍රියාත්මක වන OSI ආකෘතියෙන් ප්‍රොටෝකෝල ස්තරය මගින් වර්ගීකරණය කරයි. Cloud Balancer TCP මට්ටමේ ක්‍රියාත්මක වන අතර එය හතරවන ස්ථරය වන L4 ට අනුරූප වේ.

අපි Cloud balancer architecture හි දළ විශ්ලේෂණයකට යමු. අපි විස්තර මට්ටම ක්රමයෙන් වැඩි කරන්නෙමු. අපි සමතුලිත සංරචක පන්ති තුනකට බෙදන්නෙමු. config plane පන්තිය පරිශීලක අන්තර්ක්‍රියා සඳහා වගකිව යුතු අතර පද්ධතියේ ඉලක්ක තත්ත්වය ගබඩා කරයි. පාලන තලය මඟින් පද්ධතියේ වත්මන් තත්ත්වය ගබඩා කර දත්ත තල පන්තියෙන් පද්ධති කළමනාකරණය කරයි, ඒවා සේවාදායකයින්ගෙන් ඔබේ අවස්ථාවන්ට ගමනාගමනය ලබා දීමට සෘජුවම වගකිව යුතුය.

දත්ත තලය

ගමනාගමනය අවසන් වන්නේ මායිම් රවුටර නම් මිල අධික උපාංග මත ය. දෝෂ ඉවසීම වැඩි කිරීම සඳහා, එවැනි උපකරණ කිහිපයක් එක් දත්ත මධ්යස්ථානයක එකවර ක්රියාත්මක වේ. ඊළඟට, ගනුදෙනුකරුවන් සඳහා BGP හරහා ඕනෑම AZ වෙත ඕනෑම IP ලිපින ප්‍රකාශ කරන සමතුලිතයන් වෙත ගමනාගමනය යයි. 

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

වින්යාස තලය

 
වින්‍යාස තලයේ ප්‍රධාන අංගය API වන අතර එමඟින් සමතුලිතයන් සමඟ මූලික මෙහෙයුම් සිදු කරනු ලැබේ: අවස්ථා නිර්මාණය කිරීම, මකා දැමීම, අවස්ථා සංයුතිය වෙනස් කිරීම, සෞඛ්‍ය පරීක්ෂණ ප්‍රතිඵල ලබා ගැනීම යනාදිය. එක් අතකින්, මෙය REST API වේ, සහ වෙනත්, Cloud හි අපි බොහෝ විට gRPC රාමුව භාවිතා කරමු, එබැවින් අපි REST gRPC වෙත "පරිවර්තනය" කර පසුව gRPC පමණක් භාවිතා කරමු. ඕනෑම ඉල්ලීමක් Yandex.Cloud සේවකයින්ගේ පොදු සංචිතයක් මත ක්‍රියාත්මක වන අසමමුහුර්ත idempotent කාර්යයන් මාලාවක් නිර්මාණය කිරීමට හේතු වේ. Tasks ලියා ඇත්තේ ඒවා ඕනෑම අවස්ථාවක අත්හිටුවා නැවත ආරම්භ කළ හැකි ආකාරයටය. මෙය පරිමාණය, පුනරාවර්තන හැකියාව සහ මෙහෙයුම් ලොග් කිරීම සහතික කරයි.

ප්රතිඵලයක් වශයෙන්, API වෙතින් කාර්යය Go හි ලියා ඇති balancer සේවා පාලකය වෙත ඉල්ලීමක් කරනු ඇත. එයට සමතුලිතයන් එකතු කිරීම සහ ඉවත් කිරීම, පසුබිම් සහ සැකසුම් වල සංයුතිය වෙනස් කළ හැකිය. 

සේවාව Yandex දත්ත සමුදාය තුළ එහි තත්වය ගබඩා කරයි, ඔබට ඉක්මනින් භාවිතා කළ හැකි බෙදා හරින ලද කළමනාකරණය කළ දත්ත ගබඩාවක්. Yandex.Cloud හි, අප දැනටමත් මෙන් කිව්වා, සුනඛ ආහාර සංකල්පය අදාළ වේ: අප විසින්ම අපගේ සේවාවන් භාවිතා කරන්නේ නම්, අපගේ ගනුදෙනුකරුවන් ද ඒවා භාවිතා කිරීමට සතුටු වනු ඇත. Yandex දත්ත සමුදාය එවැනි සංකල්පයක් ක්රියාත්මක කිරීම සඳහා උදාහරණයකි. අපි අපගේ සියලුම දත්ත YDB හි ගබඩා කරන අතර, දත්ත සමුදාය නඩත්තු කිරීම සහ පරිමාණය කිරීම ගැන අප සිතිය යුතු නැත: මෙම ගැටළු අප වෙනුවෙන් විසඳනු ලැබේ, අපි දත්ත සමුදාය සේවාවක් ලෙස භාවිතා කරමු.

අපි සමතුලිත පාලකය වෙත ආපසු යමු. එහි කර්තව්‍යය වන්නේ සමතුලිතය පිළිබඳ තොරතුරු සුරැකීම සහ අථත්‍ය යන්ත්‍රයේ සූදානම සෞඛ්‍ය පිරික්සුම් පාලකය වෙත පරීක්ෂා කිරීම සඳහා කාර්යයක් යැවීමයි.

සෞඛ්‍ය පරීක්ෂක පාලකය

එය චෙක්පත් නීති වෙනස් කිරීමට ඉල්ලීම් ලබා ගනී, YDB හි ඒවා සුරකියි, හෙල්ට්චෙක් නෝඩ් අතර කාර්යයන් බෙදා හරින අතර ප්‍රතිඵල එකතු කරයි, ඒවා දත්ත සමුදායට සුරකින අතර loadbalancer පාලකය වෙත යවනු ලැබේ. එය අනෙක් අතට, දත්ත තලයේ පොකුරේ සංයුතිය loadbalancer-node වෙත වෙනස් කිරීමට ඉල්ලීමක් යවයි, එය මම පහත සාකච්ඡා කරමි.

සෞඛ්‍ය පරීක්‍ෂණ ගැන වැඩි විස්තර කතා කරමු. ඒවා පන්ති කිහිපයකට බෙදිය හැකිය. විගණනයට විවිධ සාර්ථක නිර්ණායක ඇත. TCP චෙක්පත්වලට නිශ්චිත කාලයක් තුළ සම්බන්ධතාවයක් සාර්ථකව ස්ථාපිත කිරීමට අවශ්‍ය වේ. HTTP චෙක්පත් සඳහා සාර්ථක සම්බන්ධතාවයක් සහ 200 තත්ව කේතයක් සහිත ප්‍රතිචාරයක් අවශ්‍ය වේ.

එසේම, චෙක්පත් ක්රියාකාරී පන්තියේ වෙනස් වේ - ඒවා ක්රියාකාරී සහ නිෂ්ක්රීය වේ. නිෂ්ක්‍රීය චෙක්පත් කිසිදු විශේෂ ක්‍රියාමාර්ගයක් නොගෙන ගමනාගමනය සමඟ සිදුවන දේ නිරීක්ෂණය කරයි. මෙය L4 මත ඉතා හොඳින් ක්‍රියා නොකරයි, මන්ද එය ඉහළ මට්ටමේ ප්‍රොටෝකෝලවල තර්කනය මත රඳා පවතී: L4 හි මෙහෙයුමට කොපමණ කාලයක් ගත වූවාද හෝ සම්බන්ධතාවය සම්පූර්ණ කිරීම හොඳ හෝ නරකද යන්න පිළිබඳ තොරතුරු නොමැත. සක්‍රීය චෙක්පත් සඳහා සමතුලිතයාට එක් එක් සේවාදායක අවස්ථාවට ඉල්ලීම් යැවීමට අවශ්‍ය වේ.

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

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

වෙනස වන්නේ සේවාලාභීන් VIP වෙත ඉල්ලීම් කරන අතර සෞඛ්‍ය පරීක්ෂාවන් එක් එක් RIP වෙත ඉල්ලීම් කිරීමයි. මෙහිදී සිත්ගන්නා ගැටළුවක් පැන නගී: අපි අපගේ පරිශීලකයින්ට අළු IP ජාල වල සම්පත් නිර්මාණය කිරීමට අවස්ථාව ලබා දෙමු. අපි හිතමු විවිධ ක්ලවුඩ් හිමිකරුවන් දෙදෙනෙක් තම සේවා balancers පිටුපස සඟවා ඇති බව. ඒ සෑම එකක්ම 10.0.0.1/24 උපජාලයේ එකම ලිපින සහිත සම්පත් ඇත. ඔබට ඒවා කෙසේ හෝ වෙන්කර හඳුනා ගැනීමට හැකි විය යුතු අතර, මෙහිදී ඔබට Yandex.Cloud අථත්‍ය ජාලයේ ව්‍යුහයට කිමිදිය යුතුය. තුළ වැඩි විස්තර සොයා ගැනීම වඩා හොඳය වීඩියෝව ගැන:වලාකුළු සිදුවීමෙන්, ජාලය බහු ස්ථර සහ උපජාල id මගින් වෙන්කර හඳුනාගත හැකි උමං සහිත වීම අපට දැන් වැදගත් වේ.

සෞඛ්‍ය පරීක්‍ෂණ නෝඩ් ඊනියා අර්ධ-IPv6 ලිපින භාවිතයෙන් සමතුලිතයන් සම්බන්ධ කරයි. අර්ධ ලිපිනයක් යනු IPv6 ලිපිනයක් සහ පරිශීලක උපජාල හැඳුනුම්පතක් එහි අන්තර්ගත IPv4 ලිපිනයකි. ගමනාගමනය සමතුලිතය වෙත ළඟා වන අතර, එයින් IPv4 සම්පත් ලිපිනය උපුටා ගන්නා අතර, IPv6 වෙනුවට IPv4 ආදේශ කර පැකට්ටුව පරිශීලක ජාලයට යවයි.

ප්‍රතිලෝම ගමනාගමනය එකම ආකාරයකින් සිදුවේ: සෞඛ්‍ය පරීක්ෂකයන්ගෙන් ගමනාන්තය අළු ජාලයක් බව සමතුලිතකරු දකින අතර IPv4 IPv6 බවට පරිවර්තනය කරයි.

VPP - දත්ත තලයේ හදවත

සමතුලිතය ක්‍රියාත්මක කරනු ලබන්නේ දෛශික පැකට් සැකසුම් (VPP) තාක්ෂණය භාවිතයෙන් වන අතර එය ජාල ගමනාගමනය කණ්ඩායම් සැකසීම සඳහා සිස්කෝ වෙතින් රාමුවකි. අපගේ නඩුවේදී, රාමුව පරිශීලක-අවකාශ ජාල උපාංග කළමනාකරණ පුස්තකාලය මත ක්‍රියා කරයි - Data Plane Development Kit (DPDK). මෙය ඉහළ පැකට් සැකසුම් කාර්ය සාධනයක් සහතික කරයි: කර්නලයේ බාධා කිරීම් ඉතා අඩුවෙන් සිදු වන අතර කර්නල් අවකාශය සහ පරිශීලක අවකාශය අතර සන්දර්භ ස්විචයන් නොමැත. 

VPP තව දුරටත් ගොස් පැකේජ කාණ්ඩවලට ඒකාබද්ධ කිරීමෙන් පද්ධතියෙන් ඊටත් වඩා කාර්ය සාධනයක් මිරිකයි. නවීන ප්‍රොසෙසරවල හැඹිලි ආක්‍රමණශීලී ලෙස භාවිතා කිරීමෙන් කාර්ය සාධන වාසි ලැබේ. දත්ත හැඹිලි දෙකම භාවිතා කරනු ලැබේ (පැකට් "දෛශික" තුළ සකසනු ලැබේ, දත්ත එකිනෙකට සමීප වේ) සහ උපදෙස් හැඹිලි: VPP හි, පැකට් සැකසීම ප්‍රස්ථාරයක් අනුගමනය කරයි, එහි නෝඩ් එකම කාර්යය ඉටු කරන කාර්යයන් අඩංගු වේ.

උදාහරණයක් ලෙස, VPP හි IP පැකට් සැකසීම පහත අනුපිළිවෙලින් සිදු වේ: පළමුව, පැකට් ශීර්ෂයන් විග්‍රහ කිරීමේ නෝඩයේ විග්‍රහ කරනු ලැබේ, පසුව ඒවා නෝඩයට යවනු ලැබේ, එමඟින් මාර්ගගත වගු අනුව පැකට් තවදුරටත් ඉදිරියට යවනු ලැබේ.

ටිකක් hardcore. VPP හි කතුවරුන් ප්‍රොසෙසර හැඹිලි භාවිතයේදී සම්මුති ඉවසන්නේ නැත, එබැවින් පැකට් දෛශිකයක් සැකසීම සඳහා සාමාන්‍ය කේතය අතින් දෛශිකකරණය අඩංගු වේ: “අපට පෝලිමේ පැකට් හතරක් තිබේ” වැනි තත්වයක් සැකසෙන සැකසුම් ලූපයක් ඇත. පසුව දෙදෙනෙකු සඳහා එකම, පසුව - එක් සඳහා. පසුකාලීන පුනරාවර්තන වලදී ඒවාට ප්‍රවේශය වේගවත් කිරීම සඳහා දත්ත හැඹිලි තුළට පැටවීමට පෙර ලබා ගැනීමේ උපදෙස් බොහෝ විට භාවිතා වේ.

n_left_from = frame->n_vectors;
while (n_left_from > 0)
{
    vlib_get_next_frame (vm, node, next_index, to_next, n_left_to_next);
    // ...
    while (n_left_from >= 4 && n_left_to_next >= 2)
    {
        // processing multiple packets at once
        u32 next0 = SAMPLE_NEXT_INTERFACE_OUTPUT;
        u32 next1 = SAMPLE_NEXT_INTERFACE_OUTPUT;
        // ...
        /* Prefetch next iteration. */
        {
            vlib_buffer_t *p2, *p3;

            p2 = vlib_get_buffer (vm, from[2]);
            p3 = vlib_get_buffer (vm, from[3]);

            vlib_prefetch_buffer_header (p2, LOAD);
            vlib_prefetch_buffer_header (p3, LOAD);

            CLIB_PREFETCH (p2->data, CLIB_CACHE_LINE_BYTES, STORE);
            CLIB_PREFETCH (p3->data, CLIB_CACHE_LINE_BYTES, STORE);
        }
        // actually process data
        /* verify speculative enqueues, maybe switch current next frame */
        vlib_validate_buffer_enqueue_x2 (vm, node, next_index,
                to_next, n_left_to_next,
                bi0, bi1, next0, next1);
    }

    while (n_left_from > 0 && n_left_to_next > 0)
    {
        // processing packets by one
    }

    // processed batch
    vlib_put_next_frame (vm, node, next_index, n_left_to_next);
}

ඉතින්, Healthchecks IPv6 හරහා VPP වෙත කතා කරයි, එය IPv4 බවට පත් කරයි. මෙය සිදු කරනු ලබන්නේ ප්‍රස්ථාරයේ ඇති නෝඩයක් මගිනි, එය අප ඇල්ගොරිතම NAT ලෙස හඳුන්වයි. ප්‍රතිලෝම ගමනාගමනය සඳහා (සහ IPv6 සිට IPv4 දක්වා පරිවර්තනය) එකම ඇල්ගොරිතම NAT නෝඩයක් ඇත.

සමතුලිත සේවාදායකයින්ගෙන් සෘජු ගමනාගමනය සමතුලිතතාවයම සිදු කරන ප්‍රස්ථාර නෝඩ් හරහා ගමන් කරයි. 

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

5-tuple හැෂ් අපට පසුකාලීන ස්ථාවර හැෂිං නෝඩයේ අඩු ගණනය කිරීම් සිදු කිරීමට මෙන්ම සමතුලිතය පිටුපස සම්පත් ලැයිස්තුවේ වෙනස්වීම් වඩා හොඳින් හැසිරවීමට උපකාරී වේ. සැසියක් නොමැති පැකට්ටුවක් සමතුලිතය වෙත පැමිණි විට, එය ස්ථාවර හැෂිං නෝඩයට යවනු ලැබේ. ස්ථාවර හැෂිං භාවිතයෙන් තුලනය සිදු වන්නේ මෙහිදීය: පවතින "සජීවී" සම්පත් ලැයිස්තුවෙන් අපි සම්පතක් තෝරා ගනිමු. ඊළඟට, පැකට් NAT නෝඩය වෙත යවනු ලැබේ, එය ඇත්ත වශයෙන්ම ගමනාන්ත ලිපිනය ප්‍රතිස්ථාපනය කර චෙක්සම් නැවත ගණනය කරයි. ඔබට පෙනෙන පරිදි, අපි VPP හි නීති රීති අනුගමනය කරමු - කැමති කිරීමට කැමති, ප්‍රොසෙසර හැඹිලිවල කාර්යක්ෂමතාව වැඩි කිරීම සඳහා සමාන ගණනය කිරීම් කණ්ඩායම්ගත කරන්න.

ස්ථාවර හැෂිං

අපි එය තෝරා ගත්තේ ඇයි සහ එය පවා කුමක්ද? පළමුව, අපි පෙර කාර්යය සලකා බලමු - ලැයිස්තුවෙන් සම්පතක් තෝරා ගැනීම. 

නොගැලපෙන හැෂිං සමඟ, එන පැකට්ටුවේ හැෂ් ගණනය කරනු ලබන අතර, මෙම හැෂ් සම්පත් ගණනින් බෙදීමේ ඉතිරි කොටස මඟින් ලැයිස්තුවෙන් සම්පතක් තෝරා ගනු ලැබේ. ලැයිස්තුව නොවෙනස්ව පවතින තාක්, මෙම යෝජනා ක්රමය හොඳින් ක්රියා කරයි: අපි සෑම විටම එකම 5-tuple සහිත පැකට් එකම අවස්ථාවට යවන්නෙමු. උදාහරණයක් ලෙස, යම් සම්පතක් සෞඛ්‍ය පරීක්‍ෂණවලට ප්‍රතිචාර දැක්වීම නැවැත්වුවහොත්, හැෂ් වල සැලකිය යුතු කොටසක් සඳහා තේරීම වෙනස් වේ. සේවාලාභියාගේ TCP සම්බන්ධතා බිඳී යනු ඇත: කලින් A අවස්ථාවට ළඟා වූ පැකට්ටුවක් මෙම පැකට්ටුව සඳහා වන සැසියට හුරු නැති B අවස්ථාවට ළඟා වීමට පටන් ගත හැකිය.

අඛණ්ඩව හෑෂ් කිරීම විස්තර කරන ලද ගැටළුව විසඳයි. මෙම සංකල්පය පැහැදිලි කිරීමට ඇති පහසුම ක්‍රමය මෙයයි: ඔබ සතුව හෑෂ් මගින් සම්පත් බෙදා හරින මුද්දක් ඇතැයි සිතන්න (උදාහරණයක් ලෙස, IP:port මගින්). සම්පතක් තෝරාගැනීම යනු පැකට්ටුවේ හැෂ් මගින් තීරණය කරනු ලබන කෝණයකින් රෝදය හැරවීමයි.

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

සමතුලිතය සහ සම්පත් අතර සෘජු ගමනාගමනයට සිදුවන්නේ කුමක්දැයි අපි සොයා බැලුවෙමු. දැන් අපි බලමු return Traffic එක ගැන. එය ගමනාගමනය පිරික්සීමේ රටාවම අනුගමනය කරයි - ඇල්ගොරිතම NAT හරහා, එනම්, සේවාදායක ගමනාගමනය සඳහා ප්‍රතිලෝම NAT 44 හරහා සහ සෞඛ්‍ය පරීක්‍ෂණ ගමනාගමනය සඳහා NAT 46 හරහා. අපි අපගේම යෝජනා ක්‍රමයට අනුගත වෙමු: අපි සෞඛ්‍ය පරීක්‍ෂණ ගමනාගමනය සහ සැබෑ පරිශීලක ගමනාගමනය ඒකාබද්ධ කරමු.

Loadbalancer-node සහ එකලස් කරන ලද සංරචක

VPP හි සමතුලිත සහ සම්පත් සංයුතිය දේශීය සේවය - loadbalancer-node විසින් වාර්තා කරනු ලැබේ. එය loadbalancer-controller වෙතින් සිදුවීම් ප්‍රවාහයට දායක වන අතර වත්මන් VPP තත්ත්වය සහ පාලකයෙන් ලැබෙන ඉලක්ක තත්ත්වය අතර වෙනස සැලසුම් කිරීමට හැකි වේ. අපට සංවෘත පද්ධතියක් ලැබේ: API වෙතින් සිදුවීම් සමතුලිත පාලකය වෙත පැමිණෙන අතර, සම්පත්වල "සජීවී බව" පරීක්ෂා කිරීම සඳහා සෞඛ්ය පරීක්ෂක පාලකයට කාර්යයන් පවරයි. එය අනෙක් අතට, සෞඛ්‍ය පරීක්‍ෂණ-නෝඩයට කාර්යයන් පවරන අතර ප්‍රතිඵල එකතු කරයි, ඉන්පසු එය නැවත සමතුලිත පාලකය වෙත යවයි. Loadbalancer-node පාලකයෙන් සිදුවීම් වලට දායක වන අතර VPP හි තත්වය වෙනස් කරයි. එවැනි පද්ධතියක් තුළ, සෑම සේවාවක්ම අසල්වැසි සේවාවන් ගැන අවශ්ය දේ පමණක් දනී. සම්බන්ධතා ගණන සීමිත වන අතර විවිධ කොටස් ස්වාධීනව ක්‍රියාත්මක කිරීමට සහ පරිමාණය කිරීමට අපට හැකියාව ඇත.

වැළකුණු ගැටළු මොනවාද?

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

ගැටළු සහ විසඳුම්

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

එසේම, ක්‍රියාකාරී පරීක්ෂණ සඳහා Go හොඳම තේරීම නොවිය හැක. ඒවා තරමක් වාචික වන අතර, "CI හි සෑම දෙයක්ම කණ්ඩායමක් තුළ ධාවනය කිරීම" යන සම්මත ප්රවේශය ඔවුන් සඳහා ඉතා සුදුසු නොවේ. කාරණය නම් ක්‍රියාකාරී පරීක්ෂණ වඩා සම්පත් ඉල්ලුමක් ඇති අතර සැබෑ කාල සීමාවන් ඇති කරයි. මේ නිසා, CPU ඒකක පරීක්ෂණ සමඟ කාර්යබහුල බැවින් පරීක්ෂණ අසාර්ථක විය හැක. නිගමනය: හැකි නම්, ඒකක පරීක්ෂණ වලින් වෙන වෙනම "බර" පරීක්ෂණ සිදු කරන්න. 

ක්ෂුද්‍ර සේවා සිද්ධි ගෘහ නිර්මාණ ශිල්පය මොනොලිතයකට වඩා සංකීර්ණ ය: විවිධ යන්ත්‍ර දුසිම් ගණනක ලඝු-සටහන් එකතු කිරීම ඉතා පහසු නොවේ. නිගමනය: ඔබ ක්ෂුද්‍ර සේවා කරන්නේ නම්, වහාම සොයා ගැනීම ගැන සිතන්න.

අපේ සැලසුම්

අපි අභ්‍යන්තර සමතුලිතයක්, IPv6 balancer එකක් දියත් කරන්නෙමු, Kubernetes ස්ක්‍රිප්ට් සඳහා සහය එක් කරන්නෙමු, අපගේ සේවාවන් අඛණ්ඩව බෙදාහරින්නෙමු (දැනට සෞඛ්‍ය පරීක්‍ෂණ-නෝඩ් සහ සෞඛ්‍ය පරීක්‍ෂණ-ctrl පමණක් බෙදා ඇත), නව සෞඛ්‍ය පරීක්‍ෂණ එක් කරන්න, සහ චෙක්පත් සමතුලිත කිරීම ක්‍රියාත්මක කරන්නෙමු. අපගේ සේවාවන් වඩාත් ස්වාධීන කිරීමට ඇති හැකියාව අපි සලකා බලමින් සිටිමු - එවිට ඔවුන් එකිනෙකා සමඟ සෘජුව නොව පණිවිඩ පෝලිමක් භාවිතා කරයි. SQS-අනුකූල සේවාවක් මෑතකදී Cloud හි දර්ශනය විය Yandex පණිවිඩ පෝලිම.

මෑතකදී, Yandex Load Balancer හි ප්රසිද්ධ නිකුතුව සිදු විය. ගවේෂණය කරන්න ලේඛනගත කිරීම සේවාවට, ඔබට පහසු ආකාරයෙන් සමතුලිත කළමනාකරණය කරන්න සහ ඔබේ ව්‍යාපෘතිවල වැරදි ඉවසීම වැඩි කරන්න!

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