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

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

يتوفر دعم منطقة التوفر ل Azure Functions على كل من خطط Premium (Elastic Premium) و Dedicated (App Service). يركز هذا المقال على دعم التكرار المنعدم لخطط Premium. للحصول على تكرار المنطقة على الخطط المخصصة، راجع ترحيل خدمة التطبيقات إلى دعم منطقة التوفر.

دعم منطقة القابلية للوصول

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

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

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

تدعم Azure Functions توزيع المنطقة المكررة.

عند تكوين Functions كمنطقة زائدة عن الحاجة، ينشر النظام الأساسي مثيلات تطبيق الوظائف تلقائيا عبر ثلاث مناطق في المنطقة المحددة.

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

• الحد الأدنى لعدد مثيلات تطبيق الوظائف هو ثلاثة.
• عند تحديد سعة أكبر من ثلاثة، يتم توزيع المثيلات بالتساوي فقط عندما تكون السعة مضاعف 3.
• بالنسبة لقيمة السعة أكثر من 3*N، تنتشر مثيلات إضافية عبر المنطقتين أو المنطقتين المتبقيتين.

هام

يمكن لـ Azure Functions أن تعمل على النظام الأساسي لخدمة تطبيقات Azure. في النظام الأساسي لخدمة التطبيقات، يشار إلى الخطط التي تستضيف تطبيقات وظائف الخطة المتميزة باسم خطط Elastic Premium، مع أسماء SKU مثل EP1. إذا اخترت تشغيل تطبيق الوظائف على خطة Premium، فتأكد من إنشاء خطة باسم SKU يبدأ ب "E"، مثل EP1. أسماء SKU لخطة App Service التي تبدأ ب "P"، مثل P1V2 (خطة Premium V2 Small)، هي في الواقع خطط استضافة مخصصة. نظرًا إلى أنها مخصصة وليست Elastic Premium، فإن الخطط التي تحمل أسماء SKU التي تبدأ بـ "P" لن يتم قياسها ديناميكيًا وقد تزيد من تكاليفك.

التوفر الإقليمي

تتوفر خطط Premium المكررة للمنطقة في المناطق التالية:

الأمريكتان	‏‏أوروبا	الشرق الأوسط	أفريقيا	آسيا/المحيط الهادئ
جنوب البرازيل	وسط فرنسا	إسرائيل الوسطى	جنوب أفريقيا	شرق أستراليا
وسط كندا	وسط غرب ألمانيا	قطر الوسطى		وسط الهند‬
Central US	منطقة شمال إيطاليا	شمال الإمارات العربية المتحدة		منطقة شمال الصين 3
شرق الولايات المتحدة	أوروبا الشمالية			شرق آسيا
East US 2	شرق النرويج			شرق اليابان
South Central US	منطقة السويد الوسطى			جنوب شرق آسيا
West US 2	شمال سويسرا
غرب الولايات المتحدة الأمريكية 3	جنوب المملكة المتحدة
	أوروبا الغربية

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

دعم منطقة التوفر هو خاصية لخطة Premium. فيما يلي المتطلبات/القيود الحالية لتمكين مناطق التوافر:

• يمكنك فقط تمكين مناطق التوفر عند إنشاء خطة Premium لتطبيق الوظائف الخاص بك. لا يمكنك تحويل خطة Premium موجودة لاستخدام مناطق التوفر.
• يجب استخدام حساب تخزين متكرر للمنطقة (ZRS)لحساب تخزين تطبيق الوظائف الخاص بك. إذا كنت تستخدم نوعا مختلفا من حساب التخزين، يمكن أن تظهر الوظائف سلوكا غير متوقع أثناء انقطاع المنطقة.
• يتم دعم كل من Windows وLinux.
• يجب استضافتها على خطة استضافة Elastic Premium أو Dedicated. لمعرفة كيفية استخدام التكرار في المنطقة مع خطة مخصصة، راجع ترحيل خدمة التطبيقات إلى دعم منطقة التوفر.
  • دعم منطقة التوفر غير متوفر حاليًا لتطبيقات الوظائف في خطط Consumption.
• يجب أن تحتوي تطبيقات الوظائف المضافة على خطة Premium على عدد مثيلات جاهزة دائمًا كحد أدنى يبلغ ثلاثة.
  • يفرض النظام الأساسي هذا العدد الأدنى خلف الكواليس إذا حددت عدد مثيلات أقل من ثلاثة.
• إذا كنت لا تستخدم خطة Premium أو وحدة مقياس تدعم مناطق التوفر، أو في منطقة غير مدعومة، أو غير متأكد، فشاهد إرشادات الترحيل.

التسعير

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

إنشاء خطة متميزة زائدة عن الحاجة وتطبيق وظائف

هناك حاليا طريقتان لنشر خطة مميزة زائدة عن الحاجة في المنطقة وتطبيق الوظائف. يمكنك استخدام إما مدخل Microsoft Azure أو قالب ARM.

مدخل Microsoft Azure

1. افتح مدخل Microsoft Azure وانتقل إلى صفحة Create Function App. يمكن العثور على معلومات حول إنشاء تطبيق دالة في المدخل هنا.

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

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

   

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

   الإعدادات	القيمة المقترحة	ملاحظات لتكرار المنطقة
   حساب التخزين	حساب تخزين متكرر في المنطقة	كما هو مذكور أعلاه في قسم المتطلبات الأساسية ، نوصي بشدة باستخدام حساب تخزين متكرر في المنطقة لتطبيق الوظائف المكررة في منطقتك.
   Plan Type	Functions Premium	توضح هذه المقالة بالتفصيل كيفية إنشاء تطبيق متكرر للمنطقة في خطة Premium. التكرار في المنطقة غير متوفر حاليًا في خطط الاستهلاك. يمكن العثور على معلومات حول تكرار المنطقة في خطط خدمة التطبيق في هذه المقالة.
   التكرار في المنطقة	مُمَكّن	يملأ هذا الحقل العلامة التي تحدد ما إذا كان تطبيقك زائدًا عن الحاجة أم لا. لن تتمكن من تحديد Enabled إلا إذا اخترت منطقة تدعم تكرار المنطقة، كما هو مذكور في الخطوة 2.

   

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

قالب ARM

يمكنك استخدام قالب ARM للنشر في خطة Premium زائدة عن الحاجة في المنطقة. لمعرفة كيفية نشر تطبيقات الوظائف إلى خطة Premium، راجع أتمتة توزيع الموارد في Azure Functions.

الخصائص الوحيدة التي يجب أن تكون على علم بها أثناء إنشاء خطة استضافة مكررة في منطقة هي خاصية zoneRedundant وحقول عدد مثيلات (capacity). يجب تعيين الخاصية zoneRedundant إلى true ويجب تعيين خاصية capacity استنادًا إلى متطلبات حمل العمل ولكن لا يقل عن 3. اختيار القدرة المناسبة يختلف على أساس عدة عوامل واستراتيجيات قابلية الوصول العالية/التسامح مع الخطأ. من القواعد الأساسية الجيدة ضمان مثيلات كافية للتطبيق بحيث يترك فقدان منطقة واحدة من المثيلات سعة كافية للتعامل مع الحمل المتوقع.

هام

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

وفيما يلي قصاصة برمجية لقالب ARM لخطة Premium المكررة في المنطقة، والتي تعرض الحقل الجديد zoneRedundantومواصفات capacity.

"resources": [
    {
        "type": "Microsoft.Web/serverfarms",
        "apiVersion": "2021-01-15",
        "name": "<YOUR_PLAN_NAME>",
        "location": "<YOUR_REGION_NAME>",
        "sku": {
            "name": "EP1",
            "tier": "ElasticPremium",
            "size": "EP1",
            "family": "EP", 
            "capacity": 3
        },
        "kind": "elastic",
        "properties": {
            "perSiteScaling": false,
            "elasticScaleEnabled": true,
            "maximumElasticWorkerCount": 20,
            "isSpot": false,
            "reserved": false,
            "isXenon": false,
            "hyperV": false,
            "targetWorkerCount": 0,
            "targetWorkerSizeId": 0, 
            "zoneRedundant": true
        }
    }
]

لمعرفة المزيد عن هذه القوالب، راجع أتمتة توزيع الموارد في Azure Functions.

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

ترحيل منطقة التوفر

لا تدعم Azure Function Apps حاليا الترحيل الموضعي لمثيلات تطبيقات الوظائف الموجودة. للحصول على معلومات حول كيفية ترحيل خطة Premium متعددة المستأجرين العامة من منطقة عدم التوفر إلى دعم منطقة التوفر، راجع ترحيل خدمة التطبيقات إلى دعم منطقة التوفر.

تجربة تعطل المنطقة

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

عندما تخصص الوظائف مثيلات لخطة Premium زائدة عن الحاجة للمنطقة، فإنها تستخدم موازنة منطقة الجهد الأفضل التي تقدمها مجموعات مقاييس Azure Virtual Machine الأساسية. تعتبر الخطة المتميزة متوازنة عندما يكون لكل منطقة نفس عدد الأجهزة الظاهرية (± 1 VM) في جميع المناطق الأخرى التي تستخدمها خطة Premium.

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

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

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

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

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

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

عند تشغيل نفس التعليمات البرمجية للدالة في مناطق متعددة، هناك نمطان يجب مراعاته، نشط-نشط ونشط-سلبي.

نمط نشط-نشط لوظائف مشغل HTTP

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

هام

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

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

نمط نشط-سلبي لوظائف مشغل غير HTTPS

يوصى باستخدام نمط نشط-سلبي للدالات المشغلة المستندة إلى الحدث وغير HTTP، مثل ناقل خدمة Microsoft Azure ومراكز الأحداث التي تم تشغيلها.

لإنشاء تكرار لوظائف مشغل غير HTTP، استخدم نمط نشط-سلبي. مع نمط نشط-سلبي، تعمل الوظائف بنشاط في المنطقة التي تتلقى الأحداث؛ بينما تظل نفس الدالات في منطقة ثانية الخامة. يوفر النمط النشط السلبي طريقة لدالة واحدة فقط لمعالجة كل رسالة مع توفير آلية للفشل إلى المنطقة الثانوية في كارثة. تعمل تطبيقات الدوال مع سلوكيات تجاوز الفشل لخدمات الشريك، مثل التعافي في المناطق الجغرافية لـ Azure Service Bus والتعافي في المناطق الجغرافية لـ Azure Event Hubs.

خذ بعين الاعتبار مثال طوبولوجيا باستخدام مشغل Azure Event Hubs. في هذه الحالة، يتطلب نمط نشط/سلبي المكونات التالية:

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

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

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

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

• إنشاء Azure Front Door
• اعتبارات تجاوز الفشل لمراكز الأحداث
• دليل Azure Architecture Center حول مناطق التوفر
• الموثوقية في Azure