تنشيط الشبكة الافتراضية
حتى يتم تنشيط OVN، لا تعرض صفحات Network > OVN أي بيانات: لا يعرف Vapor أين تقع قواعد بيانات OVN أو ما هو الدور الذي يلعبه هذا المضيف. يقوم التنشيط بتسوية الأمرين ويسري مفعوله دون الحاجة إلى إعادة تشغيل Vapor.
افتح Network > OVN وابدأ معالج التنشيط. على المضيف الذي تم تنشيطه بالفعل، يتوفر نفس المعالج كخيار Reconfigure.
أين تُحفظ الإعدادات
يتم تخزين بيانات التنشيط في قاعدة بيانات Vapor الخاصة، وبالتالي تظل محفوظة بعد إعادة التشغيل ويمكن تعديلها في أي وقت. يمكن لثلاثة مصادر توفير عناوين قاعدة البيانات، وأول مصدر يحتوي على قيمة يتم اعتماده:
- متغيرات البيئة (Environment variables) —
VAPOR_OVN_NB_DBوVAPOR_OVN_SB_DB - قاعدة بيانات Vapor — ما يكتبه المعالج
vapor.conf—ovn_nb_dbوovn_sb_db، وهو مفيد للتهيئة المسبقة للمضيف قبل أن يفتح أي شخص واجهة المستخدم
إذا لم يتم تعيين أي منها، تعود أدوات OVN تلقائيًا إلى مأخذ التوصيل المحلي (local socket)، وهو أمر صحيح فقط على المضيف الذي يحتفظ بقواعد البيانات بنفسه.
تعرض بطاقة الحالة المصدر قيد الاستخدام حاليًا، فإذا بدا أن التغيير لا يسري مفعوله، تحقق من هناك أولاً — فالمتغير البيئي المعين على الخدمة سيتجاوز أي شيء يخزنه المعالج.
المعالج، خطوة بخطوة
1. الوضع (Mode)
اختر نمط نشر بيئة التشغيل. تم توضيح الأوضاع الثلاثة أدناه؛ الفروق جوهرية، لذا اقرأ تفاصيل الوضع الذي تنوي استخدامه قبل المتابعة.
2. الاكتشاف (Discovery)
يفحص Vapor المضيف ويعرض ما وجده: برامج OVN وOVS المثبتة وإصداراتها، والخدمات قيد التشغيل، ومعرف system-id الحالي إذا كان موجودًا، وعناوين الأنفاق المرشحة مع الشبكة الفرعية التي ينتمي إليها كل منها، وما إذا كان هذا المضيف عقدة Kubernetes وما إذا كان kube-ovn موجودًا (إذا كان ملف kubeconfig متاحًا).
تقتصر مرحلة الاكتشاف على القراءة فقط. لا يتم تغيير أي شيء حتى تصل إلى خطوة التطبيق (apply).
قد يبدو أحد المدخلات متناقضًا على عقدة Kubernetes: قد يتم الإبلاغ عن ovn-controller بأنه غير مثبت بينما هو قيد التشغيل في نفس الوقت. هذا متوقع، لأن kube-ovn يشغله داخل حاوية (pod) بدلاً من تشغيله كخدمة مباشرة على المضيف.
3. العناوين والنظراء (Addresses and peers)
بالنسبة لبيئات OVN الخارجية أو kube-ovn، يتم هنا إدخال عناوين northbound وsouthbound. أما بالنسبة لبيئة Vapor-native، فهنا تحدد ما إذا كان المضيف central (يدير قواعد البيانات) أو chassis (مفرط أجهزة يتصل بها)، وبالنسبة للمركزي (central)، ما إذا كان يبدأ عنقودًا جديدًا أو ينضم إلى عنقود حالي.
4. الهيكل المحلي (Local chassis)
معرف system-id، ونوع تغليف النفق وعنوانه، وتعيينات الجسور الاختيارية (bridge mappings).
اختر عنوان النفق من المرشحين الذين تقدمهم مرحلة الاكتشاف، واختر عنوانًا على شبكة فرعية يشترك فيها كل مضيف آخر في بيئة التشغيل. فالهيكل الذي يملك عنوانًا لا يمكن لنظرائه الوصول إليه يسجل بنجاح ولكنه لا يشكل نفقًا أبدًا، مما يبدو وكأنه بيئة تعمل بينما تُسقط حركة المرور بين المضيفين بصمت.
تعيينات الجسور مطلوبة فقط إذا كنت تنوي منح الموجه المنطقي مسارًا إلى شبكة فيزيائية — راجع التوجيه والاتصال الخارجي.
5. الفحص المسبق (Preflight)
يشغل Vapor قائمة من الفحوصات ويعرض كل فحص مع سببه. تؤدي حالة الفشل (fail) إلى منع التطبيق؛ بينما يتطلب التحذير (warning) منك الإقرار به صراحةً.
| الفحص | ما يعنيه |
|---|---|
ovs_installed | ovs-vsctl موجود. بدونه، يفشل ربط الجهاز الافتراضي ببدّال منطقي عند بدء تشغيل الجهاز |
ovn_tools_installed | أدوات ovn-nbctl وovn-sbctl موجودة مع إصداراتها |
nb_reachable / sb_reachable | قواعد البيانات تستجيب. يتم تخطيه لـ Vapor-native central الذي ينشئ قواعد بياناته الخاصة |
central_capable | يحتوي المضيف على وحدات systemd التي يحتاجها OVN central. أداة ovn-ctl وحدها لا تكفي — فهي تأتي مع حزمة المضيف أيضًا |
cluster_remote_reachable | بالنسبة لخادم central ينضم إلى عنقود، العضو المراد الاتصال به يمكن الوصول إليه |
encap_ip_valid | عنوان النفق موجود على هذا المضيف |
system_id_valid | معرف النظام غير معين أو يطابق بالفعل ما نعتزم استخدامه |
no_stale_chassis | عدم وجود تسجيل هيكل قديم لهذا المضيف تحت معرف مختلف |
kube_ovn_external_vpc | تمت تهيئة kube-ovn لعدم حذف الكائنات التي لا يتعرف عليها |
kube_ovn_node_match | هذا المضيف هو عقدة Kubernetes |
6. المراجعة والتطبيق (Review and apply)
التطبيق عملية متماثلة التأثير (idempotent): إعادة تشغيله بنفس التهيئة يبلغ بأنه لم تكن هناك حاجة لتغيير أي شيء. إذا فشلت خطوة في منتصف الطريق، يقوم Vapor بالتراجع عما قام بتغييره ويخبرك بما تمت استعادته، بحيث لا يترك التنشيط الفاشل المضيف في حالة أسوأ مما كان عليه.
الوضع 1: Vapor-native
يدير Vapor قواعد بيانات OVN بنفسه. هذا هو النمط الموصى به لبيئة لا تشغل OVN مسبقًا، لأنه لا توجد أنظمة أخرى تمتلك قواعد البيانات ولن يزيل أي شيء ما تقوم بإنشائه.
يكون المضيف إما central أو chassis:
- يقوم central بتشغيل
ovn-northdوقواعد بيانات northbound وsouthbound، وهو أيضًا هيكل (chassis). - يشغل chassis برنامج
ovn-controllerفقط ويتصل بالخوادم المركزية (centrals).
خادم مركزي واحد يُعد بيئة تشغيل كاملة وتعمل دون تكرارية (redundancy). لتحقيق التوافر العالي (high availability)، استخدم ثلاثة أو أكثر. وجود خادمين أسوأ من وجود خادم واحد: فلا يمكنهما تشكيل أغلبية كافية للأغلبية (quorum)، وبالتالي فإن فقدان أي من المضيفين يوقف بيئة التشغيل بالكامل.
تتم تغطية تشكيل العنقود ورموز الانضمام وإضافة المضيفين في عناقيد Vapor-native.
الوضع 2: بيئة OVN خارجية حالية (Existing external OVN)
نظام آخر يدير ovn-central. ما عليك سوى تزويد عناوين northbound وsouthbound الخاصة به؛ ينضم Vapor كعميل ويهيئ هذا المضيف كهيكل (chassis). لن يحاول Vapor إعادة تهيئة ذلك الخادم المركزي.
هذا هو الوضع الأبسط. إذا كانت العناوين تستجيب وعنوان النفق صحيح، فلا يوجد شيء آخر يحتاج إلى قرار.
الوضع 3: عنقود kube-ovn حالي (Existing kube-ovn cluster)
يتشارك Vapor قواعد بيانات OVN التابعة لـ Kubernetes CNI. هذا الخيار يعمل، لكن kube-ovn يفترض أنه يمتلك تلك القواعد بالكامل، لذا توجد شروط ملزمة. يتحقق Vapor من الشروط الثلاثة أثناء الفحص المسبق.
يجب إخبار kube-ovn بعدم جمع الكائنات الخارجية
يقوم kube-ovn بمطابقة OVN مع موارد Kubernetes ويحذف أي شيء لا يستطيع نسبته إليها. بالإعدادات الافتراضية، تؤدي إعادة تشغيل واحدة لـ kube-ovn-controller إلى حذف كل بدّال وموجه منطقي أنشأه Vapor، كما يؤدي مسحه الدوري إلى حذف منافذ البدّالات المنطقية خلال دورتين.
اضبط --enable-external-vpc=true في نشر kube-ovn-controller. باستخدام هذا الخيار، يتم استبعاد الكائنات التي لا تحمل علامة kube-ovn الخاصة تمامًا من عملية جمع المهملات (garbage collection).
يقرأ Vapor هذا الخيار أثناء الاكتشاف ويحذر بشكل بارز إذا لم يتم تعيينه. لا تتجاهل هذا التحذير في بيئة عمل تهمك.
تمكين هذا الخيار له عواقب
مع تعيين --enable-external-vpc=true، ينشئ kube-ovn موردًا مخصصًا Vpc على مستوى العنقود لكل موجه منطقي لا يمتلكه، بما في ذلك موجهات Vapor. حذف هذا المورد المخصص يؤدي إلى حذف الموجه في OVN.
احمِ هذه الموارد قبل الاعتماد على هذا النمط:
- استبعد موارد
Vpcمن أي عمليات تشذيب لـ GitOps، و - فكر في سياسة قبول (admission policy) ترفض حذف موارد
Vpcالتي تحمل التسميةovn.kubernetes.io/vpc_external=trueلأي طرف باستثناء حساب خدمة kube-ovn الخاص.
إن المورد الذي لا يعلن عنه أحد هو بالضبط ما تزيله أدوات التنظيف الآلية.
يجب أن يكون كل مفرط أجهزة في Vapor عقدة Kubernetes أيضًا
يزيل kube-ovn أي تسجيل هيكل (chassis) لا يتوافق مع عقدة Kubernetes، والراية المذكورة أعلاه لا تغير ذلك. المفرط الذي ليس عقدة يفقد هيكله عند إعادة تشغيل وحدة التحكم التالية، وتفقد معه أنفاقه.
يتعامل الفحص المسبق مع هذا الأمر كفشل حاسم (hard failure) وليس مجرد تحذير.
ملاحظة بخصوص الإصدارات
تعتمد الاستثناءات المذكورة أعلاه على قيام kube-ovn بوضع علامات على كائناته الخاصة، وهو ما يفعله بدءًا من الإصدار v1.15.0 فصاعدًا. في العناقيد الأقدم، أو تلك التي تمت ترقيتها دون تشغيل عملية ترحيل العلامات، قد يؤثر تمكين الراية أيضًا على الترحيل المباشر في KubeVirt، والذي يستخدم نفس عامل التصفية للعثور على منفذ الجهاز الافتراضي. تأكد من أن منافذك الحالية تحمل علامة vendor=kube-ovn قبل تمكينها.
إلغاء التنشيط (Deactivating)
يؤدي خيار Deactivate إلى إيقاف ovn-controller الخاص بهذا المضيف، ومسح مؤشرات قواعد البيانات الخاصة به ووضع علامة عليه كغير نشط. هذا الإجراء لا يحذف البدّالات المنطقية أو الموجهات أو قوائم التحكم في الوصول (ACLs) أو أي شيء آخر من قواعد بيانات OVN، لأنها في بيئة النشر المشتركة تخص الجميع.
على المضيف الذي تستخدم أحمال عمله OVN حاليًا، يؤدي إلغاء التنشيط إلى مقاطعة اتصال شبكتها. تعامل مع هذا الإجراء كعملية صيانة دورية.