كيف سيكون شعورك إذا بدا مركز البيانات مع أجهزتك في أحد أيام الصيف الجميلة بهذا الشكل؟
أهلاً بكم! اسمي ديمتري سامسونوف، أعمل كمسؤول نظام رائد في "" تُظهر الصورة أحد مراكز البيانات الأربعة التي تم تركيب المعدات التي تخدم مشروعنا فيها. يوجد خلف هذه الجدران حوالي 4 آلاف قطعة من المعدات: الخوادم، وأنظمة تخزين البيانات، ومعدات الشبكات، وما إلى ذلك. - ما يقرب من ثلث جميع معداتنا.
معظم الخوادم هي Linux. هناك أيضًا عشرات الخوادم على Windows (MS SQL) - وهو تراثنا الذي تخلينا عنه بشكل منهجي لسنوات عديدة.
لذلك، في 5 يونيو 2019 الساعة 14:35، أبلغ المهندسون في أحد مراكز البيانات لدينا عن إنذار حريق.
إنكار
14:45. تعد حوادث الدخان البسيطة في مراكز البيانات أكثر شيوعًا مما تعتقد. كانت المؤشرات داخل القاعات طبيعية، لذلك كان رد فعلنا الأول هادئا نسبيا: لقد فرضوا حظرا على العمل مع الإنتاج، أي على أي تغييرات في التكوين، على طرح إصدارات جديدة، وما إلى ذلك، باستثناء العمل المتعلق بإصلاح شيء ما.
غيظ
هل سبق لك أن حاولت أن تعرف من رجال الإطفاء مكان وقوع الحريق بالضبط على السطح، أو أن تصعد بنفسك إلى سطح محترق لتقييم الوضع؟ ما هي درجة الثقة في المعلومات التي يتلقاها خمسة أشخاص؟
14: 50. ووردت معلومات تفيد بأن الحريق يقترب من نظام التبريد. ولكن هل سيأتي؟ يقوم مسؤول النظام المناوب بإزالة حركة المرور الخارجية من واجهات مركز البيانات هذا.
في الوقت الحالي، تتكرر واجهات جميع خدماتنا في ثلاثة مراكز بيانات، ويتم استخدام التوازن على مستوى DNS، مما يسمح لنا بإزالة عناوين مركز بيانات واحد من DNS، وبالتالي حماية المستخدمين من المشكلات المحتملة في الوصول إلى الخدمات . إذا حدثت مشكلات بالفعل في مركز البيانات، فإنه يترك عملية التدوير تلقائيًا. يمكنك قراءة المزيد هنا:
لم يؤثر الحريق علينا بأي شكل من الأشكال حتى الآن، ولم يتضرر المستخدمون ولا المعدات. هل هذا حادث؟ يحدد القسم الأول من وثيقة "خطة التعامل مع الحوادث" مفهوم "الحوادث"، وينتهي القسم على النحو التالي:
«إذا كان هناك شك في أن هناك حادث أم لا فهو حادث!»
14:53. يتم تعيين منسق للطوارئ.
المنسق هو الشخص الذي يتحكم في الاتصال بين جميع المشاركين، ويقيم حجم الحادث، ويستخدم خطة عمل الطوارئ، ويجذب الموظفين اللازمين، ويراقب استكمال الإصلاحات، والأهم من ذلك، يفوض أي مهام. وبعبارة أخرى، هذا هو الشخص الذي يدير عملية الاستجابة للطوارئ بأكملها.
مزاد علني
15:01. نبدأ في تعطيل الخوادم غير المرتبطة بالإنتاج.
15:03. نقوم بإيقاف تشغيل جميع الخدمات المحجوزة بشكل صحيح.
وهذا لا يشمل فقط الواجهات (التي لم يعد المستخدمون يصلون إليها بحلول هذه المرحلة) وخدماتها المساعدة (منطق الأعمال، وذاكرة التخزين المؤقت، وما إلى ذلك)، ولكن أيضًا قواعد البيانات المتنوعة ذات عامل النسخ المتماثل 2 أو أكثر (, , , إلخ.).
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. أداة تعقب المشكلات وWiki غير متوفرة، قم بالتبديل إلى وضع الاستعداد.
هذا ليس إنتاجًا، ولكن في حالة وقوع حادث، قد يكون توفر أي قاعدة معرفية أمرًا بالغ الأهمية.
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 ، ، "زملاء الصف" - لمدة ثلاثة أيام كانت البوابة غير متاحة كليًا أو جزئيًا. طوال هذا الوقت، قام أكثر من 100 شخص من مدن مختلفة، ومن شركات مختلفة (شكرًا جزيلاً مرة أخرى!)، عن بعد وبشكل مباشر في مراكز البيانات، يدويًا وتلقائيًا، بإصلاح آلاف الخوادم.
لقد توصلنا إلى استنتاجات. ولمنع حدوث ذلك مرة أخرى، قمنا ونواصل القيام بعمل مكثف حتى يومنا هذا.
ما هي الاختلافات الرئيسية بين الحادث الحالي و 404؟
- لدينا "خطة عمل للحوادث". نقوم بإجراء التمارين مرة كل ثلاثة أشهر - حيث نلعب دور حالة الطوارئ، والتي يجب على مجموعة من المسؤولين (الجميع بدورهم) التخلص منها باستخدام "خطة عمل الطوارئ". يتناوب مسؤولو النظام الرائدون في لعب دور المنسق.
- ربع سنوي، في وضع الاختبار، نقوم بعزل مراكز البيانات (كلها بدورها) عبر شبكات LAN وWAN، مما يسمح لنا بتحديد الاختناقات على الفور.
- عدد أقل من الأقراص المعطلة، لأننا قمنا بتشديد المعايير: ساعات تشغيل أقل، وعتبات أكثر صرامة لـ SMART،
- لقد تخلينا تمامًا عن BerkeleyDB، وهي قاعدة بيانات قديمة وغير مستقرة تتطلب الكثير من الوقت للتعافي بعد إعادة تشغيل الخادم.
- لقد قمنا بتقليل عدد الخوادم التي تستخدم MS SQL وتقليل الاعتماد على الخوادم المتبقية.
- لدينا منطقتنا ، حيث قمنا بترحيل جميع الخدمات بشكل نشط لمدة عامين حتى الآن. تعمل السحابة على تبسيط الدورة الكاملة للعمل مع التطبيق إلى حد كبير، وفي حالة وقوع حادث، فإنها توفر أدوات فريدة مثل:
- الإيقاف الصحيح لجميع التطبيقات بنقرة واحدة؛
- سهولة ترحيل التطبيقات من الخوادم الفاشلة؛
- الإطلاق التلقائي (حسب أولوية الخدمات) لمركز البيانات بأكمله.
كان الحادث الموصوف في هذا المقال هو الأكبر منذ اليوم 404. وبطبيعة الحال، لم يسير كل شيء بسلاسة. على سبيل المثال، أثناء عدم توفر مركز بيانات تالف في مركز بيانات آخر، فشل قرص موجود على أحد الخوادم، أي أنه لم يتبق سوى نسخة واحدة فقط من النسخ المتماثلة الثلاثة في مجموعة Cassandra قابلة للوصول، وهذا هو السبب في أن 4,2% من الأجهزة المحمولة لم يتمكن مستخدمو التطبيق من تسجيل الدخول. وفي الوقت نفسه، واصل المستخدمون المتصلون بالفعل العمل. في المجموع، نتيجة للحادث، تم تحديد أكثر من 30 مشكلة - من الأخطاء المبتذلة إلى أوجه القصور في بنية الخدمة.
لكن الفرق الأكثر أهمية بين الحادث الحالي والحادث 404 هو أنه بينما كنا نتخلص من عواقب الحريق، كان المستخدمون لا يزالون يرسلون رسائل نصية ويجرون مكالمات فيديو إلى ولعبوا الألعاب واستمعوا إلى الموسيقى وقدموا الهدايا لبعضهم البعض وشاهدوا مقاطع الفيديو والمسلسلات التلفزيونية والقنوات التلفزيونية ، والتي تم بثها أيضًا .
كيف تسير حوادثك؟
المصدر: www.habr.com