استكشاف أخطاء الشبكة الافتراضية وإصلاحها
يحتوي OVN على نمط فشل شائع يقع فيه الجميع، لذا يجدر معرفته قبل أي شيء آخر.
القاعدة التي توجد ولا تفعل شيئاً
تقوم قاعدة بيانات OVN الشمالية (northbound) بعمليات تحقق قليلة للغاية. فهي تقبل قاعدة لا يمكن لمستوى البيانات (data plane) تجميع تعبيرها. وعندما يحدث ذلك:
- يتم إنشاء الكائن،
- تبلغ واجهة برمجة التطبيقات (API) بالنجاح،
- تسردها الصفحة على أنها سليمة،
- ولا يكون لها أي تأثير على الإطلاق.
لا يوجد شيء في Vapor يمكنه إخبارك بذلك، لأنه فيما يتعلق بقاعدة البيانات، فإن الكائن يبدو في حالة جيدة. الدليل الوحيد موجود على المضيف، في سجل ovn-controller:
grep -iE "error parsing|Syntax error" /var/log/ovn/ovn-controller.logاجعل هذا فحصك الأول كلما وُجد كائن ولم يؤد ما ينص عليه. هناك سببان شائعان لحدوث ذلك:
- علامة
-في اسم مجموعة المنافذ أو مجموعة العناوين، والتي يقرأها OVN كعملية طرح - قيمة خيار مشوهة، مثل قائمة خوادم DNS بصيغة خاطئة
إشارة ثانية لنفس الفئة من المشاكل: تظهر القاعدة في ovn-sbctl lflow-list ولكن ليس لها إدخال مطابق في ovs-ofctl dump-flows br-int. حيث تم إنشاء القاعدة المنطقية ورفضها البدّال.
الأعراض وأين تبحث
الجهاز الافتراضي لا يحصل على عنوان DHCP
- هل يطابق عنوان MAC الذي سجله OVN للمنفذ عنوان MAC الذي يرسل منه النظام الضيف؟ يجب أن يتطابقا؛ يستجيب مجيب DHCP في OVN بناءً على عنوان MAC المصدر.
- هل تم تمكين DHCP في تلك الشبكة الفرعية، وهل خيارات DHCP للشبكة الفرعية مرفقة بالمنفذ؟
- تحقق من
ovn-controller.logكما هو موضح أعلاه — خيار DHCP المشوه يوقف خدمة DHCP لكل منفذ على البدّال، وليس لمنفذ واحد فقط. - هل طلب النظام الضيف عنوانًا بالفعل؟ الواجهة التي يتم توصيلها أثناء التشغيل (hot-plugged) لا يتم تكوينها تلقائيًا.
الجهاز يصل إلى بوابته والأجهزة في نفس الشبكة الفرعية، لكن التوجيه لا يعمل
يعود هذا دائمًا تقريبًا إلى توجيه النظام الضيف وليس إلى OVN. عادةً ما يحتوي النظام الضيف المزود بواجهة ثانية على مسار افتراضي بمقياس (metric) أقل هناك، وبالتالي تخرج حركة المرور الموجهة من المسار الخاطئ. تحقق من جدول توجيه النظام الضيف قبل الاشتباه في الشبكة.
لا تستطيع المضيفات الموجودة على نفس البدّال المنطقي الوصول إلى بعضها البعض
- هل كلا المنفذين مربوطان (bound)؟ يظهر المنفذ كمربوط في صفحة Logical Switch Ports بمجرد أن يطالب به
ovn-controller. - هل عناوين أنفاق الهيكلين (chassis) تقع في شبكة فرعية يشتركان فيها؟ الهيكل الذي يحتوي على عنوان نفق لا يمكن الوصول إليه يسجل بنجاح ولا يشكل نفقًا أبدًا.
- عدم وجود منافذ أنفاق (صفر منافذ) على مضيف ليس لديه منافذ منطقية أمر طبيعي. يبني OVN الأنفاق عند الطلب فقط.
فشل إرفاق جهاز ببدّال منطقي عند بدء تشغيله
يحتاج المضيف إلى ovs-vsctl، والذي يستخدمه Vapor لوضع الواجهة على جسر التكامل. بدونه، يفشل الجهاز في بدء التشغيل مع ظهور رسالة حول إضافة منفذ إلى br-int. تبلغ بطاقة حالة OVN عما إذا كان هذا العميل موجودًا أم لا.
موازن الأحمال لا يُرجع شيئاً
- أرفقه بـ البدّال المنطقي، وليس بموجه موزع بدون منفذ بوابة. يترجم الموازن المرفق بالموجه حركة المرور الواردة وليس الردود.
- امنح الـ VIP عنوانًا خارج الشبكة الفرعية للعميل. الـ VIP الموجود داخل الشبكة الفرعية لا يحتوي على مجيب ARP، وبالتالي يتعطل الاتصال قبل إرسال الحزمة.
قائمة التحكم في الوصول (ACL) لا تحظر ما ينبغي حظره
- تحقق من قاعدة التسمية لمجموعات المنافذ ومجموعات العناوين، ثم راجع
ovn-controller.log. - تأكد من تسجيل الطرف البعيد فعليًا. تتطابق قائمة ACL التي لا تحتوي على قيود على المصدر مع كل مصدر، وهو أوسع مما هو مقصود ويبدو وكأن القاعدة "لا تعمل" بينما هي في الواقع تنطبق على كل شيء.
- خيار
allowغير محتفظ بالحالة. لأي شيء يعتمد على الجلسات استخدمallow-related، وإلا فسيتم إسقاط الردود.
اختفاء الكائنات بعد فترة
في بيئة نشر kube-ovn المشتركة، يحدث هذا بسبب عملية جمع المهملات (garbage collection) الخاصة بـ kube-ovn. تحقق من:
kubectl -n kube-system logs deploy/kube-ovn-controller | grep gc.goوما إذا كانت وحدة التحكم قد أعيد تشغيلها. راجع قسم الوضع 3 في تنشيط الشبكة الافتراضية للشروط الثلاثة التي تمنع ذلك.
اختفاء موجه في بيئة kube-ovn
إذا تم تعيين --enable-external-vpc=true، فإن كل موجه من موجهات Vapor موجود أيضًا كمورد Vpc في Kubernetes، وحذف هذا المورد يحذف الموجه في OVN. تحقق مما إذا قامت أي أداة بتشذيبه أو حذفه.
فحوصات خاصة بالعناقيد
يرفض أحد الأعضاء الاتصالات على منفذ العميل الخاص به
متوقع على التابع (follower). يتحدث عملاء OVSDB فقط إلى القائد (leader)، لذلك يتم رفض الاستعلام الموجه إلى تابع واحد على الرغم من أن العضو سليم. يوجه Vapor العنقود من خلال جميع أعضائه لهذا السبب. للاستعلام عن تابع مباشرة للتشخيص، استخدم --no-leader-only.
القيادة تستمر في الانتقال
طبيعي بعد إعادة التشغيل أو فقدان الاتصال لفترة وجيزة. تظل بيئة النشر قابلة للاستخدام. استقرار القيادة على عضو مختلف عن العضو الذي قمت بتهيئته أولاً ليس عطلاً.
قواعد بيانات الخادم المركزي لا تبدأ
تحقق من الترتيب: يتطلب ovn-northd تشغيل خدمتي قاعدة البيانات، وبدء تشغيلهما معًا قد يؤدي إلى تعارض في التزامن. ابدأ تشغيل ovn-ovsdb-server-nb و ovn-ovsdb-server-sb أولاً، وتأكد من أنهما نشطان، ثم ابدأ ovn-northd.
بعد إعادة التشغيل لا يحتوي الخادم المركزي على قواعد بيانات
تعيش معلمات العنقود في تهيئة وحدات خدمة OVN ويجب تمكين تلك الوحدات. يقوم Vapor بتمكينها أثناء التنشيط ويسجل تحذيرًا إذا لم يتمكن من ذلك.
أوامر مفيدة
قم بتشغيل هذه الأوامر على المضيف. على عقدة kube-ovn، قد تتواجد أدوات ovn-nbctl و ovs-vsctl داخل حاوية pod بدلاً من وجودها مباشرة على المضيف.
# ما يعتقد هذا المضيف أن دوره هو
ovn-nbctl --db=<nb-address> show
# هل المنفذ مربوط وإلى أي هيكل
ovn-sbctl --db=<sb-address> find Port_Binding logical_port=<port>
# عضوية العنقود لقاعدة بيانات واحدة
ovs-appctl -t /var/run/ovn/ovnnb_db.ctl cluster/status OVN_Northbound
# القواعد المنطقية التي تم إنشاؤها لبدّال معين
ovn-sbctl lflow-list <switch>
# ما قام البدّال بتثبيته فعليًا
ovs-ofctl dump-flows br-int
# السجل الذي يوضح الإخفاقات الصامتة
grep -iE "error parsing|Syntax error" /var/log/ovn/ovn-controller.logعند الإبلاغ عن مشكلة
اذكر الوضع الذي تم تنشيط هذا المضيف فيه، والمصدر الذي زود عناوين قاعدة البيانات (توضح ذلك بطاقة الحالة)، وما إذا كان الكائن موجودًا في قاعدة البيانات الشمالية، وما إذا كان هناك تدفق مطابق على البدّال، وأي أسطر error parsing من ovn-controller.log. تفصل هذه الإجابات الخمس بين الخطأ في التكوين والعطل الفعلي أسرع من أي شيء آخر.