إشعار
يتطلب الوصول إلى هذه الصفحة تخويلاً. يمكنك محاولة تسجيل الدخول أو تغيير الدلائل.
يتطلب الوصول إلى هذه الصفحة تخويلاً. يمكنك محاولة تغيير الدلائل.
ينطبق على: ✔️ أجهزة Linux الظاهرية ✔️ مجموعات مقياس مرنة
إذا قمت بإنشاء صور مخصصة معممة واستخدام cloud-init للتزويد، فقد لا يتم إنشاء الجهاز الظاهري بشكل صحيح. في هذه الحالة، قم باستكشاف أخطاء الصورة وإصلاحها للعثور على المشكلة.
بعض الأمثلة، للمشكلات المتعلقة بالتوفير:
- ترجع واجهة برمجة تطبيقات موفر موارد الحوسبة خطأ، وتقارير cloud-init عن الفشل الناتج.
- يتعطل الجهاز الظاهري عند "الإنشاء" لمدة 40 دقيقة، ويتم وضع علامة على إنشاء الجهاز الظاهري على أنه فاشل.
- لا تتم معالجة البيانات المخصصة أو بيانات المستخدم.
- فشل تحميل القرص المؤقت (ل Skus VM التي تأتي مع أقراص موارد SCSI).
- لا يتم إنشاء المستخدمين، أو هناك مشكلات في وصول المستخدم.
- لم يتم إعداد الشبكات بشكل صحيح.
- فشل ملف المبادلة أو القسم.
توضح لك هذه المقالة كيفية استكشاف أخطاء cloud-init وإصلاحها. لمزيد من التفاصيل، راجع التعمق في تفاصيل cloud-init.
تنبيه
تشير هذه المقالة إلى CentOS، توزيع Linux الذي يمثل حالة انتهاء الدعم (EOS). ضع في اعتبارك استخدامك والتخطيط وفقا لذلك. لمزيد من المعلومات، راجع إرشادات نهاية العمر الافتراضي CentOS.
استكشاف الأخطاء وإصلاحها التي تم الإبلاغ عنها بواسطة cloud-init وتسجيلها كخطأ
يصدر Cloud-init أخطاء منظمة عند الإبلاغ عن فشل في Azure أثناء التوفير. تتضمن رسائل الخطأ هذه سببا وبيانات داعمة (مثل الطابع الزمني ومعرف الجهاز الظاهري وعنوان URL للوثائق وما إلى ذلك) للمساعدة في التحقيق في الفشل.
| السبب | وصف | الإجراء |
|---|---|---|
| فشل العثور على واجهة DHCP | لم يتم العثور على واجهة شبكة اتصال. | حذف الجهاز الظاهري وإعادة إنشائه. إذا استمرت المشكلة، فتأكد من تثبيت برامج تشغيل الشبكات أو النواة الخاصة ب Azure وتحقق من تشخيصات التمهيد للتحقق من تعداد eth0. |
| فشل الحصول على عقد إيجار DHCP | تفشل خدمة DHCP في الاستجابة بسبب مشكلة عابرة في النظام الأساسي. | أعد نشر الجهاز الافتراضي (حذف + إعادة إنشاء) بسبب مشكلة مؤقتة في منصة Azure DHCP. |
| فشل العثور على واجهة DHCP الأساسية | لم يتم العثور على واجهة DHCP الأساسية. | تحقق من تشخيصات التمهيد للتأكد من تسمية eth0 واجهة الشبكة الأساسية ولم تتم إعادة تسميتها. |
| مهلة الاتصال للاستعلام عن IMDS | قد تنتهي مهلة الاتصالات ب IMDS بسبب مشكلة مؤقتة في النظام الأساسي أو NSG أو تكوين جدار حماية نظام التشغيل. | حذف الجهاز الظاهري وإعادة إنشائه. إذا استمرت المشكلة، فتحقق من أن NSG أو جدار حماية نظام التشغيل لا يمنع الوصول إلى IMDS. |
| قراءة مهلة الاستعلام عن IMDS | قد تنتهي مهلة الاتصالات ب IMDS بسبب مشكلة مؤقتة في النظام الأساسي أو تكوين جدار حماية نظام التشغيل. | حذف الجهاز الظاهري وإعادة إنشائه. إذا استمرت المشكلة، فتحقق من صحة جدار حماية نظام التشغيل لا يمنع الوصول إلى IMDS. |
| تحليل بيانات التعريف غير متوقع ovf-env.xml | بيانات تعريف الجهاز الظاهري التي تم تكوينها بشكل غير جيد في ovf-env.xml. |
أرسل المشكلة إلى متتبع السحابة. |
| خطأ في انتظار إيقاف تشغيل المضيف | فشل أثناء معالجة إيقاف تشغيل المضيف. | أرسل المشكلة إلى متتبع السحابة. |
| لم يتم العثور على عامل وكيل Azure |
azure-proxy-agent الثنائي مفقود. |
تأكد من تثبيت عامل وكيل Azure في الصورة. لمزيد من استكشاف الأخطاء وإصلاحها، راجع دليل استكشاف أخطاء MSP وإصلاحها. |
| فشل حالة عامل وكيل Azure | أبلغ وكيل الوكيل عن خطأ في الحالة. | راجع سجلات وكيل الوكيل وقم بتحديثها إذا لزم الأمر. لمزيد من استكشاف الأخطاء وإصلاحها، راجع دليل استكشاف أخطاء MSP وإصلاحها. |
| استثناء غير معالج | حدث خطأ غير متوقع داخل cloud-init. | أرسل المشكلة إلى متتبع السحابة. |
للحصول على تعليمات حول تمكين تشخيصات التمهيد والتحقق منها، راجع تشخيصات التمهيد.
إذا استمرت أي من هذه المشكلات في المحاولات اللاحقة للتزويد، فهذا يرجع إلى تكوين خاطئ في الصورة. إذا كان هناك سبب للاعتقاد بأن هناك مشكلة في cloud-init، فبلغها إلى cloud-init GitHub issue tracker.
استكشاف أخطاء الفشل الأخرى التي لم يتم الإبلاغ عنها بواسطة cloud-init وإصلاحها
اعتمادا على الفشل، ضع في اعتبارك هذه الخطوات.
الخطوة 1: اختبار التوزيع دون customData
يمكن أن يقبل customData Cloud-init الذي يتم تمريره إليه، عند إنشاء الجهاز الظاهري. أولا، يجب التأكد من أن هذا التكوين لا يسبب أي مشكلات في عمليات النشر. بعض المشاكل الشائعة يمكن أن تشمل:
- YAML مشوه
- السكربتات داخل customData تفشل أو تتعطل
- تجاوز ما يعتمد عليه Cloud Init (على سبيل المثال، إعداد القرص أو الشبكات).
- تحتوي البيانات على أحرف غير مدعومة أو مشاكل ترميز. حاول تجهيز الجهاز الافتراضي دون تمرير أي إعداد. إذا فشل الجهاز الظاهري في التوفير، فاتبع خطوات استكشاف الأخطاء وإصلاحها الموصى بها. إذا لم يتم تطبيق التكوين، يرجى الرجوع إلى الخطوة 4.
الخطوة 2: مراجعة متطلبات الصورة
السبب الرئيسي لفشل توفير الأجهزة الظاهرية هو أن صورة نظام التشغيل لا تفي بالمتطلبات الأساسية للتشغيل على Azure. تأكد من إعداد صورك بشكل صحيح قبل محاولة توفيرها في Azure.
توضح المقالات التالية الخطوات اللازمة لإعداد توزيعات Linux المختلفة المدعومة في Azure:
- التوزيعات المستندة إلى CentOS
- دبيان لينكس
- حاوية Flatcar Linux
- أوراكل لينكس
- ريد هات إنتربرايز لينكس
- SLES &openSUSE
- Ubuntu
- أخرى: التوزيعات غير المعتمدة
بالنسبة لصور Azure cloud-init المدعومة، تحتوي توزيعات Linux بالفعل على جميع الحزم والتكوينات المطلوبة لتوفير الصورة بشكل صحيح في Azure. إذا وجدت أن جهازك الظاهري يفشل في الإنشاء من صورتك المنسقة، فجرب صورة Azure Marketplace مدعومة تم تكوينها بالفعل لـ cloud-init، مع customData الاختيارية.
customData إذا كان يعمل بشكل صحيح مع صورة Azure Marketplace، فمن المحتمل أن تكون هناك مشكلة في الصورة المنسقة.
الخطوة 3: جمع سجلات الجهاز الظاهري ومراجعتها
عندما يفشل الجهاز الظاهري في التوفير، يعرض Azure حالة "الإنشاء"، لمدة 20 دقيقة، ثم أعد تشغيل الجهاز الظاهري، وانتظر 20 دقيقة أخرى قبل وضع علامة أخيرا على توزيع الجهاز الظاهري على أنه فشل، قبل وضع علامة عليه أخيرا بخطأ OSProvisioningTimedOut .
أثناء تشغيل الجهاز الظاهري، تحتاج إلى السجلات من الجهاز الظاهري لفهم سبب فشل التوفير. لفهم سبب فشل توفير الجهاز الظاهري، لا توقف الجهاز الظاهري. حافظ على تشغيل الجهاز الظاهري. تحتاج إلى الاحتفاظ بالجهاز الظاهري الفاشل في حالة تشغيل لتجميع السجلات. لتجميع السجلات، استخدم أحد الأساليب التالية:
قم بتمكين تشخيصات التمهيد قبل إنشاء الجهاز الظاهري ثم قم بعرضها أثناء التمهيد.
قم بتشغيل AZ VM Repair لإرفاق قرص نظام التشغيل وتحميله (lvm، بدون lvm)، مما سيسمح لك بتجميع هذه السجلات وفحصها:
/rescue/var/log/waagent* /rescue/var/log/syslog* /rescue/var/log/rsyslog* /rescue/var/log/messages* /rescue/var/log/kern* /rescue/var/log/dmesg* /rescue/var/log/boot* /rescue/ /var/log/cloud-init.log /rescue//var/log/cloud-init-output.log
ملاحظة
بدلا من ذلك، يمكنك إنشاء آلة افتراضية لإنقاذ يدويا باستخدام بوابة Azure. لمزيد من المعلومات، راجع استكشاف أخطاء جهاز افتراضي لينكس عن طريق ربط قرص نظام التشغيل بجهاز افتراضي للاسترداد باستخدام بوابة Azure. لبدء استكشاف الأخطاء الأولية، ابدأ بالسجلات التسلسلية وسجلات السحابة لفهم مكان حدوث الفشل. ثم استخدم السجلات الأخرى للغوص بشكل أعمق لمساعدتك في تقديم رؤى إضافية.
- /var/log/cloud-init.log
- /var/log/cloud-init-output.log
- سجلات التسلسل/التمهيد
في جميع السجلات، ابدأ البحث عن "فشل"، "تحذير"، "تحذير"، "خطأ"، "خطأ"، و"خطأ". ينصح بضبط الإعدادات لتجاهل عمليات البحث الحساسة للحرف.
بدلا من ذلك، استخدم الأوامر cloud‑init collect‑logs لجمع جميع السجلات اللازمة.
أحدث إصدارات Azure السحابية (≥ 18.2) تتضمن أمر collect-logs، والذي:
يجمع السجلات الأساسية: /var/log/cloud-init*.log، بيانات وصفية للمحالة، معلومات النظام.
يجمع كل شيء في أرشيف .tar.gz مسجل زمنيا.
يحفظ الأرشيف محليا (على سبيل المثال، /tmp/cloud-init-logs-timestamp.tar.gz).
تلميح
إذا كنت تحاول حل مشكلة صورة مخصصة، يجب أن تفكر في إضافة مستخدم أثناء الصورة. إذا فشل التوفير في تعيين المستخدم المسؤول، لا يزال بإمكانك تسجيل الدخول إلى نظام التشغيل.
تحليل السجلات
إليك المزيد من التفاصيل حول ما يجب البحث عنه في كل سجل سحابة.
/var/log/cloud-init.log
بشكل افتراضي، جميع أحداث البداية السحابية التي لها أولوية تصحيح أو أعلى، تكتب إلى /var/log/cloud-init.log. يوفر هذا السجل سجلات مفصلة لكل حدث حدث أثناء تهيئة السحابة (cloud-init).
على سبيل المثال:
2019-10-10 04:51:25,321 - util.py[DEBUG]: Failed mount of '/dev/sr0' as 'auto': Unexpected error while running command.
Command: ['mount', '-o', 'ro,sync', '-t', 'auto', u'/dev/sr0', '/run/cloud-init/tmp/tmpLIrklc']
Exit code: 32
Reason: -
Stdout:
Stderr: mount: unknown filesystem type 'udf'
2020-01-31 00:21:53,352 - DataSourceAzure.py[WARNING]: /dev/sr0 was not mountable
عند العثور على خطأ أو تحذير، اقرأ إلى الخلف في سجل cloud-init لفهم ما كان يحاول cloud-init قبل أن يصل إلى الخطأ أو التحذير. في كثير من الحالات، يقوم cloud-init بتشغيل أوامر نظام التشغيل أو تنفيذ خطوات التوفير قبل حدوث الخطأ. يمكن أن تساعد هذه الإجراءات في شرح سبب ظهور الخطأ في السجلات. يوضح المثال التالي أن cloud-init حاول تحميل جهاز قبل أن يواجه المشكلة مباشرة.
2019-10-10 04:51:24,010 - util.py[DEBUG]: Running command ['mount', '-o', 'ro,sync', '-t', 'auto', u'/dev/sr0', '/run/cloud-init/tmp/tmpXXXXX'] with allowed return codes [0] (shell=False, capture=True)
إذا كان لديك حق الوصول إلى "Serial Console"، فيمكنك محاولة إعادة تشغيل الأمر الذي كانت تحاول cloud-init تشغيله.
يمكن أيضاً إعادة تكوين تسجيل الدخول إلى /var/log/cloud-init.log داخل /etc/cloud/cloud.cfg.d/05_logging.cfg. لمزيد من المعلومات حول تسجيل cloud-init، راجع وثائق cloud-init.
/var/log/cloud-init-output.log
يمكنك الحصول على معلومات من stdout وstderr أثناء مراحل cloud-init. تتضمن هذه البيانات عادة معلومات جدول التوجيه ومعلومات الشبكات ومعلومات التحقق من مفتاح مضيف ssh، stdout, ولكل stderr مرحلة من مراحل cloud-init، جنبا إلى جنب مع الطوابع الزمنية. إذا رغبت في ذلك، يمكن إعادة تكوين تسجيل stderr وstdout من /etc/cloud/cloud.cfg.d/05_logging.cfg.
سجلات المسلسل/التمهيد
لدى Cloud-init تبعيات متعددة. يتم توثيق هذه التبعيات في المتطلبات الأساسية المطلوبة للصور على Azure، مثل الشبكات والتخزين والقدرة على تحميل ISO وتركيب القرص المؤقت وتنسيقه. قد تتسبب أي من هذه التبعيات في حدوث أخطاء وتتسبب في فشل cloud-init. على سبيل المثال، إذا لم يتمكن الجهاز الظاهري من الحصول على عقد إيجار DHCP، يفشل cloud-init.
إذا كنت لا تزال غير قادر على عزل سبب فشل cloud-init في التوفير، فأنت بحاجة إلى فهم مراحل cloud-init، ومتى يتم تشغيل الوحدات النمطية. لمزيد من المعلومات، راجع التعمق في cloud-init.
الخطوة 4: التحقيق في سبب عدم تطبيق التكوين
لا يؤدي كل فشل في cloud-init إلى فشل فادح في التوفير. على سبيل المثال، إذا كنت تستخدم runcmd الوحدة النمطية في تكوين cloud-init، فإن رمز الخروج غير الصفري من الأمر يؤدي إلى فشل توفير الجهاز الظاهري. يحدث هذا السلوك لأن الوحدة النمطية تعمل بعد خطوات التوفير الأساسية في المراحل الثلاث الأولى من cloud-init. لاستكشاف سبب عدم تطبيق التكوين وإصلاحها، راجع السجلات في الخطوة 3 والوحدات النمطية ل cloud-init يدويا. على سبيل المثال:
-
runcmd- هل تعمل البرامج النصية بدون أخطاء؟ للتأكد من أنها تعمل كما هو متوقع، قم بتشغيل التكوين يدويا من المحطة الطرفية. - تثبيت الحزم - هل يمتلك الجهاز الظاهري حق الوصول إلى مستودعات الحزم؟
- تحقق من
customDataالتكوين الذي تم توفيره إلى الجهاز الظاهري. يقع هذا الملف في/var/lib/cloud/instances/<unique-instance-identifier>/user-data.txt.
الخطوات التالية
إذا تجاوز cloud-init التكوين، فافحص كل مرحلة cloud-init وتوقيت تنفيذ الوحدة النمطية لتحديد السبب. لمزيد من المعلومات، راجع التعمق في تكوين cloud-init.