Share via

فشل أجهزة VMware VMs بعد الإصلاح بعد الكارثة إلي Azure

  • مقالة

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

  • الفشل في العودة إلى الموقع الأصلي
  • الفشل في العودة إلى موقع بديل

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

ملاحظة

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

استرداد الموقع الأصلي (OLR)

إذا اخترت الفشل في العودة إلى الجهاز الظاهري الأصلي، فيجب استيفاء الشروط التالية:

  • إذا كان الجهاز الظاهري يُدار بواسطة خادم vCenter، فيجب أن يكون لمضيف ESX للهدف الرئيسي حق الوصول إلى مخزن بيانات الجهاز الظاهري.
  • إذا كان الجهاز الظاهري موجودًا على مضيف ESX ولكن لا تتم إدارته بواسطة vCenter، فيجب أن يكون القرص الثابت للجهاز الظاهري في مخزن بيانات يمكن لمضيف الهدف الرئيسي الوصول إليه.
  • إذا كان جهازك الظاهري موجودًا على مضيف ESX ولا يستخدم vCenter، فيجب عليك إكمال اكتشاف مضيف ESX للهدف الرئيسي قبل إعادة الكشف. ينطبق هذا إذا كنت تفشل في استرداد الخوادم المادية أيضًا.
  • يمكنك الفشل في العودة إلى شبكة منطقة التخزين الافتراضية (vSAN) أو القرص الذي يعتمد على تعيين الجهاز الأولي (RDM) إذا كانت الأقراص موجودة بالفعل ومتصلة بالجهاز الظاهري المحلي.

هام

من المهم تمكين disk.enableUUID = TRUE حتى تتمكن خدمة Azure Site Recovery أثناء إعادة المحاولة من تحديد VMDK الأصلي على الجهاز الظاهري الذي ستتم كتابة التغييرات المعلقة عليه. إذا لم يتم تعيين هذه القيمة لتكون TRUE، فستحاول الخدمة تحديد VMDK المحلي المقابل على أساس أفضل جهد. إذا لم يتم العثور على VMDK الصحيح، فإنه ينشئ قرصًا إضافيًا ويتم كتابة البيانات عليه.

استرداد موقع بديل (ALR)

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

  • عندما تفشل في العودة إلى موقع بديل، يتم استرداد الجهاز الظاهري إلى نفس مضيف ESX الذي تم نشر الخادم الهدف الرئيسي عليه. سيكون مخزن البيانات المستخدم لإنشاء قرص هو نفس مخزن البيانات الذي تم تحديده عند إعادة حماية الجهاز الظاهري.
  • يمكنك الفشل في العودة إلى نظام ملفات الجهاز الظاهري (VMFS) أو مخزن بيانات vSAN. إذا كان لديك RDM، فلن تعمل إعادة الحماية وإعادة الفشل.
  • تتضمن إعادة الحماية عملية نقل بيانات أولية كبيرة تليها التغييرات. توجد هذه العملية لأن الجهاز الظاهري غير موجود في أماكن العمل. ينبغي نسخ البيانات الكاملة مرة أخرى. ستستغرق عملية إعادة الحماية هذه أيضًا وقتًا أطول من استرداد الموقع الأصلي.
  • لا يمكنك الفشل في العودة إلى الأقراص المستندة إلى RDM. يمكن فقط إنشاء أقراص جهاز ظاهري جديدة (VMDKs) على مخزن بيانات VMFS / vSAN.

ملاحظة

عند فشل الجهاز الفعلي في Azure، يمكن أن يتعطل مرة أخرى فقط كجهاز VMware الظاهري. يتبع هذا نفس سير العمل مثل استرداد الموقع البديل. تأكد من اكتشاف خادم هدف رئيسي واحد على الأقل ومضيفات ESX / ESXi الضرورية التي تحتاج إلى الفشل في العودة إليها.

الخطوات التالية

اتبع الخطوات لتنفيذ عملية إعادة الفشل.