مشاركة عبر

استكشاف أخطاء توفير الأجهزة الظاهرية باستخدام cloud-init وإصلاحها

  • مقالة

تنبيه

تشير هذه المقالة إلى CentOS، وهو توزيع Linux هو حالة نهاية العمر الافتراضي (EOL). يرجى مراعاة استخدامك والتخطيط وفقا لذلك. لمزيد من المعلومات، راجع إرشادات نهاية العمر الافتراضي CentOS.

ينطبق على: ✔️ أجهزة Linux الظاهرية ✔️ مجموعات مقياس مرنة

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

بعض الأمثلة، للمشكلات المتعلقة بالتوفير:

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

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

الخطوة 1: اختبار التوزيع دون customData

يمكن لـ Cloud-init أن تقبل customData، التي يتم تمريرها إليها، عند إنشاء الجهاز الظاهري. يجب عليك أولاً التأكد من أن هذا لا يسبب أي مشكلات في عمليات التوزيع. حاول توفير الجهاز الظاهري دون المرور في أي تكوين. إذا فشل الجهاز الظاهري في التوفير، فتابع الخطوات أدناه، إذا وجدت أن التكوين الذي تقوم بتمريره لا يتم تطبيقه، فانتقل إلى الخطوة 4.

الخطوة 2: مراجعة متطلبات الصورة

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

توضح المقالات التالية الخطوات اللازمة لإعداد توزيعات Linux المختلفة المدعومة في Azure:

بالنسبة لصور Azure cloud-init المدعومة، تحتوي توزيعات Linux بالفعل على جميع الحزم والتكوينات المطلوبة لتوفير الصورة بشكل صحيح في Azure. إذا وجدت أن جهازك الظاهري يفشل في الإنشاء من صورتك المنسقة، فجرب صورة Azure Marketplace مدعومة تم تكوينها بالفعل لـ cloud-init، مع customData الاختيارية. إذا كان customData يعمل بشكل صحيح مع صورة Azure Marketplace، فمن المحتمل أن تكون هناك مشكلة في صورتك المنسقة.

الخطوة 3: جمع سجلات الجهاز الظاهري ومراجعتها

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

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

sudo cat /rescue/var/log/cloud-init*
sudo cat /rescue/var/log/waagent*
sudo cat /rescue/var/log/syslog*
sudo cat /rescue/var/log/rsyslog*
sudo cat /rescue/var/log/messages*
sudo cat /rescue/var/log/kern*
sudo cat /rescue/var/log/dmesg*
sudo cat /rescue/var/log/boot*

إشعار

بدلا من ذلك، يمكنك إنشاء جهاز ظاهري للإنقاذ يدويا باستخدام مدخل Microsoft Azure. لمزيد من المعلومات، راجع استكشاف أخطاء جهاز Linux الظاهري وإصلاحها عن طريق إرفاق قرص نظام التشغيل بجهاز ظاهري للاسترداد باستخدام مدخل Microsoft Azure.

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

  • /var/log/cloud-init.log
  • /var/log/cloud-init-output.log
  • سجلات المسلسل/التمهيد

في جميع السجلات، ابدأ البحث عن "Failed"، و"WARNING"، و"WARN"، و"err"، و"error"، و"ERROR". يوصى بإعداد التكوين لتجاهل عمليات البحث الحساسة لحالة الأحرف.

تلميح

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

تحليل السجلات

فيما يلي مزيد من التفاصيل حول ما يجب البحث عنه في كل سجل cloud-init.

/var/log/cloud-init.log

بشكل افتراضي، تتم كتابة جميع أحداث cloud-init ذات أولوية تصحيح الأخطاء أو أعلى إلى /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، ستؤدي التعليمة البرمجية للخروج غير الصفرية من الأمر الذي يتم تشغيله إلى فشل توفير الجهاز الظاهري. هذا لأنه يعمل بعد وظيفة التوفير الأساسية التي تحدث في أول 3 مراحل من cloud-init. لاستكشاف سبب عدم تطبيق التكوين وإصلاحه، راجع السجلات في الخطوة 3 والوحدات النمطية لـ cloud-init يدوياً. على سبيل المثال:

  • runcmd - هل تعمل البرامج النصية بدون أخطاء؟ قم بتشغيل التكوين يدوياً من المحطة الطرفية لضمان تشغيلها كما هو متوقع.
  • تثبيت الحزم - هل يمتلك الجهاز الظاهري حق الوصول إلى مستودعات الحزم؟
  • يجب عليك أيضاً التحقق من تكوين البيانات customData الذي تم توفيره إلى الجهاز الظاهري، والموجود في /var/lib/cloud/instances/<unique-instance-identifier>/user-data.txt.

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

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