ജോലി റൗണ്ടുകൾ കൊണ്ടുവരുന്ന കേടുപാടുകൾ സൂക്ഷിക്കുക. ഭാഗം 1: FragmentSmack/SegmentSmack

എല്ലാവർക്കും ഹായ്! എന്റെ പേര് ദിമിത്രി സാംസോനോവ്, ഞാൻ ഒഡ്‌നോക്ലാസ്നിക്കിയിലെ ഒരു പ്രമുഖ സിസ്റ്റം അഡ്മിനിസ്ട്രേറ്ററായി പ്രവർത്തിക്കുന്നു. ഞങ്ങൾക്ക് 7 ആയിരത്തിലധികം ഫിസിക്കൽ സെർവറുകളും ഞങ്ങളുടെ ക്ലൗഡിൽ 11 ആയിരം കണ്ടെയ്‌നറുകളും 200 ആപ്ലിക്കേഷനുകളും ഉണ്ട്, അവ വിവിധ കോൺഫിഗറേഷനുകളിൽ 700 വ്യത്യസ്ത ക്ലസ്റ്ററുകളായി മാറുന്നു. ഭൂരിഭാഗം സെർവറുകളും CentOS 7 പ്രവർത്തിപ്പിക്കുന്നു.
14 ഓഗസ്റ്റ് 2018-ന്, FragmentSmack അപകടസാധ്യതയെക്കുറിച്ചുള്ള വിവരങ്ങൾ പ്രസിദ്ധീകരിച്ചു
(CVE-2018-5391) കൂടാതെ SegmentSmack (CVE-2018-5390). നെറ്റ്‌വർക്ക് അറ്റാക്ക് വെക്‌ടറും സാമാന്യം ഉയർന്ന സ്‌കോറും (7.5) ഉള്ള കേടുപാടുകൾ ഇവയാണ്, ഇത് റിസോഴ്‌സ് എക്‌സാഷൻ (സിപിയു) കാരണം സേവന നിഷേധത്തെ (DoS) ഭീഷണിപ്പെടുത്തുന്നു. FragmentSmack-നുള്ള ഒരു കേർണൽ ഫിക്സ് അക്കാലത്ത് നിർദ്ദേശിച്ചിരുന്നില്ല; മാത്രമല്ല, അപകടസാധ്യതയെക്കുറിച്ചുള്ള വിവരങ്ങൾ പ്രസിദ്ധീകരിക്കുന്നതിന് വളരെ വൈകിയാണ് ഇത് പുറത്തുവന്നത്. SegmentSmack ഇല്ലാതാക്കാൻ, കേർണൽ അപ്ഡേറ്റ് ചെയ്യാൻ നിർദ്ദേശിച്ചു. അപ്‌ഡേറ്റ് പാക്കേജ് തന്നെ അതേ ദിവസം തന്നെ പുറത്തിറക്കി, അത് ഇൻസ്റ്റാൾ ചെയ്യുക മാത്രമാണ് അവശേഷിക്കുന്നത്.
ഇല്ല, കേർണൽ അപ്‌ഡേറ്റ് ചെയ്യുന്നതിന് ഞങ്ങൾ എതിരല്ല! എന്നിരുന്നാലും, സൂക്ഷ്മതകളുണ്ട് ...

ഉൽപ്പാദനത്തിൽ ഞങ്ങൾ കേർണൽ എങ്ങനെ അപ്ഡേറ്റ് ചെയ്യുന്നു

പൊതുവേ, സങ്കീർണ്ണമായ ഒന്നും തന്നെയില്ല:

1. പാക്കേജുകൾ ഡൗൺലോഡ് ചെയ്യുക;
2. അവ നിരവധി സെർവറുകളിൽ ഇൻസ്റ്റാൾ ചെയ്യുക (ഞങ്ങളുടെ ക്ലൗഡ് ഹോസ്റ്റുചെയ്യുന്ന സെർവറുകൾ ഉൾപ്പെടെ);
3. ഒന്നും തകർന്നിട്ടില്ലെന്ന് ഉറപ്പാക്കുക;
4. എല്ലാ സ്റ്റാൻഡേർഡ് കേർണൽ ക്രമീകരണങ്ങളും പിശകുകളില്ലാതെ പ്രയോഗിച്ചിട്ടുണ്ടെന്ന് ഉറപ്പാക്കുക;
5. കുറച്ച് ദിവസം കാത്തിരിക്കുക;
6. സെർവർ പ്രകടനം പരിശോധിക്കുക;
7. പുതിയ സെർവറുകളുടെ വിന്യാസം പുതിയ കേർണലിലേക്ക് മാറ്റുക;
8. ഡാറ്റാ സെന്റർ മുഖേന എല്ലാ സെർവറുകളും അപ്ഡേറ്റ് ചെയ്യുക (പ്രശ്നങ്ങൾ ഉണ്ടായാൽ ഉപയോക്താക്കളിൽ ഉണ്ടാകുന്ന പ്രഭാവം കുറയ്ക്കുന്നതിന് ഒരു സമയം ഒരു ഡാറ്റാ സെന്റർ);
9. എല്ലാ സെർവറുകളും റീബൂട്ട് ചെയ്യുക.

നമുക്കുള്ള കേർണലുകളുടെ എല്ലാ ശാഖകൾക്കും ആവർത്തിക്കുക. ഇപ്പോൾ ഇത്:

• Stock CentOS 7 3.10 - മിക്ക സാധാരണ സെർവറുകൾക്കും;
• വാനില 4.19 - നമ്മുടേത് ഒറ്റമേഘങ്ങൾ, കാരണം ഞങ്ങൾക്ക് BFQ, BBR മുതലായവ ആവശ്യമാണ്.
• Elrepo kernel-ml 5.2 - വേണ്ടി ഉയർന്ന ലോഡ് വിതരണക്കാർ, കാരണം 4.19 അസ്ഥിരമായി പെരുമാറിയിരുന്നു, എന്നാൽ അതേ സവിശേഷതകൾ ആവശ്യമാണ്.

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

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

FragmentSmack/SegmentSmack. പരിഹാര മാർഗം

ഭാഗ്യവശാൽ, ചില കേടുപാടുകൾക്ക് അത്തരമൊരു പ്ലാൻ ബി നിലവിലുണ്ട്, അതിനെ വർക്ക്‌എറൗണ്ട് എന്ന് വിളിക്കുന്നു. മിക്കപ്പോഴും, ഇത് കേർണൽ/അപ്ലിക്കേഷൻ ക്രമീകരണങ്ങളിലെ മാറ്റമാണ്, ഇത് സാധ്യമായ പ്രഭാവം കുറയ്ക്കുകയോ കേടുപാടുകൾ ചൂഷണം ചെയ്യുന്നത് പൂർണ്ണമായും ഇല്ലാതാക്കുകയോ ചെയ്യും.

FragmentSmack/SegmentSmack ന്റെ കാര്യത്തിൽ നിർദ്ദേശിക്കപ്പെട്ടു ഈ പ്രതിവിധി:

«നിങ്ങൾക്ക് net.ipv4.ipfrag_high_thresh, net.ipv3.ipfrag_low_thresh (ഒപ്പം ipv4 net.ipv4.ipfrag_high_thresh, net.ipv6.ipfrag_low_thresh, net.ipv6.ipfrag_low_thresh എന്നിവയ്‌ക്കുള്ള അവയുടെ എതിരാളികൾ) 6MB, 256MB എന്നിവയുടെ സ്ഥിരസ്ഥിതി മൂല്യങ്ങൾ യഥാക്രമം kB അല്ലെങ്കിൽ 192 kB ആക്കി മാറ്റാം. താഴത്തെ. ഹാർഡ്‌വെയർ, ക്രമീകരണങ്ങൾ, വ്യവസ്ഥകൾ എന്നിവയെ ആശ്രയിച്ച് ആക്രമണസമയത്ത് സിപിയു ഉപയോഗത്തിൽ ചെറിയ മുതൽ കാര്യമായ കുറവുകൾ ടെസ്റ്റുകൾ കാണിക്കുന്നു. എന്നിരുന്നാലും, ipfrag_high_thresh=262144 ബൈറ്റുകൾ കാരണം ചില പ്രകടന സ്വാധീനം ഉണ്ടായേക്കാം, കാരണം ഒരേസമയം രണ്ട് 64K ശകലങ്ങൾ മാത്രമേ റീഅസെംബ്ലി ക്യൂവിൽ ഉൾക്കൊള്ളാൻ കഴിയൂ. ഉദാഹരണത്തിന്, വലിയ UDP പാക്കറ്റുകളിൽ പ്രവർത്തിക്കുന്ന ആപ്ലിക്കേഷനുകൾ തകരാൻ സാധ്യതയുണ്ട്".

പരാമീറ്ററുകൾ തന്നെ കേർണൽ ഡോക്യുമെന്റേഷനിൽ താഴെ വിവരിച്ചിരിക്കുന്നു:

ipfrag_high_thresh - LONG INTEGER
    Maximum memory used to reassemble IP fragments.

ipfrag_low_thresh - LONG INTEGER
    Maximum memory used to reassemble IP fragments before the kernel
    begins to remove incomplete fragment queues to free up resources.
    The kernel still accepts new fragments for defragmentation.

ഉൽപ്പാദന സേവനങ്ങളിൽ ഞങ്ങൾക്ക് വലിയ UDP-കൾ ഇല്ല. LAN-ൽ വിഘടിത ട്രാഫിക് ഇല്ല; WAN-ൽ വിഘടിച്ച ട്രാഫിക് ഉണ്ട്, പക്ഷേ കാര്യമായതല്ല. അടയാളങ്ങളൊന്നുമില്ല - നിങ്ങൾക്ക് ഒരു പരിഹാരമാർഗ്ഗം തയ്യാറാക്കാം!

FragmentSmack/SegmentSmack. ആദ്യ രക്തം

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

എന്തുകൊണ്ട് ഹോസ്റ്റിൽ Sysctl പ്രയോഗിച്ചാൽ പോരാ? കണ്ടെയ്നർ സ്വന്തം സമർപ്പിത നെറ്റ്‌വർക്ക് നെയിംസ്‌പേസിൽ താമസിക്കുന്നു, അതിനാൽ കുറഞ്ഞത് നെറ്റ്‌വർക്കിന്റെ ഭാഗം Sysctl പാരാമീറ്ററുകൾ കണ്ടെയ്നറിൽ ഹോസ്റ്റിൽ നിന്ന് വ്യത്യസ്തമായിരിക്കാം.

കണ്ടെയ്‌നറിൽ Sysctl ക്രമീകരണങ്ങൾ കൃത്യമായി എങ്ങനെയാണ് പ്രയോഗിക്കുന്നത്? ഞങ്ങളുടെ കണ്ടെയ്‌നറുകൾ പ്രത്യേകാവകാശമില്ലാത്തതിനാൽ, കണ്ടെയ്‌നറിലേക്ക് പോയി നിങ്ങൾക്ക് ഒരു Sysctl ക്രമീകരണവും മാറ്റാൻ കഴിയില്ല - നിങ്ങൾക്ക് മതിയായ അവകാശങ്ങൾ ഇല്ല. കണ്ടെയ്‌നറുകൾ പ്രവർത്തിപ്പിക്കാൻ, അക്കാലത്ത് ഞങ്ങളുടെ ക്ലൗഡ് ഡോക്കർ ഉപയോഗിച്ചു (ഇപ്പോൾ പോഡ്മാൻ). ആവശ്യമായ Sysctl ക്രമീകരണങ്ങൾ ഉൾപ്പെടെ, പുതിയ കണ്ടെയ്‌നറിന്റെ പാരാമീറ്ററുകൾ API വഴി ഡോക്കറിന് കൈമാറി.
പതിപ്പുകളിലൂടെ തിരയുമ്പോൾ, ഡോക്കർ API എല്ലാ പിശകുകളും നൽകിയിട്ടില്ല (കുറഞ്ഞത് പതിപ്പ് 1.10 ൽ എങ്കിലും). “ഡോക്കർ റൺ” വഴി ഞങ്ങൾ കണ്ടെയ്നർ ആരംഭിക്കാൻ ശ്രമിച്ചപ്പോൾ, ഒടുവിൽ ഞങ്ങൾ എന്തെങ്കിലും കണ്ടു:

write /proc/sys/net/ipv4/ipfrag_high_thresh: invalid argument docker: Error response from daemon: Cannot start container <...>: [9] System error: could not synchronise with container process.

പാരാമീറ്റർ മൂല്യം സാധുതയുള്ളതല്ല. പക്ഷെ എന്തുകൊണ്ട്? എന്തുകൊണ്ടാണ് ഇത് ചിലപ്പോൾ മാത്രം സാധുതയില്ലാത്തത്? Sysctl പാരാമീറ്ററുകൾ പ്രയോഗിക്കുന്ന ക്രമത്തിന് ഡോക്കർ ഗ്യാരണ്ടി നൽകുന്നില്ലെന്ന് മനസ്സിലായി (ഏറ്റവും പുതിയ പരീക്ഷിച്ച പതിപ്പ് 1.13.1 ആണ്), അതിനാൽ ചിലപ്പോൾ ipfrag_low_thresh 256M ആയിരിക്കുമ്പോൾ ipfrag_high_thresh 3K ആയി സജ്ജീകരിക്കാൻ ശ്രമിച്ചു, അതായത്, ഉയർന്ന പരിധി കുറവായിരുന്നു. കുറഞ്ഞ പരിധിയേക്കാൾ, ഇത് പിശകിലേക്ക് നയിച്ചു.

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

FragmentSmack/SegmentSmack. ആദ്യ രക്തം 2

ക്ലൗഡിലെ വർക്ക്‌എറൗണ്ടിന്റെ ഉപയോഗം മനസിലാക്കാൻ ഞങ്ങൾക്ക് സമയം ലഭിക്കുന്നതിന് മുമ്പ്, ഉപയോക്താക്കളിൽ നിന്നുള്ള ആദ്യത്തെ അപൂർവ പരാതികൾ എത്തിത്തുടങ്ങി. ആ സമയത്ത്, ആദ്യത്തെ സെർവറുകളിൽ വർക്ക്‌അൗണ്ട് ഉപയോഗിക്കാൻ തുടങ്ങി നിരവധി ആഴ്ചകൾ കഴിഞ്ഞിരുന്നു. വ്യക്തിഗത സേവനങ്ങൾക്കെതിരെയാണ് പരാതികൾ ലഭിച്ചതെന്നും ഈ സേവനങ്ങളുടെ എല്ലാ സെർവറുകളല്ലെന്നും പ്രാഥമിക അന്വേഷണത്തിൽ തെളിഞ്ഞു. പ്രശ്നം വീണ്ടും അങ്ങേയറ്റം അനിശ്ചിതത്വത്തിലായി.

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

മൂന്നാഴ്ചയ്ക്കുശേഷം പ്രശ്നം ആവർത്തിച്ചു. ഈ സെർവറുകളുടെ കോൺഫിഗറേഷൻ വളരെ ലളിതമായിരുന്നു: പ്രോക്സി/ബാലൻസർ മോഡിൽ Nginx. അധികം തിരക്കില്ല. പുതിയ ആമുഖ കുറിപ്പ്: ക്ലയന്റുകളിൽ 504 പിശകുകളുടെ എണ്ണം ഓരോ ദിവസവും വർദ്ധിച്ചുകൊണ്ടിരിക്കുന്നു (ഗേറ്റ്‌വേ ടൈംഔട്ട്). ഈ സേവനത്തിനായി പ്രതിദിനം 504 പിശകുകളുടെ എണ്ണം ഗ്രാഫ് കാണിക്കുന്നു:

എല്ലാ പിശകുകളും ഒരേ ബാക്കെൻഡിനെക്കുറിച്ചാണ് - ക്ലൗഡിലുള്ളതിനെക്കുറിച്ചാണ്. ഈ ബാക്കെൻഡിലെ പാക്കേജ് ശകലങ്ങൾക്കായുള്ള മെമ്മറി ഉപഭോഗ ഗ്രാഫ് ഇതുപോലെ കാണപ്പെടുന്നു:

ഓപ്പറേറ്റിംഗ് സിസ്റ്റം ഗ്രാഫുകളിലെ പ്രശ്നത്തിന്റെ ഏറ്റവും വ്യക്തമായ പ്രകടനങ്ങളിലൊന്നാണിത്. ക്ലൗഡിൽ, അതേ സമയം തന്നെ, QoS (ട്രാഫിക് കൺട്രോൾ) ക്രമീകരണങ്ങളുമായുള്ള മറ്റൊരു നെറ്റ്‌വർക്ക് പ്രശ്നം പരിഹരിച്ചു. പാക്കറ്റ് ശകലങ്ങൾക്കായുള്ള മെമ്മറി ഉപഭോഗത്തിന്റെ ഗ്രാഫിൽ, ഇത് തികച്ചും സമാനമാണ്:

അനുമാനം ലളിതമായിരുന്നു: ഗ്രാഫുകളിൽ അവ ഒരേപോലെയാണെങ്കിൽ, അവയ്ക്ക് ഒരേ കാരണമുണ്ട്. മാത്രമല്ല, ഇത്തരത്തിലുള്ള മെമ്മറിയിൽ എന്തെങ്കിലും പ്രശ്നങ്ങൾ വളരെ വിരളമാണ്.

QoS-ൽ സ്ഥിരസ്ഥിതി ക്രമീകരണങ്ങളുള്ള fq പാക്കറ്റ് ഷെഡ്യൂളർ ഞങ്ങൾ ഉപയോഗിച്ചു എന്നതാണ് പരിഹരിക്കപ്പെട്ട പ്രശ്നത്തിന്റെ സാരം. സ്ഥിരസ്ഥിതിയായി, ഒരു കണക്ഷനായി, ക്യൂവിലേക്ക് 100 പാക്കറ്റുകൾ ചേർക്കാൻ ഇത് നിങ്ങളെ അനുവദിക്കുന്നു, കൂടാതെ ചില കണക്ഷനുകൾ, ചാനൽ ക്ഷാമത്തിന്റെ സാഹചര്യങ്ങളിൽ, ശേഷിയിലേക്ക് ക്യൂ തടസ്സപ്പെടാൻ തുടങ്ങി. ഈ സാഹചര്യത്തിൽ, പാക്കറ്റുകൾ ഉപേക്ഷിക്കപ്പെടുന്നു. tc സ്ഥിതിവിവരക്കണക്കുകളിൽ (tc -s qdisc) ഇത് ഇതുപോലെ കാണാവുന്നതാണ്:

qdisc fq 2c6c: parent 1:2c6c limit 10000p flow_limit 100p buckets 1024 orphan_mask 1023 quantum 3028 initial_quantum 15140 refill_delay 40.0ms
 Sent 454701676345 bytes 491683359 pkt (dropped 464545, overlimits 0 requeues 0)
 backlog 0b 0p requeues 0
  1024 flows (1021 inactive, 0 throttled)
  0 gc, 0 highprio, 0 throttled, 464545 flows_plimit

"464545 flows_plimit" എന്നത് ഒരു കണക്ഷന്റെ ക്യൂ പരിധി കവിഞ്ഞതിനാൽ ഡ്രോപ്പ് ചെയ്യപ്പെട്ട പാക്കറ്റുകളാണ്, കൂടാതെ "ഡ്രോപ്പ്ഡ് 464545" എന്നത് ഈ ഷെഡ്യൂളറിന്റെ എല്ലാ പാക്കറ്റുകളുടെയും ആകെത്തുകയാണ്. ക്യൂ ലെങ്ത് 1 ആയി വർധിപ്പിച്ച് കണ്ടെയ്‌നറുകൾ പുനരാരംഭിച്ച ശേഷം, പ്രശ്നം സംഭവിക്കുന്നത് നിർത്തി. നിങ്ങൾക്ക് ഇരുന്ന് സ്മൂത്തി കുടിക്കാം.

FragmentSmack/SegmentSmack. അവസാന രക്തം

ഒന്നാമതായി, കേർണലിലെ കേടുപാടുകൾ പ്രഖ്യാപിച്ച് കുറച്ച് മാസങ്ങൾക്ക് ശേഷം, FragmentSmack-നുള്ള ഒരു പരിഹാരം ഒടുവിൽ പ്രത്യക്ഷപ്പെട്ടു (ഓഗസ്റ്റിലെ പ്രഖ്യാപനത്തോടൊപ്പം, SegmentSmack-ന് മാത്രമായി ഒരു ഫിക്സ് പുറത്തിറക്കിയതായി ഞാൻ നിങ്ങളെ ഓർമ്മിപ്പിക്കട്ടെ), ഇത് ഞങ്ങൾക്ക് വർക്ക്റൗണ്ട് ഉപേക്ഷിക്കാൻ അവസരം നൽകി, അത് ഞങ്ങളെ വളരെയധികം കുഴപ്പത്തിലാക്കി. ഈ സമയത്ത്, ചില സെർവറുകൾ പുതിയ കേർണലിലേക്ക് മാറ്റാൻ ഞങ്ങൾക്ക് ഇതിനകം കഴിഞ്ഞു, ഇപ്പോൾ ഞങ്ങൾ ആദ്യം മുതൽ ആരംഭിക്കേണ്ടതുണ്ട്. FragmentSmack പരിഹാരത്തിനായി കാത്തുനിൽക്കാതെ എന്തുകൊണ്ടാണ് ഞങ്ങൾ കേർണൽ അപ്ഡേറ്റ് ചെയ്തത്? ഈ കേടുപാടുകൾക്കെതിരെ പരിരക്ഷിക്കുന്ന പ്രക്രിയ CentOS തന്നെ അപ്‌ഡേറ്റ് ചെയ്യുന്ന പ്രക്രിയയുമായി (ഇത് കേർണൽ മാത്രം അപ്‌ഡേറ്റ് ചെയ്യുന്നതിനേക്കാൾ കൂടുതൽ സമയമെടുക്കുന്നു) പൊരുത്തപ്പെടുന്നു എന്നതാണ് വസ്തുത. കൂടാതെ, SegmentSmack കൂടുതൽ അപകടകരമായ ഒരു അപകടസാധ്യതയാണ്, അതിനുള്ള ഒരു പരിഹാരം ഉടനടി പ്രത്യക്ഷപ്പെട്ടു, അതിനാൽ അത് എന്തായാലും അർത്ഥവത്താണ്. എന്നിരുന്നാലും, CentOS-ൽ കേർണൽ അപ്‌ഡേറ്റ് ചെയ്യാൻ ഞങ്ങൾക്ക് കഴിഞ്ഞില്ല, കാരണം CentOS 7.5-ൽ പ്രത്യക്ഷപ്പെട്ട FragmentSmack ദുർബലത പതിപ്പ് 7.6-ൽ മാത്രമേ പരിഹരിച്ചിട്ടുള്ളൂ, അതിനാൽ ഞങ്ങൾക്ക് 7.5-ലേക്കുള്ള അപ്‌ഡേറ്റ് നിർത്തി 7.6-ലേക്കുള്ള അപ്‌ഡേറ്റ് ഉപയോഗിച്ച് വീണ്ടും ആരംഭിക്കേണ്ടി വന്നു. കൂടാതെ ഇതും സംഭവിക്കുന്നു.

രണ്ടാമതായി, പ്രശ്‌നങ്ങളെക്കുറിച്ചുള്ള അപൂർവ ഉപയോക്തൃ പരാതികൾ ഞങ്ങളിലേക്ക് മടങ്ങിയെത്തി. അവയെല്ലാം ക്ലയന്റുകളിൽ നിന്ന് ഞങ്ങളുടെ ചില സെർവറുകളിലേക്ക് അപ്‌ലോഡ് ചെയ്യുന്നതുമായി ബന്ധപ്പെട്ടതാണെന്ന് ഇപ്പോൾ ഞങ്ങൾക്ക് ഉറപ്പായി അറിയാം. മാത്രമല്ല, മൊത്തം പിണ്ഡത്തിൽ നിന്ന് വളരെ ചെറിയ എണ്ണം അപ്‌ലോഡുകൾ ഈ സെർവറിലൂടെ കടന്നുപോയി.

മുകളിലെ കഥയിൽ നിന്ന് നമ്മൾ ഓർക്കുന്നത് പോലെ, Sysctl തിരികെ കൊണ്ടുവരുന്നത് സഹായിച്ചില്ല. റീബൂട്ട് സഹായിച്ചു, പക്ഷേ താൽക്കാലികമായി.
Sysctl സംബന്ധിച്ച സംശയങ്ങൾ നീങ്ങിയില്ല, എന്നാൽ ഇത്തവണ കഴിയുന്നത്ര വിവരങ്ങൾ ശേഖരിക്കേണ്ടത് ആവശ്യമാണ്. എന്താണ് സംഭവിക്കുന്നതെന്ന് കൂടുതൽ കൃത്യമായി പഠിക്കുന്നതിനായി ക്ലയന്റിലുള്ള അപ്‌ലോഡ് പ്രശ്‌നം പുനർനിർമ്മിക്കാനുള്ള കഴിവിന്റെ വലിയ കുറവും ഉണ്ടായിരുന്നു.

ലഭ്യമായ എല്ലാ സ്ഥിതിവിവരക്കണക്കുകളുടെയും ലോഗുകളുടെയും വിശകലനം എന്താണ് സംഭവിക്കുന്നതെന്ന് മനസ്സിലാക്കാൻ ഞങ്ങളെ കൂടുതൽ അടുപ്പിച്ചില്ല. ഒരു നിർദ്ദിഷ്ട കണക്ഷൻ "അനുഭവിക്കുന്നതിനായി" പ്രശ്നം പുനർനിർമ്മിക്കാനുള്ള കഴിവിന്റെ രൂക്ഷമായ അഭാവം ഉണ്ടായിരുന്നു. അവസാനമായി, ഡെവലപ്പർമാർ, ആപ്ലിക്കേഷന്റെ ഒരു പ്രത്യേക പതിപ്പ് ഉപയോഗിച്ച്, Wi-Fi വഴി കണക്റ്റുചെയ്യുമ്പോൾ ഒരു ടെസ്റ്റ് ഉപകരണത്തിൽ പ്രശ്നങ്ങളുടെ സ്ഥിരമായ പുനർനിർമ്മാണം നേടാൻ കഴിഞ്ഞു. ഇത് അന്വേഷണത്തിൽ വഴിത്തിരിവായി. ഞങ്ങളുടെ ജാവ ആപ്ലിക്കേഷനായ ബാക്കെൻഡിലേക്ക് പ്രോക്‌സി ചെയ്‌ത Nginx-ലേക്ക് ക്ലയന്റ് കണക്റ്റുചെയ്‌തു.

പ്രശ്‌നങ്ങൾക്കുള്ള ഡയലോഗ് ഇതുപോലെയായിരുന്നു (Nginx പ്രോക്‌സി ഭാഗത്ത് പരിഹരിച്ചത്):

1. ക്ലയന്റ്: ഒരു ഫയൽ ഡൗൺലോഡ് ചെയ്യുന്നതിനെ കുറിച്ചുള്ള വിവരങ്ങൾ സ്വീകരിക്കാൻ അഭ്യർത്ഥിക്കുക.
2. ജാവ സെർവർ: പ്രതികരണം.
3. ക്ലയന്റ്: ഫയലിനൊപ്പം പോസ്റ്റ് ചെയ്യുക.
4. ജാവ സെർവർ: പിശക്.

അതേ സമയം, ക്ലയന്റിൽ നിന്ന് 0 ബൈറ്റ് ഡാറ്റ ലഭിച്ചതായി ജാവ സെർവർ ലോഗിലേക്ക് എഴുതുന്നു, കൂടാതെ അഭ്യർത്ഥനയ്ക്ക് 30 സെക്കൻഡിൽ കൂടുതൽ സമയമെടുത്തതായി Nginx പ്രോക്സി എഴുതുന്നു (30 സെക്കൻഡ് എന്നത് ക്ലയന്റ് ആപ്ലിക്കേഷന്റെ സമയപരിധിയാണ്). എന്തുകൊണ്ട് കാലഹരണപ്പെട്ടു, എന്തുകൊണ്ട് 0 ബൈറ്റുകൾ? ഒരു HTTP വീക്ഷണകോണിൽ നിന്ന്, എല്ലാം ചെയ്യേണ്ടതുപോലെ പ്രവർത്തിക്കുന്നു, പക്ഷേ ഫയലിനൊപ്പം POST നെറ്റ്‌വർക്കിൽ നിന്ന് അപ്രത്യക്ഷമാകുന്നതായി തോന്നുന്നു. മാത്രമല്ല, ക്ലയന്റിനും Nginx നും ഇടയിൽ ഇത് അപ്രത്യക്ഷമാകുന്നു. Tcpdump ഉപയോഗിച്ച് സ്വയം ആയുധമാക്കാനുള്ള സമയമാണിത്! എന്നാൽ ആദ്യം നിങ്ങൾ നെറ്റ്‌വർക്ക് കോൺഫിഗറേഷൻ മനസ്സിലാക്കേണ്ടതുണ്ട്. Nginx പ്രോക്സിയാണ് L3 ബാലൻസറിന് പിന്നിലുള്ളത് എൻഎഫ്വെയർ. L3 ബാലൻസറിൽ നിന്ന് സെർവറിലേക്ക് പാക്കറ്റുകൾ വിതരണം ചെയ്യാൻ ടണലിംഗ് ഉപയോഗിക്കുന്നു, ഇത് പാക്കറ്റുകളിലേക്ക് അതിന്റെ തലക്കെട്ടുകൾ ചേർക്കുന്നു:

ഈ സാഹചര്യത്തിൽ, നെറ്റ്‌വർക്ക് ഈ സെർവറിലേക്ക് Vlan-ടാഗുചെയ്‌ത ട്രാഫിക്കിന്റെ രൂപത്തിൽ വരുന്നു, അത് പാക്കറ്റുകളിലേക്ക് സ്വന്തം ഫീൽഡുകളും ചേർക്കുന്നു:

ഈ ട്രാഫിക്കും വിഘടിപ്പിക്കാം (പരിഹാരത്തിനായുള്ള അപകടസാധ്യതകൾ വിലയിരുത്തുമ്പോൾ ഞങ്ങൾ സംസാരിച്ച ഇൻകമിംഗ് വിഘടിച്ച ട്രാഫിക്കിന്റെ അതേ ചെറിയ ശതമാനം), ഇത് തലക്കെട്ടുകളുടെ ഉള്ളടക്കത്തെയും മാറ്റുന്നു:

ഒരിക്കൽ കൂടി: പാക്കറ്റുകൾ ഒരു വ്ലാൻ ടാഗ് ഉപയോഗിച്ച് പൊതിഞ്ഞ്, ഒരു തുരങ്കം കൊണ്ട് പൊതിഞ്ഞ്, വിഘടിച്ചിരിക്കുന്നു. ഇത് എങ്ങനെ സംഭവിക്കുന്നു എന്ന് നന്നായി മനസ്സിലാക്കാൻ, ക്ലയന്റിൽനിന്ന് Nginx പ്രോക്സിയിലേക്കുള്ള പാക്കറ്റ് റൂട്ട് നമുക്ക് കണ്ടെത്താം.

1. പാക്കറ്റ് L3 ബാലൻസറിൽ എത്തുന്നു. ഡാറ്റാ സെന്ററിനുള്ളിലെ ശരിയായ റൂട്ടിംഗിനായി, പാക്കറ്റ് ഒരു തുരങ്കത്തിൽ പൊതിഞ്ഞ് നെറ്റ്‌വർക്ക് കാർഡിലേക്ക് അയയ്ക്കുന്നു.
2. പാക്കറ്റ് + ടണൽ ഹെഡറുകൾ MTU-യിൽ ചേരാത്തതിനാൽ, പാക്കറ്റ് ശകലങ്ങളായി മുറിച്ച് നെറ്റ്‌വർക്കിലേക്ക് അയയ്ക്കുന്നു.
3. L3 ബാലൻസറിന് ശേഷമുള്ള സ്വിച്ച്, ഒരു പാക്കറ്റ് സ്വീകരിക്കുമ്പോൾ, അതിലേക്ക് ഒരു Vlan ടാഗ് ചേർത്ത് അത് ഓണാക്കുന്നു.
4. Nginx പ്രോക്‌സിക്ക് മുന്നിലുള്ള സ്വിച്ച്, സെർവർ ഒരു Vlan-എൻക്യാപ്‌സുലേറ്റഡ് പാക്കറ്റ് പ്രതീക്ഷിക്കുന്നതായി (പോർട്ട് ക്രമീകരണങ്ങളെ അടിസ്ഥാനമാക്കി) കാണുന്നു, അതിനാൽ അത് Vlan ടാഗ് നീക്കം ചെയ്യാതെ തന്നെ അത് അയയ്‌ക്കുന്നു.
5. Linux വ്യക്തിഗത പാക്കേജുകളുടെ ശകലങ്ങൾ എടുത്ത് അവയെ ഒരു വലിയ പാക്കേജിലേക്ക് ലയിപ്പിക്കുന്നു.
6. അടുത്തതായി, പാക്കറ്റ് Vlan ഇന്റർഫേസിൽ എത്തുന്നു, അതിൽ നിന്ന് ആദ്യത്തെ പാളി നീക്കംചെയ്യുന്നു - Vlan encapsulation.
7. ലിനക്സ് അത് ടണൽ ഇന്റർഫേസിലേക്ക് അയയ്ക്കുന്നു, അവിടെ നിന്ന് മറ്റൊരു ലെയർ നീക്കംചെയ്യുന്നു - ടണൽ എൻക്യാപ്സുലേഷൻ.

ഇതെല്ലാം പാരാമീറ്ററുകളായി tcpdump-ലേക്ക് കൈമാറുക എന്നതാണ് ബുദ്ധിമുട്ട്.
നമുക്ക് അവസാനം മുതൽ ആരംഭിക്കാം: ക്ലയന്റുകളിൽ നിന്ന് vlan, ടണൽ എൻക്യാപ്‌സുലേഷൻ നീക്കം ചെയ്‌ത വൃത്തിയുള്ള (അനാവശ്യ തലക്കെട്ടുകളില്ലാതെ) IP പാക്കറ്റുകൾ ഉണ്ടോ?

tcpdump host <ip клиента>

ഇല്ല, സെർവറിൽ അത്തരം പാക്കേജുകളൊന്നും ഉണ്ടായിരുന്നില്ല. അതുകൊണ്ട് പ്രശ്നം നേരത്തെ തന്നെ ഉണ്ടാവണം. Vlan എൻക്യാപ്‌സുലേഷൻ മാത്രം നീക്കം ചെയ്‌ത ഏതെങ്കിലും പാക്കറ്റുകൾ ഉണ്ടോ?

tcpdump ip[32:4]=0xx390x2xx

0xx390x2xx എന്നത് ഹെക്സ് ഫോർമാറ്റിലുള്ള ക്ലയന്റ് ഐപി വിലാസമാണ്.
32:4 — ടണൽ പാക്കറ്റിൽ SCR IP എഴുതിയിരിക്കുന്ന ഫീൽഡിന്റെ വിലാസവും നീളവും.

ഫീൽഡ് വിലാസം ബ്രൂട്ട് ഫോഴ്‌സ് ഉപയോഗിച്ച് തിരഞ്ഞെടുക്കേണ്ടതുണ്ട്, കാരണം ഇൻറർനെറ്റിൽ അവർ 40, 44, 50, 54 എന്ന് എഴുതുന്നു, പക്ഷേ അവിടെ ഐപി വിലാസം ഇല്ലായിരുന്നു. നിങ്ങൾക്ക് ഹെക്സിലെ പാക്കറ്റുകളിൽ ഒന്ന് (tcpdump-ലെ -xx അല്ലെങ്കിൽ -XX പാരാമീറ്റർ) നോക്കാനും നിങ്ങൾക്കറിയാവുന്ന IP വിലാസം കണക്കാക്കാനും കഴിയും.

Vlan, Tunnel encapsulation നീക്കം ചെയ്യാത്ത പാക്കറ്റ് ശകലങ്ങൾ ഉണ്ടോ?

tcpdump ((ip[6:2] > 0) and (not ip[6] = 64))

അവസാനത്തേത് ഉൾപ്പെടെ എല്ലാ ശകലങ്ങളും ഈ മാജിക് നമുക്ക് കാണിച്ചുതരും. ഒരുപക്ഷേ, അതേ കാര്യം ഐപി ഉപയോഗിച്ച് ഫിൽട്ടർ ചെയ്യാൻ കഴിയും, പക്ഷേ ഞാൻ ശ്രമിച്ചില്ല, കാരണം അത്തരം ധാരാളം പാക്കറ്റുകൾ ഇല്ല, എനിക്ക് ആവശ്യമുള്ളവ പൊതുവായ ഒഴുക്കിൽ എളുപ്പത്തിൽ കണ്ടെത്തി. അവ ഇതാ:

14:02:58.471063 In 00:de:ff:1a:94:11 ethertype IPv4 (0x0800), length 1516: (tos 0x0, ttl 63, id 53652, offset 0, flags [+], proto IPIP (4), length 1500)
    11.11.11.11 > 22.22.22.22: truncated-ip - 20 bytes missing! (tos 0x0, ttl 50, id 57750, offset 0, flags [DF], proto TCP (6), length 1500)
    33.33.33.33.33333 > 44.44.44.44.80: Flags [.], seq 0:1448, ack 1, win 343, options [nop,nop,TS val 11660691 ecr 2998165860], length 1448
        0x0000: 0000 0001 0006 00de fb1a 9441 0000 0800 ...........A....
        0x0010: 4500 05dc d194 2000 3f09 d5fb 0a66 387d E.......?....f8}
        0x0020: 1x67 7899 4500 06xx e198 4000 3206 6xx4 [email protected].
        0x0030: b291 x9xx x345 2541 83b9 0050 9740 0x04 .......A...P.@..
        0x0040: 6444 4939 8010 0257 8c3c 0000 0101 080x dDI9...W.......
        0x0050: 00b1 ed93 b2b4 6964 xxd8 ffe1 006a 4578 ......ad.....jEx
        0x0060: 6966 0000 4x4d 002a 0500 0008 0004 0100 if..MM.*........

14:02:58.471103 In 00:de:ff:1a:94:11 ethertype IPv4 (0x0800), length 62: (tos 0x0, ttl 63, id 53652, offset 1480, flags [none], proto IPIP (4), length 40)
    11.11.11.11 > 22.22.22.22: ip-proto-4
        0x0000: 0000 0001 0006 00de fb1a 9441 0000 0800 ...........A....
        0x0010: 4500 0028 d194 00b9 3f04 faf6 2x76 385x E..(....?....f8}
        0x0020: 1x76 6545 xxxx 1x11 2d2c 0c21 8016 8e43 .faE...D-,.!...C
        0x0030: x978 e91d x9b0 d608 0000 0000 0000 7c31 .x............|Q
        0x0040: 881d c4b6 0000 0000 0000 0000 0000 ..............

ഒരു ഫോട്ടോയോടുകൂടിയ ഒരു പാക്കേജിന്റെ (അതേ ഐഡി 53652) രണ്ട് ശകലങ്ങളാണിവ (ആദ്യ പാക്കേജിൽ Exif എന്ന വാക്ക് ദൃശ്യമാണ്). ഈ തലത്തിൽ പാക്കേജുകൾ ഉള്ളതിനാൽ, ഡംപുകളിൽ ലയിപ്പിച്ച രൂപത്തിൽ അല്ല, പ്രശ്നം അസംബ്ലിയിൽ വ്യക്തമാണ്. ഒടുവിൽ ഇതിന് ഡോക്യുമെന്ററി തെളിവുകളുണ്ട്!

പാക്കറ്റ് ഡീകോഡർ നിർമ്മാണത്തെ തടയുന്ന പ്രശ്നങ്ങളൊന്നും വെളിപ്പെടുത്തിയില്ല. ഇവിടെ പരീക്ഷിച്ചു: hpd.gasmi.net. ആദ്യം, നിങ്ങൾ അവിടെ എന്തെങ്കിലും സ്റ്റഫ് ചെയ്യാൻ ശ്രമിക്കുമ്പോൾ, ഡീകോഡറിന് പാക്കറ്റ് ഫോർമാറ്റ് ഇഷ്ടമല്ല. Srcmac-നും Ethertype-നും ഇടയിൽ ചില അധിക രണ്ട് ഒക്ടറ്റുകൾ ഉണ്ടെന്ന് കണ്ടെത്തി (ശകല വിവരങ്ങളുമായി ബന്ധമില്ല). അവ നീക്കം ചെയ്ത ശേഷം, ഡീകോഡർ പ്രവർത്തിക്കാൻ തുടങ്ങി. എന്നിരുന്നാലും, ഇത് പ്രശ്നങ്ങളൊന്നും കാണിച്ചില്ല.
എന്തൊക്കെ പറഞ്ഞാലും ആ Sysctl ഒഴികെ മറ്റൊന്നും കണ്ടെത്തിയില്ല. സ്കെയിൽ മനസ്സിലാക്കുന്നതിനും തുടർനടപടികൾ തീരുമാനിക്കുന്നതിനുമായി പ്രശ്‌നമുള്ള സെർവറുകൾ തിരിച്ചറിയുന്നതിനുള്ള ഒരു മാർഗം കണ്ടെത്തുക മാത്രമാണ് ശേഷിക്കുന്നത്. ആവശ്യമായ കൌണ്ടർ വേണ്ടത്ര വേഗത്തിൽ കണ്ടെത്തി:

netstat -s | grep "packet reassembles failed”

OID=1.3.6.1.2.1.4.31.1.1.16.1 (snmpd-ൽ ഇത് ഉണ്ട്ipSystemStatsReasmFails).

"IP റീ-അസംബ്ലി അൽഗോരിതം കണ്ടെത്തിയ പരാജയങ്ങളുടെ എണ്ണം (എന്തു കാരണത്താലും: സമയം കഴിഞ്ഞു, പിശകുകൾ മുതലായവ)."

പ്രശ്നം പഠിച്ച സെർവറുകളുടെ കൂട്ടത്തിൽ, രണ്ടിൽ ഈ കൗണ്ടർ വേഗത്തിൽ വർദ്ധിച്ചു, രണ്ടിൽ കൂടുതൽ സാവധാനത്തിൽ, രണ്ടെണ്ണത്തിൽ അത് വർദ്ധിച്ചില്ല. ജാവ സെർവറിലെ HTTP പിശകുകളുടെ ചലനാത്മകതയുമായി ഈ കൗണ്ടറിന്റെ ചലനാത്മകത താരതമ്യം ചെയ്യുമ്പോൾ ഒരു പരസ്പരബന്ധം വെളിപ്പെട്ടു. അതായത്, മീറ്റർ നിരീക്ഷിക്കാൻ കഴിയും.

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

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

ഏറ്റവും പ്രധാനപ്പെട്ട ചോദ്യങ്ങൾ

എന്തുകൊണ്ടാണ് ഞങ്ങളുടെ L3 ബാലൻസറിൽ പാക്കറ്റുകൾ വിഘടിച്ചിരിക്കുന്നത്? ഉപയോക്താക്കളിൽ നിന്ന് ബാലൻസറുകളിലേക്ക് എത്തുന്ന മിക്ക പാക്കറ്റുകളും SYN, ACK എന്നിവയാണ്. ഈ പാക്കേജുകളുടെ വലിപ്പം ചെറുതാണ്. എന്നാൽ അത്തരം പാക്കറ്റുകളുടെ പങ്ക് വളരെ വലുതായതിനാൽ, അവയുടെ പശ്ചാത്തലത്തിൽ വിഘടിക്കാൻ തുടങ്ങിയ വലിയ പാക്കറ്റുകളുടെ സാന്നിധ്യം ഞങ്ങൾ ശ്രദ്ധിച്ചില്ല.

തകർന്ന കോൺഫിഗറേഷൻ സ്ക്രിപ്റ്റായിരുന്നു കാരണം advmss Vlan ഇന്റർഫേസുകളുള്ള സെർവറുകളിൽ (അക്കാലത്ത് ഉൽപ്പാദനത്തിൽ ടാഗ് ചെയ്ത ട്രാഫിക്കുള്ള വളരെ കുറച്ച് സെർവറുകൾ മാത്രമേ ഉണ്ടായിരുന്നുള്ളൂ). ഞങ്ങളുടെ ദിശയിലുള്ള പാക്കറ്റുകൾ വലുപ്പത്തിൽ ചെറുതായിരിക്കണം എന്ന വിവരം ക്ലയന്റിലേക്ക് അറിയിക്കാൻ Advmss ഞങ്ങളെ അനുവദിക്കുന്നു, അതിനാൽ അവയിൽ ടണൽ ഹെഡറുകൾ ഘടിപ്പിച്ചതിന് ശേഷം അവ വിഭജിക്കേണ്ടതില്ല.

എന്തുകൊണ്ട് Sysctl റോൾബാക്ക് സഹായിച്ചില്ല, പക്ഷേ റീബൂട്ട് ചെയ്തു? റോൾ ബാക്ക് Sysctl പാക്കേജുകൾ ലയിപ്പിക്കുന്നതിന് ലഭ്യമായ മെമ്മറിയുടെ അളവ് മാറ്റി. അതേസമയം, ശകലങ്ങൾക്കുള്ള മെമ്മറി ഓവർഫ്ലോ എന്ന വസ്തുത തന്നെ കണക്ഷനുകളുടെ വേഗത കുറയുന്നതിന് കാരണമായി, ഇത് ശകലങ്ങൾ ക്യൂവിൽ വളരെക്കാലം വൈകുന്നതിന് കാരണമായി. അതായത്, പ്രക്രിയ ചക്രങ്ങളിലൂടെ കടന്നുപോയി.
റീബൂട്ട് മെമ്മറി ക്ലിയർ ചെയ്തു, എല്ലാം ക്രമത്തിൽ തിരിച്ചെത്തി.

പരിഹാരമില്ലാതെ ചെയ്യാൻ കഴിയുമോ? അതെ, എന്നാൽ ഒരു ആക്രമണമുണ്ടായാൽ ഉപയോക്താക്കളെ സേവനമില്ലാതെ ഉപേക്ഷിക്കാനുള്ള ഉയർന്ന അപകടസാധ്യതയുണ്ട്. തീർച്ചയായും, വർക്ക്‌എറൗണ്ടിന്റെ ഉപയോഗം ഉപയോക്താക്കൾക്കുള്ള സേവനങ്ങളിലൊന്നിന്റെ വേഗത കുറയുന്നത് ഉൾപ്പെടെ വിവിധ പ്രശ്‌നങ്ങൾക്ക് കാരണമായി, എന്നിരുന്നാലും പ്രവർത്തനങ്ങൾ ന്യായമാണെന്ന് ഞങ്ങൾ വിശ്വസിക്കുന്നു.

ആൻഡ്രി ടിമോഫീവിന് വളരെ നന്ദി (atimofeyev) അന്വേഷണം നടത്തുന്നതിനുള്ള സഹായത്തിനായി, അതുപോലെ അലക്സി ക്രെനെവ് (devicex) - സെർവറുകളിൽ സെന്റോസും കേർണലുകളും അപ്ഡേറ്റ് ചെയ്യുന്നതിനുള്ള ടൈറ്റാനിക് ജോലികൾക്കായി. ഈ സാഹചര്യത്തിൽ തുടക്കം മുതൽ പലതവണ ആരംഭിക്കേണ്ട ഒരു പ്രക്രിയ, അതിനാലാണ് ഇത് മാസങ്ങളോളം ഇഴയുന്നത്.

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