إصلاح الأعطال والتوزيع الجغرافي في دوال Azure الدائمة
تسعى Microsoft جاهدة لضمان إتاحة خدمات Azure دائمًا. ومع ذلك، قد يحدث انقطاعات الخدمة غير المخطط لها. إذا تطلب التطبيق مرونة، توصي Microsoft بتكوين تطبيقك للتكرار الجغرافي. بالإضافة إلى ذلك، ينبغي أن يكون لدى العملاء خطة إصلاح بعد عطل فادح لمعالجة انقطاع الخدمة الإقليمية. يستعد جزء مهم من خطة إصلاح عطل فادح للرجوع الاحتياطي في النسخة المتماثلة الثانوية لتطبيقك والتخزين في حالة عدم إتاحة النسخة المتماثلة الأساسية.
في "دوال دائمة"، يتم استمرار كل الحالات في تخزين Azure بشكل افتراضي. محور المهام هي حاوية منطقية لموارد تخزين Azure المستخدمة في التزامناتوالكيانات. يمكن أن تتفاعل دوال المنسق والنشاط والكيان مع بعضها البعض فقط عندما تنتمي إلى نفس محور المهمة. سوف يشير هذا المستند إلى محاور المهمة عند وصف سيناريوهات الاحتفاظ بموارد تخزين Azure هذه المتاحة بشكل كبير.
إشعار
يفترض التوجيه في هذه المقالة أنك تستخدم موفّر تخزين Azure الافتراضي لتخزين حالة وقت تشغيل "دوال دائمة". ومع ذلك، من الممكن تكوين موفري التخزين البديلة التي تخزن الحالة في مكان آخر، مثل قاعدة بيانات خادم SQL. وقد تكون هناك حاجة إلى استراتيجيات مختلفة لإصلاح الأعطال والتوزيع الجغرافي لمقدمي خدمات التخزين البديلة. لمزيدٍ من المعلومات حول خيارات موفري التخزين المختلفين، راجع وثائق موفري تخزين الدوال الدائمة.
يمكن تشغيل التزامنات والكيانات باستخدام دوال العميل التي يتم تشغيلها عبر HTTP أو أحد أنواع مشغلات دوال Azure المعتمدة الأخرى. ويمكن أيضًا تشغيلها باستخدام واجهات برمجة التطبيقات HTTP المضمنة. للبساطة، ستركز هذه المقالة على السيناريوهات التي تتضمن مشغلات دالة تخزين Azure والمستندة إلى HTTP والخيارات لزيادة التوفر وتقليل وقت التعطل أثناء أنشطة إصلاح عطل فادح. لن تتم تغطية أنواع المشغلات الأخرى، مثل ناقل خدمة Microsoft Azure أو مشغلات Azure Cosmos DB، بشكل صريح.
تستند السيناريوهات التالية إلى تكوينات نشطة-خاملة، حيث يتم إرشادها باستخدام تخزين Azure. يتكون هذا النمط من نشر تطبيق دالة النسخ الاحتياطي (الخامل) إلى منطقة مختلفة. ستراقب إدارة نسبة استخدام الشبكة تطبيق الدوال الأساسي (النشط) لتوفر HTTP. وسوف ترجع احتياطيًا إلى تطبيق دالة النسخ الاحتياطي إذا فشل الأساسي. لمزيدٍ من المعلومات، راجع أسلوب الأولوية لتوجيه حركة المرورلإدارة نسبة استخدام الشبكة Azure.
إشعار
- يضمن التكوين النشط-الخامل المقترح أن العميل قادر دائما على تشغيل التزامنات الجديدة عبر HTTP. ومع ذلك، نتيجة لوجود تطبيقين للدالة اللذان يشاركان نفس محور المهمة في التخزين، سيتم توزيع بعض معاملات تخزين الخلفية بينهما. ولذلك، فإن هذا التكوين يؤدي إلى تكبد بعض تكاليف الخروج الإضافية لتطبيق الدوال الثانوية.
- يتم إنشاء حساب التخزين الأساسي ومركز المهام في المنطقة الأساسية، ويتم مشاركتهما من قبل كل من تطبيقات الدوال.
- يجب أن تشترك جميع تطبيقات الدوال التي يتم نشرها بشكل زائد عن الحاجة في نفس مفاتيح وصول الدوال في حالة تنشيطها عبر HTTP. يعرض وقت تشغيل الدوال إدارة واجهة برمجة التطبيقات التي تمكن المستهلكين من إضافة مفاتيح الدوال وحذفها وتحديثها برمجيًّا. إدارة المفاتيح ممكن أيضًا أن تستخدم واجهات برمجة التطبيقات لإدارة موارد Azure.
السيناريو 1 - تحميل حساب متوازن مع التخزين المشترك
إذا فشلت البنية الأساسية للحوسبة في Azure، قد يصبح تطبيق الدالة غير متاح. لتقليل إمكانية مثل وقت التعطل هذا، يستخدم هذا السيناريو تطبيقين دالة يتم نشرهما إلى مناطق مختلفة. تم تكوين إدارة نسبة استخدام الشبكة للكشف عن المشاكل في تطبيق الدالة الأساسي وإعادة توجيه نسبة استخدام الشبكة تلقائيًا إلى تطبيق الدالة في المنطقة الثانوية. يشارك تطبيق الدالة هذا نفس حساب تخزين Azure ومركز المهام. لذلك، لا يتم فقدان حالة تطبيقات الدوال ويمكن استئناف العمل بشكل طبيعي. بمجرد استعادة الصحة إلى المنطقة الأساسية، ستبدأ إدارة نسبة استخدام الشبكة Azure بتوجيه الطلبات إلى تطبيق الدوال هذا تلقائيا.
هناك العديد من الفوائد عند استخدام سيناريو النشر هذا:
- إذا فشلت البنية الأساسية للحوسبة، يمكن استئناف العمل في منطقة الرجوع الاحتياطي دون فقدان البيانات.
- إدارة نسبة استخدام الشبكة تعتني بالرجوع الاحتياطي التلقائي إلى تطبيق الدالة الصحية تلقائيا.
- تقوم إدارة نسبة استخدام الشبكة تلقائيا بإعادة تأسيس نسبة استخدام الشبكة إلى تطبيق الدوال الأساسية بعد تصحيح الانقطاع.
ومع ذلك، باستخدام هذا السيناريو خذ بعين الاعتبار:
- إذا تم نشر تطبيق الدوال باستخدام خطة مخصصة لخدمة التطبيقات، فإن تكرار البنية الأساسية للحوسبة في مركز بيانات الرجوع الاحتياطي يزيد من التكاليف.
- يغطي هذا السيناريو الانقطاعات في البنية الأساسية للحوسبة، ولكن حساب التخزين لا يزال نقطة واحدة من الفشل لتطبيق الدالة. في حالة حدوث انقطاع التخزين، يعاني التطبيق من وقت تعطل.
- إذا فشل تطبيق الدالة، فسيزيد زمن الوصول لأنه سيتم الوصول إلى حسابه للتخزين عبر المناطق.
- الوصول إلى خدمة التخزين من منطقة مختلفة حيث يقع يتكبد في تكلفة أعلى بسبب نسبة استخدام الشبكة لخروج الشبكة.
- يعتمد هذا السيناريو على إدارة نسبة استخدام الشبكة. النظر في كيفية عمل إدارة نسبة استخدام الشبكة، قد يأخذ بعض الوقت حتى يحتاج تطبيق العميل الذي يستهلك دالة دائمة إلى الاستعلام مرة أخرى عن عنوان تطبيق الدالة من إدارة نسبة استخدام الشبكة.
إشعار
بدءا من v2.3.0 من ملحق "الدوال الدائمة"، يمكن تشغيل تطبيقين للدالة بأمان في نفس الوقت باستخدام نفس حساب التخزين وتكوين المحور للمهمة. سيحصل التطبيق الأول، الذي سيبدأ على إيجار الفقاعة على مستوى التطبيق، الذي يمنع التطبيقات الأخرى من سرقة الرسائل من قوائم انتظار المحور للمهمة. إذا توقف هذا التطبيق الأول عن التشغيل، ستنتهي صلاحية إيجاره ويمكن الحصول عليه من خلال تطبيق ثانٍ، والذي سيتابع بعد ذلك معالجة رسائل المحور للمهمة.
قبل v2.3.0، ستعالج تطبيقات الدوال، التي تم تكوينها لاستخدام نفس حساب التخزين، الرسائل وستحدث أدوات التخزين في وقت واحد، مما سيؤدى إلى أزمنة وصول أعلى بكثير وإلى تكاليف للخروج. إذا كانت التطبيقات الأساسية والنسخة المتماثلة لديها أبدًا أي رمز مختلف تم نشره لهم، ولو مؤقتًا، إذًا، قد تفشل التزامنات في التنفيذ بشكل صحيح بسبب عدم تناسق دالة التزامن عبر التطبيقين. لذلك يوصى بأن تستخدم جميع التطبيقات التي تتطلب التوزيع الجغرافي لأغراض إصلاح الأعطال v2.3.0 أو أعلى من الملحق الدائم.
السيناريو 2 - تحميل حساب متوازن مع التخزين الإقليمي
يغطي السيناريو السابق حالة الفشل في البنية الأساسية للحوسبة. إذا فشلت خدمة التخزين، سيؤدي ذلك إلى انقطاع تطبيق الدوال. لضمان التشغيل المستمر للدوال الدائمة، يستخدم هذا السيناريو حساب تخزين محلي في كل منطقة يتم نشر تطبيقات الدوال إليها.
يضيف هذا النهج تحسينات على السيناريو السابق:
- إذا فشل تطبيق الدالة، فإن إدارة نسبة استخدام الشبكة تهتم بالرجوع الاحتياطي في المنطقة الثانوية. ومع ذلك، لأن تطبيق الدالة يعتمد على حسابه للتخزين، تُواصل الدوال الدائمة العمل.
- أثناء الرجوع الاحتياطي، لا يوجد زمن وصول إضافي في منطقة الرجوع الاحتياطي نظرًا لأن تطبيق الدالة وحساب التخزين متواصلان شبكيًّا.
- سيؤدي فشل طبقة التخزين إلى حدوث حالات فشل في الدوال الدائمة، والتي بدورها ستشغل إعادة التوجيه إلى منطقة الرجوع الإحتياطي. مرة أخرى، نظرًا لأن تطبيق الدالة والتخزين معزولان لكل منطقة، ستستمر الدوال الدائمة في العمل.
اعتبارات هامة لهذا السيناريو:
- إذا تم نشر تطبيق الدوال باستخدام خطة مخصصة لخدمة التطبيقات، فإن تكرار البنية الأساسية للحوسبة في مركز بيانات الرجوع الاحتياطي يزيد من التكاليف.
- لم يتم الرجوع الاحتياطي للحالة الحالية، مما يعني أن التزامنات والكيانات الموجودة سيتم إيقافها مؤقتًا بشكل فعال ولن تكون متاحة حتى تتعافى المنطقة الأساسية.
للتلخيص، المفاضلة بين السيناريو الأول والثاني هو أن يتم الاحتفاظ بزمن الوصول وأن يتم تقليل تكاليف الخروج ولكن التزامنات والكيانات الموجودة لن تكون متاحة أثناء وقت التعطل. ما إذا كانت هذه المفاضلات مقبولة يعتمد على متطلبات التطبيق.
السيناريو 3 - تحميل حساب متوازن مع تخزين GRS مشترك
هذا السيناريو هو تعديل عبر السيناريو الأول، بتطبيق حساب تخزين مشترك. والفرق الرئيسي هو أن حساب التخزين يتم إنشاؤه مع تمكين النسخ المتماثل الجغرافي. يوفر هذا السيناريو وظيفيا نفس مزايا السيناريو 1 ولكنه يتيح مزايا استرداد البيانات الإضافية:
- تزيد سعة التخزين الجغرافية الزائدة عن الحاجة (GRS) وGRS (RA-GRS) الموصول للقراءة، من إتاحة حسابك للتخزين.
- إذا كان هناك انقطاع إقليمي لخدمة التخزين، يمكنك بدء الرجوع الاحتياطي يدويًا إلى النسخة المتماثلة الثانوية. في الحالات القصوى حيث يتم فقدان منطقة بسبب كارثة كبيرة، قد تبدأ Microsoft رجوع إحتياطي إقليمي. في هذه الحالة، لا يلزم اتخاذ أي إجراء من جانبك.
- عند حدوث الرجوع الإحتياطي، سيتم الاحتفاظ بحالة الدوال الدائمة حتى النسخ المتماثل الأخير لحساب التخزين، والذي يحدث عادة كل بضع دقائق.
وكما هو الحال مع السيناريوهات الأخرى، هناك اعتبارات هامة:
- الرجوع الاحتياطي إلى النسخة المتماثلة قد يستغرق بعض الوقت. حتى اكتمال الرجوع الإحتياطي وتحديث سجلات DNS لتخزين Azure، سوف يعاني تطبيق الدالة من انقطاع.
- هناك تكلفة متزايدة لاستخدام حسابات التخزين المنسوخة جغرافيًا.
- تنسخ النُسخ المُتماثلة من GRS البيانات بشكل غير متزامن. قد يتم فقدان بعض المعاملات الأخيرة بسبب زمن وصول عملية النسخ المتماثل.
إشعار
كما هو موضح في السيناريو 1، فمن الموصى بشدة أن تستخدم تطبيقات الدوال المنشورة مع هذه الاستراتيجية v2.3.0 أو أعلى من ملحق الدوال الدائم.
لمزيدٍ من المعلومات، راجع وثائق الرجوع الاحتياطي في حساب التخزين وإصلاح عطل التخزين من Azure.