ما الذي يسبب فشل DNS المتقطع في التطبيقات المستضافة ذاتيًا؟
تحدث فشل DNS المتقطع عندما يتغير مسار محلل التطبيق، أو ينتهي وقت الانتظار، أو يتعرض للتحميل الزائد، أو يعيد إجابات مخزنة مؤقتًا غير متسقة.
في بيئة الاستضافة الذاتية، قد يمر الاستعلام الفاشل عبر وقت تشغيل التطبيق، وDNS الخاص بالحاوية، ومحلل المضيف، والموجه، وPi-hole أو AdGuard Home، وسياسة VPN، وخادم علوي عام أو موثوق. لا يمكن لاختبار المتصفح من المضيف إثبات أن التطبيق يرى نفس المسار، لذا يجب أن تلتقط عملية التشخيص الاسم الفاشل داخل الحاوية أو الخدمة المتأثرة وتقارنه مع استعلام ناجح في نفس اللحظة.
التقاط الاستعلام الفاشل داخل بيئة التطبيق المتأثرة
سجل اسم المضيف الدقيق، ونص الخطأ، والطابع الزمني، والحاوية أو العملية، وما إذا كان الفشل يؤثر على الأسماء الداخلية، أو الأسماء العامة، أو كليهما. نفذ استعلامات متكررة من داخل البيئة المتأثرة بدلاً من الاعتماد فقط على اختبارات مستوى المضيف.
وثقت مشكلة في Kubernetes حالات فشل متقطعة حيث انتهى وقت الاستعلام الأول لـ DNS بينما نجحت الاستعلامات اللاحقة. يوضح هذا النمط سبب عدم قدرة استعلام ناجح واحد بعد الحادث على تفسير فشل المحلل العابر.
سجل مدة الاستعلام، والخادم الذي أعاد الإجابة، ورمز الاستجابة، ونتيجة إعادة المحاولة. إذا فشل اسم واحد فقط، فافحص تلك المنطقة أو السلطة؛ إذا فشلت كل الأسماء معًا، ركز على الوصلة المحلية، أو المحلل العلوي، أو مسار الشبكة.
مقارنة DNS الخاص بالمضيف مع DNS الخاص بالحاوية أو الخدمة
افحص تكوين المحلل داخل الحاوية، أو الجهاز الافتراضي، أو صندوق الرمل الخاص بالتطبيق وقارنه مع خوادم DNS النشطة على المضيف. قد توفر بيئات تشغيل الحاويات واصفًا مدمجًا أو تنسخ ملف resolv.conf المُولد بدلاً من كشف محلل المضيف مباشرة.
أظهرت حالة من مجتمع HashiCorp أن DNS يعمل على المضيف لكنه لا يعمل في الحاوية لأن مستمع systemd-resolved الخاص بالمضيف لم يكن متاحًا من الجسر، مما استلزم مستمع محلل إضافي على عنوان يمكن للحاوية الاستعلام منه.
استعلم عن خادم الأسماء المُكوَّن مباشرة من كلا البيئتين. إذا نجح المضيف بينما انتهى وقت انتظار الحاوية مقابل وصلة حلقة العودة أو واصف غير متاح، أصلح مسار المحلل المرئي للجسر بدلاً من إعادة تشغيل التطبيق مرارًا وتكرارًا.
فصل فشل المناطق الداخلية عن فشل DNS العام
اختبر اسمًا عامًا مستقرًا واحدًا واسم خدمة داخلية مطلوبًا واحدًا خلال نفس نافذة الفشل. يشير الفشل الداخلي فقط إلى DNS المنقسم، أو مجالات البحث، أو السجلات الموثوقة المحلية، أو التوجيه الشرطي؛ بينما يشير فشل كلاهما إلى مسار الاستعلام التكراري.
تصف تقارير منتدى Docker DNS الذي يجب أن يحل باستمرار لكنه فشل بدون نمط واضح أثناء عمليات البناء. لذلك يمكن أن يفشل DNS الخاص بالحاوية حتى عندما تظل شبكة التطبيق نفسها متاحة.
إذا عملت الأسماء العامة لكن فشل اسم تطبيق داخلي، استعلم مباشرة عن الخادم الموثوق المحلي واستخدم النطاق الكامل بدلاً من اسم قصير مع لاحقة البحث. إذا فشل كلاهما، تجاوز الفلتر المحلي مؤقتًا باستخدام محلل معروف واحد لتحديد ما إذا كانت المشكلة في الأعلى أو داخل الشبكة المنزلية.
قياس مهلات المحلل، والتحميل، وسلوك UDP مقابل TCP
نفذ استعلامات متكررة محددة الوقت مباشرة ضد كل محلل في السلسلة وقارن بين UDP وTCP. تتبع فقدان الحزم، ووقت الاستجابة، وSERVFAIL، والمهلة، والاقتطاع، وما إذا كانت الإخفاقات تتزامن مع وظائف النسخ الاحتياطي، أو تحديثات التصفية، أو استخدام وحدة المعالجة المركزية العالي.
يوصي دليل استكشاف أخطاء DNS المتقطع بالتقاط الإخفاقات عند حدوثها وفصل عدم استقرار المحلل عن فقدان الشبكة بدلاً من تغيير عدة خوادم DNS دفعة واحدة.
إذا انتهت مهلة محلل واحد بينما أجاب آخر فورًا، حافظ على مسار التطبيق ثابتًا واستبدل أو أصلح المحلل الفاشل. إذا فشلت كل المحللات في نفس الوقت من الحاوية ولكن ليس من المضيف، عد إلى سلوك الجسر، وجدار الحماية، وconntrack، ومساحات الأسماء.
التحقق من تجديدات DHCP، وسياسات VPN، وتغييرات المحلل مع مرور الوقت
قارن تكوين DNS قبل وبعد تجديد DHCP، أو تغييرات اتصال VPN، أو نوم المضيف، أو إعادة تشغيل الموجه، أو إعادة إنشاء الحاوية. غالبًا ما تتبع الإخفاقات المتقطعة حدث دورة حياة يستبدل المحلل أو مجال البحث بصمت.
تتبع مستخدم Docker مشكلة عشوائية ظاهرة إلى تجديد عقد DHCP وأخرى إلى التفاعل بين Docker وTailscale. هذا النوع من الأدلة الزمنية أقوى من افتراض أن المحلل يفشل عشوائيًا.
احفظ قائمة المحللات، والمسارات، ومجالات البحث، وحالة VPN قبل وبعد الحدث. أصلح المصدر الذي يعيد كتابتها—DHCP، NetworkManager، systemd-resolved، عميل VPN، أو بيئة تشغيل الحاوية—بدلاً من ترميز محلل عام لا يمكنه الإجابة على الأسماء الداخلية.
التحقق من الإصلاح خلال نافذة الفشل الأصلية
نفذ استعلامًا مجدولًا من داخل بيئة التطبيق لفترة أطول من الفاصل الزمني الذي ينتج عادةً الإخفاقات. سجل المحلل المستخدم، والكمون، ورمز الاستجابة، ونتيجة على مستوى التطبيق بدلاً من تسجيل استعلامات سطر الأوامر الناجحة فقط.
يغطي دليل ZimaSpace لـ حل مشكلة عدم اتساق حل أسماء NAS المشكلة المجاورة على جانب العميل؛ يجب أن يثبت هذا الاختبار الموجه للتطبيق أيضًا أن الحاوية ووقت التشغيل يستخدمان المحلل المقصود باستمرار.
يتم إصلاح المشكلة فقط عندما تكتمل عملية التطبيق الأصلية عبر إعادة تشغيل الموجه، وتجديدات العقد، وإعادة إنشاء الحاوية، وتغييرات حالة VPN التي كانت تسبب الفشل سابقًا. إذا كانت عمليات إعادة التشغيل تعيد ضبط المؤقت فقط، استمر في جمع الحالة عند لحظة الفشل بدلاً من قبول إعادة التشغيل كإصلاح.
المنتجات الموصى بها
الدعم والنصائح
المزيد للقراءة
لماذا تؤدي استعادة وحدة تخزين Docker إلى إعادة إنشاء محتويات الملفات مع فقدان السمات الموسّعة؟
تشخيص لاستعادة وحدة تخزين يغطي جرد السمات الموسَّعة (xattr)، وخيارات tar وRsync، ومساحات الأسماء، ودعم الوجهة، والامتيازات، والتسميات، والبيانات الوصفية للتطبيق، والاختبارات.
لماذا يحتفظ الحاوي قيد التشغيل بحد الذاكرة القديم بعد تغيير ملف Compose؟
تشخيص لحدود الذاكرة يغطي مجموعات cgroups النشطة، وإعادة التشغيل مقابل إعادة الإنشاء، وحقول Compose، والحدود الصارمة والمرنة، والنطاقات الأصلية، وذاكرة التبديل، وأكوام الذاكرة في...
لماذا يؤدي إعادة تشغيل وكيل عكسي إلى إبطال كل جلسة في تطبيق مستضاف ذاتيًا واحد؟
تشخيص لفقدان الجلسة يشمل نطاق إعادة التشغيل، وملكية ملفات تعريف الارتباط، وتدوير الأسرار، والجلسات المدعومة بالتخزين المؤقت، والتوجيه الثابت، وبوابات المصادقة، والاسترداد.
