آیا در صورت آتش گرفتن تست دود مرکز داده، سرورها باید خاموش شوند؟

اگر یک روز خوب تابستانی مرکز داده با تجهیزات شما به این شکل باشد، چه احساسی خواهید داشت؟

سلام به همه! نام من دیمیتری سامسونوف است، من به عنوان یک مدیر پیشرو سیستم در " کار می کنمهمکلاسی ها" این عکس یکی از چهار مرکز داده را نشان می دهد که تجهیزاتی که پروژه ما را در آن خدمت می کنند نصب شده است. در پشت این دیوارها حدود 4 هزار قطعه تجهیزات وجود دارد: سرورها، سیستم های ذخیره سازی اطلاعات، تجهیزات شبکه و غیره. - تقریبا ⅓ از تمام تجهیزات ما.
اکثر سرورها لینوکس هستند. همچنین چندین ده سرور در ویندوز (MS SQL) وجود دارد - میراث ما، که سال هاست به طور سیستماتیک آن را رها کرده ایم.
بنابراین، در 5 ژوئن 2019 در ساعت 14:35، مهندسان در یکی از مراکز داده ما یک هشدار آتش را گزارش کردند.

انکار

14:45. حوادث جزئی دود در مراکز داده بیشتر از آن چیزی است که فکر می کنید. نشانگرهای داخل سالن ها عادی بود، بنابراین اولین واکنش ما نسبتاً آرام بود: آنها ممنوعیت کار با تولید، یعنی هرگونه تغییر پیکربندی، عرضه نسخه های جدید و غیره را به جز کارهای مربوط به تعمیر چیزی، ممنوع کردند.

خشم

آیا تا به حال سعی کرده اید از آتش نشانان بفهمید که آتش دقیقاً در کجای پشت بام رخ داده است یا خودتان برای ارزیابی وضعیت به سقف در حال سوختن بروید؟ میزان اعتماد به اطلاعات دریافتی از طریق پنج نفر چقدر خواهد بود؟

14: 50. اطلاعاتی مبنی بر نزدیک شدن آتش به سیستم خنک کننده دریافت شده است. اما آیا خواهد آمد؟ مدیر وظیفه سیستم، ترافیک خارجی را از جلوی این مرکز داده حذف می کند.

در حال حاضر، جبهه تمام خدمات ما در سه مرکز داده کپی شده است، تعادل در سطح DNS استفاده می شود، که به ما امکان می دهد آدرس های یک مرکز داده را از DNS حذف کنیم، در نتیجه کاربران را از مشکلات احتمالی دسترسی به خدمات محافظت می کنیم. . اگر قبلاً مشکلاتی در مرکز داده رخ داده باشد، چرخش به طور خودکار خارج می شود. در اینجا می توانید بیشتر بخوانید: تعادل بار و تحمل خطا در Odnoklassniki.

آتش هنوز به هیچ وجه ما را تحت تأثیر قرار نداده است - نه کاربران و نه تجهیزات آسیب ندیده اند. آیا این یک تصادف است؟ بخش اول سند "برنامه اقدام تصادف" مفهوم "حادثه" را تعریف می کند و بخش به این صورت به پایان می رسد:
«اگر در تصادف یا نبودن شک باشد، تصادف است!»

14:53. هماهنگ کننده اضطراری منصوب شد.

هماهنگ کننده فردی است که ارتباط بین همه شرکت کنندگان را کنترل می کند، مقیاس حادثه را ارزیابی می کند، از برنامه اقدام اضطراری استفاده می کند، پرسنل لازم را جذب می کند، بر اتمام تعمیرات نظارت می کند و مهمتر از همه، هر گونه کار را محول می کند. به عبارت دیگر، این شخصی است که کل فرآیند واکنش اضطراری را مدیریت می کند.

چانه زدن

15:01. ما شروع به غیرفعال کردن سرورهایی می کنیم که مربوط به تولید نیستند.
15:03. ما به درستی تمام خدمات رزرو شده را خاموش می کنیم.
این نه تنها شامل جبهه‌ها (که تا این لحظه کاربران دیگر به آن‌ها دسترسی ندارند) و خدمات کمکی آنها (منطق تجاری، حافظه پنهان و غیره)، بلکه پایگاه‌های داده مختلف با ضریب تکرار 2 یا بیشتر را نیز شامل می‌شود.کاساندرا, ذخیره سازی داده های باینری, سردخانه, NewSQL و غیره.).
15: 06. اطلاعات دریافت شده مبنی بر اینکه آتش سوزی یکی از سالن های مرکز داده را تهدید می کند. ما در این اتاق تجهیزات نداریم، اما این واقعیت که آتش می تواند از پشت بام به سالن ها سرایت کند، تصویر آنچه را که در حال رخ دادن است به شدت تغییر می دهد.
(بعداً مشخص شد که سالن هیچ تهدیدی فیزیکی نداشته است، زیرا از پشت بام آن را بسته شده است. تهدید فقط سیستم خنک کننده این سالن بوده است).
15:07. ما به اجرای دستور در سرورها در حالت تسریع بدون بررسی اضافی اجازه می دهیم (بدون ماشین حساب مورد علاقه ما).
15:08. دمای سالن ها در حد نرمال است.
15: 12. افزایش دما در سالن ها ثبت شد.
15:13. بیش از نیمی از سرورهای مرکز داده خاموش هستند. بیا ادامه بدهیم.
15:16. تصمیم گرفته شد تمام تجهیزات خاموش شود.
15:21. ما بدون خاموش کردن صحیح برنامه و سیستم عامل شروع به خاموش کردن سرورهای بدون وضعیت می کنیم.
15:23. گروهی از افراد مسئول MS SQL اختصاص داده شده اند (تعداد کمی از آنها وجود دارد ، وابستگی خدمات به آنها زیاد نیست ، اما روند بازیابی عملکرد طولانی تر و پیچیده تر از مثلاً کاساندرا است).

افسردگی

15: 25. اطلاعاتی مبنی بر قطع برق چهار سالن از 16 سالن (شماره 6، 7، 8، 9) دریافت شد. تجهیزات ما در سالن 7 و 8 قرار دارد. از دو سالن ما (شماره 1 و 3) خبری نیست.
معمولاً در هنگام آتش سوزی، برق بلافاصله قطع می شود، اما در این حالت به لطف کار هماهنگ آتش نشانان و پرسنل فنی مرکز داده، نه همه جا و نه بلافاصله، بلکه در صورت لزوم قطع می شد.
(بعدها مشخص شد که برق سالن 8 و 9 قطع نشده است.)
15:28. ما شروع به استقرار پایگاه های داده MS SQL از پشتیبان گیری در مراکز داده دیگر کرده ایم.
چقد طول میکشه؟ آیا ظرفیت شبکه کافی برای کل مسیر وجود دارد؟
15: 37. خاموشی برخی از بخش های شبکه ثبت شد.
مدیریت و شبکه تولید از نظر فیزیکی از یکدیگر جدا هستند. اگر شبکه تولید در دسترس باشد، می توانید به سرور بروید، برنامه را متوقف کنید و سیستم عامل را خاموش کنید. اگر در دسترس نیست، می توانید از طریق IPMI وارد شوید، برنامه را متوقف کنید و سیستم عامل را خاموش کنید. اگر هیچ یک از شبکه ها وجود نداشته باشد، پس نمی توانید کاری انجام دهید. فکر می کنید "ممنون، کلاه!"
همچنین ممکن است فکر کنید: "و به طور کلی، آشفتگی زیادی وجود دارد."
مسئله این است که سرورها، حتی بدون آتش سوزی، مقدار زیادی گرما تولید می کنند. به عبارت دقیق تر، زمانی که خنک کننده باشد، گرما تولید می کنند و زمانی که خنک کننده وجود ندارد، یک جهنم جهنمی ایجاد می کنند که در بهترین حالت، بخشی از تجهیزات ذوب می شود و بخشی دیگر خاموش می شود و در بدترین حالت... آتش سوزی در داخل سالن که تقریباً همه چیز را نابود می کند.

15:39. ما مشکلات مربوط به پایگاه داده conf را برطرف می کنیم.

پایگاه داده conf پشتیبان سرویسی به همین نام است که توسط همه برنامه های تولیدی برای تغییر سریع تنظیمات استفاده می شود. بدون این پایه، ما نمی توانیم عملکرد پورتال را کنترل کنیم، اما خود پورتال می تواند کار کند.

15:41. سنسورهای دما در تجهیزات شبکه اصلی قرائت را نزدیک به حداکثر مجاز ثبت می کنند. این جعبه ای است که کل رک را اشغال می کند و عملکرد تمام شبکه های داخل مرکز داده را تضمین می کند.

15:42. ردیاب مشکل و ویکی در دسترس نیستند، به حالت آماده به کار بروید.
این تولید نیست، اما در صورت وقوع حادثه، در دسترس بودن هر پایگاه دانشی می تواند حیاتی باشد.
15:50. یکی از سیستم های مانیتورینگ خاموش شده است.
چندین مورد از آنها وجود دارد و آنها مسئول جنبه های مختلف خدمات هستند. برخی از آنها به گونه‌ای پیکربندی شده‌اند که در هر مرکز داده به‌طور مستقل عمل کنند (یعنی فقط مرکز داده خود را نظارت می‌کنند)، برخی دیگر از اجزای توزیع‌شده تشکیل شده‌اند که به طور شفاف از دست دادن هر مرکز داده جان سالم به در می‌برند.
در این صورت از کار افتاد سیستم تشخیص ناهنجاری شاخص های منطق تجاری، که در حالت آماده به کار اصلی کار می کند. به حالت آماده به کار تبدیل شد.

پذیرش

15:51. همه سرورها به جز MS SQL از طریق IPMI بدون خاموش شدن صحیح خاموش شدند.
آیا در صورت لزوم برای مدیریت گسترده سرور از طریق IPMI آماده هستید؟

درست لحظه ای که نجات تجهیزات در مرکز داده در این مرحله کامل می شود. هر کاری که می شد انجام شد. برخی از همکاران می توانند استراحت کنند.
16: 13. اطلاعات دریافت شده است مبنی بر ترکیدن لوله های فریون از تهویه مطبوع در پشت بام - این امر راه اندازی مرکز داده را پس از از بین بردن آتش به تاخیر می اندازد.
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 چه اتفاقی افتاد؟
پاسخ: به دنبال "برنامه اقدام بلایا"، ما همه خدمات را راه اندازی می کنیم که از مهمترین آنها شروع می شود. در این مورد، هماهنگ کننده در چت، سرویس را به یک مدیر رایگان می دهد، که بررسی می کند که آیا سیستم عامل و برنامه شروع شده است، آیا خطا وجود دارد و آیا شاخص ها عادی هستند یا خیر. پس از اتمام راه اندازی، او به چت گزارش می دهد که آزاد است و یک سرویس جدید از هماهنگ کننده دریافت می کند.
این روند توسط سخت افزار شکست خورده کندتر می شود. حتی اگر توقف سیستم عامل و خاموش کردن سرورها به درستی انجام شود، برخی از سرورها به دلیل خرابی ناگهانی دیسک، حافظه و شاسی باز نمی گردند. با قطع برق، میزان خرابی افزایش می یابد.
س: چرا نمی توانید همه چیز را به یکباره اجرا کنید، و سپس آنچه را که در مانیتورینگ ظاهر می شود، اصلاح کنید؟
پاسخ: همه چیز باید به تدریج انجام شود، زیرا وابستگی هایی بین خدمات وجود دارد. و شما باید همه چیز را فوراً بررسی کنید، بدون اینکه منتظر نظارت باشید - زیرا بهتر است بلافاصله با مشکلات مقابله کنید، بدون اینکه منتظر بدتر شدن آنها باشید.

7:40 آخرین ادمین (هماهنگ کننده) به رختخواب رفت. کار روز اول به پایان رسیده است.
8:09. اولین توسعه دهندگان، مهندسان مرکز داده و مدیران (از جمله هماهنگ کننده جدید) کار بازسازی را آغاز کردند.
09:37. شروع به بالا بردن سالن شماره 7 (آخرین) کردیم.
در همان زمان، ما همچنان به بازیابی مواردی که در اتاق‌های دیگر ثابت نشده بود، ادامه می‌دهیم: جایگزینی دیسک‌ها/حافظه/سرورها، تعمیر هر چیزی که در نظارت می‌سوزد، تغییر نقش‌ها در طرح‌های اصلی آماده‌باش و چیزهای کوچک دیگری، که وجود دارد. با این حال بسیار زیاد
17:08. ما اجازه می دهیم همه کارهای منظم با تولید انجام شود.
21:45. کار روز دوم به پایان رسید.
09:45. امروز جمعه است. هنوز چند مشکل کوچک در نظارت وجود دارد. آخر هفته در پیش است، همه می خواهند استراحت کنند. ما به تعمیر انبوه هر چیزی که می توانیم ادامه می دهیم. وظایف مدیر معمولی که ممکن بود به تعویق بیفتد به تعویق افتاد. هماهنگ کننده جدید است.
15:40. ناگهان نیمی از پشته تجهیزات شبکه اصلی در مرکز داده دیگری راه اندازی مجدد شد. جبهه ها برای به حداقل رساندن خطرات از چرخش خارج شدند. هیچ تاثیری برای کاربران ندارد. بعداً مشخص شد که شاسی آن معیوب بوده است. هماهنگ کننده در حال کار بر روی تعمیر دو حادثه به طور همزمان است.
17:17. عملیات شبکه در مرکز داده دیگری بازیابی شده است، همه چیز بررسی شده است. مرکز داده در چرخش قرار می گیرد.
18:29. کار روز سوم و به طور کلی مرمت بعد از حادثه تمام شده است.

پس از کلمه

04.04.2013/XNUMX/XNUMX، در روز خطای 404، "همکلاسی ها" از بزرگترین تصادف جان سالم به در برد - به مدت سه روز پورتال به طور کامل یا جزئی در دسترس نبود. در تمام این مدت، بیش از 100 نفر از شهرهای مختلف، از شرکت های مختلف (باز هم با تشکر فراوان!)، از راه دور و مستقیم در مراکز داده، به صورت دستی و خودکار، هزاران سرور را تعمیر کردند.
ما نتیجه گیری کرده ایم. برای جلوگیری از تکرار این اتفاق، کارهای گسترده ای را تا به امروز انجام داده و ادامه می دهیم.

تفاوت اصلی تصادف فعلی با 404 چیست؟

• ما یک "برنامه اقدام تصادف" داریم. هر سه ماه یک بار تمریناتی را انجام می دهیم - یک موقعیت اضطراری را ایفا می کنیم که گروهی از مدیران (همه به نوبه خود) باید با استفاده از "برنامه اقدام اضطراری" آن را حذف کنند. مدیران پیشرو سیستم به نوبت نقش هماهنگ کننده را بازی می کنند.
• به صورت فصلی، در حالت تست، مراکز داده را (همه به نوبه خود) از طریق شبکه‌های LAN و WAN جدا می‌کنیم، که به ما امکان می‌دهد به سرعت گلوگاه‌ها را شناسایی کنیم.
• دیسک های شکسته کمتر، زیرا استانداردها را سخت تر کرده ایم: ساعات کار کمتر، آستانه سخت گیرانه تر برای SMART،
• ما به طور کامل BerkeleyDB را رها کردیم، یک پایگاه داده قدیمی و ناپایدار که پس از راه اندازی مجدد سرور به زمان زیادی برای بازیابی نیاز داشت.
• ما تعداد سرورهای دارای MS SQL را کاهش دادیم و وابستگی به بقیه را کاهش دادیم.
• ما خودمان را داریم ابر - یک ابری، جایی که ما اکنون دو سال است که به طور فعال همه خدمات را انتقال داده ایم. ابر کل چرخه کار با برنامه را تا حد زیادی ساده می کند و در صورت بروز حادثه ابزارهای منحصر به فردی مانند:
  • توقف صحیح همه برنامه ها با یک کلیک؛
  • مهاجرت آسان برنامه ها از سرورهای ناموفق؛
  • راه اندازی خودکار (به ترتیب اولویت خدمات) یک مرکز داده کامل.

حادثه توصیف شده در این مقاله بزرگترین حادثه از روز 404 بود. البته همه چیز به آرامی پیش نرفت. به عنوان مثال، در زمان در دسترس نبودن یک مرکز داده آسیب دیده در اثر آتش سوزی در مرکز داده دیگر، یک دیسک روی یکی از سرورها از کار افتاد، یعنی تنها یکی از سه کپی موجود در خوشه Cassandra در دسترس باقی ماند، به همین دلیل است که 4,2٪ از تلفن همراه کاربران برنامه نتوانستند وارد شوند. در همان زمان، کاربران از قبل متصل به کار خود ادامه دادند. در مجموع، در نتیجه این حادثه، بیش از 30 مشکل شناسایی شد - از اشکالات پیش پا افتاده تا کاستی در معماری خدمات.

اما مهمترین تفاوت تصادف فعلی با 404 این است که در حالی که ما در حال رفع عواقب آتش سوزی بودیم، کاربران همچنان در حال ارسال پیامک و تماس تصویری بودند. دقیقا، بازی کردند، موسیقی گوش کردند، به یکدیگر هدیه دادند، فیلم، سریال و کانال تلویزیونی را تماشا کردند خوب، و همچنین جریان یافت خوب زنده.

تصادفات شما چگونه پیش می رود؟

منبع: www.habr.com