使用 Pacemaker 在 SUSE Linux Enterprise Server 上的 Azure VM 上，IBM Db2 LUW 的高可用性
高可用性和災害復原的 IBM Db2 for Linux、UNIX 和 Windows （LUW） 組態 包含一個執行主資料庫實例的節點，以及至少一個執行輔助資料庫實例的節點。 主資料庫實例的變更會同步或異步地復寫到輔助資料庫實例，視您的組態而定。
注意
本文包含 Microsoft 不再使用的詞彙參考。 從軟體中移除這些字詞時，我們會從本文中移除這些字詞。
本文說明如何部署及設定 Azure 虛擬機（VM）、安裝叢集架構，以及安裝具有 HADR 設定的 IBM Db2 LUW。
本文未涵蓋如何使用HADR或SAP軟體安裝來安裝和設定IBM Db2 LUW。 為了協助您完成這些工作，我們提供 SAP 和 IBM 安裝手冊的參考。 本文著重於 Azure 環境特有的部分。
支援的 IBM Db2 版本為 10.5 和更新版本，如 SAP 附注 1928533所述。
開始安裝之前，請參閱下列 SAP 附注和檔：
| SAP 附注 | 描述 |
|---|---|
| 1928533 | Azure 上的 SAP 應用程式：支援的產品和 Azure VM 類型 |
| 2015553 | Azure 上的 SAP：支援必要條件 |
| 2178632 | Azure 上 SAP 的主要監視計量 |
| 2191498 | Linux 上的 SAP 與 Azure：增強型監視 |
| 2243692 | Azure 上的 Linux （IaaS） VM：SAP 授權問題 |
| 1984787 | SUSE LINUX Enterprise Server 12：安裝注意事項 |
| 1999351 | 針對適用於 SAP 的增強型 Azure 監視進行疑難解答 |
| 2233094 | DB6：Azure 上使用 IBM Db2 for Linux、UNIX 和 Windows 的 SAP 應用程式 - 其他資訊 |
| 1612105 | DB6：使用HADR的 Db2 常見問題 |
| 文件 |
|---|
| SAP 社群 Wiki：具有適用於 Linux 的所有必要 SAP 附注 |
| 適用於 Sap on Linux 的 Azure 虛擬機器 規劃和實作指南 |
| 適用於 Linux 上 SAP 的 Azure 虛擬機器 部署 （本文） |
| 適用於Linux上的SAP的 Azure 虛擬機器 資料庫管理系統（DBMS） 部署指南 |
| Azure 上的 SAP 工作負載規劃和部署檢查清單 |
| SUSE Linux Enterprise Server for SAP Applications 12 SP4 最佳做法指南 |
| SUSE Linux Enterprise 高可用性擴充功能 12 SP4 |
| 適用於 SAP 工作負載的 IBM Db2 Azure 虛擬機器 DBMS 部署 |
| IBM Db2 HADR 11.1 |
| IBM Db2 HADR R 10.5 |
概觀
為了達到高可用性，IBM Db2 LUW 搭配 HADR 安裝在至少兩部 Azure 虛擬機上，這些虛擬機部署在具有跨可用性區域或可用性設定組中彈性協調流程的虛擬機擴展集中。
下圖顯示兩部資料庫伺服器 Azure VM 的設定。 兩部資料庫伺服器 Azure VM 都已連結自己的記憶體，且已啟動並執行。 在HADR中，其中一個 Azure VM 中的一個資料庫實例具有主要實例的角色。 所有客戶端都會連線到這個主要實例。 資料庫交易中的所有變更都會保存在 Db2 事務歷史記錄中本機。 當事務歷史記錄記錄保存在本機時，記錄會透過 TCP/IP 傳輸到第二部資料庫伺服器、待命伺服器或待命實例上的資料庫實例。 待命實例會向前復原傳輸的事務歷史記錄記錄來更新本機資料庫。 如此一來，待命伺服器會與主伺服器保持同步。
HADR 只是復寫功能。 它沒有失敗偵測，也沒有自動接管或故障轉移設施。 資料庫管理員必須手動起始接管或傳輸至待命伺服器。 若要達到自動接管和失敗偵測，您可以使用Linux Pacemaker叢集功能。 Pacemaker 會監視兩個資料庫伺服器實例。 當主資料庫伺服器實例當機時，Pacemaker 會 起始待命伺服器自動 接管HADR。 Pacemaker 也會確保虛擬IP位址已指派給新的主伺服器。
若要讓 SAP 應用程式伺服器連線到主資料庫，您需要虛擬主機名和虛擬 IP 位址。 故障轉移之後，SAP 應用程式伺服器會連線到新的主資料庫實例。 在 Azure 環境中， Azure 負載平衡器 必須以 IBM Db2 HADR 所需的方式使用虛擬 IP 位址。
為了協助您充分瞭解具有 HADR 和 Pacemaker 的 IBM Db2 LUW 如何融入高可用性 SAP 系統設定，下圖概述以 IBM Db2 資料庫為基礎的 SAP 系統高可用性設定。 本文僅涵蓋 IBM Db2，但它提供有關如何設定 SAP 系統其他元件之其他文章的參考。
必要步驟的高階概觀
若要部署 IBM Db2 設定，您必須遵循下列步驟：
- 規劃您的環境。
- 部署 VM。
- 更新 SUSE Linux 並設定檔案系統。
- 安裝和設定 Pacemaker。
- 安裝 高可用性 NFS。
- 在 個別的叢集上安裝 ASCS/ERS。
- 安裝具有分散式/高可用性選項的 IBM Db2 資料庫（SWPM）。
- 安裝和建立輔助資料庫節點和實例，並設定HADR。
- 確認HADR正在運作。
- 套用 Pacemaker 設定來控制 IBM Db2。
- 設定 Azure Load Balancer。
- 安裝主要和對話框應用程式伺服器。
- 檢查並調整 SAP 應用程式伺服器的組態。
- 執行故障轉移和接管測試。
規劃使用HADR裝載IBM Db2 LUW的 Azure 基礎結構
在執行部署之前，請先完成規劃程式。 規劃會建置在 Azure 中使用 HADR 部署 Db2 設定的基礎。 下表列出需要規劃 IMB Db2 LUW（SAP 環境的資料庫部分）的重要元素：
| 主題 | 簡短描述 |
|---|---|
| 定義 Azure 資源群組 | 部署 VM、虛擬網路、Azure Load Balancer 和其他資源的資源群組。 可以是現有或新的。 |
| 虛擬網路/子網定義 | IBM Db2 和 Azure Load Balancer 的 VM 正在部署的位置。 可以是現有或新建立的。 |
| 裝載IBM Db2 LUW 的虛擬機 | VM 大小、記憶體、網路功能、IP 位址。 |
| IBM Db2 資料庫的虛擬主機名和虛擬IP | 用於連線 SAP 應用程式伺服器的虛擬 IP 或主機名。 db-virt-hostname，db-virt-ip。 |
| Azure 隔離 | Azure 擊劍或 SBD 擊劍（強烈建議使用）。 避免分裂大腦情況的方法。 |
| SBD VM | SBD 虛擬機大小、記憶體、網路。 |
| Azure Load Balancer | Db2 資料庫的探查埠使用標準 （建議），探查埠 （我們建議 62500） 探查埠。 |
| 名稱解析 | 名稱解析在環境中的運作方式。 強烈建議使用 DNS 服務。 可以使用本機主機檔案。 |
如需 Azure 中 Linux Pacemaker 的詳細資訊，請參閱 在 Azure 中的 SUSE Linux Enterprise Server 上設定 Pacemaker。
重要
針對 Db2 11.5.6 版和更新版本，強烈建議使用 IBM 的 Pacemaker 整合式解決方案。
- 使用 Pacemaker 的整合式解決方案。
- Microsoft Azure 上可用的替代或其他組態。
SUSE Linux 上的部署
IBM Db2 LUW 的資源代理程式包含在 SUSE Linux Enterprise Server for SAP Applications 中。 針對本檔中所述的設定，您必須使用 SUSE Linux Server for SAP Applications。 Azure Marketplace 包含 SUSE Enterprise Server for SAP Applications 12 的映射，可供您用來部署新的 Azure 虛擬機。 當您在 Azure VM Marketplace 中選擇 VM 映射時，請注意 SUSE 透過 Azure Marketplace 提供的各種支援或服務模型。
主機：DNS 更新
列出所有主機名，包括虛擬主機名，並更新您的 DNS 伺服器，以啟用適當的 IP 位址進行主機名解析。 如果 DNS 伺服器不存在，或您無法更新和建立 DNS 專案，您必須使用參與此案例之個別 VM 的本機主機檔案。 如果您使用主機檔案專案，請確定專案會套用至 SAP 系統環境中的所有 VM。 不過，建議您使用您的 DNS，在理想情況下延伸至 Azure
手動部署
請確定IBM/SAP for IBM Db2 LUW 支援選取的OS。 SAP 附註 1928533提供適用於 Azure VM 和 Db2 版本的支援 OS 版本清單。 個別 Db2 版本的 OS 版本清單可在 SAP 產品可用性矩陣中取得。 強烈建議至少使用 SLES 12 SP4，因為此或更新版本的 SUSE Linux 版本有 Azure 相關的效能改善。
- 建立或選取資源群組。
- 建立或選取虛擬網路和子網。
- 為 SAP 虛擬機選擇適當的部署類型。 通常是具有彈性協調流程的虛擬機擴展集。
- 建立虛擬機 1。
- 在 Azure Marketplace 中使用 SLES for SAP 映像。
- 選取在步驟 3 中建立的擴展集、可用性區域或可用性設定組。
- 建立虛擬機 2。
- 在 Azure Marketplace 中使用 SLES for SAP 映像。
- 選取在步驟 3 中建立的擴展集、可用性區域或可用性設定組（與步驟 4 中建立的區域不同）。
- 將數據磁碟新增至 VM，然後在 IBM Db2 Azure 虛擬機器 SAP 工作負載的 DBMS 部署一文中檢查文件系統設定的建議。
安裝IBM Db2 LUW 和 SAP 環境
在您根據 IBM Db2 LUW 開始安裝 SAP 環境之前，請先檢閱下列檔：
- Azure 文件
- SAP 檔
- IBM 檔
本文簡介一節提供此文件的連結。
請查看 SAP 安裝手冊，以在 IBM Db2 LUW 上安裝 NetWeaver 型應用程式。
您可以使用 SAP 安裝指南尋找工具，在 SAP 說明入口網站上找到指南。
您可以藉由設定下列篩選來減少入口網站中顯示的指南數目：
- 我想：“安裝新系統”
- 我的資料庫：“IBM Db2 for Linux、Unix 和 Windows”
- SAP NetWeaver 版本、堆疊組態或操作系統的其他篩選
使用HADR設定IBM Db2 LUW的安裝提示
若要設定主要 IBM Db2 LUW 資料庫實例：
- 使用高可用性或分散式選項。
- 安裝 SAP ASCS/ERS 和資料庫實例。
- 備份新安裝的資料庫。
重要
記下安裝期間所設定的「資料庫通訊埠」。 這兩個資料庫實例的埠號碼都必須相同 
若要使用 SAP 同質系統複製程式設定待命資料庫伺服器，請執行下列步驟：
選取 [系統複製] 選項 [目標系統>分散式>資料庫實例]。>
選取 [同質系統] 作為複製方法，讓您可以使用備份來還原待命伺服器實例上的備份。
當您到達結束步驟以還原資料庫以進行同質系統複製時，請結束安裝程式。 從主要主機的備份還原資料庫。 所有後續的安裝階段都已在主資料庫伺服器上執行。
設定IBM Db2的HADR。
注意
針對 Azure 和 Pacemaker 特有的安裝和設定：透過 SAP Software Provisioning Manager 在安裝程序期間，IBM Db2 LUW 的高可用性有明確的問題：
- 請勿選取 IBM Db2 pureScale。
- 請勿針對多平台選取 [安裝 IBM Tivoli 系統自動化]。
- 請勿選取 [ 產生叢集組態檔]。
當您使用適用於 Linux Pacemaker 的 SBD 裝置時，請設定下列 Db2 HADR 參數：
- HADR 對等窗口持續時間 （秒） （HADR_PEER_WINDOW） = 300
- HADR 逾時值 （HADR_TIMEOUT） = 60
當您使用 Azure Pacemaker 隔離代理程式時，請設定下列參數：
- HADR 對等窗口持續時間 （秒） （HADR_PEER_WINDOW） = 900
- HADR 逾時值 （HADR_TIMEOUT） = 60
建議您根據初始故障轉移/接管測試，使用上述參數。 您必須測試故障轉移和接管這些參數設定的適當功能。 因為個別組態可能會有所不同，因此參數可能需要調整。
重要
針對具有正常啟動的 HADR 設定 IBM Db2：次要或待命資料庫實例必須啟動並執行，才能啟動主資料庫實例。
為了示範目的和本文所述的程序，資料庫 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
在 VM 設定期間，您可以選擇在網路區段中建立或選取結束的負載平衡器。 請遵循下列步驟來設定標準負載平衡器，以設定 DB2 資料庫的高可用性設定。
遵循建立負載平衡器指南，使用 Azure 入口網站 為高可用性 SAP 系統設定標準負載平衡器。 在設定負載平衡器期間，請考慮下列幾點。
- 前端IP組態： 建立前端IP。 選取與 DB 虛擬機相同的虛擬網路和子網。
- 後端集區： 建立後端集區並新增 DB VM。
- 輸入規則： 建立負載平衡規則。 針對這兩個負載平衡規則，請遵循相同的步驟。
- 前端IP位址：選取前端IP
- 後端集區：選取後端集區
- 檢查「高可用性埠」
- 通訊協定：TCP
- 健康情況探查：使用下列詳細數據建立健康情況探查
- 通訊協定：TCP
- 埠：[例如：625<實例否。>]
- 間隔：5
- 探查臨界值：2
- 閑置逾時（分鐘）：30
- 檢查 [啟用浮動 IP]
注意
健康情況探查組態屬性 numberOfProbes，否則在入口網站中稱為「狀況不良閾值」，則不會受到尊重。 因此，若要控制連續探查成功或失敗的數目，請將屬性 “probeThreshold” 設定為 2。 目前無法使用 Azure 入口網站 來設定此屬性，因此請使用 Azure CLI 或 PowerShell 命令。
重要
負載平衡案例中的 NIC 次要IP組態不支援浮動IP。 如需詳細資訊，請參閱 Azure Load Balancer 限制。 如果您需要 VM 的另一個 IP 位址，請部署第二個 NIC。
注意
當沒有公用IP位址的VM放在標準 Azure Load Balancer 內部（無公用IP位址）實例的後端集區時，除非執行更多組態以允許路由傳送至公用端點，否則不會有輸出因特網連線能力。 如需如何達成輸出連線的詳細資訊，請參閱 SAP 高可用性案例中使用 Azure Standard Load Balancer 的 VM 公用端點連線。
重要
請勿在位於 Azure Load Balancer 後方的 Azure VM 上啟用 TCP 時間戳。 啟用 TCP 時間戳可能會導致健康情況探查失敗。 將參數 net.ipv4.tcp_timestamps 設定為 0。 如需詳細資訊，請參閱 Load Balancer健康情況探查。
建立 Pacemaker 叢集
若要為此 IBM Db2 伺服器建立基本 Pacemaker 叢集，請參閱 在 Azure 中的 SUSE Linux Enterprise Server 上設定 Pacemaker。
Db2 Pacemaker 設定
當您在節點失敗時使用 Pacemaker 進行自動故障轉移時，您必須據以設定 Db2 實例和 Pacemaker。 本節描述這種類型的組態。
下列專案前面會加上下列專案：
- [A]： 適用於所有節點
- [1]： 僅適用於節點 1
- [2]： 僅適用於節點 2
[A] Pacemaker 設定的必要條件：
- 使用 db2stop 的使用者 db2<sid> 關閉這兩部資料庫伺服器。
- 將 db2 sid> 使用者的殼層環境變更為 /bin/ksh。< 我們建議您使用 Yast 工具。
Pacemaker 設定
重要
最近的測試顯示，netcat 因待處理專案而停止回應要求的情況，以及只處理一個連線的限制。 netcat 資源會停止接聽 Azure Load Balancer 要求，而浮動 IP 變成無法使用。 針對現有的 Pacemaker 叢集，我們過去建議使用 socat 取代 netcat。 目前，建議您使用屬於套件資源代理程式的 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 偵測強化中所述，就不需要立即切換至 azure-lb 資源代理程式。
[1] IBM Db2 HADR 特定的 Pacemaker 設定：
# Put Pacemaker into maintenance mode sudo crm configure property maintenance-mode=true[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[1] 啟動 IBM Db2 資源：
讓 Pacemaker 脫離維護模式。
# Put Pacemaker out of maintenance-mode - that start IBM Db2 sudo crm configure property maintenance-mode=false[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 ]
重要
您必須使用 Pacemaker 工具來管理 Pacemaker 叢集 Db2 實例。 如果您使用 db2stop 之類的 db2 命令，Pacemaker 會將動作偵測為資源失敗。 如果您正在執行維護，您可以將節點或資源置於維護模式。 Pacemaker 會暫停監視資源，然後您可以使用一般的 db2 系統管理命令。
變更 SAP 設定檔以使用虛擬 IP 進行連線
若要連線到HADR組態的主要實例，SAP 應用層必須使用您為 Azure Load Balancer 定義和設定的虛擬IP位址。 需要下列變更：
/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 堆疊執行如下。
ABAP+Java 或 Java 堆疊系統 JDBC URL 檢查
使用 J2EE 組態工具來檢查或更新 JDBC URL。 由於 J2EE 組態工具是圖形化工具，因此您必須安裝 X 伺服器：
登入 J2EE 實例的主要應用程式伺服器，然後執行：
sudo /usr/sap/*SID*/*Instance*/j2ee/configtool/configtool.sh在左框架中，選擇 安全性存放區。
在正確的框架中，選擇密鑰 jdbc/pool/<SAPSID>/url。
將 JDBC URL 中的主機名變更為虛擬主機名。
jdbc:db2://db-virt-hostname:5912/TSP:deferPrepares=0選取新增。
若要儲存變更，請選取左上方的磁碟圖示。
關閉組態工具。
重新啟動Java實例。
設定HADR設定的記錄封存
若要設定 HADR 設定的 Db2 記錄封存，建議您同時設定主資料庫和待命資料庫，讓所有記錄封存位置都有自動記錄擷取功能。 主資料庫和待命資料庫都必須能夠從其中一個資料庫實例封存記錄檔的所有記錄封存位置擷取記錄封存盤案。
記錄封存只會由主資料庫執行。 如果您變更資料庫伺服器的HADR角色，或發生失敗，新的主資料庫會負責記錄封存。 如果您已設定多個記錄封存位置，記錄可能會封存兩次。 在本機或遠端追趕時，您可能也必須手動將封存的記錄從舊主伺服器複製到新主伺服器的使用中記錄位置。
建議您設定從這兩個節點寫入記錄的一般NFS共用。 NFS 共用必須具有高可用性。
您可以針對傳輸或設定檔目錄使用現有的高可用性 NFS 共用。 如需詳細資訊，請參閱
- SUSE Linux Enterprise Server 上 Azure VM 上的 NFS 高可用性。
- SUSE Linux Enterprise Server 上的 Azure VM 上的 SAP NetWeaver 高可用性與適用於 SAP 應用程式的 Azure NetApp Files。
- Azure NetApp Files （若要建立 NFS 共用）。
測試叢集設定
本節說明如何測試 Db2 HADR 設定。 每個測試都假設您已以使用者根目錄身分登入，而 IBM Db2 primary 是在 az ibmdb01 虛擬機上執行。
此處將說明所有測試案例的初始狀態：（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 系統中的原始狀態記載於 Transaction DBACOCKPIT > 組態 > 概觀中，如下圖所示：
測試接管IBM Db2
重要
開始測試之前，請確定：
Pacemaker 沒有任何失敗的動作（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 系統中的原始狀態記載於 Transaction DBACOCKPIT > 組態 > 概觀中，如下圖所示：
使用 「crm resource migrate」 的資源移轉會建立位置條件約束。 應刪除位置條件約束。 如果未刪除位置條件約束，資源就無法容錯回復，或者您可能會遇到不必要的接管。
將資源移回 azibmdb01 ，並清除位置條件約束
crm resource migrate msl_Db2_db2ptr_PTR azibmdb01
crm resource clear msl_Db2_db2ptr_PTR
- crm 資源遷移 <res_name><主機>： 建立位置限制，並可能導致接管問題
- crm 資源清除 <res_name>：清除位置條件約束
- crm 資源清除 <res_name>：清除資源的所有錯誤
測試 SBD 隔離
在此情況下，我們會測試 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角色將會移至 az ibmdb02。 當 azibmdb01 重新上線時，Db2 實例將會在輔助資料庫實例的角色中移動。
如果 Pacemaker 服務未在重新啟動的前主要複本上自動啟動，請務必以手動方式啟動：
sudo service pacemaker start
測試手動接管
您可以停止 azibmdb01 節點上的 Pacemaker 服務，以測試手動接管：
service pacemaker stop
azibmdb02 上的 status
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
終止執行HADR主資料庫的節點上的 Db2 進程
#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
在執行HADR主資料庫實例的節點上，透過 db2stop force 停止 DB
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 ]
當使用者 db2<sid> 執行命令 db2stop force：
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主資料庫實例的節點上重新啟動時當機 VM
#Linux kernel panic - with OS restart
azibmdb01:~ # echo b > /proc/sysrq-trigger
Pacemaker 會將次要實例升階為主要實例角色。 舊的主要實例會在 VM 重新啟動後完全還原所有服務之後移至次要角色。
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 主資料庫實例且「停止」的 VM
#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 管理工具重新啟動失敗的節點（在 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 ]