مشاركة عبر

إعداد استعادة القدرة على الإصلاح بعد كارثة لتطبيق متعدد المستويات قائم على IIS web

  • مقالة

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

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

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

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

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

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

قبل أن تبدأ، تأكد من معرفتك بكيفية القيام بالمهام التالية:

نماذج التوزيع

يتبع تطبيق خادم ويب يعتمد على IIS بشكل نمطي أحد أنماط النشر التالية:

نمط النشر 1

مجموعة خوادم ويب تعتمد على IIS مع توجيه طلب التطبيق (ARR)، خادم IIS، و Microsoft SQL Server.

رسم تخطيطي لمزرعة ويب مستندة إلى IIS تحتوي على ثلاثة مستويات

نمط النشر 2

مجموعة خوادم ويب تعتمد على IIS مع ARR، خادم IIS، خادم تطبيق، و Microsoft SQL Server.

رسم تخطيطي لمزرعة ويب مستندة إلى IIS تحتوي على أربعة مستويات

دعم "استرداد الموقع"

بالنسبة للأمثلة الواردة في هذه المقالة، نستخدم أجهزة VMware الظاهرية المزودة بـIIS 7.5 على Windows Server 2012 R 2 Enterprise. نظرًا لأن النسخ المتماثل لاسترداد الموقع ليس خاصًا بالتطبيق، فمن المتوقع تطبيق التوصيات الواردة في هذه المقالة في السيناريوهات المدرجة في الجدول التالي، وبالنسبة للإصدارات المختلفة من IIS.

المصدر والهدف

السيناريو إلى موقع ثانوي إلى Azure
Hyper-V ‏‏نعم‬ ‏‏نعم‬
VMware ‏‏نعم‬ ‏‏نعم‬
الخادم الفعلي لا ‏‏نعم‬
Azure غير متوفر ‏‏نعم‬

نسخ الأجهزة الظاهرية نسخًا متماثلاً

لبدء النسخ المتماثل لجميع الأجهزة الافتراضية لمجموعة خوادم ويب تعتمد على IIS إلى Azure، اتبع الإرشادات الواردة في اختبار تجاوز الفشل إلى Azure في استعادة الموقع .

إذا كنت تستخدم عنوان IP ثابتًا، فيمكنك تحديد عنوان IP الذي تريد أن تأخذه الآلة الظاهرية. لتعيين عنوان IP، انتقل إلى إعدادات الشبكة > IP الهدف .

لقطة شاشة توضح كيفية تعيين IP الهدف في جزء Site Recovery Network

إنشاء خطة استرداد

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

إضافة أجهزة ظاهرية لمجموعات تجاوز الفشل

يتكون تطبيق الويب النموذجي متعدد المستويات لـIIS من المكونات التالية:

  • مستوى قاعدة بيانات يحتوي على أجهزة SQL الظاهرية.
  • طبقة الويب، والتي تتكون من خادم IIS وطبقة تطبيق.

أضف أجهزة ظاهرية إلى مجموعات مختلفة بناءً على الطبقة:

  1. إنشاء خطة استرداد. إضافة مستوى قاعدة البيانات الأجهزة الظاهرية تحت المجموعة 1. يضمن ذلك إيقاف تشغيل الأجهزة الظاهرية من مستوى قاعدة البيانات أخيرًا وإحضارها أولًا.
  2. أضف الأجهزة الظاهرية لمستوى التطبيق ضمن المجموعة 2. وهذا يضمن رفع مستوى الأجهزة الظاهرية للتطبيقات بعد رفع مستوى قاعدة البيانات.
  3. أضف الأجهزة الظاهرية لمستوى الويب في المجموعة 3. وهذا يضمن ظهور الأجهزة الظاهرية لطبقة الويب بعد ظهور طبقة التطبيق.
  4. إضافة الأجهزة الظاهرية لتوازن التحميل في المجموعة 4. وهذا يضمن ظهور الأجهزة الظاهرية لتوازن التحميل بعد ظهور طبقة الويب.

لمزيد من المعلومات، راجع تخصيص خطة الاسترداد.

إضافة برنامج نصي إلى خطة الاسترداد

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

تحديث DNS

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

سلسلة الاتصال في web.config الخاص بالتطبيق

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

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

<?xml version="1.0" encoding="utf-8"?>
<configuration>
<connectionStrings>
<add name="ConnStringDb1" connectionString="Data Source= 127.0.1.2\SqlExpress; Initial Catalog=TestDB1;Integrated Security=False;" />
</connectionStrings>
</configuration>

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

روابط الموقع للتطبيق

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

إشعار

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

لقطة شاشة تعرض إعداد ربط TLS/SSL

إذا قمت بإقران عنوان IP بموقع، فقم بتحديث جميع روابط الموقع بعنوان IP الجديد. لتغيير ارتباطات الموقع، أضف نص تحديث مستوى ويب IIS بعد المجموعة 3 في خطة الاسترداد.

تحديث عنوان IP لموازن الحمل

إذا كان لديك جهاز ARR ظاهري، لتحديث عنوان IP، أضف برنامج نصي لتجاوز فشل IIS ARR بعد المجموعة 4.

شهادة TLS/SSL ملزمة لاتصال HTTPS

قد يحتوي موقع الويب على شهادة TLS/SSL مرتبطة تساعد على ضمان اتصال آمن بين خادم الويب ومتصفح المستخدم. إذا كان موقع الويب يحتوي على اتصال HTTPS، كما يحتوي على موقع HTTPS مرتبط يرتبط بعنوان IP لخادم IIS مع ربط شهادة TLS/SSL، فيجب عليك إضافة ربط موقع جديد للشهادة بعنوان IP للآلة الظاهرية IIS بعد تجاوز الفشل.

يمكن إصدار شهادة TLS/SSL مقابل هذه المكونات:

  • اسم النطاق المؤهل بالكامل للموقع.
  • اسم الخادم.
  • شهادة البدل لاسم النطاق.
  • عنوان IP. إذا تم إصدار شهادة TLS/SSL مقابل عنوان IP لخادم IIS، فيجب إصدار شهادة TLS/SSL أخرى مقابل عنوان IP لخادم IIS على موقع Azure. يجب إنشاء ملحق TLS إضافي لهذه الشهادة. ولهذا السبب، نوصي بعدم استخدام شهادة TLS/SSL صادرة مقابل عنوان IP. هذا الخيار أقل استخدامًا على نطاق واسع وسيتم إهماله قريبًا وفقًا للتغييرات الجديدة في سلطة الشهادة/منتدى المتصفح.

تحديث التبعية بين مستوى الويب ومستوى التطبيق

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

إجراء تجاوز لفشل اختبار

  1. في مدخل Microsoft Azure، حدد مخزن «Recovery Services».
  2. حدد خطة الاسترداد التي قمت بإنشائها لمجموعة خوادم ويب IIS.
  3. حدد "Test Failover".
  4. لبدء عملية تجاوز فشل الاختبار، حدد نقطة الاسترداد والشبكة الظاهرية في Azure.
  5. عند تهيئة البيئة الثانوية، يمكنك تنفيذ عمليات التحقق من الصحة.
  6. عند اكتمال عمليات التحقق من الصحة، لتنظيف بيئة تجاوز الفشل، حدد Validations complete.

لمزيد من المعلومات، راجع اختبار تجاوز الفشل في Azure في استرداد الموقع.

إجراء تجاوز الفشل

  1. في مدخل Microsoft Azure، حدد مخزن «Recovery Services».
  2. حدد خطة الاسترداد التي قمت بإنشائها لمجموعة خوادم ويب IIS.
  3. حدد "Failover".
  4. لبدء عملية تجاوز الفشل، حدد نقطة الاسترداد.

لمزيد من المعلومات، راجع تجاوز الفشل في استعادة الموقع.

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