أنشئ مجموعة SLES 15 HA مدعومة باستخدام Fencing First

بالنسبة لنظام SLES 15، قم بتسجيل إضافة SUSE Linux Enterprise High Availability، ثم استخدمها crm cluster initلتهيئة crm cluster joinالعقد. قبل وضع الخدمات على المجموعة، تحقق من وجود شبكة احتياطية، وحماية العقد (STONITH)، ​​والنصاب القانوني.

يتبع هذا الإجراء وثائق SLE HA 15 SP7 المحدثة في أكتوبر 2026. تأكد من حزمة الخدمة المثبتة لديك وبنية وحدة المعالجة المركزية؛ قد تختلف معرفات التسجيل وتفاصيل الدعم.

1. تجهيز العقد والشبكة

أوامر التحقق المسبق للطرفية لأسماء العقد، والبحث عن المضيف، ومزامنة الوقت باستخدام Chrony، وواجهات الشبكة
تحقق من تسمية المضيف، وحل الأسماء، ومزامنة الوقت، وحالة الواجهة على كل عقدة قبل تشكيل المجموعة.

استخدم عقدتين على الأقل على نفس بنية المعالج المدعومة، وعناوين IP أساسية ثابتة، وأسماء فريدة قابلة للحل على كل عقدة، وساعات متزامنة باستخدام مصدر وقت خارجي. يتطلب نظام SUSE مسارين اتصال TCP/IP احتياطيين لكل عقدة؛ ويجب أن تتطابق أسماء الواجهات بين العقد.

hostname -f
getent hosts node1 node2
chronyc tracking
ip -br addr

قم بإجراء عمليات التحقق على كلا العقدتين وتأكد من صحة الواجهات والأسماء المحددة قبل بدء التشغيل.

2. قم بتسجيل وتثبيت ملحق التوافر العالي

أوامر الطرفية لتسجيل SUSE Linux Enterprise High Availability 15.7 وتثبيت نمط ha_sles
قم بتسجيل ملحق SLE HA على كل عقدة وقم بتثبيت نمط إدارة المجموعة الخاص به.

SLE HA هو امتداد مسجل بشكل منفصل؛ لا يتضمن SLES وحده نمط التجميع. بالنسبة لعُقد SLES 15 SP7 x86_64 المسجلة، فعّل الامتداد وثبّت النمط على كل عُقدة.

SUSEConnect -p sle-ha/15.7/x86_64 -r ADDITIONAL_REGCODE
zypper install -t pattern ha_sles

استبدل ADDITIONAL_REGCODEهذا برمز اشتراكك. مُعرّف المنتج خاص بمعالجات x86_64؛ استخدم مُعرّف SUSE المُطابق للمعالجات الأخرى. حافظ على جميع العُقد على نفس مستوى SLES SP وSLE HA. راجع دليل تثبيت SUSE SLE HA 15 SP7 .

3. تحديد نطاق العمل والنصاب القانوني قبل البدء

قائمة التحقق الطرفية التي تنص على ضرورة وجود STONITH ومسارات Corosync الاحتياطية، ويجب تقييم QDevice أو QNetd لعقدتين.
يُعدّ السياج أحد متطلبات الدعم؛ كما يجب تصميم مجموعة العقدتين مع مراعاة سلوك النصاب القانوني.

مطلوب للمجموعات المدعومة: عزل العقدة (STONITH)، ​​مع تفعيل stonith-enabledالخيارين "و" و startup-fencing"مُفعّل". يعمل العزل على عزل عقدة غير مؤكدة لمنع تشغيل الخدمة نفسها على جانبي القسم. اختر جهاز تحكم طاقة مدعومًا أو جهاز SBD مزودًا بمراقبة مُختبرة لأجهزتك أو برنامج إدارة الأجهزة الافتراضية لديك.

بالنسبة للعقدتين: توصي SUSE باستخدام QDevice/QNetd للمجموعات ذات عدد العقد الزوجي. يضيف هذا النظام آلية تصويت مستقلة للنصاب، وليس آلية حماية؛ لذا، قم بتكوين خادم QNetd منفصل أولاً إذا كنت ستستخدم QDevice أثناء عملية التهيئة. راجع دليل QDevice وQNetd .

مفهوم خاطئ شائع حول التخزين: التخزين المشترك ليس إلزاميًا لكل مجموعة، ولكن بيانات التطبيقات تحتاج إلى تصميم مشترك أو قابل للتكرار أو الاسترداد. يقوم Pacemaker بنقل الموارد، ولا ينسخ بيانات التطبيقات.

4. تهيئة العقدة الأولى

يعرض الطرفية عملية تهيئة مجموعة CRM مع اسم المجموعة ومطالبة لتحديد عنوان شبكة Corosync
يبدأ برنامج التمهيد على العقدة 1 ويطلب عنوان الشبكة الذي يجب أن يستخدمه Corosync.

على العقدة 1، ابدأ تشغيل CRM Shell كجذر أو من خلال إعداد المستخدم sudo المعتمد لديك:

crm cluster init --name prod-ha

اتبع التعليمات وحدد عنوان Corosync المطلوب. يقوم البرنامج النصي بتهيئة Corosync وSSH وCsync2 ومنافذ جدار الحماية للمجموعة وHawk2؛ كما يتحقق من مزامنة الوقت ويوفر خيار SBD وعنوان IP لإدارة Hawk2. راجع /var/log/crmsh/crmsh.logإعدادات التمهيد.

قم بإعداد نظام المراقبة على كل عقدة قبل اختيار SBD. في حال استخدام حماية خارجية، قم بتكوين مورد STONITH المدعوم قبل تحميل الأحمال. لا تقم أبدًا بتعطيل STONITH لتجاوز جهاز مفقود. يقوم Bootstrap بإنشاء مجموعة أساسية، وليس تطبيقًا عالي التوفر.

5. ضم العقدة الثانية

أمر الطرفية crm cluster join على العقدة 2 الاتصال بالجذر على العقدة 1
قم بتشغيل أمر الانضمام على العقدة 2؛ استخدم نفس خيارات واجهة الشبكة التي تم تحديدها أثناء التهيئة.

قم بتثبيت وتسجيل SLE HA على العقدة 2. إذا كنت تستخدم SBD، فقم بإعداد نظام المراقبة الخاص به هناك قبل الانضمام. ثم، بصلاحيات المستخدم الجذر:

crm cluster join -c root@node1

لإعداد مستخدم بصلاحيات sudo، اتبع USER@NODE1إجراءات SUSE. حدد نفس واجهتي الاتصال إذا تم تكوينهما عند بدء التشغيل. يقوم البرنامج النصي بنسخ إعدادات Corosync، وإعداد SSH وCsync2، وتفعيل العقدة 2. كرر هذه العملية مع المزيد من العقد؛ لا تخلط بين طريقتي إعداد bootstrap وYaST.

6. تأكيد العضوية وتأمين الإدارة

طرفية تحتوي على أوامر حالة نظام إدارة علاقات العملاء (crm status) وكلمة مرور نظام إدارة علاقات العملاء (passwd) الخاصة بنظام إدارة علاقات العملاء (hacluster) للتحقق من حالة المجموعة وتغيير كلمة مرور الحساب الأولي
تحقق من حالة العضوية في نظام إدارة علاقات العملاء (crm) وقم بتغيير كلمة مرور مجموعة الهاكلاستر قبل استخدام Hawk2.

من عقدة المجموعة، تحقق من العضوية:

crm status

تأكد من أن كلا العقدتين متصلتان بالإنترنت وأن النصاب القانوني متوفر. يتم إنشاء عملية التمهيد haclusterباستخدام كلمة المرور الأولية linux؛ قم بتغييرها على كل عقدة مهيأة.

passwd hacluster

يستخدم Hawk2 بروتوكول HTTPS على المنفذ 7630. تحقق من صحة الشهادة الموقعة ذاتيًا مع مسؤول النظام قبل اعتمادها. عنوان IP الخاص بإدارة Hawk2 ليس عنوان عميل التطبيق.

7. أضف موارد للخدمة التي تحتاجها فعليًا للحماية

مثال على واجهة CRM Shell لتعريف مورد IP افتراضي لخدمة IPaddr2، مع ملاحظة لاستخدام عنوان IP متاح من الشبكة الفرعية المحلية.
يُعرّف المثال مورد IP عائم فقط؛ استبدل عنوان التوثيق الخاص به بعنوان غير مستخدم من الشبكة الفرعية الخاصة بك.

يدير برنامج Pacemaker الخدمات من خلال وكلاء الموارد. قم بتثبيت وتكوين عبء العمل بشكل مناسب على العقد المؤهلة. ينشئ هذا المثال فقط عنصر IP عائم أساسي.

crm configure primitive service-vip IPaddr2   params ip=192.0.2.50 cidr_netmask=24   op monitor interval=10s timeout=20s

192.0.2.50هذا مخصص للتوثيق. استبدله بعنوان IP مجاني وبادئة صحيحة من شبكتك الفرعية. لا يقوم عنوان IP بتشغيل تطبيق أو نسخ البيانات. أضف الوكيل المدعوم للتطبيق بالإضافة إلى ترتيب التحميل، والتجميع، وسلوك التخزين الخاص بحمل العمل؛ واتبع إرشادات الاسترداد والحماية الخاصة بهذا المنتج.

8. اختبر تجاوز الفشل قبل إعلان جاهزية المجموعة

أوامر طرفية لوضع العقدة 1 في وضع الاستعداد، والتحقق من حالة المجموعة وعنوان IP الظاهري النموذجي، ثم إعادة العقدة 1 إلى وضع الاتصال بالإنترنت
يتحقق اختبار الاستعداد المخطط له من نقل المورد، ثم يعيد العقدة إلى الخدمة.

بعد تهيئة الموارد الحقيقية وتأمينها، قم بجدولة اختبار تجاوز الفشل المُتحكم به. ضع العقدة 1 في وضع الاستعداد وتحقق من الخدمة من العقدة 2:

crm node standby node1
crm status
ping -c 4 SERVICE_VIP
crm node online node1

استبدل SERVICE_VIPعنوان العميل الحقيقي. تأكد من استجابة التطبيق، ونقل الموارد كما هو متوقع، وانضمام العقدة 1 مجددًا. يتحقق الأمر ping من إمكانية الوصول إلى الشبكة فقط. تقوم SUSE crm cluster crash_testبتعطيل المكونات عمدًا، لذا استخدمه في بيئة اختبار مُخططة. اقرأ دليل البدء السريع ودليل الحماية الخاص بتثبيت SLE HA .

تحقق من توافر الخدمة

بعد الاختبار، تأكد من أن كلا العقدتين في الحالة المتوقعة، وأن خاصية الحماية لا تزال مُفعّلة، وأن عبء العمل يستجيب عبر نقطة نهاية العميل الخاصة به بعد عودة العقدة 1 إلى الاتصال بالإنترنت. لا يُعدّ ظهور حالة العضوية باللون الأخضر أو ​​نجاح اختبار الاتصال (ping) دليلاً كافياً على استعادة التطبيق.

اترك تعليقاً

أنشئ مجموعة SLES 15 HA مدعومة باستخدام Fencing First

أنشئ مجموعة SLES 15 HA مدعومة باستخدام Fencing First

قم بتسجيل SLE HA، وقم بتشغيل SLES 15 عقدة، ثم أضف الحماية، والنصاب القانوني، وموارد الخدمة المختبرة قبل الاعتماد على تجاوز الفشل.

خطأ HTTP 500 في SLES Zypper: تحديد المستودع المعطل

خطأ HTTP 500 في SLES Zypper: تحديد المستودع المعطل

تتبع خطأ تحديث Zypper إلى SUSE أو RMT أو نقطة نهاية تابعة لجهة خارجية، ثم قم بتطبيق الإصلاح الصحيح من جانب الخادم أو ذاكرة التخزين المؤقت دون تعطيل التحديثات الأساسية.

نفاد مساحة التخزين في نظام SLES Thin Pool: توسيع LVM بأمان واستعادة عمليات الكتابة

نفاد مساحة التخزين في نظام SLES Thin Pool: توسيع LVM بأمان واستعادة عمليات الكتابة

قم بحل أخطاء مساحة التخزين الرقيقة في SUSE LVM عن طريق التحقق من استخدام البيانات والبيانات الوصفية، وتوسيع المجموعة بأمان، ومنع الانقطاعات المتكررة.

عندما يصبح نظام ملفات Btrfs الخاص بنظام SLES للقراءة فقط: قم بالتشخيص قبل إعادة التثبيت

عندما يصبح نظام ملفات Btrfs الخاص بنظام SLES للقراءة فقط: قم بالتشخيص قبل إعادة التثبيت

حدد ما إذا كان نظام الملفات Btrfs مخصصًا للقراءة فقط عن قصد، أو يعاني من نقص في المساحة، أو يحمي البيانات بعد حدوث أخطاء، ثم اختر مسار استعادة يناسب السبب.

قم بتسجيل SLES 15 باستخدام SUSE Manager في شبكة غير متصلة بالإنترنت

قم بتسجيل SLES 15 باستخدام SUSE Manager في شبكة غير متصلة بالإنترنت

قم بإعداد القنوات المتطابقة، وإنشاء مفتاح التنشيط، وتشغيل عميل SLES 15 بدون اتصال مباشر بالإنترنت مع الحفاظ على الاتصال اللازم لتسجيل دخول المدير.

تفعيل خاصية إعادة توجيه X11 في YaST عبر SSH

تفعيل خاصية إعادة توجيه X11 في YaST عبر SSH

قم بإصلاح خطأ تشغيل XIO الخاص بـ YaST عبر SSH، وتحقق من إعادة توجيه X11 و xauth، وقم بالتبديل إلى واجهة ncurses عندما تكون النافذة البعيدة غير ضرورية.

التراجع الآمن عن تحديث SLES الفاشل باستخدام Snapper

التراجع الآمن عن تحديث SLES الفاشل باستخدام Snapper

ابحث عن لقطة Btrfs قبل التحديث، واختبرها للقراءة فقط، واجعل الاسترداد دائمًا باستخدام Snapper مع فهم البيانات التي تبقى خارج عملية التراجع الجذرية.

إعادة توجيه سجلات النظام الآمنة في SLES باستخدام rsyslog وبروتوكول TLS المتبادل

إعادة توجيه سجلات النظام الآمنة في SLES باستخدام rsyslog وبروتوكول TLS المتبادل

إرسال سجلات نظام SLES إلى جامع rsyslog عن بعد عبر TLS مصادق عليه، مع عمليات التحقق من الشهادات، وتخزين الانقطاعات مؤقتًا، واختبارات التسليم.

تتبع أخطاء الذاكرة في ترقية نظام SLES قبل إعادة المحاولة

تتبع أخطاء الذاكرة في ترقية نظام SLES قبل إعادة المحاولة

استخدم سجلات ذاكرة الوصول العشوائي (RAM) والمبادلة والنواة وZypper لتحديد ضغط الذاكرة الحقيقي وحماية حالة الحزمة واختيار محاولة إعادة ترقية SLES أكثر أمانًا.

حافظ على تشغيل تحديثات الأمان الخاصة بنظام Debian 12 على خادم بدون واجهة رسومية

حافظ على تشغيل تحديثات الأمان الخاصة بنظام Debian 12 على خادم بدون واجهة رسومية

قم بتمكين تحديثات الأمان التلقائية لنظام Debian عبر SSH، واحتفظ بمصادر الحزم الافتراضية، وتحقق من عمليات التشغيل المجدولة من خلال سجلات systemd و APT.