قابلية الوصول العالية لـ IBM Db2 LUW على أجهزة Azure الظاهرية على خادم Red Hat Enterprise Linux

يتكون 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
2002167	Red Hat Enterprise Linux 7.x: التثبيت والترقية
2694118	المكون الإضافي لـ Red Hat Enterprise Linux HA Add-On على Azure
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
نظرة عامة على المكون الإضافي لقابلية الوصول العالية لـ Red Hat Enterprise Linux 7
إدارة المكون الإضافي لقابلية الوصول العالية
الوصول العالي Add-On المرجع
نهج الدعم لمجموعات التوفر العالي RHEL - الأجهزة الظاهرية لـMicrosoft Azure كأعضاء في المجموعة
تثبيت وتكوين Red Hat Enterprise Linux 7.4 (والإصدار الأحدث) High-Availability Cluster على Microsoft Azure
نشر نظام إدارة قواعد البيانات للأجهزة الظاهرية لـ IBM Db2 Azure لـ SAP workload
IBM Db2 HADR 11.1
IBM Db2 HADR 10.5
نهج الدعم لأنظمة مجموعات قابلية الوصول العالية لـ RHEL - إدارة IBM Db2 لنظام التشغيل Linux وUnix وWindows في نظام مجموعة

نظرة عامة

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

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

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

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

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

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

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

• تخطيط بيئتك.
• نشر الأجهزة الظاهرية.
• تحديث RHEL Linux وتكوين أنظمة الملفات.
• تثبيت Pacemaker وتكوينه.
• إعداد نظام مجموعة glusterfs أو Azure NetApp Files
• قم بتثبيت 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	استخدام منفذ الفحص القياسي (الموصى به) لقاعدة بيانات Db2 (توصيتنا 62500) منفذ الفحص.
تحليل الاسم	كيفية عمل تحليل الاسم في البيئة. يوصى بشدة بخدمة DNS. يمكن استخدام ملف المضيفين المحليين.

لمزيد من المعلومات حول Linux Pacemaker في Azure، راجع إعداد Pacemaker على Red Hat Enterprise Linux في Azure.

هام

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

• حل متكامل باستخدام Pacemaker
• تكوينات بديلة أو إضافية متوفرة في Microsoft Azure

التوزيع على Red Hat Enterprise Linux

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

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

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

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

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

1. إنشاء مجموعة موارد أو تحديدها.
2. إنشاء شبكة ظاهرية وشبكة فرعية أو تحديدهما.
3. اختر نوع نشر مناسب لأجهزة SAP الظاهرية. عادة ما يتم تعيين مقياس الجهاز الظاهري مع تزامن مرن.
4. قم بإنشاء جهاز ظاهري 1.
   1. استخدم Red Hat Enterprise Linux لصورة SAP في Azure Marketplace.
   2. حدد مجموعة التحجيم أو منطقة التوفر أو مجموعة التوفر التي تم إنشاؤها في الخطوة 3.
5. قم بإنشاء جهاز ظاهري 2.
   1. استخدم Red Hat Enterprise Linux لصورة 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 أو تكوين المكدس أو نظام التشغيل.

قواعد جدار حماية Red Hat

يحتوي Red Hat Enterprise Linux على جدار حماية ممكَّن افتراضيًا.

#Allow access to SWPM tool. Rule is not permanent.
sudo firewall-cmd --add-port=4237/tcp

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

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

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

هام

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

إعدادات IBM Db2 HADR لـ Azure

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

• مدة نافذة نظير HADR (بالثواني) (HADR_PEER_WINDOW) = 240
• قيمة وقت HADR (HADR_TIMEOUT) = 45

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

إشعار

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

إشعار

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

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

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

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

قواعد جدار حماية Red Hat لـ DB2 HADR

أضف قواعد جدار الحماية للسماح بحركة المرور إلى DB2 وبين DB2 لكي تعمل HADR:

• منفذ اتصال قاعدة البيانات. إذا كنت تستخدم أقسامًا، فأضف هذه المنافذ أيضًا.
• منفذ HADR (قيمة المعلمة DB2 HADR_LOCAL_SVC).
• منفذ فحص Azure.

sudo firewall-cmd --add-port=<port>/tcp --permanent
sudo firewall-cmd --reload

IBM Db2 HADR الاختيار

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

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

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

#Primary output:
Database Member 0 -- Database ID2 -- Active -- Up 1 days 15:45:23 -- Date 2019-06-25-10.55.25.349375

                            HADR_ROLE = PRIMARY
                          REPLAY_TYPE = PHYSICAL
                        HADR_SYNCMODE = NEARSYNC
                           STANDBY_ID = 1
                        LOG_STREAM_ID = 0
                           HADR_STATE = PEER
                           HADR_FLAGS =
                  PRIMARY_MEMBER_HOST = az-idb01
                     PRIMARY_INSTANCE = db2id2
                       PRIMARY_MEMBER = 0
                  STANDBY_MEMBER_HOST = az-idb02
                     STANDBY_INSTANCE = db2id2
                       STANDBY_MEMBER = 0
                  HADR_CONNECT_STATUS = CONNECTED
             HADR_CONNECT_STATUS_TIME = 06/25/2019 10:55:05.076494 (1561460105)
          HEARTBEAT_INTERVAL(seconds) = 7
                     HEARTBEAT_MISSED = 5
                   HEARTBEAT_EXPECTED = 52
                HADR_TIMEOUT(seconds) = 30
        TIME_SINCE_LAST_RECV(seconds) = 5
             PEER_WAIT_LIMIT(seconds) = 0
           LOG_HADR_WAIT_CUR(seconds) = 0.000
    LOG_HADR_WAIT_RECENT_AVG(seconds) = 598.000027
   LOG_HADR_WAIT_ACCUMULATED(seconds) = 598.000
                  LOG_HADR_WAIT_COUNT = 1
SOCK_SEND_BUF_REQUESTED,ACTUAL(bytes) = 0, 46080
SOCK_RECV_BUF_REQUESTED,ACTUAL(bytes) = 0, 369280
            PRIMARY_LOG_FILE,PAGE,POS = S0000012.LOG, 14151, 3685322855
            STANDBY_LOG_FILE,PAGE,POS = S0000012.LOG, 14151, 3685322855
                  HADR_LOG_GAP(bytes) = 132242668
     STANDBY_REPLAY_LOG_FILE,PAGE,POS = S0000012.LOG, 14151, 3685322855
       STANDBY_RECV_REPLAY_GAP(bytes) = 0
                     PRIMARY_LOG_TIME = 06/25/2019 10:45:42.000000 (1561459542)
                     STANDBY_LOG_TIME = 06/25/2019 10:45:42.000000 (1561459542)
              STANDBY_REPLAY_LOG_TIME = 06/25/2019 10:45:42.000000 (1561459542)
         STANDBY_RECV_BUF_SIZE(pages) = 2048
             STANDBY_RECV_BUF_PERCENT = 0
           STANDBY_SPOOL_LIMIT(pages) = 1000
                STANDBY_SPOOL_PERCENT = 0
                   STANDBY_ERROR_TIME = NULL
                 PEER_WINDOW(seconds) = 300
                      PEER_WINDOW_END = 06/25/2019 11:12:03.000000 (1561461123)
             READS_ON_STANDBY_ENABLED = N


#Secondary output:
Database Member 0 -- Database ID2 -- Standby -- Up 1 days 15:45:18 -- Date 2019-06-25-10.56.19.820474

                            HADR_ROLE = STANDBY
                          REPLAY_TYPE = PHYSICAL
                        HADR_SYNCMODE = NEARSYNC
                           STANDBY_ID = 0
                        LOG_STREAM_ID = 0
                           HADR_STATE = PEER
                           HADR_FLAGS =
                  PRIMARY_MEMBER_HOST = az-idb01
                     PRIMARY_INSTANCE = db2id2
                       PRIMARY_MEMBER = 0
                  STANDBY_MEMBER_HOST = az-idb02
                     STANDBY_INSTANCE = db2id2
                       STANDBY_MEMBER = 0
                  HADR_CONNECT_STATUS = CONNECTED
             HADR_CONNECT_STATUS_TIME = 06/25/2019 10:55:05.078116 (1561460105)
          HEARTBEAT_INTERVAL(seconds) = 7
                     HEARTBEAT_MISSED = 0
                   HEARTBEAT_EXPECTED = 10
                HADR_TIMEOUT(seconds) = 30
        TIME_SINCE_LAST_RECV(seconds) = 1
             PEER_WAIT_LIMIT(seconds) = 0
           LOG_HADR_WAIT_CUR(seconds) = 0.000
    LOG_HADR_WAIT_RECENT_AVG(seconds) = 598.000027
   LOG_HADR_WAIT_ACCUMULATED(seconds) = 598.000
                  LOG_HADR_WAIT_COUNT = 1
SOCK_SEND_BUF_REQUESTED,ACTUAL(bytes) = 0, 46080
SOCK_RECV_BUF_REQUESTED,ACTUAL(bytes) = 0, 367360
            PRIMARY_LOG_FILE,PAGE,POS = S0000012.LOG, 14151, 3685322855
            STANDBY_LOG_FILE,PAGE,POS = S0000012.LOG, 14151, 3685322855
                  HADR_LOG_GAP(bytes) = 0
     STANDBY_REPLAY_LOG_FILE,PAGE,POS = S0000012.LOG, 14151, 3685322855
       STANDBY_RECV_REPLAY_GAP(bytes) = 0
                     PRIMARY_LOG_TIME = 06/25/2019 10:45:42.000000 (1561459542)
                     STANDBY_LOG_TIME = 06/25/2019 10:45:42.000000 (1561459542)
              STANDBY_REPLAY_LOG_TIME = 06/25/2019 10:45:42.000000 (1561459542)
         STANDBY_RECV_BUF_SIZE(pages) = 2048
             STANDBY_RECV_BUF_PERCENT = 0
           STANDBY_SPOOL_LIMIT(pages) = 1000
                STANDBY_SPOOL_PERCENT = 0
                   STANDBY_ERROR_TIME = NULL
                 PEER_WINDOW(seconds) = 1000
                      PEER_WINDOW_END = 06/25/2019 11:12:59.000000 (1561461179)
             READS_ON_STANDBY_ENABLED = N

تكوين Azure Load Balancer

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

مدخل Microsoft Azure

اتبع الخطوات الواردة في إنشاء موازن تحميل لإعداد موازن تحميل قياسي لنظام 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 .

Azure CLI

# Create the load balancer resource with frontend IP. Allocation of private IP address is dynamic using below command. If you want to pass static IP address, include parameter --private-ip-address.
az network lb create -g MyResourceGroup -n MyLB --sku Standard --vnet-name MyVMsVirtualNetwork --subnet MyVMsSubnet --backend-pool-name MyBackendPool --frontend-ip-name MyDBFrontendIpName

# Create the health probe
az network lb probe create -g MyResourceGroup --lb-name MyLB -n MyDBHealthProbe --protocol tcp --port MyDBHealthProbePort --interval 5 --probe-threshold 2
 
# Create load balancing rule
az network lb rule create -g MyResourceGroup --lb-name MyLB -n MyDBRuleName --protocol All --frontend-ip-name MyDBFrontendIpName --frontend-port 0 --backend-pool-name MyBackendPool --backend-port 0 --probe-name MyDBHealthProbe --idle-timeout-in-minutes 30 --enable-floating-ip 

# Add database VMs in backend pool
az network nic ip-config address-pool add --address-pool MyBackendPool --ip-config-name DBVm1IpConfigName --nic-name DBVm1NicName -g MyResourceGroup --lb-name MyLB
az network nic ip-config address-pool add --address-pool MyBackendPool --ip-config-name DBVm2IpConfigName --nic-name DBVm2NicName -g MyResourceGroup --lb-name MyLB

التوسيع لعرض التعليمات البرمجية الكاملة ل CLI

# Define variables for Resource Group, and Database VMs.

rg_name="resourcegroup-name"
vm1_name="db1-name"
vm2_name="db2-name"

# Define variables for the load balancer that will be utilized in the creation of the load balancer resource.

lb_name="sap-db-sid-ilb"
bkp_name="db-backendpool"
db_fip_name="db-frontendip"

db_hp_name="db-healthprobe"
db_hp_port="625<instance-no>"

db_rule_name="db-lb-rule"
 
# Command to get VMs network information like primary NIC name, primary IP configuration name, virtual network name, and subnet name. 
 
vm1_primary_nic=$(az vm nic list -g $rg_name --vm-name $vm1_name --query "[?primary == \`true\`].{id:id} || [?primary == \`null\`].{id:id}" -o tsv)
vm1_nic_name=$(basename $vm1_primary_nic)
vm1_ipconfig=$(az network nic ip-config list -g $rg_name --nic-name $vm1_nic_name --query "[?primary == \`true\`].name" -o tsv)
 
vm2_primary_nic=$(az vm nic list -g $rg_name --vm-name $vm2_name --query "[?primary == \`true\`].{id:id} || [?primary == \`null\`].{id:id}" -o tsv)
vm2_nic_name=$(basename $vm2_primary_nic)
vm2_ipconfig=$(az network nic ip-config list -g $rg_name --nic-name $vm2_nic_name --query "[?primary == \`true\`].name" -o tsv)
 
vnet_subnet_id=$(az network nic show -g $rg_name -n $vm1_nic_name --query ipConfigurations[0].subnet.id -o tsv)
vnet_name=$(basename $(dirname $(dirname $vnet_subnet_id)))
subnet_name=$(basename $vnet_subnet_id)
 
# Create the load balancer resource with frontend IP.
# Allocation of private IP address is dynamic using below command. If you want to pass static IP address, include parameter --private-ip-address. 
  
az network lb create -g $rg_name -n $lb_name --sku Standard --vnet-name $vnet_name --subnet $subnet_name --backend-pool-name $bkp_name --frontend-ip-name $db_fip_name
 
# Create the health probe
 
az network lb probe create -g $rg_name --lb-name $lb_name -n $db_hp_name --protocol tcp --port $db_hp_port --interval 5 --probe-threshold 2
 
# Create load balancing rule
  
az network lb rule create -g $rg_name --lb-name $lb_name -n  $db_rule_name --protocol All --frontend-ip-name $db_fip_name --frontend-port 0 --backend-pool-name $bkp_name --backend-port 0 --probe-name $db_hp_name --idle-timeout-in-minutes 30 --enable-floating-ip 
 
# Add database VMs in backend pool
 
az network nic ip-config address-pool add --address-pool $bkp_name --ip-config-name $vm1_ipconfig --nic-name $vm1_nic_name -g $rg_name --lb-name $lb_name
az network nic ip-config address-pool add --address-pool $bkp_name --ip-config-name $vm2_ipconfig --nic-name $vm2_nic_name -g $rg_name --lb-name $lb_name

# [OPTIONAL] Change the assignment of frontend IP address from dynamic to static
dbfip=$(az network lb frontend-ip show --lb-name $lb_name -g $rg_name -n $db_fip_name --query "{privateIPAddress:privateIPAddress}" -o tsv)
az network lb frontend-ip update --lb-name $lb_name -g $rg_name -n $db_fip_name --private-ip-address $dbfip

بوويرشيل

# Create frontend IP configurations
$db_fip = New-AzLoadBalancerFrontendIpConfig -Name MyDBFrontendIpName -SubnetId MyDBSubnetName

# Create backend pool
$bePool = New-AzLoadBalancerBackendAddressPoolConfig -Name MyBackendPool

# Create health probe
$db_healthprobe = New-AzLoadBalancerProbeConfig -Name MyDBHealthProbe -Protocol 'tcp' -Port MyDBHealthProbePort -IntervalInSeconds 5 -ProbeThreshold 2 -ProbeCount 1

# Create load balancing rule
$db_rule = New-AzLoadBalancerRuleConfig -Name MyDBRuleName -Probe $db_healthprobe -Protocol 'All' -IdleTimeoutInMinutes 30 -FrontendIpConfiguration $db_fip -BackendAddressPool $bePool -EnableFloatingIP

# Create the load balancer resource
$lb = New-AzLoadBalancer -ResourceGroupName MyResourceGroup -Name MyLB -Location MyRegion -Sku 'Standard' -FrontendIpConfiguration $db_fip -BackendAddressPool $bePool -LoadBalancingRule $db_rule -Probe $db_healthprobe

التوسيع لعرض التعليمات البرمجية الكاملة ل PowerShell

# Define variables for Resource Group, and Database VMs.

$rg_name = 'resourcegroup-name'
$vm1_name = 'db1-name'
$vm2_name = 'db2-name'

# Define variables for the load balancer that will be utilized in the creation of the load balancer resource.

$lb_name = 'sap-db-sid-ilb'
$bkp_name = 'db-backendpool'
$db_fip_name = 'db-frontendip'
 
$db_hp_name = 'db-healthprobe'
$db_hp_port = '625<instance-no>'
 
$db_rule_name = 'db-lb-rule'
 
# Command to get VMs network information like primary NIC name, primary IP configuration name, virtual network name, and subnet name.
 
$vm1 = Get-AzVM -ResourceGroupName $rg_name -Name $vm1_name
$vm1_primarynic = $vm1.NetworkProfile.NetworkInterfaces | Where-Object {($_.Primary -eq "True") -or ($_.Primary -eq $null)}
$vm1_nic_name = $vm1_primarynic.Id.Split('/')[-1]
 
$vm1_nic_info = Get-AzNetworkInterface -Name $vm1_nic_name -ResourceGroupName $rg_name
$vm1_primaryip = $vm1_nic_info.IpConfigurations | Where-Object -Property Primary -EQ -Value "True"
$vm1_ipconfig_name = ($vm1_primaryip).Name
 
$vm2 = Get-AzVM -ResourceGroupName $rg_name -Name $vm2_name
$vm2_primarynic = $vm2.NetworkProfile.NetworkInterfaces | Where-Object {($_.Primary -eq "True") -or ($_.Primary -eq $null)}
$vm2_nic_name = $vm2_primarynic.Id.Split('/')[-1]
 
$vm2_nic_info = Get-AzNetworkInterface -Name $vm2_nic_name -ResourceGroupName $rg_name
$vm2_primaryip = $vm2_nic_info.IpConfigurations | Where-Object -Property Primary -EQ -Value "True"
$vm2_ipconfig_name = ($vm2_primaryip).Name
 
$vnet_name = $vm1_primaryip.Subnet.Id.Split('/')[-3]
$subnet_name = $vm1_primaryip.Subnet.Id.Split('/')[-1]
$location = $vm1.Location
 
# Create frontend IP resource.
# Allocation of private IP address is dynamic using below command. If you want to pass static IP address, include parameter -PrivateIpAddress
 
$db_lb_fip = @{
    Name = $db_fip_name
    SubnetId = $vm1_primaryip.Subnet.Id
}
$db_fip = New-AzLoadBalancerFrontendIpConfig @db_lb_fip

# Create backend pool
 
$bepool = New-AzLoadBalancerBackendAddressPoolConfig -Name $bkp_name

# Create the health probe
 
$db_probe = @{
    Name = $db_hp_name
    Protocol = 'tcp'
    Port = $db_hp_port
    IntervalInSeconds = '5'
    ProbeThreshold = '2'
    ProbeCount = '1'
}
$db_healthprobe = New-AzLoadBalancerProbeConfig @db_probe
    
# Create load balancing rule
 
$db_lbrule = @{
    Name = $db_rule_name
    Probe = $db_healthprobe
    Protocol = 'All'
    IdleTimeoutInMinutes = '30'
    FrontendIpConfiguration = $db_fip
    BackendAddressPool = $bePool 
} 
$db_rule = New-AzLoadBalancerRuleConfig @db_lbrule -EnableFloatingIP 
 
# Create the load balancer resource
 
$loadbalancer = @{
    ResourceGroupName = $rg_name
    Name = $lb_name
    Location = $location
    Sku = 'Standard'
    FrontendIpConfiguration = $db_fip
    BackendAddressPool = $bePool
    LoadBalancingRule = $db_rule
    Probe = $db_healthprobe
} 
$lb = New-AzLoadBalancer @loadbalancer

# Add DB VMs in backend pool
 
$vm1_primaryip.LoadBalancerBackendAddressPools.Add($lb.BackendAddressPools[0])
$vm2_primaryip.LoadBalancerBackendAddressPools.Add($lb.BackendAddressPools[0])
$vm1_nic_info | Set-AzNetworkInterface
$vm2_nic_info | Set-AzNetworkInterface

إشعار

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

هام

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

[أ] إضافة قاعدة جدار الحماية لمنفذ التحقيق:

sudo firewall-cmd --add-port=<probe-port>/tcp --permanent
sudo firewall-cmd --reload

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

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

تكوين Db2 Pacemaker

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

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

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

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

• قم بإيقاف تشغيل كل من خوادم قاعدة البيانات باستخدام db2sid< المستخدم باستخدام db2stop>.

• تغيير بيئة shell لمستخدم db2<sid> إلى /bin/ksh:

  # Install korn shell:
  sudo yum install ksh
  # Change users shell:
  sudo usermod -s /bin/ksh db2<sid>
  

تكوين جهاز Pacemaker

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

   # Put Pacemaker into maintenance mode
   sudo pcs property set maintenance-mode=true
   

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

   إذا كان إنشاء نظام مجموعة على RHEL 7.x، فتأكد من تحديث حزمة عوامل الموارد إلى إصدار resource-agents-4.1.1-61.el7_9.15 أو أعلى. استخدم الأوامر التالية لإنشاء موارد نظام المجموعة:

   # Replace bold strings with your instance name db2sid, database SID, and virtual IP address/Azure Load Balancer.
   sudo pcs resource create Db2_HADR_ID2 db2 instance='db2id2' dblist='ID2' master meta notify=true resource-stickiness=5000
   
   #Configure resource stickiness and correct cluster notifications for master resoruce
   sudo pcs resource update Db2_HADR_ID2-master meta notify=true resource-stickiness=5000
   
   # Configure virtual IP - same as Azure Load Balancer IP
   sudo pcs resource create vip_db2id2_ID2 IPaddr2 ip='10.100.0.40'
   
   # Configure probe port for Azure load Balancer
   sudo pcs resource create nc_db2id2_ID2 azure-lb port=62500
   
   #Create a group for ip and Azure loadbalancer probe port
   sudo pcs resource group add g_ipnc_db2id2_ID2 vip_db2id2_ID2 nc_db2id2_ID2
   
   #Create colocation constrain - keep Db2 HADR Master and Group on same node
   sudo pcs constraint colocation add g_ipnc_db2id2_ID2 with master Db2_HADR_ID2-master
   
   #Create start order constrain
   sudo pcs constraint order promote Db2_HADR_ID2-master then g_ipnc_db2id2_ID2
   

   إذا كان إنشاء نظام مجموعة على RHEL 8.x، فتأكد من تحديث حزمة وكلاء الموارد إلى إصدار resource-agents-4.1.1-93.el8 أو أعلى. للحصول على التفاصيل، راجع فشل ترقية مورد Red Hat KBA db2 مع HADR مع الحالة PRIMARY/REMOTE_CATCHUP_PENDING/CONNECTED. استخدم الأوامر التالية لإنشاء موارد نظام المجموعة:

   # Replace bold strings with your instance name db2sid, database SID, and virtual IP address/Azure Load Balancer.
   sudo pcs resource create Db2_HADR_ID2 db2 instance='db2id2' dblist='ID2' promotable meta notify=true resource-stickiness=5000
   
   #Configure resource stickiness and correct cluster notifications for master resoruce
   sudo pcs resource update Db2_HADR_ID2-clone meta notify=true resource-stickiness=5000
   
   # Configure virtual IP - same as Azure Load Balancer IP
   sudo pcs resource create vip_db2id2_ID2 IPaddr2 ip='10.100.0.40'
   
   # Configure probe port for Azure load Balancer
   sudo pcs resource create nc_db2id2_ID2 azure-lb port=62500
   
   #Create a group for ip and Azure loadbalancer probe port
   sudo pcs resource group add g_ipnc_db2id2_ID2 vip_db2id2_ID2 nc_db2id2_ID2
   
   #Create colocation constrain - keep Db2 HADR Master and Group on same node
   sudo pcs constraint colocation add g_ipnc_db2id2_ID2 with master Db2_HADR_ID2-clone
   
   #Create start order constrain
   sudo pcs constraint order promote Db2_HADR_ID2-clone then g_ipnc_db2id2_ID2
   

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

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

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

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

   sudo pcs status
   2 nodes configured
   5 resources configured
   
   Online: [ az-idb01 az-idb02 ]
   
   Full list of resources:
   
   rsc_st_azure   (stonith:fence_azure_arm):      Started az-idb01
   Master/Slave Set: Db2_HADR_ID2-master [Db2_HADR_ID2]
        Masters: [ az-idb01 ]
        Slaves: [ az-idb02 ]
   Resource Group: g_ipnc_db2id2_ID2
        vip_db2id2_ID2     (ocf::heartbeat:IPaddr2):       Started az-idb01
        nc_db2id2_ID2      (ocf::heartbeat:azure-lb):      Started az-idb01
   
   Daemon Status:
     corosync: active/disabled
     pacemaker: active/disabled
     pcsd: active/enabled
   

هام

يجب عليك إدارة مثيل 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 شائعة أو GlusterFS، حيث تتم كتابة السجلات من كلتا العقدتين. يجب أن تكون حصة NFS أو GlusterFS متاحة بشكل كبير.

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

• GlusterFS على أجهزة Azure الظاهرية على Red Hat Enterprise Linux ل SAP NetWeaver.
• قابلية وصول عالية ل SAP NetWeaver على أجهزة Azure الظاهرية على Red Hat Enterprise Linux مع Azure NetApp Files لتطبيقات SAP.
• Azure NetApp Files (لإنشاء مشاركات NFS).

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

يوضح هذا القسم كيفية اختبار إعداد Db2 HADR. يفترض كل اختبار أن IBM Db2 الأساسي يعمل على الجهاز الظاهري az-idb01. يجب استخدام المستخدم الذي يتمتع بامتيازات sudo أو الجذر (غير مستحسن).

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

• حالة أجهزة الكمبيوتر الشخصية هي لقطة لحالة Pacemaker في وقت التنفيذ.
• crm_mon -r هو الإخراج المستمر لحالة Pacemaker.

2 nodes configured
5 resources configured

Online: [ az-idb01 az-idb02 ]

Full list of resources:

rsc_st_azure   (stonith:fence_azure_arm):      Started az-idb01
Master/Slave Set: Db2_HADR_ID2-master [Db2_HADR_ID2]
     Masters: [ az-idb01 ]
     Slaves: [ az-idb02 ]
Resource Group: g_ipnc_db2id2_ID2
     vip_db2id2_ID2     (ocf::heartbeat:IPaddr2):       Started az-idb01
     nc_db2id2_ID2      (ocf::heartbeat:azure-lb):      Started az-idb01

Daemon Status:
  corosync: active/disabled
  pacemaker: active/disabled
  pcsd: active/enabled

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

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

هام

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

• لا يحتوي Pacemaker على أي إجراءات فاشلة (حالة pcs).

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

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

  db2pd -hadr -db <DBSID>
  

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

# On RHEL 7.x
sudo pcs resource move Db2_HADR_ID2-master
# On RHEL 8.x
sudo pcs resource move Db2_HADR_ID2-clone --master

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

2 nodes configured
5 resources configured

Online: [ az-idb01 az-idb02 ]

Full list of resources:

rsc_st_azure   (stonith:fence_azure_arm):      Started az-idb01
Master/Slave Set: Db2_HADR_ID2-master [Db2_HADR_ID2]
     Masters: [ az-idb02 ]
     Stopped: [ az-idb01 ]
Resource Group: g_ipnc_db2id2_ID2
     vip_db2id2_ID2     (ocf::heartbeat:IPaddr2):       Started az-idb02
     nc_db2id2_ID2      (ocf::heartbeat:azure-lb):      Started az-idb02

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

يؤدي ترحيل الموارد باستخدام "نقل موارد pcs" إلى إنشاء قيود على الموقع. تمنع قيود الموقع في هذه الحالة تشغيل مثيل IBM Db2 على az-idb01. إذا لم يتم حذف قيود الموقع، فلا يمكن أن يفشل المورد مرة أخرى.

سيتم بدء إزالة تقييد الموقع وعقدة الاستعداد على az-idb01.

# On RHEL 7.x
sudo pcs resource clear Db2_HADR_ID2-master
# On RHEL 8.x
sudo pcs resource clear Db2_HADR_ID2-clone

وتتغير حالة نظام المجموعة إلى:

2 nodes configured
5 resources configured

Online: [ az-idb01 az-idb02 ]

Full list of resources:

 rsc_st_azure   (stonith:fence_azure_arm):      Started az-idb01
 Master/Slave Set: Db2_HADR_ID2-master [Db2_HADR_ID2]
     Masters: [ az-idb02 ]
     Slaves: [ az-idb01 ]
 Resource Group: g_ipnc_db2id2_ID2
     vip_db2id2_ID2     (ocf::heartbeat:IPaddr2):       Started az-idb02
     nc_db2id2_ID2      (ocf::heartbeat:azure-lb):      Started az-idb02

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

# On RHEL 7.x
sudo pcs resource move Db2_HADR_ID2-master az-idb01
sudo pcs resource clear Db2_HADR_ID2-master
# On RHEL 8.x
sudo pcs resource move Db2_HADR_ID2-clone --master
sudo pcs resource clear Db2_HADR_ID2-clone

• على RHEL 7.x - pcs resource move <resource_name> <host>: ينشئ قيود الموقع ويمكن أن يسبب مشكلات في الاستيلاء
• على RHEL 8.x - pcs resource move <resource_name> --master: ينشئ قيود الموقع ويمكن أن يسبب مشكلات في الاستيلاء
• pcs resource clear <resource_name>: مسح قيود الموقع
• pcs resource cleanup <resource_name>: مسح كافة أخطاء المورد

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

يمكنك اختبار الاستحواذ اليدوي عن طريق إيقاف خدمة Pacemaker على عقدة az-idb01:

systemctl stop pacemaker

الحالة على az-ibdb02

2 nodes configured
5 resources configured

Node az-idb01: pending
Online: [ az-idb02 ]

Full list of resources:

rsc_st_azure   (stonith:fence_azure_arm):      Started az-idb02
Master/Slave Set: Db2_HADR_ID2-master [Db2_HADR_ID2]
     Masters: [ az-idb02 ]
     Stopped: [ az-idb01 ]
Resource Group: g_ipnc_db2id2_ID2
     vip_db2id2_ID2     (ocf::heartbeat:IPaddr2):       Started az-idb02
     nc_db2id2_ID2      (ocf::heartbeat:azure-lb):      Started az-idb02

Daemon Status:
  corosync: active/disabled
  pacemaker: active/disabled
  pcsd: active/enabled

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

systemctl start  pacemaker

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

#Kill main db2 process - db2sysc
[sapadmin@az-idb02 ~]$ sudo ps -ef|grep db2sysc
db2ptr    34598  34596  8 14:21 ?        00:00:07 db2sysc 0
[sapadmin@az-idb02 ~]$ sudo kill -9 34598

مثيل Db2 بصدد الفشل، وسيقوم Pacemaker بنقل العقدة الرئيسية والإبلاغ عن الحالة التالية:

2 nodes configured
5 resources configured

Online: [ az-idb01 az-idb02 ]

Full list of resources:

rsc_st_azure   (stonith:fence_azure_arm):      Started az-idb02
Master/Slave Set: Db2_HADR_ID2-master [Db2_HADR_ID2]
     Masters: [ az-idb02 ]
     Stopped: [ az-idb01 ]
Resource Group: g_ipnc_db2id2_ID2
     vip_db2id2_ID2     (ocf::heartbeat:IPaddr2):       Started az-idb02
     nc_db2id2_ID2      (ocf::heartbeat:azure-lb):      Started az-idb02

Failed Actions:
* Db2_HADR_ID2_demote_0 on az-idb01 'unknown error' (1): call=49, status=complete, exitreason='none',
    last-rc-change='Wed Jun 26 09:57:35 2019', queued=0ms, exec=362ms

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

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

[sapadmin@az-idb02 ~]$ sudo ps -ef|grep db2sysc
db2id2    23144  23142  2 09:53 ?        00:00:13 db2sysc 0
[sapadmin@az-idb02 ~]$ sudo kill -9 23144

تدخل العقدة في فشل ذكرها وتم الإبلاغ عن الخطأ.

2 nodes configured
5 resources configured

Online: [ az-idb01 az-idb02 ]

Full list of resources:

rsc_st_azure   (stonith:fence_azure_arm):      Started az-idb02
Master/Slave Set: Db2_HADR_ID2-master [Db2_HADR_ID2]
     Masters: [ az-idb01 ]
     Slaves: [ az-idb02 ]
Resource Group: g_ipnc_db2id2_ID2
     vip_db2id2_ID2     (ocf::heartbeat:IPaddr2):       Started az-idb01
     nc_db2id2_ID2      (ocf::heartbeat:azure-lb):      Started az-idb01

Failed Actions:
* Db2_HADR_ID2_monitor_20000 on az-idb02 'not running' (7): call=144, status=complete, exitreason='none',
    last-rc-change='Wed Jun 26 10:02:09 2019', queued=0ms, exec=0ms

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

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

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

az-idb01:db2ptr> db2stop force

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

2 nodes configured
5 resources configured

Online: [ az-idb01 az-idb02 ]

Full list of resources:

rsc_st_azure   (stonith:fence_azure_arm):      Started az-idb02
Master/Slave Set: Db2_HADR_ID2-master [Db2_HADR_ID2]
     Slaves: [ az-idb02 ]
     Stopped: [ az-idb01 ]
Resource Group: g_ipnc_db2id2_ID2
     vip_db2id2_ID2     (ocf::heartbeat:IPaddr2):       Stopped
     nc_db2id2_ID2      (ocf::heartbeat:azure-lb):      Stopped

Failed Actions:
* Db2_HADR_ID2_demote_0 on az-idb01 'unknown error' (1): call=110, status=complete, exitreason='none',
    last-rc-change='Wed Jun 26 14:03:12 2019', queued=0ms, exec=355ms

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

2 nodes configured
5 resources configured

Online: [ az-idb01 az-idb02 ]

Full list of resources:

rsc_st_azure   (stonith:fence_azure_arm):      Started az-idb02
Master/Slave Set: Db2_HADR_ID2-master [Db2_HADR_ID2]
     Masters: [ az-idb02 ]
     Slaves: [ az-idb01 ]
Resource Group: g_ipnc_db2id2_ID2
     vip_db2id2_ID2     (ocf::heartbeat:IPaddr2):       Started az-idb02
     nc_db2id2_ID2      (ocf::heartbeat:azure-lb):      Started az-idb02

Failed Actions:
* Db2_HADR_ID2_demote_0 on az-idb01 'unknown error' (1): call=110, status=complete, exitreason='none',
    last-rc-change='Wed Jun 26 14:03:12 2019', queued=0ms, exec=355ms

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

#Linux kernel panic.
sudo echo b > /proc/sysrq-trigger

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

2 nodes configured
5 resources configured

Node az-idb01: UNCLEAN (online)
Online: [ az-idb02 ]

Full list of resources:

rsc_st_azure    (stonith:fence_azure_arm):      Started az-idb02
Master/Slave Set: Db2_HADR_ID2-master [Db2_HADR_ID2]
     Masters: [ az-idb01 ]
     Slaves: [ az-idb02 ]
Resource Group: g_ipnc_db2id2_ID2
     vip_db2id2_ID2     (ocf::heartbeat:IPaddr2):       Started az-idb01
     nc_db2id2_ID2      (ocf::heartbeat:azure-lb):      Started az-idb01

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

2 nodes configured
5 resources configured

Online: [ az-idb02 ]
OFFLINE: [ az-idb01 ]

Full list of resources:

rsc_st_azure    (stonith:fence_azure_arm):      Started az-idb02
Master/Slave Set: Db2_HADR_ID2-master [Db2_HADR_ID2]
     Masters: [ az-idb02 ]
     Stopped: [ az-idb01 ]
Resource Group: g_ipnc_db2id2_ID2
     vip_db2id2_ID2     (ocf::heartbeat:IPaddr2):       Started az-idb02
     nc_db2id2_ID2      (ocf::heartbeat:azure-lb):      Started az-idb02

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

sudo pcs cluster start

يبدأ مثيل Db2 في الدور الثانوي.

2 nodes configured
5 resources configured

Online: [ az-idb01 az-idb02 ]

Full list of resources:

rsc_st_azure    (stonith:fence_azure_arm):      Started az-idb02
Master/Slave Set: Db2_HADR_ID2-master [Db2_HADR_ID2]
     Masters: [ az-idb02 ]
     Slaves: [ az-idb01 ]
Resource Group: g_ipnc_db2id2_ID2
     vip_db2id2_ID2     (ocf::heartbeat:IPaddr2):       Started az-idb02
     nc_db2id2_ID2      (ocf::heartbeat:azure-lb):      Started az-idb02

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

• بنية وسيناريوهات عالية التوفر لـSAP NetWeaver
• إعداد Pacemaker على نظام التشغيل Red Hat Enterprise Linux في نظام Azure