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