إعداد Pacemaker على Red Hat Enterprise Linux في Azure

توضح هذه المقالة كيفية تكوين مجموعة Pacemaker الأساسية على Red Hat Enterprise Server (RHEL). تغطي التعليمات RHEL 7 و RHEL 8 و RHEL 9.

المتطلبات الأساسية

اقرأ ملاحظات وأوراق SAP التالية أولا:

تثبيت المجموعة

Diagram that shows an overview of Pacemaker on RHEL.

إشعار

لا يدعم Red Hat مراقبة محاكية للبرامج. لا يدعم Red Hat SBD على الأنظمة الأساسية السحابية. لمزيد من المعلومات، راجع نهج الدعم لمجموعات قابلية الوصول العالية ل RHEL - sbd و fence_sbd.

آلية التسييج الوحيدة المدعومة لمجموعات Pacemaker RHEL على Azure هي عامل سياج Azure.

العناصر التالية مسبوقة بأيٍ مما يلي:

  • [أ]: ينطبق على جميع العقد
  • [1]: ينطبق فقط على العقدة 1
  • [2]: ينطبق فقط على العقدة 2

يتم وضع علامة على الاختلافات في الأوامر أو التكوين بين RHEL 7 و RHEL 8/RHEL 9 في المستند.

  1. [A] تسجيل. هذه الخطوة اختيارية. إذا كنت تستخدم الصور التي تدعم RHEL SAP HA، فهذه الخطوة غير مطلوبة.

    على سبيل المثال، إذا كنت تقوم بالنشر على RHEL 7، فسجل الجهاز الظاهري الخاص بك وأرفقه بتجمع يحتوي على مستودعات ل RHEL 7.

    sudo subscription-manager register
    # List the available pools
    sudo subscription-manager list --available --matches '*SAP*'
    sudo subscription-manager attach --pool=<pool id>
    

    عند إرفاق تجمع إلى صورة RHEL للدفع أولا بأول في Azure Marketplace، تتم محاسبتك بشكل فعال على استخدام RHEL. تتم فوترتك مرة واحدة لصورة الدفع أولا بأول ومرة واحدة لتستحق RHEL في التجمع الذي تقوم بإرفاقه. للتخفيف من هذا الموقف، يوفر Azure الآن صور RHEL لجلب اشتراكك الخاص. لمزيد من المعلومات، راجع Red Hat Enterprise Linux bring-your-own-subscription Azure images.

  2. [A] تمكين RHEL لمستودعات SAP. هذه الخطوة اختيارية. إذا كنت تستخدم الصور التي تدعم RHEL SAP HA، فهذه الخطوة غير مطلوبة.

    لتثبيت الحزم المطلوبة على RHEL 7، قم بتمكين المستودعات التالية:

    sudo subscription-manager repos --disable "*"
    sudo subscription-manager repos --enable=rhel-7-server-rpms
    sudo subscription-manager repos --enable=rhel-ha-for-rhel-7-server-rpms
    sudo subscription-manager repos --enable=rhel-sap-for-rhel-7-server-rpms
    sudo subscription-manager repos --enable=rhel-ha-for-rhel-7-server-eus-rpms
    
  3. [A] تثبيت الوظيفة الإضافية RHEL HA.

     sudo yum install -y pcs pacemaker fence-agents-azure-arm nmap-ncat
    

    هام

    نوصي بالإصدارات التالية من عامل Azure fence (أو أحدث) للعملاء للاستفادة من وقت تجاوز الفشل الأسرع، إذا فشل توقف المورد أو تعذر على عقد نظام المجموعة الاتصال مع بعضها البعض بعد الآن:

    RHEL 7.7 أو أعلى استخدام أحدث إصدار متاح من حزمة وكلاء السياج.

    RHEL 7.6: fence-agents-4.2.1-11.el7_6.8

    RHEL 7.5: fence-agents-4.0.11-86.el7_5.8

    RHEL 7.4: fence-agents-4.0.11-66.el7_4.12

    لمزيد من المعلومات، راجع Azure VM الذي يعمل كعضو في نظام مجموعة RHEL عالي التوفر يستغرق وقتا طويلا جدا ليتم تسييجه، أو فشل/مهلة التسييج قبل إيقاف تشغيل الجهاز الظاهري.

    هام

    نوصي بالإصدارات التالية من عامل Azure fence (أو أحدث) للعملاء الذين يرغبون في استخدام الهويات المدارة لموارد Azure بدلا من الأسماء الأساسية للخدمة لعامل السياج:

    RHEL 8.4: fence-agents-4.2.1-54.el8.

    RHEL 8.2: fence-agents-4.2.1-41.el8_2.4

    RHEL 8.1: fence-agents-4.2.1-30.el8_1.4

    RHEL 7.9: fence-agents-4.2.1-41.el7_9.4.

    هام

    في RHEL 9، نوصي بإصدارات الحزمة التالية (أو أحدث) لتجنب المشكلات مع عامل سياج Azure:

    عوامل السياج-4.10.0-20.el9_0.7

    fence-agents-common-4.10.0-20.el9_0.6

    ha-cloud-support-4.10.0-20.el9_0.6.x86_64.rpm

    تحقق من إصدار Azure fence agent. إذا لزم الأمر، فقم بتحديثه إلى الحد الأدنى المطلوب من الإصدار أو أحدث.

    # Check the version of the Azure Fence Agent
     sudo yum info fence-agents-azure-arm
    

    هام

    إذا كنت بحاجة إلى تحديث عامل Azure fence، وإذا كنت تستخدم دورا مخصصا، فتأكد من تحديث الدور المخصص لتضمين powerOff للإجراء. لمزيد من المعلومات، راجع إنشاء دور مخصص لعامل السياج.

  4. إذا كنت تقوم بالنشر على RHEL 9، فقم أيضا بتثبيت عوامل الموارد لنشر السحابة.

    sudo yum install -y resource-agents-cloud
    
  5. [A] إعداد دقة اسم المضيف.

    يمكنك إما استخدام خادم DNS أو تعديل الملف على /etc/hosts جميع العقد. يوضح هذا المثال كيفية استخدام ملف /etc/hosts. استبدل عنوان IP واسم المضيف في الأوامر التالية.

    هام

    إذا كنت تستخدم أسماء المضيفين في تكوين نظام المجموعة، فمن الضروري أن يكون لديك دقة موثوقة لاسم المضيف. يفشل اتصال نظام المجموعة إذا لم تكن الأسماء متوفرة، ما قد يؤدي إلى تأخيرات تجاوز فشل نظام المجموعة.

    تتمثل فائدة الاستخدام /etc/hosts في أن نظام المجموعة الخاص بك يصبح مستقلا عن DNS، والذي قد يكون نقطة فشل واحدة أيضا.

    sudo vi /etc/hosts
    

    أدرج الأسطر التالية في /etc/hosts. قم بتغيير عنوان IP واسم المضيف لمطابقة بيئتك.

    # IP address of the first cluster node
    10.0.0.6 prod-cl1-0
    # IP address of the second cluster node
    10.0.0.7 prod-cl1-1
    
  6. [A] تغيير hacluster كلمة المرور إلى نفس كلمة المرور.

    sudo passwd hacluster
    
  7. [A] إضافة قواعد جدار الحماية ل Pacemaker.

    أضف قواعد جدار الحماية التالية إلى جميع اتصالات المجموعة بين عقد المجموعة.

    sudo firewall-cmd --add-service=high-availability --permanent
    sudo firewall-cmd --add-service=high-availability
    
  8. [A] تمكين خدمات نظام المجموعة الأساسية.

    قم بتشغيل الأوامر التالية لتمكين خدمة Pacemaker وبدء تشغيلها.

    sudo systemctl start pcsd.service
    sudo systemctl enable pcsd.service
    
  9. [1] إنشاء نظام مجموعة Pacemaker.

    قم بتشغيل الأوامر التالية لمصادقة العقد وإنشاء المجموعة. قم بتعيين الرمز المميز إلى 30000 للسماح بالحفاظ على الذاكرة الصيانة. لمزيد من المعلومات، راجع this article for Linux.

    إذا كنت تقوم بإنشاء نظام مجموعة على RHEL 7.x، فاستخدم الأوامر التالية:

    sudo pcs cluster auth prod-cl1-0 prod-cl1-1 -u hacluster
    sudo pcs cluster setup --name nw1-azr prod-cl1-0 prod-cl1-1 --token 30000
    sudo pcs cluster start --all
    

    إذا كنت تقوم بإنشاء نظام مجموعة على RHEL 8.x/RHEL 9.x، فاستخدم الأوامر التالية:

    sudo pcs host auth prod-cl1-0 prod-cl1-1 -u hacluster
    sudo pcs cluster setup nw1-azr prod-cl1-0 prod-cl1-1 totem token=30000
    sudo pcs cluster start --all
    

    تحقق من حالة نظام المجموعة عن طريق تشغيل الأمر التالي:

    # Run the following command until the status of both nodes is online
    sudo pcs status
    
    # Cluster name: nw1-azr
    # WARNING: no stonith devices and stonith-enabled is not false
    # Stack: corosync
    # Current DC: prod-cl1-1 (version 1.1.18-11.el7_5.3-2b07d5c5a9) - partition with quorum
    # Last updated: Fri Aug 17 09:18:24 2018
    # Last change: Fri Aug 17 09:17:46 2018 by hacluster via crmd on prod-cl1-1
    #
    # 2 nodes configured
    # 0 resources configured
    #
    # Online: [ prod-cl1-0 prod-cl1-1 ]
    #
    # No resources
    #
    # Daemon Status:
    #   corosync: active/disabled
    #   pacemaker: active/disabled
    #   pcsd: active/enabled
    
  10. [A] تعيين الأصوات المتوقعة.

    # Check the quorum votes 
    pcs quorum status
    
    # If the quorum votes are not set to 2, execute the next command
    sudo pcs quorum expected-votes 2
    

    تلميح

    إذا كنت تقوم بإنشاء مجموعة متعددة العقد، أي مجموعة بها أكثر من عقدتين، فلا تقم بتعيين الأصوات إلى 2.

  11. [1] السماح بإجراءات السياج المتزامنة.

    sudo pcs property set concurrent-fencing=true
    

إنشاء جهاز تسييج

يستخدم جهاز التسييج إما هوية مدارة لمورد Azure أو كيان خدمة للتخويل مقابل Azure.

لإنشاء هوية مدارة (MSI)، قم بإنشاء هوية مدارة يعينها النظام لكل جهاز ظاهري في نظام المجموعة. إذا كانت الهوية المدارة المعينة من قبل النظام موجودة بالفعل، يتم استخدامها. لا تستخدم الهويات المدارة المعينة من قبل المستخدم مع Pacemaker في هذا الوقت. يتم دعم جهاز السياج، استنادا إلى الهوية المدارة، على RHEL 7.9 و RHEL 8.x/RHEL 9.x.

[1] إنشاء دور مخصص لعامل التحديد

لا تملك كل من الهوية المدارة ومدير الخدمة أذونات للوصول إلى موارد Azure بشكل افتراضي. تحتاج إلى منح الهوية المدارة أو أذونات كيان الخدمة لبدء وإيقاف (إيقاف التشغيل) جميع الأجهزة الظاهرية لنظام المجموعة. إذا لم تكن قد أنشأت الدور المخصص بالفعل، يمكنك إنشاؤه باستخدام PowerShell أو Azure CLI.

استخدم المحتوى التالي لملف الإدخال. تحتاج إلى تكييف المحتوى مع اشتراكاتك، أي استبدال xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx ومعرفات yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy اشتراكك. إذا كان لديك اشتراك واحد فقط، فقم بإزالة الإدخال الثاني في AssignableScopes.

{
      "Name": "Linux Fence Agent Role",
      "description": "Allows to power-off and start virtual machines",
      "assignableScopes": [
              "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
              "/subscriptions/yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy"
      ],
      "actions": [
              "Microsoft.Compute/*/read",
              "Microsoft.Compute/virtualMachines/powerOff/action",
              "Microsoft.Compute/virtualMachines/start/action"
      ],
      "notActions": [],
      "dataActions": [],
      "notDataActions": []
}

[A]تعيين الدور المخصص

استخدم الهوية المدارة أو كيان الخدمة.

تعيين الدور Linux Fence Agent Role المخصص الذي تم إنشاؤه في القسم الأخير لكل هوية مدارة من الأجهزة الظاهرية لنظام المجموعة. تحتاج كل هوية مُدارة يعينها نظام VM إلى الدور المعين لكل مورد لمجموعة VM. للمزيد من المعلومات، راجع تعيين الوصول إلى هوية مدارة إلى مورد باستخدام مدخل Azure. تحقق من أن تعيين دور الهوية المدارة لكل جهاز ظاهري يحتوي على جميع الأجهزة الظاهرية لنظام المجموعة.

هام

يجب أن تدرك أن تعيين وإزالة التخويل مع الهويات المدارة يمكن تأخيرها حتى تصبح فعالة .

[1] إنشاء أجهزة الحد

بعد تحرير أذونات الأجهزة الظاهرية، يمكنك تكوين أجهزة التسييج في نظام المجموعة.

sudo pcs property set stonith-timeout=900

إشعار

الخيار pcmk_host_map مطلوب فقط في الأمر إذا لم تكن أسماء مضيفي RHEL وأسماء Azure VM متطابقة. حدد التعيين بتنسيق hostname:vm-name. ارجع إلى القسم الغامق في الأمر. لمزيد من المعلومات، راجع ما التنسيق الذي يجب استخدامه لتحديد تعيينات العقد لأجهزة التسييج في pcmk_host_map؟.

بالنسبة ل RHEL 7.x، استخدم الأمر التالي لتكوين جهاز السياج:

sudo pcs stonith create rsc_st_azure fence_azure_arm msi=true resourceGroup="resource group" \ 
subscriptionId="subscription id" pcmk_host_map="prod-cl1-0:prod-cl1-0-vm-name;prod-cl1-1:prod-cl1-1-vm-name" \
power_timeout=240 pcmk_reboot_timeout=900 pcmk_monitor_timeout=120 pcmk_monitor_retries=4 pcmk_action_limit=3 pcmk_delay_max=15 \
op monitor interval=3600

بالنسبة إلى RHEL 8.x/9.x، استخدم الأمر التالي لتكوين جهاز السياج:

# Run following command if you are setting up fence agent on (two-node cluster and pacemaker version greater than 2.0.4-6.el8) OR (HANA scale out)
sudo pcs stonith create rsc_st_azure fence_azure_arm msi=true resourceGroup="resource group" \
subscriptionId="subscription id" pcmk_host_map="prod-cl1-0:prod-cl1-0-vm-name;prod-cl1-1:prod-cl1-1-vm-name" \
power_timeout=240 pcmk_reboot_timeout=900 pcmk_monitor_timeout=120 pcmk_monitor_retries=4 pcmk_action_limit=3 \
op monitor interval=3600

# Run following command if you are setting up fence agent on (two-node cluster and pacemaker version less than 2.0.4-6.el8)
sudo pcs stonith create rsc_st_azure fence_azure_arm msi=true resourceGroup="resource group" \
subscriptionId="subscription id" pcmk_host_map="prod-cl1-0:prod-cl1-0-vm-name;prod-cl1-1:prod-cl1-1-vm-name" \
power_timeout=240 pcmk_reboot_timeout=900 pcmk_monitor_timeout=120 pcmk_monitor_retries=4 pcmk_action_limit=3 pcmk_delay_max=15 \
op monitor interval=3600

إذا كنت تستخدم جهاز تسييج يستند إلى تكوين كيان الخدمة، فاقرأ التغيير من SPN إلى MSI لمجموعات Pacemaker باستخدام تسييج Azure وتعلم كيفية التحويل إلى تكوين الهوية المدارة.

تلميح

  • لتجنب سباقات السياج داخل نظام مجموعة منظم ضربات القلب ثنائية العقدة، يمكنك تكوين priority-fencing-delay خاصية نظام المجموعة. تقدم هذه الخاصية تأخيرا إضافيا في تسييج عقدة ذات أولوية إجمالية أعلى للموارد عند حدوث سيناريو تقسيم الدماغ. لمزيد من المعلومات، راجع هل يمكن ل Pacemaker سياج عقدة نظام المجموعة بأقل الموارد قيد التشغيل؟.
  • تنطبق الخاصية priority-fencing-delay على إصدار Pacemaker 2.0.4-6.el8 أو أعلى وعلى نظام مجموعة مكون من عقدتين. إذا قمت بتكوين priority-fencing-delay خاصية نظام المجموعة، فلن تحتاج إلى تعيين الخاصية pcmk_delay_max . ولكن إذا كان إصدار Pacemaker أقل من 2.0.4-6.el8، فأنت بحاجة إلى تعيين الخاصية pcmk_delay_max .
  • للحصول على إرشادات حول كيفية تعيين priority-fencing-delay خاصية نظام المجموعة، راجع مستندات SAP ASCS/ERS المعنية وSAP HANA لزيادة قابلية الوصول العالية.

تم إلغاء تسلسل عمليات المراقبة والحد الزمني. ونتيجة لذلك، إذا كانت هناك عملية مراقبة قيد التشغيل وحدث تسييج متزامن، فلن يكون هناك تأخير في تجاوز فشل نظام المجموعة لأن عملية المراقبة قيد التشغيل بالفعل.

[1] تمكين استخدام جهاز الحد

sudo pcs property set stonith-enabled=true

تلميح

يتطلب عامل سياج Azure اتصالا صادرا بنقاط النهاية العامة. لمزيد من المعلومات جنبا إلى جنب مع الحلول الممكنة، راجع اتصال نقطة النهاية العامة للأجهزة الظاهرية باستخدام ILB القياسي.

تكوين Pacemaker للأحداث المجدولة في Azure

يقدم Azure الأحداث المجدولة. يتم إرسال الأحداث المجدولة عبر خدمة بيانات التعريف وتسمح بوقت التطبيق للتحضير لمثل هذه الأحداث.

يراقب عامل azure-events-az موارد Pacemaker أحداث Azure المجدولة. إذا تم الكشف عن الأحداث وحدد عامل المورد توفر عقدة نظام مجموعة أخرى، فإنه يعين سمة صحة نظام المجموعة.

عند تعيين سمة صحة نظام المجموعة لعقدة، يتم تشغيل قيد الموقع ويتم ترحيل جميع الموارد التي لا تبدأ بالأسماء health- بعيدا عن العقدة مع الحدث المجدول. بعد أن تكون عقدة نظام المجموعة المتأثرة خالية من تشغيل موارد نظام المجموعة، يتم الاعتراف بالحدث المجدول ويمكنه تنفيذ الإجراء الخاص به، مثل إعادة التشغيل.

  1. [A] تأكد من أن حزمة العامل مثبتة azure-events-az بالفعل ومحدثة.

    RHEL 8.x: sudo dnf info resource-agents
    RHEL 9.x: sudo dnf info resource-agents-cloud
    

    الحد الأدنى لمتطلبات الإصدار:

    • RHEL 8.4: resource-agents-4.1.1-90.13
    • RHEL 8.6: resource-agents-4.9.0-16.9
    • RHEL 8.8: resource-agents-4.9.0-40.1
    • RHEL 9.0: resource-agents-cloud-4.10.0-9.6
    • RHEL 9.2 والأحدث: resource-agents-cloud-4.10.0-34.1
  2. [1] قم بتكوين الموارد في Pacemaker.

    #Place the cluster in maintenance mode
    sudo pcs property set maintenance-mode=true
    
    
  3. [1] تعيين استراتيجية عقدة صحة نظام مجموعة Pacemaker والقيد.

    sudo pcs property set node-health-strategy=custom
    sudo pcs constraint location 'regexp%!health-.*' \
    rule score-attribute='#health-azure' \
    defined '#uname'
    

    هام

    لا تحدد أي موارد أخرى في نظام المجموعة بدءا health- من إلى جانب الموارد الموضحة في الخطوات التالية.

  4. [1] تعيين القيمة الأولية لسمات نظام المجموعة. قم بتشغيل لكل عقدة نظام مجموعة وبيئات توسيع النطاق بما في ذلك الجهاز الظاهري لصانع الأغلبية.

    sudo crm_attribute --node prod-cl1-0 --name '#health-azure' --update 0
    sudo crm_attribute --node prod-cl1-1 --name '#health-azure' --update 0
    
  5. [1] قم بتكوين الموارد في Pacemaker. تأكد من أن الموارد تبدأ ب health-azure.

    sudo pcs resource create health-azure-events \
    ocf:heartbeat:azure-events-az \
    op monitor interval=10s timeout=240s \
    op start timeout=10s start-delay=90s
    sudo pcs resource clone health-azure-events allow-unhealthy-nodes=true failure-timeout=120s
    
  6. أخرج نظام مجموعة Pacemaker من وضع الصيانة.

    sudo pcs property set maintenance-mode=false
    
  7. قم بإلغاء تحديد أي أخطاء أثناء التمكين وتحقق من أن health-azure-events الموارد قد بدأت بنجاح على جميع عقد نظام المجموعة.

    sudo pcs resource cleanup
    

    قد يستغرق تنفيذ الاستعلام لأول مرة للأحداث المجدولة ما يصل إلى دقيقتين. يمكن أن يستخدم اختبار Pacemaker مع الأحداث المجدولة إجراءات إعادة التشغيل أو إعادة التوزيع للأجهزة الظاهرية لنظام المجموعة. لمزيد من المعلومات، راجع الأحداث المجدولة.

تكوين التحديد الاختياري

تلميح

ينطبق هذا القسم فقط إذا كنت تريد تكوين جهاز fence_kdumpالتسييج الخاص .

إذا كنت بحاجة إلى جمع معلومات تشخيصية داخل الجهاز الظاهري، فقد يكون من المفيد تكوين جهاز تسييج آخر استنادا إلى عامل fence_kdumpالسياج . يمكن للعامل fence_kdump اكتشاف أن عقدة دخلت استرداد تعطل kdump ويمكن أن تسمح بإكمال خدمة استرداد الأعطال قبل استدعاء أساليب التسييج الأخرى. لاحظ أن fence_kdump ليس بديلا لآليات السياج التقليدية، مثل عامل سياج Azure، عند استخدام أجهزة Azure الظاهرية.

هام

يجب أن تدرك أنه عند fence_kdump تكوينه كجهاز تسييج من المستوى الأول، فإنه يقدم تأخيرات في عمليات التسييج، وعلى التوالي، التأخيرات في تجاوز فشل موارد التطبيق.

إذا تم الكشف عن تفريغ الأعطال بنجاح، يتم تأخير التسييج حتى تكتمل خدمة استرداد الأعطال. إذا كانت العقدة الفاشلة غير قابلة للوصول أو إذا لم تستجب، يتم تأخير التسييج حسب الوقت المحدد، وعدد التكرارات المكونة، والمهلة fence_kdump . لمزيد من المعلومات، راجع كيف أعمل تكوين fence_kdump في مجموعة Red Hat Pacemaker؟.

قد تحتاج المهلة المقترحة fence_kdump إلى التكيف مع البيئة المحددة.

نوصي بتكوين fence_kdump التسييج فقط عند الضرورة لجمع التشخيصات داخل الجهاز الظاهري والجمع دائما مع أساليب السياج التقليدية، مثل عامل سياج Azure.

تحتوي مقالات كيلوبايت Red Hat التالية على معلومات مهمة حول تكوين fence_kdump التسييج:

قم بتشغيل الخطوات الاختيارية التالية لإضافتها fence_kdump كتكوين تسييج من المستوى الأول، بالإضافة إلى تكوين عامل سياج Azure.

  1. [A] تحقق من أن kdump يكون نشطا ومكونا.

    systemctl is-active kdump
    # Expected result
    # active
    
  2. [A] ثبت عامل التحديد fence_kdump.

    yum install fence-agents-kdump
    
  3. [1] إنشاء fence_kdump جهاز تسييج في نظام المجموعة.

    pcs stonith create rsc_st_kdump fence_kdump pcmk_reboot_action="off" pcmk_host_list="prod-cl1-0 prod-cl1-1" timeout=30
    
  4. [1] تكوين مستويات التسييج بحيث يتم إشراك آلية التسييج fence_kdump أولا.

    pcs stonith create rsc_st_kdump fence_kdump pcmk_reboot_action="off" pcmk_host_list="prod-cl1-0 prod-cl1-1"
    pcs stonith level add 1 prod-cl1-0 rsc_st_kdump
    pcs stonith level add 1 prod-cl1-1 rsc_st_kdump
    pcs stonith level add 2 prod-cl1-0 rsc_st_azure
    pcs stonith level add 2 prod-cl1-1 rsc_st_azure
    
    # Check the fencing level configuration 
    pcs stonith level
    # Example output
    # Target: prod-cl1-0
    # Level 1 - rsc_st_kdump
    # Level 2 - rsc_st_azure
    # Target: prod-cl1-1
    # Level 1 - rsc_st_kdump
    # Level 2 - rsc_st_azure
    
  5. [A] السماح بالمنافذ المطلوبة من fence_kdump خلال جدار الحماية.

    firewall-cmd --add-port=7410/udp
    firewall-cmd --add-port=7410/udp --permanent
    
  6. [A] تأكد من initramfs أن ملف الصورة يحتوي على الملفين fence_kdump و hosts . لمزيد من المعلومات، راجع كيف أعمل تكوين fence_kdump في مجموعة Red Hat Pacemaker؟.

    lsinitrd /boot/initramfs-$(uname -r)kdump.img | egrep "fence|hosts"
    # Example output 
    # -rw-r--r--   1 root     root          208 Jun  7 21:42 etc/hosts
    # -rwxr-xr-x   1 root     root        15560 Jun 17 14:59 usr/libexec/fence_kdump_send
    
  7. [A] قم بإجراء fence_kdump_nodes التكوين في /etc/kdump.conf لتجنب fence_kdump الفشل مع مهلة لبعض kexec-tools الإصدارات. لمزيد من المعلومات، راجع مهلة fence_kdump عندما لا يتم تحديد fence_kdump_nodes مع kexec-tools الإصدار 2.0.15 أو أحدث ويفشل fence_kdump مع "المهلة بعد X ثانية" في نظام مجموعة قابلية وصول عالية التوفر RHEL 6 أو 7 مع إصدارات أدوات kexec أقدم من 2.0.14. يتم تقديم مثال التكوين لنظام مجموعة من عقدتين هنا. بعد إجراء تغيير في /etc/kdump.conf، يجب إعادة إنشاء صورة kdump. لإعادة إنشاء الخدمة، أعد تشغيل kdump الخدمة.

    vi /etc/kdump.conf
    # On node prod-cl1-0 make sure the following line is added
    fence_kdump_nodes  prod-cl1-1
    # On node prod-cl1-1 make sure the following line is added
    fence_kdump_nodes  prod-cl1-0
    
    # Restart the service on each node
    systemctl restart kdump
    
  8. اختبر التكوين عن طريق تحطيم عقدة. لمزيد من المعلومات، راجع كيف أعمل تكوين fence_kdump في مجموعة Red Hat Pacemaker؟.

    هام

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

    echo c > /proc/sysrq-trigger
    

الخطوات التالية