مرحبا قراء هبر! في المقالة الأخيرة ، تحدثنا عن وسيلة بسيطة للتعافي من الكوارث في أنظمة التخزين AERODISK ENGINE - النسخ المتماثل. في هذه المقالة ، سوف نتعمق في موضوع أكثر تعقيدًا وإثارة للاهتمام - metrocluster ، أي أداة آلية للحماية من الكوارث لمركزي بيانات يسمحان لمراكز البيانات بالعمل في الوضع النشط-النشط. سوف نخبر ونعرض ونكسر ونصلح.
كالعادة ، في بداية النظرية
الكتلة الكبرى هي مجموعة متباعدة في عدة مواقع داخل مدينة أو منطقة. تشير كلمة "الكتلة" بوضوح إلى أن المجمع مؤتمت ، أي أن تبديل العقد العنقودية في حالة الفشل (تجاوز الفشل) يحدث تلقائيًا.
هذا هو المكان الذي يكمن فيه الاختلاف الرئيسي بين metrocluster والنسخ المتماثل المنتظم. أتمتة العمليات. أي في حالة وقوع حوادث معينة (فشل مركز البيانات ، وانقطاع القنوات ، وما إلى ذلك) ، سيقوم نظام التخزين بشكل مستقل بتنفيذ الإجراءات اللازمة من أجل الحفاظ على توافر البيانات. عند استخدام النسخ المتماثلة العادية ، يتم تنفيذ هذه الإجراءات يدويًا كليًا أو جزئيًا بواسطة موجه النظام.
ما هو؟
الهدف الرئيسي الذي يسعى إليه العملاء الذين يستخدمون بعض تطبيقات metrocluster هو تقليل RTO (هدف وقت الاسترداد). أي لتقليل وقت استرداد خدمات تكنولوجيا المعلومات بعد الفشل. إذا كنت تستخدم النسخ المتماثل التقليدي ، فسيكون وقت الاسترداد دائمًا أكبر من وقت الاسترداد باستخدام مجموعة metro. لماذا؟ بسيط جدا. يجب أن يكون المسؤول في مكان العمل وأن يبدل النسخ المتماثل يدويًا ، بينما تقوم مجموعة metro بذلك تلقائيًا.
إذا لم يكن لديك مسؤول واجب مخصص لا ينام ، ولا يأكل ، ولا يدخن أو يمرض ، ولكن ينظر إلى حالة نظام التخزين على مدار 24 ساعة في اليوم ، فلا توجد طريقة لضمان أن المسؤول سيفعل ذلك. تكون متاحة للتبديل اليدوي أثناء الفشل.
وفقًا لذلك ، فإن RTO في حالة عدم وجود مجموعة مترو أو مشرف خالد للمستوى 99 من خدمة واجب المسؤولين ستكون مساوية لمجموع وقت التبديل لجميع الأنظمة وأقصى فترة زمنية يتم بعدها ضمان المسؤول بدء العمل مع نظام التخزين والأنظمة ذات الصلة.
وبالتالي ، توصلنا إلى استنتاج واضح مفاده أنه يجب استخدام الكتلة المعدنية إذا كانت متطلبات RTO هي دقائق ، وليس ساعات أو أيام. أي عندما ، في حالة حدوث أسوأ سقوط لمركز البيانات ، يجب على قسم تكنولوجيا المعلومات توفير العمل مع الوقت لاستعادة الوصول إلى خدمات تكنولوجيا المعلومات في غضون دقائق أو حتى ثوان.
كيف يعمل؟
في المستوى الأدنى ، يستخدم metrocluster آلية تكرار البيانات المتزامنة التي وصفناها في المقالة السابقة (انظر أدناه). ). نظرًا لأن النسخ متزامن ، فإن متطلباته مناسبة ، أو بالأحرى:
- الألياف كفيزياء ، 10 جيجابت إيثرنت (أو أعلى) ؛
- لا تزيد المسافة بين مراكز البيانات عن 40 كيلومترًا ؛
- تأخير القناة الضوئية بين مراكز البيانات (بين أنظمة التخزين) يصل إلى 5 مللي ثانية (على النحو الأمثل 2).
كل هذه المتطلبات استشارية بطبيعتها ، أي أن مجموعة المترو ستعمل حتى إذا لم يتم استيفاء هذه المتطلبات ، ولكن يجب أن يكون مفهوماً أن عواقب عدم الامتثال لهذه المتطلبات تساوي إبطاء تشغيل نظامي التخزين. في كتلة المترو.
لذلك ، يتم استخدام نسخة متماثلة متزامنة لنقل البيانات بين أنظمة التخزين ، ولكن كيف يتم تبديل النسخ المتماثلة تلقائيًا ، والأهم من ذلك ، كيفية تجنب تقسيم الدماغ؟ للقيام بذلك ، في المستوى أعلاه ، يتم استخدام كيان إضافي - الحكم.
كيف يعمل المحكم وما هي مهمته؟
الحكم عبارة عن آلة افتراضية صغيرة أو مجموعة أجهزة تحتاج إلى إطلاقها على موقع ثالث (على سبيل المثال ، في مكتب) وتوفر الوصول إلى التخزين عبر ICMP و SSH. بعد البدء ، يجب على الحكم تعيين IP ، ثم تحديد عنوانه من جانب التخزين ، بالإضافة إلى عناوين وحدات التحكم عن بُعد التي تشارك في مجموعة المترو. بعد ذلك ، يكون الحكم جاهزًا للانطلاق.
يراقب المحكم باستمرار جميع أنظمة التخزين في كتلة metro ، وفي حالة عدم توفر نظام تخزين معين ، بعد تأكيد عدم التوفر من عضو آخر في الكتلة (أحد أنظمة التخزين "الحية") ، يقرر بدء الإجراء لـ تبديل قواعد النسخ ورسم الخرائط.
نقطة مهمة جدا. يجب أن يكون الحكم دائمًا موجودًا في موقع مختلف عن تلك التي توجد بها أنظمة التخزين ، أي ليس في DPC 1 ، حيث يوجد التخزين 1 ، ولا في DPC 2 ، حيث يتم تثبيت التخزين 2.
لماذا؟ لأنه بهذه الطريقة فقط يمكن للحكم ، بمساعدة أحد أنظمة التخزين الباقية ، تحديد سقوط أي من الموقعين المثبتين لأنظمة التخزين بشكل لا لبس فيه وبدقة. قد تؤدي أي طريقة أخرى لوضع المحكم إلى انقسام الدماغ.
الآن دعنا نتعمق في تفاصيل وظيفة الحكم.
يتم تشغيل العديد من الخدمات على الحكم الذي يقوم باستمرار باستقصاء جميع وحدات التحكم في التخزين. إذا كانت نتيجة الاستطلاع تختلف عن النتيجة السابقة (متوفرة / غير متوفرة) ، فسيتم كتابتها في قاعدة بيانات صغيرة تعمل أيضًا على الحكم.
تأمل منطق الحكم بمزيد من التفصيل.
الخطوة 1. تحديد عدم التوفر. الحدث الذي يشير إلى فشل نظام التخزين هو عدم وجود اختبار ping من كل من وحدات التحكم في نفس نظام التخزين لمدة 5 ثوانٍ.
الخطوة 2. بدء إجراء التحويل. بعد أن أدرك المحكم أن أحد أنظمة التخزين غير متوفر ، أرسل طلبًا إلى نظام التخزين "المباشر" للتأكد من أن نظام التخزين "الميت" قد مات بالفعل.
بعد تلقي مثل هذا الأمر من المحكم ، يتحقق نظام التخزين (المباشر) الثاني بالإضافة إلى ذلك من توفر نظام التخزين الأول المتساقط ، وإذا لم يكن الأمر كذلك ، يرسل تأكيد المحكم لتخمينه. SHD ، في الواقع ، غير متوفر.
بعد تلقي هذا التأكيد ، يبدأ المحكم في إجراء عن بُعد لتبديل النسخ المتماثل ورفع التعيين على تلك النسخ المتماثلة التي كانت نشطة (أساسية) على نظام التخزين المتساقط ، ويرسل أمرًا إلى نظام التخزين الثاني لإنشاء هذه النسخ المتماثلة من الثانوي إلى الأساسي ورفع التعيين. حسنًا ، يقوم نظام التخزين الثاني ، على التوالي ، بتنفيذ هذه الإجراءات ، وبعد ذلك يوفر الوصول إلى LUNs المفقودة من تلقاء نفسه.
لماذا هناك حاجة إلى مزيد من التحقق؟ للنصاب. أي أن غالبية العدد الفردي (3) الإجمالي لأعضاء الكتلة يجب أن يؤكد سقوط إحدى العقد العنقودية. عندها فقط سيكون هذا القرار صحيحًا تمامًا. يعد هذا ضروريًا لتجنب التبديل الخاطئ ، وبالتالي ، تقسيم الدماغ.
تستغرق الخطوة 2 حوالي 5-10 ثوانٍ في الوقت المناسب ، لذلك ، مع الأخذ في الاعتبار الوقت المطلوب لتحديد عدم التوفر (5 ثوانٍ) ، في غضون 10-15 ثانية بعد الفشل ، ستتوفر LUNs مع نظام تخزين ساقط تلقائيًا للعمل مع البث المباشر تخزين.
من الواضح أنه لتجنب الانفصال عن المضيفين ، يجب عليك أيضًا الاهتمام بالإعداد الصحيح للمهلة على المضيفين. المهلة الموصى بها هي 30 ثانية على الأقل. هذا يمنع المضيف من قطع الاتصال بوحدة التخزين أثناء تحميل تجاوز الفشل ويمكن أن يضمن عدم انقطاع الإدخال / الإخراج.
انتظر لحظة ، اتضح أنه إذا كان كل شيء على ما يرام مع مجموعة المترو ، فلماذا نحتاج إلى نسخ منتظم على الإطلاق؟
في الواقع ، كل شيء ليس بهذه البساطة.
ضع في اعتبارك إيجابيات وسلبيات metrocluster
لذلك ، أدركنا أن المزايا الواضحة لـ metrocluster مقارنة بالنسخ المتماثل التقليدي هي:
- أتمتة كاملة ، تضمن الحد الأدنى من وقت التعافي في حالة وقوع كارثة ؛
- وهذا كل شيء :-).
والآن ، الانتباه ، السلبيات:
- تكلفة الحل. على الرغم من أن metrocluster في أنظمة Aerodisk لا يتطلب ترخيصًا إضافيًا (يتم استخدام نفس الترخيص للنسخة المتماثلة) ، إلا أن تكلفة الحل ستظل أعلى من استخدام النسخ المتزامن. سوف تحتاج إلى تنفيذ جميع متطلبات النسخة المتماثلة المتزامنة ، بالإضافة إلى متطلبات الكتلة المركزية المرتبطة بالتبديل الإضافي والموقع الإضافي (انظر تخطيط مجموعة المترو) ؛
- تعقيد القرار. يعد metrocluster أكثر تعقيدًا من النسخ المتماثلة العادية ، ويتطلب المزيد من الاهتمام والجهد للتخطيط والتكوين والتوثيق.
مؤخراً. من المؤكد أن Metrocluster هو حل تقني وجيد للغاية عندما تحتاج حقًا إلى توفير RTO في ثوانٍ أو دقائق. ولكن إذا لم تكن هناك مهمة من هذا القبيل ، وكان RTO في غضون ساعات مناسبًا للعمل ، فلن يكون من المنطقي إطلاق النار على العصافير من مدفع. يكفي التكرار المعتاد بين العمال والفلاحين ، لأن المترو سيتسبب في تكاليف إضافية وتعقيد البنية التحتية لتكنولوجيا المعلومات.
تخطيط كتلة المترو
لا يزعم هذا القسم أنه برنامج تعليمي شامل حول تصميم مجموعة المترو ، ولكنه يعرض فقط الاتجاهات الرئيسية التي يجب وضعها إذا قررت إنشاء مثل هذا النظام. لذلك ، أثناء التنفيذ الفعلي لمجموعة المترو ، تأكد من إشراك الشركة المصنعة لنظام التخزين (أي نحن) والأنظمة الأخرى ذات الصلة للاستشارة.
الأماكن
كما هو مذكور أعلاه ، تتطلب مجموعة المترو ثلاثة مواقع على الأقل. مركزان للبيانات ، حيث ستعمل أنظمة التخزين والأنظمة ذات الصلة ، بالإضافة إلى موقع ثالث حيث سيعمل الحكم.
المسافة الموصى بها بين مراكز البيانات لا تزيد عن 40 كيلومترًا. من المحتمل جدًا أن تتسبب المسافة الأكبر في حدوث تأخيرات إضافية ، وهو أمر غير مرغوب فيه للغاية في حالة مجموعة المترو. تذكر أن التأخيرات يجب أن تصل إلى 5 ميلي ثانية ، على الرغم من أنه من المستحسن الاحتفاظ بها في حدود 2.
يوصى أيضًا بفحص التأخيرات أثناء عملية التخطيط. يمكن لأي مقدم خدمات بالغ أو أقل يوفر الألياف بين مراكز البيانات تنظيم فحص الجودة بسرعة كبيرة.
بالنسبة للتأخيرات التي يتعرض لها المحكم (أي بين الموقع الثالث والموقعين الأولين) ، فإن حد التأخير الموصى به يصل إلى 200 مللي ثانية ، أي أن اتصال VPN المنتظم للشركة عبر الإنترنت سيفي بالغرض.
التبديل والشبكة
على عكس مخطط النسخ المتماثل ، حيث يكفي توصيل أنظمة التخزين من مواقع مختلفة ، يتطلب مخطط كتلة المترو توصيل المضيفين بكلا نظامي التخزين في مواقع مختلفة. لتوضيح الفرق ، تم سرد كلا النظامين أدناه.
كما ترون من الرسم التخطيطي ، لدينا مضيفو الموقع 1 ينظرون إلى كل من نظام التخزين 1 ونظام التخزين 2. أيضًا ، على العكس من ذلك ، ينظر مضيفو الموقع 2 إلى كل من نظام التخزين 2 ونظام التخزين 1. أي أن كل مضيف يرى كلا نظامي التخزين. هذا شرط أساسي لتشغيل metrocluster.
بالطبع ، ليست هناك حاجة لسحب كل مضيف بسلك ضوئي إلى مركز بيانات آخر ، فلن يكون هناك ما يكفي من المنافذ والأسلاك. يجب إجراء جميع هذه الاتصالات من خلال محولات Ethernet 10G + أو FibreChannel 8G + (FC فقط لتوصيل المضيفين والتخزين لـ IO ، قناة النسخ المتماثل متاحة حاليًا فقط عبر IP (Ethernet 10G +).
الآن بضع كلمات حول طوبولوجيا الشبكة. النقطة المهمة هي التكوين الصحيح للشبكات الفرعية. يجب تحديد عدة شبكات فرعية على الفور للأنواع التالية من حركة المرور:
- الشبكة الفرعية للنسخ المتماثل ، والتي من خلالها ستتم مزامنة البيانات بين أنظمة التخزين. قد يكون هناك العديد منهم ، في هذه الحالة لا يهم ، كل هذا يتوقف على طوبولوجيا الشبكة الحالية (التي تم تنفيذها بالفعل). إذا كان هناك اثنان منهم ، فمن الواضح أنه يجب تكوين التوجيه بينهما ؛
- شبكات التخزين الفرعية التي سيصل من خلالها المضيفون إلى موارد التخزين (إذا كان بروتوكول iSCSI). يجب أن يكون هناك شبكة فرعية واحدة في كل مركز بيانات ؛
- التحكم في الشبكات الفرعية ، أي ثلاث شبكات فرعية قابلة للتوجيه في ثلاثة مواقع يتم من خلالها إدارة التخزين ، كما يوجد الحكم هناك.
نحن لا نعتبر الشبكات الفرعية للوصول إلى موارد المضيف هنا ، لأنها تعتمد بشكل كبير على المهام.
يعد فصل حركة المرور المختلفة إلى شبكات فرعية مختلفة أمرًا بالغ الأهمية (من المهم بشكل خاص فصل النسخة المتماثلة عن الإدخال / الإخراج) ، لأنه إذا قمت بخلط كل حركة المرور في شبكة فرعية واحدة "سميكة" ، فسيكون من المستحيل إدارة حركة المرور هذه ، وفي ظروف اثنين من مراكز البيانات لا يزال من الممكن أن يتسبب ذلك في العديد من خيارات تضارب الشبكة. لن نتعمق في هذه المشكلة في إطار هذه المقالة ، حيث يمكنك أن تقرأ عن التخطيط لشبكة ممتدة بين مراكز البيانات على موارد الشركات المصنعة لمعدات الشبكة ، حيث يتم وصف ذلك بتفصيل كبير.
تكوين الحكم
يحتاج المحكم إلى توفير الوصول إلى جميع واجهات التحكم في نظام التخزين عبر بروتوكولات ICMP و SSH. يجب أن تفكر أيضًا في تحمل الحكم للخطأ. هناك فارق بسيط هنا.
الحكم الفشل أمر مرغوب فيه للغاية ، ولكن ليس مطلوبًا. وماذا يحدث إذا تعطل المحكم في الوقت الخطأ؟
- لن يتغير تشغيل metrocluster في الوضع العادي ، لأن لا يؤثر arbtir على تشغيل مجموعة المترو في الوضع العادي بأي شكل من الأشكال (مهمتها هي تبديل الحمل بين مراكز البيانات في الوقت المناسب)
- في الوقت نفسه ، إذا سقط الحكم لسبب أو لآخر و "نام" الحادث في مركز البيانات ، فلن يحدث تبديل ، لأنه لن يكون هناك من يعطي أوامر التبديل اللازمة وينظم النصاب القانوني. في هذه الحالة ، ستتحول مجموعة المترو إلى مخطط تكرار منتظم ، والذي سيتعين تبديله يدويًا أثناء وقوع كارثة ، مما سيؤثر على RTO.
ماذا يتبع من هذا؟ إذا كنت تحتاج حقًا إلى توفير حد أدنى من RTO ، فأنت بحاجة إلى التأكد من تسامح الحكم مع الخطأ. هناك خياران لهذا:
- قم بتشغيل آلة افتراضية بحكم على برنامج Hypervisor المتسامح مع الأخطاء ، نظرًا لأن جميع برامج Hypervisor البالغين تدعم التسامح مع الخطأ ؛
- إذا كان في الموقع الثالث (في المكتب الشرطي) كسولًا جدًا في تثبيت مجموعة عادية ولا توجد مجموعة موجودة من برامج Hypervisor ، فقد قدمنا إصدارًا من جهاز الحكم ، والذي تم إنشاؤه في مربع 2U ، حيث تعمل خوادم x-86 العادية والتي يمكن أن تنجو من فشل محلي.
نوصي بشدة بضمان التسامح مع الخطأ للحكم ، على الرغم من حقيقة أن مجموعة المترو لا تحتاجها في الوضع العادي. ولكن كما تظهر كل من النظرية والتطبيق ، إذا قمت ببناء بنية تحتية موثوقة حقًا تتحمل الكوارث ، فمن الأفضل تشغيلها بأمان. من الأفضل حماية نفسك وعملك من "قانون الخسة" ، أي من فشل كل من المحكم وأحد المواقع التي يوجد بها نظام التخزين.
هندسة الحل
بالنظر إلى المتطلبات المذكورة أعلاه ، نحصل على هندسة الحلول العامة التالية.
يجب توزيع LUNs بالتساوي عبر الموقعين لتجنب الازدحام الشديد. في الوقت نفسه ، عند التحجيم في كلا مركزي البيانات ، من الضروري توفير ليس فقط ضعف الحجم (وهو أمر ضروري لتخزين البيانات في وقت واحد على نظامي تخزين) ، ولكن أيضًا أداء مزدوج في IOPS و MB / s من أجل منع تدهور التطبيقات في حالة فشل أحد مراكز البيانات - ov.
بشكل منفصل ، نلاحظ أنه مع النهج المناسب للتحجيم (أي ، بشرط أن نقدم الحدود العليا المناسبة لـ IOPS و MB / s ، بالإضافة إلى موارد وحدة المعالجة المركزية وذاكرة الوصول العشوائي الضرورية) ، إذا كان أحد أنظمة التخزين في فشل كتلة المترو ، لن يكون هناك انخفاض خطير في الأداء في ظروف العمل المؤقت على نظام تخزين واحد.
ويفسر ذلك حقيقة أنه في ظروف موقعين يعملان في وقت واحد ، فإن تشغيل النسخ المتماثل المتزامن "يأكل" نصف أداء الكتابة ، حيث يجب كتابة كل معاملة على نظامي تخزين (على غرار RAID-1/10). لذلك ، إذا فشل أحد أنظمة التخزين ، فإن تأثير النسخ المتماثل مؤقتًا (حتى يرتفع نظام التخزين الفاشل) يختفي ، ونحصل على زيادة مضاعفة في أداء الكتابة. بعد إعادة تشغيل LUNs لنظام التخزين الفاشل على نظام التخزين العامل ، تختفي هذه الزيادة المزدوجة نظرًا لوجود حمل من LUNs لنظام تخزين آخر ، ونعود إلى نفس مستوى الأداء الذي كان لدينا قبل "تقع" ، ولكن فقط داخل نفس المنصة.
بمساعدة التحجيم المختص ، من الممكن توفير ظروف لا يشعر فيها المستخدمون بفشل نظام التخزين بأكمله على الإطلاق. ولكن مرة أخرى ، يتطلب هذا تحجيمًا دقيقًا للغاية ، والذي ، بالمناسبة ، يمكنك الاتصال بنا مجانًا :-).
إنشاء كتلة مترو
يشبه إنشاء مجموعة metro إلى حد كبير إعداد النسخ المتماثل المنتظم ، والذي وصفناه في . لذلك دعونا نركز فقط على الاختلافات. أنشأنا مقعدًا في المختبر بناءً على البنية أعلاه ، فقط في الإصدار الأدنى: نظامان للتخزين متصلان عبر 10G Ethernet ببعضهما البعض ، ومحولان 10G ومضيف واحد يبحث من خلال المحولات إلى كلا نظامي التخزين بمنافذ 10G. يعمل المحكم على جهاز افتراضي.
عند تكوين IP الظاهري (VIP) لنسخة متماثلة ، يجب عليك تحديد نوع VIP - لمجموعة metro.
تم إنشاء ارتباطي نسخ متماثل لاثنين من LUNs وتوزيعهما على نظامي تخزين: LUN TEST Primary على التخزين 1 (اتصال METRO) ، LUN TEST2 Primary للتخزين 2 (اتصال METRO2).
بالنسبة لهم ، قمنا بتكوين هدفين متطابقين (في حالتنا ، iSCSI ، لكن FC مدعوم أيضًا ، منطق التكوين هو نفسه).
تخزين 1:
تخزين 2:
بالنسبة إلى روابط النسخ المتماثل ، تم إجراء التعيينات على كل نظام تخزين.
تخزين 1:
تخزين 2:
قمنا بإعداد متعدد المسارات وقدمناه إلى المضيف.
إنشاء حكم
لست بحاجة إلى القيام بأي شيء خاص مع الحكم نفسه ، ما عليك سوى تشغيله على الموقع الثالث ، وتعيين IP الخاص به وتهيئة الوصول إليه عبر ICMP و SSH. يتم تنفيذ التكوين نفسه من أنظمة التخزين نفسها. في الوقت نفسه ، يكفي تكوين الحكم مرة واحدة على أي من وحدات التحكم في التخزين في مجموعة المترو ، وسيتم توزيع هذه الإعدادات على جميع وحدات التحكم تلقائيًا.
ضمن النسخ المتماثل البعيد >> Metrocluster (على أي وحدة تحكم) >> زر التكوين.
ندخل عنوان IP للحكم ، وكذلك واجهات التحكم لوحدتي التحكم في التخزين البعيد.
بعد ذلك ، تحتاج إلى تمكين جميع الخدمات (زر "إعادة تشغيل كل شيء"). إذا قمت بإعادة التكوين في المستقبل ، فيجب إعادة تشغيل الخدمات حتى تدخل الإعدادات حيز التنفيذ.
نتحقق من تشغيل جميع الخدمات.
هذا يكمل الإعداد metrocluster.
اختبار التصادم
سيكون اختبار التصادم في حالتنا بسيطًا وسريعًا للغاية ، نظرًا لأن وظيفة النسخ المتماثل (التبديل ، والاتساق ، وما إلى ذلك) تم اعتبارها في . لذلك ، لاختبار موثوقية مجموعة المترو ، يكفي أن نتحقق من أتمتة اكتشاف الحوادث والتبديل وعدم وجود خسائر في الكتابة (توقفات الإدخال / الإخراج).
للقيام بذلك ، نقوم بمحاكاة فشل كامل لأحد أنظمة التخزين عن طريق إيقاف تشغيل كل من وحدات التحكم الخاصة به فعليًا ، بعد البدء في نسخ ملف كبير إلى LUN ، والذي يجب تنشيطه على نظام تخزين آخر.
تعطيل نظام تخزين واحد. في نظام التخزين الثاني ، نرى تنبيهات ورسائل في السجلات تفيد بأن الاتصال بالنظام المجاور قد اختفى. إذا تم تكوين الإشعارات عبر مراقبة SMTP أو SNMP ، فسيتم إرسال الإخطارات المناسبة إلى المسؤول.
بعد 10 ثوانٍ بالضبط (كما هو موضح في كلتا اللقطتين) ، أصبح رابط النسخ المتماثل METRO (الذي كان أساسيًا في نظام التخزين المتساقط) تلقائيًا أساسيًا في نظام التخزين العامل. باستخدام التعيين الحالي ، ظل LUN TEST متاحًا للمضيف ، وانخفض التسجيل قليلاً (في حدود 10 بالمائة الموعودة) ، لكنه لم يتوقف.
اكتمل الاختبار بنجاح.
تلخيص
يتيح لك التنفيذ الحالي للعنقود المعدني في أنظمة التخزين AERODISK Engine N-series بشكل كامل حل المشكلات حيث تحتاج إلى التخلص من وقت تعطل خدمات تكنولوجيا المعلومات أو تقليله وضمان تشغيلها في وضع 24/7/365 بأقل تكاليف العمالة.
يمكنك القول ، بالطبع ، أن كل هذا نظري ، وظروف معملية مثالية ، وما إلى ذلك ... ولكن لدينا عددًا من المشاريع المنفذة التي نفذنا فيها وظيفة التعافي من الكوارث ، وتعمل الأنظمة بشكل مثالي. وافق أحد عملائنا المعروفين إلى حدٍ ما ، حيث يتم استخدام نظامي تخزين فقط في تكوين متسامح مع الكوارث ، على نشر معلومات حول المشروع ، لذلك سنتحدث في الجزء التالي عن تنفيذ القتال.
شكرا ، أتطلع إلى مناقشة مثمرة.
المصدر: www.habr.com