قائمة مراجعة المرونة لخدمات Azure المحددة

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

App Service

استخدم المستوى القياسي أو Premium. تدعم هذه المستويات فتحات التقسيم المرحلي والنسخ الاحتياطية التلقائية. لمزيدٍ من المعلومات، راجع نظرة معمقة حول خطط خدمة App Service

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

تخزين التكوين كإعدادات للتطبيق. استخدم إعدادات التطبيق للاحتفاظ بإعدادات التكوين كإعدادات للتطبيق. حدد الإعدادات في قوالب Resource Manager، أو باستخدام PowerShell، بحيث يمكنك تطبيقها كجزء من عملية نشر / تحديث تلقائية، وهي أكثر موثوقية. لمزيد من المعلومات، راجع تكوين تطبيقات الويب في Azure App Service.

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

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

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

تجنب استخدام ميزة النسخ الاحتياطي لخدمة التطبيقات لنسخ قواعد بيانات Azure SQL احتياطيًا. بدلًا من ذلك، استخدم النسخ الاحتياطي الآلي لقاعدة بيانات SQL. يقوم النسخ الاحتياطي لخدمة التطبيقات بتصدير قاعدة البيانات إلى ملف BACPAC SQL، والذي يكلف وحدات DTUs.

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

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

تمكين تسجيل التشخيص، بما في ذلك تسجيل التطبيق وتسجيل خادم الويب. التسجيل مهم للمراقبة والتشخيص. راجع تمكين تسجيل التشخيص لتطبيقات الويب في Azure App Service

تسجيل الدخول إلى تخزين كائن ثنائي كبير الحجم. وهذا يجعل من السهل جمع البيانات وتحليلها.

إنشاء حساب تخزين منفصل للسجلات. تجنب استخدام نفس حساب التخزين للسجلات وبيانات التطبيق. يساعد هذا على منع التسجيل من تقليل أداء التطبيق.

مراقبة الأداء. استخدم خدمة مراقبة الأداء مثل New Relic أو Application Insights لمراقبة أداء التطبيق وسلوكه تحت الحمل. تمنحك مراقبة الأداء نظرة ثاقبة للتطبيق في الوقت الفعلي. يمكّنك من تشخيص المشكلات وإجراء تحليل الأسباب الجذرية للفشل.

موازن تحميل Azure

حدد Standard SKU. يوفر موازن التحميل القياسي بعدا من الموثوقية التي لا يوفرها Basic - أي مناطق التوفر ومرونة المنطقة. وهذا يعني أنه عندما تتعطل منطقة ما، لن تتأثر موازنة التحميل القياسية المكررة في منطقتك. يضمن هذا إمكانية تحمل عمليات التوزيع الخاصة بك لفشل المنطقة داخل منطقة ما. بالإضافة إلى ذلك، يدعم Standard Load Balancer موازنة التحميل العمومية لضمان عدم تأثر التطبيق الخاص بك بفشل المنطقة أيضًا.

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

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

Application Gateway

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

Azure Cosmos DB

تكوين تكرار المنطقة. عند استخدام التكرار في المنطقة، يقوم Azure Cosmos DB بشكل متزامن بنسخ جميع عمليات الكتابة عبر مناطق التوفر. يفشل تلقائيا في حالة انقطاع المنطقة. لمزيد من المعلومات، راجع تحقيق قابلية وصول عالية باستخدام Azure Cosmos DB.

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

مراكز الأحداث

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

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

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

استخدم قائمة انتظار غير مستخدمة. إذا كانت معالجة رسالة تؤدي إلى فشل غير متصل، فضع الرسالة في قائمة انتظار غير مستخدمة، بحيث يمكنك تعقب الحالة. اعتمادًا على السيناريو، يمكنك إعادة محاولة الرسالة لاحقًا، أو تطبيق معاملة تعويضية، أو اتخاذ بعض الإجراءات الأخرى. لاحظ أن مراكز الأحداث لا تحتوي على أي وظيفة قائمة انتظار غير مستخدمة مضمنة. يمكنك استخدام Azure Queue Storage أو Service Bus لتنفيذ قائمة انتظار غير مستخدمة، أو استخدام Azure Functions أو بعض آليات الأحداث الأخرى.

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

تنفيذ الإصلاح بعد كارثة عن طريق تجاوز الفشل في مساحة اسم مراكز الأحداث الثانوية. لمزيد من المعلومات، راجع Azure Event Hubs استرداد البيانات من الكوارث الجغرافية.

ذاكرة التخزين المؤقت في Azure لـ Redis

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

تكوين النسخ المتماثل الجغرافي. يوفر النسخ المتماثل الجغرافي آلية لربط اثنين من ذاكرة التخزين المؤقت Azure Premium المستوى لمثيلات Redis. يتم نسخ البيانات المكتوبة إلى ذاكرة التخزين المؤقت الأساسية إلى ذاكرة تخزين مؤقت ثانوية للقراءة فقط. لمزيد من المعلومات، راجع كيفية تكوين النسخ المتماثل الجغرافي لذاكرة التخزين المؤقت Azure لـRedis

تكوين استمرارية البيانات. يسمح لك استمرار Redis بالاحتفاظ بالبيانات المخزنة في Redis. يمكنك أيضًا أخذ لقطات ونسخ البيانات احتياطيًا، والتي يمكنك تحميلها في حالة فشل الأجهزة. لمزيد من المعلومات، راجع كيفية تكوين استمرارية البيانات المتميزة الخاص بـ Azure Cache لـ Redis

إذا كنت تستخدم ذاكرة التخزين المؤقت Azure لـRedis كذاكرة تخزين مؤقتة للبيانات وليس كمخزن مستمر، فقد لا تنطبق هذه التوصيات.

البحث الإدراكي

توفير أكثر من نسخة متماثلة واحدة. استخدم نسختين متماثلتين على الأقل للقراءة عالية التوفر، أو ثلاث نسخ متماثلة لقابلية الوصول العالية للقراءة والكتابة.

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

تكوين المفهرسات للتوزيعات متعددة المناطق. إذا كان لديك توزيع متعدد المناطق، ففكر في خياراتك لاستمرارية الفهرسة.

• إذا تم نسخ مصدر البيانات جغرافيا، يجب توجيه كل مفهرس لكل azure Cognitive خدمة البحث إقليمي إلى النسخة المتماثلة لمصدر البيانات المحلي الخاص به. ومع ذلك، لا يوصى بهذا الأسلوب لمجموعات البيانات الكبيرة المخزنة في Azure SQL Database. والسبب هو أن Azure Cognitive Search لا يمكنه إجراء فهرسة تزايدية من النسخ المتماثلة الثانوية لقاعدة بيانات SQL، فقط من النسخ المتماثلة الأساسية. بدلًا من ذلك، أشر جميع المفهرسات إلى النسخة المتماثلة الأساسية. بعد تجاوز الفشل، أشر إلى مفهرسات Azure Cognitive Search إلى النسخة المتماثلة الأساسية الجديدة.

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

ناقل الخدمة

استخدم الطبقة Premium لأحمال عمل الإنتاج. يوفر Service Bus Premium Messaging موارد معالجة مخصصة ومحجوزة وسعة ذاكرة لدعم الأداء ومعدل النقل المتوقعين. Premium تمنحك طبقة المراسلة أيضًا إمكانية الوصول إلى الميزات الجديدة المتوفرة للعملاء المتميزين فقط في البداية. يمكنك تحديد عدد وحدات المراسلة استنادًا إلى أحمال العمل المتوقعة.

معالجة الرسائل المكررة. إذا فشل الناشر مباشرة بعد إرسال رسالة، أو واجه مشكلات في الشبكة أو النظام، فقد يفشل بشكل خاطئ في تسجيل تسليم الرسالة، وقد يرسل نفس الرسالة إلى النظام مرتين. يمكن لناقل خدمة Microsoft Azure معالجة هذه المشكلة عن طريق تمكين الكشف عن التكرارات. لمزيد من المعلومات، اطلع على "Duplicate detection".

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

نهج إعادة المحاولة. يسمح لك ناقل خدمة Microsoft Azure باختيار أفضل نهج لإعادة المحاولة لتطبيقاتك. النهج الافتراضي هو السماح بـ9 محاولات كحد أقصى لإعادة المحاولة، والانتظار لمدة 30 ثانية ولكن يمكن تعديل هذا بشكل أكبر. لمزيد من المعلومات، راجع نهج إعادة المحاولة – ناقل خدمة Microsoft Azure.

استخدم قائمة انتظار غير مستخدمة. إذا تعذرت معالجة رسالة أو تسليمها إلى أي جهاز استقبال بعد إعادة المحاولة المتعددة، يتم نقلها إلى قائمة انتظار الرسائل المهملة. تنفيذ عملية لقراءة الرسائل من قائمة انتظار الرسائل غير المستخدمة، وفحصها، ومعالجة المشكلة. اعتمادًا على السيناريو، يمكنك إعادة محاولة الرسالة كما هي، أو إجراء تغييرات وإعادة المحاولة، أو تجاهل الرسالة. لمزيد من المعلومات، اطلع على "Overview of Service Bus dead-letter queues".

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

استخدم Geo-Disaster Recovery. يضمن الإصلاح بعد كارثة الجغرافية استمرار معالجة البيانات في العمل في منطقة أو مركز بيانات مختلف إذا أصبحت منطقة أو مركز بيانات Azure بأكمله غير متوفرين بسبب كارثة. لمزيد من المعلومات، راجع التعافي الجغرافي من الكوارث باستخدام ناقل خدمة Microsoft Azure.

التخزين

استخدم التخزين المتكرر في المنطقة. التخزين المتكرر للمنطقة (ZRS): تنسخ البيانات بشكل متزامن عبر ثلاث مناطق توفر لـ Azure في المنطقة الأساسية. إذا واجهت منطقة توفر انقطاعا، يفشل Azure Storage تلقائيا في الوصول إلى منطقة بديلة. لمزيد من المعلومات، راجع تكرار Azure Storage.

عند استخدام التكرار الجغرافي، قم بتكوين الوصول للقراءة. إذا كنت تستخدم بنية متعددة المناطق، فاستخدم طبقة تخزين مناسبة للتكرار العالمي. باستخدام RA-GRS أو RA-GZRS، يتم نسخ بياناتك نسخا متماثلا إلى منطقة ثانوية. يستخدم RA-GRS التخزين المتكرر محليا (LRS) في المنطقة الأساسية، بينما يستخدم RA-GZRS التخزين المتكرر للمنطقة (ZRS) في المنطقة الأساسية. يوفر كلا التكوينين وصولا للقراءة فقط إلى بياناتك في المنطقة الثانوية. إذا كان هناك انقطاع في التخزين في المنطقة الأساسية، يمكن للتطبيق قراءة البيانات من المنطقة الثانوية إذا قمت بتصميمها لهذه الإمكانية. لمزيد من المعلومات، راجع تكرار Azure Storage.

بالنسبة لأقراص الجهاز الظاهري، استخدم الأقراص المدارة.توفرالأقراص المدارة موثوقية أفضل للأجهزة الظاهرية في مجموعة توفر، لأن الأقراص معزولة بشكل كاف عن بعضها البعض لتجنب نقاط الفشل الفردية. أيضًا، لا تخضع الأقراص المدارة لحدود IOPS لـVHDs التي تم إنشاؤها في حساب تخزين. لمزيد من المعلومات، راجع إدارة توفر الأجهزة الظاهرية لـWindows في Azure.

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

قاعدة بيانات SQL

استخدم المستوى القياسي أو Premium. توفر هذه المستويات فترة استعادة أطول في نقطة زمنية (35 يومًا). لمزيد من المعلومات، راجع SQL خيارات قاعدة البيانات والأداء.

تمكين تدقيق قاعدة بيانات SQL. يمكن استخدام التدقيق لتشخيص الهجمات الضارة أو الخطأ البشري. لمزيد من المعلومات، راجع بدء استخدام تدقيق قاعدة بيانات SQL.

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

استخدم التقسيم. استخدم ميزة التقسيم لتقسيم قاعدة البيانات أفقياً. يمكن أن يوفر التقسيم إمكانية فصل الأعطال. لمزيد من المعلومات، راجع توسيع قاعدة بيانات Azure SQL.

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

استخدم استعادة الموقع الجغرافي لإصلاح انقطاع الخدمة. تستعيد خدمة استعادة الموقع الجغرافي قاعدة بيانات من نسخة احتياطية مكررة بالمواقع الجغرافية. لمزيد من المعلومات، راجع استرداد قاعدة بيانات SQL Azure باستخدام النسخ الاحتياطية التلقائية لقاعدة البيانات.

Azure Synapse Analytics

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

SQL Server قيد التشغيل في جهاز ظاهري

نسخ قاعدة البيانات. إذا كنت تستخدم Azure Backup بالفعل لنسخ الأجهزة الظاهرية احتياطيًا، ففكر في استخدام Azure Backup لأحمال العمل SQL Server باستخدام DPM. باستخدام هذا الأسلوب، هناك دور مسؤول نسخ احتياطي واحد للمؤسسة وإجراء استرداد موحد للأجهزة الظاهرية SQL Server. وإلا، استخدم SQL Server النسخ الاحتياطي المدار إلى Microsoft Azure.

Traffic Manager

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

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

الأجهزة الظاهرية

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

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

ضع كل طبقة تطبيق في مجموعة توفر منفصلة. في تطبيق N-tier، لا تضع الأجهزة الظاهرية من مستويات مختلفة في نفس مجموعة التوفر. يتم وضع الأجهزة الظاهرية في مجموعة توفر عبر مجالات الخطأ (FDs) ومجالات التحديث (UD). ومع ذلك، للحصول على فائدة التكرار من FDs وUDS، يجب أن يكون كل جهاز ظاهري في مجموعة التوفر قادرًا على التعامل مع نفس طلبات العميل.

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

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

استخدم الأقراص المدارة للأقراص الثابتة الظاهرية.توفرالأقراص المدارة موثوقية أفضل للأجهزة الظاهرية في مجموعة توفر، لأن الأقراص معزولة بشكل كاف عن بعضها البعض لتجنب نقاط الفشل الفردية. أيضًا، لا تخضع الأقراص المدارة لحدود IOPS لـVHDs التي تم إنشاؤها في حساب تخزين. لمزيد من المعلومات، راجع إدارة توفر الأجهزة الظاهرية لـWindows في Azure.

تثبيت التطبيقات على قرص بيانات، وليس قرص نظام التشغيل. وإلا، فقد تصل إلى حد حجم القرص.

استخدم Azure Backup لنسخ الأجهزة الظاهرية احتياطيًا. تحمي النسخ الاحتياطية من فقدان البيانات العرضي. لمزيد من المعلومات، راجع حماية أجهزة Azure الظاهرية باستخدام مخزن خدمات الاسترداد.

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

تكوين Azure Monitor. جمع وتحليل بيانات المراقبة من أجهزة Azure الظاهرية بما في ذلك نظام التشغيل الضيف وأحمال العمل التي تعمل فيه، راجع Azure Monitor وQuickstart: Azure Monitor.

شبكة ظاهرية

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

إنشاء فحص صحة مخصص. يمكن لـLoad Balancer Health Probes اختبار إما HTTP أو TCP. إذا كان الجهاز الظاهري يقوم بتشغيل خادم HTTP، فإن فحص HTTP هو مؤشر أفضل للحالة الصحية من فحص TCP. بالنسبة إلى فحص HTTP، استخدم نقطة نهاية مخصصة تبلغ عن الصحة العامة للتطبيق، بما في ذلك جميع التبعيات الهامة. لمزيد من المعلومات، راجع نظرة عامة على موازن تحميل Azure.

لا تمنع الفحص الصحي. يتم إرسال مسبار Load Balancer Health من عنوان IP معروف، 168.63.129.16. لا تمنع نسبة استخدام الشبكة من أو إلى عنوان IP هذا في أي نهج جدار حماية أو قواعد مجموعة أمان الشبكة. قد يؤدي حظر التحقيق الصحي إلى إزالة موازن التحميل للجهاز الظاهري من التدوير.

تمكين تسجيل موازن التحميل. تظهر السجلات عدد الأجهزة الظاهرية الموجودة على الواجهة الخلفية التي لا تتلقى نسبة استخدام الشبكة بسبب استجابات الفحص الفاشلة. لمزيد من المعلومات، راجع تحليلات السجل لـAzure Load Balancer.