تطبيق ويب مُتعدد المناطق عالي التوفر

يستند هذا المثال إلى بنية مثال تطبيق الويب الأساسي ويوسعها لإظهار:

• الممارسات المثبتة لتحسين قابلية التوسع والأداء في تطبيق ويب Azure App Service
• كيفية تشغيل تطبيق Azure App Service في مناطق متعددة لتحقيق قابلية وصول عالية

بناء الأنظمة

قم بتنزيل ملف Visio لهذه البنية.

‏‏سير العمل‬

يعالج سير العمل هذا الجوانب متعددة المناطق للبنية ويعتمد على تطبيق الويب الأساسي.

• المنطقة الأساسية والثانوية.. تستخدم هذه البنية منطقتين لتحقيق قابلية وصول أعلى. يتم توزيع التطبيق في كل منطقة. أثناء العمليات العادية، توجه نسبة استخدام الشبكة إلى المنطقة الأساسية. إذا أصبحت المنطقة الأساسية غير متوفرة، تُوجه نسبة الاستخدام إلى المنطقة الثانوية.
• الباب الأمامي. Azure Front Door هو موازن التحميل الموصى به للتطبيقات متعددة المناطق. وهو يتكامل مع جدار حماية تطبيق الويب (WAF) للحماية من عمليات الاستغلال الشائعة ويستخدم وظيفة التخزين المؤقت للمحتوى الأصلي ل Front Door. في هذه البنية، يتم تكوين Front Door لتوجيه الأولوية ، والذي يرسل كل حركة المرور إلى المنطقة الأساسية ما لم تصبح غير متوفرة. إذا أصبحت المنطقة الأساسية غير متوفرة، يقوم Front Door بتوجيه كافة نسبة استخدام الشبكة إلى المنطقة الثانوية.
• النسخ المتماثل الجغرافي لحسابات التخزين وقاعدة بيانات SQL و/أو Azure Cosmos DB.

المكونات

التقنيات الرئيسية المستخدمة لتنفيذ هذه البنية:

• معرف Microsoft Entra هو خدمة إدارة الهوية والوصول المستندة إلى السحابة التي تتيح للموظفين الوصول إلى تطبيقات السحابة التي تم تطويرها لمؤسستك.
• يُعد Azure DNS خدمة استضافة لمجالات DNS التي تقدم تحليل الاسم باستخدام البنية الأساسية لـ Microsoft Azure. يمكنك، من خلال استضافة المجالات في Azure، إدارة سجلات DNS باستخدام نفس بيانات الاعتماد وواجهات برمجة التطبيقات والأدوات والفوترة مثل خدمات Azure الأخرى. لاستخدام اسم مجال مخصص (مثل contoso.com)، قم بإنشاء سجلات DNS التي تعين اسم المجال المخصص إلى عنوان IP. لمزيد من المعلومات، راجع تكوين اسم مجال مخصص في Azure App Service.
• Azure Content Delivery Network هي حل عالمي لتقديم محتوى عالي النطاق الترددي عن طريق تخزينه مؤقتا في العقد الفعلية الموضوعة استراتيجيا في جميع أنحاء العالم.
• Azure Front Door هو موازن تحميل الطبقة 7. في هذه البنية، فإنه يوجه طلبات HTTP إلى الواجهة الأمامية للويب. يوفر Front Door أيضا جدار حماية تطبيق الويب (WAF) الذي يحمي التطبيق من عمليات الاستغلال والثغرات الأمنية الشائعة. يستخدم Front Door أيضا لحل شبكة تسليم المحتوى (CDN) في هذا التصميم.
• Azure AppService هو نظام أساسي مدار بالكامل لإنشاء التطبيقات السحابية ونشرها. يتيح لك تحديد مجموعة من موارد الحوسبة لتطبيق ويب لتشغيل تطبيقات الويب ونشرها وتكوين فتحات التوزيع.
• يمكن استخدام Azure Function Apps لتشغيل مهام الخلفية. يتم استدعاء الوظائف بواسطة مشغل مثل حدث مؤقت أو رسالة يتم وضعها في قائمة الانتظار. للمهام ذات الحالة طويلة المدى، استخدم Durable Functions.
• Azure Storage هو حل تخزين سحابي لسيناريوهات تخزين البيانات الحديثة، ويوفر تخزينا متاحا للغاية وقابلا للتطوير بشكل كبير ودائم وآمن لمجموعة متنوعة من كائنات البيانات في السحابة.
• Azure Redis Cache هي خدمة تخزين مؤقت عالية الأداء توفر مخزن بيانات في الذاكرة لاسترداد البيانات بشكل أسرع، استنادا إلى ذاكرة التخزين المؤقت Redis للتنفيذ مفتوحة المصدر.
• قاعدة بيانات Azure SQL هي قاعدة بيانات ارتباطية كخدمة في السحابة. تشارك قاعدة بيانات SQL قاعدة التعليمات البرمجية الخاصة بها مع مشغل قاعدة بيانات Microsoft SQL Server.
• Azure Cosmos DB هي قاعدة بيانات موزعة عالميا، مدارة بالكامل، وزمن انتقال منخفض، ومتعددة النماذج، ومتعددة الاستعلامات API لإدارة البيانات على نطاق واسع.
• يمكن استخدام Azure Cognitive Search لإضافة وظائف البحث مثل اقتراحات البحث والبحث الغامض والبحث الخاص باللغة. عادة ما يتم استخدام Azure Search مع مخزن بيانات آخر خاصة إذا كان مخزن البيانات الأساسي يتطلب تناسقا مقيدا. يوصى، في هذا الأسلوب، بتخزين البيانات الموثوقة في مخزن البيانات الآخر وفهرس البحث في Azure Search. يمكن أيضا استخدام Azure Search لدمج فهرس بحث واحد من مخازن بيانات متعددة.

تفاصيل السيناريو

هناك العديد من الأساليب العامة لتحقيق قابلية الوصول العالية عبر المناطق:

• نشط / خامل مع وضع الاستعداد السريع: تنتقل نسبة استخدام الشبكة إلى منطقة واحدة، بينما تنتظر الأخرى في وضع الاستعداد. يعني الاستعداد السريع أن App Service في المنطقة الثانوية مخصصة ويتم تشغيلها دائما.

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

• نشط / نشط: كلا المنطقتين نشطتان، والطلبات متوازنة بينهما. إذا أصبحت إحدى المناطق غير متوفرة، يتم إخراجها من التدوير.

يركز هذا المرجع على النشط / الخامل مع الاستعداد السريع.

حالات الاستخدام المحتملة

يمكن أن تستفيد حالات الاستخدام هذه من التوزيع متعدد المناطق:

• تصميم خطة استمرارية الأعمال والتعافي من الكوارث لتطبيقات LoB.

• نشر التطبيقات ذات المهام الحرجة التي تعمل على Windows أو Linux.

• تحسين تجربة المستخدم عن طريق الاحتفاظ بالتطبيقات متاحة.

التوصيات

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

الاقتران الإقليمي

يتم إقران كل منطقة من مناطق Azure بمنطقة أخرى داخل نفس المنطقة الجغرافية. بشكل عام، اختر مناطق من نفس الزوج الإقليمي (على سبيل المثال، شرق الولايات المتحدة 2 ووسط الولايات المتحدة). وتشمل ميزات إجراء ذلك ما يلي:

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

ومع ذلك، تأكد من أن كلا المنطقتين تدعمان جميع خدمات Azure المطلوبة لتطبيقك. راجع الخدمات حسب المنطقة. لمزيد من المعلومات حول الأزواج الإقليمية، راجع استمرارية الأعمال والإصلاح بعد كارثة (BCDR): المناطق المقترنة في Azure.

مجموعات الموارد

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

تطبيقات App Service

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

تكوين الباب الأمامي

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

فحص الحالة. يستخدم Front Door مسبار HTTPS لمراقبة توفر كل نهاية خلفية. يمنح المسبار الباب الأمامي اختبار نجاح / فشل للفشل في المنطقة الثانوية. يعمل عن طريق إرسال طلب إلى مسار URL محدد. إذا حصل على استجابة غير 200 خلال فترة المهلة، يفشل التحقيق. يمكنك تكوين تكرار فحص السلامة، وعدد العينات المطلوبة للتقييم، وعدد العينات الناجحة المطلوبة لوضع علامة على الأصل على أنها سليمة. إذا وضع Front Door علامة على الأصل على أنه متدهور، فإنه يفشل إلى الأصل الآخر. للحصول على تفاصيل، راجع المسابر الصحية.

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

يعد تأمين الأصول من الإنترنت جزءا مهما من تنفيذ تطبيق يمكن الوصول إليه بشكل عام. راجع تنفيذ الدخول الآمن للشبكة للتعرف على أنماط التصميم والتنفيذ الموصى بها من Microsoft لتأمين اتصالات دخول تطبيقك باستخدام Front Door.

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

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

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

Azure Cosmos DB

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

التخزين

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

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

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

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

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

ناقل خدمة Azure

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

Azure Cognitive Search

في البحث المعرفي، يتم تحقيق التوفر من خلال نسخ متماثلة متعددة، بينما يتم تحقيق استمرارية الأعمال والتعافي من الكوارث (BCDR) من خلال خدمات بحث متعددة.

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

يمكنك استخدام مناطق التوفر مع Azure Cognitive Search عن طريق إضافة نسختين متماثلتين أو أكثر إلى خدمة البحث. سيتم وضع كل نسخة متماثلة في منطقة توفر مختلفة داخل المنطقة.

للحصول على اعتبارات BCDR، راجع وثائق الخدمات المتعددة في مناطق جغرافية منفصلة.

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

بينما توفر جميع مستويات Azure Cache for Redis النسخ المتماثل القياسي لقابلية الوصول العالية، يوصى بمستوى Premium أو Enterprise لتوفير مستوى أعلى من المرونة وقابلية الاسترداد. راجع قابلية الوصول العالية والتعافي من الكوارث للحصول على قائمة كاملة بميزات المرونة وقابلية الاسترداد وخيارات هذه المستويات. ستحدد متطلبات عملك المستوى الأنسب للبنية الأساسية الخاصة بك.

الاعتبارات

تنفذ هذه الاعتبارات ركائز Azure Well-Architected Framework، وهو عبارة عن مجموعة من المبادئ التوجيهية التي يمكن استخدامها لتحسين جودة حمل العمل. لمزيد من المعلومات، يرجى مراجعةMicrosoft Azure Well-Architected Framework.

الموثوقيه

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

الواجهة الأمامية لـ Azure

يفشل Azure Front Door تلقائياً إذا أصبحت المنطقة الأساسية غير متاحة. عندما يفشل Front Door، هناك فترة زمنية (عادة ما تكون حوالي 20-60 ثانية) عندما لا يتمكن العملاء من الوصول إلى التطبيق. المدة تتأثر بالعوامل التالية:

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

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

يجمع مستوى Azure Front Door Standard وPremium بين قدرات Azure Front Door (الكلاسيكي) وAzure CDN Standard من Microsoft (كلاسيكي) وAzure WAF في نظام أساسي واحد. يؤدي استخدام Azure Front Door Standard أو Premium إلى تقليل نقاط الفشل وتمكين التحكم المحسن والمراقبة والأمان. لمزيد من المعلومات، راجع نظرة عامة على طبقة Azure Front Door.

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

يتم توثيق هدف نقطة الاسترداد (RPO) وهدف وقت الاسترداد المقدر (RTO) لقاعدة بيانات SQL في نظرة عامة على استمرارية الأعمال باستخدام قاعدة بيانات Azure SQL.

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

Azure Cosmos DB

RPO وهدف وقت الاسترداد (RTO) ل Azure Cosmos DB قابلان للتكوين عبر مستويات التناسق المستخدمة، والتي توفر مقايضات بين التوفر ومتانة البيانات ومعدل النقل. يوفر Azure Cosmos DB الحد الأدنى من RTO من 0 لمستوى تناسق مريح مع متعدد الإتقان أو RPO من 0 للاتساق القوي مع واحد رئيسي. لمعرفة المزيد حول مستويات تناسق Azure Cosmos DB، راجع مستويات التناسق ومتانة البيانات في Azure Cosmos DB.

التخزين

يوفر تخزين RA-GRS تخزينا دائما، ولكن من المهم مراعاة العوامل التالية عند التفكير في إجراء تجاوز الفشل:

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

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

• تخطيط فشلك بعناية: من المهم أن نفهم أنه عندما يفشل حساب التخزين، يتم فقدان البيانات الموجودة في الحساب الأساسي الأصلي. إن محاولة العودة إلى المنطقة الأساسية دون تخطيط دقيق أمر محفوف بالمخاطر. بعد اكتمال تجاوز الفشل، سيتم تكوين الأساسي الجديد - في منطقة تجاوز الفشل - للتخزين الزائد محليا (LRS). يجب إعادة تكوينه يدويا كمساحة تخزين منسوخة جغرافيا لبدء النسخ المتماثل إلى المنطقة الأساسية ثم إعطاء الوقت الكافي للسماح للحسابات بالمزامنة.

• لن تؤدي حالات الفشل العابرة، مثل انقطاع الشبكة، إلى تجاوز فشل التخزين. صمم تطبيقك ليكون مرناً في مواجهة حالات الفشل العابرة. تشمل خيارات التخفيف ما يلي:

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

لمزيد من المعلومات، راجع What to do if an Azure Storage outage occurs.

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

ناقل خدمة Azure

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

الأمان

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

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

مشاركة الموارد عبر المنشأ (CORS) إذا قمت بإنشاء موقع ويب وواجهة برمجة تطبيقات ويب كتطبيحات منفصلة، فلن يتمكن موقع الويب من إجراء مكالمات AJAX من جانب العميل إلى واجهة برمجة التطبيقات ما لم تقم بتمكين CORS.

تحتوي App Services على دعم مضمن ل CORS دون الحاجة إلى كتابة أي تعليمات برمجية للتطبيق. راجع استهلاك تطبيق API من JavaScript باستخدام CORS. أضف موقع الويب إلى قائمة الأصول المسموح بها لواجهة برمجة التطبيقات.

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

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

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

تحسين التكلفة

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

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

إذا كان التطبيق يحتوي على محتوى ثابت، فاستخدم CDN لتقليل الحمل على خوادم الواجهة الأمامية. بالنسبة إلى البيانات التي لا تتغير بشكل متكرر، استخدم Azure Cache for Redis.

تعد التطبيقات عديمة الحالة التي تم تكوينها للتحجيم التلقائي أكثر فعالية من حيث التكلفة من التطبيقات ذات الحالة. بالنسبة إلى تطبيق ASP.NET الذي يستخدم حالة جلسة العمل، قم بتخزينه في الذاكرة باستخدام Azure Cache for Redis. لمزيد من المعلومات، راجع «موفر حالة جلسة عمل ASP.NET» ل Azure Cache for Redis. خيار آخر هو استخدام Azure Cosmos DB كمخزن حالة خلفية من خلال موفر حالة جلسة عمل. راجع استخدام Azure Cosmos DB كموفر حالة جلسة عمل ASP.NET وموفر ذاكرة تخزين مؤقت.

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

لمزيد من المعلومات، راجع قسم التكلفة في Microsoft Azure Well-Architected Framework.

استخدم حاسبة التسعير لتقدير التكاليف. قد تساعدك هذه التوصيات في هذا القسم على تقليل التكلفة.

الواجهة الأمامية لـ Azure

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

Azure Cosmos DB

هناك عاملان يحددان أسعار Azure Cosmos DB:

• معدل النقل المقدم أو طلب الوحدات في الثانية (RU / s).

  هناك نوعان من معدل النقل الذي يمكن توفيره في Azure Cosmos DB، القياسي والتحجيم التلقائي. يخصص معدل النقل القياسي الموارد المطلوبة لضمان RU / s التي تحددها. بالنسبة للتحجيم التلقائي، يمكنك توفير الحد الأقصى لمعدل النقل، ويتوسع Azure Cosmos DB على الفور لأعلى أو لأسفل اعتمادا على الحمل، بحد أدنى 10٪ من الحد الأقصى لمعدل النقل للتحجيم التلقائي. يتم إصدار فاتورة للمعدل نقل القياسية لكل ساعة. يتم احتساب معدل النقل التلقائي للحصول على الحد الأقصى من معدل النقل المستهلكة كل ساعة.

• تخزين مستهلك. تتم فوترتك بمعدل ثابت لإجمالي كمية التخزين (GBs) المستهلكة للبيانات والفهارس لمدة ساعة معينة.

لمزيد من المعلومات، راجع قسم التكلفة في Microsoft Azure Well-Architected Framework.

كفاءة الأداء

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

تطبيق خدمة التطبيقات

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

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

زيادة قابلية التوسع لقاعدة بيانات SQL عن طريق تقسيم قاعدة البيانات. يشير التقسيم إلى تجزئة قاعدة البيانات أفقيا. يسمح لك التقسيم بتوسيع قاعدة البيانات أفقيا باستخدام «أدوات قاعدة البيانات المرنة». تشمل المزايا المحتملة للتقسيم ما يلي:

• معدل نقل أفضل للعملية.
• يمكن تشغيل الاستعلامات بشكل أسرع عبر مجموعة فرعية من البيانات.

الواجهة الأمامية لـ Azure

يمكن أن يقوم Front Door بإلغاء تحميل SSL ويقلل أيضا من العدد الإجمالي لاتصالات TCP مع تطبيق الويب الخلفي. يؤدي ذلك إلى تحسين قابلية التوسع لأن تطبيق الويب يدير حجما أصغر من عمليات تأكيد اتصال SSL واتصالات TCP. تنطبق مكاسب الأداء هذه حتى في حالة إعادة توجيه الطلبات إلى تطبيق الويب ك HTTPS نتيجة المستوى العالي لإعادة استخدام الاتصال.

Azure Search

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

التميز التشغيلي

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

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

• الغوص العميق في Azure Front Door - طرق توجيه نسبة استخدام الشبكة

• إنشاء تحقيقات السلامة التي تُبلغ عن الحالة العامة للتطبيق بناءً على أنماط مراقبة نقطة النهاية

• تمكين مجموعات تجاوز الفشل التلقائي لـ Azure SQL

• ضمان استمرارية الأعمال والإصلاح بعد كارثة باستخدام مناطق Azure المقترنة

الموارد ذات الصلة

• تطبيق N-tier متعدد المناطق هو سيناريو مشابه. يعرض تطبيق N-tier يعمل في مناطق Azure متعددة

• مبادئ التصميم لتطبيقات Azure