Red Hat Enterprise Linux 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 授權問題 |
| 2002167 | Red Hat Enterprise Linux 7.x：安裝和升級 |
| 2694118 | Azure 上的 Red Hat Enterprise Linux HA 附加元件 |
| 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 工作負載規劃和部署檢查清單 |
| Red Hat Enterprise Linux 7 高可用性附加元件概觀 |
| 高可用性附加元件 管理員 |
| 高可用性附加元件參考 |
| RHEL 高可用性叢集的支持原則 - Microsoft Azure 虛擬機器 為叢集成員 |
| 在 Microsoft Azure 上安裝和設定 Red Hat Enterprise Linux 7.4（及更新版本）高可用性叢集 |
| 適用於 SAP 工作負載的 IBM Db2 Azure 虛擬機器 DBMS 部署 |
| IBM Db2 HADR 11.1 |
| IBM Db2 HADR 10.5 |
| RHEL 高可用性叢集的支持原則 - 管理叢集中的 IBM Db2 for Linux、Unix 和 Windows |
概觀
為了達到高可用性，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。
- 更新 RHEL Linux 並設定文件系統。
- 安裝和設定 Pacemaker。
- 設定 glusterfs 叢集 或 Azure NetApp Files
- 在 個別的叢集上安裝 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 | 虛擬IP或主機名用於 SAP 應用程式伺服器的連線。 db-virt-hostname，db-virt-ip。 |
| Azure 隔離 | 避免分裂大腦情況的方法已避免。 |
| Azure Load Balancer | Db2 資料庫的探查埠使用標準 （建議），探查埠 （我們建議 62500） 探查埠。 |
| 名稱解析 | 名稱解析在環境中的運作方式。 強烈建議使用 DNS 服務。 可以使用本機主機檔案。 |
如需 Azure 中 Linux Pacemaker 的詳細資訊，請參閱 在 Azure 中的 Red Hat Enterprise Linux 上設定 Pacemaker。
重要
針對 Db2 11.5.6 版和更新版本，強烈建議使用 IBM 的 Pacemaker 整合式解決方案。
Red Hat Enterprise Linux 上的部署
IBM Db2 LUW 的資源代理程式包含在 Red Hat Enterprise Linux Server HA Addon 中。 針對本檔中所述的設定，您應該使用 Red Hat Enterprise Linux for SAP。 Azure Marketplace 包含 Red Hat Enterprise Linux 7.4 for SAP 或更新版本的映射，可供您用來部署新的 Azure 虛擬機。 當您在 Azure VM Marketplace 中選擇 VM 映射時，請注意 Red Hat 透過 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 產品可用性矩陣中取得。 我們強烈建議 SAP 至少使用 Red Hat Enterprise Linux 7.4，因為此或更新版本的 Red Hat Enterprise Linux 版本有 Azure 相關的效能改善。
- 建立或選取資源群組。
- 建立或選取虛擬網路和子網。
- 為 SAP 虛擬機選擇適當的部署類型。 通常是具有彈性協調流程的虛擬機擴展集。
- 建立虛擬機 1。
- 在 Azure Marketplace 中使用 Red Hat Enterprise Linux for SAP 映射。
- 選取在步驟 3 中建立的擴展集、可用性區域或可用性設定組。
- 建立虛擬機 2。
- 在 Azure Marketplace 中使用 Red Hat Enterprise Linux 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 版本、堆疊組態或操作系統的其他篩選。
Red Hat 防火牆規則
Red Hat Enterprise Linux 預設會啟用防火牆。
#Allow access to SWPM tool. Rule is not permanent.
sudo firewall-cmd --add-port=4237/tcp
使用HADR設定IBM Db2 LUW的安裝提示
若要設定主要 IBM Db2 LUW 資料庫實例：
- 使用高可用性或分散式選項。
- 安裝 SAP ASCS/ERS 和資料庫實例。
- 備份新安裝的資料庫。
重要
記下安裝期間所設定的「資料庫通訊埠」。 這兩個資料庫實例的埠號碼都必須相同。
適用於 Azure 的 IBM Db2 HADR 設定
當您使用 Azure Pacemaker 隔離代理程式時，請設定下列參數：
- HADR 對等窗口持續時間 （秒） （HADR_PEER_WINDOW） = 240
- HADR 逾時值 （HADR_TIMEOUT） = 45
建議您根據初始故障轉移/接管測試，使用上述參數。 您必須測試故障轉移和接管這些參數設定的適當功能。 因為個別組態可能會有所不同，因此參數可能需要調整。
注意
針對具有正常啟動的 HADR 設定 IBM Db2：次要或待命資料庫實例必須啟動並執行，才能啟動主資料庫實例。
注意
針對 Azure 和 Pacemaker 特有的安裝和設定：透過 SAP Software Provisioning Manager 在安裝程序期間，IBM Db2 LUW 的高可用性有明確的問題：
- 請勿選取 IBM Db2 pureScale。
- 請勿針對多平台選取 [安裝 IBM Tivoli 系統自動化]。
- 請勿選取 [ 產生叢集組態檔]。
若要使用 SAP 同質系統複製程式設定待命資料庫伺服器，請執行下列步驟：
- 選取 [系統複製] 選項 [目標系統>分散式>資料庫實例]。>
- 選取 [同質系統] 作為複製方法，讓您可以使用備份來還原待命伺服器實例上的備份。
- 當您到達結束步驟以還原資料庫以進行同質系統複製時，請結束安裝程式。 從主要主機的備份還原資料庫。 所有後續的安裝階段都已在主資料庫伺服器上執行。
DB2 HADR 的 Red Hat 防火牆規則
新增防火牆規則以允許 DB2 的流量，以及 DB2 之間的流量，讓 HADR 能夠運作：
- 資料庫通訊埠。 如果使用分割區，也請新增這些埠。
- HADR 埠（DB2 參數的值HADR_LOCAL_SVC）。
- Azure 探查埠。
sudo firewall-cmd --add-port=<port>/tcp --permanent
sudo firewall-cmd --reload
IBM Db2 HADR 檢查
為了示範目的和本文所述的程序，資料庫 SID 是 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
在 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健康情況探查。
[A] 新增探查埠的防火牆規則：
sudo firewall-cmd --add-port=<probe-port>/tcp --permanent
sudo firewall-cmd --reload
建立 Pacemaker 叢集
若要為此 IBM Db2 伺服器建立基本的 Pacemaker 叢集，請參閱 在 Azure 中的 Red Hat Enterprise Linux 上設定 Pacemaker。
Db2 Pacemaker 設定
當您在節點失敗時使用 Pacemaker 進行自動故障轉移時，您必須據以設定 Db2 實例和 Pacemaker。 本節描述這種類型的組態。
下列專案前面會加上下列專案：
- [A]： 適用於所有節點
- [1]： 僅適用於節點 1
- [2]： 僅適用於節點 2
[A] Pacemaker 設定的必要條件：
使用 db2stop 的使用者 db2<sid> 關閉這兩部資料庫伺服器。
將 db2 sid> 使用者的殼層環境變更為 /bin/ksh：<
# Install korn shell: sudo yum install ksh # Change users shell: sudo usermod -s /bin/ksh db2<sid>
Pacemaker 設定
[1] IBM Db2 HADR 特定的 Pacemaker 設定：
# Put Pacemaker into maintenance mode sudo pcs property set maintenance-mode=true[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。 如需詳細資訊，請參閱具有 HADR 的 Red Hat KBAdb2資源失敗升級狀態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[1] 啟動 IBM Db2 資源：
讓 Pacemaker 脫離維護模式。
# Put Pacemaker out of maintenance-mode - that start IBM Db2 sudo pcs property set maintenance-mode=false[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
重要
您必須使用 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 共用或 GlusterFS，其中記錄會從這兩個節點寫入。 NFS 共用或 GlusterFS 必須具有高可用性。
您可以使用現有的高可用性 NFS 共用或 GlusterFS 進行傳輸或設定文件目錄。 如需詳細資訊，請參閱
- Red Hat Enterprise Linux 上的 Azure VM 上的 GlusterFS for SAP NetWeaver。
- Red Hat Enterprise Linux 上 Azure VM 上的 SAP NetWeaver 高可用性與適用於 SAP 應用程式的 Azure NetApp Files。
- Azure NetApp Files （若要建立 NFS 共用）。
測試叢集設定
本節說明如何測試 Db2 HADR 設定。 每個測試假設 IBM Db2 primary 是在 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 系統中的原始狀態記載於 Transaction DBACOCKPIT > 組態 > 概觀中，如下圖所示：
測試接管IBM Db2
重要
開始測試之前，請確定：
Pacemaker 沒有任何失敗的動作（計算機狀態）。
沒有位置條件約束（移轉測試的剩餘專案）。
IBM Db2 HADR 同步處理正在運作。 請洽詢使用者 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 系統中的原始狀態記載於 Transaction DBACOCKPIT > 組態 > 概觀中，如下圖所示：
使用「計算機資源移動」的資源移轉會建立位置條件約束。 在此情況下，位置條件約束會防止在 az-idb01 上執行 IBM Db2 實例。 如果未刪除位置條件約束，資源就無法容錯回復。
拿掉位置限制和待命節點將會在 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>：清除資源的所有錯誤
測試手動接管
您可以在 az-idb01 節點上停止 Pacemaker 服務，以測試手動接管：
systemctl stop pacemaker
az-ibdb02 上的 status
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
終止執行HADR主資料庫的節點上的 Db2 進程
#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 實例會在先前指派的次要角色中重新啟動。
在執行HADR主資料庫實例的節點上，透過 db2stop force 停止 DB
當使用者 db2<sid> 執行命令 db2stop force：
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 主資料庫實例且「停止」的 VM
#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