استمرارية الأعمال والإصلاح بعد كارثة ل Azure VMware Solution

يساعد هذا السيناريو على نطاق المؤسسة على تحسين استمرارية الأعمال والإصلاح بعد كارثة (BCDR). يوفر Azure VMware Solutionسحبا خاصة تحتوي على مجموعات VMware vSphere التي تم إنشاؤها من البنية الأساسية المخصصة ل Azure بلا نظام تشغيل. يوفر الحل ما لا يقل عن ثلاثة مضيفين ESXi، بحد أقصى 16 مضيفا لكل نظام مجموعة. تحتوي جميع السحب الخاصة المتوفرة على خادم VMware vCenter وVMware vSAN وVMware vSphere ومركز بيانات VMware NSX-T. للتعرف على اتفاقية مستوى الخدمة (SLA) ل Azure VMware Solution، راجع اتفاقية مستوى الخدمة ل Azure VMware Solution.

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

ملاحظة

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

اعتبارات تصميم استمرارية الأعمال

• يتم تنفيذ نهج تخزين VMware vSAN على Azure VMware Solution مع مراعاة توفر التخزين. عندما يحتوي نظام المجموعة على ما بين ثلاثة وخمسة مضيفين، فإن عدد حالات فشل المضيف التي يمكن تحملها دون فقدان البيانات يساوي واحدا. عندما يحتوي نظام المجموعة على ما بين 6 و16 مضيفا، فإن عدد حالات فشل المضيف في التحمل قبل حدوث فقدان البيانات يساوي اثنين. يمكن تطبيق نهج تخزين VMware vSAN على أساس كل جهاز ظاهري. في حين أن هذه النهج هي النهج الافتراضية، يمكنك تعديل النهج ليناسب المتطلبات المخصصة. لمزيد من المعلومات، راجع مفاهيم تخزين Azure VMware Solution.

• يتم تمكين التوفر العالي ل vSphere بشكل افتراضي على Azure VMware Solution. يحتفظ نهج القبول عالي التوفر بسعة الحوسبة والذاكرة لعقدة واحدة. يضمن هذا الحجز سعة كافية لإعادة تشغيل أحمال العمل في عقدة أخرى في نظام مجموعة Azure VMware Solution.

• قابلية وصول عالية مع نظام مجموعة التمدد: مع Azure VMware Solution، يتواجد مضيفو ESXi الموزعون في مجموعة vSphere قياسية تقليديا في منطقة توفر Azure واحدة وتتم حمايتهم بواسطة توفر vSphere العالي. ومع ذلك، لا تتم حماية أحمال العمل من فشل منطقة التوفر. للحماية من الفشل، يمكن أن تمتد مجموعة vSAN واحدة عبر منطقتين منفصلتين للتوفر، تسمى مجموعة vSAN الممتدة. لمزيد من المعلومات، راجع توزيع مجموعات vSAN الممتدة.

• اختر حل نسخ احتياطي تم التحقق من صحته لأجهزة VMware vSphere الظاهرية (VMs)، مثل Microsoft Azure Backup Server أو حل النسخ الاحتياطي للشريك.

• للحصول على معلومات حول الميزات المدعومة في حلول النسخ الاحتياطي للشريك، راجع وثائق الشريك المعنية.

  ملاحظة

  يتم نسخ تكوينات vCenter Server وNSX-T Data Center للسحب الخاصة احتياطيا كل ساعة، ويتم الاحتفاظ بالنسخ الاحتياطية لمدة ثلاثة أيام.

• مكونات Azure VMware Solution مثل vCenter Server أو NSX-T Manager أو HCX Manager هي خدمات مدارة تتم إدارة النسخ الاحتياطي لها بواسطة Azure. للاستعادة من نسخة احتياطية، قم بإنشاء طلب دعم Azure.

توصيات تصميم استمرارية الأعمال

• استخدم Azure Backup Server لنسخ سحابة Azure VMware Solution الخاصة احتياطيا. لمزيد من المعلومات، راجع النسخ الاحتياطي لأجهزة VMware vSphere الظاهرية باستخدام Azure Backup. تتضمن طبولوجيا التوزيع المدعومة عامل MARS وإدارة حماية البيانات. كل مخطط توزيع له مصفوفة دعم وقيود وقيود خاصة به.

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

• يمكن نشر Azure Backup كجهاز ظاهري للبنية الأساسية ل Azure كخدمة (IaaS) أو داخل السحابة الخاصة ل Azure VMware Solution. يوصى بشدة بنشره خارج سحابة Azure VMware Solution الخاصة. انشر النسخ الاحتياطي في شبكة Azure الظاهرية وتأكد من توصيل هذه الشبكة الظاهرية بنفس ExpressRoute المتصل بالسحابة الخاصة ل Azure VMware Solution. يساعد تشغيل خادم النسخ الاحتياطي خارج سحابة Azure VMware Solution الخاصة على تقليل استهلاك vSAN، نظرا لأن vSAN هو مورد سعة محدود داخل السحابة الخاصة ل Azure VMware Solution.

  تم نشر Azure Backup Server كجهاز Azure IaaS ظاهري.

  

  تم نشر Azure Backup Server ك Azure VMware Solution VM.

  

• استخدم قائمة التحقق من متطلبات أداء التطبيق للوصول إلى السعة الصحيحة ونوع القرص، مثل HDD أو SSD أو Ultra. ضع في اعتبارك Azure IaaS VM SKU الذي يدعم نوع القرص وسعة عمليات النسخ الاحتياطي.

• استخدم مخطط سعة Azure Backup Server لتحديد عدد الخوادم والتخزين ومتطلبات IOPS لكل منها. عند توفير قيمة "الحجم الإجمالي لحمل العمل (GB)*" في مخطط السعة، استخدم القيمة الوسيطة بين "التخزين المستخدم" و"التخزين المخصص" لجميع الأجهزة الظاهرية في vCenter التي تريد نسخها احتياطيا.

• استخدم تجمعات التخزين مع Azure Backup Server لتحسين IOPS/معدل النقل للقرص. استخدم التخزين المتدرج على خادم النسخ الاحتياطي للعمليات المحسنة.

• تحديد عدد مهام النسخ الاحتياطي المتوازية وعمليات الاستعادة لتشغيلها على خادم Azure Backup. حاليا، يتم دعم 8 مهام نسخ احتياطي متوازية. قياس مقدار الوقت المستغرق للنسخ الاحتياطي واستعادة أحمال العمل الحرجة للمهمة عبر عمليات تشغيل متعددة. تحقق من أن أوقات النسخ الاحتياطي والاستعادة تفي بمتطلبات RPO وRTO لخادم Azure Backup. تأكد من أن مخزن بيانات AVS vSAN لديه سعة كافية للاحتفاظ بالنسخ الاحتياطي المستعادة.

• أضف استثناءات مكافحة الفيروسات الضرورية لملفات ومجلدات Azure Backup Server كما هو موثق هنا إذا كان أي برنامج مكافحة الفيروسات/مكافحة البرامج الضارة يعمل على Azure Backup Server. عند استخدام عامل حماية DPM على أي Azure VMware Solution VM للنسخ الاحتياطي للتطبيق (على سبيل المثال SQL وSharepoint وما إلى ذلك)، قم بتعطيل مراقبة dpmra.exeفي الوقت الحقيقي.

• قم بتكوين قواعد NSG المناسبة (مجموعة أمان الشبكة) على الشبكة الفرعية التي تستضيف Azure Backup Server للسماح بالاتصال بالشبكة من عامل حماية DPM الذي يعمل على الجهاز الظاهري المحمي في Azure VMware Solution. يتصل عامل حماية DPM بخادم Azure Backup على أي منفذ ديناميكي بين 1024 و65535.

• حاليا، لا يدعم Azure Backup Server الاستعادة عبر المناطق للسحابة الخاصة ل Azure VMware Solution. راجع قسم حلول النسخ الاحتياطي للشريكوالإصلاح بعد كارثة عند الحاجة إلى استرداد Azure VMware Solution عبر المناطق.

اعتبارات تصميم الإصلاح بعد كارثة

• مواءمة متطلبات العمل مع أهداف وقت الاسترداد (RTO) والسعة وأهداف نقطة الاسترداد (RPO) للتطبيقات. التخطيط والتصميم وفقا لذلك لتحقيق هذه الأهداف باستخدام تقنية النسخ المتماثل الأكثر ملاءمة. على سبيل المثال، نسخ قواعد بيانات SQL بشكل أصلي باستخدام مجموعة قابلية وصول عالية التوفر SQL AlwaysOn، أو استخدام أداة الإصلاح بعد كارثة مثل VMware Site Recovery Manager.

• حدد موقع الإصلاح بعد كارثة الهدف للسحابة الخاصة ل Azure VMware Solution المحمية. يؤثر هذا الموقع على أدوات الإصلاح بعد كارثة المناسبة للبيئة. على سبيل المثال، إذا كنت ترغب في استرداد أحمال عمل Azure VMware Solution إلى أجهزة IaaS الظاهرية الأصلية في Azure، فإن Zerto هو الحل الوحيد.

• حدد المجموعة الفرعية من أحمال عمل Azure VMware Solution التي تتطلب الحماية إذا كان هناك حدث استرداد بعد كارثة. ضع في اعتبارك تصنيف أحمال العمل استنادا إلى الأولوية: P0 لأحمال العمل الحرجة للأعمال، وP1، وP2، وP3 لأحمال العمل الأخرى المهمة ولكنها ليست مهمة للأعمال. تحدد خطة استمرارية الأعمال للعميل مستويات الأولوية، مما يساعد على التحكم في التكاليف المرتبطة بتنفيذ الإصلاح بعد كارثة.

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

• بالنسبة لعمليات نشر الضوء التجريبي خاصة، تأكد من تأمين جميع الحصة النسبية للمضيف المطلوبة في الموقع الثانوي بحيث لا تضطر إلى انتظار السعة المطلوبة أثناء التوسع الكامل. راجع طلب الحصة النسبية للمضيف ل Azure VMware Solution.

• إعداد أدوار المجال الوظيفية، مثل وحدات تحكم مجال Active Directory، في البيئة الثانوية.

• تتوفر الحلول من شركاء مثل JetStream وZerto بشكل عام ويتم التحقق من صحتها على Azure VMware Solution. وهي تدعم معظم سيناريوهات الإصلاح بعد كارثة ويمكن أن توفر استردادا أسرع مع RPO شبه الصفري.

• يدعم VMware Site Recovery Manager و Jetstream وZerto الترحيل من مواقع الجهات الخارجية إلى Azure VMware Solution.

• VMware HCX هو أيضا حل فعال من حيث التكلفة للإصلاح بعد كارثة. ومع ذلك، لا يوصى به لأحمال عمل الإنتاج الكبيرة بسبب التزامن اليدوي.

• للإصلاح بعد كارثة بين السحب الخاصة ل Azure VMware Solution في مناطق Azure المختلفة، تحتاج إلى تمكين ExpressRoute Global Reach بين كل من دوائر ExpressRoute الخلفية. تنشئ هذه الدوائر اتصالا سحابيا خاصا أساسيا إلى ثانويا عند الحاجة لحلول مثل VMware SRM وVMware HCX.

• للإصلاح بعد كارثة بين السحب الخاصة ل Azure VMware Solution في نفس منطقة Azure، تحتاج إلى تمكين Azure VMware Solution Interconnect. ينشئ رابط توجيه بين شبكات الإدارة وأحمال العمل للسحب الخاصة ل Azure VMware Solution للاتصال بين السحب. تأكد من أن مساحة عنوان IP الموجهة في كل سحابة خاصة فريدة ولا تتداخل.

• عند العمل مع الإصلاح بعد كارثة، يمكنك استخدام نفس مساحة عنوان IP المصدر في منطقة Azure الأساسية ومنطقة Azure الثانوية. ومع ذلك، فإنه يتطلب جهود تصميم وهندسة إضافية.

  • الاحتفاظ بنفس عناوين IP: يمكن استرداد الأجهزة الظاهرية في موقع Azure VMware Solution الثانوي باستخدام نفس عنوان IP المصدر مثل الموقع الأساسي. لهذا الأسلوب، قم بإنشاء شبكات VLAN المعزولة أو مقاطع NSX-T في الموقع الثانوي وتأكد من عدم توصيل أي من شبكات VLAN أو المقاطع المعزولة هذه بالبيئة. قم بتعديل مسارات الإصلاح بعد كارثة لتعكس أن الشبكة الفرعية قد انتقلت إلى الموقع الثانوي وموقع عناوين IP الجديد. بينما يعمل هذا الأسلوب، فإنه ينشئ أيضا نفقات هندسية عند استهداف الإصلاح بعد كارثة المؤتمت بالكامل.

  • استخدام عناوين IP مختلفة: يمكنك أيضا استخدام عناوين IP مختلفة للأجهزة الظاهرية المستردة. إذا تم نقل الجهاز الظاهري إلى موقع ثانوي، فإن خطة الاسترداد داخل VMware Site Recovery Manager توضح تفاصيل خريطة IP المخصصة. حدد هذه الخريطة لتغيير عنوان IP. يتم إحضار الأجهزة الظاهرية في مقاطع NSX-T الجديدة ويتم تعيين عناوين IP جديدة. يمكن أن تختلف الأدوات لحلول الإصلاح بعد كارثة المختلفة.

• العوامل المهمة لسيناريوهات الإصلاح بعد كارثة الجزئية والكاملة:

  • يدعم VMware Site Recovery Manager الاسترداد الجزئي، والذي يسترد مجموعة فرعية فقط من الأجهزة الظاهرية، والإصلاح الكامل بعد كارثة. بين موقعين من مواقع Azure VMware Solution في المنطقة 1 والمنطقة 2، يمكن أن تفشل جميع الأجهزة الظاهرية أو بعضها.

  • يحدد شرط استبقاء عنوان IP المصدر للأجهزة الظاهرية المستردة ما إذا كان الإصلاح الجزئي مقابل التعافي الكامل من الكوارث ممكنا.

  • للحفاظ على عنوان IP المصدر أثناء إجراء الإصلاح الجزئي بعد كارثة في Site Recovery Manager، تحتاج بوابة الشبكة الفرعية إلى الانتقال إلى الموقع الثانوي.

  ملاحظة

  لا يتطلب الإصلاح بعد كارثة في وضع الاستعداد النشط تمديد الطبقة 2.

توصيات تصميم الإصلاح بعد كارثة

• استخدم إدارة استرداد موقع VMware عند العمل مع Azure VMware Solution في كل من المواقع الأساسية والثانوية. وتعرف المواقع الأساسية والثانوية أيضا باسم مواقع الحماية والاسترداد، على التوالي.

  نظرة عامة عالية المستوى على النسخ المتماثل vSphere المستمر.

  

  مثال مفصل على النسخ المتماثل vSphere المستمر بين المواقع الأساسية والثانوية.

  

• بالنسبة للتطبيقات المهمة للأعمال، تتوفر Zerto و JetStream كحلول للإصلاح بعد كارثة للسحابة الخاصة ل Azure VMware Solution. تم بناء JetStream وZerto على أساس حماية البيانات المستمرة (CDP)، باستخدام VMware vSphere API لإطار عمل تصفية الإدخال/الإخراج (VAIO)، والذي يتيح الحد الأدنى من فقدان البيانات أو إغلاقه. كما أنه يتيح الإصلاح بعد كارثة بتكلفة فعالة باستخدام الحد الأدنى من الموارد.

• استخدم Zerto إذا كانت الأجهزة الظاهرية ل Azure IaaS هي هدف الإصلاح بعد كارثة للسحابة الخاصة ل Azure VMware Solution.

• تقليل الإدخال اليدوي باستخدام خطط الاسترداد التلقائية داخل كل من حلول الإصلاح بعد كارثة المعنية. هذه الخطط مفيدة عند العمل إما مع VMware Site Recovery Manager أو حلول الشركاء. تجمع خطة الاسترداد الأجهزة في مجموعات استرداد لتجاوز الفشل. ثم يساعد على تحديد عملية استرداد منهجية عن طريق إنشاء وحدات مستقلة يمكن أن تتجاوز الفشل.

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

• استخدم الأزواج الإقليمية الجيوسياسية كبيئة ثانوية للتعافي من الكوارث. بعض فوائد الأزواج الإقليمية هي استرداد المنطقة ذات الأولوية والتحديثات المتسلسلة والعزل المادي وإقامة البيانات.

• حافظ على مسافات العناوين المختلفة لتجنب تداخل عناوين IP بين الموقعين. على سبيل المثال، يمكنك استخدام 192.168.0.0/16 للمنطقة 1 وللمنطقة 10.0.0.0/16 2.

• استخدم اتصال ExpressRoute Global Reach بين السحب الخاصة الأساسية والثانوية في مناطق مختلفة. راجع المزيد من اعتبارات وتوصيات الشبكات في مجال التصميم ذي الصلة.

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

تعرف على الاعتبارات والتوصيات للتوزيع الأولي ل Azure VMware Solution وإرشادات التشغيل التلقائي.

أتمتة النظام الأساسي ل Azure VMware Solution