مشاركة عبر

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

  • مقالة

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

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

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

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

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

تحافظ الدفعة على التماثل مع Azure على دعم مناطق التوفر.

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

  • بالنسبة إلى حسابات Batch لوضع اشتراك المستخدم، تأكد من أن الاشتراك الذي تقوم بإنشاء تجمعك فيه لا يحتوي على قيود عرض المنطقة على وحدة SKU للجهاز الظاهري المطلوبة. لمعرفة ما إذا كان اشتراكك لا يحتوي على أي قيود، اتصل ب Resource Skus List API وتحقق من ResourceSkuRestrictions. إذا كان هناك تقييد منطقة، يمكنك إرسال تذكرة دعم لإزالة تقييد المنطقة.

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

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

  • لتخصيص تجمع الدفعات عبر مناطق التوفر، يجب أن تدعم منطقة Azure التي تم إنشاء التجمع فيها وحدة SKU للجهاز الظاهري المطلوبة في أكثر من منطقة واحدة. للتحقق من أن المنطقة تدعم VM SKU المطلوبة في أكثر من منطقة واحدة، قم باستدعاء Resource Skus List API وتحقق من locationInforesourceSkuحقل . تأكد من دعم أكثر من منطقة واحدة ل VM SKU المطلوبة. يمكنك أيضا استخدام Azure CLI لسرد جميع وحدات SKU للمورد المتوفرة باستخدام الأمر التالي:

    
    az vm list-skus

إنشاء تجمع Azure Batch عبر مناطق التوفر

للحصول على أمثلة حول كيفية إنشاء تجمع Batch عبر مناطق التوفر، راجع إنشاء تجمع Azure Batch عبر مناطق التوفر.

تعرف على المزيد حول إنشاء حسابات الدفعة مع مدخل Microsoft Azure أو Azure CLI أو PowerShell أو واجهة برمجة تطبيقات إدارة الدفعات.

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

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

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

التسامح مع الخطأ

للتحضير لفشل محتمل في منطقة التوفر، يجب الإفراط في توفير سعة الخدمة للتأكد من أن الحل يمكن أن يتسامح مع فقدان السعة بنسبة 1/3 والاستمرار في العمل دون انخفاض الأداء أثناء الانقطاعات على مستوى المنطقة. نظراً لأن النظام الأساسي ينشر الأجهزة الظاهرية عبر ثلاث مناطق وتحتاج إلى حساب فشل منطقة واحدة على الأقل، فقم بضرب ذروة عدد مثيلات حمل العمل بعامل المناطق/(المناطق-1) أو 3/2. على سبيل المثال، إذا كان حمل العمل الذروة النموذجي يتطلب أربعة مثيلات، يجب توفير ستة مثيلات: (2/3 * 6 مثيلات) = 4 مثيلات.

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

لا يمكنك ترحيل تجمع Batch موجود إلى دعم منطقة التوفر. إذا كنت ترغب في إعادة إنشاء تجمع الدفعات عبر مناطق التوفر، فشاهد إنشاء تجمع Azure Batch عبر مناطق التوفر.

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

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

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

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

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

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

ضع بعين الاعتبار النقاط التالية عند تصميم حل يمكنه تجاوز الفشل:

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

  • تأكد مسبقا من تعيين الحصص النسبية المناسبة لجميع حسابات دفعة اشتراك المستخدم، لتخصيص العدد المطلوب من الذاكرات الأساسية باستخدام حساب Batch.

  • استخدم القوالب و/أو البرامج النصية للتنفيذ التلقائي لنشر التطبيق في المنطقة.

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

  • يُسهل استدعاء الدُفعة والتخزين وأي خدمات أخرى في التطبيق التبديل بين العملاء أو التحميل إلى مناطق مختلفة.

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

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

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

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

اختبار استرداد البيانات بعد الكوارث

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

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

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

تعمل Microsoft وعملاؤها ضمن نموذج المسؤولية المشتركة. تتحمل Microsoft مسؤولية النظام الأساسي ومرونة البنية الأساسية. أنت مسؤول عن معالجة التعافي من الكوارث لأي خدمة معينة تقوم بنشرها والتحكم فيها. لضمان أن يكون الاسترداد استباقيا:

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

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

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

إشعار

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

التخزين

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

يدعم Batch الأنواع التالية من حسابات تخزين Azure:

  • حسابات الأغراض العامة v2 (GPv2)
  • حسابات الأغراض العامة v1 (GPv1)
  • حسابات تخزين Blob (مدعومة حالياً للتجمعات في تكوين Virtual Machine)

لمزيد من المعلومات حول حسابات التخزين، راجع نظرة عامة على حساب تخزين Azure.

يمكنك إقران حساب تخزين بحساب Batch الخاص بك عند إنشاء الحساب أو القيام بهذه الخطوة لاحقا.

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

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

عند ربط حساب تخزين بحساب Batch، فكر فيه على أنه حساب تخزين تلقائي. مطلوب حساب تخزين تلقائي إذا كنت تخطط لاستخدام إمكانية حزم التطبيقات، كما يتم استخدامه لتخزين حزمة التطبيق .zip الملفات. يمكن أيضا استخدام حساب تخزين تلقائي لملفات موارد المهام؛ نظرا لأن حساب التخزين التلقائي مرتبط بالفعل بحساب Batch، فإن هذا يتجنب الحاجة إلى عناوين URL لتوقيع الوصول المشترك (SAS) للوصول إلى ملفات الموارد.

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