إعداد Pacemaker على Red Hat Enterprise Linux في Azure
توضح هذه المقالة كيفية تكوين مجموعة Pacemaker الأساسية على Red Hat Enterprise Server (RHEL). تغطي التعليمات RHEL 7 و RHEL 8 و RHEL 9.
المتطلبات الأساسية
اقرأ ملاحظات وأوراق SAP التالية أولا:
- 1928533 ملاحظة SAP، والتي تحتوي على:
- قائمة بأحجام الجهاز الظاهري Azure (VM) المدعومة لنشر برنامج SAP.
- معلومات هامة عن السعة لأحجام أجهزة Azure الظاهرية.
- برامج SAP المدعومة ونظام التشغيل (OS) ومجموعات قاعدة البيانات.
- إصدار SAP kernel المطلوب لـ Windows وLinux على Microsoft Azure.
- تسرد ملاحظة SAP رقم 2015553 المتطلبات الأساسية لعمليات نشر برامج SAP المدعومة في Azure.
- توصي SAP Note 2002167 بإعدادات نظام التشغيل ل Red Hat Enterprise Linux.
- توصي SAP Note 3108316 بإعدادات نظام التشغيل ل Red Hat Enterprise Linux 9.x.
- يحتوي SAP Note 2009879 على إرشادات SAP Hana لنظام التشغيل Red Hat Enterprise Linux.
- SAP Note 3108302 لديه إرشادات SAP HANA ل Red Hat Enterprise Linux 9.x.
- تحتوي ملاحظة SAP Note 2178632 على معلومات مفصلة حول جميع مقاييس المراقبة التي تم الإبلاغ عنها لـ SAP في Azure.
- تحتوي ملاحظة SAP 2191498 على إصدار SAP Host Agent المطلوب لنظام التشغيل Linux في Azure.
- تحتوي ملاحظة SAP رقم 2243692 على معلومات حول ترخيص SAP على Linux في Azure.
- تحتوي ملاحظة SAP رقم 1999351 على مزيد من المعلومات عن استكشاف الأخطاء وإصلاحها لملحق المراقبة المحسّن Azure لـ SAP.
- يحتوي SAP Community WIKI عل كل ملاحظات SAP المطلوبة لـ Linux.
- تخطيط وتنفيذ أجهزة Azure الظاهرية ل SAP على Linux
- توزيع Azure Virtual Machines لـ SAP على Linux (هذه المقالة)
- نشر Azure Virtual Machines DBMS لـ SAP على Linux
- النسخ المتماثل لنظام SAP HANA في نظام مجموعة Pacemaker
- وثائق RHEL العامة:
- وثائق RHEL الخاصة ب Azure:
- نهج الدعم لمجموعات قابلية الوصول العالية RHEL - أجهزة Microsoft Azure الظاهرية كأعضاء نظام المجموعة
- تثبيت وتكوين Red Hat Enterprise Linux 7.4 (والإصدار الأحدث) High-Availability Cluster على Microsoft Azure
- اعتبارات في اعتماد RHEL 8 - قابلية وصول عالية ومجموعات
- تكوين SAP S/4HANA ASCS/ERS باستخدام خادم انتظار مستقل 2 (ENSA2) في Pacemaker على RHEL 7.6
- RHEL لـ SAP Offerings على Azure
تثبيت المجموعة
إشعار
لا يدعم Red Hat مراقبة محاكية للبرامج. لا يدعم Red Hat SBD على الأنظمة الأساسية السحابية. لمزيد من المعلومات، راجع نهج الدعم لمجموعات قابلية الوصول العالية ل RHEL - sbd و fence_sbd.
آلية التسييج الوحيدة المدعومة لمجموعات Pacemaker RHEL على Azure هي عامل سياج Azure.
العناصر التالية مسبوقة بأيٍ مما يلي:
- [أ]: ينطبق على جميع العقد
- [1]: ينطبق فقط على العقدة 1
- [2]: ينطبق فقط على العقدة 2
يتم وضع علامة على الاختلافات في الأوامر أو التكوين بين RHEL 7 و RHEL 8/RHEL 9 في المستند.
[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.
[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
[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 للإجراء. لمزيد من المعلومات، راجع إنشاء دور مخصص لعامل السياج.
إذا كنت تقوم بالنشر على RHEL 9، فقم أيضا بتثبيت عوامل الموارد لنشر السحابة.
sudo yum install -y resource-agents-cloud
[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
[A] تغيير
hacluster
كلمة المرور إلى نفس كلمة المرور.sudo passwd hacluster
[A] إضافة قواعد جدار الحماية ل Pacemaker.
أضف قواعد جدار الحماية التالية إلى جميع اتصالات المجموعة بين عقد المجموعة.
sudo firewall-cmd --add-service=high-availability --permanent sudo firewall-cmd --add-service=high-availability
[A] تمكين خدمات نظام المجموعة الأساسية.
قم بتشغيل الأوامر التالية لتمكين خدمة Pacemaker وبدء تشغيلها.
sudo systemctl start pcsd.service sudo systemctl enable pcsd.service
[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
[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.
[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-
بعيدا عن العقدة مع الحدث المجدول. بعد أن تكون عقدة نظام المجموعة المتأثرة خالية من تشغيل موارد نظام المجموعة، يتم الاعتراف بالحدث المجدول ويمكنه تنفيذ الإجراء الخاص به، مثل إعادة التشغيل.
[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
- RHEL 8.4:
[1] قم بتكوين الموارد في Pacemaker.
#Place the cluster in maintenance mode sudo pcs property set maintenance-mode=true
[1] تعيين استراتيجية عقدة صحة نظام مجموعة Pacemaker والقيد.
sudo pcs property set node-health-strategy=custom sudo pcs constraint location 'regexp%!health-.*' \ rule score-attribute='#health-azure' \ defined '#uname'
هام
لا تحدد أي موارد أخرى في نظام المجموعة بدءا
health-
من إلى جانب الموارد الموضحة في الخطوات التالية.[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
[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
أخرج نظام مجموعة Pacemaker من وضع الصيانة.
sudo pcs property set maintenance-mode=false
قم بإلغاء تحديد أي أخطاء أثناء التمكين وتحقق من أن
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 في نظام مجموعة Red Hat Pacemaker؟.
- راجع كيفية تكوين/إدارة مستويات التسييج في مجموعة RHEL باستخدام Pacemaker.
- راجع فشل fence_kdump مع "المهلة بعد X ثانية" في مجموعة RHEL 6 أو 7 HA مع kexec-tools أقدم من 2.0.14.
- للحصول على معلومات حول كيفية تغيير المهلة الافتراضية، راجع كيف أعمل تكوين kdump للاستخدام مع الوظيفة الإضافية RHEL 6 و7 و8 HA؟.
- للحصول على معلومات حول كيفية تقليل تأخير تجاوز الفشل عند استخدام
fence_kdump
، راجع هل يمكنني تقليل التأخير المتوقع لتجاوز الفشل عند إضافة تكوين fence_kdump؟.
قم بتشغيل الخطوات الاختيارية التالية لإضافتها fence_kdump
كتكوين تسييج من المستوى الأول، بالإضافة إلى تكوين عامل سياج Azure.
[A] تحقق من أن
kdump
يكون نشطا ومكونا.systemctl is-active kdump # Expected result # active
[A] ثبت عامل التحديد
fence_kdump
.yum install fence-agents-kdump
[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
[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
[A] السماح بالمنافذ المطلوبة من
fence_kdump
خلال جدار الحماية.firewall-cmd --add-port=7410/udp firewall-cmd --add-port=7410/udp --permanent
[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
[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
اختبر التكوين عن طريق تحطيم عقدة. لمزيد من المعلومات، راجع كيف أعمل تكوين fence_kdump في مجموعة Red Hat Pacemaker؟.
هام
إذا كان نظام المجموعة قيد الاستخدام الإنتاجي بالفعل، فخطط الاختبار وفقا لذلك لأن تعطل عقدة له تأثير على التطبيق.
echo c > /proc/sysrq-trigger
الخطوات التالية
- راجع تخطيط الأجهزة الظاهرية Azure وتنفيذها ل SAP.
- راجع توزيع أجهزة Azure الظاهرية ل SAP.
- راجع توزيع Azure Virtual Machines DBMS ل SAP.
- لمعرفة كيفية إنشاء قابلية وصول عالية والتخطيط للتعافي من الكوارث من SAP HANA على أجهزة Azure الظاهرية، راجع قابلية الوصول العالية ل SAP HANA على أجهزة Azure الظاهرية.
الملاحظات
https://aka.ms/ContentUserFeedback.
قريبًا: خلال عام 2024، سنتخلص تدريجيًا من GitHub Issues بوصفها آلية إرسال ملاحظات للمحتوى ونستبدلها بنظام ملاحظات جديد. لمزيد من المعلومات، راجعإرسال الملاحظات وعرضها المتعلقة بـ