حتى الآن كان كل شيء في هذه السلسلة يحدث على عقدة واحدة. وهذا كافٍ تماماً حتى اليوم الذي تشتري فيه سيرفراً ثانياً — وتكتشف أن إدارته من لوحة منفصلة يعني نسخ كل شيء مرتين، وأن نقل جهاز بينهما يعني إطفاءه وتصديره واستيراده.
الكلاستر يحلّ هذا: لوحة واحدة، صلاحيات واحدة، مخزّنات معرّفة مرّة واحدة، وترحيل بضغطة. هذه المقالة تبنيه أمامك من الصفر — ومعها ثلاثة أخطاء وقعنا فيها فعلاً أثناء بنائه.
كل لقطة في هذه السلسلة من بروكسموكس حقيقي يعمل. نسخة Proxmox VE 9.2 كاملة بأجهزة وحاويات ومخزّنات ومهامّ نسخ فعلية، شغّلناها معزولة لهذا الغرض حتى لا يظهر اسم زبون واحد، ودخلنا لوحتها عبر نفق مشفّر لا عبر الإنترنت. وما تراه في كل صورة هو ما ستراه أنت حرفياً على شاشتك.
قبل: عقدة وحيدة
لاحظ أمرين هنا: Join Information مُطفأ (لا يوجد كلاستر بعد لتصدّر معلوماته)، وCluster Name فارغ. وهذا هو الوضع الافتراضي لأي تنصيب جديد.
ما الذي يشتركه الكلاستر فعلياً؟
كلمة «كلاستر» توحي بأن العقد تصير جهازاً واحداً. ليس صحيحاً. ما يُشارَك بالضبط:
| يُشارَك | لا يُشارَك |
|---|---|
| تعريفات الأجهزة والحاويات | أقراص الأجهزة (تبقى محليّة ما لم يكن التخزين مشتركاً) |
| تعريفات المخزّنات | محتوى المخزّن المحلّي |
| المستخدمون والأدوار والصلاحيات | ذاكرة ومعالج كل عقدة |
| قواعد الجدار الناري ومجموعاته | إعدادات الشبكة الفيزيائية لكل عقدة |
| مهامّ النسخ الاحتياطي | النسخ نفسها إن كانت على تخزين محلّي |
| التجمّعات (Pools) والملاحظات | حزم النظام وإصدار النواة |
كل هذا يعيش في /etc/pve — وهو ليس مجلّداً عادياً بل نظام ملفّات موزّع (pmxcfs) تُزامنه corosync بين العقد. أي تعديل على أي عقدة يظهر على البقية خلال أجزاء من الثانية. وهذا يفسّر سلوكاً سنراه بعد قليل: حين يفقد الكلاستر نصابه يصير /etc/pve للقراءة فقط على كل العقد.
الخطوة ١: إنشاء الكلاستر على العقدة الأولى
| الخانة | التوصية | لماذا |
|---|---|---|
| Cluster Name | أحرف لاتينية وأرقام وشرطات فقط | يدخل في إعدادات corosync، ولا يمكن تغييره لاحقاً إلا بهدم الكلاستر |
| Cluster Network (Link 0) | الشبكة الخاصة إن وُجدت | مسار نبضات corosync — يريد زمناً ثابتاً لا عرض نطاق |
| Link 1 (إضافي) | أضفه إن كان لديك شبكة ثانية | مسار احتياطي للنبضات — يمنع فقد النصاب عند عطل سويتش |
شبكة corosync تريد زمن استجابة لا سرعة. رابط 1G مخصّص أفضل من 10G مشترك مع حركة النسخ الاحتياطي. السبب بسيط: النبضات صغيرة جداً لكنها يجب أن تصل في الوقت — وحين تغرق نسخة احتياطية الرابط، تتأخّر النبضة فيظنّ الكلاستر أن العقدة ماتت.
القاعدة العملية: لا تمرّر حركة النسخ الاحتياطي والترحيل على نفس شبكة corosync إن استطعت.
الخطوة ٢: تصدير معلومات الانضمام
هذا النصّ ليس كلمة مرور — بل تغليف لثلاث معلومات: عنوان العقدة المضيفة، وبصمة شهادتها، واسم الكلاستر. تنسخه ثم تلصقه في العقدة الثانية، فتتأكّد هي من أنها تتحدّث مع الخادم الصحيح لا مع منتحل.
الخطوة ٣: الانضمام من العقدة الثانية
⚠️ العقدة المنضمّة يجب أن تكون فارغة. الانضمام يستبدل محتوى /etc/pve عندها بمحتوى الكلاستر — أي أن تعريفات أجهزتها وحاوياتها ومخزّناتها ومستخدميها تختفي. الأقراص تبقى على التخزين، لكن التعريفات تُمحى وتحتاج إعادة بناء يدوي.
الترتيب الصحيح: ابنِ الكلاستر قبل أن تضع أي شيء على العقدة الجديدة. وإن كانت تحوي أجهزة فعلاً: انسخها احتياطياً، انضمّ، ثم استرجعها.
ما رأيناه فعلاً أثناء الانضمام
عمليّتنا نجحت لكنها انتهت برسالة خطأ:
| السطر | المعنى |
|---|---|
| copy corosync auth key | مفتاح التوثيق انتقل — بداية سليمة |
| waiting for quorum...OK | العقدة صارت جزءاً من النصاب |
| generated new node certificate | شهادة جديدة موقّعة من الكلاستر |
| Job for pveproxy.service failed… | فشلت إعادة تشغيل الواجهة |
السبب كان ذاكرة غير كافية على العقدة الثانية — وسنعود إليه بعد قليل لأنه تسبّب بما هو أسوأ. العلاج كان سطراً واحداً: systemctl restart pveproxy pvedaemon pvestatd. الانضمام نفسه كان قد نجح — الفشل كان في إعادة تشغيل الخدمة فقط، لذا لا تهدم شيئاً قبل أن تتحقّق.
بعد: عقدتان في لوحة واحدة
⭐ النصاب (Quorum) — المفهوم الذي يوقع الجميع
الكلاستر يحتاج أغلبية الأصوات ليسمح بالكتابة. القاعدة: (N/2)+1.
| عدد العقد | النصاب | تتحمّل فقد | الحكم |
|---|---|---|---|
| ١ | ١ | لا شيء | ليس كلاستراً |
| ٢ | ٢ | لا شيء | ⚠️ أي عقدة تسقط ⇒ الاثنتان تتجمّدان |
| ٣ | ٢ | عقدة واحدة | ✅ الحدّ الأدنى العملي |
| ٤ | ٣ | واحدة | لا يضيف تحمّلاً على الثلاثة |
| ٥ | ٣ | اثنتان | ✅ للإنتاج الجادّ |
كلاستر من عقدتين هو أسوأ الخيارات من ناحية التوفّر. عقدة واحدة تسقط ⇒ العقدة الباقية تفقد النصاب ⇒ /etc/pve يصير للقراءة فقط ⇒ لا تشغيل ولا إطفاء ولا تعديل. الأجهزة التي تعمل تستمرّ، لكنك لا تستطيع إدارتها.
إن كنت تملك جهازين فقط فأضف شاهداً (QDevice) — جهاز صغير جداً (حتى حاوية أو Raspberry Pi) يعطي صوتاً ثالثاً بلا أن يشغّل أي ضيف. هذا هو الحلّ الرسمي وليس ترقيعاً.
ماذا يحدث فعلاً عند فقد النصاب؟ شاهدناه
عقدتنا الثانية بُنيت بذاكرة ضيّقة عمداً. وحين بدأنا أول ترحيل، استهلك تشغيل الجهاز الهدف ما تبقّى من ذاكرتها، فقتل النظام corosync:
| ما ظهر | أين |
|---|---|
| corosync.service: A process of this unit has been killed by the OOM killer | سجلّ العقدة الثانية |
| [pve-lab2] cluster not ready - no quorum? | سجلّ مهمّة الترحيل |
| ERROR: unable to open file '/etc/pve/nodes/…/220.conf.tmp.318232' - Permission denied | سجلّ المهمّة — على العقدة الأولى |
السطر الثالث هو الدرس: «Permission denied» داخل /etc/pve لا تعني مشكلة صلاحيات إطلاقاً — تعني أن الكلاستر فقد نصابه فصار نظام الملفّات للقراءة فقط. وقد يضيع ساعة كامل من يبحث عن chmod بدل أن ينظر إلى حالة corosync.
وقايتان طبّقناهما: رفع ذاكرة العقدة حتى لا تختنق أصلاً، وتحصين الخدمة الحسّاسة بملحق systemd يضع لها OOMScoreAdjust=-900 وMemoryMin — فيصير corosync آخر ما يفكّر النظام في قتله. وهذا إجراء يستحقّ التطبيق على كل عقدة إنتاج، لا على المختبرات فقط.
الإجراءات الجماعية — مكسب فوري للكلاستر
حقل التأخير هو الأهمّ هنا. تشغيل عشرين جهازاً في لحظة واحدة يخلق عاصفة قراءة تُغرق التخزين وتجعل الإقلاع أبطأ للجميع. تأخير ٣٠–٦٠ ثانية بين كل جهاز يجعل عودة الخدمة أسرع رغم أنها تبدو أبطأ.
أخطاء شائعة وحلولها
| العرَض | السبب الحقيقي | الحلّ |
|---|---|---|
| Permission denied في /etc/pve | فقد النصاب | أعِد العقدة الناقصة أو افحص corosync |
| انضمام يفشل بمهلة | الجدار الناري يحجب 5405/udp أو 8006 | افتحهما بين العقد قبل المحاولة |
| انضمام يفشل بخطأ اسم | العقدتان بنفس اسم المضيف | أسماء فريدة + تعريف متبادل في /etc/hosts |
| العقدة تظهر ثم تختفي | تذبذب الشبكة أو غرقها | شبكة مخصّصة للنبضات، أو رابط ثانٍ |
| الواجهة لا تعمل بعد الانضمام | pveproxy لم يُعَد تشغيله | systemctl restart pveproxy pvedaemon |
| عقدة بعلامة سؤال حمراء | pvestatd متوقّفة أو الوقت منحرف | شغّل الخدمة، وتأكّد من NTP على الجميع |
⚠️ الوقت غير المتزامن يكسر الكلاستر بصمت. انحراف بضع ثوانٍ بين العقد يربك الشهادات وسجلّات المهامّ ويُنتج أعطالاً لا تُفسَّر. تأكّد أن chrony يعمل على كل عقدة قبل بناء الكلاستر.
متى لا تبني كلاستراً؟
| الحالة | الأفضل |
|---|---|
| سيرفر واحد ولا نيّة لثانٍ | ابقَ منفرداً — الكلاستر يضيف تعقيداً بلا مقابل |
| سيرفران في موقعين بعيدين | منفردان + نسخ متبادل؛ corosync يكره زمن الإنترنت |
| سيرفران فقط بلا شاهد | أضف QDevice أولاً |
| أعتدة مختلفة جذرياً (Intel وAMD) | الكلاستر يعمل، لكن لا ترحيل حيّ بينهما — وهذا قيد حقيقي واجهناه على أسطولنا |
أسئلة شائعة
هل أحتاج تخزيناً مشتركاً للكلاستر؟
لا للكلاستر نفسه، ونعم للاستفادة الكاملة. بلا تخزين مشترك يبقى الترحيل ممكناً لكنه ينسخ القرص كاملاً، والتوفّر العالي يصير غير عملي.
هل تحتاج العقد نفس العتاد؟
لا، لكن نفس عائلة المعالج شرط للترحيل الحيّ. اختلاف الذاكرة والأقراص مقبول تماماً.
كيف أُخرج عقدة من الكلاستر؟
أطفئها نهائياً ثم pvecm delnode من عقدة باقية. ولا تُعِد وصلها بعد ذلك أبداً قبل إعادة تنصيبها من الصفر — العقدة المحذوفة تحتفظ بمفاتيح قديمة تُفسد الكلاستر إن عادت.
هل يعمل الكلاستر عبر الإنترنت؟
تقنياً نعم، عملياً لا. corosync يريد زمناً أقلّ من بضعة ملّي ثانية وثباتاً؛ ووصلة إنترنت متذبذبة تعني فقد نصاب متكرّر. إن اضطررت فاستعمل نفقاً مخصّصاً واقبل المخاطرة.
كم عقدة أقصى؟
عشرات العقد مدعومة رسمياً. الحدّ العملي يأتي من شبكة النبضات لا من العدد.
ماذا بعد؟
الكلاستر قائم — والمكسب الأول الذي ستستعمله كل أسبوع هو نقل جهاز يعمل من عقدة إلى أخرى بلا إطفاء. وهذا موضوع المقالة التالية، بسجلّ ترحيل حقيقي وأرقامه.
سلسلة «بروكسموكس من الداخل» — بلقطات حقيقية من الواجهة.
الأساسيات:
١. الواجهة ·
٢. أول جهاز ·
٣. الحاويات ·
٤. الصور والقوالب ·
٥. الصلاحيات
التخزين:
٦. أنواع التخزين ·
٧. إضافة قرص وتوسيعه ·
٨. ZFS ·
٩. نقل قرص ·
١٠. امتلاء التخزين
الشبكة والأمان:
١١. تبويب الشبكة ·
١٢. الجدار الناري ·
١٣. SDN ·
١٤. تأمين اللوحة ·
١٥. السجلّات
التشغيل اليومي:
١٦. ضبط الموارد ·
١٧. مهمّة النسخ ·
١٨. الاسترجاع ·
١٩. اللقطات ·
٢٠. قراءة الرسوم
التوسّع:
٢١. الكلاستر ·
٢٢. الترحيل الحيّ ·
٢٣. تمرير الأجهزة ·
٢٤. التحديث والترقية ·
٢٥. التوفّر العالي