علت اصلی حوادث در مراکز داده وجود واشر بین کامپیوتر و صندلی است

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

طبق آمار مؤسسه Uptime، اکثر حوادث در مراکز داده مربوط به خرابی سیستم منبع تغذیه است - آنها 39٪ از حوادث را تشکیل می دهند. پس از آنها عامل انسانی است که 24 درصد دیگر از تصادفات را تشکیل می دهد. سومین دلیل مهم (15%) خرابی سیستم تهویه مطبوع و در رتبه چهارم (12%) بلایای طبیعی بود. کل سهم سایر مشکلات فقط 10 درصد است. بدون زیر سوال بردن داده‌های یک سازمان محترم، موارد رایج در تصادفات مختلف را برجسته می‌کنیم و سعی می‌کنیم بفهمیم که آیا می‌توان از آنها اجتناب کرد. اسپویلر: در بیشتر موارد امکان پذیر است.

علم ارتباطات

به بیان ساده، فقط دو مشکل در منبع تغذیه وجود دارد: یا در جایی که باید تماسی وجود ندارد، یا جایی که نباید تماسی وجود داشته باشد. شما می توانید برای مدت طولانی در مورد قابلیت اطمینان سیستم های منبع تغذیه بدون وقفه مدرن صحبت کنید، اما آنها همیشه شما را نجات نمی دهند. مورد برجسته مرکز داده مورد استفاده بریتیش ایرویز، که متعلق به شرکت مادر International Airlines Group است را در نظر بگیرید. دو ملک در نزدیکی فرودگاه هیترو وجود دارد - خانه Boadicea و Comet House. در اولین مورد، در 27 می 2017، یک قطع برق تصادفی رخ داد که منجر به اضافه بار و از کار افتادن سیستم UPS شد. در نتیجه، برخی از تجهیزات فناوری اطلاعات آسیب فیزیکی دیدند و آخرین فاجعه سه روز طول کشید تا برطرف شود.

شرکت هواپیمایی مجبور شد بیش از هزار پرواز را لغو یا تغییر دهد، حدود 75 هزار مسافر نتوانستند به موقع پرواز کنند - 128 میلیون دلار برای پرداخت غرامت هزینه شد، بدون احتساب هزینه های مورد نیاز برای بازگرداندن عملکرد مراکز داده. تاریخچه دلایل خاموشی روشن نیست. اگر نتایج تحقیقات داخلی اعلام شده توسط ویلی والش، مدیر عامل گروه هواپیمایی بین المللی را باور دارید، این به دلیل اشتباه مهندسان بوده است. با این حال، سیستم منبع تغذیه بدون وقفه باید در برابر چنین خاموشی مقاومت می کرد - به همین دلیل نصب شد. این مرکز داده توسط متخصصانی از شرکت برون سپاری CBRE Managed Services مدیریت می شد، بنابراین بریتیش ایرویز تلاش کرد تا میزان خسارت را از طریق دادگاه لندن بازیابی کند.

قطع برق در سناریوهای مشابه اتفاق می افتد: ابتدا به دلیل تقصیر منبع برق خاموش می شود، گاهی اوقات به دلیل آب و هوای بد یا مشکلات داخلی (از جمله خطاهای انسانی)، و سپس سیستم منبع تغذیه بدون وقفه نمی تواند با بار یا کوتاهی برق مقابله کند. قطعی موج سینوسی باعث خرابی بسیاری از سرویس ها می شود که بازیابی آن زمان و هزینه زیادی را می طلبد. آیا می توان از چنین حوادثی جلوگیری کرد؟ بی شک. اگر سیستم را به درستی طراحی کنید، حتی سازندگان مراکز داده بزرگ نیز از اشتباه مصون نیستند.

عامل انسانی

هنگامی که علت فوری یک حادثه اقدامات نادرست پرسنل مرکز داده باشد، مشکلات اغلب (اما نه همیشه) بر بخش نرم افزاری زیرساخت فناوری اطلاعات تأثیر می گذارد. چنین حوادثی حتی در شرکت های بزرگ نیز رخ می دهد. در فوریه 2017، به دلیل استخدام نادرست عضو تیم در گروه عملیات فنی یکی از مراکز داده، بخشی از سرورهای وب سرویس آمازون غیرفعال شد. هنگام اشکال‌زدایی فرآیند صورت‌حساب برای مشتریان ذخیره‌سازی ابری Amazon Simple Storage Service (S3) خطایی روی داد. یک کارمند سعی کرد تعدادی از سرورهای مجازی مورد استفاده توسط سیستم صورتحساب را حذف کند، اما به یک خوشه بزرگتر برخورد کرد.

در نتیجه یک خطای مهندسی، سرورهایی که ماژول های مهم نرم افزار ذخیره سازی ابری آمازون را اجرا می کنند، حذف شدند. اولین موردی که تحت تأثیر قرار گرفت، زیرسیستم نمایه سازی بود که حاوی اطلاعاتی درباره ابرداده و مکان همه اشیاء S3 در منطقه US-EAST-1 آمریکا است. این حادثه همچنین بر زیرسیستم مورد استفاده برای میزبانی داده ها و مدیریت فضای موجود برای ذخیره سازی تأثیر گذاشت. پس از حذف ماشین‌های مجازی، این دو زیرسیستم نیاز به راه‌اندازی مجدد کامل داشتند، و سپس مهندسان آمازون در غافلگیری بودند - برای مدت طولانی، فضای ذخیره‌سازی ابری عمومی قادر به پاسخگویی به درخواست‌های مشتریان نبود.

این تأثیر گسترده بود، زیرا بسیاری از منابع بزرگ از Amazon S3 استفاده می کنند. این قطعی ها بر Trello، Coursera، IFTTT و از همه ناخوشایندتر، خدمات شرکای اصلی آمازون از لیست S&P 500 تأثیر گذاشت. محاسبه خسارت در چنین مواردی دشوار است، اما در منطقه صدها میلیون دلار آمریکا بود. همانطور که می بینید، یک دستور اشتباه برای غیرفعال کردن سرویس بزرگترین پلت فرم ابری کافی است. این یک مورد مجزا نیست؛ در 16 مه 2019، در حین تعمیر و نگهداری، سرویس Yandex.Cloud حذف شده ماشین‌های مجازی کاربران در منطقه ru-central1-c که حداقل یک بار در وضعیت SUSPENDED بودند. داده‌های مشتری قبلاً در اینجا آسیب دیده است که برخی از آنها به طور غیرقابل برگشتی از بین رفته است. البته، افراد ناقص هستند، اما سیستم‌های امنیت اطلاعات مدرن مدت‌هاست که قادر به نظارت بر اعمال کاربران ممتاز قبل از اجرای دستوراتی هستند که وارد کرده‌اند. اگر چنین راه حل هایی در Yandex یا Amazon اجرا شود، می توان از چنین حوادثی جلوگیری کرد.

خنک کننده یخ زده

در ژانویه 2017، یک حادثه بزرگ در مرکز داده Dmitrov شرکت Megafon رخ داد. سپس دما در منطقه مسکو به -35 درجه سانتیگراد کاهش یافت که منجر به از کار افتادن سیستم خنک کننده تأسیسات شد. سرویس مطبوعاتی این اپراتور به طور خاص در مورد دلایل این حادثه صحبت نکرد - شرکت های روسی به شدت تمایلی به صحبت در مورد حوادث در تاسیسات خود ندارند؛ از نظر تبلیغات، ما بسیار از غرب عقب هستیم. نسخه ای در شبکه های اجتماعی در مورد انجماد مایع خنک کننده در لوله های گذاشته شده در امتداد خیابان و نشت اتیلن گلیکول منتشر شد. به گفته وی، سرویس عملیات به دلیل تعطیلات طولانی نتوانست به سرعت 30 تن مایع خنک کننده را به دست آورد و با استفاده از وسایل بداهه خارج شد و برخلاف قوانین کارکرد سیستم، خنک کننده آزاد بداهه را سازماندهی کرد. سرمای شدید این مشکل را تشدید کرد - در ژانویه، زمستان به طور ناگهانی روسیه را گرفت، اگرچه هیچ کس انتظار آن را نداشت. در نتیجه کارکنان مجبور شدند برق بخشی از رک های سرور را قطع کنند و به همین دلیل برخی از خدمات اپراتور به مدت دو روز در دسترس نبودند.

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

بلایای طبیعی

اغلب، طوفان‌های تندری و/یا طوفان‌ها زیرساخت‌های مهندسی مرکز داده را مختل می‌کنند که منجر به وقفه در سرویس و/یا آسیب فیزیکی به تجهیزات می‌شود. حوادث ناشی از آب و هوای بد اغلب اتفاق می افتد. در سال 2012، طوفان سندی با بارندگی شدید، سواحل غربی ایالات متحده را درنوردید. در یک ساختمان بلند در منهتن پایین، مرکز داده Peer 1 واقع شده است منبع تغذیه خارجی از دست رفته، پس از طغیان آب شور دریا به زیرزمین ها. ژنراتورهای اضطراری این مرکز در طبقه هجدهم قرار داشتند و عرضه سوخت آنها محدود بود - قوانینی که پس از حملات تروریستی 18 سپتامبر در نیویورک وضع شد، ذخیره مقادیر زیادی سوخت در طبقات بالا را ممنوع می کند.

پمپ بنزین نیز از کار افتاد، بنابراین کارکنان چندین روز را صرف کشیدن گازوئیل به ژنراتورها کردند. قهرمانی تیم مرکز داده را از یک حادثه جدی نجات داد، اما آیا واقعاً لازم بود؟ ما در سیاره ای زندگی می کنیم که جو نیتروژن-اکسیژن و آب زیادی دارد. رعد و برق و طوفان در اینجا (به ویژه در مناطق ساحلی) رایج است. طراحان احتمالاً خوب خواهند بود که خطرات موجود را در نظر بگیرند و یک سیستم منبع تغذیه بدون وقفه مناسب بسازند. یا حداقل مکان مناسب تری را برای مرکز داده نسبت به یک ساختمان بلند در یک جزیره انتخاب کنید.

همه چیز دیگر

موسسه Uptime انواع حوادث را در این دسته شناسایی می کند که از بین آنها انتخاب یک نمونه معمولی دشوار است. سرقت کابل‌های مسی، برخورد اتومبیل‌ها به مراکز داده، پشتیبانی از خطوط برق و پست‌های ترانسفورماتور، آتش‌سوزی، اپراتورهای بیل مکانیکی که به اپتیکال آسیب می‌رسانند، جوندگان (موش‌ها، خرگوش‌ها و حتی حشرات که در واقع کیسه‌داران هستند) و همچنین کسانی که دوست دارند تیراندازی کنند. سیم - منو گسترده است. قطع برق حتی می تواند باعث شود دزدی کشت غیرقانونی ماری جوانا برق در بیشتر موارد افراد خاصی مقصر حادثه می شوند، یعنی باز هم با عامل انسانی سروکار داریم که مشکل نام و نام خانوادگی دارد. حتی اگر در نگاه اول حادثه با نقص فنی یا بلایای طبیعی همراه باشد، می توان از آن اجتناب کرد، مشروط بر اینکه تاسیسات به درستی طراحی و به درستی کار کند. تنها موارد استثنا موارد آسیب جدی به زیرساخت مرکز داده یا تخریب ساختمان ها و سازه ها به دلیل یک بلای طبیعی است. اینها واقعاً شرایط فورس ماژور هستند و همه مشکلات دیگر به دلیل واشر بین رایانه و صندلی ایجاد می شوند - شاید این غیر قابل اعتمادترین بخش از هر سیستم پیچیده باشد.

منبع: www.habr.com