නවීන දත්ත මධ්‍යස්ථානවල විවිධ ආකාරයේ නිරීක්ෂණ මගින් ආවරණය වන සක්‍රීය උපාංග සිය ගණනක් ස්ථාපනය කර ඇත. නමුත් අතේ පරිපූර්ණ අධීක්ෂණයක් ඇති පරමාදර්ශී ඉංජිනේරුවෙකුට පවා මිනිත්තු කිහිපයකින් ජාල අසාර්ථකත්වයකට නිවැරදිව ප්‍රතිචාර දැක්විය හැකිය. Next Hop 2020 සම්මන්ත්‍රණයේ වාර්තාවක, මම DC ජාල සැලසුම් ක්‍රමවේදයක් ඉදිරිපත් කළෙමි, එයට සුවිශේෂී ලක්ෂණයක් ඇත - දත්ත මධ්‍යස්ථානය මිලි තත්පර වලින් සුව වේ. වඩාත් නිවැරදිව, ඉංජිනේරුවරයා සන්සුන්ව ගැටළුව විසඳන අතර, සේවාවන් එය නොසලකයි.
බොහෝ ජාල ඉංජිනේරුවන් සඳහා, දත්ත මධ්‍යස්ථාන ජාලයක් ආරම්භ වන්නේ, ඇත්ත වශයෙන්ම, ToR සමඟ, රාක්කයේ ස්විචයක් සමඟිනි. ToR සාමාන්යයෙන් සබැඳි වර්ග දෙකක් ඇත. කුඩා ඒවා සේවාදායකයන් වෙත යයි, අනෙක් ඒවා - N ගුණයකින් වැඩි ඒවා ඇත - පළමු මට්ටමේ කශේරුකා දෙසට, එනම් එහි ඉහළ සබැඳි වෙත යන්න. Uplinks සාමාන්යයෙන් සමාන ලෙස සලකනු ලබන අතර, ප්‍රෝටෝ, src_ip, dst_ip, src_port, dst_port ඇතුළත් වන 5-tuple වෙතින් හැෂ් එකක් මත පදනම්ව uplinks අතර ගමනාගමනය සමතුලිත වේ. මෙහි විස්මයන් නොමැත.
ඊළඟට, සැලසුම් ගෘහ නිර්මාණ ශිල්පය පෙනෙන්නේ කෙසේද? පළමු මට්ටමේ කඤ්චුක එකිනෙකට සම්බන්ධ වී නැත, නමුත් superspines හරහා සම්බන්ධ වේ. X අකුර සුපර්ස්පයින් සඳහා වගකිව යුතු ය; එය හරස් සම්බන්ධයක් වැනි ය.
අනෙක් අතට, ටෝරි පළමු මට්ටමේ සියලුම කොඳු ඇට පෙළට සම්බන්ධ වී ඇති බව පැහැදිලිය. මෙම පින්තූරයේ වැදගත් වන්නේ කුමක්ද? අපට රාක්කය තුළ අන්තර්ක්රියා තිබේ නම්, අන්තර්ක්රියා, ඇත්ත වශයෙන්ම, ToR හරහා ගමන් කරයි. මොඩියුලය තුළ අන්තර්ක්රියා සිදුවන්නේ නම්, අන්තර්ක්රියා සිදු වන්නේ පළමු මට්ටමේ කටු හරහා ය. අන්තර්ක්රියා අන්තර් මොඩියුලර් නම් - මෙහි මෙන්, ToR 1 සහ ToR 2 - එවිට අන්තර්ක්රියා පළමු සහ දෙවන මට්ටම් දෙකෙහිම කටු හරහා යයි.
න්යායාත්මකව, එවැනි ගෘහ නිර්මාණ ශිල්පයක් පහසුවෙන් පරිමාණය කළ හැකිය. අපට වරාය ධාරිතාව, දත්ත මධ්‍යස්ථානයේ අමතර ඉඩ සහ පෙර තැබූ තන්තු තිබේ නම්, මංතීරු ගණන සැමවිටම වැඩි කළ හැකි අතර එමඟින් පද්ධතියේ සමස්ත ධාරිතාව වැඩි කළ හැකිය. කඩදාසි මත මෙය කිරීම ඉතා පහසුය. සැබෑ ජීවිතයේ දී එය එසේ වනු ඇත. නමුත් අද කතාව ඒ ගැන නොවේ.
නිවැරදි නිගමනවලට එළඹීමට මට අවශ්‍යයි. දත්ත මධ්‍යස්ථානය තුළ අපට බොහෝ මාර්ග තිබේ. ඔවුන් කොන්දේසි සහිතව ස්වාධීන වේ. දත්ත මධ්‍යස්ථානය තුළ එක් මාර්ගයක් කළ හැක්කේ ToR තුළ පමණි. මොඩියුලය තුළ, අපට ගුවන් යානා ගණනට සමාන මාර්ග ගණනක් ඇත. මොඩියුල අතර ඇති මාර්ග ගණන ගුවන් යානා ගණනේ ගුණිතයට සමාන වන අතර එක් එක් තලයේ ඇති සුපර්ස්පින් ගණනට සමාන වේ. එය වඩාත් පැහැදිලි කිරීමට, පරිමාණය දැනීමට, මම Yandex දත්ත මධ්යස්ථානයක් සඳහා වලංගු සංඛ්යා ලබා දෙන්නෙමි.
ගුවන් යානා අටක් ඇත, සෑම යානයකටම සුපර්ස්පින් 32 ක් ඇත. එහි ප්රතිඵලයක් වශයෙන්, මොඩියුලය තුළ මාර්ග අටක් ඇති බව පෙනී යන අතර, අන්තර් මොඩියුල අන්තර්ක්රියා සමඟ දැනටමත් ඒවායින් 256 ක් ඇත.
එනම්, අපි Cookbook සංවර්ධනය කරන්නේ නම්, තමන්ම සුවපත් වන දෝෂ-ඉවසන දත්ත මධ්‍යස්ථාන ගොඩනඟන්නේ කෙසේදැයි ඉගෙන ගැනීමට උත්සාහ කරන්නේ නම්, තල ගෘහ නිර්මාණ ශිල්පය නිවැරදි තේරීම වේ. පරිමාණ ගැටළුව විසඳීමට එය ඔබට ඉඩ සලසයි, න්යායාත්මකව එය පහසු වේ. බොහෝ ස්වාධීන මාර්ග තිබේ. ප්රශ්නය ඉතිරිව පවතී: එවැනි ගෘහ නිර්මාණ ශිල්පයක් අසාර්ථක වීමෙන් බේරෙන්නේ කෙසේද? විවිධ කඩා වැටීම් තිබේ. තවද අපි දැන් මේ ගැන සාකච්ඡා කරමු.
අපේ සුපිරි දඟකාරයෙක් අසනීප වෙන්න ඉඩ දෙන්න. මෙන්න මම ගුවන් යානා දෙකක ගෘහ නිර්මාණ ශිල්පය වෙත ආපසු පැමිණියෙමි. අඩු චලනය වන කොටස් සමඟ සිදුවන්නේ කුමක්ද යන්න සරලව බැලීම පහසු වනු ඇති නිසා අපි උදාහරණයක් ලෙස මේවා සමඟ රැඳී සිටිමු. X11 ලෙඩ වෙන්න දෙන්න. දත්ත මධ්‍යස්ථාන තුළ ජීවත් වන සේවාවන්ට මෙය බලපාන්නේ කෙසේද? අසාර්ථකත්වය සැබවින්ම පෙනෙන්නේ කෙසේද යන්න මත බොහෝ දේ රඳා පවතී.
අසාර්ථකත්වය හොඳ නම්, එය එකම BFD හි ස්වයංක්‍රීයකරණ මට්ටමට හසු වේ, ස්වයංක්‍රීයකරණය සතුටින් ගැටළු සහගත සන්ධි දමා ගැටලුව හුදකලා කරයි, එවිට සියල්ල හොඳයි. අපට බොහෝ මාර්ග තිබේ, ගමනාගමනය ක්ෂණිකව විකල්ප මාර්ග වෙත නැවත හරවා යවනු ලබන අතර සේවාවන් කිසිවක් නොදකිනු ඇත. මේක හොඳ ජවනිකාවක්.
නරක තත්වයක් නම් අපට නිරන්තර පාඩු ඇති නම් සහ ස්වයංක්‍රීයකරණය ගැටලුව නොසලකයි. මෙය යෙදුමට බලපාන්නේ කෙසේද යන්න තේරුම් ගැනීමට, TCP ප්‍රොටෝකෝලය ක්රියා කරන ආකාරය සාකච්ඡා කිරීමට අපට සුළු කාලයක් ගත කිරීමට සිදුවනු ඇත.
මෙම තොරතුරු සමඟ මම කිසිවෙකු කම්පනයට පත් නොකරනු ඇතැයි මම බලාපොරොත්තු වෙමි: TCP යනු සම්ප්‍රේෂණ තහවුරු කිරීමේ ප්‍රොටෝකෝලයකි. එනම්, සරලම අවස්ථාවෙහිදී, යවන්නා පැකට් දෙකක් යවන අතර ඒවා මත සමුච්චිත ඇක් එකක් ලබා ගනී: "මට පැකට් දෙකක් ලැබුණා."
ඊට පසු, ඔහු තවත් පැකට් දෙකක් යවන අතර, තත්වය නැවත නැවතත් සිදුවනු ඇත. යම් සරල කිරීමක් සඳහා මම කල්තියා සමාව අයදිමි. කවුළුව (ගුවන් ගමනේ පැකට් ගණන) දෙකක් නම් මෙම දර්ශනය නිවැරදි වේ. ඇත්ත වශයෙන්ම, මෙය සාමාන්යයෙන් අවශ්ය නොවේ. නමුත් පැකට් ඉදිරියට යැවීමේ සන්දර්භය කවුළුවේ ප්‍රමාණයට බලපාන්නේ නැත.
පැකට් 3 නැති උනොත් මොකද වෙන්නේ? මෙම අවස්ථාවේදී, ලබන්නාට පැකට් 1, 2 සහ 4 ලැබෙනු ඇත. තවද ඔහු SACK විකල්පය භාවිතයෙන් යවන්නාට පැහැදිලිවම පවසනු ඇත: "ඔබ දන්නවා, තුනක් ආවා, නමුත් මැද නැති වී ඇත." ඔහු කියනවා "Ack 2, SACK 4".
මේ මොහොතේ, යවන්නා කිසිදු ගැටළුවක් නොමැතිව නැතිවූ පැකට්ටුව හරියටම පුනරුච්චාරණය කරයි.
නමුත් කවුළුවේ අවසාන පැකට්ටුව නැති වුවහොත් තත්වය සම්පූර්ණයෙන්ම වෙනස් වනු ඇත.
ලබන්නාට පළමු පැකට් තුන ලැබෙන අතර පළමුවෙන්ම බලා සිටීමට පටන් ගනී. ලිනක්ස් කර්නලයේ TCP තොගයේ ඇති සමහර ප්‍රශස්තිකරණයන්ට ස්තූතිවන්ත වන අතර, එය අවසන් පැකට්ටුව හෝ ඒ හා සමාන දෙයක් බව ධජ පැහැදිලිව දක්වන්නේ නම් මිස එය යුගල කළ පැකට්ටුවක් සඳහා රැඳී සිටිනු ඇත. එය ප්‍රමාද වූ ACK කල් ඉකුත්වීම අවසන් වන තෙක් බලා සිට පළමු පැකට් තුනට පිළිගැනීමක් එවනු ඇත. නමුත් දැන් යවන්නා බලා සිටිනු ඇත. හතරවන පැකේජය නැති වී තිබේද නැතහොත් පැමිණීමට ආසන්නද යන්න ඔහු නොදනී. ජාලය අධික ලෙස පැටවීම නොකිරීමට, එය පැකට්ටුව නැති වී ඇති බවට පැහැදිලි ඇඟවීමක් හෝ RTO කල් ඉකුත්වීම සඳහා රැඳී සිටීමට උත්සාහ කරයි.
RTO කල් ඉකුත්වීම යනු කුමක්ද? මෙය TCP තොගය සහ සමහර නියතය මගින් ගණනය කරන ලද RTT හි උපරිමය වේ. මෙය කුමන ආකාරයේ නියතයක්ද, අපි දැන් සාකච්ඡා කරමු.
හැබැයි වැදගත්ම දේ තමයි අපි ආයෙත් අවාසනාවන්ත වෙලා හතරවෙනි පැකට් එක ආයෙ නැති උනොත් RTO ඩබල් වෙනවා. එනම්, සෑම අසාර්ථක උත්සාහයක්ම කාල සීමාව දෙගුණ කිරීමකි.
දැන් අපි බලමු මොකක්ද මේ පදනම සමාන වෙන්නේ කියලා. පෙරනිමියෙන්, අවම RTO 200 ms වේ. දත්ත පැකට් සඳහා අවම RTO මෙයයි. SYN පැකට් සඳහා, එය වෙනස් වේ, තත්පර 1. ඔබට පෙනෙන පරිදි, පැකට් නැවත යැවීමේ පළමු උත්සාහය පවා දත්ත මධ්‍යස්ථානය තුළ ඇති RTT වලට වඩා 100 ගුණයකින් වැඩි කාලයක් ගතවනු ඇත.
දැන් අපි අපේ දර්ශනය වෙත ආපසු යමු. සේවාව සමඟ සිදු වන්නේ කුමක්ද? සේවාව පැකට් නැති වීමට පටන් ගනී. සේවාව මුලින් කොන්දේසි සහිත වාසනාවන්ත වීමට ඉඩ දෙන්න සහ කවුළුව මැද යමක් නැති වී යයි, පසුව එය SACK එකක් ලබාගෙන නැති වූ පැකට් නැවත යවයි.
නමුත් අවාසනාව නැවත නැවත සිදුවුවහොත්, අපට RTO ඇත. මෙහි වැදගත් වන්නේ කුමක්ද? ඔව්, අපට ජාලය තුළ බොහෝ මාර්ග තිබේ. නමුත් එක් විශේෂිත TCP සම්බන්ධතාවයක TCP ගමනාගමනය එකම කැඩුණු තොගය හරහා දිගටම ගමන් කරනු ඇත. පැකට් පාඩුව, අපගේ මැජික් X11 තනිවම පිටතට නොයන බව සපයා ඇති අතර, ගැටලුකාරී නොවන ප්‍රදේශවලට ගමනාගමනය ගලා නොයයි. අපි එම කැඩුණු තොගය හරහා පැකට්ටුවක් ලබා දීමට උත්සාහ කරමු. මෙය කඩා වැටීමේ අසාර්ථකත්වයට තුඩු දෙයි: දත්ත මධ්යස්ථානයක් යනු අන්තර්ක්රියා කරන යෙදුම් සමූහයක් වන අතර, මෙම සියලුම යෙදුම්වල සමහර TCP සම්බන්ධතා පිරිහීමට පටන් ගනී - මන්ද සුපර්ස්පින් දත්ත මධ්‍යස්ථානය තුළ ඇති සියලුම යෙදුම් වලට බලපායි. කියමනෙහි මෙන්: ඔබ අශ්වයෙකුට සපත්තු නොදුන්නේ නම්, අශ්වයා කොර යයි; අශ්වයා කොර - වාර්තාව ලබා දී නැත; පණිවිඩය ලබා දුන්නේ නැත - ඔවුන්ට යුද්ධය අහිමි විය. ගැටළුව ඇති වූ මොහොතේ සිට සේවා දැනෙන්නට පටන් ගන්නා පරිහානියේ අවධිය දක්වා ගණන් කිරීම තත්පර ගණනකට යන්නේ මෙහිදී පමණි. මෙයින් අදහස් කරන්නේ පරිශීලකයින්ට කොතැනක හෝ යමක් නොලැබිය හැකි බවයි.
එකිනෙකට අනුපූරක වන සම්භාව්ය විසඳුම් දෙකක් තිබේ. පළමුවැන්න නම් පිදුරු දමා ගැටලුව විසඳීමට උත්සාහ කරන සේවාවන් ය: “අපි TCP තොගයේ යමක් වෙනස් කරමු. අභ්‍යන්තර සෞඛ්‍ය පරීක්‍ෂාවන් සමඟින් යෙදුම් මට්ටමින් හෝ දිගුකාලීන TCP සැසිවලින් කල් ඉකුත් වෙමු." ගැටලුව වන්නේ එවැනි විසඳුම්: a) කිසිසේත් පරිමාණය නොවේ; ආ) ඉතා දුර්වල ලෙස පරීක්ෂා කර ඇත. එනම්, සේවාව අහම්බෙන් TCP තොගය වඩා හොඳ වන ආකාරයෙන් වින්‍යාස කළත්, පළමුව, එය සියලුම යෙදුම් සහ සියලුම දත්ත මධ්‍යස්ථාන සඳහා අදාළ වීමට අපහසුය, දෙවනුව, බොහෝ විට, එය සිදු කළ බව එය තේරුම් නොගනී. නිවැරදිව , සහ නැති දේ. එනම්, එය ක්රියා කරයි, නමුත් එය දුර්වල ලෙස ක්රියා කරන අතර පරිමාණ නොවේ. තවද ජාල ගැටලුවක් තිබේ නම්, දොස් පැවරිය යුත්තේ කාටද? ඇත්ත වශයෙන්ම, NOC. NOC කරන්නේ කුමක්ද?
බොහෝ සේවාවන් විශ්වාස කරන්නේ NOC වල වැඩ මේ වගේ දෙයක් බවයි. නමුත් අවංකව කිවහොත් පමණක් නොවේ.
සම්භාව්ය යෝජනා ක්‍රමයේ NOC බොහෝ නිරීක්ෂණ සංවර්ධනයෙහි නියැලී සිටී. මේවා කළු පෙට්ටි නිරීක්ෂණ සහ සුදු පෙට්ටි නිරීක්ෂණය යන දෙකම වේ. කළු පෙට්ටිය-කොඳු ඇට පෙළ නිරීක්ෂණය කිරීමේ උදාහරණය ගැන ඇලෙක්සැන්ඩර් ක්ලිමෙන්කෝ අවසාන ඊළඟ හොප් එකේ. මාර්ගය වන විට, මෙම අධීක්ෂණය ක්රියා කරයි. නමුත් පරමාදර්ශී අධීක්ෂණයට පවා කාල ප්‍රමාදයක් ඇත. සාමාන්යයෙන් මෙය මිනිත්තු කිහිපයකි. එය ක්රියා විරහිත වූ පසු, රාජකාරියේ යෙදී සිටින ඉංජිනේරුවන්ට එහි ක්රියාකාරිත්වය දෙවරක් පරීක්ෂා කිරීමටත්, ගැටලුව ප්‍රාදේශීයකරණය කිරීමටත්, පසුව ගැටළු සහිත ප්‍රදේශය නිවා දැමීමටත් කාලය අවශ්ය වේ. එනම්, හොඳම අවස්ථාවෙහිදී, පාඩු සිදුවන්නේ කොතැනද යන්න වහාම නොපැහැදිලි නම්, ගැටලුවට ප්රතිකාර කිරීම විනාඩි 5 ක්, නරකම අවස්ථාවක, විනාඩි 20 ක් ගතවේ. මේ කාලය පුරාම - මිනිත්තු 5 ක් හෝ 20 ක් - අපගේ සේවාවන් දිගටම දුක් විඳිනු ඇති බව පැහැදිලිය, එය බොහෝ විට හොඳ නැත.
ඔබ ඇත්තටම ලැබීමට කැමති කුමක්ද? අපට බොහෝ මාර්ග තිබේ. අවාසනාවන්ත TCP ප්‍රවාහයන් එකම මාර්ගය දිගටම භාවිතා කිරීම නිසා ගැටළු ඇතිවේ. එක් TCP සම්බන්ධතාවයක් තුළ විවිධ මාර්ග භාවිතා කිරීමට අපට ඉඩ සලසන දෙයක් අපට අවශ්ය වේ. අපට විසඳුමක් ඇති බව පෙනේ. TCP ඇත, එය බහුමාර්ග TCP ලෙස හැඳින්වේ, එනම් බහු මාර්ග සඳහා TCP. ඇත්ත, එය සම්පූර්ණයෙන්ම වෙනස් කාර්යයක් සඳහා සංවර්ධනය කරන ලදී - ජාල උපාංග කිහිපයක් ඇති ස්මාර්ට්ෆෝන් සඳහා. මාරු කිරීම උපරිම කිරීමට හෝ ප්‍රාථමික/බැකප් මාදිලිය සෑදීමට, යෙදුමට විනිවිද පෙනෙන බහු නූල් (සැසි) සාදන යාන්ත්‍රණයක් සංවර්ධනය කරන ලද අතර අසාර්ථක වූ විට ඒවා අතර මාරු වීමට ඔබට ඉඩ සලසයි. නැත්නම්, මම කිව්වා වගේ, ස්ට්රීක් උපරිම කරන්න.
නමුත් මෙහි සූක්ෂ්මතාවයක් තිබේ. එය කුමක්ද යන්න තේරුම් ගැනීමට, නූල් ස්ථාපිත කර ඇති ආකාරය දෙස බැලීමට සිදුවනු ඇත.
නූල් අනුපිළිවෙලින් සකසා ඇත. පළමු ධාරාව මුලින්ම ස්ථාපනය කර ඇත. පසුව එම නූල් තුළ දැනටමත් එකඟ වී ඇති කුකිය භාවිතයෙන් පසු නූල් සකසනු ලැබේ. ඒ වගේම මෙන්න මේකයි ගැටලුව.
ගැටලුව වන්නේ පළමු ත්‍රෙඩ් එක ස්ථාපිත නොවන්නේ නම්, දෙවන සහ තුන්වන නූල් කිසි විටෙකත් මතු නොවනු ඇත. එනම්, Multipath TCP පළමු ප්‍රවාහයේදී SYN පැකට්ටුවක අලාභය විසඳන්නේ නැත. තවද SYN නැති වුවහොත්, බහුමාර්ග TCP සාමාන්‍ය TCP බවට හැරේ. මෙයින් අදහස් කරන්නේ දත්ත මධ්‍යස්ථාන පරිසරයක එය කර්මාන්තශාලාවේ පාඩු පිළිබඳ ගැටළුව විසඳීමට සහ අසාර්ථක වූ විට බහු මාර්ග භාවිතා කිරීමට ඉගෙන ගැනීමට අපට උපකාරී නොවන බවයි.
අපට උපකාර කළ හැක්කේ කුමක්ද? අපගේ වැඩිදුර කතාවේ වැදගත් ක්ෂේත්‍රයක් වනුයේ IPv6 ප්රවාහ ලේබල් ශීර්ෂ ක්ෂේත්‍රය බව ඔබගෙන් සමහරෙක් දැනටමත් මාතෘකාවෙන් අනුමාන කර ඇත. ඇත්ත වශයෙන්ම, මෙය v6 හි දිස්වන ක්ෂේත්‍රයකි, එය v4 හි නොවේ, එය බිටු 20 ක් අල්ලාගෙන ඇත, සහ දිගු කාලයක් තිස්සේ එහි භාවිතය පිළිබඳ මතභේද පවතී. මෙය ඉතා සිත්ගන්නා සුළුය - ආරවුල් ඇති විය, RFC තුළ යමක් සවි කර ඇති අතර, ඒ සමඟම ලිනක්ස් කර්නලය තුළ ක්‍රියාත්මක කිරීමක් දර්ශනය විය, එය කොතැනකවත් ලේඛනගත කර නොමැත.
පොඩි පරීක්ෂණයකට මාත් එක්ක යන්න කියලා මම ආරාධනා කරනවා. පසුගිය වසර කිහිපය තුළ ලිනක්ස් කර්නලයේ සිදුවෙමින් පවතින දේ දෙස බලමු.
වසර 2014. එක් විශාල සහ ගෞරවනීය සමාගමක ඉංජිනේරුවෙකු විසින් ලිනක්ස් කර්නලයේ ක්‍රියාකාරීත්වයට සොකට් හැෂ් මත ප්රවාහ ලේබල් අගය මත යැපීම එක් කරයි. ඔවුන් මෙහි නිවැරදි කිරීමට උත්සාහ කළේ කුමක්ද? මෙය RFC 6438 හා සම්බන්ධ වන අතර, එය පහත ගැටලුව සාකච්ඡා කළේය. දත්ත මධ්‍යස්ථානය තුළ, IPv4 බොහෝ විට IPv6 පැකට් වල කොටා ඇත, මන්ද කර්මාන්ත ශාලාවම IPv6 වන නමුත් IPv4 කෙසේ හෝ පිටත ලබා දිය යුතුය. TCP හෝ UDP වෙත යාමට සහ එහි src_ports, dst_ports සොයා ගැනීමට IP ශීර්ෂ දෙකක් යටතේ බැලීමට නොහැකි වූ ස්විචයන් සමඟ දිගු කාලයක් තිස්සේ ගැටළු ඇති විය. ඔබ පළමු IP ශීර්ෂ දෙක දෙස බැලුවහොත් හැෂ් එක බොහෝ දුරට සවි කර ඇති බව පෙනී ගියේය. මෙය වළක්වා ගැනීම සඳහා, මෙම සංවෘත ගමනාගමනය සමතුලිත කිරීම නිවැරදිව ක්‍රියාත්මක වන පරිදි, ප්රවාහ ලේබල් ක්ෂේත්‍රයේ අගයට 5-tuple සංවෘත පැකට්ටුවේ හැෂ් එකතු කිරීමට යෝජනා කරන ලදී. UDP සඳහා, GRE සඳහා, අනෙකුත් encapsulation යෝජනා ක්‍රම සඳහාද ආසන්න වශයෙන් එකම දේ සිදු කරන ලදී, දෙවැන්න GRE Key ක්ෂේත්‍රය භාවිතා කළේය. එක් ආකාරයකින් හෝ වෙනත් ආකාරයකින්, මෙහි අරමුණු පැහැදිලිය. අඩුම තරමින් එම අවස්ථාවේ දී ඔවුන් ප්රයෝජනවත් විය.
2015 දී, එකම ගෞරවනීය ඉංජිනේරුවෙකුගෙන් නව පැච් එකක් පැමිණේ. ඔහු ඉතා සිත්ගන්නා සුළුය. එය පහත සඳහන් දේ කියයි - සෘණ මාර්ගගත කිරීමේ සිදුවීමකදී අපි හැෂ් අහඹු ලෙස වෙනස් කරන්නෙමු. සෘණ මාර්ගගත සිදුවීමක් යනු කුමක්ද? මේක තමයි අපි කලින් සාකච්ඡා කරපු RTO එක, ඒ කියන්නේ ජනේලයේ වලිගය නැතිවීම ඇත්තටම සෘණාත්මක සිදුවීමක්. ඇත්ත, මෙය එය යැයි අනුමාන කිරීම සාපේක්ෂව දුෂ්කර ය.
2016, තවත් පිළිගත් සමාගමක්, ද විශාල. එය අවසාන කිහිලිකරු විසුරුවා හරින අතර, අප කලින් අහඹු ලෙස සාදන ලද හැෂ්, දැන් එක් එක් SYN නැවත සම්ප්‍රේෂණය සඳහා සහ එක් එක් RTO කල් ඉකුත්වීමෙන් පසුව වෙනස් වන පරිදි එය සිදු කරයි. තවද මෙම ලිපියේ, පළමු සහ අවසාන වතාවට, අවසාන ඉලක්කය සඳහන් කර ඇත - පාඩු හෝ නාලිකා තදබදයකදී ගමනාගමනය මෘදු ලෙස නැවත මාර්ගගත කිරීමට සහ බහු මාර්ග භාවිතා කිරීමට හැකියාව ඇති බව සහතික කිරීම. ඇත්ත වශයෙන්ම, මෙයින් පසු ප්‍රකාශන රාශියක් තිබුණි, ඔබට ඒවා පහසුවෙන් සොයාගත හැකිය.
නැතත්, ඔබට බැහැ, මන්ද මෙම මාතෘකාව පිළිබඳ එක ප්‍රකාශනයක් හෝ නොතිබුණි. නමුත් අපි දන්නවා!
ඔබ සිදු කළ දේ සම්පූර්ණයෙන්ම තේරුම් නොගන්නේ නම්, මම දැන් ඔබට කියමි.
ලිනක්ස් කර්නලයට එකතු කළේ කුමක්ද, කුමන ක්‍රියාකාරිත්වයද? එක් එක් RTO සිදුවීමෙන් පසු txhash අහඹු අගයකට වෙනස් වේ. මෙය මාර්ගගත කිරීමේ ඉතා සෘණාත්මක ප්රතිඵලයයි. හැෂ් මෙම txhash මත රඳා පවතින අතර, ප්රවාහ ලේබලය skb හැෂ් මත රඳා පවතී. මෙහි ශ්‍රිත පිළිබඳ ගණනය කිරීම් කිහිපයක් ඇත; සියලුම විස්තර එක් විනිවිදකයක් මත තැබිය නොහැක. කවුරුහරි කුතුහලයෙන් සිටිනවා නම්, ඔබට කර්නල් කේතය හරහා ගොස් පරීක්ෂා කළ හැකිය.
මෙහි වැදගත් වන්නේ කුමක්ද? ප්රවාහ ලේබල් ක්ෂේත්‍රයේ අගය එක් එක් RTOට පසුව අහඹු අංකයකට වෙනස් වේ. මෙය අපගේ අවාසනාවන්ත TCP ප්‍රවාහයට බලපාන්නේ කෙසේද?
SACK එකක් සිදුවුවහොත්, අපි දන්නා නැතිවූ පැකට්ටුවක් නැවත යැවීමට උත්සාහ කරන නිසා කිසිවක් වෙනස් නොවේ. මේ වනතෙක් ගොඩක් හොඳයි.
නමුත් RTO සම්බන්ධයෙන්, අපි ToR හි හැෂ් ශ්‍රිතයට ප්රවාහ ලේබලයක් එක් කර ඇත්නම්, ගමනාගමනය වෙනස් මාර්ගයක් ගත හැකිය. තවද මංතීරු වැඩි වන තරමට, එය විශේෂිත උපාංගයක අසාර්ථකත්වයකින් බලපෑමට ලක් නොවන මාර්ගයක් සොයා ගැනීමට ඇති අවස්ථාව වැඩි වේ.
එක් ගැටළුවක් ඉතිරිව ඇත - RTO. තවත් මාර්ගයක්, ඇත්ත වශයෙන්ම, සොයාගෙන ඇත, නමුත් ඒ සඳහා බොහෝ කාලයක් වැය වේ. 200ms ගොඩක්. දෙවැන්න සාමාන්යයෙන් වනචරත්වයයි. මීට පෙර, මම සේවා වින්‍යාස කරන කාල සීමාවන් ගැන කතා කළෙමි. එබැවින්, තත්පරයක් යනු සාමාන්යයෙන් යෙදුම් මට්ටමින් සේවාවක් සකසන කාල සීමාවක් වන අතර මෙම සේවාව සාපේක්ෂව නිවැරදි වනු ඇත. එපමණක් නොව, මම නැවතත්, නවීන දත්ත මධ්යස්ථානයක් තුළ සැබෑ RTT මිලි තත්පර 1 ක් පමණ වේ.
RTO කල් ඉකුත්වීම් සමඟ ඔබට කුමක් කළ හැකිද? දත්ත පැකට් නැතිවීමකදී RTO සඳහා වගකිව යුතු කාල සීමාව, පරිශීලක අවකාශයෙන් සාපේක්ෂව පහසුවෙන් වින්‍යාසගත කළ හැකිය: IP උපයෝගීතාවයක් ඇති අතර එහි එක් පරාමිතියක එකම rto_min අඩංගු වේ. RTO, ඇත්ත වශයෙන්ම, ගෝලීය වශයෙන් නොව, ලබා දී ඇති උපසර්ග සඳහා සකස් කළ යුතු බව සලකන විට, එවැනි යාන්ත්‍රණයක් තරමක් ක්රියා කළ හැකි බව පෙනේ.
ඇත්ත, SYN_RTO සමඟ සෑම දෙයක්ම තරමක් නරක ය. එය ස්වභාවිකවම ඇණ ගසා ඇත. කර්නලයට තත්පර 1 ක ස්ථාවර අගයක් ඇත, එය එයයි. ඔබට පරිශීලක අවකාශයෙන් එහි ළඟා විය නොහැක. ඇත්තේ එකම මාර්ගයකි.
eBPF ගලවා ගැනීමට පැමිණේ. සරලව කිවහොත්, මේවා කුඩා C වැඩසටහන් වේ, ඒවා කර්නල් ස්ටැක් සහ TCP ස්ටැක් ක්‍රියාත්මක කිරීමේදී විවිධ ස්ථානවල කොකුවලට ඇතුළු කළ හැකිය, එමඟින් ඔබට ඉතා විශාල සැකසුම් ප්‍රමාණයක් වෙනස් කළ හැකිය. පොදුවේ ගත් කල, eBPF යනු දිගු කාලීන ප්‍රවණතාවයකි. නව sysctl පරාමිති දුසිම් ගනනක් කපා හැරීම සහ IP උපයෝගීතාව පුළුල් කිරීම වෙනුවට, ව්යාපාරය eBPF වෙත ගමන් කරමින් එහි ක්රියාකාරිත්වය පුළුල් කරයි. eBPF භාවිතයෙන්, ඔබට තදබදය පාලනය සහ වෙනත් විවිධ TCP සැකසුම් ගතිකව වෙනස් කළ හැක.
නමුත් එහි ආධාරයෙන් ඔබට SYN_RTO හි අගයන් විකෘති කළ හැකි බව අපට වැදගත් වේ. ප්‍රසිද්ධියේ පළ කළ උදාහරණයක් තිබේ: . මෙහි සිදු කරන්නේ කුමක්ද? උදාහරණය වැඩ කරයි, නමුත් එයම ඉතා රළු ය. මෙහිදී උපකල්පනය කරනු ලබන්නේ දත්ත මධ්‍යස්ථානය තුළ අපි පළමු බිටු 44 සංසන්දනය කරන බවයි; ඒවා ගැලපෙන්නේ නම්, අපි දත්ත මධ්‍යස්ථානය තුළ සිටිමු. තවද මෙම අවස්ථාවේදී අපි SYN_RTO කල් ඉකුත්වීමේ අගය 4ms ලෙස වෙනස් කරමු. එකම කාර්යය වඩාත් අලංකාර ලෙස කළ හැකිය. නමුත් මෙම සරල උදාහරණය පෙන්නුම් කරන්නේ මෙය අ) හැකි බවයි; b) සාපේක්ෂව පහසුයි.
අපි දැනටමත් දන්නේ කුමක්ද? ගුවන් යානා ගෘහ නිර්මාණ ශිල්පය පරිමාණය කිරීමට ඉඩ සලසන කාරණය, අපි ToR මත ප්රවාහ ලේබලය සක්‍රීය කර ගැටළු සහිත ප්‍රදේශ වටා ගලා යාමේ හැකියාව ලබා ගන්නා විට එය අපට අතිශයින්ම ප්රයෝජනවත් වේ. RTO සහ SYN-RTO අගයන් අඩු කිරීමට හොඳම ක්රමය eBPF වැඩසටහන් භාවිතා කිරීමයි. ප්රශ්නය ඉතිරිව පවතී: සමතුලිත කිරීම සඳහා ප්රවාහ ලේබලයක් භාවිතා කිරීම ආරක්ෂිතද? තවද මෙහි සූක්ෂ්මතාවයක් ඇත.
ඔබගේ ජාලයේ ඕනෑම ආකාරයකින් ජීවත් වන සේවාවක් ඔබට ඇතැයි සිතමු. අවාසනාවකට, anycast යනු කුමක්ද යන්න ගැන විස්තර කිරීමට මට වෙලාවක් නැත, නමුත් එය එකම IP ලිපිනය හරහා ප්‍රවේශ විය හැකි විවිධ භෞතික සේවාදායකයන් සහිත බෙදාහැරීමේ සේවාවකි. මෙහි ඇති විය හැකි ගැටළුවක් ඇත: RTO සිදුවීම සිදුවිය හැක්කේ රෙදිපිළි හරහා ගමනාගමනය ගමන් කරන විට පමණක් නොවේ. එය ToR බෆර මට්ටමින් ද සිදු විය හැක: ඉන්කාස්ට් සිදුවීමක් සිදු වූ විට, ධාරකය යම් දෙයක් වැගිරෙන විට එය ධාරකය මත පවා සිදු විය හැක. RTO සිදුවීමක් සිදු වූ විට සහ එය ප්රවාහ ලේබලය වෙනස් කරන විට. මෙම අවස්ථාවේදී, ගමනාගමනය වෙනත් ඕනෑම අවස්ථාවකට යා හැක. අපි උපකල්පනය කරමු මෙය ප්‍රකාශිත ඕනෑම විකාශනයක්, එහි සම්බන්ධතා තත්වයක් අඩංගු වේ - එය L3 Balancer හෝ වෙනත් සේවාවක් විය හැකිය. එවිට ගැටළුවක් පැන නගී, මන්ද RTO ට පසුව මෙම TCP සම්බන්ධතාවය ගැන කිසිවක් නොදන්නා සේවාදායකයට TCP සම්බන්ධතාවය පැමිණේ. අපට ඕනෑම විකාශන සේවාදායක අතර රාජ්‍ය බෙදාගැනීමක් නොමැති නම්, එවැනි ගමනාගමනය අත්හරිනු ඇති අතර TCP සම්බන්ධතාවය බිඳී යනු ඇත.
මෙහි කුමක් කළ හැකිද? ඔබගේ පාලිත පරිසරය තුළ, ඔබ ප්රවාහ ලේබල තුලනය සක්‍රීය කරන විට, ඕනෑම විකාශන සේවාදායක වෙත ප්‍රවේශ වීමේදී ඔබ ප්රවාහ ලේබලයේ අගය සටහන් කළ යුතුය. පහසුම ක්රමය වන්නේ එකම eBPF වැඩසටහන හරහා මෙය සිදු කිරීමයි. නමුත් මෙහි ඉතා වැදගත් කරුණක් ඇත - ඔබ දත්ත මධ්‍යස්ථාන ජාලයක් ක්‍රියාත්මක නොකරන්නේ නම්, නමුත් ටෙලිකොම් ක්‍රියාකරුවෙකු නම් කුමක් කළ යුතුද? මෙය ඔබගේද ගැටලුවකි: Juniper සහ Arista හි ඇතැම් අනුවාද වලින් පටන් ගෙන, ඔවුන් පෙරනිමියෙන් ඔවුන්ගේ හැෂ් ශ්‍රිතවල ප්රවාහ ලේබලයක් ඇතුළත් කරයි - අවංකවම, මට අපැහැදිලි හේතුවක් නිසා. මෙය ඔබගේ ජාලය හරහා ගමන් කරන පරිශීලකයින්ගෙන් TCP සම්බන්ධතා අත්හැරීමට හේතු විය හැක. එබැවින් ඔබගේ රවුටර සැකසුම් මෙහි පරීක්ෂා කිරීමට මම තරයේ නිර්දේශ කරමි.
එක් ආකාරයකින් හෝ වෙනත් ආකාරයකින්, අපි අත්හදා බැලීම් වෙත යාමට සූදානම් බව මට පෙනේ.
අපි ToR හි ප්රවාහ ලේබලය සක්‍රිය කළ විට, දැන් සත්කාරක මත ජීවත් වන නියෝජිතයාගේ eBPF සකස් කළ විට, අපි ඊළඟ විශාල අසාර්ථකත්වය බලා නොසිට, පාලිත පිපිරීම් සිදු කිරීමට තීරණය කළෙමු. අපි uplink හතරක් තියෙන ToR අරගෙන එකකට drops දැම්මා. ඔවුන් රීතියක් ඇදගත්තා, ඔවුන් කිව්වා - දැන් ඔබට සියලු පැකට් අහිමි වෙනවා. ඔබට වම් පසින් පෙනෙන පරිදි, අපට පැකට් එකකට නිරීක්ෂණ ඇත, එය 75% දක්වා පහත වැටී ඇත, එනම් පැකට් වලින් 25% ක් නැති වී ඇත. දකුණු පසින් මෙම ToR පිටුපස ජීවත් වන සේවා ප්රස්ථාර ඇත. ඇත්ත වශයෙන්ම, මේවා රාක්කයේ ඇතුළත සේවාදායකයන් සහිත සන්ධිවල ගමනාගමන ප්රස්ථාර වේ. ඔබට පෙනෙන පරිදි, ඔවුන් ඊටත් වඩා පහළට ගිලී ගියේය. ඔවුන් පහළට ගිලී ගියේ ඇයි - 25% කින් නොවේ, නමුත් සමහර අවස්ථාවල 3-4 ගුණයකින්? TCP සම්බන්ධතාවය අවාසනාවන්ත නම්, එය කැඩුණු අතුරු මුහුණත හරහා ළඟා වීමට උත්සාහ කරයි. DC තුළ ඇති සේවාවේ සාමාන්‍ය හැසිරීම මගින් මෙය උග්‍ර වේ - එක් පරිශීලක ඉල්ලීමක් සඳහා, අභ්‍යන්තර සේවා සඳහා N ඉල්ලීම් උත්පාදනය වන අතර, ප්‍රතිචාරය පරිශීලකයා වෙත යනු ඇත, එක්කෝ සියලුම දත්ත මූලාශ්‍ර ප්‍රතිචාර දක්වන විට හෝ කල් ඉකුත් වූ විට තවමත් වින්‍යාස කිරීමට අවශ්ය යෙදුම් මට්ටම. එනම්, සෑම දෙයක්ම ඉතා නරක ය.
දැන් එකම අත්හදා බැලීම, නමුත් ප්රවාහ ලේබලය සක්‍රීය කර ඇත. ඔබට පෙනෙන පරිදි, වම් පසින්, අපගේ කණ්ඩායම නිරීක්ෂණය කිරීම එම 25% කින්ම ගිලී ඇත. මෙය සම්පූර්ණයෙන්ම නිවැරදියි, එය නැවත සම්ප්‍රේෂණය කිරීම ගැන කිසිවක් නොදන්නා නිසා, එය පැකට් යවන අතර බෙදා හරින ලද සහ නැතිවූ පැකට් ගණනේ අනුපාතය ගණනය කරයි.
සහ දකුණු පසින් සේවා කාලසටහන වේ. ගැටළු සන්ධියක බලපෑම ඔබට මෙහි සොයාගත නොහැක. එම මිලි තත්පරවලම ගමනාගමනය ගැටලුකාරී ප්‍රදේශයේ සිට ගැටලුවට බල නොපා ඇති ඉතිරි උඩුබැඳි තුන දක්වා ගලා ගියේය. අපට සුවපත් වන ජාලයක් ලැබුණා.
මෙය මගේ අවසාන ස්ලයිඩයයි, සාරාංශ කිරීමට කාලයයි. දැන්, ස්වයං-සුව කිරීමේ දත්ත මධ්‍යස්ථාන ජාලයක් ගොඩනඟන්නේ කෙසේදැයි ඔබ දන්නවා යැයි මම බලාපොරොත්තු වෙමි. ඔබට ලිනක්ස් කර්නල් ලේඛනාගාරය හරහා ගොස් එහි විශේෂ පැච් සෙවීමට අවශ්ය නොවනු ඇත; මෙම නඩුවේ ප්රවාහ ලේබලය ගැටළුව විසඳන බව ඔබ දන්නවා, නමුත් ඔබ මෙම යාන්ත්‍රණය ප්‍රවේශමෙන් ප්‍රවේශ විය යුතුය. තවද මම නැවත වරක් අවධාරණය කරන්නේ ඔබ ටෙලිකොම් ක්‍රියාකරුවෙකු නම්, ඔබ හැෂ් ශ්‍රිතයක් ලෙස ප්රවාහ ලේබලය භාවිතා නොකළ යුතු බවත්, එසේ නොමැතිනම් ඔබ ඔබේ පරිශීලකයින්ගේ සැසිවලට බාධා කරන බවත්ය.
ජාල ඉංජිනේරුවන් සඳහා, සංකල්පමය මාරුවක් සිදු විය යුතුය: ජාලය ToR සමඟ ආරම්භ නොවේ, ජාල උපාංගයක් සමඟ නොව, සත්කාරකයක් සමඟ. තරමක් කැපී පෙනෙන උදාහරණයක් නම්, RTO වෙනස් කිරීමට සහ ඕනෑම විකාශන සේවා සඳහා ප්රවාහ ලේබලය සවි කිරීමට අපි eBPF භාවිතා කරන ආකාරයයි.
ප්රවාහ ලේබල් යාන්ත්‍ර විද්‍යාව පාලිත පරිපාලන අංශය තුළ වෙනත් යෙදුම් සඳහා නිසැකවම සුදුසු වේ. මෙය දත්ත මධ්‍යස්ථාන අතර ගමනාගමනය විය හැකිය, නැතහොත් පිටතට යන ගමනාගමනය කළමනාකරණය කිරීමට ඔබට එවැනි යාන්ත්‍රික විශේෂ ආකාරයකින් භාවිතා කළ හැකිය. නමුත් මම මේ ගැන කතා කරන්නම්, මම බලාපොරොත්තු වෙනවා, ඊළඟ වතාවේ. ඔබගේ අවධානයට බොහෝම ස්තූතියි.
මූලාශ්රය: www.habr.com