關於管理失敗

Oracle Fusion Middleware (FMW) 延伸叢集拓樸可復原任何個別元件中的失敗。

每個網站都會遵循 Oracle FMW Enterprise Deployment 拓樸中概述的高可用性最佳做法，確保本機備援能夠防止元件層次 (例如負載平衡器、Oracle HTTP Server 執行處理、Oracle WebLogic Server 或資料庫執行處理) 發生中斷。

以下章節將探討解決案例的考量，例如網站內的完整層故障或網站故障總計。

管理單一網站上所有 Web 伺服器的失敗

如果網站遺失所有 Oracle HTTP Server 執行處理，前端系統 (無論是全域負載平衡器還是 Oracle Cloud Infrastructure (OCI) 流量管理操控原則) 都應該將網站標示為狀況不良。

所有從屬端要求 (不論其網站偏好設定為何) 都將遞送至其他網站。

因此，含有失敗 Web 伺服器的網站 Oracle WebLogic 伺服器將不會收到新的要求。他們可以繼續執行一些處理 (例如，處理 Oracle SOA 複合項目和 java 訊息服務 (JMS) 訊息)。不過，從這些伺服器內部產生的任何 HTTP 回呼都會失敗，因為它們指向自己的網站，而其 Web 伺服器已失敗。

下圖顯示某個網站之所有 Web 伺服器的失敗


failures-all-web-servers-one-site.png 的描述如下
failureures-all-web-servers-one-site.png 圖解描述

失敗 - 所有 Web 伺服器 - 單一網站 -oracle.zip

從失敗復原

如果要立即從單一站台上的所有 Web 伺服器故障復原，不需要手動介入。

系統會根據 Oracle Cloud Infrastructure (OCI) 流量管理操控原則或全域負載平衡器 (GLBR)，將用戶端自動重新導向至其他網站。

如果短期內無法回復遺失的 Web 伺服器執行處理，您可以執行下列動作，以使用失敗的 Web 層來使用網站的 WebLogic 伺服器：

  1. 設定其他站台的 Oracle HTTP Server (OHS) 執行處理，以將要求遞送至失敗站台上的 Oracle WebLogic Server 執行處理。
    1. 更新 OHS 組態並將 DynamicServerList 參數設為 ON。
    2. 以輪流方式重新啟動 OHS 以套用此變更，以避免發生停止工作的情形。
    3. 此外，請確定允許從 Web 伺服器到其他網站的 WebLogic 伺服器進行跨區域通訊。
  2. 為避免超文字傳輸協定 (HTTP) 回呼因無法使用 OHS 伺服器的網站而失敗，請更新 WebLogic 伺服器主機之 /etc/hosts 檔案或專用網域名稱系統 (DNS) 中的前端名稱項目，以指向另一個網站的負載平衡器。
失敗的伺服器再次可用之後：
  1. 啟動失敗網站中的 OHS 處理作業。

    當 Oracle Cloud Infrastructure Health Checks 再次確認後，流量管理操控原則將會根據定義的規則，在兩個網站之間負載平衡從屬端要求。

  2. 在另一個網站中再次將 DynamicServerList 設為 OFF。
  3. 回復 WebLogic 伺服器的 /etc/hosts 檔案 (或專用 DNS) 中的任何變更，以便再次指向自己的網站負載平衡器。

下列影像顯示 Java Message Service (JMS) 佇列訊息，以及一個站台上所有 Web 伺服器失敗時的從屬端失敗要求：


failure-messages-all-web-servers-one-site.png 的描述如下
failure-messages-all-web-servers-one-site.png 圖解描述

預期復原時間目標

使用 Oracle Cloud Infrastructure (OCI) 流量管理操控原則進行全球平衡時，在大約 1 分鐘的期間內發現錯誤 + DNS 存留時間 (TTL)。

DNS 更新會影響其操控原則偏好設定設為失敗區域的從屬端。TTL 值會決定這些從屬端在更新舊項目以指向狀況良好的網站之前，將繼續使用舊項目的時間長度。額外時間 (約 1 分鐘) 取決於 OCI 操控原則中設定的狀況檢查頻率和逾時 (上述測試使用 30 秒執行狀況檢查間隔，逾時 10 秒)。

使用全域負載平衡器 (GLBR) 時，停機時間取決於 GLBR 中設定的狀況檢查頻率。當 GLBR 將集區標記為狀況不良時，內送要求就會重新導向至其他網站。使用 GLBR 時，沒有 DNS 更新，因此前端項目的 TTL 值不相關。

管理單一網站上所有 Oracle WebLogic 伺服器的失敗

當所有 WebLogic 伺服器都在一個站台關閉時，其他站台會繼續處理要求。

失敗網站的負載平衡器會傳回失敗的回應，因此以 Oracle Cloud Infrastructure (OCI) 流量操控原則和狀況檢查為基礎的前端全域平衡功能，應該將網站標示為狀況不良。所有用戶端要求 (不論其偏好設定為何) 都將遞送至其他網站。

使用「自動服務移轉」以及「Java 資料庫連線 (JDBC)」永久存放區時，WebLogic Java Message Service (JMS) 和 Java Transaction API (JTA) 服務將會自動移轉至其他網站的伺服器。

在 Oracle Fusion Middleware (FMW) SOA 案例中，如果自動復原叢集主要資料庫是由失敗的伺服器代管，就會在可用位置中產生新的叢集主要資料庫。此伺服器會執行在其他網站上起始之 SOA 執行處理的自動復原。

下圖顯示某個網站上所有 WebLogic 伺服器的失敗：


failures-all-weblogic-servers-one-site.png 的描述如下
failures-all-weblogic-servers-one-site.png 圖解描述

fail-all-weblogic-servers-one-site-oracle.zip

下列影像顯示當網站上的所有 WebLogic 伺服器都失敗時，每個伺服器的從屬端失敗要求和 JMS 訊息。


failure-messages-all-weblogic-servers-one-site.png 的描述如下
failure-messages-all-weblogic-servers-one-site.png 圖解描述

在 JMS 訊息圖表中，有四行，每個行代表伺服器的 JMS 佇列。綠色與藍色線條 (幾乎重疊) 對應至已終止的伺服器。這些佇列的 JMS 訊息數目在中斷開始後不會增加。

紅線與黃線代表區域 2 中仍然停留的伺服器。將所有要求重新導向至此區域時，每個剩餘的伺服器都會收到總負載的 50%。不過，訊息在其佇列中累積的速率不同。這是因為失敗伺服器的 JMS 伺服器已移轉至其餘的伺服器之一，所以該伺服器中的訊息現在由三個佇列處理。因此，斜度會以黃色顯示較低值 (請注意，監督工具不會顯示已移轉佇列的訊息計數)。

從失敗復原

一個站台上所有 Oracle WebLogic Server 伺服器發生故障時，不需要手動介入即可立即復原。

失敗的伺服器再次可用之後：

  1. 在失敗的網站中啟動受管理伺服器。
  2. 一旦 Oracle Cloud Infrastructure Health Checks 再度正常執行，流量管理操控原則就會根據定義的規則，在兩個網站之間負載平衡用戶端要求。

預期復原時間目標

使用 Oracle Cloud Infrastructure (OCI) 流量管理操控原則進行全球平衡時，在大約 1 分鐘的期間內觀察到錯誤，再加上 DNS 存留時間 (TTL)。

這類似於某個站台上所有 Web 伺服器發生故障的情況，

DNS 更新會影響其操控原則偏好設定設為失敗區域的從屬端。TTL 值會決定這些從屬端在更新舊項目以指向狀況良好的網站之前，將繼續使用舊項目的時間長度。額外時間 (約 1 分鐘) 取決於 OCI 流量管理操控原則中設定之狀況檢查的頻率和逾時 (測試中已使用 30 秒進行狀況檢查間隔，逾時 10 秒)。

使用全域負載平衡器 (GLBR) 時，停機時間取決於 GLBR 中設定的狀況檢查頻率。當 GLBR 將集區標記為狀況不良時，內送要求就會重新導向至其他網站。使用 GLBR 時，沒有 DNS 更新，因此前端項目的 TTL 值不相關。

管理資料庫中的失敗：資料保全切換和容錯移轉

如果問題只影響主要資料庫，請儘快執行資料庫切換或容錯移轉至其他網站。

先前在「設定 WebLogic 資料來源」中提供的 Java 資料庫連線 (JDBC) URL 字串和 Oracle Notification Service (ONS) 組態，可確保將重新連線自動重新連線至新的主要資料庫。針對這些精確的測試 (使用 Oracle Fusion Middleware (FMW) SOA FOD，甚至具有 160 個並行呼叫的高工作負載)，資料庫切換或容錯移轉需要不到幾分鐘的時間。這個時間可能會因系統配置和環境而有所不同。在妥善調整的系統中，通常會有 1 到 5 分鐘的切換時間，但系統大小、資源、工作負載、重做日誌同步化以及網路效能等因素可能會影響總持續時間。如需 Oracle Data Guard 文件和其他資源的連結，請參閱「探索更多」一節。

在資料庫切換或容錯移轉期間，將會發生應用程式錯誤。此外，如果使用服務移轉的 WebLogic 伺服器無法更新其租賃表格，則節點管理程式可以關閉並自動重新啟動。預設租賃參數的預期行為為：

  1. 如果資料庫中斷非常短 (<1-2 分鐘)，則不應自動重新啟動 WebLogic 伺服器。
  2. 如果資料庫停止運作時間較長 (2-10 分鐘)，則 WebLogic 伺服器可能會因資料庫再次啟動時「失去租用」而自動重新啟動。

    如「設定調整 WebLogic 資料庫租賃」中所述，透過調整 WebLogic 的資料庫租賃重試來提高下限。

  3. 如果資料庫停機時間超過 10 分鐘，則 WebLogic 伺服器可能會因其他失敗而自動重新啟動，例如遺失對重要 JDBC 儲存的存取 (「無法使用 JTA 的 JDBC 儲存」)。

下圖顯示 FMW 延伸叢集拓樸中的資料庫切換


stretched-clusters-db-switchover.png 的描述如下
stretched-clusters-db-switchover.png 圖解描述

延伸叢集資料庫切換 oracle.zip

下列影像顯示 FMW 延伸叢集中資料庫切換期間，每一伺服器佇列的從屬端要求效能和 Java Message Service (JMS) 訊息。


stretched-clusters-db-switchover-messages.png 的描述如下
stretched-clusters-db-switchover-messages.png 圖解描述

從失敗復原

如果要立即從資料庫失敗復原：
  1. 使用 Oracle Cloud Infrastructure (OCI) 主控台或 Oracle Data Guard 中介命令行介面執行資料庫切換。
  2. 如果主要資料庫無法使用，請從待命資料庫執行資料庫容錯移轉。

    Oracle WebLogic Server 伺服器會自動重新連線至新的主要資料庫，因此除了可視需要從應用程式特定的錯誤復原之外，不需要手動動作 (例如，在 Oracle SOA Suite 中，您可能需要復原「錯誤急救中心」中的複合項目)。

失敗的伺服器再次可用之後：

  1. 如果執行資料庫容錯移轉，請恢復失敗的資料庫。

    如果您執行切換，則不需要此動作。

  2. 執行資料庫切換回原始網站。

預期復原時間目標

針對計畫的切換，復原時間總計很短，且取決於資料庫需要切換或容錯移轉的時間。

針對執行的測試，切換作業時間不到 2 分鐘。

針對非計畫性切換移轉或容錯移轉，總停機時間取決於資料庫停止運作的時間：

  • 如果您幾乎立即執行資料庫容錯移轉或切換，則復原的總時間很短。這取決於資料庫進行切換或容錯移轉所需的時間。針對執行的測試，切換作業需要不到 2 分鐘的時間，因此預期的復原時間目標 (RTO) 為：
    RTO = DB DOWNTIME + SHORT TIME (1-2 min)
  • 如果資料庫停止工作時間較長，可能會有額外的錯誤 (例如 Oracle WebLogic Server 自動重新啟動) 增加 RTO。在此情況下，預期的 RTO 為： 
    RTO = DB DOWNTIME + WEBLOGIC START TIME

管理 WebLogic 管理伺服器中的失敗

管理伺服器的處理作業失敗是由該節點中的 WebLogic 節點管理程式處理。

「節點管理程式」將會就地自動重新啟動失敗的伺服器。

不過，如果停機完全影響「管理伺服器」執行的主機，就必須將「管理伺服器」容錯移轉至不同的節點。

基本上，這包括在不同的節點中重新啟動「管理伺服器」，確保它指向包含「管理伺服器」網域目錄的位置，並使用對應至適當虛擬 IP (VIP) 的監聽位址。

此「管理伺服器」網域目錄可能是相同區域中不同節點可用的共用儲存體位置，或是從其他區域中節點可用的備份或檔案系統複製進行回復。

附註：

無論延伸叢集組態為何，都應該為您的 Oracle WebLogic 網域設定適當的備份程序。

因此，在 Oracle Fusion Middleware (FMW) 延伸的叢集拓樸中，將「管理伺服器」移轉至不同區域中的節點，以及將它移轉至相同區域中的節點時，會有不同的考量。

下圖顯示管理伺服器容錯移轉至 FMW 延伸叢集中的其他網站


failures-admin-server.png 的描述如下
failureures-admin-server.png 圖解描述

failures-admin-server-oracle.zip

容錯移轉至其他區域

若要將「管理伺服器」容錯移轉至其他區域，請執行下列步驟。
  1. 將管理伺服器的網域目錄 (ASERVER_HOME) 備份到容錯移轉網站。
  2. 回復容錯移轉網站中的 ASERVER_HOME 目錄 (包括網域和應用程式目錄)，讓相同的網域目錄結構與原始網站一致。
  3. 區域 1 與區域 2 中的子網路通常會使用不同的無類別網域間路由 (CIDR) 區塊。因此，管理伺服器在區域 1 (例如 10.10.10.1) 中使用的虛擬 IP (VIP) 在區域 2 中無效。當「管理伺服器」在區域 2 中執行時，會使用不同的 VIP (例如 20.20.20.1)。更新主機名稱解析，讓「管理伺服器」的監聽位址 (ADMINHOSTVHN) 對應至新的 VIP。
    1. 如 Using a Virtual IP (VIP) in Oracle Cloud Infrastructure 部落格所述，將虛擬 IP 指定並附加至將在區域 2 中執行管理伺服器的主機。
    2. 更新 /etc/hosts 或兩個區域中的網域名稱系統 (DNS) 專用檢視，將 ADMINHOSTVHN 記錄從先前的 IP (例如 10.10.10.1) 變更為新的 IP (例如 20.20.20.1)。
  4. 修改將回復「管理伺服器」之節點中的 $NM_HOME/nodemanager.domains 檔案，以包含 ASERVER_HOME 並重新啟動「節點管理程式」：
    domain_name=MSERVER_HOME;ASERVER_HOME
  5. 在新主機中啟動管理伺服器。
  6. Oracle HTTP Server 執行處理使用 DNS 快取，由 mod_wl_ohs.conf 中的指令 WLDNSRefreshInterval 控制。預設為 0，表示「永久快取」。您必須重新啟動 OHS 才能重新整理 DNS 解析快取。您有兩種方法：
    1. 重新啟動 OHS 伺服器以重新整理 DNS 解析快取。
    2. 或在 mod_wl_ohs.conf 中設定 WLDNSRefreshInterval 的非零值。

    否則，OHS 會繼續嘗試使用先前的 IP 位址連線至管理伺服器。

存取 WebLogic Remote Console 和 Oracle Enterprise Manager Fusion Middleware Control ，以驗證管理伺服器是否正常運作。

容錯移轉至相同區域

若要將管理伺服器容錯移轉至相同區域中的主機，您不需要複製管理伺服器的網域目錄，而虛擬 IP (VIP) 的值也不會變更。

因此，容錯移轉程序與驗證管理伺服器的手動容錯移轉中的 Enterprise Deployment Guide (僅英文版) 所述的程序相同。

若要管理 Oracle Cloud Infrastructure (OCI) 系統中的管理伺服器虛擬 IP (VIP)，您可以使用 Using a Virtual IP (VIP) in Oracle Cloud Infrastructure 部落格中所述的步驟

管理代管主要資料庫的整個區域失敗

如果停機影響整個區域 1，請儘快執行資料庫切換或容錯移轉至其他網站 / 區域。

剩餘網站中的 Oracle WebLogic Server 執行處理若使用上一節所述的建議組態，將會自動重新連線至新的主要資料庫。

失敗網站的負載平衡器將會傳回失敗的回應，因此前端全域平衡功能應將網站標示為狀況不良。所有用戶端要求 (不論其偏好設定為何) 都將遞送至其他網站。

使用「自動服務移轉」以及 JDBC 永久存放區時，WebLogic JMS 和 JTA 服務將會自動移轉至其他網站中的伺服器。在 Oracle Fusion Middleware (FMW) Oracle SOA Suite 的案例中，如果自動復原叢集主要資料庫是由失敗的伺服器代管，就會在可用位置中產生新的叢集主要資料庫。新的叢集管理程式將會執行在其他網站上起始之 SOA 執行處理的自動復原。

下圖顯示 FMW 延伸叢集拓樸中整個區域 1 的失敗：


failures-entire-region.png 的描述如下
failureures-entire-region.png 圖解描述

故障 - 整個區域 -oracle.zip

從失敗復原
要立即從區域 1 的完整失敗復原：
  1. 使用 Oracle Cloud Infrastructure (OCI) 主控台或 Oracle Data Guard 中介命令行介面執行資料庫切換。

    如果主要資料庫無法使用，請從待命資料庫執行資料庫容錯移轉。

  2. Oracle WebLogic Server 執行處理會自動重新連線至新的主要資料庫，因此除了從應用程式特定的錯誤復原之外，不需要手動動作 (例如，在 Oracle SOA Suite 中，您可能需要復原「錯誤急救中心」中的複合項目)。
  3. 如有需要，請執行管理伺服器容錯移轉至區域 2。

復原失敗的網站後，可以再次使用：

  1. 重新啟動失敗主機中的處理作業：Oracle HTTP 伺服器、WebLogic 管理伺服器和受管理伺服器。

    請確定已設定「管理伺服器」虛擬 IP (VIP)，而且沒有無法啟動的獨立檔案。

  2. 如果執行資料庫容錯移轉，請恢復失敗的資料庫。

    如果您執行切換，則不需要此動作。

  3. 執行資料庫切換至原始網站。
預期復原時間目標
當資料庫關閉時，系統將無法使用。

剩餘站台中的伺服器可以在剩餘站台中再次執行資料庫時繼續處理要求，因此停機時間取決於切換資料庫前所使用的時間。

  • 如果您幾乎立即執行資料庫容錯移轉或切換，則復原的總時間很短。這取決於資料庫進行切換或容錯移轉所需的時間。針對執行的測試，切換作業需要不到 2 分鐘的時間，因此預期的 RTO 為： 
    RTO = DB DOWNTIME + SHORT TIME (1-2 min).
  • 如果資料庫停止工作時間較長，可能會有額外的錯誤 (例如 Oracle WebLogic Server 自動重新啟動) 增加 RTO。預期的 RTO 為： 
    RTO = DB DOWNTIME + WEBLOGIC START TIME

管理代管待命資料庫的整個區域失敗

如果失敗會影響整個區域 2，前端全域平衡功能應將網站標示為狀況不良。

所有用戶端要求 (不論其位置偏好設定為何) 都將遞送至區域 1，以繼續處理要求。使用「自動服務移轉」以及 JDBC 永久存放區時，WebLogic JMS 和 JTA 服務將會自動移轉至網站 1 中的伺服器。

在含有 Oracle SOA Suite 的 Oracle Fusion Middleware (FMW) 案例中，如果自動復原叢集主要資料庫是由失敗的伺服器代管，就會在可用位置中產生新的叢集主要資料庫。此伺服器會執行在其他網站上起始之 SOA 執行處理的自動復原。

由於停機不會影響主要資料庫，因此不需要執行資料庫切換。

下圖顯示 FMW 延伸叢集拓樸中整個區域 2 的失敗。


failures-standby-db-region.png 的描述如下
failures-standby-db-region.png 圖解描述

fails-standby-db-region-oracle.zip

從失敗復原
從區域 2 的完整失敗立即復原，不需要手動介入。

再次提供失敗的網站之後，請重新啟動 Oracle HTTP 伺服器和 WebLogic 受管理伺服器之失敗主機中的處理作業。

請確定沒有無法啟動 WebLogic 的獨立檔案。

由於全球負載平衡器功能 (Oracle Cloud Infrastructure 流量管理操控原則或全域負載平衡器) 的緣故，客戶端的要求將再次重新平衡 2 個網站。

預期復原時間目標
使用 Oracle Cloud Infrastructure (OCI) 流量操控原則進行全域平衡時，失敗期間比操控原則中所定義前端項目的存留時間 (TTL) 多出 1 分鐘。

網域名稱系統 (DNS) 更新會影響已將區域 2 設為其在地理位置操控原則中偏好的從屬端。DNS 更新會影響其操控原則偏好設定設為失敗區域的從屬端。TTL 值會決定這些從屬端在更新舊項目以指向狀況良好的網站之前，將繼續使用舊項目的時間長度。額外時間 (約 1 分鐘) 取決於 OCI 流量管理操控原則中設定之狀況檢查的頻率和逾時 (上述測試使用 30 秒執行狀況檢查間隔，逾時 10 秒)。

使用全域負載平衡器 (GLBR) 時，停機時間取決於 GLBR 中設定的狀況檢查頻率。當 GLBR 將集區標記為狀況不良時，內送要求就會重新導向至其他網站。使用 GLBR 時，沒有 DNS 更新，因此前端項目的 TTL 值不相關。