مشاركة عبر


Reliability in Azure Databricks

Azure Databricks هو منصة تعاونية تعتمد على Apache Spark للبيانات والذكاء الذكاء الاصطناعي، تم تحسينها لصالح Microsoft Azure. يوفر بيئة موحدة لأعباء عمل البيانات الضخمة والذكاء الذكاء الاصطناعي ويجمع بين أفضل ما في Databricks وAzure لتبسيط هندسة البيانات وعلوم البيانات وتعلم الآلة.

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

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

توصيات نشر الإنتاج

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

نظرة عامة على بنية الموثوقية

يجب أن تفهم مدى موثوقية كل مكون أساسي في Azure Databricks:

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

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

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

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

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

المرونة في مواجهة الأعطال العابرة

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

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

يمكنك التحكم في إعادة المحاولات للمهام داخل وظائف Lakeflow للمساعدة في التعافي من الأخطاء المؤقتة.

بالنسبة للتطبيقات التي تعمل على Azure Databricks، نفذ منطق إعادة المحاولة مع رفع أسي عند الاتصال بخدمات خارجية أو خدمات Azure، مثل Storage أو Azure SQL Database أو Azure Event Hubs. يتضمن Databricks Runtime مرونة مدمجة للعديد من خدمات Azure، لكن كود التطبيق يجب أن يتعامل مع الأعطال المؤقتة الخاصة بالخدمة.

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

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

يدعم Azure Databricks تكرار المنطقة لكل مكون:

  • مستوى التحكم: في المناطق التي تدعم مناطق التوفر، يعمل مستوى التحكم في عدة مناطق توافر. تتعامل طائرة التحكم مع أعطال المناطق تلقائيا، مع تأثير ضئيل ودون تدخل من المستخدم.

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

  • جذر DBFS: في المناطق التي تدعم مناطق التوفر، يمكنك تكوين حساب التخزين لجذر DBFS ليستخدم التخزين المتكرر للمنطقة (ZRS). في المناطق المزدوجة التي تدعم مناطق التوفر، يمكنك استخدام تخزين احتياطي للمنطقة الجيولوجية (GZRS).

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

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

المتطلبات

لاستخدام دعم منطقة التوفر في Azure Databricks، تحتاج إلى المتطلبات التالية:

  • دعم المنطقة: دعم منطقة توفر Azure Databricks متوفر في جميع مناطق Azure التي تدعم Azure Databricks وتوفر مناطق التوافر. للحصول على قائمة بالمناطق التي تدعم Azure Databricks، انظر المنتجات المتوفرة حسب المنطقة. للحصول على قائمة كاملة بالمناطق التي تدعم مناطق التوفر، راجع مناطق Azure التي تدعم مناطق التوفر.

  • تكرار التخزين: قم بتكوين حسابات تخزين مساحة العمل لاستخدام ZRS أو GZRS (حيثما توفرت الفرصة).

  • سعة الحوسبة: تأكد من وجود سعة حسابية كافية عبر عدة مناطق في منطقتك المستهدفة. يقوم Azure Databricks بتوزيع عقد التجمع تلقائيا عبر المناطق، لكن يجب عليك التحقق من توفر أنواع النسخ المختارة في جميع المناطق المستهدفة.

الاعتبارات

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

التكلفة

توزيع المناطق لا يؤثر على تكاليف الحوسبة لأنك تدفع مقابل نفس عدد الأجهزة الافتراضية بغض النظر عن موقعها في منطقة التوفر. لمزيد من المعلومات، انظر Azure Databricks compute preciing.

التكرار الافتراضي لحساب التخزين المدار، أو جذر DBFS، هو التخزين الجغرافي المتكرر (GRS). التغيير إلى ZRS أو GZRS قد يؤثر على تكاليف التخزين لديك. لمزيد من المعلومات، راجع تسعير Azure Blob Storage.

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

  • مستوى التحكم: تدعم طائرة التحكم تلقائيا تكرار المناطق في المناطق التي تحتوي على مناطق توفر. لا تحتاج إلى تكوين أي شيء.

  • جذر DBFS: يمكنك تكوين تكرار المنطقة لتخزين الجذر في DBFS عند إنشاء مساحة عمل جديدة أو تعديل مساحة عمل موجودة:

    • إنشاء مساحة عمل جديدة باستخدام تخزين جذر DBFS المتكرر في المنطقة: عند إنشاء مساحة عمل جديدة ل Azure Databricks، يمكنك اختياريا تكوين حساب التخزين المرتبط ليستخدم ZRS أو GZRS بدلا من GRS الافتراضي. لمزيد من المعلومات، راجع تغيير خيارات التكرار في مساحة العمل.

    • تمكين تكرار المناطق في تخزين الجذور في DBFS: بالنسبة لمساحات العمل الحالية، يمكنك تغيير تكوين التكرار في حساب تخزين مساحة العمل إلى ZRS أو GZRS. لمزيد من المعلومات حول كيفية تفعيل تكرار المناطق، راجع تغيير إعدادات النسخ لحساب تخزين.

  • مستوى الحوسبة: يتم توزيع عقد العنقود تلقائيا عبر مناطق التوفر. لا يلزم إعداد العميل لتوزيع المناطق.

السلوك عندما تكون جميع المناطق صحية

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

  • تكرار البيانات بين المناطق: يحدث نسخ البيانات لتخزين مساحة العمل بشكل متزامن عبر المناطق عندما يستخدم جذر DBFS حساب ZRS أو GZRS. يضمن هذا النهج اتساقا قويا مع تأثير أداء ضئيل للغاية.

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

السلوك أثناء فشل المنطقة

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

  • الكشف والاستجابة: تكتشف مايكروسوفت تلقائيا أعطال المناطق وتبدأ إجراءات الاستجابة. لا تحتاج إلى اتخاذ أي إجراء لاستبدال الفشل على مستوى المنطقة.

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

  • الطلبات النشطة: قد تفقد المجموعات الجارية العقد في المنطقة المتأثرة. يطلب مدير العنقود تلقائيا عقد بديلة من المناطق المتبقية. إذا فقدت عقدة التعريف، يعاد العنقود والمهمة التشغيل بالكامل.

  • فقدان البيانات المتوقع:

    • مستوى التحكم: لا تتوقع فقدان بيانات أثناء انقطاع المنطقة.

    • جذر DBFS: تظل بيانات مساحة العمل متاحة إذا استخدمت تكوينات تخزين ZRS أو GZRS.

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

  • وقت التوقف المتوقع:

    • مستوى التحكم: يقوم مستوى التحكم في Databricks بإجراء التحويل التلقائي التلقائي إلى المناطق الصحية خلال حوالي 15 دقيقة.

    • جذر DBFS: لا توقع أي توقف لحسابات التخزين التي تستخدم ZRS أو GZRS.

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

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

      يمكنك استخدام مجموعات الخادم بدون خادم أو مجموعات مثيلات لتقليل هذا الوقت.

  • إعادة توجيه حركة المرور:

    • مستوى التحكم: يقوم مستوى التحكم في Databricks بإجراء التحويل التلقائي التلقائي إلى المناطق الصحية خلال حوالي 15 دقيقة.

    • جذر DBFS: يقوم Azure Storage تلقائيا بإعادة توجيه الطلبات إلى مجموعات التخزين في المناطق الصحية.

    • مستوى الحوسبة: يقوم مدير العنقود تلقائيا بالتبديل إلى العقد في المناطق الصحية.

استعادة المنطقة

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

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

اختبار فشل المنطقة

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

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

القدرة على الصمود في وجه الإخفاقات على مستوى المنطقة

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

حلول مخصصة متعددة المناطق للمرونة

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

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

لاختيار هندسة معمارية، ضع في اعتبارك العوامل التالية:

  • أهمية عبء العمل على عملك
  • المدة المحتملة للاضطراب (ساعات أو ربما يوم كامل)
  • الجهد المطلوب لجعل مساحة العمل تعمل بالكامل
  • الجهد المطلوب لاستعادة أو فشل العودة إلى المنطقة الأساسية

بالنسبة لأعباء العمل التي تتطلب حماية متعددة المناطق، انظر Azure Databricks Disaster Recovery.

النسخ الاحتياطي والاسترداد.

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

‏‫ملاحظة

إذا حدث عطل في المنطقة، لا يتوقع Azure Databricks فقدان بيانات.

ننصحك بتخزين بياناتك على تخزين كتالوج Unity. يمكنك تكرار البيانات من خلال تكرار التخزين أو استنساخ دلتا.

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

المرونة في صيانة الخدمة

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

اتفاقية مستوى الخدمة

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