توزيع Azure Databricks في شبكة Azure الظاهرية (حقن الشبكة الظاهرية)

  • مقالة

توضح هذه المقالة كيفية نشر مساحة عمل Azure Databricks في شبكة Azure الظاهرية الخاصة بك، والمعروفة أيضا باسم حقن الشبكة الظاهرية.

تخصيص الشبكة مع حقن VNet

النشر الافتراضي ل Azure Databricks هو خدمة مدارة بالكامل على Azure. يتم نشر شبكة Azure الظاهرية (VNet) إلى مجموعة موارد مؤمنة. ترتبط جميع موارد وحدة الحوسبة الكلاسيكية بتلك الشبكة الظاهرية. إذا كنت تحتاج إلى تخصيص الشبكة، يمكنك نشر موارد وحدة الحوسبة الكلاسيكية Azure Databricks في شبكتك الظاهرية. يمكّنك هذا من:

يتيح لك نشر موارد وحدة الحوسبة الكلاسيكية في Azure Databricks على الشبكة الظاهرية الخاصة بك أيضا الاستفادة من نطاقات CIDR المرنة. بالنسبة للشبكة الظاهرية، يمكنك استخدام حجم /16-/24نطاق CIDR . بالنسبة للشبكات الفرعية، استخدم نطاقات IP صغيرة مثل /26.

هام

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

متطلبات الشبكة الظاهرية

يجب أن تفي الشبكة الظاهرية التي تقوم بنشر مساحة عمل Azure Databricks بها بالمتطلبات التالية:

  • المنطقة: يجب أن تتواجد الشبكة الظاهرية في نفس المنطقة والاشتراك مثل مساحة عمل Azure Databricks.
  • الاشتراك: يجب أن تكون الشبكة الظاهرية في نفس الاشتراك مثل مساحة عمل Azure Databricks.
  • مساحة العنوان: كتلة CIDR بين /16 و /24 للشبكة الظاهرية وحظر CIDR حتى /26 للشبكتين الفرعيتين: شبكة فرعية للحاوية وشبكة فرعية مضيفة. للحصول على إرشادات حول الحد الأقصى لعقد نظام المجموعة استنادا إلى حجم الشبكة الظاهرية والشبكات الفرعية الخاصة بها، راجع مساحة العنوان والحد الأقصى لعقد نظام المجموعة.
  • الشبكات الفرعية: يجب أن تتضمن الشبكة الظاهرية شبكتين فرعيتين مخصصتين لمساحة عمل Azure Databricks: شبكة فرعية للحاوية (تسمى أحيانا الشبكة الفرعية الخاصة) وشبكة فرعية مضيفة (تسمى أحيانا الشبكة الفرعية العامة). عند نشر مساحة عمل باستخدام اتصال نظام المجموعة الآمن، تستخدم كل من الشبكة الفرعية للحاوية والشبكة الفرعية المضيفة عناوين IP خاصة. لا يمكنك مشاركة الشبكات الفرعية عبر مساحات العمل أو توزيع موارد Azure الأخرى على الشبكات الفرعية التي تستخدمها مساحة عمل Azure Databricks. للحصول على إرشادات حول الحد الأقصى لعقد نظام المجموعة استنادا إلى حجم الشبكة الظاهرية والشبكات الفرعية الخاصة بها، راجع مساحة العنوان والحد الأقصى لعقد نظام المجموعة.

مساحة العنوان والحد الأقصى لعقد نظام المجموعة

يمكن أن نفدت مساحة العمل مع شبكة ظاهرية أصغر من عناوين IP (مساحة الشبكة) بسرعة أكبر من مساحة العمل مع شبكة ظاهرية أكبر. استخدم كتلة CIDR بين /16 و /24 للشبكة الظاهرية وحظر CIDR حتى /26 للشبكتين الفرعيتين (الشبكة الفرعية للحاوية والشبكة الفرعية للمضيف). يمكنك إنشاء كتلة CIDR حتى /28 للشبكات الفرعية الخاصة بك، ولكن لا يوصي Databricks بشبكة فرعية أصغر من /26.

يؤثر نطاق CIDR لمساحة عنوان VNet على الحد الأقصى لعدد عقد نظام المجموعة التي يمكن أن تستخدمها مساحة العمل الخاصة بك.

تتطلب مساحة عمل Azure Databricks شبكتين فرعيتين في الشبكة الظاهرية: شبكة فرعية للحاوية وشبكة فرعية مضيفة. يحتفظ Azure بخمسة عناوين IP في كل شبكة فرعية. يتطلب Azure Databricks عنواني IP لكل عقدة نظام مجموعة: عنوان IP واحد للمضيف في الشبكة الفرعية للمضيف وعنوان IP واحد للحاوية في الشبكة الفرعية للحاوية.

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

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

مساحة عنوان الشبكة الظاهرية (CIDR) الحد الأقصى لحجم الشبكة الفرعية ل Azure Databricks (CIDR) بافتراض عدم وجود شبكات فرعية أخرى
/16 /17
/17 /18
/18 /19
/20 /21
/21 /22
/22 /23
/23 /24
/24 /25

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

حجم الشبكة الفرعية (CIDR) عناوين IP لكل شبكة فرعية الحد الأقصى لعقد نظام مجموعة Azure Databricks
/17 32768 32763
/18 16384 16379
/19 8192 8187
/20 4096 4091
/21 2048 2043
/22 1024 1019
/23 512 507
/24 256 251
/25 128 123
/26 64 59

عناوين IP للخروج عند استخدام اتصال نظام المجموعة الآمن

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

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

تحذير

أعلنت Microsoft أنه في 30 سبتمبر 2025، سيتم إيقاف اتصال الوصول الصادر الافتراضي للأجهزة الظاهرية في Azure. راجع هذا الإعلان. وهذا يعني أن مساحات عمل Azure Databricks التي تستخدم الوصول الصادر الافتراضي بدلا من IP عام ثابت للخروج قد لا تستمر في العمل بعد ذلك التاريخ. توصي Databricks بإضافة أساليب صادرة صريحة لمساحات العمل قبل ذلك التاريخ.

لتكوين IP عام ثابت للخروج، راجع Egress مع حقن VNet

الموارد المشتركة والتناظر

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

إذا كانت لديك موارد أخرى في الشبكة الظاهرية أو تستخدم التناظر، فإن Databricks توصي بشدة بإضافة قواعد Deny إلى مجموعات أمان الشبكة (NSGs) المرفقة بالشبكات والشبكات الفرعية الأخرى الموجودة في نفس VNet أو التي يتم إقرانها بتلك الشبكة الظاهرية. أضف قواعد الرفض للاتصالات لكل من الاتصالات الواردة والصادرة بحيث تحد من الاتصالات من وإلى موارد حساب Azure Databricks. إذا كان نظام المجموعة الخاص بك يحتاج إلى الوصول إلى الموارد على الشبكة، أضف قواعد للسماح فقط بالحد الأدنى من الوصول المطلوب لتلبية المتطلبات.

للحصول على معلومات ذات صلة، راجع قواعد مجموعة أمان الشبكة.

إنشاء مساحة عمل Azure Databricks باستخدام مدخل Microsoft Azure

يصف هذا القسم كيفية إنشاء مساحة عمل Azure Databricks في مدخل Microsoft Azure ونشرها في الشبكة الظاهرية الموجودة لديك. يقوم Azure Databricks بتحديث الشبكة الظاهرية بشبكتين فرعيتين جديدتين إذا لم تكن موجودة بعد، باستخدام نطاقات CIDR التي تحددها. تقوم الخدمة أيضا بتحديث الشبكات الفرعية بمجموعة أمان شبكة جديدة، وتكوين القواعد الواردة والصادرة، وأخيرا نشر مساحة العمل إلى الشبكة الظاهرية المحدثة. لمزيد من التحكم في تكوين VNet، استخدم قوالب Azure-Databricks-supplied Azure Resource Manager (ARM) بدلا من المدخل. على سبيل المثال، استخدم مجموعات أمان الشبكة الموجودة أو أنشئ قواعد الأمان الخاصة بك. راجع التكوين المتقدم باستخدام قوالب Azure Resource Manager.

يجب تعيين دور مساهم الشبكة للمستخدم الذي يقوم بإنشاء مساحة العمل إلى الشبكة الظاهرية المقابلة، أو دور مخصص تم تعيين الأذونات Microsoft.Network/virtualNetworks/subnets/join/action و Microsoft.Network/virtualNetworks/subnets/write .

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

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

  1. في مدخل Microsoft Azure، حدد + Create a resource > Analytics > Azure Databricks أو ابحث عن Azure Databricks وانقر فوق Create أو + Add لتشغيل مربع حوار Azure Databricks Service.

  2. اتبع خطوات التكوين الموضحة في إنشاء مساحة عمل Azure Databricks في التشغيل السريع ل VNet الخاص بك.

  3. في علامة التبويب Networking ، حدد VNet الذي تريد استخدامه في حقل Virtual network .

    هام

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

    تحديد الشبكة الظاهرية

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

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

    يتطلب Azure Databricks أن لا تزيد أسماء الشبكات الفرعية عن 80 حرفا.

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

  5. انقر فوق Create لنشر مساحة عمل Azure Databricks إلى VNet.

التكوين المتقدم باستخدام قوالب Azure Resource Manager

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

إذا كنت تستخدم قالب Azure Resource Manager مخصصا أو قالب مساحة العمل لحقن Azure Databricks VNet لنشر مساحة عمل إلى شبكة ظاهرية موجودة، يجب إنشاء شبكات فرعية للمضيف والحاوية، وإرفاق مجموعة أمان شبكة اتصال بكل شبكة فرعية، وتفويض الشبكات الفرعية إلى Microsoft.Databricks/workspaces موفر الموارد قبل نشر مساحة العمل. يجب أن يكون لديك زوج منفصل من الشبكات الفرعية لكل مساحة عمل تقوم بنشرها.

قالب الكل في واحد

لإنشاء مساحة عمل VNet وAzure Databricks باستخدام قالب واحد، استخدم القالب الكل في واحد لمساحات العمل المحقونة في Azure Databricks VNet.

قالب الشبكة الظاهرية

لإنشاء شبكة ظاهرية مع الشبكات الفرعية المناسبة باستخدام قالب، استخدم قالب VNet لحقن Databricks VNet.

قالب مساحة عمل Azure Databricks

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

يسمح لك قالب مساحة العمل بتحديد شبكة ظاهرية موجودة واستخدام الشبكات الفرعية الموجودة:

  • يجب أن يكون لديك زوج منفصل من الشبكات الفرعية للمضيف/الحاوية لكل مساحة عمل تقوم بنشرها. لا يتم دعم مشاركة الشبكات الفرعية عبر مساحات العمل أو نشر موارد Azure الأخرى على الشبكات الفرعية التي تستخدمها مساحة عمل Azure Databricks.
  • يجب أن يكون لدى مضيف الشبكة الظاهرية والشبكات الفرعية للحاوية مجموعات أمان شبكة اتصال مرفقة ويجب تفويضها إلى Microsoft.Databricks/workspaces الخدمة قبل استخدام قالب Azure Resource Manager هذا لنشر مساحة عمل.
  • لإنشاء شبكة ظاهرية مع شبكات فرعية مفوضة بشكل صحيح، استخدم قالب VNet لحقن Databricks VNet.
  • لاستخدام شبكة ظاهرية موجودة عند عدم تفويض الشبكات الفرعية للمضيف والحاوية بعد، راجع إضافة تفويض شبكة فرعية أو إزالته.

قواعد مجموعة أمان الشبكة

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

كيفية إدارة Azure Databricks لقواعد مجموعة أمان الشبكة

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

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

هام

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

قواعد مجموعة أمان الشبكة لمساحات العمل

تنطبق المعلومات الواردة في هذا القسم فقط على مساحات عمل Azure Databricks التي تم إنشاؤها بعد 13 يناير 2020. إذا تم إنشاء مساحة العمل الخاصة بك قبل إصدار اتصال نظام المجموعة الآمن (SCC) في 13 يناير 2020، فشاهد القسم التالي.

يسرد هذا الجدول قواعد مجموعة أمان الشبكة لمساحات العمل ويتضمن قاعدتين لمجموعة الأمان الواردة التي يتم تضمينها فقط إذا تم تعطيل اتصال نظام المجموعة الآمن (SCC ).

الاتجاه البروتوكول المصدر منفذ المصدر الوجهة ميناء الوجهة مستخدم
وارد أي VirtualNetwork أي VirtualNetwork أي الإعداد الافتراضي
وارد TCP AzureDatabricks (علامة الخدمة)
فقط إذا تم تعطيل SCC		 أي VirtualNetwork 22 عنوان IP عام
وارد TCP AzureDatabricks (علامة الخدمة)
فقط إذا تم تعطيل SCC		 أي VirtualNetwork 5557 عنوان IP عام
صادر TCP VirtualNetwork أي AzureDatabricks (علامة الخدمة) 443, 3306, 8443-8451 الإعداد الافتراضي
صادر TCP VirtualNetwork أي SQL 3306 الإعداد الافتراضي
صادر TCP VirtualNetwork أي التخزين 443 الإعداد الافتراضي
صادر أي VirtualNetwork أي VirtualNetwork أي الإعداد الافتراضي
صادر TCP VirtualNetwork أي EventHub 9093 افتراضية

إشعار

إذا قمت بتقييد القواعد الصادرة، توصي Databricks بفتح المنفذين 111 و2049 لتمكين تثبيتات معينة للمكتبة.

هام

Azure Databricks هي خدمة الطرف الأول من Microsoft Azure التي يتم نشرها على البنية الأساسية ل Global Azure Public Cloud. تظل جميع الاتصالات بين مكونات الخدمة، بما في ذلك بين عناوين IP العامة في مستوى التحكم ولوحة حساب العميل، داخل العمود الفقري لشبكة Microsoft Azure. راجع أيضا شبكة Microsoft العمومية.

استكشاف الاخطاء

أخطاء إنشاء مساحة العمل

تتطلب الشبكة <subnet-id> الفرعية أي من التفويضات التالية [Microsoft.Databricks/workspaces] للإشارة إلى ارتباط اقتران الخدمة

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

الشبكة <subnet-id> الفرعية قيد الاستخدام بالفعل بواسطة مساحة العمل <workspace-id>

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

استكشاف الأخطاء وإصلاحها

المثيلات غير قابلة للوصول: لم يتم الوصول إلى الموارد عبر SSH.

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

فشل تشغيل غير متوقع: حدث خطأ غير متوقع أثناء إعداد نظام المجموعة. يرجى إعادة المحاولة والاتصال ب Azure Databricks إذا استمرت المشكلة. رسالة الخطأ الداخلية: Timeout while placing node.

السبب المحتمل: تم حظر نسبة استخدام الشبكة من العمال إلى نقاط نهاية Azure Storage. إذا كنت تستخدم خوادم DNS مخصصة، فتحقق أيضا من حالة خوادم DNS في VNet.

فشل تشغيل موفر السحابة: تمت مصادفة خطأ موفر السحابة أثناء إعداد نظام المجموعة. راجع دليل Azure Databricks لمزيد من المعلومات. رمز خطأ Azure: AuthorizationFailed/InvalidResourceReference.

السبب المحتمل: الشبكة الظاهرية أو الشبكات الفرعية غير موجودة بعد الآن. تأكد من وجود الشبكة الظاهرية والشبكات الفرعية.

تم إنهاء نظام المجموعة. السبب: فشل بدء تشغيل Spark: لم يتمكن Spark من البدء في الوقت المناسب. يمكن أن تكون هذه المشكلة ناتجة عن خلل في Hive metastore أو تكوينات Spark غير صالحة أو تعطل البرامج النصية init. راجع سجلات برنامج تشغيل Spark لاستكشاف هذه المشكلة وإصلاحها، ثم اتصل ب Databricks إذا استمرت المشكلة. رسالة الخطأ الداخلية: Spark failed to start: Driver failed to start in time.

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