🛸 👨🏿‍🚀 👩🏿‍🔬 المراقبة في مركز البيانات: كيف قمنا بتغيير نظام إدارة المباني القديم إلى نظام جديد. الجزء 2 👏🏽 🙌🏿 👧🏿

في الجزء الأول ، تحدثنا عن سبب قررنا تغيير نظام BMS القديم في مراكز البيانات لدينا إلى نظام جديد. وليس التغيير فحسب ، بل التطوير من الصفر ليلائم متطلباتك. في الجزء الثاني نقول كيف فعلنا ذلك.

تحليل السوق

بناءً على الرغبات والقرارات الموضحة في الجزء الأول ، لرفض ترقية النظام الحالي ، قمنا بكتابة بيان عمل لإيجاد حل في السوق واستفسرنا عن العديد من الشركات الكبيرة التي تشارك فقط في إنشاء أنظمة SCADA الصناعية.

أظهرت الإجابات الأولى منهم أن قادة سوق أنظمة المراقبة يواصلون العمل بشكل أساسي على خوادم الحديد ، على الرغم من أن عملية الترحيل إلى السحب في هذا الجزء قد بدأت بالفعل. أما بالنسبة للأجهزة الافتراضية الاحتياطية - فلا أحد يدعم هذا الخيار. علاوة على ذلك ، كان هناك شعور بأن أيا من المطورين الظاهر في السوق لم يظهر حتى فهمًا للحاجة إلى التكرار: "السحابة لا تسقط" ، كانت الإجابة الأكثر شيوعًا. في الواقع ، عرض علينا وضع مراقبة مركز البيانات في سحابة موجودة فعليًا في نفس مركز البيانات.

هنا من الضروري عمل بحث صغير حول عملية اختيار المقاول. السعر بالطبع مهم ، ولكن خلال أي مناقصة لتنفيذ مشروع معقد ، في مرحلة الحوار مع الموردين ، تبدأ في الشعور بأي من المرشحين أكثر اهتمامًا وقادرًا على تنفيذه.

هذا ملحوظ بشكل خاص في المشاريع المعقدة.

من خلال طبيعة الأسئلة التوضيحية للمعارف التقليدية ، من الممكن تقسيم المقاولين إلى المهتمين بالبيع ببساطة (الشعور بالضغط القياسي لمدير المبيعات) والمهتمين بتطوير المنتج ، بعد الاستماع إلى العميل وفهمه ، لإجراء تعديلات بناءة على المواصفات الفنية حتى قبل الاختيار النهائي (حتى على الرغم من الحقيقة خطر تحسين المعارف التقليدية لشخص آخر وفقدان العطاء) ، في النهاية ، على استعداد لقبول التحدي المهني وتقديم منتج جيد.

كل هذا جعلنا ننتبه إلى مطور محلي صغير نسبيًا - مجموعة شركات Sunline ، التي استجابت لمعظم متطلباتنا على الفور وكانت مستعدة لتلبية جميع الاحتياجات المتعلقة بنظام إدارة المباني الجديد.

المخاطر

بينما كان اللاعبون الكبار يحاولون فهم ما نريد ، وكنا في مراسلات مهللة بمساعدة متخصصين قبل البيع ، قام مطور محلي بتحديد موعد في مكتبنا بمشاركة فريقه الفني. في هذا الاجتماع ، أظهر المقاول مرة أخرى الرغبة في المشاركة في المشروع - والأهم من ذلك - شرح كيف سيتم تنفيذ النظام المطلوب.

قبل الاجتماع ، رأينا خطرين للعمل مع فريق ليس لديه موارد شركة وطنية أو دولية كبيرة:

يمكن للمتخصصين المبالغة في تقدير قدراتهم ونتيجة لذلك لا يمكنهم ببساطة التكيف ، على سبيل المثال ، سيستخدمون برامج معقدة أو تصميم خوارزميات النسخ الاحتياطي غير عملي.
بعد تنفيذ المشروع ، قد ينفصل فريق المشروع ، وبالتالي ، سيكون دعم المنتج في خطر.

لتقليل هذه المخاطر ، قمنا بدعوة متخصصي التطوير لدينا إلى الاجتماع. تم إجراء مقابلات شاملة مع موظفي المقاول المحتمل حول ما يقوم عليه النظام ، وكيف يتم التخطيط لتنفيذ الحجوزات ، وعلى القضايا الأخرى التي نحن فيها ، كخدمة تشغيل ، غير مؤهلين بما فيه الكفاية.

كان الحكم إيجابيًا: إن بنية منصة BMS الحالية حديثة وبسيطة وموثوقة ، ويمكن الانتهاء منها ، ونظام النسخ الاحتياطي والمزامنة المقترح منطقي وفعال.

تعاملوا مع المخاطر الأولى. لقد استبعدوا الثاني ، بعد أن تلقوا تأكيدًا من المقاول أنهم كانوا على استعداد لإعطائنا كود المصدر للنظام والوثائق ، بالإضافة إلى اختيار لغة برمجة Python ، المعروفة جيدًا لمتخصصينا. وهذا يضمن لنا فرصة الحفاظ على النظام بمفردنا دون أي صعوبات وفترة تدريب طويلة للموظفين في حالة مغادرة الشركة المطورة للسوق.

ميزة إضافية للمنصة هي أنه تم تنفيذها في حاويات Docker: في هذه البيئة ، النواة ، واجهة الويب ووظيفة قاعدة بيانات المنتج. يوفر هذا النهج العديد من المزايا ، بما في ذلك الإعدادات المسبقة لأعلى سرعة نشر للحل مقارنةً بـ "الكلاسيكية" والإضافة البسيطة للأجهزة الجديدة إلى النظام. يبسط مبدأ "الكل معًا" تنفيذ النظام قدر الإمكان: يكفي لفك النظام ويمكنك تشغيله على الفور.

مع هذا الحل ، من الأسهل عمل نسخ من النظام ، ومن الممكن تحسينه وتنفيذ الترقيات في بيئة منفصلة ، دون إيقاف الحل ككل.

بعد تقليل كلا الخطرين ، قدم المقاول KP. لقد عملنا على جميع أهم معلمات نظام BMS بالنسبة لنا.

حجز

كان من المفترض أن يكون نظام BMS الجديد في السحابة على جهاز افتراضي.

لا توجد أجهزة ولا خوادم وجميع الإزعاج والمخاطر المرتبطة بنموذج النشر هذا - سمح لنا الحل السحابي بالتخلص منها إلى الأبد. تقرر أن يعمل النظام في سحبتنا في موقعين لمركز البيانات في سانت بطرسبرغ وموسكو. هذان نظامان يعملان بشكل كامل ويعملان في وضع الاستعداد النشط مع وصول لجميع المتخصصين المعتمدين.

يؤمن النظامان بعضهما البعض ، مما يوفر احتياطيًا كاملاً لكل من طاقة الحوسبة وقنوات إرسال البيانات. يتم أيضًا إعداد إجراءات أمان إضافية ، بما في ذلك النسخ الاحتياطي للبيانات والقنوات والأنظمة والأجهزة الظاهرية بشكل عام ونسخة احتياطية منفصلة لقاعدة البيانات مرة واحدة في الشهر (المورد الأكثر قيمة في منظور الإدارة والتحليل).

لاحظ أن التكرار كخيار لحل BMS تم تطويره خصيصًا لطلبنا. بدا مخطط النسخ الاحتياطي نفسه كما يلي:

الدعم

أهم نقطة للتشغيل الفعال لحل BMS هو الدعم الفني.

كل شيء بسيط هنا: سيكلفنا نظام جديد 35000 روبل في هذا المؤشر. شهريا "استجابة جيش تحرير السودان في غضون 8 ساعات" ، أي 35000 × 12/80 = 5250 دولار في السنة. السنة الأولى مجانية.

للمقارنة: يكلف دعم BMS القديم من البائع 18000 دولار سنويًا مع زيادة في المبلغ لكل جهاز جديد تمت إضافته! في الوقت نفسه ، لم تقدم الشركة مديرًا مخصصًا ، وتمت جميع التفاعلات من خلال مدير مبيعات مهتم بنا كمشتري محتمل مع تركيز مماثل في معالجة الطلبات.

للحصول على أموال أقل ، تلقينا دعمًا كاملاً للمنتج ، مع مدير حساب يشارك في تطوير المنتج ، مع نقطة دخول واحدة ، وما إلى ذلك. أصبح الدعم أكثر مرونة - بفضل الوصول المباشر إلى المطورين لإجراء تعديلات تشغيلية على أي جانب من جوانب النظام ، والتكامل عبر واجهة برمجة التطبيقات ، وما إلى ذلك.

التحديثات

وفقًا لـ KP المقترح في BMS الجديد ، يتم تضمين جميع التحديثات في تكلفة الدعم ، أي لا تتطلب دفع إضافي. الاستثناء هو تطوير وظائف إضافية تتجاوز تلك المحددة في ToR.

افترض النظام القديم الدفع لتحديث البرامج الثابتة للبرامج المجانية (مثل Java) وإصلاح الأخطاء. كان من المستحيل رفض ذلك ، في ظل عدم وجود تحديثات للنظام ككل "تباطأ" بسبب الإصدارات القديمة من المكونات الداخلية.

وبالطبع ، كان من المستحيل تحديث البرنامج دون شراء حزمة دعم.

نهج مرن

يتعلق أحد المتطلبات الأساسية الأخرى بالواجهة. أردنا توفير الوصول إليها من خلال متصفح ويب من أي مكان ، دون وجود مهندس في مركز البيانات. بالإضافة إلى ذلك ، عملنا جاهدين على إنشاء واجهة متحركة ، بحيث تكون ديناميكيات عمل البنية التحتية أكثر وضوحًا للمهندسين المناوبين.

أيضًا في النظام الجديد ، كان من الضروري تقديم الدعم للصيغ لحساب تشغيل أجهزة الاستشعار الافتراضية في الأنظمة الهندسية - على سبيل المثال ، من أجل التوزيع الأمثل للطاقة الكهربائية بين الرفوف مع المعدات. للقيام بذلك ، يجب أن يكون لديك تحت تصرفك جميع العمليات الرياضية المعتادة المطبقة على مؤشرات أجهزة الاستشعار.

علاوة على ذلك ، كان الوصول إلى قاعدة بيانات SQL مطلوبًا مع القدرة على أخذ البيانات اللازمة حول تشغيل المعدات - أي جميع السجلات المتعلقة برصد ألفي جهاز وألفي مستشعر افتراضي تولد حوالي 20 ألف متغير.

احتجنا أيضًا إلى وحدة لمعدات المحاسبة في الرف ، مما يعطي تمثيلًا رسوميًا لموقع الأجهزة في كل وحدة مع حساب الوزن الإجمالي للأجهزة ، والحفاظ على مكتبة من الأجهزة ومعلومات تفصيلية حول كل عنصر.

مواءمة المعارف التقليدية والتوقيع على اتفاق

في ذلك الوقت ، عندما كان من الضروري البدء في العمل على النظام الجديد ، كانت المراسلات مع الشركات "الكبيرة" لا تزال بعيدة جدًا عن مناقشة تكلفة مقترحاتها ، لذلك قمنا بمقارنة KP المستلمة مع تكاليف تحديث BMS القديمة (انظر الجزء الأول ) ، و ونتيجة لذلك ، تبين أنها أكثر جاذبية من حيث السعر والمطابقة لمتطلباتنا.

تم الاختيار.

بعد اختيار مقاول ، بدأ المحامون في صياغة عقد ، وصقلت الفرق الفنية على الجانبين المواصفات الفنية. كما تعلم ، فإن المعارف التقليدية المفصلة والكفؤة هي أساس نجاح أي عمل. كلما كانت التفاصيل أكثر تفصيلاً في المعارف التقليدية ، كانت خيبة الأمل أقل مثل "لكننا لم نحب ذلك".

سأقدم مثالين على مستوى تفاصيل المتطلبات في المعارف التقليدية:

BMS , PDU. BMS «», , . . . , : , . .
BMS : – , – , – «». «» , , . , BMS . , , «» , , «» , .

مع درجة مماثلة من التفاصيل ، وتنسيقات الرسوم البيانية والإبلاغ ، ومخططات الواجهة ، وقائمة بالأجهزة التي تحتاج إلى المراقبة ، وتم وصف العديد من الأشياء الأخرى.

لقد كان عملًا مبتكرًا حقًا لثلاث مجموعات عمل - خدمة العملاء ، التي تملي متطلباتها وشروطها ؛ أخصائيون تقنيون من الجانبين مهمتهم تحويل هذه الشروط إلى وثائق فنية ؛ فرق من المبرمجين المتعاقدين الذين نفذوا متطلبات العملاء للوثائق الفنية المطورة ... ونتيجة لذلك ، قمنا بتكييف بعض متطلباتنا غير المبدئية مع وظائف النظام الأساسي الحالي ، وهو أمر تعهد به المقاول لإضافته لنا.

التشغيل المتوازي لنظامين

حان الوقت للتنفيذ. وهذا يعني عمليًا أننا نعطي المقاول الفرصة لنشر نموذج BMS أولي في السحابة الافتراضية الخاصة بنا وتوفير الوصول إلى الشبكة لجميع الأجهزة التي تتطلب المراقبة.

علاوة على ذلك ، لم يكن النظام الجديد جاهزا للعمل بعد. في هذه المرحلة ، كان من المهم بالنسبة لنا الحفاظ على المراقبة في النظام القديم وفي نفس الوقت منح الوصول إلى أجهزة النظام الجديد. من المستحيل إنشاء نظام بشكل صحيح دون رؤية الأجهزة فيه ، والذي بدوره لا يمكن فصله عن النظام القديم.

لم يكن واضحًا ما إذا كانت الأجهزة قادرة على تحمل الاستطلاع المتزامن بواسطة نظامين بدون اختبارات حقيقية. كان من الممكن أن يؤدي المسح المزدوج المتزامن إلى رفض متكرر للاستجابات من الأجهزة وسوف نتلقى العديد من الأخطاء بسبب عدم توفر الأجهزة ، الأمر الذي سيعوق بدوره تشغيل نظام المراقبة القديم.

ألقى قسم الشبكة مسارات افتراضية من النموذج الأولي BMS الجديد المنتشر في السحابة إلى الأجهزة ، وحصلنا على النتائج:

الأجهزة المتصلة عبر بروتوكول SNMP لم تنفصل عمليا عن قطع الاتصال بسبب المكالمات المتزامنة ،
واجهت الأجهزة المتصلة عبر مداخل باستخدام بروتوكولات modbas-TCP مشكلات تم حلها من خلال تقليل معقول في وتيرة الاقتراع.

ثم بدأنا في ملاحظة كيف تم بناء نظام جديد أمام أعيننا ، وقد ظهرت فيه بالفعل أجهزة مألوفة لنا ، ولكن في واجهة مختلفة - مريحة وسريعة ويمكن الوصول إليها حتى من الهاتف.

سنتحدث عما حدث نتيجة للجزء الثالث من مقالنا.

المراقبة في مركز البيانات: كيف قمنا بتغيير نظام إدارة المباني القديم إلى نظام جديد. الجزء 2