تفعيل الشبكة الافتراضية
يتم التفعيل عبر معالج على مركز البيانات: مركز البيانات › الشبكة الافتراضية › تفعيل (Activate). وينفذ المعالج نفس الخطوات الخمس لكل وضع؛ وتعتبر الخطوة 2 هي الخطوة التي يختلف محتواها.
الترخيص
يتطلب التفعيل توفر استحقاق الشبكة الافتراضية (Virtual Network entitlement) في ترخيص Cockpit لديك. إذا لم يكن متوفرًا، أضفه إلى اشتراكك واستورد الترخيص المحدث قبل البدء — انظر الملاحظة في نظرة عامة.
قبل البدء، يجب أن يكون كل مضيف في مركز البيانات متصلاً في Cockpit. يسأل المعالج كل مضيف عما يمكنه دعمه، والمضيف الذي لا يمكن الوصول إليه لا يمكن تضمينه.
الخطوة 1 — الاسم والوضع
أعطِ بيئة التشغيل اسمًا واختر أحد الأوضاع الثلاثة الموضحة في نظرة عامة. لا يمكن تغيير الوضع لاحقًا؛ للتبديل، يجب إلغاء التفعيل ثم التفعيل مجددًا.
الخطوة 2 — متطلبات كل وضع
تشكيل بيئة OVN أصيلة لـ Vapor (Vapor-native)
اختر العقد المركزية (Centrals): المضيفون الذين سيشغلون قواعد بيانات OVN كعنقود RAFT.
- 1، أو 3، أو 5 عقد. يرفض المعالج الأعداد 2 و4. فالعدد الزوجي أسوأ تمامًا من العدد الفردي الذي يسبقه: لا يمكن لعقدتين مركزيتين التفوق في التصويت على بعضهما، لذا فإن فقدان أي منهما يؤدي إلى فقدان العنقود بأكمله.
- التوزيع عبر العناقيد. عندما يحتوي مركز البيانات على ثلاثة عناقيد أو أكثر، يحدد المعالج افتراضيًا عقدة مركزية واحدة لكل عنقود. يمثل العنقود عادةً خزانة خوادم (Rack) أو نطاق فشل (Failure domain)؛ وجود 3 عقد مركزية في خزانة واحدة ينجو من تعطل مضيف واحد ولكنه لا ينجو من انقطاع الخزانة بالكامل.
- قواعد البيانات الحالية. إذا كانت إحدى العقد المركزية المختارة تحتوي بالفعل على قواعد بيانات OVN من تشغيل سابق، فسوف يوضح الفحص المسبق ذلك (انظر أدناه). قد تحتوي تلك الملفات على التكوين المنطقي الكامل لكل ما كانت تخدمه سابقًا. لن يستبدلها المعالج دون تأكيد صريح منك.
ينضم كل مضيف آخر في مركز البيانات كـ هيكل (Chassis). تعمل بيئة العقدة المركزية الواحدة دون تكرار (Redundancy)؛ استخدمها في بيئات المختبرات فقط.
الانضمام إلى بيئة OVN خارجية موجودة
أدخل عنواني قاعدتي البيانات northbound وsouthbound، على سبيل المثال tcp:10.0.0.1:6641 وtcp:10.0.0.1:6642.
إذا كانت قواعد البيانات الخارجية في عنقود متماثل، اذكر جميع الأعضاء مفصولة بفواصل: tcp:10.0.0.1:6641,tcp:10.0.0.2:6641,tcp:10.0.0.3:6641. يتحدث عملاء OVN فقط مع قائد العنقود الحالي، وبالتالي فإن استخدام عنوان واحد يتوقف عن العمل بمجرد انتقال القيادة إلى عضو آخر. استخدم ssl: بدلاً من tcp: إذا كانت قواعد البيانات تتطلب تشفير TLS.
تعتبر تعيينات الجسور (Bridge mappings) اختيارية وتُطبق على كل مضيف؛ اتركها فارغة ما لم تكن بيئة التشغيل الخارجية تتطلب شبكة موفر (Provider network).
الانضمام إلى عنقود Kube-OVN موجود
لا يلزم كتابة أي شيء هنا. يعرض المعالج ما اكتشفه على كل مضيف:
| الحقل | المعنى |
|---|---|
| Kube-OVN | ما إذا كان kube-ovn يعمل على ذلك المضيف. يتم اكتشافه عبر Kubernetes API عندما يمتلك المضيف ملف kubeconfig، أو من خلال برنامج kube-ovn الخفي على المضيف عندما لا يمتلكه (عقد العمل لا تمتلكه عادةً). |
| Node | اسم عقدة Kubernetes. |
| --enable-external-vpc | خيار تحكم kube-ovn-controller. انظر التحذير الخطير أدناه. |
| Northbound (المكتشف) | عنوان قاعدة البيانات الذي أبلغ عنه kube-ovn. |
تُملأ عناوين بيئة التشغيل من أول مضيف يبلغ عنها وتُعرض للقراءة فقط. حدد خيار Override the discovered addresses فقط إذا كنت متأكدًا أكثر من الـ CNI. إذا أبلغت المضيفات عن عناوين مختلفة، فهذا يعني أنها تنتمي إلى عناقيد kube-ovn مختلفة، ويمكن لمركز البيانات الواحد الانضمام إلى عنقود واحد فقط.
استبعاد المضيفات التي ليست عقد kube-ovn
لا يمكن للمضيف الذي ليس عقدة kube-ovn الانضمام في هذا الوضع. فإذا انضم، فسيتم تسجيله في قاعدة بيانات southbound الخاصة بـ kube-ovn كهيكل لا يعرفه kube-ovn — ويقوم متحكم kube-ovn بإزالة الهياكل غير المعروفة في كل مرة يعاد تشغيله فيها. ينطبق الأمر نفسه على العقد التي لا تحتوي حزمة Vapor الخاصة بها على أدوات عميل OVN، لأنها لن تتمكن أبدًا من قراءة قاعدة البيانات التي انضمت إليها.
يتم تسجيل هذه المضيفات كـ excluded (مستبعدة) مع ذكر السبب، ولا يتم تطبيق أي شيء عليها. لضم أحدها لاحقًا، أصلح السبب (ثبت kube-ovn، أو حزمتي ovn-common وopenvswitch-switch) ثم استخدم Sync.
راية --enable-external-vpc
يتعامل متحكم kube-ovn مع قاعدة بيانات northbound الخاصة به على أنها ملك حصري له. ويعتبر أي كائن لا يمكن ربطه بمورد Kubernetes بمثابة تسريب يجب تنظيفه: تُحذف منافذ البدّالات المنطقية بعد مؤقت 360 ثانية، وتُحذف البدّالات والموجهات المنطقية دفعة واحدة عند إعادة تشغيل المتحكم. الخيار الذي يستثني الكائنات الخارجية هو وضع --enable-external-vpc=true على بيئة kube-ovn-controller، وتكون قيمته الافتراضية false.
بدون تفعيلها، فإن كل شبكة تنشئها من خلال Cockpit تظل موجودة فقط حتى إعادة تشغيل المتحكم التالية ثم تختفي فجأة — وهو ما قد يحدث بعد أسابيع، ولن يربط أحد بين الحدثين. يبلغ الفحص المسبق عن حالة هذه الراية؛ ولن يتابع المعالج دون إقرار صريح عند عدم تفعيلها. يُنصح بضبطها أولاً.
الخطوة 3 — المضيفون والتغليف
صف واحد لكل مضيف في مركز البيانات، مع عنوان IP للتغليف (Encapsulation IP) الذي سيستخدمه المضيف لأنفاق Geneve. يملأ المعالج العنوان استنادًا إلى ما يقترحه المضيف نفسه؛ قم بتعديل الصف إذا كان لدى المضيف واجهة أفضل لحركة مرور الأنفاق (مثل شبكة تخزين مخصصة أو شبكة تغطية overlay).
قاعدتان يفرضهما المعالج:
- عنوان واحد لكل مضيف. اشتراك مضيفين في نفس عنوان IP للتغليف ينتج عنه نسيج لا تعمل فيه الأنفاق إطلاقًا.
- عدم نسخ عنوان مضيف إلى مضيف آخر. كل صف يمثل العنوان المستقل الخاص بذلك المضيف.
في وضع vapor-native، تصبح عناوين IP للتغليف الخاصة بالعقد المركزية هي نفسها عناوين قواعد البيانات التي يتصل بها كل مضيف.
الخطوة 4 — الفحص المسبق (Preflight)
يتحقق المعالج من مركز البيانات بأكمله قبل إجراء أي تغييرات. يُعرض كل فحص لكل مضيف مع تفاصيله؛ والنتيجة fail تمنع التفعيل، بينما تتطلب warn إقرارًا بالموافقة.
| الفحص | ما يتحقق منه |
|---|---|
| Central quorum | 1، أو 3، أو 5 عقد مركزية (vapor-native). |
| Encapsulation path | قدرة كل مضيف على الوصول إلى عنوان IP للتغليف الخاص بكل مضيف آخر. هذا فحص واتصال فعلي بين المضيفين وليس مجرد مقارنة للشبكات الفرعية. |
| Geneve MTU headroom | نفس الفحص باستخدام حزمة بحجم إطار نظام ضيف منقول عبر نفق بحجم 1500 بايت. وظهور warn هنا يعني أن المسار يعمل ولكن يجب على الأنظمة الضيفة على هذا النسيج استخدام MTU أصغر (1442 مع شبكة أساسية بحجم 1500 بايت) أو زيادة حجم MTU للشبكة الأساسية إلى 1558. وعدم حل ذلك يؤدي إلى إنشاء أجهزة افتراضية تتصل بالشبكة لكنها تفشل في تمرير الحزم كاملة الحجم. |
| Existing OVN databases | امتلاك العقدة المركزية المقترحة لملفات قواعد بيانات سابقة. وإذا كانت تنتمي إلى عنقود نشط ينجح الفحص؛ وإذا كانت مستقلة يُصدر تحذيرًا ويظهر تأكيد replace databases — خذ نسخة احتياطية أولاً. |
| Kube-OVN membership | إمكانية مشاركة كل مضيف؛ وتُسرد المضيفات المستبعدة مع ذكر السبب. |
| Kube-OVN external VPC | التحقق من راية المتحكم كما هو موضح أعلاه. |
| Per-host checks | الفحوصات الفردية لكل مضيف مشارك من قبل Vapor: توفر الحزم، إمكانية الوصول إلى قواعد البيانات، صلاحية عنوان IP للتغليف، وقدرة العقدة المركزية المنضمة على الوصول إلى عضو العنقود الذي ستنضم إليه. |
يصبح التفعيل متاحًا عند عدم وجود أي إخفاق وبعد تأكيد جميع التحذيرات.
الخطوة 5 — التطبيق والتحقق
يعرض المعالج تقدم كل مضيف تباعًا. في وضع vapor-native، تتم العملية تسلسليًا حسب التصميم — تبدأ أول عقدة مركزية بالإقلاع، ثم تنضم العقد الأخرى واحدة تلو الأخرى، ثم تنضم الهياكل (chassis) بالتوازي — لذا تستغرق العملية بضع عشرات من الثواني وليس ثانية واحدة.
يتم الإبلاغ عن كل مضيف على مستويين: applied (قبل Vapor التكوين) وregistered (ظهر المضيف فعليًا في قاعدة بيانات southbound كهيكل). يمكن أن يصل المضيف إلى مرحلة دون الأخرى؛ ويوضح المعالج ذلك بدقة.
عند الانتهاء:
- Active — تم ضم جميع المضيفين بنجاح. ينقلك زر Finish إلى بيئة التشغيل.
- Partial أو Error — تعذر ضم بعض المضيفين. تُسرد الأخطاء لكل مضيف متأثر. يؤدي خيار Retry failed hosts إلى إعادة تطبيق الإعدادات على جميع الأعضاء ودفع قائمة الأعضاء مجددًا؛ بينما يترك خيار Close بيئة التشغيل كما هي، ويعرض تبويب الشبكة الافتراضية نفس الحالة مع نفس خيار إعادة المحاولة.
السبب الأكثر شيوعًا للنتيجة الجزئية هو تعذر الوصول إلى مضيف وقت التطبيق. أصلح السبب ثم أعد المحاولة — لا يلزم التراجع عن أي شيء مسبقًا.
بعد التفعيل
يُظهر كل مضيف الآن معلومات الهيكل الخاص به تحت المضيف › تكوين › الشبكات › الشبكة الافتراضية، ويعرض تبويب مركز البيانات مخزون النسيج. ومن هنا، يتم توضيح العمليات اليومية في صفحة تشغيل الشبكة الافتراضية.