ഒരു സെക്കൻഡിൽ 200 ഫോട്ടോകൾ അയക്കാനുള്ള കഴിവ് Badoo എങ്ങനെ കൈവരിച്ചു

മീഡിയ ഉള്ളടക്കമില്ലാതെ ആധുനിക വെബ് ഏതാണ്ട് അചിന്തനീയമാണ്: മിക്കവാറും എല്ലാ മുത്തശ്ശിമാർക്കും ഒരു സ്മാർട്ട്‌ഫോൺ ഉണ്ട്, എല്ലാവരും സോഷ്യൽ നെറ്റ്‌വർക്കുകളിലുണ്ട്, കൂടാതെ അറ്റകുറ്റപ്പണികളുടെ പ്രവർത്തനരഹിതമായ സമയം കമ്പനികൾക്ക് ചെലവേറിയതാണ്. കമ്പനിയുടെ കഥയുടെ ഒരു ട്രാൻസ്ക്രിപ്റ്റ് ഇതാ ബാദു ഒരു ഹാർഡ്‌വെയർ സൊല്യൂഷൻ ഉപയോഗിച്ച് അവൾ ഫോട്ടോകളുടെ ഡെലിവറി എങ്ങനെ സംഘടിപ്പിച്ചു, ഈ പ്രക്രിയയിൽ അവൾ നേരിട്ട പ്രകടന പ്രശ്‌നങ്ങൾ, അവയ്ക്ക് കാരണമെന്താണ്, എല്ലാ തലങ്ങളിലും തെറ്റ് സഹിഷ്ണുത ഉറപ്പാക്കിക്കൊണ്ട്, Nginx അടിസ്ഥാനമാക്കിയുള്ള ഒരു സോഫ്റ്റ്‌വെയർ സൊല്യൂഷൻ ഉപയോഗിച്ച് ഈ പ്രശ്‌നങ്ങൾ എങ്ങനെ പരിഹരിച്ചു (видео). ഒലെഗിന്റെ കഥയുടെ രചയിതാക്കൾക്ക് ഞങ്ങൾ നന്ദി പറയുന്നു സന്നിസ് സമ്മേളനത്തിൽ അനുഭവം പങ്കുവെച്ച എഫിമോവയും അലക്‌സാന്ദ്ര ഡിമോവയും പ്രവർത്തനസമയം ദിവസം 4.

— ഫോട്ടോകൾ എങ്ങനെ സംഭരിക്കുകയും കാഷെ ചെയ്യുകയും ചെയ്യുന്നു എന്നതിനെക്കുറിച്ചുള്ള ഒരു ചെറിയ ആമുഖത്തോടെ നമുക്ക് ആരംഭിക്കാം. ഞങ്ങൾ അവ സംഭരിക്കുന്ന ഒരു ലെയറും ഫോട്ടോകൾ കാഷെ ചെയ്യുന്ന ഒരു ലെയറും ഉണ്ട്. അതേ സമയം, ഉയർന്ന ട്രിക്ക് റേറ്റ് നേടാനും സ്റ്റോറേജിലെ ലോഡ് കുറയ്ക്കാനും ഞങ്ങൾ ആഗ്രഹിക്കുന്നുവെങ്കിൽ, ഒരു വ്യക്തിഗത ഉപയോക്താവിന്റെ ഓരോ ഫോട്ടോയും ഒരു കാഷിംഗ് സെർവറിലാണെന്നത് ഞങ്ങൾക്ക് പ്രധാനമാണ്. അല്ലെങ്കിൽ, നമുക്ക് കൂടുതൽ സെർവറുകൾ ഉള്ളതിന്റെ ഇരട്ടി ഡിസ്കുകൾ ഇൻസ്റ്റാൾ ചെയ്യേണ്ടിവരും. ഞങ്ങളുടെ ട്രിക്ക് നിരക്ക് ഏകദേശം 99% ആണ്, അതായത്, ഞങ്ങളുടെ സ്റ്റോറേജിലെ ലോഡ് ഞങ്ങൾ 100 മടങ്ങ് കുറയ്ക്കുന്നു, ഇത് ചെയ്യുന്നതിന്, 10 വർഷം മുമ്പ്, ഇതെല്ലാം നിർമ്മിക്കുമ്പോൾ, ഞങ്ങൾക്ക് 50 സെർവറുകൾ ഉണ്ടായിരുന്നു. അതനുസരിച്ച്, ഈ ഫോട്ടോകൾ നൽകുന്നതിന്, ഈ സെർവറുകൾ നൽകുന്ന 50 ബാഹ്യ ഡൊമെയ്‌നുകൾ ഞങ്ങൾക്ക് ആവശ്യമാണ്.

സ്വാഭാവികമായും, ചോദ്യം ഉടനടി ഉയർന്നു: ഞങ്ങളുടെ സെർവറുകളിലൊന്ന് പ്രവർത്തനരഹിതമാവുകയും ലഭ്യമല്ലാതാവുകയും ചെയ്താൽ, ട്രാഫിക്കിന്റെ ഏത് ഭാഗമാണ് നമുക്ക് നഷ്ടപ്പെടുന്നത്? വിപണിയിൽ ഉള്ളത് നോക്കി ഞങ്ങൾ ഒരു ഹാർഡ്‌വെയർ വാങ്ങാൻ തീരുമാനിച്ചു, അത് ഞങ്ങളുടെ എല്ലാ പ്രശ്നങ്ങളും പരിഹരിക്കും. തിരഞ്ഞെടുപ്പ് F5-നെറ്റ്‌വർക്ക് കമ്പനിയുടെ പരിഹാരത്തിൽ വീണു (അത്, അടുത്തിടെ NGINX, Inc വാങ്ങിയത്): BIG-IP ലോക്കൽ ട്രാഫിക് മാനേജർ.

ഈ ഹാർഡ്‌വെയർ (LTM) എന്താണ് ചെയ്യുന്നത്: ഇത് ഒരു ഇരുമ്പ് റൂട്ടറാണ്, അത് അതിന്റെ ബാഹ്യ പോർട്ടുകളുടെ ഇരുമ്പ് ആവർത്തനം ഉണ്ടാക്കുകയും നെറ്റ്‌വർക്ക് ടോപ്പോളജി അടിസ്ഥാനമാക്കി ട്രാഫിക് റൂട്ട് ചെയ്യാൻ നിങ്ങളെ അനുവദിക്കുകയും ചില ക്രമീകരണങ്ങളിൽ ആരോഗ്യ പരിശോധനകൾ നടത്തുകയും ചെയ്യുന്നു. ഈ ഹാർഡ്‌വെയർ പ്രോഗ്രാം ചെയ്യാൻ കഴിയുമെന്നത് ഞങ്ങൾക്ക് പ്രധാനമായിരുന്നു. അതനുസരിച്ച്, ഒരു നിർദ്ദിഷ്‌ട കാഷെയിൽ നിന്ന് ഒരു നിർദ്ദിഷ്‌ട ഉപയോക്താവിന്റെ ഫോട്ടോഗ്രാഫുകൾ എങ്ങനെ നൽകപ്പെട്ടു എന്നതിന്റെ യുക്തി നമുക്ക് വിവരിക്കാം. അത് കാഴ്ച്ചയ്ക് എന്ത് പോലെയിരിക്കും? ഒരു ഡൊമെയ്‌നിൽ ഇന്റർനെറ്റ് നോക്കുന്ന ഒരു ഹാർഡ്‌വെയർ ഉണ്ട്, ഒരു ഐപി, ssl ഓഫ്‌ലോഡ് ചെയ്യുന്നു, http അഭ്യർത്ഥനകൾ പാഴ്‌സ് ചെയ്യുന്നു, IRule-ൽ നിന്ന് ഒരു കാഷെ നമ്പർ തിരഞ്ഞെടുക്കുന്നു, എവിടെ പോകണം, ട്രാഫിക്കിനെ അവിടേക്ക് പോകാൻ അനുവദിക്കുന്നു. അതേ സമയം, അത് ആരോഗ്യ പരിശോധനകൾ നടത്തുന്നു, ചില മെഷീൻ ലഭ്യമല്ലാത്ത സാഹചര്യത്തിൽ, ആ സമയത്ത് ട്രാഫിക് ഒരു ബാക്കപ്പ് സെർവറിലേക്ക് പോകുന്ന തരത്തിൽ ഞങ്ങൾ അത് ഉണ്ടാക്കി. ഒരു കോൺഫിഗറേഷൻ വീക്ഷണകോണിൽ, തീർച്ചയായും, ചില സൂക്ഷ്മതകളുണ്ട്, പക്ഷേ പൊതുവേ എല്ലാം വളരെ ലളിതമാണ്: ഞങ്ങൾ ഒരു കാർഡ് രജിസ്റ്റർ ചെയ്യുന്നു, നെറ്റ്‌വർക്കിലെ ഞങ്ങളുടെ ഐപിയിലേക്ക് ഒരു നിശ്ചിത നമ്പറിന്റെ കത്തിടപാടുകൾ, ഞങ്ങൾ പോർട്ടുകൾ 80 ൽ കേൾക്കുമെന്ന് ഞങ്ങൾ പറയുന്നു. കൂടാതെ 443, സെർവർ ലഭ്യമല്ലെങ്കിൽ, നിങ്ങൾ ബാക്കപ്പിലേക്ക് ട്രാഫിക് അയയ്‌ക്കേണ്ടതുണ്ടെന്ന് ഞങ്ങൾ പറയുന്നു, ഈ സാഹചര്യത്തിൽ 35-ാമത്തേത്, ഈ ആർക്കിടെക്ചർ എങ്ങനെ വേർപെടുത്തണം എന്നതിനെക്കുറിച്ചുള്ള ഒരു കൂട്ടം യുക്തി ഞങ്ങൾ വിവരിക്കുന്നു. ഒരേയൊരു പ്രശ്നം ഹാർഡ്‌വെയർ പ്രോഗ്രാം ചെയ്ത ഭാഷ Tcl ആയിരുന്നു എന്നതാണ്. ആർക്കെങ്കിലും ഇത് ഓർമ്മയുണ്ടെങ്കിൽ... പ്രോഗ്രാമിംഗിന് സൗകര്യപ്രദമായ ഭാഷയേക്കാൾ എഴുതാൻ മാത്രമുള്ളതാണ് ഈ ഭാഷ:

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

എന്നിരുന്നാലും…

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

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

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

അതായത്, പ്രശ്നത്തിന്റെ ഉറവിടം ഞങ്ങൾ തിരിച്ചറിഞ്ഞു, തടസ്സം തിരിച്ചറിഞ്ഞു. ഞങ്ങൾ എന്ത് ചെയ്യണമെന്ന് തീരുമാനിക്കാൻ അവശേഷിക്കുന്നു.

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

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

അതനുസരിച്ച്, ലോജിക് അതേപടി തുടരുന്നു: ഞങ്ങൾ Nginx ഇൻസ്റ്റാൾ ചെയ്യുന്നു, അതിന് SSL-ഓഫ്‌ലോഡ് ചെയ്യാൻ കഴിയും, നമുക്ക് എങ്ങനെയെങ്കിലും റൂട്ടിംഗ് ലോജിക് പ്രോഗ്രാം ചെയ്യാം, കോൺഫിഗറുകളിൽ ആരോഗ്യ പരിശോധനകൾ നടത്താം, കൂടാതെ നമുക്ക് മുമ്പ് ഉണ്ടായിരുന്ന ലോജിക് ഡ്യൂപ്ലിക്കേറ്റ് ചെയ്യാം.

കോൺഫിഗറേഷനുകൾ എഴുതാൻ നമുക്ക് ഇരിക്കാം. ആദ്യം എല്ലാം വളരെ ലളിതമാണെന്ന് തോന്നി, പക്ഷേ, നിർഭാഗ്യവശാൽ, ഓരോ ജോലിക്കും മാനുവലുകൾ കണ്ടെത്തുന്നത് വളരെ ബുദ്ധിമുട്ടാണ്. അതിനാൽ, "ഫോട്ടോകൾക്കായി Nginx എങ്ങനെ കോൺഫിഗർ ചെയ്യാം" എന്ന് ഗൂഗിൾ ചെയ്യാൻ ഞങ്ങൾ ശുപാർശ ചെയ്യുന്നില്ല: ഔദ്യോഗിക ഡോക്യുമെന്റേഷൻ റഫർ ചെയ്യുന്നതാണ് നല്ലത്, ഏത് ക്രമീകരണങ്ങളാണ് സ്പർശിക്കേണ്ടത് എന്ന് കാണിക്കും. എന്നാൽ നിർദ്ദിഷ്ട പാരാമീറ്റർ സ്വയം തിരഞ്ഞെടുക്കുന്നതാണ് നല്ലത്. ശരി, അപ്പോൾ എല്ലാം ലളിതമാണ്: ഞങ്ങളുടെ പക്കലുള്ള സെർവറുകൾ ഞങ്ങൾ വിവരിക്കുന്നു, ഞങ്ങൾ സർട്ടിഫിക്കറ്റുകൾ വിവരിക്കുന്നു ... എന്നാൽ ഏറ്റവും രസകരമായ കാര്യം, വാസ്തവത്തിൽ, റൂട്ടിംഗ് ലോജിക് തന്നെയാണ്.

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

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

ഇത് ഒഴിവാക്കാൻ, ഞങ്ങൾ രണ്ട് കാര്യങ്ങൾ ചെയ്തു:

a) ഇത് സ്വമേധയാ ചെയ്യുന്നതിൽ നിന്ന് അവർ Nginx നെ വിലക്കി - നിർഭാഗ്യവശാൽ, ഇത് ചെയ്യാനുള്ള ഒരേയൊരു മാർഗ്ഗം max fails ക്രമീകരണങ്ങൾ സജ്ജീകരിക്കുക എന്നതാണ്.

b) മറ്റ് പ്രോജക്റ്റുകളിൽ ഞങ്ങൾ പശ്ചാത്തല ആരോഗ്യ പരിശോധന നടത്താൻ അനുവദിക്കുന്ന ഒരു മൊഡ്യൂൾ ഉപയോഗിക്കുന്നുണ്ടെന്ന് ഞങ്ങൾ ഓർത്തു - അതനുസരിച്ച്, ഞങ്ങൾ പതിവായി ആരോഗ്യ പരിശോധനകൾ നടത്തിയതിനാൽ ഒരു അപകടമുണ്ടായാൽ പ്രവർത്തനരഹിതമായ സമയം കുറവായിരിക്കും.

നിർഭാഗ്യവശാൽ, ഇതും എല്ലാം അല്ല, കാരണം അക്ഷരാർത്ഥത്തിൽ ഈ സ്കീമിന്റെ ആദ്യ രണ്ടാഴ്ചത്തെ പ്രവർത്തനം TCP ആരോഗ്യ പരിശോധനയും വിശ്വസനീയമല്ലാത്ത ഒരു കാര്യമാണെന്ന് കാണിച്ചു: അപ്‌സ്ട്രീം സെർവറിൽ ഇത് Nginx അല്ലെങ്കിൽ D-state-ലെ Nginx ആയിരിക്കില്ല. ഈ സാഹചര്യത്തിൽ കേർണൽ കണക്ഷൻ സ്വീകരിക്കും, ആരോഗ്യ പരിശോധന കടന്നുപോകും, ​​പക്ഷേ പ്രവർത്തിക്കില്ല. അതിനാൽ, ഞങ്ങൾ ഇത് ഉടനടി ഹെൽത്ത് ചെക്ക് http ഉപയോഗിച്ച് മാറ്റി, ഒരു നിർദ്ദിഷ്ട ഒന്ന് ഉണ്ടാക്കി, അത് 200 നൽകുകയാണെങ്കിൽ, ഈ സ്ക്രിപ്റ്റിൽ എല്ലാം പ്രവർത്തിക്കും. നിങ്ങൾക്ക് അധിക ലോജിക് ചെയ്യാൻ കഴിയും - ഉദാഹരണത്തിന്, കാഷിംഗ് സെർവറുകളുടെ കാര്യത്തിൽ, ഫയൽ സിസ്റ്റം ശരിയായി മൌണ്ട് ചെയ്തിട്ടുണ്ടോയെന്ന് പരിശോധിക്കുക:

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

ഒരു അപ്‌സ്ട്രീമിനുള്ളിൽ മറ്റൊരു അപ്‌സ്ട്രീമിലേക്ക് പോകുന്നത് അസാധ്യമായതിനാൽ, ശരിയായതും ആവശ്യമായതുമായ ഫോട്ടോ കാഷെ ഞങ്ങൾ ലളിതമായി റെക്കോർഡുചെയ്‌ത പ്രധാന അപ്‌സ്ട്രീം ലഭ്യമല്ലെങ്കിൽ, ഞങ്ങൾ പിശക്_പേജിലൂടെ ഫാൾബാക്കിലേക്ക് പോയി. ഞങ്ങൾ ബാക്കപ്പ് അപ്‌സ്ട്രീമിലേക്ക് പോയത്:

അക്ഷരാർത്ഥത്തിൽ നാല് സെർവറുകൾ ചേർക്കുന്നതിലൂടെ, ഞങ്ങൾക്ക് ലഭിച്ചത് ഇതാണ്: ഞങ്ങൾ ലോഡിന്റെ ഒരു ഭാഗം മാറ്റി - ഞങ്ങൾ ഇത് LTM-ൽ നിന്ന് ഈ സെർവറുകളിലേക്ക് നീക്കം ചെയ്തു, സ്റ്റാൻഡേർഡ് ഹാർഡ്‌വെയറും സോഫ്റ്റ്വെയറും ഉപയോഗിച്ച് അതേ ലോജിക് അവിടെ നടപ്പിലാക്കി, ഈ സെർവറുകൾക്ക് കഴിയുന്ന ബോണസ് ഉടനടി ലഭിച്ചു. സ്കെയിൽ ചെയ്യണം, കാരണം അവ ആവശ്യമുള്ളത്ര വിതരണം ചെയ്യാൻ കഴിയും. ശരി, ബാഹ്യ ഉപയോക്താക്കൾക്കുള്ള ഉയർന്ന ലഭ്യത ഞങ്ങൾക്ക് നഷ്‌ടപ്പെട്ടു എന്നതാണ് ഒരേയൊരു നെഗറ്റീവ്. എന്നാൽ ആ നിമിഷം ഞങ്ങൾക്ക് ഇത് ത്യജിക്കേണ്ടിവന്നു, കാരണം പ്രശ്നം ഉടനടി പരിഹരിക്കേണ്ടത് ആവശ്യമാണ്. അതിനാൽ, ഞങ്ങൾ ലോഡിന്റെ ഒരു ഭാഗം നീക്കംചെയ്തു, ആ സമയത്ത് അത് ഏകദേശം 40% ആയിരുന്നു, LTM ന് നല്ലതായി തോന്നി, അക്ഷരാർത്ഥത്തിൽ പ്രശ്നം ആരംഭിച്ച് രണ്ടാഴ്ചയ്ക്ക് ശേഷം, ഞങ്ങൾ സെക്കൻഡിൽ 45k അഭ്യർത്ഥനകളല്ല, 55k അയയ്‌ക്കാൻ തുടങ്ങി. വാസ്തവത്തിൽ, ഞങ്ങൾ 20% വളർന്നു - ഇത് വ്യക്തമായും ഞങ്ങൾ ഉപയോക്താവിന് നൽകാത്ത ട്രാഫിക്കാണ്. അതിനുശേഷം, ശേഷിക്കുന്ന പ്രശ്നം എങ്ങനെ പരിഹരിക്കാമെന്ന് അവർ ചിന്തിക്കാൻ തുടങ്ങി - ഉയർന്ന ബാഹ്യ പ്രവേശനക്ഷമത ഉറപ്പാക്കാൻ.

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

ആരംഭിക്കുന്നതിന്, Keepalived എന്താണ് ഉൾക്കൊള്ളുന്നത്? ആദ്യത്തേത് നെറ്റ്‌വർക്കർമാർക്ക് പരക്കെ അറിയപ്പെടുന്ന VRRP പ്രോട്ടോക്കോൾ ആണ്, ഇത് ക്ലയന്റുകളെ ബന്ധിപ്പിക്കുന്ന ബാഹ്യ IP വിലാസത്തിന് തെറ്റ് സഹിഷ്ണുത നൽകുന്ന നെറ്റ്‌വർക്ക് ഉപകരണങ്ങളിൽ സ്ഥിതിചെയ്യുന്നു. രണ്ടാം ഭാഗം IPVS ആണ്, IP വെർച്വൽ സെർവർ, ഫോട്ടോ റൂട്ടറുകൾക്കിടയിൽ ബാലൻസ് ചെയ്യുന്നതിനും ഈ ലെവലിൽ തെറ്റ് സഹിഷ്ണുത ഉറപ്പാക്കുന്നതിനും. മൂന്നാമത്തേത് - ആരോഗ്യ പരിശോധനകൾ.

ആദ്യ ഭാഗത്തിൽ നിന്ന് നമുക്ക് ആരംഭിക്കാം: VRRP - അത് എങ്ങനെയിരിക്കും? ക്ലയന്റുകളെ ബന്ധിപ്പിക്കുന്ന dns badoocdn.com-ൽ ഒരു പ്രത്യേക വെർച്വൽ ഐപി ഉണ്ട്. ചില സമയങ്ങളിൽ, ഒരു സെർവറിൽ ഞങ്ങൾക്ക് ഒരു IP വിലാസമുണ്ട്. വിആർആർപി പ്രോട്ടോക്കോൾ ഉപയോഗിച്ച് സെർവറുകൾക്കിടയിൽ കീപാലിവ്ഡ് പാക്കറ്റുകൾ പ്രവർത്തിക്കുന്നു, റഡാറിൽ നിന്ന് മാസ്റ്റർ അപ്രത്യക്ഷമായാൽ - സെർവർ റീബൂട്ട് ചെയ്‌തോ മറ്റെന്തെങ്കിലുമോ, ബാക്കപ്പ് സെർവർ ഈ ഐപി വിലാസം സ്വയമേവ എടുക്കുന്നു - മാനുവൽ പ്രവർത്തനങ്ങളൊന്നും ആവശ്യമില്ല. മാസ്റ്ററും ബാക്കപ്പും തമ്മിലുള്ള വ്യത്യാസം പ്രധാനമായും മുൻഗണനയാണ്: അത് ഉയർന്നതാണ്, മെഷീൻ ഒരു മാസ്റ്ററാകാനുള്ള സാധ്യത കൂടുതലാണ്. നിങ്ങൾ സെർവറിൽ തന്നെ IP വിലാസങ്ങൾ കോൺഫിഗർ ചെയ്യേണ്ടതില്ല എന്നതാണ് ഒരു വലിയ നേട്ടം, കോൺഫിഗറിൽ അവ വിവരിച്ചാൽ മതിയാകും, കൂടാതെ IP വിലാസങ്ങൾക്ക് ചില ഇഷ്‌ടാനുസൃത റൂട്ടിംഗ് നിയമങ്ങൾ ആവശ്യമാണെങ്കിൽ, ഇത് കോൺഫിഗറിൽ നേരിട്ട് വിവരിച്ചിരിക്കുന്നു, VRRP പാക്കേജിൽ വിവരിച്ചിരിക്കുന്ന അതേ വാക്യഘടന. നിങ്ങൾക്ക് അപരിചിതമായ കാര്യങ്ങളൊന്നും നേരിടേണ്ടി വരില്ല.

ഇത് പ്രായോഗികമായി എങ്ങനെ കാണപ്പെടുന്നു? സെർവറുകളിൽ ഒന്ന് പരാജയപ്പെട്ടാൽ എന്ത് സംഭവിക്കും? മാസ്റ്റർ അപ്രത്യക്ഷമായാലുടൻ, ഞങ്ങളുടെ ബാക്കപ്പ് പരസ്യങ്ങൾ സ്വീകരിക്കുന്നത് നിർത്തുകയും സ്വയമേവ ഒരു മാസ്റ്ററായി മാറുകയും ചെയ്യും. കുറച്ച് സമയത്തിന് ശേഷം, ഞങ്ങൾ മാസ്റ്റർ റിപ്പയർ ചെയ്തു, റീബൂട്ട് ചെയ്തു, Keepalived ഉയർത്തി - പരസ്യങ്ങൾ ബാക്കപ്പിനെക്കാൾ ഉയർന്ന മുൻ‌ഗണനയോടെ എത്തുന്നു, കൂടാതെ ബാക്കപ്പ് യാന്ത്രികമായി പിന്നിലേക്ക് തിരിയുന്നു, IP വിലാസങ്ങൾ നീക്കംചെയ്യുന്നു, സ്വമേധയാലുള്ള പ്രവർത്തനങ്ങളൊന്നും ചെയ്യേണ്ടതില്ല.

അതിനാൽ, ബാഹ്യ ഐപി വിലാസത്തിന്റെ തെറ്റ് സഹിഷ്ണുത ഞങ്ങൾ ഉറപ്പാക്കിയിട്ടുണ്ട്. എക്‌സ്‌റ്റേണൽ ഐപി അഡ്രസ് മുതൽ ഇതിനകം അവസാനിപ്പിക്കുന്ന ഫോട്ടോ റൂട്ടറുകളിലേക്കുള്ള ട്രാഫിക് എങ്ങനെയെങ്കിലും സന്തുലിതമാക്കുക എന്നതാണ് അടുത്ത ഭാഗം. ബാലൻസിങ് പ്രോട്ടോക്കോളുകൾ ഉപയോഗിച്ച് എല്ലാം വളരെ വ്യക്തമാണ്. ഇത് ഒന്നുകിൽ ഒരു ലളിതമായ റൗണ്ട് റോബിൻ, അല്ലെങ്കിൽ കുറച്ചുകൂടി സങ്കീർണ്ണമായ കാര്യങ്ങൾ, wrr, ലിസ്റ്റ് കണക്ഷൻ തുടങ്ങിയവയാണ്. ഇത് അടിസ്ഥാനപരമായി ഡോക്യുമെന്റേഷനിൽ വിവരിച്ചിരിക്കുന്നു, പ്രത്യേകമായി ഒന്നുമില്ല. എന്നാൽ ഡെലിവറി രീതി... എന്തിനാണ് ഞങ്ങൾ അവയിലൊന്ന് തിരഞ്ഞെടുത്തതെന്ന് ഇവിടെ ഞങ്ങൾ പരിശോധിക്കും. NAT, Direct Routing, TUN എന്നിവയാണ് ഇവ. സൈറ്റുകളിൽ നിന്ന് 100 ജിഗാബൈറ്റ് ട്രാഫിക് നൽകാൻ ഞങ്ങൾ ഉടൻ പദ്ധതിയിട്ടിരുന്നു എന്നതാണ് വസ്തുത. നിങ്ങൾ കണക്കാക്കുകയാണെങ്കിൽ, നിങ്ങൾക്ക് 10 ജിഗാബിറ്റ് കാർഡുകൾ ആവശ്യമാണ്, അല്ലേ? ഒരു സെർവറിലെ 10 ജിഗാബിറ്റ് കാർഡുകൾ ഇതിനകം തന്നെ ഞങ്ങളുടെ "സാധാരണ ഉപകരണങ്ങൾ" എന്ന ആശയത്തിന്റെ പരിധിക്കപ്പുറമാണ്. അപ്പോൾ ഞങ്ങൾ ഓർത്തു, ഞങ്ങൾ കുറച്ച് ട്രാഫിക്ക് മാത്രമല്ല, ഫോട്ടോകളും നൽകുന്നു.

എന്താണ് പ്രത്യേകത? - ഇൻകമിംഗ്, ഔട്ട്ഗോയിംഗ് ട്രാഫിക്ക് തമ്മിലുള്ള വലിയ വ്യത്യാസം. ഇൻകമിംഗ് ട്രാഫിക് വളരെ ചെറുതാണ്, ഔട്ട്ഗോയിംഗ് ട്രാഫിക് വളരെ വലുതാണ്:

ഈ ഗ്രാഫുകൾ പരിശോധിച്ചാൽ, ഇപ്പോൾ സംവിധായകന് സെക്കൻഡിൽ 200 എംബി ലഭിക്കുന്നത് വളരെ സാധാരണമായ ദിവസമാണെന്ന് നിങ്ങൾക്ക് കാണാൻ കഴിയും. ഞങ്ങൾ സെക്കൻഡിൽ 4,500 MB തിരികെ നൽകുന്നു, ഞങ്ങളുടെ അനുപാതം ഏകദേശം 1/22 ആണ്. 22 വർക്കർ സെർവറുകളിലേക്ക് ഔട്ട്‌ഗോയിംഗ് ട്രാഫിക് പൂർണ്ണമായും നൽകുന്നതിന്, ഈ കണക്ഷൻ സ്വീകരിക്കുന്ന ഒന്ന് മാത്രമേ ഞങ്ങൾക്ക് ആവശ്യമുള്ളൂ എന്നത് ഇതിനകം തന്നെ വ്യക്തമാണ്. ഇവിടെയാണ് നേരിട്ടുള്ള റൂട്ടിംഗ് അൽഗോരിതം നമ്മുടെ സഹായത്തിനെത്തുന്നത്.

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

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

ഞങ്ങൾ മധ്യത്തിൽ എവിടെയോ നിർത്തി: ഞങ്ങൾക്ക് ഒരു പ്രത്യേക സ്ഥലത്തേക്ക് ഒരു https അഭ്യർത്ഥനയുണ്ട്, സ്‌ക്രിപ്റ്റ് എന്ന് വിളിക്കപ്പെടുന്നു, അത് 200-ാമത്തെ പ്രതികരണത്തോടെ പ്രതികരിക്കുകയാണെങ്കിൽ, ഈ സെർവറിൽ എല്ലാം ശരിയാണെന്നും അത് സജീവമാണെന്നും അത് പൂർണ്ണമായും ഓണാക്കാമെന്നും ഞങ്ങൾ വിശ്വസിക്കുന്നു. എളുപ്പത്തിൽ.

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

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

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

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

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

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

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