مشاركة عبر

إعداد استرداد بعد عطل فادح لـ Active Directory وDNS

  • مقالة

تعتمد تطبيقات المؤسسات مثل SharePoint و Dynamics AX و SAP على Active Directory والبنية الأساسية لـ DNS لتعمل بشكل صحيح. عند إعداد الإصلاح بعد الكارثة للتطبيقات، فغالبًا ما تحتاج إلى استرداد Active Directory ونظام أسماء المجالات (DNS) قبل استعادة مكونات التطبيق الأخرى، لضمان صحة وظائف التطبيق.

يمكنك استخدام Site Recovery لإنشاء خطة الإصلاح بعد الكارثة لـ Active Directory. عند حدوث اضطراب، يمكنك بدء تجاوز الفشل. يمكنك تشغيل Active Directory في غضون بضع دقائق. إذا قمت بنشر Active Directory لتطبيقات متعددة في موقعك الأساسي، على سبيل المثال، لـ SharePoint و SAP، فقد ترغب في تجاوز الفشل في الموقع بالكامل. يمكنك تجاوز الفشل أولاً على Active Directory باستخدام Site Recovery. بعد ذلك، تجاوز الفشل في التطبيقات الأخرى باستخدام خطط الاسترداد الخاصة بالتطبيقات.

تشرح هذه المقالة كيفية إنشاء حل الإصلاح بعد كارثة لـ Active Directory. يتضمن المتطلبات الأساسية وإرشادات تجاوز الفشل. يجب أن تكون على دراية بـ Active Directory وSite Recovery قبل أن تبدأ.

المتطلبات الأساسية

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

إجراء نسخ متماثل لوحدة تحكم المجال

  • يجب عليك إعداد النسخ المتماثل لاستعادة الموقع، على جهاز ظاهري واحد على الأقل (VM) يستضيف وحدة تحكم مجال أو DNS.
  • إذا كان لديك العديد من وحدات تحكم المجال في بيئتك، فيجب عليك أيضًا إعداد وحدة تحكم مجال إضافية على الموقع الهدف. يمكن أن تكون وحدة التحكم بالمجال الإضافية في Azure، أو في مركز بيانات محلي ثانوي.
  • إذا كان لديك عدد قليل من التطبيقات ووحدة تحكم مجال واحدة، فقد ترغب في الفشل عبر الموقع بأكمله معاً. في هذه الحالة، نوصي باستخدام "استرداد الموقع" لنسخ وحدة تحكم المجال إلى الموقع الهدف، إما في Azure أو في مركز بيانات محلي ثانوي. يمكنك استخدام نفس وحدة التحكم بالمجال المنسوخة أو الجهاز الظاهري لنظام أسماء النطاقات من أجل اختبار تجاوز الفشل .
  • إذا كان لديك العديد من التطبيقات وأكثر من وحدة تحكم مجال في بيئتك، أو إذا كنت تخطط للفشل في بعض التطبيقات في وقت واحد، بالإضافة إلى نسخ الجهاز الظاهري لوحدة التحكم بالمجال مع Site Recovery، نوصيك بإعداد عنصر إضافي وحدة تحكم المجال على الموقع الهدف (إما في Azure أو في مركز بيانات محلي ثانوي). بالنسبة إلى اختبار تجاوز الفشل ، يمكنك استخدام وحدة تحكم المجال التي يتم نسخها من خلال Site Recovery. تجاوز الفشل، يمكنك استخدام وحدة تحكم مجال إضافية على الموقع الهدف.

تمكين الحماية باستخدام Site Recovery

يمكنك استخدام Site Recovery لحماية الجهاز الظاهري الذي يستضيف وحدة تحكم المجال أو DNS.

حماية الجهاز الظاهري

يتم استخدام وحدة تحكم المجال التي يتم نسخها من خلال استخدام Site Recovery في اختبار تجاوز الفشل . تأكد من أنها تفي بالمتطلبات التالية:

  1. وحدة تحكم المجال هو خادم نشرة مصورة عمومية.
  2. يجب أن تكون وحدة التحكم بالمجال هي مالك دور العمليات الرئيسية المفردة المرنة (FSMO) للأدوار المطلوبة أثناء اختبار تجاوز الفشل. وبخلاف ذلك، يجب الاستيلاء على هذه الأدوار بعد تجاوز الفشل.

تكوين إعدادات شبكة الجهاز الظاهري

بالنسبة للجهاز الظاهري الذي يستضيف وحدة تحكم المجال أو DNS، في Site Recovery، قم بتكوين إعدادات الشبكة ضمن إعدادات الشبكة للجهاز الظاهري المنسوخ. وهذا يضمن أن الجهاز الظاهري موصول بالشبكة الصحيحة بعد تجاوز الفشل.

حماية Active Directory

حماية موقع إلى موقع

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

حماية من الموقع إلى Azure

أولاً، إنشاء وحدة تحكم مجال في Azure virtual network. عند ترقية الملقم إلى دور وحدة تحكم مجال، حدد نفس اسم المجال المستخدم في الموقع الأساسي.

ثم إعادة تكوين خادم DNS لشبكة الاتصال الظاهرية لاستخدام خادم DNS في Azure.

شبكة Azure

حماية من الموقع إلى Azure

أولاً، إنشاء وحدة تحكم مجال في Azure virtual network. عند ترقية الملقم إلى دور وحدة تحكم مجال، حدد نفس اسم المجال المستخدم في الموقع الأساسي.

ثم إعادة تكوين خادم DNS لشبكة الاتصال الظاهرية لاستخدام خادم DNS في Azure.

اعتبارات تجاوز الفشل الاختبار

لتجنب التأثير على أعباء عمل الإنتاج، يحدث تجاوز الفشل التجريبي في شبكة معزولة عن شبكة الإنتاج.

تتطلب معظم التطبيقات وجود وحدة تحكم مجال أو خادم DNS. لذلك، قبل فشل التطبيق، يجب إنشاء وحدة تحكم مجال في شبكة الاتصال المعزولة لاستخدامها في تجاوز الفشل الاختبار. أسهل طريقة للقيام بذلك هي استخدامSite Recovery لنسخ جهاز ظاهري يستضيف وحدة تحكم مجال أو DNS. ثم قم بتشغيل تجاوز فشل اختبار الجهاز الظاهري وحدة تحكم المجال قبل تشغيل تجاوز فشل اختبار خطة الاسترداد للتطبيق.

  1. استخدم Site Recovery من أجل النسخ المتماثل للجهاز الظاهري الذي يستضيف وحدة تحكم المجال أو DNS.

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

  3. توفير عنوان IP DNS في شبكة الاتصال المعزولة. استخدم عنوان IP الذي يتوقع الجهاز الظاهري DNS للحصول علىه. إذا كنت تقوم بلنسخ المتماثل إلى Azure، فقم بتوفير عنوان IP للجهاز الظاهري المستخدم في تجاوز الفشل. لإدخال عنوان IP، في الجهاز الظاهري المنسوخ، في إعدادات الشبكة ، حدد إعدادات عنوان IP المستهدف .

    شبكة اختبار Azure

    تلميح

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

    إذا كان عنوان IP الهدف جزءاً من الشبكة الفرعية المحددة، فسيحاول Site Recovery إنشاء الجهاز الظاهري لتجاوز الفشل الاختبار باستخدام عنوان IP الهدف. إذا لم يكن IP الهدف جزءاً من الشبكة الفرعية المحددة، فسيتم إنشاء الجهاز الظاهري لتجاوز الفشل باستخدام IP التالي المتوفر في الشبكة الفرعية المحددة.

تجاوز فشل الاختبار إلى موقع ثانوي

  1. إذا كنت تقوم بالنسخ المتماثل إلى موقع محلي آخر وكنت تستخدم DHCP، فقم بإعداد DNS و DHCP لاختبار تجاوز الفشل .
  2. قم بإجراء اختبار تجاوز الفشل للجهاز الظاهري وحدة تحكم المجال التي تعمل في شبكة الاتصال المعزولة. استخدم أحدث تطبيق متناسق متاح للجهاز الظاهري لوحدة تحكم المجال لإجراء اختبار تجاوز الفشل.
  3. تشغيل تجاوز فشل اختبار لخطة التعافي التي تحتوي على الأجهزة الظاهرية التي يعمل التطبيق عليه.
  4. عند اكتمال الاختبار، نظف تجاوز الفشل التجريبي على الجهاز الظاهري لوحدة التحكم بالمجال. هذه الخطوة بحذف وحدة تحكم المجال التي تم إنشاؤها لاختبار تجاوز الفشل.

إزالة مراجع إلى وحدات تحكم مجال أخرى

عند بدء تجاوز فشل اختبار لا تقم بتضمين جميع وحدات تحكم المجال في شبكة الاختبار. لإزالة المراجع إلى وحدات تحكم المجال الأخرى الموجودة في بيئة الإنتاج الخاصة بك، قد تحتاج إلى الاستيلاء على أدوار FSMO Active Directory والقيام بتنظيف بيانات التعريف لوحدات التحكم بالمجال المفقودة.

المشاكل الناجمة عن ضمانات المحاكاة الافتراضية

هام

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

بدءًا من Windows Server 2012، تم تضمين إجراءات حماية إضافية في Active Directory Domain Services (AD DS) . تساعد وسائل الحماية هذه في حماية وحدات التحكم بالمجال الافتراضية من عمليات التراجع عن رقم تسلسل التحديث (USN) إذا كان النظام الأساسي لبرنامج hypervisor يدعم VM-GenerationID . يدعم Azure VM-GenerationID . وبسبب هذا، وحدات تحكم المجال التي تعمل Windows Server 2012 أو أحدث على الأجهزة الظاهرية لـ Azure هذه الضمانات الإضافية.

عند إعادة تعيين VM-GenerationID ، تتم أيضًا إعادة تعيين قيمة InvocationID لقاعدة بيانات AD DS. بالإضافة إلى ذلك، يتم تجاهل تجمع المعرف النسبي (RID)، ويتم وضع علامة على المجلد SYSVOL على أنه غير موثوق. لمزيد من المعلومات، راجع مقدمة إلى ظاهرية خدمات مجال Active Directory و الظاهرية الآمنة للنسخ المتماثل لنظام الملفات الموزعة (DFSR) .

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

نظراً لاستخدام وحدة تحكم المجال هذه فقط في تجاوز الفشل الاختباري، فإن ضمانات المحاكاة الافتراضية ليست ضرورية. للتأكد من أن قيمة VM-GenerationID للجهاز الظاهري لوحدة التحكم بالمجال لا تتغير، يمكنك تغيير قيمة ما يلي DWORD إلى 4 في وحدة تحكم المجال المحلية:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\gencounter\Start

أعراض ضمانات المحاكاة الافتراضية

إذا تم تشغيل ضمانات المحاكاة الافتراضية بعد تجاوز الفشل في الاختبار، فقد ترى واحداً أو أكثر من الأعراض التالية:

  • تتغير قيمة GenerationID :

  • تتغير قيمة InvocationID :

  • SYSVOL مجلد ومشاركاتNETLOGON غير متوفرة.

    مشاركة مجلد SYSVOL

    مجلد NtFrs SYSVOL

  • يتم حذف قواعد بيانات DFSR.

استكشاف أخطاء وحدة تحكم المجال وإصلاحها أثناء اختبار تجاوز الفشل

هام

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

  1. في موجه الأوامر، قم بتشغيل الأمر التالي للتحقق من مشاركة SYSVOL مجلد و NETLOGON مجلد:

    NET SHARE

  2. في موجه الأوامر، شغّل الأمر التالي للتأكد من أن وحدة تحكم المجال تعمل بشكل صحيح:

    dcdiag /v > dcdiag.txt

  3. في سجل الإخراج، ابحث عن النص التالي. يؤكد النص أن وحدة تحكم المجال تعمل بطريقةٍ صحيحةٍ.

    • passed test Connectivity
    • passed test Advertising
    • passed test MachineAccount

في حالة استيفاء الشروط السابقة، فمن المحتمل أن وحدة تحكم المجال تعمل بشكل صحيح. إذا لم يكن كذلك، فأكمل الخطوات التالية:

  1. احرص على إجراء استعادة موثوقة لوحدة تحكم المجال. راعِ المعلومات المذكورة أدناه:

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

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\Repl Perform Initial Synchronizations

    لمزيد من المعلومات، راجع استكشاف أخطاء معرف حدث DNS وإصلاحها 4013: تعذر على خادم DNS تحميل مناطق DNS المتكاملة لـAD .

  3. قم بتعطيل متطلبات توفر خادم الكتالوج العمومي للتحقق من تسجيل دخول المستخدم. للقيام بذلك، في وحدة التحكم بالمجال المحلية، قم بتعيين مفتاح التسجيل التالي على 1 . إذا لم يكن DWORD موجودًا، فيمكنك إنشاؤه ضمن العقدة Lsa .

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\IgnoreGCFailures

    لمزيد من المعلومات، راجع كيف يعمل الكتالوج العالمي .

DNS ووحدة تحكم المجال على أجهزة مختلفة

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

إذا لم يكن DNS على نفس الجهاز الظاهري كوحدة تحكم المجال، فستحتاج إلى إنشاء DNS VM لاختبار تجاوز الفشل. يمكنك استخدام خادم DNS جديد وإنشاء جميع المناطق المطلوبة. على سبيل المثال، إذا كان مجال Active Directory الخاص بك هوcontoso.com، فيمكنك إنشاء منطقة DNS بالاسم contoso.com. يجب تحديث الإدخالات التي تتوافق معActive Directory في DNS كما يلي:

  1. تأكد من أن هذه الإعدادات في مكانها قبل بدء تشغيل أي جهاز ظاهري آخر في خطة الاسترداد:

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

  2. تشغيل الأمر التالي على الجهاز الظاهري الذي يستضيف وحدة تحكم المجال:

    nltest /dsregdns

  3. تشغيل الأوامر التالية لإضافة منطقة على خادم DNS، والسماح بالتحديثات غير الآمنة، وإضافة إدخال للمنطقة إلى DNS:

    dnscmd /zoneadd contoso.com  /Primary

dnscmd /recordadd contoso.com  contoso.com. SOA %computername%.contoso.com. hostmaster. 1 15 10 1 1

dnscmd /recordadd contoso.com %computername%  A <IP_OF_DNS_VM>

dnscmd /config contoso.com /allowupdate 1

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

تعرف على المزيد حول حماية أعباء عمل المؤسسة باستخدام Azure Site Recovery.