مشاركة عبر

توفر IBM Db2 LUW عالي المستوى على أجهزة Azure الظاهرية على خادم SUSE Linux Enterprise Server المزود بجهاز Pacemaker

  • مقالة

يتكون IBM Db2 لنظام التشغيل Linux وUNIX وWindows (LUW) في تكوين قابلية الوصول العالية والإصلاح بعد كارثة (HADR) من عقدة واحدة تقوم بتشغيل مثيل قاعدة بيانات أساسي، وعقدة واحدة على الأقل تقوم بتشغيل مثيل قاعدة بيانات ثانوي. يتم نسخ التغييرات التي تطرأ على مثيل قاعدة البيانات الأساسي إلى مثيل قاعدة بيانات ثانوي بشكل متزامن أو غير متزامن، اعتمادًا على التكوين.

إشعار

تحتوي هذه المقالة على مراجع للمصطلحات التي لم تعد Microsoft تستخدمها. عند إزالة هذه المصطلحات من البرنامج، سنقوم بإزالتها من هذه المقالة.

توضح هذه المقالة كيفية توزيع أجهزة Azure الظاهرية (VMs) وتكوينها، وتثبيت إطار عمل نظام المجموعة، وتثبيت IBM Db2 LUW باستخدام تكوين HADR.

لا تغطي المقالة كيفية تثبيت IBM Db2 LUW وتكوينه باستخدام تثبيت برنامج HADR أو SAP. لمساعدتك في إنجاز هذه المهام، نقدم مراجع بشأن أدلة تثبيت SAP وIBM. تركز هذه المقالة على الأجزاء الخاصة ببيئة Azure.

إصدارات IBM Db2 المدعومة هي 10.5 والإصدارات الأحدث، كما هو موثق في ملاحظة SAP رقم 1928533.

قبل بدء التثبيت، راجع ملاحظات SAP والوثائق التالية:

ملاحظة SAP ‏‏الوصف
1928533 تطبيقات SAP على Azure: المنتجات المدعومة وأنواع أجهزة Azure الظاهرية
2015553 SAP على Azure: دعم المتطلبات الأساسية
2178632 مقاييس المراقبة الرئيسية لـ SAP على Azure
2191498 SAP على Linux باستخدام Azure: مراقبة محسنة
2243692 جهاز ظاهري بنظام Linux على Azure (خدمة تأجير البنية التحتية): مشكلات ترخيص SAP
1984787 خادم المؤسسة 12 لـSUSE LINUX: ملاحظات التثبيت
1999351 استكشاف أخطاء مراقبة Azure المحسنة لـ SAP وإصلاحها
2233094 DB6: تطبيقات SAP على Azure التي تستخدم IBM Db2 لـ Linux وUNIX وWindows - معلومات إضافية
1612105 DB6: الأسئلة المتداولة حول Db2 مع HADR
الوثائق
SAP Community Wiki: يحتوي على جميع ملاحظات SAP المطلوبة لنظام التشغيل Linux.
تخطيط وتنفيذ أجهزة Azure الظاهرية لـSAP على Linux دليل
توزيع Azure Virtual Machines لـ SAP على Linux (هذه المقالة)
نشر نظام إدارة قواعد بيانات الأجهزة الظاهرية Azure (DBMS) لـSAP على Linux دليل
قائمة التحقق من التخطيط والتوزيع لحمل عمل SAP على Azure
أدلة أفضل الممارسات لـSUSE Linux Enterprise Server for SAP Apps 12 SP4
SUSE Linux Enterprise High Availability Extension 12 SP4
نشر نظام إدارة قواعد البيانات للأجهزة الظاهرية لـ IBM Db2 Azure لـ SAP workload
IBM Db2 HADR 11.1
IBM Db2 HADR R 10.5

نظرة عامة

لتحقيق قابلية وصول عالية، يتم تثبيت IBM Db2 LUW مع HADR على جهازين ظاهريين على الأقل من Azure، يتم نشرهما في مجموعة مقياس جهاز ظاهري مع تزامن مرن عبر مناطق التوفر أو في مجموعة توفر.

تعرض الرسومات التالية إعداداً لجهازي Azure ظاهريين لخادم قاعدة البيانات. يحتوي كل جهاز Azure ظاهري لخادم قاعدة البيانات على وحدة تخزين خاصة به مرفقة وقيد التشغيل. في HADR، يكون لمثيل قاعدة بيانات واحد في أحد الأجهزة الظاهرية لـAzure دور المثيل الأساسي. كل العملاء يتم توصيلهم بهذا المثيل الأساسي. تستمر كافة التغييرات في معاملات قاعدة البيانات محلياً في سجل معاملات Db2. مع استمرار سجلات سجل المعاملات محليًا، يتم نقل السجلات عبر TCP/IP إلى مثيل قاعدة البيانات على خادم قاعدة البيانات الثاني أو خادم الاستعداد أو مثيل الاستعداد. يقوم مثيل الاستعداد بتحديث قاعدة البيانات المحلية عن طريق إعادة توجيه سجلات سجل العمليات المنقولة. وبهذه الطريقة، يتم الاحتفاظ بخادم الاستعداد متزامناً مع الخادم الأساسي.

HADR ليست إلا وظيفة النسخ المتماثل. ليس لديها كشف للفشل ولا إمكانيات الاستحواذ التلقائي أو تجاوز الفشل. يجب بدء عملية الاستيلاء أو النقل إلى خادم الاستعداد يدوياً بواسطة مسؤول قاعدة بيانات. لتحقيق الاستحواذ التلقائي والكشف عن الفشل، يمكنك استخدام ميزة تجميع Linux Pacemaker. تراقب Pacemaker مثيلي خادم قاعدة البيانات. عند تعطل مثيل خادم قاعدة البيانات الأساسي، يبدأ Pacemaker عملية استحواذ HADR تلقائية بواسطة خادم الاستعداد. تضمن Pacemaker أيضًا تعيين عنوان IP الظاهري إلى الخادم الأساسي الجديد.

نظرة عامة على قابلية الوصول العالية لـ IBM Db2

لجعل خوادم تطبيقات SAP متصلة بقاعدة البيانات الأساسية، تحتاج إلى اسم مضيف افتراضي وعنوان IP افتراضي. بعد تجاوز الفشل، تتصل خوادم تطبيق SAP بمثيل قاعدة البيانات الأساسي الجديد. في بيئة Azure، يلزم وجود موازن تحميل Azure لاستخدام عنوان IP افتراضي بالطريقة المطلوبة لـ HADR من IBM Db2.

لمساعدتك في الفهم الكامل لكيفية تناسب IBM Db2 LUW مع HADR وPacemaker مع إعداد نظام SAP متوفر بشكل كبير، تقدم الصورة التالية نظرة عامة على إعداد متاح للغاية لنظام SAP استنادًا إلى قاعدة بيانات IBM Db2. تغطي هذه المقالة IBM Db2 فقط، ولكنها توفر مراجع لمقالات أخرى حول كيفية إعداد مكونات أخرى لنظام SAP.

نظرة عامة على البيئة الكاملة لقابلية الوصول العالية لـ IBM DB2

نظرة عامة رفيعة المستوى على الخطوات المطلوبة

لتوزيع تكوين IBM Db2، تحتاج إلى اتباع الخطوات التالية:

  • تخطيط بيئتك.
  • نشر الأجهزة الظاهرية.
  • تحديث SUSE Linux وتكوين أنظمة الملفات.
  • تثبيت Pacemaker وتكوينه.
  • قم بتثبيت NFS عالي التوافر.
  • قم بتثبيت ASCS/ERS على نظام مجموعة منفصل.
  • قم بتثبيت قاعدة بيانات IBM Db2 باستخدام خيار التوزيع/قابلية الوصول العالية (SWPM).
  • قم بتثبيت وإنشاء عقدة قاعدة بيانات ثانوية ومثيل، وتكوين HADR.
  • تأكد من عمل HADR.
  • قم بتطبيق تكوين Pacemaker للتحكم في IBM Db2.
  • تكوين موازنة التحميل .Azure
  • قم بتثبيت خوادم التطبيقات الأساسية والحوارية.
  • تحقق من تكوين خوادم تطبيقات SAP وقم بمواءمته.
  • إجراء اختبارات تجاوز الفشل والاستحواذ.

التخطيط للبنية الأساسية لـ Azure لاستضافة IBM Db2 LUW باستخدام HADR

أكمل عملية التخطيط قبل تنفيذ التوزيع. يبني التخطيط الأساس لتوزيع تكوين Db2 باستخدام HADR في Azure. يتم سرد العناصر الرئيسية التي يجب أن تكون جزءًا من التخطيط لـ IMB Db2 LUW (جزء قاعدة البيانات من بيئة SAP) في الجدول التالي:

الموضوع وصف قصير
تعريف مجموعات موارد Azure مجموعات الموارد حيث تقوم بنشر الجهاز الظاهري والشبكة الظاهرية وموازن تحميل Azure والموارد الأخرى. يمكن أن تكون موجودة أو جديدة.
تعريف الشبكة الظاهرية / الشبكة الفرعية حيث يتم توزيع الأجهزة الظاهرية لـIBM Db2 وموازن تحميل Azure. يمكن أن تكون موجودة أو تم إنشاؤها حديثًا.
الأجهزة الظاهرية التي تستضيف IBM Db2 LUW حجم الجهاز الظاهري، والتخزين، والشبكات، وعنوان IP.
اسم المضيف الظاهري وعنوان IP الظاهري لقاعدة بيانات IBM Db2 عنوان IP الظاهري أو اسم المضيف المستخدم للاتصال بخوادم تطبيقات SAP. db-virt-hostname, db-virt-ip.
سياج Azure سياج Azure أو سياج SBD (موصى به للغاية). طريقة لتجنب حالات انقسام الدماغ.
SBD VM SBD حجم الجهاز الظاهري والتخزين والشبكة.
موازن تحميل Azure استخدام منفذ الفحص القياسي (الموصى به) لقاعدة بيانات Db2 (توصيتنا 62500) منفذ الفحص.
تحليل الاسم كيفية عمل تحليل الاسم في البيئة. يوصى بشدة بخدمة DNS. يمكن استخدام ملف المضيفين المحليين.

لمزيد من المعلومات حول جهاز تنظيم ضربات القلب Linux في Azure، راجع إعداد Pacemaker على SUSE Linux Enterprise Server في Azure.

هام

بالنسبة إلى الإصدار 11.5.6 الخاص بـ Db2 والإصدارات الأحدث، نوصي بشدة بالحل المتكامل باستخدام Pacemaker من شركة IBM.

النشر على SUSE Linux

يتم تضمين عامل المورد لـIBM Db2 LUW في SUSE Linux Enterprise Server لتطبيقات SAP. بالنسبة للإعداد الموضح في هذا المستند، يجب عليك استخدام SUSE Linux Server لتطبيقات SAP. يحتوي Azure Marketplace على صورة لـSUSE Enterprise Server لـSAP Applications 12 يمكنك استخدامها لتوزيع أجهزة Azure الظاهرية الجديدة. كن على دراية بنماذج الدعم أو الخدمة المختلفة التي تقدمها SUSE من خلال Azure Marketplace عند اختيار صورة VM في Azure VM Marketplace.

المضيفون: تحديثات DNS

قم بعمل قائمة بجميع أسماء المضيفين، بما في ذلك أسماء المضيفين الظاهريين، وقم بتحديث خوادم DNS لتمكين عنوان IP المناسب من تحليل اسم المضيف. إذا لم يكن خادم DNS موجودًا أو لم تتمكن من تحديث إدخالات DNS وإنشائها، فستحتاج إلى استخدام ملفات المضيف المحلي للأجهزة الظاهرية الفردية المشاركة في هذا السيناريو. إذا كنت تستخدم إدخالات ملفات المضيف، فتأكد من تطبيق الإدخالات على جميع الأجهزة الظاهرية في بيئة نظام SAP. ومع ذلك، نوصي باستخدام DNS الخاص بك الذي يمتد بشكل مثالي إلى Azure

النشر بشكل يدوي

تأكد من أن نظام التشغيل المحدد مدعوم من قبل IBM/SAP لـ IBM Db2 LUW. تتوفر قائمة إصدارات نظام التشغيل المدعومة لإصدارات أجهزة Azure الظاهرية وDb2 في ملاحظة SAP رقم 1928533. تتوفر قائمة إصدارات نظام التشغيل حسب إصدار Db2 الفردي في مصفوفة توفر منتج SAP. نوصي بشدة بحد أدنى من SLES 12 SP4 بسبب تحسينات الأداء المتعلقة بـAzure في هذا الإصدار أو الإصدارات الأحدث من SUSE Linux.

  1. إنشاء مجموعة موارد أو تحديدها.
  2. إنشاء شبكة ظاهرية وشبكة فرعية أو تحديدهما.
  3. اختر نوع نشر مناسب لأجهزة SAP الظاهرية. عادة ما يتم تعيين مقياس الجهاز الظاهري مع تزامن مرن.
  4. قم بإنشاء جهاز ظاهري 1.
    1. استخدم SLES لصورة SAP في Azure Marketplace.
    2. حدد مجموعة التحجيم أو منطقة التوفر أو مجموعة التوفر التي تم إنشاؤها في الخطوة 3.
  5. قم بإنشاء جهاز ظاهري 2.
    1. استخدم SLES لصورة SAP في Azure Marketplace.
    2. حدد مجموعة التحجيم أو منطقة التوفر أو مجموعة التوفر التي تم إنشاؤها في الخطوة 3 (ليست نفس المنطقة كما في الخطوة 4).
  6. أضف أقراص البيانات إلى الأجهزة الظاهرية، ثم تحقق من توصية إعداد نظام الملفات في المقالة توزيع نظام إدارة قواعد البيانات للأجهزة الظاهرية لـ IBM Db2 Azure لحمل عمل SAP.

تثبيت IBM Db2 LUW وبيئة SAP

قبل البدء في تثبيت بيئة SAP استنادًا إلى IBM Db2 LUW، راجع الوثائق التالية:

  • وثائق Azure
  • وثائق SAP
  • وثائق IBM

يتم توفير روابط لهذه الوثائق في القسم التمهيدي من المقالة.

تحقق من أدلة تثبيت SAP حول تثبيت التطبيقات المستندة لـ NetWeaver على IBM Db2 LUW.

يمكنك العثور على الأدلة على مدخل تعليمات SAP عن طريق استخدام مستكشف دليل تثبيت SAP.

يمكنك تقليل عدد الأدلة المعروضة في المدخل من خلال تعيين عوامل التصفية التالية:

  • أريد أن أقوم بـ: "تثبيت نظام جديد"
  • قاعدة البيانات الخاصة بي: "IBM Db2 لنظام التشغيل Linux وUnix وWindows"
  • عوامل تصفية إضافية لإصدارات SAP NetWeaver، أو تكوين المكدس، أو نظام التشغيل

تلميحات التثبيت لإعداد IBM Db2 LUW باستخدام HADR

لإعداد مثيل قاعدة بيانات IBM Db2 LUW الأساسي:

  • استخدم خيار قابلية الوصول العالية أو الخيار الموزع.
  • قم بتثبيت مثيل SAP ASCS/ERS وقاعدة البيانات.
  • أخذ نسخة احتياطية من قاعدة البيانات المثبتة حديثاً.

هام

اكتب "منفذ اتصال قاعدة البيانات" الذي تم تعيينه أثناء التثبيت. يجب أن يكون نفس رقم المنفذ لكلا مثيلي قاعدة البيانات تعريف SAP SWPM Port

لإعداد خادم قاعدة بيانات الاستعداد باستخدام إجراء نسخ النظام المتجانس SAP تنفيذ الخطوات التالية:

  1. حدد خيار نسخ النظامالأنظمة> الهدف>موزعة>مثيل قاعدة البيانات.

  2. كطريقة نسخ، حدد نظام متجانس، بحيث يمكنك استخدام النسخ الاحتياطي لاستعادة نسخة احتياطية على مثيل خادم الاستعداد.

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

  4. قم بإعداد HADR لـIBM Db2.

    إشعار

    للتثبيت والتكوين الخاص بـ Azure وPacemaker: في أثناء إجراء التثبيت من خلال SAP Software Provisioning Manager، هناك سؤال صريح حول قابلية الوصول العالية لـ IBM Db2 LUW:

    • لا تحدد IBM Db2 pureScale.
    • لا تحدد تثبيت IBM Tivoli System Automation للأنظمة الأساسية المتعددة.
    • لا تحدد إنشاء ملفات تكوين نظام المجموعة.

عند استخدام جهاز SBD لـLinux Pacemaker، قم بتعيين معلمات DB2 HADR التالية:

  • مدة نافذة نظير HADR (بالثواني) (HADR_PEER_WINDOW) = 300
  • قيمة مهلة HADR (HADR_TIMEOUT) = 60

عند استخدام عامل إنشاء حد لـ Azure Pacemaker، قم بتعيين المعلمات التالية:

  • مدة نافذة نظير HADR (بالثواني) (HADR_PEER_WINDOW) = 900
  • قيمة مهلة HADR (HADR_TIMEOUT) = 60

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

هام

خاص بـIBM Db2 مع تكوين HADR مع بدء التشغيل العادي: يجب أن يكون مثيل قاعدة البيانات الثانوي أو الاحتياطي قيد التشغيل قبل أن تتمكن من بدء تشغيل مثيل قاعدة البيانات الأساسي.

لأغراض العرض التوضيحي والإجراءات الموضحة في هذه المقالة، قاعدة البيانات SID هي PTR.

IBM Db2 HADR الاختيار

بعد تكوين HADR والحالة هي PEER وCONNECTED على العقد الأساسية وعقد الاستعداد، قم بإجراء الفحص التالي:

Execute command as db2<sid> db2pd -hadr -db <SID>

#Primary output:
# Database Member 0 -- Database PTR -- Active -- Up 1 days 01:51:38 -- Date 2019-02-06-15.35.28.505451
# 
#                             HADR_ROLE = PRIMARY
#                           REPLAY_TYPE = PHYSICAL
#                         HADR_SYNCMODE = NEARSYNC
#                            STANDBY_ID = 1
#                         LOG_STREAM_ID = 0
#                            HADR_STATE = PEER
#                            HADR_FLAGS = TCP_PROTOCOL
#                   PRIMARY_MEMBER_HOST = azibmdb02
#                      PRIMARY_INSTANCE = db2ptr
#                        PRIMARY_MEMBER = 0
#                   STANDBY_MEMBER_HOST = azibmdb01
#                      STANDBY_INSTANCE = db2ptr
#                        STANDBY_MEMBER = 0
#                   HADR_CONNECT_STATUS = CONNECTED
#              HADR_CONNECT_STATUS_TIME = 02/05/2019 13:51:47.170561 (1549374707)
#           HEARTBEAT_INTERVAL(seconds) = 15
#                      HEARTBEAT_MISSED = 0
#                    HEARTBEAT_EXPECTED = 6137
#                 HADR_TIMEOUT(seconds) = 60
#         TIME_SINCE_LAST_RECV(seconds) = 13
#              PEER_WAIT_LIMIT(seconds) = 0
#            LOG_HADR_WAIT_CUR(seconds) = 0.000
#     LOG_HADR_WAIT_RECENT_AVG(seconds) = 0.000025
#    LOG_HADR_WAIT_ACCUMULATED(seconds) = 434.595
#                   LOG_HADR_WAIT_COUNT = 223713
# SOCK_SEND_BUF_REQUESTED,ACTUAL(bytes) = 0, 46080
# SOCK_RECV_BUF_REQUESTED,ACTUAL(bytes) = 0, 374400
#             PRIMARY_LOG_FILE,PAGE,POS = S0000280.LOG, 15571, 27902548040
#             STANDBY_LOG_FILE,PAGE,POS = S0000280.LOG, 15571, 27902548040
#                   HADR_LOG_GAP(bytes) = 0
#      STANDBY_REPLAY_LOG_FILE,PAGE,POS = S0000280.LOG, 15571, 27902548040
#        STANDBY_RECV_REPLAY_GAP(bytes) = 0
#                      PRIMARY_LOG_TIME = 02/06/2019 15:34:39.000000 (1549467279)
#                      STANDBY_LOG_TIME = 02/06/2019 15:34:39.000000 (1549467279)
#               STANDBY_REPLAY_LOG_TIME = 02/06/2019 15:34:39.000000 (1549467279)
#          STANDBY_RECV_BUF_SIZE(pages) = 2048
#              STANDBY_RECV_BUF_PERCENT = 0
#            STANDBY_SPOOL_LIMIT(pages) = 0
#                 STANDBY_SPOOL_PERCENT = NULL
#                    STANDBY_ERROR_TIME = NULL
#                  PEER_WINDOW(seconds) = 300
#                       PEER_WINDOW_END = 02/06/2019 15:40:25.000000 (1549467625)
#              READS_ON_STANDBY_ENABLED = N

#Secondary output:
# Database Member 0 -- Database PTR -- Standby -- Up 1 days 01:46:43 -- Date 2019-02-06-15.38.25.644168
# 
#                             HADR_ROLE = STANDBY
#                           REPLAY_TYPE = PHYSICAL
#                         HADR_SYNCMODE = NEARSYNC
#                            STANDBY_ID = 0
#                         LOG_STREAM_ID = 0
#                            HADR_STATE = PEER
#                            HADR_FLAGS = TCP_PROTOCOL
#                   PRIMARY_MEMBER_HOST = azibmdb02
#                      PRIMARY_INSTANCE = db2ptr
#                        PRIMARY_MEMBER = 0
#                   STANDBY_MEMBER_HOST = azibmdb01
#                      STANDBY_INSTANCE = db2ptr
#                        STANDBY_MEMBER = 0
#                   HADR_CONNECT_STATUS = CONNECTED
#              HADR_CONNECT_STATUS_TIME = 02/05/2019 13:51:47.205067 (1549374707)
#           HEARTBEAT_INTERVAL(seconds) = 15
#                      HEARTBEAT_MISSED = 0
#                    HEARTBEAT_EXPECTED = 6186
#                 HADR_TIMEOUT(seconds) = 60
#         TIME_SINCE_LAST_RECV(seconds) = 5
#              PEER_WAIT_LIMIT(seconds) = 0
#            LOG_HADR_WAIT_CUR(seconds) = 0.000
#     LOG_HADR_WAIT_RECENT_AVG(seconds) = 0.000023
#    LOG_HADR_WAIT_ACCUMULATED(seconds) = 434.595
#                   LOG_HADR_WAIT_COUNT = 223725
# SOCK_SEND_BUF_REQUESTED,ACTUAL(bytes) = 0, 46080
# SOCK_RECV_BUF_REQUESTED,ACTUAL(bytes) = 0, 372480
#             PRIMARY_LOG_FILE,PAGE,POS = S0000280.LOG, 15574, 27902562173
#             STANDBY_LOG_FILE,PAGE,POS = S0000280.LOG, 15574, 27902562173
#                   HADR_LOG_GAP(bytes) = 0
#      STANDBY_REPLAY_LOG_FILE,PAGE,POS = S0000280.LOG, 15574, 27902562173
#        STANDBY_RECV_REPLAY_GAP(bytes) = 155
#                      PRIMARY_LOG_TIME = 02/06/2019 15:37:34.000000 (1549467454)
#                      STANDBY_LOG_TIME = 02/06/2019 15:37:34.000000 (1549467454)
#               STANDBY_REPLAY_LOG_TIME = 02/06/2019 15:37:34.000000 (1549467454)
#          STANDBY_RECV_BUF_SIZE(pages) = 2048
#              STANDBY_RECV_BUF_PERCENT = 0
#            STANDBY_SPOOL_LIMIT(pages) = 0
#                 STANDBY_SPOOL_PERCENT = NULL
#                    STANDBY_ERROR_TIME = NULL
#                  PEER_WINDOW(seconds) = 300
#                       PEER_WINDOW_END = 02/06/2019 15:43:19.000000 (1549467799)
#              READS_ON_STANDBY_ENABLED = N

تكوين Azure Load Balancer

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

اتبع الخطوات الواردة في إنشاء موازن تحميل لإعداد موازن تحميل قياسي لنظام SAP عالي التوفر باستخدام مدخل Microsoft Azure. أثناء إعداد موازن التحميل، ضع في اعتبارك النقاط التالية:

  1. تكوين IP للواجهة الأمامية: إنشاء عنوان IP للواجهة الأمامية. حدد نفس اسم الشبكة الظاهرية والشبكة الفرعية مثل الأجهزة الظاهرية لقاعدة البيانات.
  2. تجمع الواجهة الخلفية: إنشاء تجمع خلفي وإضافة أجهزة ظاهرية لقاعدة البيانات.
  3. القواعد الواردة: إنشاء قاعدة موازنة التحميل. اتبع نفس الخطوات لكل من قواعد موازنة التحميل.
    • عنوان IP للواجهة الأمامية: حدد عنوان IP للواجهة الأمامية.
    • تجمع الواجهة الخلفية: حدد تجمعا خلفيا.
    • منافذ قابلية الوصول العالية: حدد هذا الخيار.
    • البروتوكول: حدد TCP.
    • Health Probe: إنشاء مسبار صحي بالتفاصيل التالية:
      • البروتوكول: حدد TCP.
      • المنفذ: على سبيل المثال، 625<instance-no.>.
      • الفاصل الزمني: أدخل 5.
      • عتبة الفحص: أدخل 2.
    • مهلة الخمول (بالدقائق): أدخل 30.
    • تمكين IP العائم: حدد هذا الخيار.

إشعار

لا يتم احترام خاصية numberOfProbesتكوين فحص السلامة ، والمعروفة باسم عتبة غير سليمة في المدخل. للتحكم في عدد التحقيقات المتتالية الناجحة أو الفاشلة، قم بتعيين الخاصية probeThreshold إلى 2. لا يمكن حاليا تعيين هذه الخاصية باستخدام مدخل Microsoft Azure، لذا استخدم إما Azure CLI أو أمر PowerShell .

إشعار

عندما يتم وضع الأجهزة الظاهرية التي لا تحتوي على عناوين IP عامة في تجمع الواجهة الخلفية لمثيل داخلي (لا يوجد عنوان IP عام) لموازن تحميل Azure القياسي، لا يوجد اتصال بالإنترنت الصادر ما لم يتم إجراء المزيد من التكوين للسماح بالتوجه إلى نقاط النهاية العامة. لمزيد من المعلومات حول كيفية تحقيق الاتصال الصادر، راجع اتصال نقطة النهاية العامة للأجهزة الظاهرية باستخدام Azure Standard Load Balancer في سيناريوهات قابلية الوصول العالية ل SAP.

هام

لا تمكِّن طوابع TCP الزمنية على أجهزة Azure الظاهرية خلف Azure Load Balancer. قد يؤدي تمكين الطوابع الزمنية TCP إلى فشل فحوصات السلامة. عين المعلمة net.ipv4.tcp_timestamps على 0. لمزيد من المعلومات، يُرجى الرجوع إلى Load Balancer health probes.

إنشاء نظام مجموعة Pacemaker

لإنشاء مجموعة أساسية من Pacemaker لخادم IBM Db2 هذا، راجع إعداد Pacemaker على خادم SUSE Linux Enterprise Server في Azure.

تكوين Db2 Pacemaker

عند استخدام Pacemaker لتجاوز الفشل التلقائي في حالة فشل العقدة، تحتاج إلى تكوين مثيلات Db2 وPacemaker وفقًا لذلك. يصف هذا القسم هذا النوع من التكوين.

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

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

[A]المتطلبات الأساسية لتكوين Pacemaker:

  • قم بإيقاف تشغيل كل من خوادم قاعدة البيانات باستخدام db2sid< المستخدم باستخدام db2stop>.
  • تغيير بيئة shell لمستخدم db2sid<> إلى /bin/ksh. نُوصي باستخدام أداة Yast.

تكوين جهاز Pacemaker

هام

كشفت الاختبارات الأخيرة عن حالات، حيث تتوقف netcat عن الاستجابة للطلبات بسبب تراكم الأعمال المتراكمة ومحدوديتها في التعامل مع اتصال واحد فقط. يتوقف مورد netcat عن الاستماع إلى طلبات موازن تحميل Azure ويصبح عنوان IP الحُر غير متوفر. بالنسبة إلى أنظمة مجموعات Pacemaker الحالية، أوصينا في الماضي بإحلال netcat محل socat. نوصي حالياً باستخدام عامل موارد azure-lb، وهو جزء من عوامل موارد الحزمة، مع متطلبات إصدار الحزمة التالية:

  • بالنسبة لـ SLES 12 SP4/SP5، يجب أن يكون الإصدار على الأقل resource-agents-4.3.018.a7fb5035-3.30.1.
  • بالنسبة إلى SLES 15/15 SP1، يجب أن يكون الإصدار على الأقل resource-agents-4.3.0184.6ee15eb2-4.13.1.

لاحظ أن التغيير سيتطلب وقتًا قصيرًا.
بالنسبة إلى أنظمة مجموعات Pacemaker الموجودة، إذا تم تغيير التكوين بالفعل لاستخدام socat كما هو موضح في Azure Load-Balancer Detection Hardening، فلا يلزم التبديل فوراً إلى عامل مورد azure-lb.

  1. [1] تكوين جهاز تنظيم ضربات القلب الخاص ب IBM Db2 HADR:

    # Put Pacemaker into maintenance mode
sudo crm configure property maintenance-mode=true

  2. [1] إنشاء موارد IBM Db2:

    # Replace **bold strings** with your instance name db2sid, database SID, and virtual IP address/Azure Load Balancer.
sudo crm configure primitive rsc_Db2_db2ptr_PTR db2 \
        params instance="db2ptr" dblist="PTR" \
        op start interval="0" timeout="130" \
        op stop interval="0" timeout="120" \
        op promote interval="0" timeout="120" \
        op demote interval="0" timeout="120" \
        op monitor interval="30" timeout="60" \
        op monitor interval="31" role="Master" timeout="60"

# Configure virtual IP - same as Azure Load Balancer IP
sudo crm configure primitive rsc_ip_db2ptr_PTR IPaddr2 \
        op monitor interval="10s" timeout="20s" \
        params ip="10.100.0.10"

# Configure probe port for Azure load Balancer
sudo crm configure primitive rsc_nc_db2ptr_PTR azure-lb port=62500 \
        op monitor timeout=20s interval=10

sudo crm configure group g_ip_db2ptr_PTR rsc_ip_db2ptr_PTR rsc_nc_db2ptr_PTR

sudo crm configure ms msl_Db2_db2ptr_PTR rsc_Db2_db2ptr_PTR \
        meta target-role="Started" notify="true"

sudo crm configure colocation col_db2_db2ptr_PTR inf: g_ip_db2ptr_PTR:Started msl_Db2_db2ptr_PTR:Master

sudo crm configure order ord_db2_ip_db2ptr_PTR inf: msl_Db2_db2ptr_PTR:promote g_ip_db2ptr_PTR:start

sudo crm configure rsc_defaults resource-stickiness=1000
sudo crm configure rsc_defaults migration-threshold=5000

  3. [1] بدء تشغيل موارد IBM Db2:

    ضع Pacemaker خارج وضع الصيانة.

    # Put Pacemaker out of maintenance-mode - that start IBM Db2
sudo crm configure property maintenance-mode=false

  4. [1]تأكد من أن حالة الكتلة صحيحة وبدء تشغيل كافة الموارد. لا يهم العقدة التي يتم تشغيل الموارد عليها.

    sudo crm status

# 2 nodes configured
# 5 resources configured

# Online: [ azibmdb01 azibmdb02 ]

# Full list of resources:

# stonith-sbd    (stonith:external/sbd): Started azibmdb02
# Resource Group: g_ip_db2ptr_PTR
#      rsc_ip_db2ptr_PTR  (ocf::heartbeat:IPaddr2):       Started azibmdb02
#      rsc_nc_db2ptr_PTR  (ocf::heartbeat:azure-lb):      Started azibmdb02
# Master/Slave Set: msl_Db2_db2ptr_PTR [rsc_Db2_db2ptr_PTR]
#      Masters: [ azibmdb02 ]
#      Slaves: [ azibmdb01 ]

هام

يجب عليك إدارة مثيل Db2 المجمعة بواسطة Pacemaker باستخدام أدوات Pacemaker. إذا كنت تستخدم أوامر db2 مثل db2stop، يكتشف Pacemaker الإجراء كفشل في المورد. إذا كنت تجري صيانة، يمكنك وضع العقد أو الموارد في وضع الصيانة. يقوم Pacemaker بتعليق موارد المراقبة، ويمكنك بعد ذلك استخدام أوامر إدارة db2 العادية.

إجراء تغييرات على ملفات تعريف SAP لاستخدام IP الظاهري للاتصال

للاتصال بالمثيل الأساسي لتكوين HADR، تحتاج طبقة تطبيق SAP إلى استخدام عنوان IP الظاهري الذي قمت بتعريفه وتكوينه لموازن تحميل Azure. التغييرات التالية مطلوبة:

/sapmnt/<SID>/profile/DEFAULT.PFL

SAPDBHOST = db-virt-hostname
j2ee/dbhost = db-virt-hostname

/sapmnt/<SID>/global/db6/db2cli.ini

Hostname=db-virt-hostname

تثبيت خوادم التطبيقات الأساسية والحوارية

عند تثبيت خوادم التطبيقات الأساسية ومربع الحوار مقابل تكوين Db2 HADR، استخدم اسم المضيف الظاهري الذي اخترته للتكوين.

إذا قمت بإجراء التثبيت قبل إنشاء تكوين Db2 HADR، فقم بإجراء التغييرات كما هو موضح في القسم السابق وكما يلي لمكدسات SAP Java.

التحقق من عنوان URL لـ JDBC لأنظمة مكدس ABAP+Java أو Java

استخدم أداة تكوين J2EE للتحقق من عنوان URL لـ JDBC أو تحديثه. نظرًا لأن أداة J2EE Config هي أداة رسومية، يجب أن يكون لديك خادم X مثبتًا:

  1. سجل الدخول إلى خادم التطبيقات الأساسي لمثيل J2EE ونفذ:

    sudo /usr/sap/*SID*/*Instance*/j2ee/configtool/configtool.sh

  2. في الإطار الأيمن، اختر مخزن الأمان.

  3. في الإطار الأيمن، اختر المفتاح jdbc/pool/SAPSID</>url.

  4. تغيير اسم المضيف في عنوان URL JDBC إلى اسم المضيف الظاهري.

    jdbc:db2://db-virt-hostname:5912/TSP:deferPrepares=0

  5. حدد إضافة.

  6. لحفظ التغييرات، حدد رمز القرص في الجزء العلوي الأيمن.

  7. أغلق أداة التكوين.

  8. أعد تشغيل مثيل Java.

تكوين أرشفة السجل لإعداد HADR

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

يتم تنفيذ أرشفة السجل فقط بواسطة قاعدة البيانات الأساسية. إذا قمت بتغيير أدوار HADR لخوادم قاعدة البيانات أو في حالة حدوث فشل، تكون قاعدة البيانات الأساسية الجديدة مسؤولة عن أرشفة السجلات. إذا قمت بإعداد مواقع متعددة لأرشيف السجلات، فقد تتم أرشفة سجلاتك مرتين. في حالة اللحاق بالركب محليًا أو عن بعد، قد تضطر أيضًا إلى نسخ السجلات المؤرشفة يدوياً من الخادم الأساسي القديم إلى موقع السجل النشط للخادم الأساسي الجديد.

نوصي بتكوين مشاركة NFS شائعة حيث تتم كتابة السجلات من كلتا العقدتين. يجب أن تكون حصة NFS متاحة بشكل كبير.

يمكنك استخدام مشاركات NFS الحالية المتوفرة بشكل كبير لعمليات النقل أو دليل ملف التعريف. لمزيد من المعلومات، راجع:

اختبار إعداد نظام الكتل

يوضح هذا القسم كيفية اختبار إعداد Db2 HADR. يفترض كل اختبار أنك قمت بتسجيل الدخول كجذر مستخدم وأن IBM Db2 الأساسي يعمل على الجهاز الظاهري azibmdb01 .

يتم شرح الحالة الأولية لجميع حالات الاختبار هنا: (crm_mon -r أو حالة CRM)

  • حالة crm هي لقطة لحالة Pacemaker في وقت التنفيذ.
  • crm_mon -r هو الإخراج المستمر لحالة Pacemaker.
2 nodes configured
5 resources configured

Online: [ azibmdb01 azibmdb02 ]

Full list of resources:

stonith-sbd     (stonith:external/sbd): Started azibmdb02
Resource Group: g_ip_db2ptr_PTR
     rsc_ip_db2ptr_PTR  (ocf::heartbeat:IPaddr2):       Stopped
     rsc_nc_db2ptr_PTR  (ocf::heartbeat:azure-lb):      Stopped
Master/Slave Set: msl_Db2_db2ptr_PTR [rsc_Db2_db2ptr_PTR]
     rsc_Db2_db2ptr_PTR      (ocf::heartbeat:db2):   Promoting azibmdb01
     Slaves: [ azibmdb02 ]

يتم توثيق الحالة الأصلية في نظام SAP في «العملية DBACOCKPIT > التكوين > نظرة عامة»، كما هو موضح في الصورة التالية:

DBACockpit - قبل الترحيل

اختبار الاستحواذ لـ IBM Db2

هام

قبل بدء الاختبار، تأكد مما يلي:

  • لا يحتوي جهاز تنظيم ضربات القلب على أي إجراءات فاشلة (حالة CRM).

  • لا توجد قيود على الموقع (بقايا اختبار الترحيل.

  • مزامنة IBM Db2 HADR قيد العمل. التحقق مع المستخدم db2<sid>

    db2pd -hadr -db <DBSID>

ترحيل العقدة التي تقوم بتشغيل قاعدة بيانات Db2 الأساسية عن طريق تنفيذ الأمر التالي:

crm resource migrate msl_Db2_db2ptr_PTR azibmdb02

بعد الانتهاء من الترحيل، يبدو إخراج حالة crm كما يلي:

2 nodes configured
5 resources configured

Online: [ azibmdb01 azibmdb02 ]

Full list of resources:

stonith-sbd     (stonith:external/sbd): Started azibmdb02
Resource Group: g_ip_db2ptr_PTR
     rsc_ip_db2ptr_PTR  (ocf::heartbeat:IPaddr2):       Started azibmdb02
     rsc_nc_db2ptr_PTR  (ocf::heartbeat:azure-lb):      Started azibmdb02
Master/Slave Set: msl_Db2_db2ptr_PTR [rsc_Db2_db2ptr_PTR]
     Masters: [ azibmdb02 ]
     Slaves: [ azibmdb01 ]

يتم توثيق الحالة الأصلية في نظام SAP في «العملية DBACOCKPIT > التكوين > نظرة عامة»، كما هو موضح في الصورة التالية:

DBACockpit - بعد الترحيل

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

ترحيل المورد مرة أخرى إلى azibmdb01 ومسح قيود الموقع

crm resource migrate msl_Db2_db2ptr_PTR azibmdb01
crm resource clear msl_Db2_db2ptr_PTR
  • ترحيل موارد crm< res_name>< host>: ينشئ قيودًا على الموقع ويمكن أن يسبب مشكلات في الاستحواذ
  • res_name< مسح موارد >CRM: مسح قيود الموقع
  • res_name< تنظيف >مورد CRM: مسح كافة أخطاء المورد

اختبار SBD fencing

في هذه الحالة، نختبر سياج SBD، والذي نوصي به عند استخدام SUSE Linux.

azibmdb01:~ # ps -ef|grep sbd
root       2374      1  0 Feb05 ?        00:00:17 sbd: inquisitor
root       2378   2374  0 Feb05 ?        00:00:40 sbd: watcher: /dev/disk/by-id/scsi-36001405fbbaab35ee77412dacb77ae36 - slot: 0 - uuid: 27cad13a-0bce-4115-891f-43b22cfabe65
root       2379   2374  0 Feb05 ?        00:01:51 sbd: watcher: Pacemaker
root       2380   2374  0 Feb05 ?        00:00:18 sbd: watcher: Cluster

azibmdb01:~ # kill -9 2374

يجب إعادة تشغيل عقدة الكتلة azibmdb01 . سيتم نقل دور IBM Db2 الأساسي HADR إلى azibmdb02. عندما يعود azibmdb01 إلى الاتصال بالإنترنت، سينتقل مثيل Db2 في دور مثيل قاعدة بيانات ثانوي.

إذا لم تبدأ خدمة Pacemaker تلقائيًا في النسخة الأساسية السابقة التي أعيد تشغيلها، فتأكد من بدء تشغيلها يدويا بما يلي:

sudo service pacemaker start

اختبار الاستحواذ اليدوي

يمكنك اختبار استيلاء يدوي عن طريق إيقاف خدمة Pacemaker على عقدة azibmdb01:

service pacemaker stop

status on azibmdb02

2 nodes configured
5 resources configured

Online: [ azibmdb02 ]
OFFLINE: [ azibmdb01 ]

Full list of resources:

stonith-sbd     (stonith:external/sbd): Started azibmdb02
Resource Group: g_ip_db2ptr_PTR
     rsc_ip_db2ptr_PTR  (ocf::heartbeat:IPaddr2):       Started azibmdb02
     rsc_nc_db2ptr_PTR  (ocf::heartbeat:azure-lb):      Started azibmdb02
Master/Slave Set: msl_Db2_db2ptr_PTR [rsc_Db2_db2ptr_PTR]
     Masters: [ azibmdb02 ]
     Stopped: [ azibmdb01 ]

بعد تجاوز الفشل، يمكنك بدء تشغيل الخدمة مرة أخرى على azibmdb01.

service pacemaker start

إنهاء عملية Db2 على العقدة التي تقوم بتشغيل قاعدة البيانات الأساسية لـ HADR

#Kill main db2 process - db2sysc
azibmdb01:~ # ps -ef|grep db2s
db2ptr    34598  34596  8 14:21 ?        00:00:07 db2sysc 0

azibmdb01:~ # kill -9 34598

سيفشل مثيل Db2، وسيبلغ Pacemaker عن الحالة التالية:

2 nodes configured
5 resources configured

Online: [ azibmdb01 azibmdb02 ]

Full list of resources:

stonith-sbd    (stonith:external/sbd): Started azibmdb01
Resource Group: g_ip_db2ptr_PTR
     rsc_ip_db2ptr_PTR  (ocf::heartbeat:IPaddr2):       Stopped
     rsc_nc_db2ptr_PTR  (ocf::heartbeat:azure-lb):      Stopped
Master/Slave Set: msl_Db2_db2ptr_PTR [rsc_Db2_db2ptr_PTR]
     Slaves: [ azibmdb02 ]
     Stopped: [ azibmdb01 ]

Failed Actions:
* rsc_Db2_db2ptr_PTR_demote_0 on azibmdb01 'unknown error' (1): call=157, status=complete, exitreason='',
    last-rc-change='Tue Feb 12 14:28:19 2019', queued=40ms, exec=223ms

يعيد Pacemaker تشغيل مثيل قاعدة البيانات الأساسية Db2 على نفس العقدة، أو يفشل في العقدة التي تقوم بتشغيل مثيل قاعدة البيانات الثانوية ويتم الإبلاغ عن خطأ.

2 nodes configured
5 resources configured

Online: [ azibmdb01 azibmdb02 ]

Full list of resources:

stonith-sbd    (stonith:external/sbd): Started azibmdb01
Resource Group: g_ip_db2ptr_PTR
     rsc_ip_db2ptr_PTR  (ocf::heartbeat:IPaddr2):       Started azibmdb01
     rsc_nc_db2ptr_PTR  (ocf::heartbeat:azure-lb):      Started azibmdb01
Master/Slave Set: msl_Db2_db2ptr_PTR [rsc_Db2_db2ptr_PTR]
     Masters: [ azibmdb01 ]
     Slaves: [ azibmdb02 ]

Failed Actions:
* rsc_Db2_db2ptr_PTR_demote_0 on azibmdb01 'unknown error' (1): call=157, status=complete, exitreason='',
    last-rc-change='Tue Feb 12 14:28:19 2019', queued=40ms, exec=223ms

إنهاء عملية Db2 على العقدة التي تقوم بتشغيل مثيل قاعدة البيانات الثانوية

azibmdb02:~ # ps -ef|grep db2s
db2ptr    65250  65248  0 Feb11 ?        00:09:27 db2sysc 0

azibmdb02:~ # kill -9

تدخل العقدة في حالة فشل والإبلاغ عن خطأ

2 nodes configured
5 resources configured

Online: [ azibmdb01 azibmdb02 ]

Full list of resources:

stonith-sbd    (stonith:external/sbd): Started azibmdb01
Resource Group: g_ip_db2ptr_PTR
     rsc_ip_db2ptr_PTR  (ocf::heartbeat:IPaddr2):       Started azibmdb01
     rsc_nc_db2ptr_PTR  (ocf::heartbeat:azure-lb):      Started azibmdb01
Master/Slave Set: msl_Db2_db2ptr_PTR [rsc_Db2_db2ptr_PTR]
     rsc_Db2_db2ptr_PTR      (ocf::heartbeat:db2):   FAILED azibmdb02
     Masters: [ azibmdb01 ]

Failed Actions:
* rsc_Db2_db2ptr_PTR_monitor_30000 on azibmdb02 'not running' (7): call=144, status=complete, exitreason='',
last-rc-change='Tue Feb 12 14:36:59 2019', queued=0ms, exec=0ms

تتم إعادة تشغيل مثيل Db2 في الدور الثانوي الذي تم تعيينه من قبل.

2 nodes configured
5 resources configured

Online: [ azibmdb01 azibmdb02 ]

Full list of resources:

stonith-sbd     (stonith:external/sbd): Started azibmdb01
Resource Group: g_ip_db2ptr_PTR
     rsc_ip_db2ptr_PTR  (ocf::heartbeat:IPaddr2):       Started azibmdb01
     rsc_nc_db2ptr_PTR  (ocf::heartbeat:azure-lb):      Started azibmdb01
Master/Slave Set: msl_Db2_db2ptr_PTR [rsc_Db2_db2ptr_PTR]
     Masters: [ azibmdb01 ]
     Slaves: [ azibmdb02 ]

Failed Actions:
* rsc_Db2_db2ptr_PTR_monitor_30000 on azibmdb02 'not running' (7): call=144, status=complete, exitreason='',
    last-rc-change='Tue Feb 12 14:36:59 2019', queued=0ms, exec=0ms

إيقاف قاعدة البيانات عبر قوة db2stop على العقدة التي تقوم بتشغيل مثيل قاعدة البيانات الأساسية HADR

2 nodes configured
5 resources configured

Online: [ azibmdb01 azibmdb02 ]

Full list of resources:

stonith-sbd     (stonith:external/sbd): Started azibmdb01
Resource Group: g_ip_db2ptr_PTR
     rsc_ip_db2ptr_PTR  (ocf::heartbeat:IPaddr2):       Started azibmdb01
     rsc_nc_db2ptr_PTR  (ocf::heartbeat:azure-lb):      Started azibmdb01
Master/Slave Set: msl_Db2_db2ptr_PTR [rsc_Db2_db2ptr_PTR]
     Masters: [ azibmdb01 ]
     Slaves: [ azibmdb02 ]

كمستخدم db2sid< تنفيذ الأمر db2stop> القوة:

azibmdb01:~ # su - db2ptr
azibmdb01:db2ptr> db2stop force

تم اكتشاف الفشل

2 nodes configured
5 resources configured

Online: [ azibmdb01 azibmdb02 ]

Full list of resources:

stonith-sbd    (stonith:external/sbd): Started azibmdb01
Resource Group: g_ip_db2ptr_PTR
     rsc_ip_db2ptr_PTR  (ocf::heartbeat:IPaddr2):       Stopped
     rsc_nc_db2ptr_PTR  (ocf::heartbeat:azure-lb):      Stopped
Master/Slave Set: msl_Db2_db2ptr_PTR [rsc_Db2_db2ptr_PTR]
     rsc_Db2_db2ptr_PTR      (ocf::heartbeat:db2):   FAILED azibmdb01
     Slaves: [ azibmdb02 ]

Failed Actions:
* rsc_Db2_db2ptr_PTR_demote_0 on azibmdb01 'unknown error' (1): call=201, status=complete, exitreason='',
    last-rc-change='Tue Feb 12 14:45:25 2019', queued=1ms, exec=150ms

تمت ترقية مثيل قاعدة البيانات الثانوية Db2 HADR إلى الدور الأساسي.

nodes configured
5 resources configured

Online: [ azibmdb01 azibmdb02 ]

Full list of resources:

stonith-sbd     (stonith:external/sbd): Started azibmdb01
Resource Group: g_ip_db2ptr_PTR
     rsc_ip_db2ptr_PTR  (ocf::heartbeat:IPaddr2):       Started azibmdb02
     rsc_nc_db2ptr_PTR  (ocf::heartbeat:azure-lb):      Started azibmdb02
Master/Slave Set: msl_Db2_db2ptr_PTR [rsc_Db2_db2ptr_PTR]
     Masters: [ azibmdb02 ]
     Stopped: [ azibmdb01 ]

Failed Actions:
* rsc_Db2_db2ptr_PTR_start_0 on azibmdb01 'unknown error' (1): call=205, stat
us=complete, exitreason='',
    last-rc-change='Tue Feb 12 14:45:27 2019', queued=0ms, exec=865ms

تعطل الجهاز الظاهري مع إعادة التشغيل على العقدة التي تقوم بتشغيل مثيل قاعدة البيانات الأساسية HADR

#Linux kernel panic - with OS restart
azibmdb01:~ # echo b > /proc/sysrq-trigger

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

nodes configured
5 resources configured

Online: [ azibmdb01 azibmdb02 ]

Full list of resources:

stonith-sbd     (stonith:external/sbd): Started azibmdb02
Resource Group: g_ip_db2ptr_PTR
     rsc_ip_db2ptr_PTR  (ocf::heartbeat:IPaddr2):       Started azibmdb01
     rsc_nc_db2ptr_PTR  (ocf::heartbeat:azure-lb):      Started azibmdb01
Master/Slave Set: msl_Db2_db2ptr_PTR [rsc_Db2_db2ptr_PTR]
     Masters: [ azibmdb01 ]
     Slaves: [ azibmdb02 ]

تعطل الجهاز الظاهري الذي يقوم بتشغيل مثيل قاعدة البيانات الأساسية HADR مع "إيقاف"

#Linux kernel panic - halts OS
azibmdb01:~ # echo b > /proc/sysrq-trigger

في مثل هذه الحالة، يكتشف Pacemaker أن العقدة التي تقوم بتشغيل مثيل قاعدة البيانات الأساسية لا تستجيب.

2 nodes configured
5 resources configured

Node azibmdb01: UNCLEAN (online)
Online: [ azibmdb02 ]

Full list of resources:

stonith-sbd     (stonith:external/sbd): Started azibmdb02
Resource Group: g_ip_db2ptr_PTR
     rsc_ip_db2ptr_PTR  (ocf::heartbeat:IPaddr2):       Started azibmdb01
     rsc_nc_db2ptr_PTR  (ocf::heartbeat:azure-lb):      Started azibmdb01
Master/Slave Set: msl_Db2_db2ptr_PTR [rsc_Db2_db2ptr_PTR]
     Masters: [ azibmdb01 ]
     Slaves: [ azibmdb02 ]

تتمثل الخطوة التالية في التحقق من وجود حالة دماغية منقسمة. بعد أن تحدد العقدة الباقية أن العقدة التي قامت بتشغيل مثيل قاعدة البيانات الأساسي آخر مرة معطلة، يتم تنفيذ تجاوز فشل الموارد.

2 nodes configured
5 resources configured

Online: [ azibmdb02 ]
OFFLINE: [ azibmdb01 ]

Full list of resources:

stonith-sbd     (stonith:external/sbd): Started azibmdb02
Resource Group: g_ip_db2ptr_PTR
     rsc_ip_db2ptr_PTR  (ocf::heartbeat:IPaddr2):       Started azibmdb02
     rsc_nc_db2ptr_PTR  (ocf::heartbeat:azure-lb):      Started azibmdb02
Master/Slave Set: msl_Db2_db2ptr_PTR [rsc_Db2_db2ptr_PTR]
     Masters: [ azibmdb02 ]
     Stopped: [ azibmdb01 ]

في حالة "إيقاف" العقدة، يجب إعادة تشغيل العقدة الفاشلة عبر أدوات إدارة Azure (في مدخل Microsoft Azure أو PowerShell أو Azure CLI). بعد عودة العقدة الفاشلة إلى الاتصال بالإنترنت، يبدأ تشغيل مثيل Db2 في الدور الثانوي.

2 nodes configured
5 resources configured

Online: [ azibmdb01 azibmdb02 ]

Full list of resources:

stonith-sbd     (stonith:external/sbd): Started azibmdb02
 Resource Group: g_ip_db2ptr_PTR
     rsc_ip_db2ptr_PTR  (ocf::heartbeat:IPaddr2):       Started azibmdb02
     rsc_nc_db2ptr_PTR  (ocf::heartbeat:azure-lb):      Started azibmdb02
 Master/Slave Set: msl_Db2_db2ptr_PTR [rsc_Db2_db2ptr_PTR]
     Masters: [ azibmdb02 ]
     Slaves: [ azibmdb01 ]

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