يوجد مركز بيانات صغير بالقرب من شركة تصنيع في بلدة صغيرة بعيدة تمامًا عن موسكو. مطلوب على مدار الساعة. حدث أن هناك إدخال واحد فقط من التيار الكهربائي ، ولكن لا يوجد مجموعة مولدات ديزل. لأن الشركة ليست تكنولوجيا المعلومات ، ولكنها شركة إنتاج ، فإنهم لم يصمموا مرة واحدة بشكل صحيح. لأنه بمجرد أن عملت كل شيء.
بدأ شعاع الطاقة في لعب المقالب. كل أسبوع ، انقطع الضوء لعدة ساعات ، وبطريقة اليانصيب: يمكن أن تكون لمدة ساعة ، أو يمكن أن تكون أكثر. لا توجد أنماط.
اقترح المشرف شراء وقود ديزل ، لكن الشركة قالت إن هذا ليس عمل إداري. وظيفته هي توفير وقت التوقف عن العمل لمدة لا تزيد عن ساعة. لقد قاموا بتضخيم الكثير من المال في المعدات ، لذلك لا يمكنك المغادرة إلى السحابة ، ولا توجد مراكز بيانات تجارية لنقل المعدات هناك.
وماذا تفعل؟
بهذه المهمة جاء العميل إلينا. ليس هناك الكثير من الميزانية ، تحتاج إلى البحث عن حل صالح.
الحالة العادية (باستثناء ظهور الإدخال الثاني ، أو نقل المعدات ، أو ظهور مولد ديزل) هي نشر الحالة نفسها تمامًا في السحابة والتحول إليها إذا حدث شيء فجأة. يطلق عليه التعافي من الكوارث. يقوم البعض ببناء مركز بيانات ثانٍ لأنفسهم ، إنه بارد وينتظر سقوط المركز الرئيسي ، أو أنه يعمل في الوضع النشط النشط ، مع أخذ 50 ٪ من الحمل.
ولكن لا يوجد مال لمركز بيانات كامل ثان.
توصلوا إلى هذا:
يوجد خادم مادي ثقيل مع قاعدة بيانات في مركز بيانات العميل. وهناك تطبيقات تعمل مع قاعدة البيانات هذه ، وهي عبارة عن مجموعة من الأجهزة الافتراضية على ESXi.
لتكرار قاعدة البيانات ، قاموا بتثبيت برنامج Carbonite Availability (المعروف سابقًا باسم Double-Take Availability) في السحابة ، والتي تعمل على مستوى نظام التشغيل. ولنسخ الأجهزة الافتراضية التي قاموا بتثبيتها Zerto ، يعمل هذا البرنامج على مستوى برنامج Hypervisor. يعمل كلا الحلين بالطريقة نفسها تقريبًا: أولاً ، ينسخان الحجم الكامل لبيانات الخادم إلى السحابة ، ثم يعترضان جميع السجلات الموجودة على الأقراص على الموقع الرئيسي ويكررانها على الأقراص إلى السحابة. التأخير في هذه الحالة هو 10 ثوانٍ على وجه التحديد ، أي لدينا دائمًا نسخة حديثة من البيانات قبل 10 ثوانٍ.
لا يتم تضمين الأجهزة الافتراضية. باستخدام الزر من لوحة تحكم Zerto ، يمكننا بدء تشغيل جميع الأجهزة الافتراضية في وقت واحد. يحدث هذا في حوالي 28 دقيقة (تبدأ الآلات بالتوازي) ، SLA لمدة ساعة واحدة معنا خاملاً. يتم الإطلاق عن طريق الاتصال بمسؤول الواجب. يقرر العميل عند الحاجة.
VMs تلتقط القاعدة وتبدأ في العمل.
عندما يتم تشغيل الطاقة في المنشأة ، يفهم العميل نفسه بنيته التحتية. يتعامل مع الأعطال ، ثم يمكّن النسخ المتماثل يدويًا. يتم إرسال مقدار التغييرات في قاعدة البيانات المتراكمة أثناء تشغيل التطبيقات. منسوخ - مفتاح. في هذا المثال المحدد ، تتراكم حركة المرور لحوالي 5 دقائق من إعادة التحميل لكل ساعة من الأجهزة الافتراضية. كلما طال وقت تشغيل مثيل الطوارئ ، قل مشاركة حركة المرور ، لأن السجلات غالبًا ما تذهب إلى جداول قاعدة البيانات نفسها ، ونحن نرسل الفرق فقط.
بعد التبديل مرة أخرى في السحابة ، يتم إيقاف تشغيل الأجهزة الافتراضية. لا يدفع العميل مقابل الموارد التي تم إيقاف تشغيلها. نحن نقيس بالساعة.
الدفع هو فقط لمقدار البيانات المخزنة ، ترخيص القناة والبرمجيات للنسخ المتماثل (Zerto و Carbonite). نحن نعمل على مبدأ "التعافي من الكوارث كخدمة" ، وإعطاء اتفاقية مستوى الخدمة لذلك. والمسؤول مالياً عن اتفاقية مستوى الخدمة.
يكرر العميل كل شيء ، وهو جهاز افتراضي بنفس المعلمات الموجودة في الفيزياء ، وتعكس جميع محركات الأقراص.
هذا ما يفعله Zerto:
يحتوي على نسخ متماثل بدون وكيل ، ولديه وضع غير متزامن ، ويتم إيقاف تشغيل VMs على منصة DR ، ونسخ مجلة ، وتحسين WAN ، ونسخ عبر hypervisor ، وترخيص الأجهزة الظاهرية المحمية.
الكاربونايت هو تكرار عامل ، لذلك بغض النظر عن برنامج Hypervisor ، يوجد وضع تشغيل غير متزامن ، هناك دعم للقطات ، وضغط البيانات المرسلة ، وترخيص الأجهزة الافتراضية المحمية.
تطبيق التثبيت كلا الحلين في وقت واحد. لذلك كان من الضروري بسبب عدد من الميزات. عادة ما يقدمون شيئًا واحدًا.
يمكنك أيضًا حل مشكلة مشابهة مع حل Veeam Cloud Connect المحلي (نستخدمه عادةً إذا كان لديك بالفعل نسخة احتياطية من Veeam).
الملخص
ندرك جميعًا أنه يمكن حل المشكلة بشكل مختلف عن طريق ضخ التثبيت من جانب الخادم لمولد ديزل. ومع ذلك ، خفضت الأعمال متطلبات تنظيم الاحتياطي. قدمنا خدمة وعملت. اتضح أنه مثال جيد لكيفية نشر منصة DR بشكل صحيح وغير مكلف.
المراجع