مشاركة عبر

الموثوقية في Azure DNS

  • مقالة

تحتوي هذه المقالة على معلومات مفصلة حول التعافي من الكوارث عبر المناطق ودعم استمرارية الأعمال ل Azure DNS.

التعافي من الكوارث عبر المناطق واستمرارية الأعمال

يتعلق التعافي من الكوارث (DR) بالتعافي من الأحداث عالية التأثير، مثل الكوارث الطبيعية أو عمليات النشر الفاشلة التي تؤدي إلى وقت تعطل وفقدان البيانات. بغض النظر عن السبب، فإن أفضل علاج للكارثة هو خطة الإصلاح بعد الكارثة محددة جيدا ومختبرة وتصميم تطبيق يدعم الإصلاح بعد الكارثة بنشاط. قبل البدء في التفكير في إنشاء خطة التعافي من الكوارث، راجع التوصيات لتصميم استراتيجية التعافي من الكوارث.

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

يستخدم حل تجاوز فشل Azure DNS للتعافي من الكوارث آلية DNS القياسية للفشل في موقع النسخ الاحتياطي. يعمل الخيار اليدوي عبر Azure DNS بشكل أفضل عند استخدامه بالتزامن مع الاستعداد البارد أو نهج الضوء التجريبي.

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

إشعار

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

لمعرفة كيفية إنشاء منطقة DNS خاصة ل Azure باستخدام مدخل Microsoft Azure، راجع التشغيل السريع: إنشاء منطقة DNS خاصة ل Azure باستخدام مدخل Microsoft Azure.

لإنشاء محلل خاص ل Azure DNS باستخدام مدخل Microsoft Azure، راجع التشغيل السريع: إنشاء محلل خاص ل Azure DNS باستخدام مدخل Microsoft Azure.

التعافي من الكوارث في المنطقة الجغرافية متعددة المناطق

هناك جانبان تقنيان لإعداد بنية التعافي من الكوارث:

  • استخدام آلية نشر لنسخ المثيلات والبيانات والتكوينات بين البيئات الأساسية والبيئات الاحتياطية. يمكن إجراء هذا النوع من التعافي من الكوارث محليا عبر Azure Site Recovery، راجع وثائق استرداد موقع Azure عبر أجهزة/خدمات شركاء Microsoft Azure مثل Veritas أو NetApp.

  • تطوير حل لتحويل حركة مرور الشبكة/الويب من الموقع الأساسي إلى موقع الاستعداد. يمكن تحقيق هذا النوع من التعافي من الكوارث عبر Azure DNS أو Azure Traffic Manager (DNS) أو موازنات التحميل العمومية التابعة لجهة خارجية.

تركز هذه المقالة بشكل خاص على تخطيط التعافي من الكوارث في Azure DNS.

إعداد التعافي من الكوارث والكشف عن الانقطاع

يستخدم حل تجاوز الفشل اليدوي لـ Azure DNS للتعافي من الكوارث آلية DNS القياسية لتجاوز الفشل في موقع النسخ الاحتياطي. يعمل الخيار اليدوي عبر Azure DNS بشكل أفضل عند استخدامه بالتزامن مع أسلوب الاستعداد البارد أو الضوء التجريبي.

Diagram of manual failover using Azure DNS.

الشكل - تجاوز الفشل اليدوي باستخدام Azure DNS

الافتراضات التي وضعت للحل هي:

  • تحتوي كل من نقاط النهاية الأساسية والثانوية على عناوين IP ثابتة لا تتغير كثيراً. لنفترض أن عنوان IP للموقع الأساسي هو 100.168.124.44 وعنوان IP للموقع الثانوي هو 100.168.124.43.
  • تتوفر منطقة Azure DNS لكل من الموقع الأساسي والثانوي. لنفترض أن نقطة النهاية بالنسبة للموقع الأساسي prod.contoso.com ولموقع النسخ الاحتياطي dr.contoso.com. يوجد أيضاً سجل DNS للتطبيق الرئيسي المعروف باسم www.contoso.com.
  • TTL هو مجموعة RTO SLA في المؤسسة أو الأقل منها. على سبيل المثال، إذا قامت مؤسسة بتعيين RTO للاستجابة للكوارث في التطبيق لتكون 60 دقيقة، يجب أن يكون TTL أقل من 60 دقيقة، ويفضل أن يكون ذلك أقل ليكون الأداء أفضل. يمكنك إعداد Azure DNS لتجاوز الفشل اليدوي كما يلي:
    • قم بإنشاء منطقة DNS
    • إنشاء سجلات منطقة DNS
    • تحديث سجل CNAME

  1. أنشئ منطقة DNS (على سبيل المثال، www.contoso.com) كما هو موضح أدناه:

    Screenshot of creating a DNS zone in Azure.

    الشكل: إنشاء منطقة DNS في Azure

  2. ضمن هذه المنطقة، قم بإنشاء ثلاثة سجلات (على سبيل المثال - www.contoso.com prod.contoso.com dr.consoto.com) كما هو موضح أدناه.

    Screenshot of creating DNS zone records.

    الشكل - إنشاء سجلات منطقة DNS في Azure

    في هذا السيناريو، يحتوي الموقع www.contoso.com على TTL لمدة 30 دقيقة، وهو أقل بكثير من RTO المذكور، ويشير إلى موقع الإنتاج prod.contoso.com. هذا التكوين أثناء العمليات التجارية العادية. تم تعيين TTL prod.contoso.com وdr.contoso.com إلى 300 ثانية أو 5 دقائق. يمكنك استخدام خدمة مراقبة Azure مثل Azure Monitor أو Azure App Insights، أو أي حلول مراقبة للشركاء مثل Dynatrace. يمكنك حتى استخدام الحلول المحلية التي يمكنها مراقبة أو اكتشاف فشل مستوى التطبيق أو البنية التحتية الافتراضية.

  3. بمجرد اكتشاف الفشل، قم بتغيير قيمة السجل للإشارة إلى dr.contoso.com كما هو موضح أدناه:

    Screenshot of updating CNAME record.

    الشكل - تحديث سجل CNAME في Azure

    في غضون 30 دقيقة، يقوم خلالها معظم المحللين بتحديث ملف المنطقة المخزنة مؤقتاً، ستتم إعادة توجيه أي استعلام إلى www.contoso.com إلى dr.contoso.com. يمكنك أيضاً تشغيل أمر Azure CLI التالي لتغيير قيمة CNAME:

      az network dns record-set cname set-record \
  --resource-group 123 \
  --zone-name contoso.com \
  --record-set-name www \
  --cname dr.contoso.com

    يمكن تنفيذ هذه الخطوة يدوياً أو عن طريق التشغيل الآلي. يمكن القيام بذلك يدوياً عبر وحدة التحكم أو من خلال Azure CLI. يمكن استخدام Azure SDK وAPI لأتمتة تحديث CNAME بحيث لا يلزم أي تدخل يدوي. يمكن إنشاء الأتمتة عبر وظائف Azure أو داخل تطبيق مراقبة تابع لجهة خارجية أو حتى من أماكن العمل.

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