開始使用
此手冊中的組態使用單一 Oracle WebLogic Server 網域,其中兩個網站中的伺服器會參與相同的叢集 (稱為延伸的叢集),並依靠資料保全來提供資料庫保護。
在 OCI 中,流量管理、狀況檢查、負載平衡器、DNS 專用檢視和動態路由閘道等功能提供增強的功能,以支援此設定。對於內部部署環境,應使用等效的網路和基礎架構元件來滿足這些需求。
網站或區域之間的網路延遲必須足夠低,以將呼叫延遲所引進的效能降低,並防止在部署和執行期間發生不一致的情況。Oracle 僅在 WebLogic 伺服器與資料庫之間的延遲低於 10 毫秒往返時間 (RTT) 時,才支援此拓樸。
為了達到最佳效能和容錯移轉行為,Oracle 建議您分析 WebLogic 延伸叢集中執行的每個應用程式,並據此調整本手冊 (逾時、階段作業複製組態、服務移轉租用、Java Transaction API (JTA) 等等) 中所討論的不同參數。
瞭解 Oracle Fusion Middleware 延伸叢集
提供 Oracle 最大可用性架構 (MAA) 是任何 Oracle Fusion Middleware 企業部署的主要需求之一。
Oracle Fusion Middleware 包含一組廣泛的高可用性功能,例如處理死亡偵測和重新啟動、伺服器叢集、服務移轉、GridLink、負載平衡、容錯移轉、備份與復原、機動升級和機動組態變更,可保護企業部署免於意外停機,並將規劃的停機時間降到最低。這些功能在單一資料中心內提供本地高可用性解決方案。
此外,應用程式還需要保護,避免可能影響整個資料中心的意外災害、自然卡路里和停機時間。大多數傳統災害保護系統都使用主動 - 被動模型,其中涉及在不同於生產站台的地理位置設定待命站台。當網站之間的延遲很高,且不允許在兩個網站之間叢集時,通常會採用此模型。此方法提供完整的最大可用性架構 (MAA) 保護。不過,由於待命中介軟體系統鏡像主要系統且需要持續複製,因此會產生額外的作業和管理成本。此模型詳述於 Oracle Fusion Middleware Disaster Recovery Guide 。
此手冊描述另一個模型:以 Oracle Fusion Middleware 延伸叢集為基礎的作用中模型,可用於保護 Oracle Fusion Middleware 系統,避免多個位置的停機時間。此模型在中間層使用主動 - 主動組態,而資料庫層則使用具有資料保全的主動 - 被動組態。其設計目的是將容量最佳化,並將工作負載分散到各個網站。它會使用所有可用的資源,而非讓待命機器閒置,以比主動 - 被動模型更有效地使用資源。此模型稱為 FMW 延伸叢集部署。
特別是,本手冊著重於如何在 Oracle Cloud Infrastructure (OCI) 區域實行此模型。它提供設定建議拓樸的組態步驟,以及有關此設定之效能與容錯移轉影響的指引。
本手冊中的結果和範例是以遵循 Enterprise Deployment Guide 架構的 Oracle SOA Suite 14.1.2 系統為基礎。這是一個重要的範例,因為它包含許多功能,例如標準雅加達元件、HTTP 階段作業複製、資料庫描述資料持續性、Coherence 叢集,以及 Java Message Service (JMS) 和 Java 交易 API (JTA) 持續性存放區,以及其他延伸叢集的相關考量。因此,描述的拓樸和建議也可以套用至其他 Oracle Fusion Middleware 環境。
術語
-
中間層 (亦為中間層或中介軟體)
中間層是指位於使用者介面 (前端) 與資料儲存 (後端) 之間之多層應用程式架構內的層。它會處理業務邏輯、資料處理以及安全性,作為使用者與資料庫之間的橋接器。
-
Oracle Fusion Middleware
Oracle Fusion Middleware 是 Oracle 的全方位企業中介軟體產品系列,可讓組織以有效率且安全的方式建置、部署及管理應用程式。它包括應用程式伺服器、整合、業務流程管理、商業智慧、安全性、身分識別管理、Web 伺服器等解決方案。
-
災害
突然、非計畫性的災難性事件,導致工地或地理區域無法接受的損害或損失。災害是一種事件,會影響組織在無法接受的期間提供重要功能、處理作業或服務,並讓組織呼叫其復原計畫的能力。
-
災害復原
能夠將應用系統與資料的復原策略設到不同地理位置的待命網站,以保護生產網站上的自然或非計畫性停機。
-
Oracle 最大可用性架構
Oracle 最大可用性架構 (Oracle MAA) 是 Oracle 產品 (Oracle Database 、Oracle Fusion Middleware 、應用軟體) 資料保護和可用性的最佳實務藍圖。導入 Oracle MAA 最佳實務是任何 Oracle 部署的關鍵需求之一。它提供設定和管理 Oracle 系統的建議。Oracle MAA 包含 Oracle Fusion Middleware Enterprise Deployment Guide 建議,並新增災害保護最佳做法,將影響整個資料中心或區域的停機計畫和非計畫性停機時間降到最低。如需相關文件和其他資源的連結,請參閱「探索更多」一節。
-
網站 (或資料中心)
網站是資料中心內執行一組應用程式所需的不同元件。例如,網站可由 Oracle Fusion Middleware 執行處理、資料庫、儲存體等等組成。
-
系統
系統是一組目標 (主機、資料庫、應用程式伺服器等等),可共同代管您的應用程式。例如,若要監督 Oracle Enterprise Manager 中的應用程式,您必須先建立一個由資料庫、監聽器、應用程式伺服器以及執行應用程式之主機目標組成的系統。
-
延伸叢集
延伸叢集是指叢集架構,其中單一邏輯叢集中的節點會分散在不同地理位置的資料中心或位置。
-
切換
切換是回轉生產站台與待命站台角色的程序。切換是定期驗證或對目前生產地點執行計畫性維護的計畫性作業。在切換期間,目前的待命網站會成為新的生產網站,而目前的生產網站會成為新的待命網站。此手冊也使用詞彙切換來參照網站切換。
-
切回
「切換」是將目前的生產環境網站和目前的待命網站回復至其原始角色的程序。切換是在切換作業完成之後完成的計畫作業。切換會回復每個網站的原始角色:目前的待命網站會變成生產環境網站,而目前的生產環境網站會變成待命網站。此手冊也使用術語切換來參照網站切換。
-
容錯移轉
容錯移轉是將目前待命網站設為新生產站台的程序,因為生產站台的災害 (例如,生產站台的災害) 意外無法使用。此手冊也會使用詞彙容錯移轉來參照網站容錯移轉。
-
回復點目標 (RPO)
復原點目標指的是系統可以從業務觀點容忍的資料遺失量,例如發生停機時可接受的資料遺失量。
-
復原時間物件 (RTO)
復原時間目標指的是系統可以容忍的停機時間,或應用程式或服務在發生停機時仍無法使用的可接受時間長度 (從業務觀點來看)。
- Oracle Cloud Infrastructure
Oracle Cloud Infrastructure (OCI) 是一組互補的雲端服務,可讓您在高度可用的代管環境中建置和執行一系列的應用程式和服務。OCI 在可安全從內部部署網路存取的彈性覆疊虛擬網路中,提供高效能運算功能 (作為實體硬體實例) 和儲存容量。
-
OCI 地區
OCI 區域是本地化的地理區域,包含一或多個代管可用性網域的資料中心。區域獨立於其他地區,且遠距離能夠分離它們 (跨國家,甚至是大陸)。
區域是災害復原的一個網站。
- 可用性網域
可用性網域是區域內獨立的資料中心。每個可用性網域中的實體資源會與其他可用性網域中的資源隔離,以提供容錯能力。可用性網域不會共用基礎架構,例如電源或冷卻系統,或內部可用性網域網路。因此,一個可用性網域發生故障不應影響該區域中的其他可用性網域。
- OCI 虛擬雲端網路與子網路
虛擬雲端網路 (VCN) 是您在 OCI 區域中設定的可自訂軟體定義網路。與傳統資料中心網路一樣,VCN 可讓您控制網路環境。VCN 可以有多個非重疊的無類別網域間路由 (CIDR) 區塊,您可以在建立 VCN 之後變更這些區塊。您可以將 VCN 分隔到子網路中,而子網路的作用領域可以調整到某個區域或可用性網域。每個子網路都是由連續的位址範圍所組成,這些位址不會與 VCN 中的其他子網路重疊。您可以在建立子網路後變更其大小。子網路可以是公用網路或專用網路。
- 動態路由閘道 (DRG)
DRG 是一個虛擬路由器,提供相同區域 VCN 之間、VCN 與區域外部網路 (例如另一個 OCI 區域中的 VCN、內部部署網路,或其他雲端提供者中的網路) 的專用網路流量路徑。
- OCI DNS
Oracle Cloud Infrastructure 網域名稱系統 (DNS) 服務是高度可擴展的全球任一傳播網域名稱系統 (DNS) 網路,可提供增強的 DNS 效能、抗逆力和可擴展性,讓一般使用者可以隨時隨地快速連線至網際網路應用程式。
-
OCI DNS 專用視圖
OCI DNS 專用檢視是一或多個 OCI 專用 DNS 區域的集合,用於以邏輯方式將 DNS 區域分組,以及控制其解析方式。視觀表會連附至專用 DNS 解析器,可以是虛擬雲端網路 (VCN) 或自訂的預設解析器。這可讓您管理 VCN 內不同環境或應用程式的個別 DNS 組態。
-
虛擬 IP
虛擬 IP (VIP) 位址指的是未與特定實體網路介面或裝置連結的 IP 位址。而是會將它抽象化,然後可以在裝置之間移動,或是用於各種網路功能。
-
OCI 流量管理
OCI Traffic Management 使用進階 DNS 型原則 (OCI 流量操控原則),以智慧型方式將使用者流量導向至最佳端點。組織可以藉此控制 DNS 查詢的解決方式、最佳化用戶端要求的路由,以提升部署在 OCI 或其他地方的應用程式或服務的可用性、效能和韌性。
-
負載平衡器
負載平衡器是一項系統或服務,可將內送網路流量分散到多個伺服器,以確保應用程式的高可用性、可靠性和最佳效能。
-
OCI 負載平衡器
OCI Load Balancer 是一項完全受管理的 Oracle Cloud Infrastructure 服務,可自動將內送流量分配給多個後端伺服器或資源,以確保應用程式的高可用性、更好的效能及擴展性。
-
區塊儲存
區塊儲存是一種資料儲存體,其中的資訊儲存在固定大小的區塊中,並可透過伺服器或應用程式 (例如 iSCSI 或光纖通道) 直接存取。
- OCI 區塊磁碟區
您可以使用 Oracle Cloud Infrastructure Block Volumes 建立、連附、連線及移動儲存磁碟區,以及變更磁碟區效能以符合您的儲存、效能和應用程式需求。將磁碟區連附並連線至執行處理之後,就可以像使用一般硬碟一樣使用磁碟區。您也可以中斷磁碟區連線並將其連附至另一個執行處理,而不會遺失資料。
-
共享倉庫
共用儲存體是指 IT 環境內由多部伺服器、電腦或應用程式同時存取的儲存系統或資源。此設定可讓所有參與的系統讀取及寫入相同的資料儲存區域,使其適用於需要資料一致性、協同合作、高可用性及擴展性的情況。
- OCI 檔案儲存
Oracle Cloud Infrastructure File Storage 提供持久、可擴展、安全的企業級網路檔案系統。您可以從 VCN 中的任何裸機、虛擬機器或容器執行處理連線至 OCI 檔案儲存。您也可以使用 Oracle Cloud Infrastructure FastConnect 和 IPSec VPN,從 VCN 外部存取 OCI File Storage 。
-
OCI 資料庫服務
OCI 資料庫服務指的是 Oracle Cloud Infrastructure (OCI) 提供的受管理資料庫解決方案組合。這些服務在 Oracle Cloud 中提供各種資料庫部署和管理選項,支援不同的工作負載、效能需求和資料模型,例如 Oracle Base Database Service 和 Oracle Exadata Database Service 。
- Oracle Data Guard
Oracle Data Guard 和 Active Data Guard 提供一組全方位的服務,可建立、維護、管理及監督一或多個待命資料庫,讓實際環境執行 Oracle 資料庫維持可用狀態而不會中斷。Oracle Data Guard 會使用記憶體內複製,將這些待命資料庫當作實際環境執行資料庫的複本。如果生產資料庫因計畫性或非計畫性停機而無法使用,Oracle Data Guard 可以將任何待命資料庫切換至生產環境角色,將停機時間降到最低。Oracle Active Data Guard 可讓您將幾乎讀取的工作負載卸載至待命資料庫,還能提供進階資料保護功能。
此手冊使用 OCI 作為部署 Oracle Fusion Middleware 延伸叢集的範例基礎架構。這些是 Oracle Fusion Middleware 延伸叢集設定所需之主要元件的內部部署至 OCI 等效項目:
| 內部部署 (或一般) | OCI 等效 |
|---|---|
| 網站 (或資料中心) | OCI 區域 |
| 共用儲存體 (例如,NFS) | OCI 檔案儲存 |
| 區塊儲存 | OCI 區塊磁碟區 |
| 全域負載平衡器 | OCI 流量管理和操控原則 |
| 本機負載平衡器 | OCI 負載平衡器 |
| 網路圖 | OCI 虛擬雲端網路 |
| 防火牆 / 防火牆規則 | OCI 網路安全規則 |
| 內部 DNS | OCI DNS 專用視圖 |
| 實體伺服器 / 虛擬機器 | OCI Compute 執行個體 |
| 內部部署的資料庫 | OCI 資料庫服務 |
| 網站之間的內部部署連線 | 具備動態路由閘道的 OCI 遠端對等互連 |
架構
下列考量適用於 FMW 延伸叢集架構:
- 區域
此拓樸中有兩個區域或網站。它們之間的延遲不應高於 10 毫秒往返時間 (RTT)。頻寬需求取決於每個系統所處理的有效負載類型,但建議至少每秒 1 或 2 GB (Gbps)。
- 中間層級
中間層在主動 - 主動模型中以單一網域運作。一半的受管理伺服器部署在一個站台,其餘的伺服器則部署在其他站台。「管理伺服器」會在一個站台中執行,但可視需要容錯移轉至其他站台。此設定通常稱為延伸叢集。
- 資料庫分層
資料庫層使用 Oracle Data Guard 支援的主動 - 被動架構。主要資料庫位於一個位置,而待命資料庫則位於另一個位置。所有中間層伺服器都設定為連線至目前作為主要伺服器的資料庫,不論其位置為何。在每個網站中設定的 Oracle Database 是 Oracle Real Application Clusters (Oracle RAC) 。Oracle RAC 可讓 Oracle 資料庫在同一個資料中心內跨伺服器叢集執行,不需進行任何應用程式變更,即可提供容錯、效能和擴展性。
- 儲存體
共用儲存體是每個網站的本機儲存體。基於競爭和安全理由,不建議跨網站使用共用儲存體。磁碟鏡射或從 site1 複製到 site2,反之亦然,建議您提供每個網站中可復原的使用者自建物件複本。
- 永久存放區
WebLogic 永久存放區 (Java Message Service (JMS) 和 Java 交易 API (JTA)) 設定為資料庫內的「Java 資料庫連線 (JDBC)」存放區。如此一來,就可以從兩個網站進行連線。這可讓「自動服務移轉」功能在兩個網站之間運作。
- 要求轉寄
每個站台上的 Web 伺服器只會將要求轉送至位於相同站台內的 Oracle WebLogic Server 執行處理。Web 伺服器 (Oracle HTTP Server 執行處理) 與另一個網站中的 WebLogic 伺服器之間沒有跨區域通訊,以將延遲和跨區域流量降到最低。
- 負載平衡器
每個網站都有專屬的負載平衡器,可將要求專門導向該本機網站內的 Web 伺服器。負載平衡器與位於其他網站的 Web 伺服器之間沒有跨區域通訊。
- 前端存取
在系統前方,該解決方案提供對系統的單一前端存取。用戶端會使用保持不變的單一位址連線,不論他們被導向的網站為何。此機制會提供一個網域名稱系統 (DNS) 名稱,可供所有從屬端存取,並根據預先定義的條件和規則 (例如從屬端的地理位置),將要求遞送至任一個網站。
下圖說明 Oracle Fusion Middleware 延伸叢集拓樸
下圖說明 Oracle Fusion Middleware 延伸叢集拓樸中的 WebLogic 網域和叢集:
優點
- 簡化管理
主動 - 被動部署會產生額外的管理負荷,讓組態在主要和待命網站之間保持同步。雖然大部分的程式實際執行資訊和描述資料都位於資料庫中,但 Oracle WebLogic Server 組態仍位於檔案系統中。因此,除了資料庫的 Oracle Data Guard 複製之外,主動 - 被動模型還需要持續的檔案系統複製,以各種方式實行 (rsync、儲存層次複本等)。
不過,在 FMW 延伸叢集模型中,Oracle WebLogic Server 基礎架構會讓組態在相同網域中的多個節點間保持同步。大部分的組態通常位於「管理伺服器」的網域目錄底下。當受管理伺服器啟動或實行變更時,此組態會自動傳輸到相同網域中的其他節點。因此,與任何需要持續複製組態變更的作用中被動方法相比,部署的管理負荷非常小。
- 改善可用性,並降低某些容錯移轉案例的 RTO 和 RPO
在下列情況下,FMW 延伸叢集模型提供比主動 - 被動模型更佳的復原點目標 (RPO) 和復原時間目標 (RTO):
- 在單一網站事件中完成中間層失敗
如果某個位置中的所有中間層伺服器都失敗,系統可以立即繼續在對等網站上使用中間層伺服器來滿足要求。此案例類型的 RTO 與 RPO 為零。
為了達到此目的,替代位置中的中間層伺服器必須能夠維持兩個位置的合併工作負載。必須進行適當的產能規劃,以考量此類情況。視設計而定,只有一個站台處於作用中狀態時,可能需要調節來自一般用戶端的要求。否則,網站必須具有附加容量的設計,部分防禦持續且高效率的容量使用目的。
- 資料庫層事件失敗
資料庫切換會在主動 - 被動和 FMW 延伸叢集模型中產生相同的 RTO 和 RPO。不過,延伸叢集模型中的系統整體 RTO 較低,因為中間層伺服器已在次要站台中處於作用中狀態。不需要重新啟動中間層。使用具有 GridLink 和「快速應用程式通知 (FAN)」通知的雙連線字串的適當資料來源組態,可自動容錯移轉中間層的資料庫連線,進而減少系統的 RTO。
- 在單一網站事件中完成中間層失敗
注意事項
- 產能規劃
此模型需要容量規劃,以考量兩個網站之間的容錯移轉情境。如果整個網站都失去中間層,則另一個網站必須能夠維持完整的工作負載。否則,可用網站可能會因為製造費用而沒有回應。這表示在正常作業期間,中間層節點必須未充分使用,才能有足夠的容量來處理容錯移轉情況。相同規則也適用於 Web 層。如果某個站台遺失其所有的 Web 伺服器,則其他站台上的 Web 伺服器必須能夠處理所有的系統要求。
- 跨網站的網路傳輸量
網路傳輸量主要取決於兩個因素:網站多遠,以及網路處理可靠性與壅塞的程度。無論伺服器或軟體的速度多快,資料在網站之間移動的速度都有所限制。影響此項目的兩個重要因素包括延遲和抖動:
-
延遲是指資料從一個站台到另一個站台之間移動的時間。它可以測量單向 (從來源到目標) 或往返 (離去和往返)。來回旅行時間 (RTT) 更為常見,可以使用
ping命令來檢查。 -
抖動是資料封包到達所需時間的變化。
對於目前的模型而言,保持低延遲尤其重要,因為抖動通常只有在延遲已經非常低時才重要。因此,控制延遲是這種設定中良好效能的主要優先順序。距離通常是最相關的延遲原因。
進行的測試顯示,當延遲 (RTT) 超過 10 毫秒時,此模型中的效能 (叢集中的某些 Oracle WebLogic Server 執行處理位於與資料庫不同的位置) 會大幅降低。
Oracle 已經針對不同延遲的不同組態進行多項測試。此手冊中顯示的參考延遲可區分叢集與下列項目:- 相同可用性網域中的所有成員
- 不同可用性網域中的成員
- 附近但不同 OCI 區域中的兩個成員
下列影像顯示執行 Fusion Order Demo (FOD) 的 Oracle Fusion Middleware SOA 系統,其在 WebLogic 伺服器與資料庫之間不同延遲的傳輸量 (每秒交易數):
下圖顯示執行 Fusion Order Demo (FOD) 之 Oracle Fusion Middleware SOA 系統的 Java Transaction API (JTA) 作用中時間,該示範 (FOD) 會使用不同位置間不同延遲的資料庫:
下圖顯示網站間不同延遲 (兩個網站都與其中一個網站中的資料庫搭配運作) 的整體系統處理量 (每秒交易數) 中觀察到的效能降低。
附註:
考慮上述所有因素,在許多測試中觀察到效能處罰,Oracle 不支援網站間超過 10 毫秒延遲 (RTT) 的 Oracle Fusion Middleware 延展叢集。系統運作時不會發生問題,但交易時間會大幅增加。超過 10 毫秒 (RTT) 的延遲也會造成用於部署和 JTA、Web 服務或應用程式逾時之 Oracle Coherence 叢集的問題。這使得此手冊中提供的解決方案主要適用於在它們之間具有低延遲的網站或區域。
-
- 跨區域流量
在目前的模型中,您需要將各個網站的流量降到最低,以降低系統傳輸量延遲的影響。在典型的 FMW 系統中,不同層或元素之間的通訊如下:
-
從 Oracle WebLogic Server 執行處理存取資料庫,以進行描述資料存取和其他資料庫讀取 / 寫入作業。
-
來自負載平衡器 (LBR) 或 Oracle HTTP Server 執行處理和 HTTP 回呼的內送 HTTP 呼叫。
-
Java Naming and Directory Interface (JNDI) /Remote Method Invocation (RMI) 和 Java Message Service (JMS) 在 Oracle WebLogic Server 執行處理之間的呼叫。
-
系統中所有伺服器之間的 Oracle Coherence 通知。例如,SOA 會使用 Coherence 提供一致的複合項目和描述資料影像。
-
Oracle WebLogic Server 執行處理之間的 HTTP 階段作業複製。部分元件使用狀態性 Web 應用程式,而這些應用程式可能依賴階段作業複製,以實現跨伺服器的階段作業通透容錯移轉。視使用模式和使用者數目而定,這可能會產生大量的複製資料。
-
輕量型目錄存取通訊協定 (LDAP) /policy/identity 儲存存取是由 Oracle WebLogic Server 基礎架構執行,以供授權與驗證之用。理想情況下,每個網站都應該要有定期同步的獨立身分識別和原則存放區,以將從一個網站到另一個網站的呼叫次數降到最低。或者,兩個網站都可以共用相同的存放區。共用商店的影響將取決於商店類型與系統的使用模式。
盡可能,上述所有內容應包含在網站內,以提升效能。舉例而言:
-
一個站台中的伺服器只能接收來自相同站台中 Oracle HTTP Server 執行處理的呼叫。
-
單一站台中的伺服器應僅對同一站台中的伺服器進行 JMS、RMI 和 JNDI 呼叫,且應僅在同一站台中取得伺服器產生的回呼。
-
HTTP 階段作業複製應僅限於相同網站中的其他伺服器。每個業務案例都必須分析複寫和容錯移轉需求,但理想上,應該儘可能減少各個網站的階段作業複製流量。
-
- 共享倉庫
跨站台的網路檔案系統 (NFS) 寫入延遲可能會導致效能嚴重降低。伺服器應該使用其網站本機的儲存裝置,以避免對檔案系統的讀取 / 寫入要求發生競爭。共用儲存體應限制為位於每個網站內。
- 其他資源
這兩個網站可以共用其他外部資源,例如 LDAP、外部 JMS 目標、外部 Web 服務等等。必須在兩個網站中一致提供這些資源。這些外部資源的組態詳細資訊超出此手冊的範圍。




