സ്വയം സുഖപ്പെടുത്തുന്ന ഒരു നെറ്റ്‌വർക്ക്: ഫ്ലോ ലേബലിന്റെ മാന്ത്രികതയും ലിനക്സ് കേർണലിന് ചുറ്റുമുള്ള ഡിറ്റക്ടീവും. Yandex റിപ്പോർട്ട്

ആധുനിക ഡാറ്റാ സെൻ്ററുകളിൽ നൂറുകണക്കിന് സജീവ ഉപകരണങ്ങൾ ഇൻസ്റ്റാൾ ചെയ്തിട്ടുണ്ട്, അവ വ്യത്യസ്ത തരം നിരീക്ഷണങ്ങളാൽ മൂടപ്പെട്ടിരിക്കുന്നു. എന്നാൽ കൈയിൽ തികഞ്ഞ നിരീക്ഷണമുള്ള ഒരു മികച്ച എഞ്ചിനീയർക്ക് പോലും കുറച്ച് മിനിറ്റുകൾക്കുള്ളിൽ നെറ്റ്‌വർക്ക് പരാജയത്തോട് ശരിയായി പ്രതികരിക്കാൻ കഴിയും. നെക്സ്റ്റ് ഹോപ്പ് 2020 കോൺഫറൻസിലെ ഒരു റിപ്പോർട്ടിൽ, ഞാൻ ഒരു ഡിസി നെറ്റ്‌വർക്ക് ഡിസൈൻ രീതിശാസ്ത്രം അവതരിപ്പിച്ചു, അതിന് ഒരു സവിശേഷ സവിശേഷതയുണ്ട് - ഡാറ്റാ സെൻ്റർ മില്ലിസെക്കൻഡിൽ സ്വയം സുഖപ്പെടുത്തുന്നു. കൂടുതൽ കൃത്യമായി പറഞ്ഞാൽ, എഞ്ചിനീയർ ശാന്തമായി പ്രശ്നം പരിഹരിക്കുന്നു, അതേസമയം സേവനങ്ങൾ അത് ശ്രദ്ധിക്കുന്നില്ല.

— ആരംഭിക്കുന്നതിന്, ഒരു ആധുനിക ഡിസിയുടെ ഘടനയെക്കുറിച്ച് അറിയാത്തവർക്കായി ഞാൻ വളരെ വിശദമായ ഒരു ആമുഖം നൽകും.


പല നെറ്റ്‌വർക്ക് എഞ്ചിനീയർമാർക്കും, ഒരു ഡാറ്റ സെൻ്റർ നെറ്റ്‌വർക്ക് ആരംഭിക്കുന്നു, തീർച്ചയായും, ടോറിനൊപ്പം, റാക്കിലെ ഒരു സ്വിച്ച് ഉപയോഗിച്ച്. ToR-ന് സാധാരണയായി രണ്ട് തരം ലിങ്കുകൾ ഉണ്ട്. ചെറിയവ സെർവറുകളിലേക്ക് പോകുന്നു, മറ്റുള്ളവ - അവയിൽ N മടങ്ങ് കൂടുതലുണ്ട് - ആദ്യ ലെവലിൻ്റെ സ്പൈനുകളിലേക്ക്, അതായത്, അതിൻ്റെ അപ്‌ലിങ്കുകളിലേക്ക് പോകുക. അപ്‌ലിങ്കുകൾ സാധാരണയായി തുല്യമായി കണക്കാക്കപ്പെടുന്നു, പ്രോട്ടോ, src_ip, dst_ip, src_port, dst_port എന്നിവ ഉൾപ്പെടുന്ന 5-tuple-ൽ നിന്നുള്ള ഒരു ഹാഷിനെ അടിസ്ഥാനമാക്കി അപ്‌ലിങ്കുകൾക്കിടയിലുള്ള ട്രാഫിക് ബാലൻസ് ചെയ്യുന്നു. ഇവിടെ അത്ഭുതങ്ങളൊന്നുമില്ല.


അടുത്തതായി, പ്ലാൻ ആർക്കിടെക്ചർ എങ്ങനെയിരിക്കും? ആദ്യ ലെവലിൻ്റെ മുള്ളുകൾ പരസ്പരം ബന്ധിപ്പിച്ചിട്ടില്ല, മറിച്ച് സൂപ്പർ സ്‌പൈനുകൾ വഴി ബന്ധിപ്പിച്ചിരിക്കുന്നു. എക്‌സ് എന്ന അക്ഷരം സൂപ്പർ സ്‌പൈനുകൾക്ക് ഉത്തരവാദിയായിരിക്കും; ഇത് ഏതാണ്ട് ഒരു ക്രോസ് കണക്ട് പോലെയാണ്.


മറുവശത്ത്, ടോറി ആദ്യ ലെവലിലെ എല്ലാ മുള്ളുകളുമായും ബന്ധപ്പെട്ടിരിക്കുന്നുവെന്ന് വ്യക്തമാണ്. ഈ ചിത്രത്തിൽ എന്താണ് പ്രധാനം? റാക്കിനുള്ളിൽ നമുക്ക് ഇടപെടൽ ഉണ്ടെങ്കിൽ, ഇടപെടൽ തീർച്ചയായും ToR-ലൂടെ കടന്നുപോകുന്നു. മൊഡ്യൂളിനുള്ളിലാണ് പ്രതിപ്രവർത്തനം സംഭവിക്കുന്നതെങ്കിൽ, ആദ്യ ലെവൽ മുള്ളുകളിലൂടെയാണ് ഇടപെടൽ സംഭവിക്കുന്നത്. ഇൻ്ററാക്ഷൻ ഇൻ്റർമോഡുലാർ ആണെങ്കിൽ - ഇവിടെ പോലെ, ToR 1 ഉം ToR 2 ഉം - അപ്പോൾ പ്രതിപ്രവർത്തനം ഒന്നും രണ്ടും ലെവലുകളുടെ മുള്ളുകളിലൂടെ കടന്നുപോകും.


സിദ്ധാന്തത്തിൽ, അത്തരമൊരു വാസ്തുവിദ്യ എളുപ്പത്തിൽ അളക്കാവുന്നതാണ്. ഞങ്ങൾക്ക് പോർട്ട് കപ്പാസിറ്റി, ഡാറ്റാ സെൻ്ററിൽ സ്പെയർ സ്പേസ്, പ്രീ-ലെയ്ഡ് ഫൈബർ എന്നിവ ഉണ്ടെങ്കിൽ, പാതകളുടെ എണ്ണം എപ്പോഴും വർദ്ധിപ്പിക്കാനും അതുവഴി സിസ്റ്റത്തിൻ്റെ മൊത്തത്തിലുള്ള ശേഷി വർദ്ധിപ്പിക്കാനും കഴിയും. കടലാസിൽ ഇത് ചെയ്യാൻ വളരെ എളുപ്പമാണ്. ജീവിതത്തിൽ ഇങ്ങനെയായിരിക്കും. എന്നാൽ ഇന്നത്തെ കഥ അതിനെക്കുറിച്ചല്ല.


ശരിയായ നിഗമനങ്ങളിൽ എത്തിച്ചേരണമെന്ന് ഞാൻ ആഗ്രഹിക്കുന്നു. ഡാറ്റാ സെൻ്ററിനുള്ളിൽ ഞങ്ങൾക്ക് നിരവധി പാതകളുണ്ട്. അവർ സോപാധികമായി സ്വതന്ത്രരാണ്. ഡാറ്റാ സെൻ്ററിനുള്ളിലെ ഒരു പാത ToR-നുള്ളിൽ മാത്രമേ സാധ്യമാകൂ. മൊഡ്യൂളിനുള്ളിൽ, നമുക്ക് പാതകളുടെ എണ്ണത്തിന് തുല്യമായ പാതകളുണ്ട്. മൊഡ്യൂളുകൾക്കിടയിലുള്ള പാതകളുടെ എണ്ണം, ഓരോ വിമാനത്തിലെയും പ്ലെയിനുകളുടെ എണ്ണത്തിൻ്റെയും സൂപ്പർ സ്പൈനുകളുടെയും എണ്ണത്തിന് തുല്യമാണ്. ഇത് വ്യക്തമാക്കുന്നതിന്, സ്കെയിൽ മനസ്സിലാക്കാൻ, Yandex ഡാറ്റാ സെൻ്ററുകളിലൊന്നിന് സാധുതയുള്ള നമ്പറുകൾ ഞാൻ നൽകും.


എട്ട് വിമാനങ്ങളുണ്ട്, ഓരോ വിമാനത്തിനും 32 സൂപ്പർ സ്പൈനുകൾ ഉണ്ട്. തൽഫലമായി, മൊഡ്യൂളിനുള്ളിൽ എട്ട് പാതകളുണ്ടെന്നും ഇൻ്റർമോഡ്യൂൾ ഇടപെടലിനൊപ്പം അവയിൽ 256 എണ്ണം ഇതിനകം ഉണ്ടെന്നും ഇത് മാറുന്നു.

അതായത്, ഞങ്ങൾ കുക്ക്ബുക്ക് വികസിപ്പിച്ചെടുക്കുകയാണെങ്കിൽ, സ്വയം സുഖപ്പെടുത്തുന്ന തെറ്റ്-സഹിഷ്ണുതയുള്ള ഡാറ്റാ സെൻ്ററുകൾ എങ്ങനെ നിർമ്മിക്കാമെന്ന് പഠിക്കാൻ ശ്രമിക്കുകയാണെങ്കിൽ, പ്ലാനർ ആർക്കിടെക്ചറാണ് ശരിയായ തിരഞ്ഞെടുപ്പ്. ഇത് സ്കെയിലിംഗ് പ്രശ്നം പരിഹരിക്കുന്നു, സൈദ്ധാന്തികമായി ഇത് എളുപ്പമാണ്. നിരവധി സ്വതന്ത്ര പാതകളുണ്ട്. ചോദ്യം അവശേഷിക്കുന്നു: അത്തരമൊരു വാസ്തുവിദ്യ പരാജയങ്ങളെ എങ്ങനെ അതിജീവിക്കും? വിവിധ പരാജയങ്ങളുണ്ട്. ഞങ്ങൾ ഇപ്പോൾ ഇത് ചർച്ച ചെയ്യും.


നമ്മുടെ സൂപ്പർ സ്‌പൈനുകളിൽ ഒരാൾ "രോഗം പിടിപെടട്ടെ". ഇവിടെ ഞാൻ രണ്ട് വിമാന വാസ്തുവിദ്യയിലേക്ക് മടങ്ങി. ചലിക്കുന്ന ഭാഗങ്ങൾ കുറവായതിനാൽ എന്താണ് സംഭവിക്കുന്നതെന്ന് കാണാൻ എളുപ്പമായതിനാൽ ഞങ്ങൾ ഇവയെ ഒരു ഉദാഹരണമായി പരിഗണിക്കും. X11 അസുഖം വരട്ടെ. ഡാറ്റാ സെൻ്ററുകൾക്കുള്ളിൽ താമസിക്കുന്ന സേവനങ്ങളെ ഇത് എങ്ങനെ ബാധിക്കും? പരാജയം യഥാർത്ഥത്തിൽ എങ്ങനെ കാണപ്പെടുന്നു എന്നതിനെ ആശ്രയിച്ചിരിക്കുന്നു.


പരാജയം നല്ലതാണെങ്കിൽ, അതേ BFD യുടെ ഓട്ടോമേഷൻ തലത്തിൽ അത് പിടിക്കപ്പെടുന്നു, ഓട്ടോമേഷൻ സന്തോഷത്തോടെ പ്രശ്നമുള്ള സന്ധികൾ ഇടുകയും പ്രശ്നം ഒറ്റപ്പെടുത്തുകയും ചെയ്യുന്നു, അപ്പോൾ എല്ലാം ശരിയാണ്. ഞങ്ങൾക്ക് നിരവധി പാതകളുണ്ട്, ട്രാഫിക് തൽക്ഷണം ബദൽ റൂട്ടുകളിലേക്ക് റീ-റൂട്ട് ചെയ്യുന്നു, സേവനങ്ങൾ ഒന്നും ശ്രദ്ധിക്കില്ല. ഇതൊരു നല്ല തിരക്കഥയാണ്.


ഞങ്ങൾക്ക് നിരന്തരമായ നഷ്ടങ്ങൾ ഉണ്ടെങ്കിൽ, ഓട്ടോമേഷൻ പ്രശ്നം ശ്രദ്ധിക്കുന്നില്ല എന്നതാണ് ഒരു മോശം സാഹചര്യം. ഇത് ഒരു ആപ്ലിക്കേഷനെ എങ്ങനെ ബാധിക്കുന്നു എന്ന് മനസിലാക്കാൻ, ടിസിപി എങ്ങനെ പ്രവർത്തിക്കുന്നുവെന്ന് ചർച്ചചെയ്യാൻ ഞങ്ങൾക്ക് കുറച്ച് സമയം ചെലവഴിക്കേണ്ടിവരും.


ഈ വിവരം കൊണ്ട് ഞാൻ ആരെയും ഞെട്ടിക്കില്ലെന്ന് ഞാൻ പ്രതീക്ഷിക്കുന്നു: TCP ഒരു ട്രാൻസ്മിഷൻ സ്ഥിരീകരണ പ്രോട്ടോക്കോൾ ആണ്. അതായത്, ഏറ്റവും ലളിതമായ സാഹചര്യത്തിൽ, അയച്ചയാൾ രണ്ട് പാക്കറ്റുകൾ അയയ്ക്കുകയും അവയിൽ ഒരു ക്യുമുലേറ്റീവ് ആക്ക് സ്വീകരിക്കുകയും ചെയ്യുന്നു: "എനിക്ക് രണ്ട് പാക്കറ്റുകൾ ലഭിച്ചു."


അതിനുശേഷം, അവൻ രണ്ട് പാക്കറ്റുകൾ കൂടി അയയ്ക്കും, സാഹചര്യം ആവർത്തിക്കും. ചില ലളിതവൽക്കരണത്തിന് ഞാൻ മുൻകൂട്ടി ക്ഷമ ചോദിക്കുന്നു. വിൻഡോ (വിമാനത്തിലെ പാക്കറ്റുകളുടെ എണ്ണം) രണ്ടാണെങ്കിൽ ഈ സാഹചര്യം ശരിയാണ്. തീർച്ചയായും, പൊതുവേ, ഇത് അങ്ങനെയാകണമെന്നില്ല. എന്നാൽ വിൻഡോ വലുപ്പം പാക്കറ്റ് ഫോർവേഡിംഗ് സന്ദർഭത്തെ ബാധിക്കില്ല.


പാക്കറ്റ് 3 നഷ്ടപ്പെട്ടാൽ എന്ത് സംഭവിക്കും? ഈ സാഹചര്യത്തിൽ, സ്വീകർത്താവിന് പാക്കറ്റുകൾ 1, 2, 4 എന്നിവ ലഭിക്കും. കൂടാതെ SACK ഓപ്ഷൻ ഉപയോഗിച്ച് അയച്ചയാളോട് അവൻ വ്യക്തമായി പറയും: "നിങ്ങൾക്കറിയാമോ, മൂന്ന് എത്തി, പക്ഷേ മധ്യഭാഗം നഷ്ടപ്പെട്ടു." അവൻ പറയുന്നു, "Ack 2, SACK 4."


ഈ നിമിഷം, ഒരു പ്രശ്നവുമില്ലാതെ അയച്ചയാൾ നഷ്ടപ്പെട്ട പാക്കറ്റ് കൃത്യമായി ആവർത്തിക്കുന്നു.


എന്നാൽ വിൻഡോയിലെ അവസാന പാക്കറ്റ് നഷ്ടപ്പെട്ടാൽ, സ്ഥിതി തികച്ചും വ്യത്യസ്തമായിരിക്കും.

സ്വീകർത്താവ് ആദ്യത്തെ മൂന്ന് പാക്കറ്റുകൾ സ്വീകരിക്കുകയും ആദ്യം കാത്തിരിക്കാൻ തുടങ്ങുകയും ചെയ്യുന്നു. ലിനക്സ് കെർണലിൻ്റെ TCP സ്റ്റാക്കിലെ ചില ഒപ്റ്റിമൈസേഷനുകൾക്ക് നന്ദി, ഫ്ലാഗുകൾ ഇത് അവസാന പാക്കറ്റാണോ അല്ലെങ്കിൽ സമാനമായ മറ്റെന്തെങ്കിലും ആണെന്ന് വ്യക്തമായി സൂചിപ്പിക്കുന്നില്ലെങ്കിൽ, ജോടിയാക്കിയ പാക്കറ്റിനായി ഇത് കാത്തിരിക്കും. വൈകിയ ACK കാലഹരണപ്പെടൽ അവസാനിക്കുന്നത് വരെ ഇത് കാത്തിരിക്കുകയും ആദ്യത്തെ മൂന്ന് പാക്കറ്റുകൾക്ക് ഒരു അംഗീകാരം അയക്കുകയും ചെയ്യും. എന്നാൽ ഇപ്പോൾ അയച്ചയാൾ കാത്തിരിക്കും. നാലാമത്തെ പാക്കേജ് നഷ്ടപ്പെട്ടതാണോ അതോ എത്താൻ പോകുകയാണോ എന്ന് അവനറിയില്ല. നെറ്റ്‌വർക്ക് ഓവർലോഡ് ചെയ്യാതിരിക്കാൻ, പാക്കറ്റ് നഷ്‌ടമായതിൻ്റെ വ്യക്തമായ സൂചനയ്‌ക്കായി അല്ലെങ്കിൽ ആർടിഒ കാലഹരണപ്പെടുന്നതിന് ഇത് കാത്തിരിക്കാൻ ശ്രമിക്കും.


എന്താണ് RTO കാലഹരണപ്പെടൽ? ഇത് TCP സ്റ്റാക്കും ചില സ്ഥിരാങ്കങ്ങളും കണക്കാക്കിയ RTT യുടെ പരമാവധി ആണ്. ഇത് ഏത് തരത്തിലുള്ള സ്ഥിരതയാണ്, നമ്മൾ ഇപ്പോൾ ചർച്ച ചെയ്യും.


എന്നാൽ പ്രധാന കാര്യം, നമുക്ക് വീണ്ടും നിർഭാഗ്യവശാൽ, നാലാമത്തെ പാക്കറ്റ് വീണ്ടും നഷ്ടപ്പെടുകയാണെങ്കിൽ, RTO ഇരട്ടിയാകും. അതായത്, ഓരോ പരാജയ ശ്രമവും അർത്ഥമാക്കുന്നത് സമയപരിധി ഇരട്ടിയാക്കുന്നു എന്നാണ്.


ഇനി ഈ അടിസ്ഥാനം എന്താണ് എന്ന് നോക്കാം. ഡിഫോൾട്ടായി, ഏറ്റവും കുറഞ്ഞ RTO 200 ms ആണ്. ഡാറ്റാ പാക്കേജുകൾക്കുള്ള ഏറ്റവും കുറഞ്ഞ RTO ഇതാണ്. SYN പാക്കറ്റുകൾക്ക് ഇത് വ്യത്യസ്തമാണ്, 1 സെക്കൻഡ്. നിങ്ങൾക്ക് കാണാനാകുന്നതുപോലെ, പാക്കറ്റുകൾ വീണ്ടും അയയ്‌ക്കാനുള്ള ആദ്യ ശ്രമത്തിന് പോലും ഡാറ്റാ സെൻ്ററിനുള്ളിലെ RTT-യെക്കാൾ 100 മടങ്ങ് കൂടുതൽ സമയമെടുക്കും.


ഇനി നമുക്ക് നമ്മുടെ സാഹചര്യത്തിലേക്ക് മടങ്ങാം. സേവനത്തിൽ എന്താണ് സംഭവിക്കുന്നത്? സേവനം പാക്കറ്റുകൾ നഷ്ടപ്പെടാൻ തുടങ്ങുന്നു. സേവനം ആദ്യം സോപാധികമായി ഭാഗ്യമുള്ളതായിരിക്കട്ടെ, വിൻഡോയുടെ മധ്യത്തിൽ എന്തെങ്കിലും നഷ്‌ടപ്പെടട്ടെ, തുടർന്ന് അതിന് ഒരു SACK ലഭിക്കുകയും നഷ്ടപ്പെട്ട പാക്കറ്റുകൾ വീണ്ടും അയയ്ക്കുകയും ചെയ്യുന്നു.


പക്ഷേ ഭാഗ്യം ആവർത്തിച്ചാൽ നമുക്ക് ഒരു ആർ.ടി.ഒ. ഇവിടെ എന്താണ് പ്രധാനം? അതെ, ഞങ്ങളുടെ നെറ്റ്‌വർക്കിൽ ധാരാളം പാതകളുണ്ട്. എന്നാൽ ഒരു പ്രത്യേക ടിസിപി കണക്ഷൻ്റെ ടിസിപി ട്രാഫിക് അതേ തകർന്ന സ്റ്റാക്കിലൂടെ തുടരും. ഞങ്ങളുടെ ഈ മാന്ത്രിക X11 സ്വന്തമായി പുറത്തുപോകുന്നില്ലെങ്കിൽ, പ്രശ്‌നരഹിതമായ മേഖലകളിലേക്ക് ഗതാഗതം ഒഴുകുന്നതിലേക്ക് നയിക്കുന്നില്ല എന്നതിനാൽ, പാക്കറ്റ് നഷ്ടങ്ങൾ. തകർന്ന അതേ സ്റ്റാക്കിലൂടെ പാക്കറ്റ് എത്തിക്കാൻ ഞങ്ങൾ ശ്രമിക്കുന്നു. ഇത് ഒരു കാസ്കേഡിംഗ് പരാജയത്തിലേക്ക് നയിക്കുന്നു: ഒരു ഡാറ്റാ സെൻ്റർ ഇൻ്ററാക്ടിംഗ് ആപ്ലിക്കേഷനുകളുടെ ഒരു കൂട്ടമാണ്, കൂടാതെ ഈ എല്ലാ ആപ്ലിക്കേഷനുകളുടെയും ചില TCP കണക്ഷനുകൾ ഡീഗ്രേഡ് ചെയ്യാൻ തുടങ്ങുന്നു - കാരണം സൂപ്പർസ്പൈൻ ഡാറ്റാ സെൻ്ററിനുള്ളിൽ നിലനിൽക്കുന്ന എല്ലാ ആപ്ലിക്കേഷനുകളെയും ബാധിക്കുന്നു. പഴഞ്ചൊല്ല് പറയുന്നതുപോലെ: നിങ്ങൾ ഒരു കുതിരയെ ഷൂ ചെയ്തില്ലെങ്കിൽ, കുതിര മുടന്തിപ്പോയി; കുതിര മുടന്തനായി - റിപ്പോർട്ട് കൈമാറിയില്ല; റിപ്പോർട്ട് കൈമാറിയില്ല - ഞങ്ങൾക്ക് യുദ്ധം നഷ്ടപ്പെട്ടു. പ്രശ്‌നം ഉടലെടുത്ത നിമിഷം മുതൽ സേവനങ്ങൾ അനുഭവിക്കാൻ തുടങ്ങുന്ന തരംതാഴ്‌ന്ന ഘട്ടം വരെയുള്ള നിമിഷങ്ങൾക്കുള്ളിൽ മാത്രമാണ് ഇവിടെ എണ്ണം. ഉപയോക്താക്കൾക്ക് എവിടെയെങ്കിലും എന്തെങ്കിലും നഷ്‌ടമായേക്കാം എന്നാണ് ഇതിനർത്ഥം.


പരസ്പരം പൂരകമാകുന്ന രണ്ട് ക്ലാസിക് പരിഹാരങ്ങളുണ്ട്. ആദ്യത്തേത് സ്‌ട്രോകൾ ഇട്ട് പ്രശ്‌നം പരിഹരിക്കാൻ ശ്രമിക്കുന്ന സേവനങ്ങളാണ്: “നമുക്ക് ടിസിപി സ്റ്റാക്കിൽ എന്തെങ്കിലും മാറ്റാം. നമുക്ക് ആപ്ലിക്കേഷൻ തലത്തിൽ ടൈംഔട്ടുകൾ നടത്താം അല്ലെങ്കിൽ ആന്തരിക ആരോഗ്യ പരിശോധനകൾക്കൊപ്പം ദീർഘകാല TCP സെഷനുകൾ നടത്താം. അത്തരം പരിഹാരങ്ങൾ എന്നതാണ് പ്രശ്നം: a) സ്കെയിൽ ചെയ്യരുത്; b) വളരെ മോശമായി പരിശോധിച്ചു. അതായത്, സേവനം ആകസ്മികമായി ടിസിപി സ്റ്റാക്ക് മികച്ചതാക്കുന്ന വിധത്തിൽ കോൺഫിഗർ ചെയ്താലും, ഒന്നാമതായി, എല്ലാ ആപ്ലിക്കേഷനുകൾക്കും എല്ലാ ഡാറ്റാ സെൻ്ററുകൾക്കും ഇത് ബാധകമാകാൻ സാധ്യതയില്ല, രണ്ടാമതായി, മിക്കവാറും, ഇത് ചെയ്തുവെന്ന് മനസ്സിലാക്കാൻ കഴിയില്ല. ശരിയായി, എന്താണ് അല്ലാത്തത്. അതായത്, ഇത് പ്രവർത്തിക്കുന്നു, പക്ഷേ ഇത് മോശമായി പ്രവർത്തിക്കുന്നു, സ്കെയിൽ ചെയ്യുന്നില്ല. നെറ്റ്‌വർക്ക് പ്രശ്‌നമുണ്ടെങ്കിൽ, ആരെയാണ് കുറ്റപ്പെടുത്തേണ്ടത്? തീർച്ചയായും, എൻ.ഒ.സി. NOC എന്താണ് ചെയ്യുന്നത്?

NOC ജോലിയിൽ ഇതുപോലെ എന്തെങ്കിലും സംഭവിക്കുമെന്ന് പല സേവനങ്ങളും വിശ്വസിക്കുന്നു. എന്നാൽ സത്യം പറഞ്ഞാൽ, അത് മാത്രമല്ല.


ക്ലാസിക്കൽ സ്കീമിലെ NOC നിരവധി നിരീക്ഷണ സംവിധാനങ്ങളുടെ വികസനത്തിൽ ഏർപ്പെട്ടിരിക്കുന്നു. ഇവ ബ്ലാക്ക് ബോക്‌സ്, വൈറ്റ് ബോക്‌സ് നിരീക്ഷണമാണ്. ബ്ലാക്ക് ബോക്സ് നട്ടെല്ല് നിരീക്ഷണത്തിൻ്റെ ഒരു ഉദാഹരണത്തെക്കുറിച്ച് പറഞ്ഞു അവസാന നെക്സ്റ്റ് ഹോപ്പിൽ അലക്സാണ്ടർ ക്ലിമെൻകോ. വഴിയിൽ, ഈ നിരീക്ഷണം പ്രവർത്തിക്കുന്നു. എന്നാൽ അനുയോജ്യമായ നിരീക്ഷണത്തിന് പോലും ഒരു കാലതാമസം ഉണ്ടാകും. സാധാരണയായി ഇത് കുറച്ച് മിനിറ്റാണ്. അത് ഓഫായ ശേഷം, ഡ്യൂട്ടിയിലുള്ള എഞ്ചിനീയർമാർക്ക് അതിൻ്റെ പ്രവർത്തനം രണ്ടുതവണ പരിശോധിക്കാനും പ്രശ്നം പ്രാദേശികവൽക്കരിക്കാനും പ്രശ്നമുള്ള പ്രദേശം കെടുത്താനും സമയം ആവശ്യമാണ്. അതായത്, ഏറ്റവും നല്ല സാഹചര്യത്തിൽ, പ്രശ്നം ചികിത്സിക്കാൻ 5 മിനിറ്റ് എടുക്കും, ഏറ്റവും മോശമായ സാഹചര്യത്തിൽ, 20 മിനിറ്റ്, എവിടെയാണ് നഷ്ടം സംഭവിക്കുന്നതെന്ന് പെട്ടെന്ന് വ്യക്തമല്ലെങ്കിൽ. ഈ സമയമത്രയും - 5 അല്ലെങ്കിൽ 20 മിനിറ്റ് - ഞങ്ങളുടെ സേവനങ്ങൾ തുടർന്നും കഷ്ടപ്പെടുമെന്ന് വ്യക്തമാണ്, അത് ഒരുപക്ഷേ നല്ലതല്ല.


നിങ്ങൾ ശരിക്കും എന്താണ് സ്വീകരിക്കാൻ ആഗ്രഹിക്കുന്നത്? നമുക്ക് ഒരുപാട് വഴികളുണ്ട്. നിർഭാഗ്യകരമായ TCP ഫ്ലോകൾ ഇതേ റൂട്ട് ഉപയോഗിക്കുന്നത് തുടരുന്നതിനാലാണ് പ്രശ്നങ്ങൾ ഉണ്ടാകുന്നത്. ഒരു ടിസിപി കണക്ഷനിൽ ഒന്നിലധികം റൂട്ടുകൾ ഉപയോഗിക്കാൻ ഞങ്ങളെ അനുവദിക്കുന്ന എന്തെങ്കിലും ഞങ്ങൾക്ക് ആവശ്യമാണ്. നമുക്ക് ഒരു പരിഹാരമുണ്ടെന്ന് തോന്നുന്നു. മൾട്ടിപാത്ത് TCP എന്ന് വിളിക്കപ്പെടുന്ന TCP ഉണ്ട്, അതായത് ഒന്നിലധികം പാതകൾക്കുള്ള TCP. ശരിയാണ്, ഇത് തികച്ചും വ്യത്യസ്തമായ ഒരു ടാസ്ക്കിനായി വികസിപ്പിച്ചെടുത്തതാണ് - നിരവധി നെറ്റ്വർക്ക് ഉപകരണങ്ങളുള്ള സ്മാർട്ട്ഫോണുകൾക്കായി. കൈമാറ്റം വർദ്ധിപ്പിക്കുന്നതിനോ പ്രൈമറി/ബാക്കപ്പ് മോഡ് ഉണ്ടാക്കുന്നതിനോ, ആപ്ലിക്കേഷനിലേക്ക് സുതാര്യമായി ഒന്നിലധികം ത്രെഡുകൾ (സെഷനുകൾ) സൃഷ്ടിക്കുന്ന ഒരു സംവിധാനം വികസിപ്പിച്ചെടുത്തു, ഒരു പരാജയമുണ്ടായാൽ അവയ്ക്കിടയിൽ മാറാൻ നിങ്ങളെ അനുവദിക്കുന്നു. അല്ലെങ്കിൽ, ഞാൻ പറഞ്ഞതുപോലെ, സ്ട്രീക്ക് പരമാവധിയാക്കുക.

എന്നാൽ ഇവിടെ ഒരു ന്യൂനൻസ് ഉണ്ട്. അത് എന്താണെന്ന് മനസിലാക്കാൻ, ത്രെഡുകൾ എങ്ങനെ സ്ഥാപിക്കപ്പെടുന്നുവെന്ന് നോക്കേണ്ടതുണ്ട്.


ത്രെഡുകൾ തുടർച്ചയായി ഇൻസ്റ്റാൾ ചെയ്തിട്ടുണ്ട്. ആദ്യത്തെ ത്രെഡ് ആദ്യം ഇൻസ്റ്റാൾ ചെയ്തു. ആ ത്രെഡിനുള്ളിൽ ഇതിനകം സമ്മതിച്ചിട്ടുള്ള കുക്കി ഉപയോഗിച്ച് തുടർന്നുള്ള ത്രെഡുകൾ സജ്ജീകരിക്കുന്നു. പിന്നെ ഇവിടെയാണ് പ്രശ്നം.


ആദ്യത്തെ ത്രെഡ് സ്വയം സ്ഥാപിച്ചില്ലെങ്കിൽ, രണ്ടാമത്തെയും മൂന്നാമത്തെയും ത്രെഡുകൾ ഒരിക്കലും ഉണ്ടാകില്ല എന്നതാണ് പ്രശ്നം. അതായത്, മൾട്ടിപാത്ത് ടിസിപി ആദ്യ ഫ്ലോയിൽ ഒരു SYN പാക്കറ്റിൻ്റെ നഷ്ടം പരിഹരിക്കുന്നില്ല. SYN നഷ്ടപ്പെട്ടാൽ, മൾട്ടിപാത്ത് TCP സാധാരണ TCP ആയി മാറുന്നു. ഒരു ഡാറ്റാ സെൻ്റർ പരിതസ്ഥിതിയിൽ, ഫാക്ടറിയിലെ നഷ്ടങ്ങളുടെ പ്രശ്നം പരിഹരിക്കാനും പരാജയപ്പെടുമ്പോൾ ഒന്നിലധികം പാതകൾ ഉപയോഗിക്കാൻ പഠിക്കാനും ഇത് ഞങ്ങളെ സഹായിക്കില്ല എന്നാണ് ഇതിനർത്ഥം.


നമ്മെ എന്തു സഹായിക്കും? ഞങ്ങളുടെ തുടർന്നുള്ള സ്റ്റോറിയിലെ ഒരു പ്രധാന ഫീൽഡ് IPv6 ഫ്ലോ ലേബൽ ഹെഡർ ഫീൽഡ് ആയിരിക്കുമെന്ന് നിങ്ങളിൽ ചിലർ ഇതിനകം തന്നെ തലക്കെട്ടിൽ നിന്ന് ഊഹിച്ചിരിക്കുന്നു. തീർച്ചയായും, ഇത് v6-ൽ ദൃശ്യമാകുന്ന ഒരു ഫീൽഡാണ്, ഇത് v4-ൽ അല്ല, ഇത് 20 ബിറ്റുകൾ ഉൾക്കൊള്ളുന്നു, മാത്രമല്ല ഇത് ഉപയോഗിക്കുന്നതിൽ വളരെക്കാലമായി തർക്കമുണ്ട്. ഇത് വളരെ രസകരമാണ് - തർക്കങ്ങൾ ഉണ്ടായിരുന്നു, ആർഎഫ്‌സിയിൽ എന്തെങ്കിലും പരിഹരിച്ചു, അതേ സമയം ലിനക്സ് കേർണലിൽ ഒരു നടപ്പാക്കൽ പ്രത്യക്ഷപ്പെട്ടു, അത് എവിടെയും രേഖപ്പെടുത്തിയിട്ടില്ല.


ഒരു ചെറിയ അന്വേഷണത്തിന് എന്നോടൊപ്പം പോകാൻ ഞാൻ നിങ്ങളെ ക്ഷണിക്കുന്നു. കഴിഞ്ഞ കുറച്ച് വർഷങ്ങളായി ലിനക്സ് കേർണലിൽ എന്താണ് സംഭവിക്കുന്നതെന്ന് നമുക്ക് നോക്കാം.

വർഷം 2014. ഒരു വലുതും ആദരണീയവുമായ കമ്പനിയിൽ നിന്നുള്ള ഒരു എഞ്ചിനീയർ, സോക്കറ്റ് ഹാഷിലെ ഫ്ലോ ലേബൽ മൂല്യത്തിൻ്റെ ആശ്രിതത്വം ലിനക്സ് കേർണലിൻ്റെ പ്രവർത്തനക്ഷമതയിൽ ചേർക്കുന്നു. അവർ ഇവിടെ എന്താണ് പരിഹരിക്കാൻ ശ്രമിച്ചത്? ഇത് RFC 6438 മായി ബന്ധപ്പെട്ടതാണ്, അത് ഇനിപ്പറയുന്ന പ്രശ്നം ചർച്ച ചെയ്തു. ഡാറ്റാ സെൻ്ററിനുള്ളിൽ, IPv4 പലപ്പോഴും IPv6 പാക്കറ്റുകളിൽ ഉൾപ്പെടുത്തിയിട്ടുണ്ട്, കാരണം ഫാക്ടറി തന്നെ IPv6 ആണ്, എന്നാൽ IPv4 എങ്ങനെയെങ്കിലും പുറത്ത് നൽകണം. TCP അല്ലെങ്കിൽ UDP എന്നിവയിലേക്ക് പോകുന്നതിനും അവിടെ src_ports, dst_ports എന്നിവ കണ്ടെത്തുന്നതിനും രണ്ട് IP തലക്കെട്ടുകൾക്ക് കീഴിൽ നോക്കാൻ കഴിയാത്ത സ്വിച്ചുകളിൽ വളരെക്കാലമായി പ്രശ്നങ്ങൾ ഉണ്ടായിരുന്നു. ആദ്യത്തെ രണ്ട് ഐപി തലക്കെട്ടുകൾ നോക്കിയാൽ ഹാഷ് ഏതാണ്ട് പരിഹരിച്ചതായി തെളിഞ്ഞു. ഇത് ഒഴിവാക്കാൻ, ഈ എൻക്യാപ്‌സുലേറ്റഡ് ട്രാഫിക്കിൻ്റെ ബാലൻസ് ശരിയായി പ്രവർത്തിക്കുന്നതിന്, ഫ്ലോ ലേബൽ ഫീൽഡിൻ്റെ മൂല്യത്തിലേക്ക് 5-ട്യൂപ്പിൾ എൻക്യാപ്‌സുലേറ്റഡ് പാക്കറ്റിൻ്റെ ഹാഷ് ചേർക്കാൻ നിർദ്ദേശിക്കപ്പെട്ടു. മറ്റ് എൻക്യാപ്‌സുലേഷൻ സ്കീമുകൾക്കും, യുഡിപിയ്‌ക്കും, ജിആർഇയ്‌ക്കും, രണ്ടാമത്തേത് ജിആർഇ കീ ഫീൽഡ് ഉപയോഗിച്ചു. ഒരു തരത്തിൽ അല്ലെങ്കിൽ മറ്റൊരു തരത്തിൽ, ഇവിടെ ലക്ഷ്യങ്ങൾ വ്യക്തമാണ്. ആ സമയത്തെങ്കിലും അവ ഉപയോഗപ്രദമായിരുന്നു.

2015-ൽ, അതേ ബഹുമാനപ്പെട്ട എഞ്ചിനീയറിൽ നിന്ന് ഒരു പുതിയ പാച്ച് വരുന്നു. അവൻ വളരെ രസകരമാണ്. ഇത് ഇനിപ്പറയുന്നവ പറയുന്നു - ഒരു നെഗറ്റീവ് റൂട്ടിംഗ് ഇവൻ്റിൻ്റെ കാര്യത്തിൽ ഞങ്ങൾ ഹാഷ് ക്രമരഹിതമാക്കും. എന്താണ് ഒരു നെഗറ്റീവ് റൂട്ടിംഗ് ഇവൻ്റ്? ഇതാണ് നമ്മൾ നേരത്തെ ചർച്ച ചെയ്ത RTO, അതായത്, വിൻഡോയുടെ വാൽ നഷ്ടപ്പെടുന്നത് ശരിക്കും നെഗറ്റീവ് ആയ ഒരു സംഭവമാണ്. ശരിയാണ്, ഇതാണ് എന്ന് ഊഹിക്കാൻ താരതമ്യേന ബുദ്ധിമുട്ടാണ്.

2016, മറ്റൊരു പ്രശസ്തമായ കമ്പനി, വലിയ. ഇത് അവസാനത്തെ ക്രച്ചുകൾ ഡിസ്അസംബ്ലിംഗ് ചെയ്യുകയും ഞങ്ങൾ മുമ്പ് ക്രമരഹിതമായി ഉണ്ടാക്കിയ ഹാഷ് ഇപ്പോൾ ഓരോ SYN റീട്രാൻസ്മിഷനും ഓരോ RTO ടൈംഔട്ടിനു ശേഷവും മാറുകയും ചെയ്യുന്നു. ഈ കത്തിൽ, ആദ്യമായും അവസാനമായും, ആത്യന്തികമായ ലക്ഷ്യം പ്രസ്താവിച്ചിരിക്കുന്നു - നഷ്ടങ്ങളോ ചാനൽ തിരക്കോ ഉണ്ടാകുമ്പോൾ ട്രാഫിക്കിന് മൃദുലമായി റൂട്ട് ചെയ്യാനും ഒന്നിലധികം പാതകൾ ഉപയോഗിക്കാനുമുള്ള കഴിവുണ്ടെന്ന് ഉറപ്പാക്കുക. തീർച്ചയായും, ഇതിന് ശേഷം ധാരാളം പ്രസിദ്ധീകരണങ്ങൾ ഉണ്ടായിരുന്നു, നിങ്ങൾക്ക് അവ എളുപ്പത്തിൽ കണ്ടെത്താനാകും.

ഇല്ലെങ്കിലും, നിങ്ങൾക്ക് കഴിയില്ല, കാരണം ഈ വിഷയത്തിൽ ഒരു പ്രസിദ്ധീകരണം പോലും ഉണ്ടായിട്ടില്ല. പക്ഷേ നമുക്കറിയാം!

എന്താണ് ചെയ്തതെന്ന് നിങ്ങൾക്ക് പൂർണ്ണമായി മനസ്സിലായില്ലെങ്കിൽ, ഞാൻ ഇപ്പോൾ നിങ്ങളോട് പറയും.


എന്താണ് ചെയ്തത്, ലിനക്സ് കേർണലിലേക്ക് എന്ത് പ്രവർത്തനമാണ് ചേർത്തത്? ഓരോ RTO ഇവൻ്റിനുശേഷവും txhash ഒരു റാൻഡം മൂല്യത്തിലേക്ക് മാറുന്നു. ഇത് റൂട്ടിംഗിൻ്റെ വളരെ നെഗറ്റീവ് ഫലമാണ്. ഹാഷ് ഈ txhash-നെ ആശ്രയിച്ചിരിക്കുന്നു, ഫ്ലോ ലേബൽ skb ഹാഷിനെ ആശ്രയിച്ചിരിക്കുന്നു. ഇവിടെ ഫംഗ്‌ഷനുകളിൽ ചില കണക്കുകൂട്ടലുകൾ ഉണ്ട്; എല്ലാ വിശദാംശങ്ങളും ഒരു സ്ലൈഡിൽ സ്ഥാപിക്കാൻ കഴിയില്ല. ആർക്കെങ്കിലും ജിജ്ഞാസയുണ്ടെങ്കിൽ, നിങ്ങൾക്ക് കേർണൽ കോഡിലൂടെ പോയി പരിശോധിക്കാം.

ഇവിടെ എന്താണ് പ്രധാനം? ഓരോ ആർടിഒയ്ക്കും ശേഷം ഫ്ലോ ലേബൽ ഫീൽഡിൻ്റെ മൂല്യം ക്രമരഹിതമായ നമ്പറിലേക്ക് മാറുന്നു. ഇത് ഞങ്ങളുടെ നിർഭാഗ്യകരമായ TCP സ്ട്രീമിനെ എങ്ങനെ ബാധിക്കുന്നു?


ഒരു SACK സംഭവിക്കുകയാണെങ്കിൽ, അറിയപ്പെട്ട നഷ്‌ടപ്പെട്ട ഒരു പാക്കറ്റ് ഞങ്ങൾ വീണ്ടും അയയ്‌ക്കാൻ ശ്രമിക്കുന്നതിനാൽ ഒന്നും മാറില്ല. ഇതുവരെ വളരെ നല്ലതായിരുന്നു.


എന്നാൽ RTO-യുടെ കാര്യത്തിൽ, ToR-ലെ ഹാഷ് ഫംഗ്‌ഷനിലേക്ക് ഞങ്ങൾ ഒരു ഫ്ലോ ലേബൽ ചേർത്തിട്ടുണ്ടെങ്കിൽ, ട്രാഫിക് മറ്റൊരു റൂട്ട് എടുത്തേക്കാം. കൂടുതൽ പാതകൾ, ഒരു നിർദ്ദിഷ്‌ട ഉപകരണത്തിലെ പരാജയം ബാധിക്കാത്ത ഒരു പാത കണ്ടെത്താനുള്ള സാധ്യത കൂടുതലാണ്.


ഒരു പ്രശ്നം അവശേഷിക്കുന്നു - RTO. തീർച്ചയായും, മറ്റൊരു റൂട്ട് ഉണ്ട്, എന്നാൽ ഇതിൽ ധാരാളം സമയം പാഴാക്കുന്നു. 200 മി.എസ്. ഒരു സെക്കൻ്റ് തികച്ചും വന്യമാണ്. മുമ്പ്, സേവനങ്ങൾ ക്രമീകരിച്ചിരിക്കുന്ന സമയപരിധികളെക്കുറിച്ച് ഞാൻ സംസാരിച്ചു. അതിനാൽ, സെക്കൻഡ് എന്നത് ഒരു കാലഹരണപ്പെടലാണ്, ഇത് സാധാരണയായി ആപ്ലിക്കേഷൻ തലത്തിലുള്ള സേവനം കോൺഫിഗർ ചെയ്യുന്നു, ഇതിൽ സേവനം താരതമ്യേന ശരിയായിരിക്കും. മാത്രമല്ല, ഞാൻ ആവർത്തിക്കുന്നു, ഒരു ആധുനിക ഡാറ്റാ സെൻ്ററിനുള്ളിലെ യഥാർത്ഥ RTT ഏകദേശം 1 മില്ലിസെക്കൻഡ് ആണ്.


RTO കാലഹരണപ്പെട്ടാൽ നിങ്ങൾക്ക് എന്തുചെയ്യാൻ കഴിയും? ഡാറ്റാ പാക്കറ്റുകൾ നഷ്‌ടപ്പെടുമ്പോൾ RTO-യ്‌ക്ക് ഉത്തരവാദിത്തമുള്ള സമയപരിധി, ഉപയോക്തൃ സ്‌പെയ്‌സിൽ നിന്ന് താരതമ്യേന എളുപ്പത്തിൽ കോൺഫിഗർ ചെയ്യാൻ കഴിയും: ഒരു IP യൂട്ടിലിറ്റി ഉണ്ട്, അതിൻ്റെ പാരാമീറ്ററുകളിലൊന്നിൽ അതേ rto_min അടങ്ങിയിരിക്കുന്നു. RTO, തീർച്ചയായും ആഗോളതലത്തിലല്ല, മറിച്ച് നൽകിയിരിക്കുന്ന പ്രിഫിക്സുകൾക്കായി, അത്തരമൊരു സംവിധാനം തികച്ചും പ്രവർത്തനക്ഷമമാണെന്ന് തോന്നുന്നു.


ശരിയാണ്, SYN_RTO ഉപയോഗിച്ച് എല്ലാം കുറച്ച് മോശമാണ്. ഇത് സ്വാഭാവികമായി തറച്ചതാണ്. കേർണലിന് 1 സെക്കൻഡിൻ്റെ ഒരു നിശ്ചിത മൂല്യമുണ്ട്, അത്രമാത്രം. നിങ്ങൾക്ക് ഉപയോക്തൃ സ്ഥലത്ത് നിന്ന് അവിടെ എത്താൻ കഴിയില്ല. ഒരു വഴിയേ ഉള്ളൂ.


eBPF സഹായത്തിനെത്തുന്നു. ലളിതമായി പറഞ്ഞാൽ, ഇവ ചെറിയ സി പ്രോഗ്രാമുകളാണ്, കേർണൽ സ്റ്റാക്കിൻ്റെയും ടിസിപി സ്റ്റാക്കിൻ്റെയും എക്സിക്യൂഷനിൽ വ്യത്യസ്ത സ്ഥലങ്ങളിൽ അവ ഹുക്കുകളിലേക്ക് തിരുകാൻ കഴിയും, അതുപയോഗിച്ച് നിങ്ങൾക്ക് വളരെ വലിയ ക്രമീകരണങ്ങൾ മാറ്റാനാകും. പൊതുവേ, eBPF ഒരു ദീർഘകാല പ്രവണതയാണ്. ഡസൻ കണക്കിന് പുതിയ sysctl പാരാമീറ്ററുകൾ വെട്ടിക്കുറച്ച് ഐപി യൂട്ടിലിറ്റി വികസിപ്പിക്കുന്നതിനുപകരം, പ്രസ്ഥാനം eBPF-ലേക്ക് നീങ്ങുകയും അതിൻ്റെ പ്രവർത്തനം വിപുലീകരിക്കുകയും ചെയ്യുന്നു. eBPF ഉപയോഗിച്ച്, നിങ്ങൾക്ക് തിരക്ക് നിയന്ത്രണങ്ങളും മറ്റ് വിവിധ TCP ക്രമീകരണങ്ങളും ചലനാത്മകമായി മാറ്റാൻ കഴിയും.


എന്നാൽ SYN_RTO മൂല്യങ്ങൾ മാറ്റാൻ ഇത് ഉപയോഗിക്കാനാകുമെന്നത് ഞങ്ങൾക്ക് പ്രധാനമാണ്. കൂടാതെ, പൊതുവായി പോസ്റ്റ് ചെയ്ത ഒരു ഉദാഹരണമുണ്ട്: https://elixir.bootlin.com/linux/latest/source/samples/bpf/tcp_synrto_kern.c. ഇവിടെ എന്താണ് ചെയ്തത്? ഉദാഹരണം പ്രവർത്തിക്കുന്നു, പക്ഷേ അതിൽത്തന്നെ വളരെ പരുക്കനാണ്. ഇവിടെ ഡാറ്റാ സെൻ്ററിനുള്ളിൽ ഞങ്ങൾ ആദ്യത്തെ 44 ബിറ്റുകൾ താരതമ്യം ചെയ്യുന്നു എന്ന് അനുമാനിക്കപ്പെടുന്നു; അവ പൊരുത്തപ്പെടുന്നുവെങ്കിൽ, ഞങ്ങൾ ഡാറ്റാ സെൻ്ററിനുള്ളിലാണ്. ഈ സാഹചര്യത്തിൽ ഞങ്ങൾ SYN_RTO കാലഹരണപ്പെടൽ മൂല്യം 4ms ആയി മാറ്റുന്നു. അതേ ജോലി വളരെ ഭംഗിയായി ചെയ്യാൻ കഴിയും. എന്നാൽ ഈ ലളിതമായ ഉദാഹരണം ഇത് ഒരു) സാധ്യമാണെന്ന് കാണിക്കുന്നു; b) താരതമ്യേന ലളിതമാണ്.

നമുക്ക് ഇതിനകം എന്താണ് അറിയാവുന്നത്? പ്ലെയിൻ ആർക്കിടെക്ചർ സ്കെയിലിംഗിന് അനുവദിക്കുന്നു എന്ന വസ്തുത, ToR-ൽ ഫ്ലോ ലേബൽ പ്രവർത്തനക്ഷമമാക്കുകയും പ്രശ്നമുള്ള പ്രദേശങ്ങളിൽ ഒഴുകാനുള്ള കഴിവ് നേടുകയും ചെയ്യുമ്പോൾ അത് ഞങ്ങൾക്ക് വളരെ ഉപയോഗപ്രദമാകും. RTO, SYN-RTO മൂല്യങ്ങൾ കുറയ്ക്കുന്നതിനുള്ള ഏറ്റവും നല്ല മാർഗം eBPF പ്രോഗ്രാമുകൾ ഉപയോഗിക്കുക എന്നതാണ്. ചോദ്യം അവശേഷിക്കുന്നു: ബാലൻസിംഗിനായി ഒരു ഫ്ലോ ലേബൽ ഉപയോഗിക്കുന്നത് സുരക്ഷിതമാണോ? കൂടാതെ ഇവിടെ ഒരു ന്യൂനൻസ് ഉണ്ട്.


നിങ്ങളുടെ നെറ്റ്‌വർക്കിൽ ഏതെങ്കിലും തരത്തിൽ ജീവിക്കുന്ന ഒരു സേവനം ഉണ്ടെന്ന് കരുതുക. നിർഭാഗ്യവശാൽ, Anycast എന്താണെന്നതിനെക്കുറിച്ച് വിശദമായി പറയാൻ എനിക്ക് സമയമില്ല, എന്നാൽ ഒരേ IP വിലാസം വഴി ആക്‌സസ് ചെയ്യാവുന്ന വ്യത്യസ്ത ഫിസിക്കൽ സെർവറുകളുള്ള ഒരു വിതരണം ചെയ്ത സേവനമാണിത്. സാധ്യമായ ഒരു പ്രശ്‌നമുണ്ട്: ഫാബ്രിക്കിലൂടെ ട്രാഫിക് കടന്നുപോകുമ്പോൾ മാത്രമല്ല RTO ഇവൻ്റ് സംഭവിക്കുന്നത്. ഇത് ToR ബഫർ തലത്തിലും സംഭവിക്കാം: ഒരു ഇൻകാസ്റ്റ് ഇവൻ്റ് സംഭവിക്കുമ്പോൾ, ഹോസ്റ്റ് എന്തെങ്കിലും പകരുമ്പോൾ അത് ഹോസ്റ്റിൽ പോലും സംഭവിക്കാം. ഒരു RTO ഇവൻ്റ് സംഭവിക്കുകയും അത് ഫ്ലോ ലേബൽ മാറ്റുകയും ചെയ്യുമ്പോൾ. ഈ സാഹചര്യത്തിൽ, ട്രാഫിക്കിന് മറ്റൊരു ഏതെങ്കിലും സന്ദർഭത്തിലേക്ക് പോകാം. ഇതൊരു സ്‌റ്റേറ്റ്‌ഫുൾ എനികാസ്റ്റ് ആണെന്ന് നമുക്ക് അനുമാനിക്കാം, അതിൽ ഒരു കണക്ഷൻ നില അടങ്ങിയിരിക്കുന്നു - ഇത് ഒരു L3 ബാലൻസറോ മറ്റേതെങ്കിലും സേവനമോ ആകാം. അപ്പോൾ ഒരു പ്രശ്നം ഉയർന്നുവരുന്നു, കാരണം ആർടിഒയ്ക്ക് ശേഷം ടിസിപി കണക്ഷൻ സെർവറിൽ എത്തുന്നു, ഈ ടിസിപി കണക്ഷനെക്കുറിച്ച് ഒന്നും അറിയില്ല. കൂടാതെ, ഏതെങ്കിലും കാസ്റ്റ് സെർവറുകൾക്കിടയിൽ ഞങ്ങൾക്ക് സ്റ്റേറ്റ് പങ്കിടൽ ഇല്ലെങ്കിൽ, അത്തരം ട്രാഫിക് കുറയുകയും TCP കണക്ഷൻ തകരുകയും ചെയ്യും.


നിങ്ങൾക്ക് ഇവിടെ എന്ത് ചെയ്യാൻ കഴിയും? ഫ്ലോ ലേബൽ ബാലൻസിങ് പ്രവർത്തനക്ഷമമാക്കുന്ന നിങ്ങളുടെ നിയന്ത്രിത പരിതസ്ഥിതിയിൽ, ഏതെങ്കിലും കാസ്റ്റ് സെർവറുകൾ ആക്‌സസ് ചെയ്യുമ്പോൾ ഫ്ലോ ലേബലിൻ്റെ മൂല്യം നിങ്ങൾ രേഖപ്പെടുത്തേണ്ടതുണ്ട്. ഒരേ ഇബിപിഎഫ് പ്രോഗ്രാമിലൂടെ ഇത് ചെയ്യുക എന്നതാണ് ഏറ്റവും എളുപ്പമുള്ള മാർഗം. എന്നാൽ ഇവിടെ വളരെ പ്രധാനപ്പെട്ട ഒരു കാര്യം ഉണ്ട് - നിങ്ങൾ ഒരു ഡാറ്റാ സെൻ്റർ നെറ്റ്‌വർക്ക് പ്രവർത്തിപ്പിക്കുന്നില്ലെങ്കിലും ഒരു ടെലികോം ഓപ്പറേറ്ററാണെങ്കിൽ എന്തുചെയ്യും? ഇത് നിങ്ങളുടെയും പ്രശ്‌നമാണ്: ജുനൈപ്പറിൻ്റെയും അരിസ്റ്റയുടെയും ചില പതിപ്പുകൾ മുതൽ, അവർ അവരുടെ ഹാഷ് ഫംഗ്‌ഷനുകളിൽ ഡിഫോൾട്ടായി ഒരു ഫ്ലോ ലേബൽ ഉൾപ്പെടുത്തിയിട്ടുണ്ട് - സത്യം പറഞ്ഞാൽ, എനിക്ക് അവ്യക്തമായ ഒരു കാരണം. ഇത് നിങ്ങളുടെ നെറ്റ്‌വർക്കിലൂടെ കടന്നുപോകുന്ന ഉപയോക്താക്കളിൽ നിന്ന് TCP കണക്ഷനുകൾ ഉപേക്ഷിക്കുന്നതിന് കാരണമായേക്കാം. അതിനാൽ നിങ്ങളുടെ റൂട്ടറുകൾ ക്രമീകരണങ്ങൾ ഇവിടെ പരിശോധിക്കാൻ ഞാൻ വളരെ ശുപാർശ ചെയ്യുന്നു.

ഒരു തരത്തിൽ അല്ലെങ്കിൽ മറ്റൊരു തരത്തിൽ, ഞങ്ങൾ പരീക്ഷണങ്ങളിലേക്ക് നീങ്ങാൻ തയ്യാറാണെന്ന് എനിക്ക് തോന്നുന്നു.


ToR-ൽ ഫ്ലോ ലേബൽ പ്രവർത്തനക്ഷമമാക്കിയപ്പോൾ, ഇപ്പോൾ ഹോസ്റ്റുകളിൽ താമസിക്കുന്ന eBPF ഏജൻ്റ് തയ്യാറാക്കി, അടുത്ത വലിയ പരാജയത്തിനായി കാത്തിരിക്കേണ്ടതില്ല, നിയന്ത്രിത സ്ഫോടനങ്ങൾ നടത്താൻ ഞങ്ങൾ തീരുമാനിച്ചു. ഞങ്ങൾ നാല് അപ്‌ലിങ്കുകളുള്ള ToR എടുത്ത് അവയിലൊന്നിൽ ഡ്രോപ്പുകൾ സജ്ജീകരിച്ചു. അവർ ഒരു നിയമം വരച്ച് പറഞ്ഞു - ഇപ്പോൾ നിങ്ങൾക്ക് എല്ലാ പാക്കറ്റുകളും നഷ്ടപ്പെടുന്നു. നിങ്ങൾക്ക് ഇടതുവശത്ത് കാണാനാകുന്നതുപോലെ, ഞങ്ങൾക്ക് ഓരോ പാക്കറ്റ് നിരീക്ഷണമുണ്ട്, അത് 75% ആയി കുറഞ്ഞു, അതായത്, 25% പാക്കറ്റുകൾ നഷ്ടപ്പെട്ടു. വലതുവശത്ത് ഈ ToR-ന് പിന്നിൽ ജീവിക്കുന്ന സേവനങ്ങളുടെ ഗ്രാഫുകളാണ്. അടിസ്ഥാനപരമായി, ഇവ റാക്കിനുള്ളിലെ സെർവറുകളുള്ള ഇൻ്റർഫേസുകളുടെ ട്രാഫിക് ഗ്രാഫുകളാണ്. നിങ്ങൾക്ക് കാണാനാകുന്നതുപോലെ, അവർ കൂടുതൽ താഴ്ന്നു. എന്തുകൊണ്ടാണ് അവ താഴ്ന്നത് - 25% അല്ല, ചില സന്ദർഭങ്ങളിൽ 3-4 മടങ്ങ്? TCP കണക്ഷൻ നിർഭാഗ്യകരമാണെങ്കിൽ, അത് തകർന്ന ജംഗ്ഷനിലൂടെ എത്താൻ ശ്രമിക്കുന്നു. ഡിസിക്കുള്ളിലെ സേവനത്തിൻ്റെ സാധാരണ സ്വഭാവം ഇത് വഷളാക്കുന്നു - ഒരു ഉപയോക്തൃ അഭ്യർത്ഥനയ്ക്കായി, ആന്തരിക സേവനങ്ങളിലേക്കുള്ള N അഭ്യർത്ഥനകൾ സൃഷ്ടിക്കപ്പെടുന്നു, കൂടാതെ എല്ലാ ഡാറ്റ ഉറവിടങ്ങളും പ്രതികരിക്കുമ്പോഴോ അല്ലെങ്കിൽ ആപ്ലിക്കേഷനിൽ കാലഹരണപ്പെടുമ്പോഴോ പ്രതികരണം ഉപയോക്താവിലേക്ക് പോകും. ലെവൽ, അത് ഇപ്പോഴും കോൺഫിഗർ ചെയ്യേണ്ടതുണ്ട്. അതായത്, എല്ലാം വളരെ വളരെ മോശമാണ്.


ഇപ്പോൾ അതേ പരീക്ഷണം, എന്നാൽ ഫ്ലോ ലേബൽ മൂല്യം പ്രവർത്തനക്ഷമമാക്കി. നിങ്ങൾക്ക് കാണാനാകുന്നതുപോലെ, ഇടതുവശത്ത് ഞങ്ങളുടെ ബാച്ച് നിരീക്ഷണം അതേ 25% കുറഞ്ഞു. ഇത് തികച്ചും ശരിയാണ്, കാരണം ഇതിന് റീട്രാൻസ്മിറ്റുകളെക്കുറിച്ച് ഒന്നും അറിയില്ല, ഇത് പാക്കറ്റുകൾ അയയ്ക്കുകയും ഡെലിവർ ചെയ്തതും നഷ്ടപ്പെട്ടതുമായ പാക്കറ്റുകളുടെ എണ്ണത്തിൻ്റെ അനുപാതം കണക്കാക്കുകയും ചെയ്യുന്നു.

വലതുവശത്ത് സർവീസ് ഷെഡ്യൂൾ ഉണ്ട്. ഒരു പ്രശ്നമുള്ള സംയുക്തത്തിൻ്റെ ഫലം നിങ്ങൾ ഇവിടെ കണ്ടെത്തുകയില്ല. അതേ മില്ലിസെക്കൻഡിൽ, പ്രശ്‌നബാധിത പ്രദേശത്ത് നിന്ന് പ്രശ്‌നം ബാധിക്കാത്ത മൂന്ന് അപ്‌ലിങ്കുകളിലേക്ക് ട്രാഫിക് ഒഴുകി. സ്വയം സുഖപ്പെടുത്തുന്ന ഒരു നെറ്റ്‌വർക്ക് ഞങ്ങൾക്ക് ലഭിച്ചു.

ഇതാണ് എൻ്റെ അവസാന സ്ലൈഡ്, സംഗ്രഹിക്കാനുള്ള സമയം. ഇപ്പോൾ, ഒരു സെൽഫ്-ഹീലിംഗ് ഡാറ്റാ സെൻ്റർ നെറ്റ്‌വർക്ക് എങ്ങനെ നിർമ്മിക്കാമെന്ന് നിങ്ങൾക്കറിയാമെന്ന് ഞാൻ പ്രതീക്ഷിക്കുന്നു. നിങ്ങൾ ലിനക്സ് കേർണൽ ആർക്കൈവിലൂടെ പോയി അവിടെ പ്രത്യേക പാച്ചുകൾക്കായി നോക്കേണ്ടതില്ല; ഈ സാഹചര്യത്തിൽ ഫ്ലോ ലേബൽ പ്രശ്നം പരിഹരിക്കുമെന്ന് നിങ്ങൾക്കറിയാം, എന്നാൽ നിങ്ങൾ ഈ സംവിധാനത്തെ ശ്രദ്ധാപൂർവ്വം സമീപിക്കേണ്ടതുണ്ട്. നിങ്ങളൊരു ടെലികോം ഓപ്പറേറ്ററാണെങ്കിൽ, ഫ്ലോ ലേബൽ ഒരു ഹാഷ് ഫംഗ്‌ഷനായി ഉപയോഗിക്കരുത്, അല്ലാത്തപക്ഷം നിങ്ങളുടെ ഉപയോക്താക്കളുടെ സെഷനുകൾ തടസ്സപ്പെടുത്തുമെന്ന് ഞാൻ ഒരിക്കൽ കൂടി ഊന്നിപ്പറയുന്നു.

നെറ്റ്‌വർക്ക് എഞ്ചിനീയർമാർ ഒരു ആശയപരമായ ഷിഫ്റ്റിന് വിധേയരാകണം: നെറ്റ്‌വർക്ക് ആരംഭിക്കുന്നത് ToR ഉപയോഗിച്ചല്ല, നെറ്റ്‌വർക്ക് ഉപകരണത്തിലല്ല, ഹോസ്റ്റിൽ നിന്നാണ്. ആർടിഒ മാറ്റുന്നതിനും ഏതെങ്കിലും കാസ്റ്റ് സേവനങ്ങളിലേക്കുള്ള ഫ്ലോ ലേബൽ ശരിയാക്കുന്നതിനും ഞങ്ങൾ എങ്ങനെ ഇബിപിഎഫ് ഉപയോഗിക്കുന്നു എന്നതാണ് ശ്രദ്ധേയമായ ഒരു ഉദാഹരണം.

നിയന്ത്രിത അഡ്മിനിസ്ട്രേറ്റീവ് സെഗ്‌മെൻ്റിനുള്ളിലെ മറ്റ് ആപ്ലിക്കേഷനുകൾക്ക് ഫ്ലോ ലേബൽ മെക്കാനിക്സ് തീർച്ചയായും അനുയോജ്യമാണ്. ഇത് ഡാറ്റാ സെൻ്ററുകൾക്കിടയിലുള്ള ട്രാഫിക് ആകാം, അല്ലെങ്കിൽ ഔട്ട്‌ഗോയിംഗ് ട്രാഫിക് നിയന്ത്രിക്കുന്നതിന് നിങ്ങൾക്ക് അത്തരം മെക്കാനിക്കുകൾ ഒരു പ്രത്യേക രീതിയിൽ ഉപയോഗിക്കാം. എന്നാൽ ഇതിനെക്കുറിച്ച് ഞാൻ നിങ്ങളോട് പറയും, അടുത്ത തവണ ഞാൻ പ്രതീക്ഷിക്കുന്നു. നിങ്ങളുടെ ശ്രദ്ധയ്ക്ക് വളരെ നന്ദി.

അവലംബം: www.habr.com