在 Google Cloud上為 SAP 設定高可用性時，問題的根本原因可能出在叢集軟體、SAP 軟體、 Google Cloud 基礎架構，或是這些項目的組合。
在 Cloud Logging 中分析 Pacemaker 記錄檔
以下影片說明如何使用 Cloud Logging 開始排解 SAP 在 Google Cloud上的高可用性設定問題。
Linux 叢集中的失敗節點在容錯移轉後無法正常重新啟動
如果 Linux 高可用性叢集使用 fence_gce 圍欄代理程式，且圍欄 VM 在容錯移轉後無法重新加入叢集，您可能需要在圍欄 VM 重新啟動時延遲啟動 Corosync 軟體。
問題
在容錯期間，fence_gce 代理程式會將失敗的 Compute Engine VM 隔離，並在 Pacemaker 將隔離動作登錄為完成前，重新啟動並重新加入叢集。由於柵欄動作未註冊為已完成，因此重新啟動的 VM 會關閉 Pacemaker 和 Corosync 服務，並離開叢集。
診斷
如要確認這是否為你的問題，請按照下列步驟操作：
確認叢集是否使用
fence_gce代理程式：RHEL
pcs config
SLES
crm config show
圍欄代理程式定義包含
fence_gce。RHEL
Stonith Devices: Resource: STONITH-example-ha-vm1 (class=stonith type=fence_gce) Attributes: port=example-ha-vm1 project=example-project-123456 zone=us-central1-a Operations: monitor interval=300s timeout=120s (STONITH-example-ha-vm1-monitor-interval-60s) Resource: STONITH-example-ha-vm2 (class=stonith type=fence_gce) Attributes: port=example-ha-vm2 project=example-project-123456 zone=us-central1-c Operations: monitor interval=300s timeout=120s (STONITH-example-ha-vm2-monitor-interval-60s)
SLES
primitive fence-example-ha-vm1 stonith:fence_gce \ op monitor interval=300s timeout=120s \ op start interval=0 timeout=60s \ params port=example-ha-vm1 zone=us-central1-a project=example-project-123456 primitive fence-example-ha-vm2 stonith:fence_gce \ op monitor interval=300s timeout=120s \ op start interval=0 timeout=60s \ params port=example-ha-vm2 zone=us-central1-c project=example-project-123456
請查看系統記錄，確認是否有下列訊息：
DATESTAMP> node2 stonith-ng[1106]: notice: Operation reboot of node2 by node1 for stonith_admin.1366@node1.c3382af8: OK DATESTAMP> node2 stonith-ng[1106]: error: stonith_construct_reply: Triggered assert at commands.c:2343 : request != NULL DATESTAMP> node2 stonith-ng[1106]: warning: Can't create a sane reply DATESTAMP> node2 crmd[1110]: crit: We were allegedly just fenced by node1 for node1! DATESTAMP> node2 pacemakerd[1055]: warning: Shutting cluster down because crmd[1110] had fatal failure
解決方案
請在兩個叢集節點中設定作業系統，以便延遲 Corosync 的啟動，確保柵欄動作有時間在新的主節點上註冊為 Pacemaker 完成。此外，請設定 Pacemaker 重新啟動逾時值，以便考量延遲時間。
如要設定 Corosync 延遲啟動，請按照下列步驟操作：
將叢集切換成維護模式：
RHEL
pcs property set maintenance-mode=true
SLES
crm configure property maintenance-mode="true"
在每個叢集節點上以 root 身分，為 Corosync 設定啟動延遲時間：
建立
systemd插入檔案：systemctl edit corosync.service
在檔案中新增下列幾行內容：
[Service] ExecStartPre=/bin/sleep 60
儲存檔案並結束編輯器。
重新載入 systemd 管理員設定。
systemctl daemon-reload
在任一叢集節點上以 root 身分，確認重新啟動作業的 Pacemaker 逾時值已為兩個邊界代理程式設定：
檢查
pcmk_reboot_timeout值：crm_resource --resource FENCE_AGENT_NAME --get-parameter=pcmk_reboot_timeout
請將
FENCE_AGENT_NAME替換為圍欄代理程式名稱。如果找不到
pcmk_reboot_timeout參數，或是該參數的值小於 300，請在兩個邊界代理程式上設定值：crm_resource --resource FENCE_AGENT_NAME --set-parameter=pcmk_reboot_timeout --parameter-value=300
請將
FENCE_AGENT_NAME替換為圍欄代理程式名稱。pcmk_reboot_timeout值應大於下列項目的總和：- Corosync
token逾時 - Corosync 共識逾時時間，預設為
token* 1.2 - 重新啟動作業所需的時間長度，包括任何延遲屬性。
在 Google Cloud上，300 秒就足以處理大多數叢集。
- Corosync
確認新的
pcmk_reboot_timeout值：crm_resource --resource FENCE_AGENT_NAME --get-parameter=pcmk_reboot_timeout
請將
FENCE_AGENT_NAME替換為圍欄代理程式名稱。
將叢集移出維護模式：
RHEL
pcs property set maintenance-mode=false
SLES
crm configure property maintenance-mode="false"
無意偏好特定節點的節點相依性
當您使用叢集指令手動移動高可用性叢集中的資源時，會發現自動親和性或用戶端偏好設定會偏好特定節點。
問題
在 SAP HANA 或 SAP NetWeaver 適用的 Linux Pacemaker 高可用性叢集中，SAP HANA 系統或 SAP NetWeaver 中央服務等資源只會在特定叢集節點上執行，且不會在節點故障事件期間如預期進行容錯移轉。
因此，您可能會遇到下列問題：
當您透過發出 Pacemaker 指令，將資源
move至叢集節點，觸發 SAP NetWeaver ASCS 服務故障轉移時，資源不會啟動，並顯示狀態stopped。當您向一個叢集節點發出
standby指令，強制所有資源移至另一個節點時，資源不會啟動。
診斷
請查看 Pacemaker 記錄，找出提及特定資源無法在任何位置執行的訊息。例如：
2021-05-24 21:39:58 node_1 pacemaker-schedulerd (native_color) info: Resource NW1-ASCS01 cannot run anywhere
請檢查 Pacemaker 位置限制設定，找出可能導致資源無法在特定叢集節點上執行的任何限制。
如要檢查 Pacemaker 位置限制設定，請按照下列步驟操作：
顯示位置限制：
cibadmin --query --scope constraints | grep rsc_location
驗證位置限制：
明確的位置限制：您可以使用分數
INFINITY(偏好節點) 或-INFINITY(避免節點) 找到位置限制。例如：<rsc_location id="loc-constraint" rsc="NW1-ASCS01" score="INFINITY" node="nw-ha-1"/>
除了圍欄代理程式外，任何位置限制不得使用分數
INFINITY或-INFINITY。在所有 HA 叢集中，邊界代理程式會在評分為-INFINITY的位置限制中定義，以免在邊界目標節點上執行。隱含位置限制：當您發出 Pacemaker 指令，將資源移至叢集節點，或禁止資源在叢集節點上執行時，系統會在限制 ID 中新增前置字元為
cli-ban或cli-prefer的隱含位置限制。例如：<rsc_location id="cli-prefer-NW1-ASCS01" rsc="NW1-ASCS01" role="Started" node="nw-ha-2" score="INFINITY"/>
解決方案
請務必按照我們的部署指南說明指定位置限制：
如要修正明確的位置限制，請刪除位置限制：
RHEL
pcs constraint remove RESOURCE_LOCATION_ID
SLES
crm configure delete RESOURCE_LOCATION_ID
將
RESOURCE_LOCATION_ID替換為位置限制 ID。如要修正隱含位置限制，請移除指定資源上定義的所有限制。
在每個用於移動或禁止資源的指令後，請執行下列指令來移除所有限制：
RHEL
pcs resource clear RESOURCE_NAME
SLES
crm resource clear RESOURCE_NAME
將
RESOURCE_NAME替換為您要移動的資源名稱。
圍欄代理程式發生作業錯誤
圍欄代理程式已回報叢集狀態中的錯誤。
問題
在 SAP HANA 或 SAP NetWeaver 適用的 Linux Pacemaker 高可用性叢集中，柵欄代理程式已回報叢集狀態錯誤。例如：
Failed Resource Actions: STONITH-ha-node-01_monitor_300000 on ha-node-02 'unknown error' (1): call=153, status=Timed Out, exitreason='', last-rc-change='Mon Dec 21 23:40:47 2023', queued=0ms, exec=60003ms
診斷
在 SAP HANA 或 SAP NetWeaver 高可用性叢集中部署的圍欄代理程式會定期存取 Compute Engine API 伺服器，以便檢查圍欄目標執行個體的狀態。如果 API 呼叫回應暫時延遲，或發生網路中斷，則圍欄代理程式監控作業可能會失敗或逾時。
如要檢查圍欄代理程式狀態，請執行下列指令：
RHEL
pcs status
SLES
crm status
如果圍欄代理程式狀態為 stopped，請使用其中一種解決方案選項來解決錯誤。
圍欄代理程式操作錯誤可能會導致圍欄代理程式停止，但 Pacemaker 仍會在圍欄事件中以停止指令呼叫圍欄代理程式。
解決方案
如果圍欄代理程式狀態為 stopped，請執行下列任一操作：
如要手動重設失敗次數並重新啟動圍欄代理程式，請執行下列指令：
RHEL
pcs resource cleanup FENCE_AGENT_NAME
SLES
crm resource cleanup FENCE_AGENT_NAME
將
FENCE_AGENT_NAME替換為圍欄代理程式名稱。如要自動移除圍欄代理程式操作錯誤，請設定
failure-timeout參數。failure-timeout參數會在指定時間後重設失敗次數，並清除任何作業錯誤。套用這個參數時，您不需要重新啟動叢集或將叢集設為維護模式。如要設定
failure-timeout參數，請執行下列指令：crm_resource --meta --resource FENCE_AGENT_NAME --set-parameter failure-timeout --parameter-value DURATION
更改下列內容：
FENCE_AGENT_NAME：圍欄代理程式名稱。DURATION：上次作業失敗後的持續時間，之後會重設 failcount 並重新啟動圍欄代理程式。
已淘汰圍欄代理程式 gcpstonith
圍欄代理程式 gcpstonith 在您的設定中處於啟用狀態。這個代理程式已淘汰，客戶服務團隊已告知您必須改用 fence_gce。
問題
在 SUSE Linux 上 SAP HANA 適用的 Linux Pacemaker 高可用性叢集中，會使用圍欄代理程式 gcpstonith。例如：
# crm status | grep gcpstonith * STONITH-hana-vm1 (stonith:external/gcpstonith): Started hana-vm2 * STONITH-hana-vm2 (stonith:external/gcpstonith): Started hana-vm1
診斷
您需要更新在 SAP HANA 高可用性叢集中部署的圍欄代理程式，改為使用 OS 隨附的 fence_gce 圍欄代理程式。gcpstonith 代理程式指令碼已在舊版系統中提供，並已由 fence_gce 取代。fence_gce 是 fence-agents SUSE Linux 套件的一部分。gcpstonith 僅會隨 SUSE Linux HANA 部署作業一併提供。
解決方案
如要在 SUSE Linux 上從 gcpstonith 遷移，請完成下列步驟：
安裝下列作業系統專屬的其他套件：
SLES 15：
python3-oauth2client和python3-google-api-python-clientSLES 12：
python-google-api-python-client、python-oauth2client和python-oauth2client-gce
如要在作業系統上安裝這些套件，請使用下列指令：
SLES 15
zypper in -y python3-oauth2client python3-google-api-python-client
SLES 12
zypper in -y python-google-api-python-client python-oauth2client python-oauth2client-gce
更新
fence-agents套件，確保已安裝最新版本：zypper update -y fence-agents
將叢集置於維護模式：
crm configure property maintenance-mode=true
從叢集中刪除所有圍欄裝置。刪除最後一個圍欄裝置時，系統可能會提示您確認叢集中未定義任何
STONITH資源。crm configure delete FENCING_RESOURCE_PRIMARY
crm configure delete FENCING_RESOURCE_SECONDARY
重新建立主要執行個體的圍欄裝置：
crm configure primitive FENCING_RESOURCE_PRIMARY stonith:fence_gce \ op monitor interval="300s" timeout="120s" \ op start interval="0" timeout="60s" \ params port="PRIMARY_INSTANCE_NAME" zone="PRIMARY_ZONE" \ project="PROJECT_ID" \ pcmk_reboot_timeout=300 pcmk_monitor_retries=4 pcmk_delay_max=30
重新建立次要執行個體的圍欄裝置：
crm configure primitive FENCING_RESOURCE_SECONDARY stonith:fence_gce \ op monitor interval="300s" timeout="120s" \ op start interval="0" timeout="60s" \ params port="SECONDARY_INSTANCE_NAME" zone="SECONDARY_ZONE" \ project="PROJECT_ID" \ pcmk_reboot_timeout=300 pcmk_monitor_retries=4
設定位置限制：
crm configure location FENCING_LOCATION_NAME_PRIMARY \ FENCING_RESOURCE_PRIMARY -inf: "PRIMARY_INSTANCE_NAME" crm configure location FENCING_LOCATION_NAME_SECONDARY \ FENCING_RESOURCE_SECONDARY -inf: "SECONDARY_INSTANCE_NAME"
將叢集移出維護模式：
crm configure property maintenance-mode=false
檢查設定：
crm config show related:FENCING_RESOURCE_PRIMARY
檢查叢集狀態：
# crm status | grep fence_gce STONITH-hana-vm1 (stonith:fence_gce): Started hana-vm2 STONITH-hana-vm2 (stonith:fence_gce): Started hana-vm1
資源服務代理已停止
資源代理程式無法啟動，並維持 Stopped 狀態。
問題
在 SAP HANA 或 SAP NetWeaver 適用的 Linux Pacemaker 高可用性叢集中，資源代理程式已回報叢集狀態中的錯誤。例如：
Failed Resource Actions: rsc_SAPHana_DV0_HDB00_start_0 on ha-node-02 'error' (1): call=91, status='complete', last-rc-change='Wed Oct 18 18:00:31 2023', queued=0ms, exec=19010ms
診斷
如果執行中的資源代理程式發生錯誤，Pacemaker 會嘗試停止代理程式，然後重新啟動。如果啟動作業因任何原因失敗，Pacemaker 會將資源失敗計數器設為 INFINITY，並嘗試在其他節點上啟動代理程式。如果資源代理程式無法在任何節點上啟動，則資源代理程式會維持 Stopped 狀態。
如要檢查資源代理程式狀態，請執行下列指令：
RHEL
pcs status
SLES
crm status
以 SAP HANA 為例，以下範例顯示資源代理程式在節點 hana-b 上處於 Stopped 狀態：
Full List of Resources:
* STONITH-hana-a (stonith:fence_gce): Started hana-b
* STONITH-hana-b (stonith:fence_gce): Started hana-a
* Resource Group: g-primary:
* rsc_vip_int-primary (ocf::heartbeat:IPaddr2): Started hana-a
* rsc_vip_hc-primary (ocf::heartbeat:anything): Started hana-a
* Clone Set: cln_SAPHanaTopology_DV0_HDB00 [rsc_SAPHanaTopology_DV0_HDB00]:
* Started: [ hana-a hana-b ]
* Clone Set: msl_SAPHana_DV0_HDB00 [rsc_SAPHana_DV0_HDB00] (promotable):
* Masters: [ hana-a ]
* Stopped: [ hana-b ]
* STONITH-scaleup-majority (stonith:fence_gce): Started hana-b
解決方案
如果資源代理程式處於 Stopped 狀態，請執行下列操作：
藉由重設失敗次數，手動啟動資源代理程式：
RHEL
pcs resource cleanup RESOURCE_AGENT_NAME
SLES
crm resource cleanup RESOURCE_AGENT_NAME
將
RESOURCE_AGENT_NAME替換為資源代理程式名稱。例如rsc_SAPHana_DV0_HDB00。確認資源代理程式已達到
Started狀態：crm_mon
如果資源代理程式仍無法啟動，請收集相關診斷資訊，然後與支援團隊聯絡。
虛擬 IP 的本機網路路徑導致 VM 之間的通訊失敗
由於虛擬 IP 的本機網路路徑，導致從一個後端 VM 傳送至另一個 VM 的網路流量失敗。
問題
如果 VM 是內部直通式網路負載平衡器的一部分，後端網路通訊會將 ILB 虛擬 IP (VIP) 路由視為本機，並由迴圈裝置處理。
這種迴圈行為會導致後端 VM 無法成功使用 ILB 的 VIP，以便透過 ILB 存取可能在其他後端 VM 上代管的服務，導致通訊失敗。
例如：在設為負載平衡器後端的 SAP NetWeaver HA 叢集中，ASCS 和 ERS 之間的通訊失敗。
telnet 測試會導致 Connection Refused 錯誤，因為這種本機路由無法讓流量抵達指定的 VM：
[root@test-server-ha ~]# telnet IP_ADDRESS_OF_ILB PORT_NUMBER
Trying IP_ADDRESS_OF_ILB...
telnet: connect to address IP_ADDRESS_OF_ILB: Connection refused
診斷
必備條件：
受影響的 VM 會列為非代管執行個體群組的成員，而該群組會設為負載平衡器後端。
當內部負載平衡器 (ILB) 中的後端 VM 與 IL 的虛擬 IP (VIP) 進行通訊時，就會發生特定的路由行為。
雖然 VIP 是在 eth0 等標準網路介面上設定，並列於本機轉送路徑表中，但核心會使用迴圈介面 lo 轉送封包，以便將封包轉送至這個本機 VIP。這個內部迴圈表示封包永遠不會離開原始 VM，以便由 ILB 處理。
雖然後端 VM 使用個別 IP 進行直接通訊，但這種迴圈行為會導致後端 VM 無法成功使用 ILB 的 VIP，以便透過內部轉送網路負載平衡器存取可能在其他後端 VM 上代管的服務。
[root@test-server-ha ~]# ip route show table local
local IP_ADDRESS_OF_ILB dev eth0 proto 66 kernel scope host src IP_ADDRESS_OF_ILB
local IP_ADDRESS_OF_THE_CURRENT_NODE dev eth0 proto kernel scope host src IP_ADDRESS_OF_THE_CURRENT_NODE
local IP_ADDRESS_OF_THE_OTHER_NODE dev eth0 proto kernel scope host src IP_ADDRESS_OF_THE_OTHER_NODE
broadcast IP_ADDRESS dev lo proto kernel scope link src IP_ADDRESS
local IP_ADDRESS dev lo proto kernel scope host src IP_ADDRESS
broadcast IP_ADDRESS dev lo proto kernel scope link src IP_ADDRESS
ip route get IP_ADDRESS_OF_ILB
這項指令的輸出結果會顯示迴圈介面 lo：
[root@test-server-ha ~]# ip route get IP_ADDRESS_OF_ILB
local IP_ADDRESS_OF_ILB dev lo src IP_ADDRESS_OF_ILB uid 0
cache <local>
解決方案
修改 google-guest-agent 的設定，啟用 VM 之間的後端通訊。此設定包含在 Google Cloud提供的所有 Linux 公開映像檔的 Linux 訪客環境中。
如要啟用負載平衡器後端通訊，請在叢集中的每個 VM 上執行下列步驟：
停止代理程式：
sudo service google-guest-agent stop開啟或建立
/etc/default/instance_configs.cfg檔案進行編輯：sudo vi /etc/default/instance_configs.cfg在
/etc/default/instance_configs.cfg檔案中，指定下列設定屬性，如圖所示。如果這些區段不存在，請建立這些區段。特別注意，請務必將target_instance_ips和ip_forwarding屬性都設為 false：[IpForwarding] ethernet_proto_id = 66 ip_aliases = true target_instance_ips = false [NetworkInterfaces] dhclient_script = /sbin/google-dhclient-script dhcp_command = ip_forwarding = false setup = true啟動訪客代理程式服務：
sudo service google-guest-agent start
如要套用變更，請重新啟動 VM，或按照下列步驟刪除本機路徑
刪除將流量傳回的本機路徑：
sudo ip route del table local $(ip route show table local | grep "proto 66" | awk '{print $2}') dev eth0上述指令是一系列 Linux 指令，會連結在一起，從本機路由表中刪除 VIP。以下將各項指標逐一說明：
我們會使用以下方式識別 IP 位址：
ip route show table local | grep "proto 66" | awk '{print $2}'然後將其管道傳送至實際的刪除指令：
ip route del table local重新啟動 Google 訪客代理程式：
systemctl google-guest-agent restart
這項變更不會造成干擾。重新啟動 google-guest-agent 會重新建立新的網路路徑，指示網路流量使用 eth0 而非迴圈裝置，將流量傳送至 VIP。
如要驗證變更，請按照下列步驟操作：
ip route get IP_ADDRESS_OF_ILB
這個指令的輸出內容必須顯示網路介面 (例如 eth0)，而非迴圈介面 lo：
[root@test-server-ha ~]# ip route get IP_ADDRESS_OF_ILB
IP_ADDRESS_OF_ILB via IP_ADDRESS_OF_ILB dev eth0 src IP_ADDRESS_OF_ILB uid 0
cache
嘗試 telnet 測試：
[root@test-server-ha ~]# telnet IP_ADDRESS_OF_ILB PORT_NUMBER
Trying IP_ADDRESS_OF_ILB...
Connected to IP_ADDRESS_OF_ILB.
Escape character is '^]'.