عناقيد Vapor-native
في بيئة نشر Vapor-native، يدير Vapor قواعد بيانات OVN بنفسه. يكفي خادم مركزي (central) واحد لتشكيل بيئة كاملة؛ بينما يضمن العنقود المكون من ثلاثة خوادم أو أكثر استمرار العمل عند فقدان أحد المضيفين.
تغطي هذه الصفحة تشكيل هذا العنقود وإضافة المضيفين إليه. تتم تغطية عملية التنشيط نفسها في تنشيط الشبكة الافتراضية.
كم عدد الخوادم المركزية (Centrals) المطلوبة
يتم نسخ قواعد بيانات OVN بشكل متماثل باستخدام RAFT، والذي يتطلب موافقة أغلبية الأعضاء قبل قبول أي عملية كتابة.
| الخوادم المركزية | التحمل | ملاحظات |
|---|---|---|
| 1 | لا يتحمل أي عطل | يعمل بكامل وظائفه. فقدان المضيف يوقف بيئة التشغيل |
| 2 | لا يتحمل أي عطل | أسوأ من وجود خادم واحد. تعطل أي من المضيفين يفقد العنقود الأغلبية |
| 3 | فشل مضيف واحد | أصغر عنقود عملي ومفيد |
| 5 | فشل مضيفين اثنين | لبيئات التشغيل الأكبر |
استخدم دائمًا عددًا فرديًا. إضافة خادم مركزي ثانٍ إلى بيئة بخادم واحد يجعل التوافر أسوأ وليس أفضل، حتى تضيف خادمًا ثالثًا.
المضيفون الذين يقومون بتشغيل أحمال العمل فقط لا يحتاجون إلى أن يكونوا خوادم مركزية. بيئة تشغيل تضم ثلاثة خوادم مركزية وعشرين هيكلاً (chassis) أمر شائع وطبيعي.
تشكيل العنقود
يقوم خادم مركزي واحد بالضبط ببدء العنقود؛ وينضم كل خادم مركزي آخر إلى الخادم الذي بدأه.
الخادم المركزي الأول
في معالج التنشيط، اختر Vapor-native، والدور Central، ثم Bootstrap a new cluster. قم بالتطبيق (Apply).
بعد ذلك، تبلغ بطاقة حالة OVN بأن المضيف يحتفظ بقواعد البيانات، وتعرضه صفحة العنقود كعضو وحيد.
إضافة خادم مركزي
يقوم كل خادم مركزي إضافي بالمصادقة مع خادم حالي باستخدام رمز انضمام (join token). على الخادم المركزي الحالي، استخدم Mint join token في بطاقة حالة OVN. يُعرض الرمز مرة واحدة فقط — ويتم تخزين خلاصة التشفير (digest) فقط، لذلك لا يمكن استعادته لاحقًا. بشكل افتراضي، يكون الرمز صالحًا لمدة ساعة واحدة واستخدام واحد فقط.
على المضيف المراد إضافته، شغّل المعالج باختيار Vapor-native، والدور Central، وJoin an existing cluster، ثم:
- أدخل عنوان الخادم المركزي الحالي (يُفترض المنفذ 7770 إذا تم حذفه)،
- الصق رمز الانضمام،
- اضغط على Exchange token with central.
يتصل Vapor بالخادم المركزي، وعند النجاح يملأ عناوين قواعد البيانات وعنوان العنقود المطلوب الانضمام إليه تلقائيًا. لست بحاجة إلى نسخها يدويًا.
ثم تابع عبر الفحص المسبق والتطبيق (Apply).
لماذا يتم تبادل الرمز على المضيف وليس في متصفحك
يتم تقديم متصفحك بواسطة أحد مضيفي Vapor بينما يكون الخادم المركزي مضيفًا آخر، وعادةً ما يكون بشهادة موقعة ذاتيًا (self-signed). ينفذ المضيف المنضم عملية التبادل بنفسه، ولهذا السبب يتم توفير خيار Skip TLS verification for this exchange — فالانضمام لأول مرة يحتاجه عادةً. قم بإيقاف تشغيله بمجرد أن يقدم الخادم المركزي شهادة يثق بها المضيف المنضم.
إضافة هيكل (Chassis)
يحتاج الهيكل فقط إلى عناوين قاعدة البيانات، ولا يحتاج إلى عضوية RAFT. يمكنك تقديمها مباشرة، أو استخدام رمز انضمام بنفس الطريقة لملئها تلقائيًا نيابةً عنك.
استبدال قواعد البيانات الموجودة
يؤدي تشكيل عنقود أو الانضمام إليه إلى استبدال ملفات قاعدة بيانات OVN الخاصة بهذا المضيف. إذا كان المضيف يحتوي عليها بالفعل، يرفض Vapor العملية حتى تضع علامة في المربع Allow this host's OVN databases to be replaced.
تعامل مع هذا الأمر بجدية تامة على مضيف كان يعمل بنمط منفرد (standalone): قاعدة بياناته الشمالية (northbound) تحتوي على كامل التكوين المنطقي — كل بدّال، وموجه، وقائمة تحكم في الوصول (ACL)، وموازن أحمال. ينقل Vapor الملفات الموجودة جانبًا بدلاً من حذفها، مع لاحقة طابع زمني في /var/lib/ovn، لكن احرص على أخذ نسخة احتياطية منها قبل المتابعة.
المضيف الذي هو بالفعل عضو سليم في العنقود لا يحتاج إلى هذا الإجراء، وإعادة التطبيق لا تؤثر على قواعد بياناته.
كيفية معالجة عناوين العنقود
بمجرد وجود العنقود، يخزن Vapor عنوان كل عضو بدلاً من عنوان واحد:
tcp:10.0.0.1:6641,tcp:10.0.0.2:6641,tcp:10.0.0.3:6641هذا الإجراء مقصود ومدروس. يتحدث عملاء OVSDB فقط إلى القائد الحالي (leader)، وبالتالي فإن العنوان المخزن الفردي يتوقف عن العمل في اللحظة التي تنتقل فيها القيادة إلى عضو آخر — وهو الحدث ذاته الذي أُنشئ العنقود للنجاة منه. ومع إدراج كل عضو، يجد العميل القائد بنفسه.
تؤدي إعادة تطبيق التنشيط على أحد الأعضاء إلى تحديث القائمة، وتلك هي الطريقة التي يظهر بها المضيف المضاف حديثًا في تكوين المضيفين الآخرين.
فحص صحة العنقود
تعرض لوحة معلومات العنقود كل قاعدة بيانات بشكل منفصل، مع دور الخادم المحلي، والدورة الحالية (term)، وقائمة العضوية الكاملة. يُظهر العنقود السليم المكون من ثلاث عقد ثلاثة أعضاء لكلا قاعدتي البيانات وقائدًا واحدًا.
يُعد انتقال القيادة بين الأعضاء أمرًا طبيعيًا ومألوفًا. يحدث ذلك عند إعادة تشغيل المضيف وبعد أي انقطاع مؤقت في الاتصال، وتظل بيئة التشغيل قابلة للاستخدام طوال الوقت.
أمران لا يُعتبران أعطالاً:
- صفر منافذ أنفاق على مضيف ليس لديه منافذ منطقية. يبني OVN الأنفاق عند الطلب فقط.
- عضو يبلغ عن الحالة
follower. عضو واحد فقط يكون القائد (leader) في أي وقت معين.
المنافذ التي يجب السماح بها بين الخوادم المركزية
| المنفذ | الغرض |
|---|---|
| 6641 | قاعدة بيانات Northbound، العملاء |
| 6642 | قاعدة بيانات Southbound، العملاء (تتصل الهياكل هنا) |
| 6643 | تكرار عنقود Northbound |
| 6644 | تكرار عنقود Southbound |
| 6081/UDP | أنفاق Geneve بين الهياكل (chassis) |
تحتاج الخوادم المركزية إلى جميع هذه المنافذ مفتوحة فيما بينها. بينما يحتاج الهيكل إلى المنفذ 6642 للخوادم المركزية وGeneve للهياكل الأخرى.
النجاة بعد إعادة التشغيل
يكتب Vapor معلمات العنقود حيث تقرأها وحدات خدمة OVN ويدع systemd يمتلك عمليات قاعدة البيانات، وبالتالي يعود الخادم المركزي للعمل بعد إعادة التشغيل دون أي تدخل يدوي. إذا تعذر على Vapor تمكين تلك الوحدات، فإنه يسجل ذلك في السجل: قواعد البيانات تعمل، لكنها لن تعود للعمل تلقائيًا بمفردها بعد إعادة التشغيل.