ഡാറ്റാ സെന്ററിന്റെ പുക പരിശോധനയ്ക്ക് തീപിടിച്ചാൽ സെർവറുകൾ കെടുത്തണമോ?

ഒരു നല്ല വേനൽക്കാല ദിവസം നിങ്ങളുടെ ഉപകരണങ്ങളുള്ള ഡാറ്റാ സെന്റർ ഇതുപോലെ കാണപ്പെട്ടാൽ നിങ്ങൾക്ക് എന്തു തോന്നും?

എല്ലാവർക്കും ഹായ്! എന്റെ പേര് ദിമിത്രി സാംസോനോവ്, ഞാൻ ഒരു പ്രമുഖ സിസ്റ്റം അഡ്മിനിസ്ട്രേറ്ററായി പ്രവർത്തിക്കുന്നു "സഹപാഠികൾ" ഞങ്ങളുടെ പ്രോജക്റ്റ് നൽകുന്ന ഉപകരണങ്ങൾ ഇൻസ്റ്റാൾ ചെയ്തിരിക്കുന്ന നാല് ഡാറ്റാ സെന്ററുകളിൽ ഒന്ന് ഫോട്ടോ കാണിക്കുന്നു. ഈ മതിലുകൾക്ക് പിന്നിൽ ഏകദേശം 4 ആയിരം ഉപകരണങ്ങളുണ്ട്: സെർവറുകൾ, ഡാറ്റ സ്റ്റോറേജ് സിസ്റ്റങ്ങൾ, നെറ്റ്‌വർക്ക് ഉപകരണങ്ങൾ മുതലായവ. - ഞങ്ങളുടെ എല്ലാ ഉപകരണങ്ങളിലും ഏകദേശം ⅓.
മിക്ക സെർവറുകളും Linux ആണ്. വിൻഡോസിൽ (MS SQL) നിരവധി ഡസൻ സെർവറുകളുണ്ട് - ഞങ്ങളുടെ പൈതൃകം, ഞങ്ങൾ വർഷങ്ങളായി വ്യവസ്ഥാപിതമായി ഉപേക്ഷിക്കുന്നു.
അതിനാൽ, 5 ജൂൺ 2019-ന് 14:35-ന്, ഞങ്ങളുടെ ഡാറ്റാ സെന്ററുകളിലൊന്നിലെ എഞ്ചിനീയർമാർ ഒരു ഫയർ അലാറം റിപ്പോർട്ട് ചെയ്തു.

നിരസിക്കൽ

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

ദേഷ്യം

നിങ്ങൾ എപ്പോഴെങ്കിലും അഗ്നിശമന സേനാംഗങ്ങളിൽ നിന്ന് മേൽക്കൂരയിൽ എവിടെയാണ് തീപിടുത്തമുണ്ടായതെന്ന് കണ്ടെത്താൻ ശ്രമിച്ചിട്ടുണ്ടോ, അല്ലെങ്കിൽ സാഹചര്യം വിലയിരുത്തുന്നതിന് സ്വയം കത്തുന്ന മേൽക്കൂരയിൽ കയറാൻ ശ്രമിച്ചിട്ടുണ്ടോ? അഞ്ചുപേരിലൂടെ ലഭിക്കുന്ന വിവരങ്ങളുടെ വിശ്വാസ്യത എത്രയായിരിക്കും?

XXX: 14. തീ ശീതീകരണ സംവിധാനത്തിലേക്ക് അടുക്കുന്നതായി വിവരം ലഭിച്ചിട്ടുണ്ട്. പക്ഷേ വരുമോ? ഡ്യൂട്ടിയിലുള്ള സിസ്റ്റം അഡ്‌മിനിസ്‌ട്രേറ്റർ ഈ ഡാറ്റാ സെന്ററിന്റെ മുൻഭാഗങ്ങളിൽ നിന്ന് ബാഹ്യ ട്രാഫിക് നീക്കംചെയ്യുന്നു.

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

തീ ഇതുവരെ ഞങ്ങളെ ഒരു തരത്തിലും ബാധിച്ചിട്ടില്ല - ഉപയോക്താക്കൾക്കോ ​​ഉപകരണങ്ങൾക്കോ ​​കേടുപാടുകൾ സംഭവിച്ചിട്ടില്ല. ഇതൊരു അപകടമാണോ? "ആക്‌സിഡന്റ് ആക്ഷൻ പ്ലാൻ" എന്ന പ്രമാണത്തിന്റെ ആദ്യ വിഭാഗം "അപകടം" എന്ന ആശയത്തെ നിർവചിക്കുന്നു, വിഭാഗം ഇതുപോലെ അവസാനിക്കുന്നു:
«അപകടമുണ്ടോ ഇല്ലയോ എന്ന് സംശയം തോന്നിയാൽ അത് അപകടമാണ്!»

14:53. അടിയന്തര കോർഡിനേറ്ററെ നിയമിച്ചിട്ടുണ്ട്.

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

വിലപേശൽ

15:01. ഉൽപ്പാദനവുമായി ബന്ധമില്ലാത്ത സെർവറുകൾ ഞങ്ങൾ പ്രവർത്തനരഹിതമാക്കാൻ തുടങ്ങുന്നു.
15:03. റിസർവ് ചെയ്ത എല്ലാ സേവനങ്ങളും ഞങ്ങൾ ശരിയായി ഓഫാക്കുന്നു.
ഇതിൽ ഫ്രണ്ടുകളും (ഈ ഘട്ടത്തിൽ ഉപയോക്താക്കൾ ഇനി ആക്‌സസ് ചെയ്യാത്ത) അവരുടെ സഹായ സേവനങ്ങളും (ബിസിനസ് ലോജിക്, കാഷെകൾ മുതലായവ) മാത്രമല്ല, റെപ്ലിക്കേഷൻ ഫാക്ടർ 2 അല്ലെങ്കിൽ അതിൽ കൂടുതലുള്ള വിവിധ ഡാറ്റാബേസുകളും ഉൾപ്പെടുന്നു (ചേട്ടനാണു, ബൈനറി ഡാറ്റ സംഭരണം, ശീതസംഭരണി, ന്യൂഎസ്‌ക്യുഎൽ തുടങ്ങിയവ.).
XXX: 15. ഡാറ്റാ സെന്റർ ഹാളുകളിൽ ഒന്നിന് തീപിടിത്തം ഭീഷണിയാകുന്നതായി വിവരം ലഭിച്ചിട്ടുണ്ട്. ഈ മുറിയിൽ ഞങ്ങൾക്ക് ഉപകരണങ്ങളില്ല, എന്നാൽ മേൽക്കൂരയിൽ നിന്ന് ഹാളുകളിലേക്ക് തീ പടരുമെന്നത് എന്താണ് സംഭവിക്കുന്നതെന്നതിന്റെ ചിത്രത്തെ വളരെയധികം മാറ്റുന്നു.
(പിന്നീട് മനസ്സിലായി, ഹാളിന് ശാരീരികമായ ഒരു ഭീഷണിയുമില്ല, കാരണം അത് മേൽക്കൂരയിൽ നിന്ന് ഹെർമെറ്റിക് ആയി അടച്ചിരുന്നു. ഈ ഹാളിന്റെ ശീതീകരണ സംവിധാനത്തിന് മാത്രമാണ് ഭീഷണി.)
15:07. അധിക പരിശോധനകളില്ലാതെ ത്വരിതപ്പെടുത്തിയ മോഡിൽ സെർവറുകളിൽ കമാൻഡ് എക്‌സിക്യൂഷൻ ഞങ്ങൾ അനുവദിക്കുന്നു (ഞങ്ങളുടെ പ്രിയപ്പെട്ട കാൽക്കുലേറ്റർ ഇല്ലാതെ).
15:08. ഹാളുകളിലെ താപനില സാധാരണ പരിധിക്കുള്ളിലാണ്.
XXX: 15. ഹാളുകളിൽ താപനിലയിൽ വർദ്ധനവ് രേഖപ്പെടുത്തി.
15:13. ഡാറ്റാ സെന്ററിലെ പകുതിയിലധികം സെർവറുകളും ഓഫാണ്. നമുക്ക് തുടരാം.
15:16. എല്ലാ ഉപകരണങ്ങളും ഓഫ് ചെയ്യാൻ തീരുമാനിച്ചു.
15:21. ആപ്ലിക്കേഷനും ഓപ്പറേറ്റിംഗ് സിസ്റ്റവും ശരിയായി ഷട്ട് ഡൗൺ ചെയ്യാതെ ഞങ്ങൾ സ്‌റ്റേറ്റ്‌ലെസ് സെർവറുകളിലേക്ക് പവർ ഓഫ് ചെയ്യാൻ തുടങ്ങുന്നു.
15:23. MS SQL-ന് ഉത്തരവാദിത്തമുള്ള ഒരു കൂട്ടം ആളുകളെ അനുവദിച്ചിരിക്കുന്നു (അവരിൽ കുറച്ച് പേരുണ്ട്, അവയിൽ സേവനങ്ങളെ ആശ്രയിക്കുന്നത് വലിയ കാര്യമല്ല, പക്ഷേ പ്രവർത്തനം പുനഃസ്ഥാപിക്കുന്നതിനുള്ള നടപടിക്രമം കൂടുതൽ സമയമെടുക്കും, ഉദാഹരണത്തിന്, കസാന്ദ്രയേക്കാൾ സങ്കീർണ്ണവുമാണ്).

വിഷാദം

XXX: 15. 16ൽ നാല് ഹാളുകളിലും (നമ്പർ 6, 7, 8, 9) വൈദ്യുതി ഓഫാക്കിയതായി വിവരം ലഭിച്ചു. ഞങ്ങളുടെ ഉപകരണങ്ങൾ 7, 8 ഹാളുകളിൽ സ്ഥിതിചെയ്യുന്നു. ഞങ്ങളുടെ രണ്ട് ഹാളുകളെ കുറിച്ച് ഒരു വിവരവുമില്ല (നമ്പർ 1 ഉം 3 ഉം).
സാധാരണയായി, തീപിടുത്ത സമയത്ത്, വൈദ്യുതി വിതരണം ഉടനടി ഓഫാകും, എന്നാൽ ഈ സാഹചര്യത്തിൽ, അഗ്നിശമന സേനാംഗങ്ങളുടെയും ഡാറ്റാ സെന്ററിലെ സാങ്കേതിക ഉദ്യോഗസ്ഥരുടെയും യോജിച്ച പ്രവർത്തനത്തിന് നന്ദി, ഇത് എല്ലായിടത്തും ഓഫാക്കിയില്ല, ഉടനടി അല്ല, പക്ഷേ ആവശ്യാനുസരണം.
(8, 9 ഹാളുകളിൽ വൈദ്യുതി ഓഫാക്കിയിട്ടില്ലെന്ന് പിന്നീട് കണ്ടെത്തി.)
15:28. മറ്റ് ഡാറ്റാ സെന്ററുകളിലെ ബാക്കപ്പുകളിൽ നിന്ന് ഞങ്ങൾ MS SQL ഡാറ്റാബേസുകൾ വിന്യസിക്കാൻ തുടങ്ങുന്നു.
ഇതിന് എത്ര സമയമെടുക്കും? മുഴുവൻ റൂട്ടിനും മതിയായ നെറ്റ്‌വർക്ക് കപ്പാസിറ്റി ഉണ്ടോ?
XXX: 15. നെറ്റ്‌വർക്കിന്റെ ചില ഭാഗങ്ങളുടെ ഷട്ട്ഡൗൺ രേഖപ്പെടുത്തി.
മാനേജ്മെന്റും ഉൽപ്പാദന ശൃംഖലയും പരസ്പരം ശാരീരികമായി ഒറ്റപ്പെട്ടിരിക്കുന്നു. പ്രൊഡക്ഷൻ നെറ്റ്‌വർക്ക് ലഭ്യമാണെങ്കിൽ, നിങ്ങൾക്ക് സെർവറിലേക്ക് പോകാം, ആപ്ലിക്കേഷൻ നിർത്തി OS ഓഫ് ചെയ്യുക. ഇത് ലഭ്യമല്ലെങ്കിൽ, നിങ്ങൾക്ക് IPMI വഴി ലോഗിൻ ചെയ്യാനും ആപ്ലിക്കേഷൻ നിർത്തി ഒഎസ് ഓഫാക്കാനും കഴിയും. നെറ്റ്‌വർക്കുകളൊന്നും ഇല്ലെങ്കിൽ, നിങ്ങൾക്ക് ഒന്നും ചെയ്യാൻ കഴിയില്ല. "നന്ദി, ക്യാപ്!", നിങ്ങൾ ചിന്തിക്കും.
“പൊതുവേ, ധാരാളം പ്രക്ഷുബ്ധതയുണ്ട്,” നിങ്ങൾ ചിന്തിച്ചേക്കാം.
തീ ഇല്ലെങ്കിലും സെർവറുകൾ വലിയ അളവിൽ ചൂട് സൃഷ്ടിക്കുന്നു എന്നതാണ് കാര്യം. കൂടുതൽ കൃത്യമായി പറഞ്ഞാൽ, കൂളിംഗ് ഉണ്ടാകുമ്പോൾ, അവ താപം സൃഷ്ടിക്കുന്നു, തണുപ്പ് ഇല്ലാതിരിക്കുമ്പോൾ, അവ ഒരു നരക നരകം സൃഷ്ടിക്കുന്നു, അത് ഏറ്റവും മികച്ചത്, ഉപകരണത്തിന്റെ ഒരു ഭാഗം ഉരുകുകയും മറ്റൊരു ഭാഗം ഓഫ് ചെയ്യുകയും ചെയ്യും, ഏറ്റവും മോശം ... ഹാളിനുള്ളിലെ തീ, എല്ലാം നശിപ്പിക്കുമെന്ന് മിക്കവാറും ഉറപ്പുനൽകുന്നു.

15:39. conf ഡാറ്റാബേസിലെ പ്രശ്നങ്ങൾ ഞങ്ങൾ പരിഹരിക്കുന്നു.

ക്രമീകരണങ്ങൾ വേഗത്തിൽ മാറ്റാൻ എല്ലാ പ്രൊഡക്ഷൻ ആപ്ലിക്കേഷനുകളും ഉപയോഗിക്കുന്ന അതേ പേരിലുള്ള സേവനത്തിന്റെ ബാക്കെൻഡാണ് conf ഡാറ്റാബേസ്. ഈ അടിസ്ഥാനമില്ലാതെ, പോർട്ടലിന്റെ പ്രവർത്തനം നിയന്ത്രിക്കാൻ ഞങ്ങൾക്ക് കഴിയില്ല, എന്നാൽ പോർട്ടലിന് തന്നെ പ്രവർത്തിക്കാൻ കഴിയും.

15:41. കോർ നെറ്റ്‌വർക്ക് ഉപകരണത്തിലെ താപനില സെൻസറുകൾ അനുവദനീയമായ പരമാവധി റീഡിംഗുകൾ രേഖപ്പെടുത്തുന്നു. ഒരു മുഴുവൻ റാക്കും ഉൾക്കൊള്ളുന്ന ഒരു ബോക്സാണിത്, കൂടാതെ ഡാറ്റാ സെന്ററിനുള്ളിലെ എല്ലാ നെറ്റ്‌വർക്കുകളുടെയും പ്രവർത്തനം ഉറപ്പാക്കുന്നു.

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

ദത്തെടുക്കൽ

15:51. MS SQL ഒഴികെയുള്ള എല്ലാ സെർവറുകളും ശരിയായി ഷട്ട് ഡൗൺ ചെയ്യാതെ IPMI വഴി ഓഫാക്കി.
ആവശ്യമെങ്കിൽ IPMI വഴി വലിയ സെർവർ മാനേജ്മെന്റിന് നിങ്ങൾ തയ്യാറാണോ?

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

പുനരധിവാസം

18:02. നമ്പർ 8 (നമ്മുടേത്), 9, 10, 11 ഹാളുകളിൽ താപനില സ്ഥിരത കൈവരിച്ചു. ഓഫ്‌ലൈനായി തുടരുന്ന ഒന്നിൽ (നമ്പർ 7) ഞങ്ങളുടെ ഉപകരണങ്ങൾ ഉണ്ട്, അവിടെ താപനില ഉയരുന്നത് തുടരുന്നു.
18:31. നമ്പർ 1, 3 ഹാളുകളിൽ ഉപകരണങ്ങൾ ആരംഭിക്കാൻ അവർ അനുമതി നൽകി - ഈ ഹാളുകളെ തീ ബാധിച്ചില്ല.

നിലവിൽ, ഏറ്റവും നിർണായകമായവയിൽ തുടങ്ങി 1, 3, 8 ഹാളുകളിൽ സെർവറുകൾ ലോഞ്ച് ചെയ്യുന്നു. പ്രവർത്തിക്കുന്ന എല്ലാ സേവനങ്ങളുടെയും ശരിയായ പ്രവർത്തനം പരിശോധിച്ചു. ഹാൾ നമ്പർ 7 ന് ഇപ്പോഴും പ്രശ്നങ്ങൾ ഉണ്ട്.

18:44. റൂം നമ്പർ 7 ൽ (ഞങ്ങളുടെ ഉപകരണങ്ങൾ മാത്രം സ്ഥിതി ചെയ്യുന്ന) പല സെർവറുകളും ഓഫാക്കിയിട്ടില്ലെന്ന് ഡാറ്റാ സെന്ററിലെ സാങ്കേതിക ജീവനക്കാർ കണ്ടെത്തി. ഞങ്ങളുടെ ഡാറ്റ അനുസരിച്ച്, 26 സെർവറുകൾ അവിടെ ഓൺലൈനിൽ തുടരുന്നു. രണ്ടാമത്തെ പരിശോധനയ്ക്ക് ശേഷം, ഞങ്ങൾ 58 സെർവറുകൾ കണ്ടെത്തുന്നു.
20:18. ഡാറ്റാ സെന്റർ ടെക്നീഷ്യൻമാർ ഇടനാഴികളിലൂടെ കടന്നുപോകുന്ന മൊബൈൽ നാളങ്ങളിലൂടെ എയർകണ്ടീഷൻ ചെയ്ത മുറിയിലൂടെ വായു വീശുന്നു.
23:08. ആദ്യത്തെ അഡ്മിനെ വീട്ടിലേക്ക് അയച്ചു. നാളെ ജോലി തുടരാൻ ആരെങ്കിലും രാത്രി ഉറങ്ങണം. അടുത്തതായി, ഞങ്ങൾ കുറച്ച് അഡ്മിൻമാരെയും ഡവലപ്പർമാരെയും വിടും.
02:56. വിക്ഷേപിക്കാൻ കഴിയുന്നതെല്ലാം ഞങ്ങൾ വിക്ഷേപിച്ചു. ഓട്ടോമാറ്റിക് ടെസ്റ്റുകൾ ഉപയോഗിച്ച് ഞങ്ങൾ എല്ലാ സേവനങ്ങളും വളരെയധികം പരിശോധിക്കുന്നു.

03:02. കഴിഞ്ഞ, ഏഴാമത്തെ ഹാളിലെ എയർ കണ്ടീഷനിംഗ് പുനഃസ്ഥാപിച്ചു.
03:36. ഞങ്ങൾ ഡാറ്റാ സെന്ററിലെ ഫ്രണ്ടുകളെ DNS-ൽ റൊട്ടേഷനിലേക്ക് കൊണ്ടുവന്നു. ഈ നിമിഷം മുതൽ ഉപയോക്തൃ ട്രാഫിക് എത്താൻ തുടങ്ങുന്നു.
ഞങ്ങൾ മിക്ക അഡ്മിനിസ്ട്രേറ്റീവ് ടീമിനെയും വീട്ടിലേക്ക് അയയ്ക്കുന്നു. എന്നാൽ ഞങ്ങൾ കുറച്ച് ആളുകളെ പിന്നിലാക്കുന്നു.

ചെറിയ പതിവ് ചോദ്യങ്ങൾ:
ചോദ്യം: 18:31 മുതൽ 02:56 വരെ എന്താണ് സംഭവിച്ചത്?
ഉത്തരം: “ദുരന്ത പ്രവർത്തന പദ്ധതി” പിന്തുടർന്ന്, ഏറ്റവും പ്രധാനപ്പെട്ടവയിൽ തുടങ്ങി എല്ലാ സേവനങ്ങളും ഞങ്ങൾ സമാരംഭിക്കുന്നു. ഈ സാഹചര്യത്തിൽ, ചാറ്റിലെ കോർഡിനേറ്റർ ഒരു സൗജന്യ അഡ്മിനിസ്ട്രേറ്റർക്ക് സേവനം നൽകുന്നു, OS ഉം ആപ്ലിക്കേഷനും ആരംഭിച്ചിട്ടുണ്ടോ, എന്തെങ്കിലും പിശകുകൾ ഉണ്ടോ, സൂചകങ്ങൾ സാധാരണമാണോ എന്ന് പരിശോധിക്കുന്നു. ലോഞ്ച് പൂർത്തിയായ ശേഷം, താൻ സ്വതന്ത്രനാണെന്നും കോർഡിനേറ്ററിൽ നിന്ന് ഒരു പുതിയ സേവനം സ്വീകരിക്കുന്നുവെന്നും അദ്ദേഹം ചാറ്റിലേക്ക് റിപ്പോർട്ട് ചെയ്യുന്നു.
ഹാർഡ്‌വെയർ പരാജയപ്പെട്ടതിനാൽ പ്രക്രിയ കൂടുതൽ മന്ദഗതിയിലാകുന്നു. OS നിർത്തുകയും സെർവറുകൾ ഷട്ട് ഡൗൺ ചെയ്യുകയും ചെയ്താൽ പോലും, ഡിസ്കുകൾ, മെമ്മറി, ഷാസിസ് എന്നിവയുടെ പെട്ടെന്നുള്ള തകരാർ കാരണം ചില സെർവറുകൾ തിരികെ വരുന്നില്ല. വൈദ്യുതി നഷ്ടപ്പെടുമ്പോൾ, പരാജയ നിരക്ക് വർദ്ധിക്കുന്നു.
ചോദ്യം: എന്തുകൊണ്ടാണ് നിങ്ങൾക്ക് എല്ലാം ഒറ്റയടിക്ക് പ്രവർത്തിപ്പിച്ച് മോണിറ്ററിംഗിൽ വരുന്ന കാര്യങ്ങൾ പരിഹരിക്കാൻ കഴിയാത്തത്?
എ: എല്ലാം ക്രമേണ ചെയ്യണം, കാരണം സേവനങ്ങൾക്കിടയിൽ ഡിപൻഡൻസികൾ ഉണ്ട്. നിരീക്ഷണത്തിനായി കാത്തിരിക്കാതെ എല്ലാം ഉടനടി പരിശോധിക്കണം - കാരണം പ്രശ്നങ്ങൾ വഷളാകുന്നതുവരെ കാത്തിരിക്കാതെ ഉടനടി കൈകാര്യം ചെയ്യുന്നതാണ് നല്ലത്.

7:40. അവസാന അഡ്മിൻ (കോർഡിനേറ്റർ) ഉറങ്ങാൻ പോയി. ആദ്യ ദിവസത്തെ ജോലികൾ പൂർത്തിയായി.
8:09. ആദ്യ ഡെവലപ്പർമാർ, ഡാറ്റാ സെന്റർ എഞ്ചിനീയർമാർ, അഡ്മിനിസ്ട്രേറ്റർമാർ (പുതിയ കോ-ഓർഡിനേറ്റർ ഉൾപ്പെടെ) പുനഃസ്ഥാപന പ്രവർത്തനങ്ങൾ ആരംഭിച്ചു.
09:37. ഞങ്ങൾ ഹാൾ നമ്പർ 7 (അവസാനത്തേത്) ഉയർത്താൻ തുടങ്ങി.
അതേ സമയം, മറ്റ് മുറികളിൽ ശരിയാക്കാത്തവ ഞങ്ങൾ പുനഃസ്ഥാപിക്കുന്നത് തുടരുന്നു: ഡിസ്കുകൾ/മെമ്മറി/സെർവറുകൾ മാറ്റിസ്ഥാപിക്കൽ, നിരീക്ഷണത്തിൽ "കത്തുന്ന" എല്ലാം ശരിയാക്കുക, മാസ്റ്റർ-സ്റ്റാൻഡ്ബൈ സ്കീമുകളിലും മറ്റ് ചെറിയ കാര്യങ്ങളിലും റോളുകൾ തിരികെ മാറ്റുക. എന്നിരുന്നാലും ധാരാളം.
17:08. ഉൽപ്പാദനത്തോടൊപ്പം എല്ലാ പതിവ് ജോലികളും ഞങ്ങൾ അനുവദിക്കുന്നു.
21:45. രണ്ടാം ദിവസത്തെ പണി പൂർത്തിയായി.
09:45. ഇന്ന് വെള്ളിയാഴ്ചയാണ്. നിരീക്ഷണത്തിൽ ഇപ്പോഴും ചില ചെറിയ പ്രശ്നങ്ങളുണ്ട്. വാരാന്ത്യം മുന്നിലാണ്, എല്ലാവരും വിശ്രമിക്കാൻ ആഗ്രഹിക്കുന്നു. ഞങ്ങൾക്ക് കഴിയുന്നതെല്ലാം ഞങ്ങൾ വൻതോതിൽ നന്നാക്കുന്നത് തുടരുന്നു. മാറ്റിവെക്കാൻ സാധ്യതയുള്ള പതിവ് അഡ്മിൻ ജോലികൾ മാറ്റിവച്ചു. കോർഡിനേറ്റർ പുതിയതാണ്.
15:40. മറ്റൊരു ഡാറ്റാ സെന്ററിലെ കോർ നെറ്റ്‌വർക്ക് ഉപകരണ സ്റ്റാക്കിന്റെ പകുതിയും പെട്ടെന്ന് പുനരാരംഭിച്ചു. അപകടസാധ്യതകൾ കുറയ്ക്കുന്നതിന് മുൻഭാഗങ്ങൾ ഭ്രമണത്തിൽ നിന്ന് പുറത്തെടുത്തു. ഉപയോക്താക്കൾക്ക് ഒരു ഫലവുമില്ല. ഇത് കേടായ ഷാസിയാണെന്ന് പിന്നീട് തെളിഞ്ഞു. ഒരേസമയം രണ്ട് അപകടങ്ങൾ പരിഹരിക്കുന്നതിനുള്ള പ്രവർത്തനത്തിലാണ് കോ-ഓർഡിനേറ്റർ.
17:17. മറ്റൊരു ഡാറ്റാ സെന്ററിലെ നെറ്റ്‌വർക്ക് പ്രവർത്തനം പുനഃസ്ഥാപിച്ചു, എല്ലാം പരിശോധിച്ചു. ഡാറ്റാ സെന്റർ റൊട്ടേഷനിൽ സ്ഥാപിച്ചിരിക്കുന്നു.
18:29. മൂന്നാം ദിവസത്തെ ജോലിയും, പൊതുവേ, അപകടത്തിന് ശേഷമുള്ള പുനഃസ്ഥാപനവും പൂർത്തിയായി.

Afterword

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

നിലവിലെ അപകടവും 404 ഉം തമ്മിലുള്ള പ്രധാന വ്യത്യാസങ്ങൾ എന്തൊക്കെയാണ്?

• ഞങ്ങൾക്ക് ഒരു "അപകട പ്രവർത്തന പദ്ധതി" ഉണ്ട്. ഒരു പാദത്തിലൊരിക്കൽ, ഞങ്ങൾ വ്യായാമങ്ങൾ നടത്തുന്നു - ഒരു അടിയന്തര സാഹചര്യം ഞങ്ങൾ റോൾ പ്ലേ ചെയ്യുന്നു, അത് ഒരു കൂട്ടം അഡ്മിനിസ്ട്രേറ്റർമാർ (എല്ലാവരും) "അടിയന്തര പ്രവർത്തന പദ്ധതി" ഉപയോഗിച്ച് ഇല്ലാതാക്കണം. മുൻനിര സിസ്റ്റം അഡ്മിനിസ്ട്രേറ്റർമാർ കോർഡിനേറ്ററുടെ റോൾ മാറിമാറി കളിക്കുന്നു.
• ത്രൈമാസികമായി, ടെസ്റ്റ് മോഡിൽ, LAN, WAN നെറ്റ്‌വർക്കുകൾ വഴി ഞങ്ങൾ ഡാറ്റാ സെന്ററുകളെ (എല്ലാം) ഒറ്റപ്പെടുത്തുന്നു, ഇത് തടസ്സങ്ങൾ ഉടനടി തിരിച്ചറിയാൻ ഞങ്ങളെ അനുവദിക്കുന്നു.
• ഞങ്ങൾ മാനദണ്ഡങ്ങൾ കർശനമാക്കിയതിനാൽ കുറച്ച് തകർന്ന ഡിസ്കുകൾ: കുറച്ച് പ്രവർത്തന സമയം, SMART-ന് കർശനമായ പരിധി,
• സെർവർ പുനരാരംഭിച്ചതിന് ശേഷം വീണ്ടെടുക്കാൻ വളരെയധികം സമയം ആവശ്യമായ പഴയതും അസ്ഥിരവുമായ ഡാറ്റാബേസായ BerkeleyDB ഞങ്ങൾ പൂർണ്ണമായും ഉപേക്ഷിച്ചു.
• MS SQL ഉള്ള സെർവറുകളുടെ എണ്ണം ഞങ്ങൾ കുറയ്ക്കുകയും ശേഷിക്കുന്നവയെ ആശ്രയിക്കുന്നത് കുറയ്ക്കുകയും ചെയ്തു.
• ഞങ്ങൾക്ക് സ്വന്തമായി ഉണ്ട് മേഘം - ഒരു മേഘം, ഞങ്ങൾ ഇപ്പോൾ രണ്ട് വർഷമായി എല്ലാ സേവനങ്ങളും സജീവമായി മൈഗ്രേറ്റ് ചെയ്യുന്നു. ആപ്ലിക്കേഷനുമായി പ്രവർത്തിക്കുന്നതിന്റെ മുഴുവൻ ചക്രത്തെയും ക്ലൗഡ് വളരെ ലളിതമാക്കുന്നു, കൂടാതെ ഒരു അപകടമുണ്ടായാൽ ഇത് പോലുള്ള അദ്വിതീയ ഉപകരണങ്ങൾ നൽകുന്നു:
  • ഒരു ക്ലിക്കിൽ എല്ലാ ആപ്ലിക്കേഷനുകളുടെയും ശരിയായ സ്റ്റോപ്പ്;
  • പരാജയപ്പെട്ട സെർവറുകളിൽ നിന്നുള്ള ആപ്ലിക്കേഷനുകളുടെ എളുപ്പത്തിൽ മൈഗ്രേഷൻ;
  • ഓട്ടോമാറ്റിക് റാങ്ക്ഡ് (സേവനങ്ങളുടെ മുൻഗണന അനുസരിച്ച്) ഒരു മുഴുവൻ ഡാറ്റാ സെന്ററിന്റെ സമാരംഭം.

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

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

നിങ്ങളുടെ അപകടങ്ങൾ എങ്ങനെ പോകുന്നു?

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