Udostępnij za pośrednictwem

Wysoka dostępność systemu IBM Db2 LUW na maszynach wirtualnych platformy Azure w systemie SUSE Linux Enterprise Server z programem Pacemaker

  • Artykuł

Usługa IBM Db2 dla systemów Linux, UNIX i Windows (LUW) w konfiguracji wysokiej dostępności i odzyskiwania po awarii (HADR) składa się z jednego węzła, który uruchamia podstawowe wystąpienie bazy danych i co najmniej jeden węzeł z pomocniczym wystąpieniem bazy danych. Zmiany w podstawowym wystąpieniu bazy danych są replikowane synchronicznie lub asynchronicznie w zależności od konfiguracji.

Uwaga

Ten artykuł zawiera odwołania do terminów, których firma Microsoft już nie używa. Po usunięciu tych warunków z oprogramowania usuniemy je z tego artykułu.

W tym artykule opisano sposób wdrażania i konfigurowania maszyn wirtualnych platformy Azure, instalowania struktury klastra i instalowania bazy danych IBM Db2 LUW przy użyciu konfiguracji usługi HADR.

W tym artykule nie opisano sposobu instalowania i konfigurowania systemu IBM Db2 LUW z instalacją oprogramowania HADR lub SAP. Aby ułatwić wykonywanie tych zadań, udostępniamy odwołania do podręczników instalacji oprogramowania SAP i IBM. Ten artykuł koncentruje się na częściach specyficznych dla środowiska platformy Azure.

Obsługiwane wersje IBM Db2 to wersja 10.5 lub nowsza, jak opisano w 1928533 notatek SAP.

Przed rozpoczęciem instalacji zapoznaj się z następującymi uwagami i dokumentacją oprogramowania SAP:

Uwaga SAP opis
1928533 Aplikacje SAP na platformie Azure: obsługiwane produkty i typy maszyn wirtualnych platformy Azure
2015553 OPROGRAMOWANIE SAP na platformie Azure: wymagania wstępne dotyczące pomocy technicznej
2178632 Kluczowe metryki monitorowania oprogramowania SAP na platformie Azure
2191498 Oprogramowanie SAP w systemie Linux z platformą Azure: ulepszone monitorowanie
2243692 Maszyna wirtualna z systemem Linux na platformie Azure (IaaS): problemy z licencjami sap
1984787 SUSE LINUX Enterprise Server 12: Informacje o instalacji
1999351 Rozwiązywanie problemów z rozszerzonym monitorowaniem platformy Azure dla oprogramowania SAP
2233094 DB6: aplikacje SAP na platformie Azure korzystające z bazy danych IBM Db2 dla systemów Linux, UNIX i Windows — dodatkowe informacje
1612105 DB6: często zadawane pytania dotyczące bazy danych Db2 z usługą HADR
Dokumentacja
Witryna wiki społeczności SAP: zawiera wszystkie wymagane uwagi SAP dla systemu Linux
Przewodnik planowania i implementacji usługi Azure Virtual Machines dla oprogramowania SAP w systemie Linux
Wdrażanie usługi Azure Virtual Machines dla oprogramowania SAP w systemie Linux (ten artykuł)
Wdrażanie systemu zarządzania bazami danych usługi Azure Virtual Machines (DBMS) dla oprogramowania SAP w systemie Linux
Lista kontrolna planowania i wdrażania oprogramowania SAP na platformie Azure
SusE Linux Enterprise Server for SAP Applications 12 SP4 best practices guides (Przewodniki najlepszych rozwiązań dotyczących systemu SUSE Linux Enterprise Server dla aplikacji SAP 12 SP4)
SUSE Linux Enterprise High Availability Extension 12 SP4
Wdrażanie systemu DBMS maszyn wirtualnych PLATFORMy Azure w usłudze IBM Db2 dla obciążenia SAP
IBM Db2 HADR 11.1
IBM Db2 HADR R 10.5

Omówienie

Aby uzyskać wysoką dostępność, system IBM Db2 LUW z usługą HADR jest instalowany na co najmniej dwóch maszynach wirtualnych platformy Azure, które są wdrażane w zestawie skalowania maszyn wirtualnych z elastyczną aranżacją w różnych strefach dostępności lub w zestawie dostępności.

Poniższa grafika przedstawia konfigurację dwóch maszyn wirtualnych platformy Azure serwera bazy danych. Obie maszyny wirtualne serwera bazy danych platformy Azure mają dołączony własny magazyn i są uruchomione. W usłudze HADR jedno wystąpienie bazy danych na jednej z maszyn wirtualnych platformy Azure ma rolę wystąpienia podstawowego. Wszyscy klienci są połączeni z tym wystąpieniem podstawowym. Wszystkie zmiany transakcji bazy danych są utrwalane lokalnie w dzienniku transakcji db2. Ponieważ rekordy dziennika transakcji są utrwalane lokalnie, rekordy są przesyłane za pośrednictwem protokołu TCP/IP do wystąpienia bazy danych na drugim serwerze bazy danych, serwerze rezerwowym lub wystąpieniu rezerwowym. Wystąpienie rezerwowe aktualizuje lokalną bazę danych przez przeniesienie przeniesionych rekordów dziennika transakcji. W ten sposób serwer rezerwowy jest synchronizowany z serwerem podstawowym.

USŁUGA HADR jest tylko funkcją replikacji. Nie ma wykrywania błędów i nie ma automatycznych funkcji przejęcia ani trybu failover. Przejęcie lub przeniesienie na serwer rezerwowy musi zostać zainicjowane ręcznie przez administratora bazy danych. Aby osiągnąć automatyczne przejęcie i wykrywanie błędów, możesz użyć funkcji klastrowania Pacemaker systemu Linux. Program Pacemaker monitoruje dwa wystąpienia serwera bazy danych. W przypadku awarii wystąpienia podstawowego serwera bazy danych program Pacemaker inicjuje automatyczne przejęcie usługi HADR przez serwer rezerwowy. Program Pacemaker zapewnia również przypisanie wirtualnego adresu IP do nowego serwera podstawowego.

Omówienie wysokiej dostępności ibm Db2

Aby serwery aplikacji SAP łączyły się z podstawową bazą danych, potrzebna jest nazwa hosta wirtualnego i wirtualny adres IP. Po przejściu w tryb failover serwery aplikacji SAP łączą się z nowym podstawowym wystąpieniem bazy danych. W środowisku platformy Azure moduł równoważenia obciążenia platformy Azure jest wymagany do używania wirtualnego adresu IP w sposób wymagany dla usługi HADR firmy IBM Db2.

Aby w pełni zrozumieć, jak system IBM Db2 LUW z usługami HADR i Pacemaker pasuje do konfiguracji systemu SAP o wysokiej dostępności, na poniższej ilustracji przedstawiono omówienie konfiguracji systemu SAP o wysokiej dostępności opartej na bazie danych IBM Db2. W tym artykule opisano tylko ibm Db2, ale zawiera on odwołania do innych artykułów dotyczących konfigurowania innych składników systemu SAP.

Omówienie pełnego środowiska wysokiej dostępności IBM DB2

Ogólne omówienie wymaganych kroków

Aby wdrożyć konfigurację ibm Db2, należy wykonać następujące kroki:

  • Planowanie środowiska.
  • Wdrażanie maszyn wirtualnych.
  • Zaktualizuj system SUSE Linux i skonfiguruj systemy plików.
  • Instalowanie i konfigurowanie programu Pacemaker.
  • Zainstaluj system plików NFS o wysokiej dostępności.
  • Zainstaluj usługę ASCS/ERS w oddzielnym klastrze.
  • Zainstaluj bazę danych IBM Db2 z opcją rozproszonej/wysokiej dostępności (SWPM).
  • Zainstaluj i utwórz pomocniczy węzeł bazy danych oraz wystąpienie i skonfiguruj usługę HADR.
  • Upewnij się, że usługa HADR działa.
  • Zastosuj konfigurację programu Pacemaker, aby kontrolować ibm Db2.
  • Konfigurowanie usługi Azure Load Balancer.
  • Zainstaluj podstawowe i okna dialogowe serwery aplikacji.
  • Sprawdź i dostosuj konfigurację serwerów aplikacji SAP.
  • Przeprowadź testy przejścia w tryb failover i przejęcia.

Planowanie infrastruktury platformy Azure na potrzeby hostowania systemu IBM Db2 LUW za pomocą usługi HADR

Przed wykonaniem wdrożenia ukończ proces planowania. Planowanie tworzy podstawy wdrażania konfiguracji bazy danych Db2 z usługą HADR na platformie Azure. Kluczowe elementy, które muszą być częścią planowania usługi IMB Db2 LUW (część bazy danych środowiska SAP) są wymienione w poniższej tabeli:

Temat Krótki opis
Definiowanie grup zasobów platformy Azure Grupy zasobów, w których wdrażasz maszynę wirtualną, sieć wirtualną, usługę Azure Load Balancer i inne zasoby. Może być istniejący lub nowy.
Definicja sieci wirtualnej/podsieci Gdzie są wdrażane maszyny wirtualne dla produktów IBM Db2 i Azure Load Balancer. Może być istniejący lub nowo utworzony.
Maszyny wirtualne hostowania systemu IBM Db2 LUW Rozmiar maszyny wirtualnej, magazyn, sieć, adres IP.
Nazwa hosta wirtualnego i wirtualny adres IP bazy danych IBM Db2 Wirtualny adres IP lub nazwa hosta używana na potrzeby połączenia serwerów aplikacji SAP. db-virt-hostname, db-virt-ip.
Ogrodzenie platformy Azure Ogrodzenie platformy Azure lub ogrodzenie SBD (zdecydowanie zalecane). Metoda, aby uniknąć podziału sytuacji mózgu.
Maszyna wirtualna SBD Rozmiar maszyny wirtualnej SBD, magazyn, sieć.
Azure Load Balancer Użycie standardowego (zalecanego), portu sondy dla bazy danych Db2 (rekomendacja 62500) — port sondy.
Rozpoznawanie nazw Jak działa rozpoznawanie nazw w środowisku. Usługa DNS jest zdecydowanie zalecana. Można użyć pliku hostów lokalnych.

Aby uzyskać więcej informacji na temat programu Pacemaker systemu Linux na platformie Azure, zobacz Konfigurowanie programu Pacemaker na serwerze SUSE Linux Enterprise Server na platformie Azure.

Ważne

W przypadku bazy danych Db2 w wersji 11.5.6 lub nowszej zdecydowanie zalecamy rozwiązanie zintegrowane przy użyciu programu Pacemaker firmy IBM.

Wdrażanie w systemie SUSE Linux

Agent zasobów dla systemu IBM Db2 LUW jest zawarty w systemie SUSE Linux Enterprise Server for SAP Applications. W przypadku konfiguracji opisanej w tym dokumencie należy użyć systemu SUSE Linux Server for SAP Applications. Witryna Azure Marketplace zawiera obraz programu SUSE Enterprise Server for SAP Applications 12, którego można użyć do wdrożenia nowych maszyn wirtualnych platformy Azure. Należy pamiętać o różnych modelach pomocy technicznej lub usług oferowanych przez platformę SUSE za pośrednictwem witryny Azure Marketplace podczas wybierania obrazu maszyny wirtualnej w witrynie Azure VM Marketplace.

Hosty: aktualizacje DNS

Utwórz listę wszystkich nazw hostów, w tym nazw hostów wirtualnych, i zaktualizuj serwery DNS, aby umożliwić prawidłowe adresy IP rozpoznawania nazw hostów. Jeśli serwer DNS nie istnieje lub nie możesz zaktualizować i utworzyć wpisów DNS, musisz użyć lokalnych plików hosta poszczególnych maszyn wirtualnych uczestniczących w tym scenariuszu. Jeśli używasz wpisów plików hosta, upewnij się, że wpisy są stosowane do wszystkich maszyn wirtualnych w środowisku systemu SAP. Zalecamy jednak użycie usługi DNS, która w idealnym przypadku rozciąga się na platformę Azure

Wdrożenie ręczne

Upewnij się, że wybrany system operacyjny jest obsługiwany przez firmę IBM/SAP dla systemu IBM Db2 LUW. Lista obsługiwanych wersji systemu operacyjnego dla maszyn wirtualnych platformy Azure i wersji Db2 jest dostępna w uwagach sap 1928533. Lista wydań systemu operacyjnego według poszczególnych wersji db2 jest dostępna w macierzy dostępności produktów SAP. Zdecydowanie zalecamy co najmniej system SLES 12 z dodatkiem SP4 ze względu na ulepszenia wydajności związane z platformą Azure w tej lub nowszej wersji systemu SUSE Linux.

  1. Utwórz lub wybierz grupę zasobów.
  2. Utwórz lub wybierz sieć wirtualną i podsieć.
  3. Wybierz odpowiedni typ wdrożenia dla maszyn wirtualnych SAP. Zazwyczaj zestaw skalowania maszyn wirtualnych z elastyczną aranżacją.
  4. Utwórz maszynę wirtualną 1.
    1. Użyj protokołu SLES dla obrazu SAP w witrynie Azure Marketplace.
    2. Wybierz zestaw skalowania, strefę dostępności lub zestaw dostępności utworzony w kroku 3.
  5. Utwórz maszynę wirtualną 2.
    1. Użyj protokołu SLES dla obrazu SAP w witrynie Azure Marketplace.
    2. Wybierz zestaw skalowania, strefę dostępności lub zestaw dostępności utworzony w kroku 3 (nie tę samą strefę co w kroku 4).
  6. Dodaj dyski danych do maszyn wirtualnych, a następnie sprawdź zalecenie konfiguracji systemu plików w artykule IBM Db2 Azure Virtual Machines DBMS deployment for SAP workload (Wdrażanie programu DBMS maszyn wirtualnych platformy AZURE w usłudze IBM Db2 Azure Virtual Machines dla obciążenia SAP).

Instalowanie środowiska IBM Db2 LUW i SAP

Przed rozpoczęciem instalacji środowiska SAP opartego na systemie IBM Db2 LUW zapoznaj się z następującą dokumentacją:

  • Dokumentacja platformy Azure
  • Dokumentacja oprogramowania SAP
  • Dokumentacja firmy IBM

Linki do tej dokumentacji znajdują się w sekcji wprowadzającej tego artykułu.

Zapoznaj się z podręcznikami instalacji oprogramowania SAP dotyczącymi instalowania aplikacji opartych na oprogramowaniu NetWeaver w systemie IBM Db2 LUW.

Przewodniki można znaleźć w portalu pomocy sap, korzystając z narzędzia SAP Installation Guide Finder.

Liczbę przewodników wyświetlanych w portalu można zmniejszyć, ustawiając następujące filtry:

  • Chcę: "Zainstaluj nowy system"
  • Moja baza danych: "IBM Db2 for Linux, Unix i Windows"
  • Dodatkowe filtry dla wersji oprogramowania SAP NetWeaver, konfiguracji stosu lub systemu operacyjnego

Wskazówki instalacji dotyczące konfigurowania systemu IBM Db2 LUW z usługą HADR

Aby skonfigurować podstawowe wystąpienie bazy danych IBM Db2 LUW:

  • Użyj opcji wysokiej dostępności lub rozproszonej.
  • Zainstaluj wystąpienie sap ASCS/ERS i bazy danych.
  • Utwórz kopię zapasową nowo zainstalowanej bazy danych.

Ważne

Zapisz port "Port komunikacji bazy danych", który jest ustawiony podczas instalacji. Musi to być ten sam numer portu dla obu wystąpień bazy danych Definicja portu SAP SWPM

Aby skonfigurować serwer bazy danych rezerwowej przy użyciu procedury kopiowania homogenicznego systemu SAP, wykonaj następujące kroki:

  1. Wybierz opcję Kopiowanie systemu Docelowe >systemy>rozproszonej> bazy danych.

  2. Jako metodę kopiowania wybierz pozycję Homogeniczny system , aby można było użyć kopii zapasowej w celu przywrócenia kopii zapasowej w wystąpieniu serwera rezerwowego.

  3. Po osiągnięciu kroku zakończenia w celu przywrócenia bazy danych na potrzeby jednorodnej kopii systemu zamknij instalatora. Przywróć bazę danych z kopii zapasowej hosta podstawowego. Wszystkie kolejne fazy instalacji zostały już wykonane na podstawowym serwerze bazy danych.

  4. Konfigurowanie usługi HADR dla ibm Db2.

    Uwaga

    W przypadku instalacji i konfiguracji specyficznej dla platformy Azure i programu Pacemaker: podczas procedury instalacji za pośrednictwem programu SAP Software Provisioning Manager istnieje jawne pytanie dotyczące wysokiej dostępności systemu IBM Db2 LUW:

    • Nie wybieraj bazy danych IBM Db2 pureScale.
    • Nie wybieraj opcji Zainstaluj automatyzację systemu IBM Ibm Ibm Dla wieluplatform.
    • Nie wybieraj pozycji Generuj pliki konfiguracji klastra.

W przypadku korzystania z urządzenia SBD dla programu Linux Pacemaker ustaw następujące parametry usługi HADR Db2:

  • Czas trwania okna równorzędnego usługi HADR (w sekundach) (HADR_PEER_WINDOW) = 300
  • Wartość limitu czasu usługi HADR (HADR_TIMEOUT) = 60

W przypadku korzystania z agenta ogrodzenia usługi Azure Pacemaker ustaw następujące parametry:

  • Czas trwania okna równorzędnego usługi HADR (w sekundach) (HADR_PEER_WINDOW) = 900
  • Wartość limitu czasu usługi HADR (HADR_TIMEOUT) = 60

Zalecamy poprzednie parametry na podstawie początkowego testowania trybu failover/przejęcia. Wymagane jest przetestowanie prawidłowej funkcjonalności trybu failover i przejęcia przy użyciu tych ustawień parametrów. Ponieważ poszczególne konfiguracje mogą się różnić, parametry mogą wymagać dostosowania.

Ważne

Specyficzne dla programu IBM Db2 z konfiguracją usługi HADR z normalnym uruchamianiem: wystąpienie pomocniczej lub rezerwowej bazy danych musi być uruchomione przed uruchomieniem podstawowego wystąpienia bazy danych.

W celach demonstracyjnych i procedurach opisanych w tym artykule identyfikator SID bazy danych to PTR.

Sprawdzanie usługi HADR IBM Db2

Po skonfigurowaniu usługi HADR, a stan to PEER i CONNECTED w węzłach podstawowych i rezerwowych, wykonaj następujące sprawdzanie:

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

Konfigurowanie modułu Azure Load Balancer

Podczas konfigurowania maszyny wirtualnej masz możliwość utworzenia lub wybrania wyjścia z modułu równoważenia obciążenia w sekcji dotyczącej sieci. Wykonaj poniższe kroki, aby skonfigurować standardowy moduł równoważenia obciążenia na potrzeby konfiguracji bazy danych DB2 o wysokiej dostępności.

Wykonaj kroki opisane w temacie Tworzenie modułu równoważenia obciążenia, aby skonfigurować standardowy moduł równoważenia obciążenia dla systemu SAP o wysokiej dostępności przy użyciu witryny Azure Portal. Podczas konfigurowania modułu równoważenia obciążenia należy wziąć pod uwagę następujące kwestie:

  1. Konfiguracja adresu IP frontonu: utwórz adres IP frontonu. Wybierz tę samą sieć wirtualną i nazwę podsieci co maszyny wirtualne bazy danych.
  2. Pula zaplecza: utwórz pulę zaplecza i dodaj maszyny wirtualne bazy danych.
  3. Reguły ruchu przychodzącego: utwórz regułę równoważenia obciążenia. Wykonaj te same kroki dla obu reguł równoważenia obciążenia.
    • Adres IP frontonu: wybierz adres IP frontonu.
    • Pula zaplecza: wybierz pulę zaplecza.
    • Porty wysokiej dostępności: wybierz tę opcję.
    • Protokół: wybierz pozycję TCP.
    • Sonda kondycji: utwórz sondę kondycji z następującymi szczegółami:
      • Protokół: wybierz pozycję TCP.
      • Port: na przykład 625<instance-no.>.
      • Interwał: wprowadź wartość 5.
      • Próg sondy: wprowadź wartość 2.
    • Limit czasu bezczynności (w minutach): wprowadź wartość 30.
    • Włącz pływający adres IP: wybierz tę opcję.

Uwaga

Właściwość numberOfProbeskonfiguracji sondy kondycji , inaczej znana jako próg złej kondycji w portalu, nie jest uwzględniana. Aby kontrolować liczbę pomyślnych lub zakończonych niepowodzeniem kolejnych sond, ustaw właściwość probeThreshold na 2wartość . Obecnie nie można ustawić tej właściwości przy użyciu witryny Azure Portal, dlatego użyj interfejsu wiersza polecenia platformy Azure lub polecenia programu PowerShell.

Uwaga

Jeśli maszyny wirtualne bez publicznych adresów IP są umieszczane w puli zaplecza wystąpienia wewnętrznego (bez publicznego adresu IP) usługi Azure Load Balancer w warstwie Standardowa, nie ma wychodzącej łączności z Internetem, chyba że zostanie wykonana więcej konfiguracji, aby umożliwić routing do publicznych punktów końcowych. Aby uzyskać więcej informacji na temat uzyskiwania łączności wychodzącej, zobacz Publiczna łączność punktów końcowych dla maszyn wirtualnych korzystających z usługi Azure usługa Load Balancer w warstwie Standardowa w scenariuszach wysokiej dostępności oprogramowania SAP.

Ważne

Nie włączaj sygnatur czasowych PROTOKOŁU TCP na maszynach wirtualnych platformy Azure umieszczonych za usługą Azure Load Balancer. Włączenie sygnatur czasowych protokołu TCP może spowodować niepowodzenie sond kondycji. Ustaw parametr net.ipv4.tcp_timestamps na 0. Aby uzyskać więcej informacji, zobacz Load Balancer health probes (Sondy kondycji usługi Load Balancer).

Tworzenie klastra Pacemaker

Aby utworzyć podstawowy klaster Pacemaker dla tego serwera IBM Db2, zobacz Konfigurowanie programu Pacemaker na serwerze SUSE Linux Enterprise Server na platformie Azure.

Konfiguracja programu Pacemaker Db2

Jeśli używasz programu Pacemaker do automatycznego trybu failover w przypadku awarii węzła, należy odpowiednio skonfigurować wystąpienia bazy danych Db2 i program Pacemaker. W tej sekcji opisano ten typ konfiguracji.

Następujące elementy są poprzedzone prefiksem:

  • [A]: Dotyczy wszystkich węzłów
  • [1]: Dotyczy tylko węzła 1
  • [2]: Dotyczy tylko węzła 2

[A] Wymagania wstępne dotyczące konfiguracji programu Pacemaker:

  • Zamknij oba serwery baz danych przy użyciu identyfikatora SID> użytkownika db2<z bazą danych db2stop.
  • Zmień środowisko powłoki dla użytkownika sid> db2<na /bin/ksh. Zalecamy użycie narzędzia Yast.

Konfiguracja programu Pacemaker

Ważne

Ostatnie testy wykazały sytuacje, w których netcat przestaje odpowiadać na żądania z powodu listy prac i ograniczenia obsługi tylko jednego połączenia. Zasób netcat przestaje nasłuchiwać żądań modułu równoważenia obciążenia platformy Azure, a pływający adres IP staje się niedostępny. W przypadku istniejących klastrów Pacemaker zalecamy w przeszłości zastąpienie serwera netcat socat. Obecnie zalecamy użycie agenta zasobów azure-lb, który jest częścią agentów zasobów pakietu z następującymi wymaganiami dotyczącymi wersji pakietu:

  • W przypadku systemu SLES 12 SP4/SP5 wersja musi być co najmniej resource-agents-4.3.018.a7fb5035-3.30.1.
  • W przypadku systemu SLES 15/15 SP1 wersja musi być co najmniej resource-agents-4.3.0184.6ee15eb2-4.13.1.

Należy pamiętać, że zmiana będzie wymagać krótkiego przestoju.
W przypadku istniejących klastrów Pacemaker, jeśli konfiguracja została już zmieniona tak, aby korzystała z serwera socat zgodnie z opisem w temacie Azure Load-Balancer Detection Hardening (Wzmacnianie zabezpieczeń wykrywania modułu równoważenia obciążenia platformy Azure), nie ma potrzeby natychmiastowego przełączania się do agenta zasobów azure-lb.

  1. [1] Konfiguracja narzędzia Pacemaker specyficznego dla usługi HADR firmy IBM Db2:

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

  2. [1] Tworzenie zasobów 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] Uruchamianie zasobów IBM Db2:

    Wyjmij program Pacemaker z trybu konserwacji.

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

  4. [1] Upewnij się, że stan klastra jest prawidłowy i że wszystkie zasoby są uruchomione. Nie jest ważne, w którym węźle działają zasoby.

    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 ]

Ważne

Należy zarządzać wystąpieniem klastrowanej bazy danych Db2 programu Pacemaker przy użyciu narzędzi pacemaker. Jeśli używasz poleceń db2, takich jak db2stop, program Pacemaker wykryje akcję jako błąd zasobu. Jeśli przeprowadzasz konserwację, możesz umieścić węzły lub zasoby w trybie konserwacji. Program Pacemaker zawiesza zasoby monitorowania, a następnie można użyć normalnych poleceń administracyjnych db2.

Wprowadzanie zmian w profilach SAP w celu używania wirtualnego adresu IP na potrzeby połączenia

Aby nawiązać połączenie z podstawowym wystąpieniem konfiguracji usługi HADR, warstwa aplikacji SAP musi używać wirtualnego adresu IP zdefiniowanego i skonfigurowanego dla usługi Azure Load Balancer. Wymagane są następujące zmiany:

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

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

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

Hostname=db-virt-hostname

Instalowanie serwerów aplikacji podstawowych i dialogowych

Podczas instalowania serwerów aplikacji podstawowych i dialogowych względem konfiguracji usługi HADR db2 użyj nazwy hosta wirtualnego wybranej dla konfiguracji.

Jeśli instalacja została wykonana przed utworzeniem konfiguracji db2 HADR, wprowadź zmiany zgodnie z opisem w poprzedniej sekcji i w następujący sposób dla stosów SAP Java.

Sprawdzanie adresu URL JDBC w systemach stosu ABAP+Java lub Java

Użyj narzędzia J2EE Config, aby sprawdzić lub zaktualizować adres URL JDBC. Ponieważ narzędzie Config J2EE jest narzędziem graficznym, musisz mieć zainstalowany serwer X:

  1. Zaloguj się do podstawowego serwera aplikacji wystąpienia J2EE i wykonaj następujące polecenie:

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

  2. W lewej ramce wybierz pozycję Magazyn zabezpieczeń.

  3. W prawej ramce wybierz klucz jdbc/pool/<SAPSID>/url.

  4. Zmień nazwę hosta w adresie URL JDBC na nazwę hosta wirtualnego.

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

  5. Wybierz Dodaj.

  6. Aby zapisać zmiany, wybierz ikonę dysku w lewym górnym rogu.

  7. Zamknij narzędzie konfiguracji.

  8. Uruchom ponownie wystąpienie języka Java.

Konfigurowanie archiwizowania dzienników dla konfiguracji usługi HADR

Aby skonfigurować archiwizowanie dzienników db2 dla konfiguracji usługi HADR, zalecamy skonfigurowanie zarówno podstawowej, jak i rezerwowej bazy danych w celu automatycznego pobierania dzienników ze wszystkich lokalizacji archiwum dzienników. Zarówno podstawowa, jak i rezerwowa baza danych musi mieć możliwość pobierania plików archiwum dziennika ze wszystkich lokalizacji archiwum dziennika, do których jeden z wystąpień bazy danych może archiwizować pliki dziennika.

Archiwizacja dziennika jest wykonywana tylko przez podstawową bazę danych. Jeśli zmienisz role usługi HADR serwerów baz danych lub wystąpi awaria, nowa podstawowa baza danych jest odpowiedzialna za archiwizowanie dzienników. Jeśli skonfigurowano wiele lokalizacji archiwum dzienników, dzienniki mogą być archiwizowane dwa razy. W przypadku lokalnego lub zdalnego nadrobienia zaległości może być również konieczne ręczne skopiowanie zarchiwizowanych dzienników ze starego serwera podstawowego do aktywnej lokalizacji dziennika nowego serwera podstawowego.

Zalecamy skonfigurowanie wspólnego udziału NFS, w którym dzienniki są zapisywane z obu węzłów. Udział NFS musi być wysoce dostępny.

Istniejące udziały NFS o wysokiej dostępności można używać do transportu lub katalogu profilów. Aby uzyskać więcej informacji, zobacz:

Testowanie konfiguracji klastra

W tej sekcji opisano sposób testowania konfiguracji usługi HADR db2. Każdy test zakłada, że użytkownik jest zalogowany jako użytkownik główny , a podstawowa baza danych IBM Db2 jest uruchomiona na maszynie wirtualnej azibmdb01 .

Początkowy stan wszystkich przypadków testowych jest wyjaśniony tutaj: (crm_mon -r lub stan crm)

  • stan crm to migawka stanu programu Pacemaker w czasie wykonywania.
  • crm_mon -r to ciągłe dane wyjściowe stanu programu 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 ]

Oryginalny stan w systemie SAP jest udokumentowany w temacie Transaction DBACOCKPIT Configuration Overview (Omówienie konfiguracji > DBACOCKPIT > transakcji), jak pokazano na poniższej ilustracji:

DBACockpit — migracja wstępna

Testowe przejęcie IBM Db2

Ważne

Przed rozpoczęciem testu upewnij się, że:

  • Program Pacemaker nie ma żadnych nieudanych akcji (stan crm).

  • Brak ograniczeń lokalizacji (resztki testu migracji.

  • Synchronizacja usługi HADR IBM Db2 działa. Sprawdzanie identyfikatora SID użytkownika db2<>

    db2pd -hadr -db <DBSID>

Przeprowadź migrację węzła, w którym działa podstawowa baza danych Db2, wykonując następujące polecenie:

crm resource migrate msl_Db2_db2ptr_PTR azibmdb02

Po zakończeniu migracji dane wyjściowe stanu crm wyglądają następująco:

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 ]

Oryginalny stan w systemie SAP jest udokumentowany w temacie Transaction DBACOCKPIT Configuration Overview (Omówienie konfiguracji > DBACOCKPIT > transakcji), jak pokazano na poniższej ilustracji:

DBACockpit — po migracji

Migracja zasobów za pomocą polecenia "migracja zasobów crm" tworzy ograniczenia lokalizacji. Należy usunąć ograniczenia lokalizacji. Jeśli ograniczenia lokalizacji nie zostaną usunięte, zasób nie może powrócić po awarii lub może wystąpić niepożądane przejęcia.

Przeprowadź migrację zasobu z powrotem do bazy danych azibmdb01 i wyczyść ograniczenia lokalizacji

crm resource migrate msl_Db2_db2ptr_PTR azibmdb01
crm resource clear msl_Db2_db2ptr_PTR
  • Migracja <zasobów crm res_name><hosta>: tworzy ograniczenia lokalizacji i może powodować problemy z przejęciem
  • res_name> czyszczenia <zasobów crm: czyści ograniczenia lokalizacji
  • res_name> oczyszczania <zasobów crm: czyści wszystkie błędy zasobu

Testowanie ogrodzenia SBD

W takim przypadku testujemy ogrodzenie SBD, które zalecamy w przypadku korzystania z systemu 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

Należy ponownie uruchomić węzeł klastra azibmdb01 . Podstawowa rola HADR ibm Db2 zostanie przeniesiona do azibmdb02. Gdy polecenie azibmdb01 wróci do trybu online, wystąpienie bazy danych Db2 przeniesie się w roli pomocniczego wystąpienia bazy danych.

Jeśli usługa Pacemaker nie uruchamia się automatycznie po ponownym uruchomieniu poprzedniego podstawowego elementu podstawowego, pamiętaj, aby uruchomić ją ręcznie za pomocą polecenia:

sudo service pacemaker start

Testowanie ręcznego przejęcia

Ręczne przejęcie można przetestować, zatrzymując usługę Pacemaker w węźle azibmdb01 :

service pacemaker stop

stan na 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 ]

Po przejściu w tryb failover możesz ponownie uruchomić usługę na serwerze azibmdb01.

service pacemaker start

Zabij proces Db2 w węźle, w ramach którego jest uruchamiana podstawowa baza danych 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

Wystąpienie db2 zakończy się niepowodzeniem, a program Pacemaker zgłosi następujący stan:

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

Program Pacemaker ponownie uruchamia podstawowe wystąpienie bazy danych Db2 w tym samym węźle lub przechodzi w tryb failover do węzła, w którym uruchomiono wystąpienie pomocniczej bazy danych, a zgłaszany jest błąd.

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

Zabij proces Db2 w węźle, w ramach którego uruchomiono wystąpienie pomocniczej bazy danych

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

azibmdb02:~ # kill -9

Węzeł zostaje przełączony w błąd określony i zgłoszono błąd

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

Wystąpienie bazy danych Db2 zostanie uruchomione ponownie w roli pomocniczej, do której przypisano wcześniej.

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

Zatrzymaj bazę danych za pomocą polecenia db2stop force w węźle, w ramach którego uruchomiono podstawowe wystąpienie bazy danych usługi 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 ]

Jako użytkownik db2<sid> wykonaj polecenie db2stop force:

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

Wykryto błąd

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

Wystąpienie pomocniczej bazy danych usługi DB2 HADR zostało podniesione do roli podstawowej.

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

Awaria maszyny wirtualnej z ponownym uruchomieniem w węźle z uruchomionym podstawowym wystąpieniem bazy danych usługi HADR

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

Program Pacemaker promuje wystąpienie pomocnicze do roli wystąpienia podstawowego. Stare wystąpienie podstawowe zostanie przeniesione do roli pomocniczej po pełnym przywróceniu maszyny wirtualnej, a wszystkie usługi zostaną w pełni przywrócone po ponownym uruchomieniu maszyny wirtualnej.

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 ]

Awaria maszyny wirtualnej, na której uruchomiono podstawowe wystąpienie bazy danych usługi HADR z "zatrzymaniem"

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

W takim przypadku program Pacemaker wykrywa, że węzeł z uruchomionym wystąpieniem podstawowej bazy danych nie odpowiada.

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 ]

Następnym krokiem jest sprawdzenie sytuacji podzielonego mózgu . Po ustaleniu, że węzeł, który ostatni raz uruchomił wystąpienie podstawowej bazy danych, nie działa, jest wykonywany tryb failover zasobów.

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 ]

W przypadku zatrzymania węzła należy ponownie uruchomić węzeł, który uległ awarii za pośrednictwem narzędzi usługi Azure Management (w witrynie Azure Portal, programie PowerShell lub interfejsie wiersza polecenia platformy Azure). Po powrocie węzła, który zakończył się niepowodzeniem, uruchamia wystąpienie bazy danych Db2 w roli pomocniczej.

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 ]

Następne kroki