設定 FMW 延伸叢集
提供 OCI 基礎架構特定步驟更能反映 Oracle Fusion Middleware 延伸叢集實行所需的組態和變更。然而,所有提供的考量和步驟都可以推斷為使用其他負載平衡器、網路、硬體和儲存基礎架構的內部部署系統。在每種情況下,請使用本書中提供的 OCI 範例作為參考,參考供應商專屬的詳細資料。
設定區域
在 Oracle Cloud Infrastructure (OCI) 中,您可以跨 OCI 區域導入,在這些區域之間具有低延遲。支援的最大區域間延遲為 10 毫秒往返時間 (RTT)。您可以依序選取網路、網路指揮中心及區域間延遲,檢查 OCI 主控台中區域之間的延遲。
考慮到延遲值,您可以在 RTT 為 6-7 毫秒的法蘭克福和阿姆斯特丹等區域之間部署此模型。不過,您無法在阿什本和鳳凰城等地點之間部署此模型,因為這些區域之間的延遲超過 50 毫秒的 RTT。
區域間延遲低於 10 毫秒 RTT 的區域配對範例:
-
阿姆斯特丹 (AMS) - 巴黎 (CDG)
-
阿姆斯特丹 (AMS) - 紐波特 (CWL)
-
阿姆斯特丹 (AMS) - 法蘭克福 (FRA)
-
阿姆斯特丹 (AMS) - 倫敦 (LHR)
-
巴黎 (CDG) - 法蘭克福 (FRA)
-
巴黎 (CDG) - 倫敦 (LHR)
-
巴黎 (CDG) - 紐波特 (CWL)
-
馬賽 (MRS) - 米蘭 (LIN)
-
蘇黎世 (ZHR) - 法蘭克福 (FRA)
-
蘇黎世 (ZHR) - 米蘭 (LIN)
-
大阪 (KIX) - 東京 (NRT)
-
新加坡 (SIN) - 巴坦 (HSG)
-
聖保羅 (GRU) - 維涅杜 (VCP)
-
新加坡 (SIN) - 新加坡 2 (XSP)
-
巴坦 (HSG) - 新加坡 2 (XSP)
-
首爾 (ICN) - 春川市 (YNY)
-
多倫多 (YYZ) - 蒙特婁 (YUL)
在頻寬方面,OCI 區域之間沒有保證的頻寬,而 OCI 並未提供特定的 OCI 頻寬測量工具。如需精確的頻寬測量,請使用 iPerf 等工具。經過測試的法蘭克福與阿姆斯特丹之間的頻寬為每秒 2-2.5 GB (Gbps)。
您也可以在相同區域的可用性網域 (AD) 之間實行此模型。跨 AD 部署 Oracle WebLogic Server 伺服器實際上是平台即服務 (PaaS) 服務 (例如 Oracle SOA Suite on Marketplace 和 Oracle WebLogic Server for OCI 堆疊) 中的標準行為。不過,跨 AD 導入此模型而不是跨區域導入並不是災害保護解決方案,因為該解決方案無法防止影響整個區域的事件發生。
秘訣:
若要在每個站台中建立 FMW 部署所需的子網路、規則、運算實例、共用儲存體和負載平衡器,您可以使用 WLS-HYDR 架構 (請參閱「建立基礎架構」程序)。設定網路
此設定需要下列網路功能:
- 每個區域的 VCN 和分層子網路。
- VCN 與動態路由閘道 (DRG) 之間的遠端對等互連連線。
- 用於在網站之間遞送流量的適當路由規則。在區域 1 中,路由表應包括透過動態路由閘道路由至區域 2 VCN CIDR 的路由。同樣地,區域 2 路由表應包含透過動態路由閘道對區域 1 VCN CIDR 的路由。
- 允許延伸叢集進行下列通訊的網路安全規則:
- 在區域 1 與區域 2 的中間層子網路之間開啟 WebLogic 伺服器和「節點管理程式」連接埠。如果使用 Coherence,也允許 Coherence 連接埠的 TCP 和 UDP 流量。
- 允許來自區域 1 和區域 2 中間層子網路的傳送至資料庫監聽器和 Oracle Cloud Infrastructure Notifications (ONS) 連接埠的流量。
- 依照預設,不需要 OHS 與 WebLogic 伺服器之間的跨區域通訊。中間層子網路中的 WebLogic 伺服器連接埠只能從相同區域內的 OHS 伺服器存取。不過,在特殊情況下,可能會需要跨區域通訊,例如區域中的所有 Web 伺服器都失敗。如需進一步的詳細資訊,請參閱管理失敗段落。
- 系統使用的所有主機名稱 (WebLogic 監聽位址,以及主要和待命資料庫 SCAN 和 VIP 位址) 都必須能夠從兩個網站解析。依照預設,在 OCI 中,主機名稱只能在每個 VCN 內解析。若要允許區域 1 名稱在區域 2 中解析,請在區域 2 中建立區域 1 網域的專用 DNS 視觀表,然後新增相關名稱和 IP 位址。在區域 1 中重複此處理程序,以解析區域 2 的姓名。
- 在每個站台上,系統的前端名稱 (例如 frontend.example.com) 應指向本機負載平衡器的 IP 位址。若要達到此目的,請將前端名稱新增至每個區域的專用 DNS 檢視,或新增至中間層主機的
/etc/hosts檔案。這可確保從 WebLogic 伺服器到前端的任何回呼都會導向到區域。
設定資料庫
請務必在每個區域內使用 RAC,因為本機高可用性是關鍵需求。設定跨可用性網域 (AD) 或跨區域保護,只有在單一區域內已可靠地防止本機失敗時,才會生效。如果未實行本機高可用性 (例如 RAC 提供的高可用性),則跨多個 AD 或區域新增保護並不會處理本機環境內的失敗風險。
若要讓應用程式保持連線,並在發生 RAC 資料庫節點或執行處理失敗時收到 Oracle Notification Service 通知,請確定您的應用程式使用 Cluster Ready Services (CRS) 資料庫服務連線至可插拔資料庫 (PDB) 。主要和待命中必須要有相同的 CRS 服務。建立服務以連線到 PDB 的範例命令:
srvctl add service -db $ORACLE_UNQNAME -service pdbservice.example.com -preferred ORCL1,ORCL2 -pdb pdb1
srvctl modify service -db $ORACLE_UNQNAME -service pdbservice.example.com -rlbgoal SERVICE_TIME -clbgoal SHORT設定共用儲存體
多個運算實例可以透過網路檔案系統 (NFS) 協定同時掛載及存取相同的檔案系統。
OCI 中的 Oracle Fusion Middleware (FMW) 延伸叢集模型會在共用檔案系統 (例如共用組態或共用程式實際執行資料) 的每個區域使用 OCI 檔案儲存系統。OCI File Storage 在區域內提供高可用性:它會在可用性網域內的多個容錯域內部使用備援儲存。不過,無法跨區域存取 OCI File Storage 。因此,共用儲存體是區域的本機儲存體。
在區域之間使用本機備份和檔案系統複本,以提供可復原的使用者自建物件複本。
設定中間層
中間層運算節點分佈於兩個區域,其中半個節點位於區域 1,另一半位於區域 2。啟動設定和安裝程序與建立單一 WebLogic 網域時的程序相同。若要實行高可用性功能 (例如 Java Message Service (JMS) 和 Java Transaction API (JTA) 服務移轉、管理伺服器容錯移轉、使用節點管理程式自動偵測當機等等),請使用「瀏覽更多」段落中參照的 FMW Enterprise Deployment Guides 中建議的最佳做法。
您可以從一開始就建立網域並使用所有受管理伺服器進行設定,也可以透過在其他區域中新增節點,擴展在單一區域中執行的現有網域。
附註:
Oracle Fusion Middleware (FMW) 延伸叢集模型可套用至使用平台即服務 (PaaS) 服務 (例如 Oracle WebLogic Server for OCI 和 Oracle SOA Suite on Marketplace 堆疊) 建立的網域。這些 PaaS 服務的佈建和橫向擴展功能預設僅支援單一區域,因此您需要手動橫向擴展叢集以新增其他區域中的節點。請參閱擴展 WLS 叢集的程序,瞭解執行此作業所需的步驟。請注意,這些 PaaS 服務不包含 Web 層,也不會實作某些高可用性最佳作法,例如管理伺服器容錯移轉。因此,本文件中的部分建議可能不適用於這些環境。這些是在使用 FMW 延伸叢集模型時,在 WebLogic 組態中實行的最相關層面:
- 使用資料庫永久存放區
Oracle 支援延伸叢集,這些叢集使用 Oracle WebLogic Server 交易日誌和 JMS 的資料庫永久存放區。將交易日誌和永久資料儲存在資料庫中,可以利用資料庫的內建複製和高可用性功能,例如 Oracle Real Application Clusters (Oracle RAC) 和 Oracle Data Guard 。使用「資料保全」保護資料庫中的 JMS、交易日誌 (TLOG) 和描述資料,可簡化跨網站同步,並保證應用程式層次的一致性。這也表示中間層不再需要這些使用者自建物件的共用儲存體 (雖然它仍需要它來進行管理伺服器容錯移轉、部署計畫以及一些轉接器 (例如「檔案轉接器」)。
在資料庫中使用 TLOG 與 JMS 時,會受到系統效能的懲罰。當其中一個中間層需要與其他網站上的資料庫交叉通訊時,就會增加此罰款。從效能角度來看,每個網站本機共用儲存體會有較佳的效能,但這引進了複雜性和限制,可確保區域與應用程式一致性之間的資料遺失零。
- 每個區域的本機共用檔案系統使用者自建物件
如 Oracle Fusion Middleware Enterprise Deployment Guides 所示,「管理伺服器」網域目錄 (
ASERVER_HOME) 應位於共用儲存體,與受管理伺服器的網域資料夾 (MSERVER_HOME) 分隔。這以及使用「管理伺服器」監聽位址的虛擬主機名稱,可讓「管理伺服器」容錯移轉至相同或不同區域內的另一個主機。位於共用檔案系統中的其他使用者自建物件包括 Oracle 本位目錄安裝項目 (二進位檔案)、建置計畫以及檔案轉接器目錄 (程式實際執行資料夾)。
在 FMW 延伸叢集拓樸中,每個區域都會使用自己的本機共用儲存體。因此,第二個區域會維護自己的備援二進位檔案 (確保每個網站至少安裝兩個二進位檔案以提高可用性),以及共用組態、建置計畫、程式實際執行檔案等的共用目錄。所有這些使用者自建物件在兩個區域都必須使用相同的路徑,以確保一致性和順暢的容錯移轉。
- 針對 WebLogic 叢集使用以相關性為基礎的演算法若要將跨網站流量降到最低,請使用本機相關性來解析 Java Naming and Directory Interface (JNDI) 環境定義處理站。若要將 WebLogic 叢集的預設載入演算法設定為以相關性為基礎的演算法,請執行下列動作:
- 前往 WebLogic Remote Console 中的編輯樹狀結構。
- 前往環境,選取叢集並選取叢集。
- 在一般頁籤中,將 WebLogic 叢集的預設載入演算法設為 round-robin 相關性 (預設值為 round-robin) 或任何「相關性」演算法。
不需要使用叢集中所有伺服器的明確清單來設定叢集位址。空白時,會自動產生「叢集位址」值。確定特性叢集位址的伺服器數目限制自動產生叢集位址時要列出的伺服器數目,其值夠高,足以包含叢集中的所有伺服器。
- 使用自動服務移轉組態
Oracle 建議您為企業部署拓樸設定「自動服務移轉」以及「Java 資料庫連線 (JDBC)」永久存放區。在 FMW 延伸叢集拓樸中,只要能夠從兩個網站存取 JMS 和 TLOG 資料,就可以在區域內或跨區域進行「自動服務移轉」。使用 JDBC 永久存放區時,在延展的叢集中設定 ASM 時不需要特別考量。
當地點之間的延遲較高時,從區域 1 到區域 2 的服務移轉作業所花費的時間可能會增加。這項增加是由於在另一個伺服器中復原訊息所花費的時間所造成,因為它們是從另一個區域之資料庫中的永久存放區讀取。此延遲會隨著永久存放區中的擱置訊息數目而增加。不過,罰款僅與極高的延遲或大量待處理訊息相關。如需預期行為的詳細資訊,請參考「複查績效資料」一節。
- 前端主機名稱和解析度
設定 WebLogic 叢集的前端主機時,請指定從屬端用來存取系統的虛擬主機名稱,如同任何標準建置一樣。從屬端應將此虛擬主機名稱解析為在區域 1 和區域 2 的 OCI 負載平衡器執行處理之間平衡的外部位址。請參閱關於全域負載平衡。
為了確保每個區域中的 WebLogic 伺服器只會將內部呼叫遞送給其個別的本機 OCI 負載平衡器,請設定伺服器將前端主機名稱解析為其區域內 OCI 負載平衡器的 IP 位址。您可以透過在每個 WebLogic 伺服器主機的
/etc/hosts檔案中新增項目,或將項目新增至每個區域的 DNS 專用檢視來達到此目的:對於區域 1 中的伺服器:
[IP address of Region 1 OCI Load Balancer] [frontend hostname]對於區域 2 中的伺服器:
[IP address of Region 2 OCI Load Balancer] [frontend hostname]此組態可確保將 WebLogic 伺服器的內部通訊導向適當的區域負載平衡器,以最佳化路由和效能。
設定 WebLogic 資料來源
在所有 WebLogic 資料來源 (適用於 Oracle Fusion Middleware (FMW) 描述資料、資料庫永久存放區、租賃表格、資料庫轉接器等) 中使用具有雙重連線字串的 GridLink 資料來源,將資料庫容錯移轉自動化。當 Oracle Real Application Clusters (Oracle RAC) 的其中一個節點發生失敗或關閉時,他們應該自動重新連線,但是當資料庫完全切換到另一個區域時。為了達到此目的,請套用下列建議:
- 使用 GridLink 資料來源
GridLink 資料來源利用 Oracle Notification Service (ONS) 快速偵測並回應資料庫節點失敗或網路中斷,進而提升應用程式可用性與復原能力。他們會根據即時工作負載資訊自動分配資料庫連線,最佳化所有 RAC 節點的效能和資源使用狀況。系統會自動辨識和處理資料庫拓樸中的變更 (例如新增或移除 RAC 節點),以減少管理負荷並減少停機時間。
您不需要在 GridLink 資料來源組態中手動指定 ONS 主機和連接埠。資料庫會自動將 ONS 清單提供給驅動程式,它會擷取主要和待命資料庫的 ONS 資訊,以協助兩者連線。
- 使用 TNS 別名
在資料來源的連線字串中,使用指向
tnsnames.ora檔案中項目的 TNS 別名 (包括主要和待命 SCAN 位址)。建議的連線字串格式如下,其中包含一個描述和兩個位址清單,每個 RAC 資料庫一個:PDB = (DESCRIPTION= (CONNECT_TIMEOUT=15)(RETRY_COUNT=5)(RETRY_DELAY=5)(TRANSPORT_CONNECT_TIMEOUT=3) (ADDRESS_LIST= (LOAD_BALANCE=on) (ADDRESS=(PROTOCOL=TCP)(HOST=primdb-scan.dbsubnet.region1vcn.oraclevcn.com)(PORT=1521)) ) (ADDRESS_LIST= (LOAD_BALANCE=on) (ADDRESS=(PROTOCOL=TCP)(HOST=stbydb-scan.dbsubnet.region2vcn.oraclevcn.com)(PORT=1521)) ) (CONNECT_DATA=(SERVICE_NAME=pdbservice.example.com)) )如需有關如何在資料來源和 FMW 組態檔中設定 TNS 別名的詳細資訊,請參閱 Enterprise Deployment Guide for Oracle SOA Suite 中的 Using TNS Alias in Connect Strings 。
- 使用保留時測試連線選項
確定已為所有資料來源啟用保留時測試連線選項。這對於用來存取永久存放區的資料來源特別重要,因為永久存放區在 WebLogic 伺服器的整體狀態中十分重要。此旗標可讓 WebLogic 伺服器先測試連線,再將連線提供給應用程式。
對於測試表格名稱,請使用預設值 SQL ISVALID 。這是一個快速且有效率的測試,因為它會執行輕量型驗證來判斷資料庫連線是否仍在作用中,而不需要存取特定的實體表格。
- 調整初始容量
當 WebLogic 伺服器啟動時,有相當長的時間專門用來建立資料來源集區的初始連線。根據資料來源中的初始容量設定值,預期會有不同的延遲。依預設,大多數 FMW 資料來源的連線集區使用零初始容量。不過,為了在一般執行階段作業期間縮短系統的回應時間,增加初始集區容量會很有幫助。
由於初始容量是在資料來源 (連線集區) 層次設定,因此這些設定值會影響叢集內所有伺服器 (資料庫本端伺服器與其遠端伺服器) 的啟動時間。在 FMW 延伸叢集中,使用較高的初始集區容量時,遠端位於資料庫的伺服器在啟動時會顯示較大的延遲 (請參閱「複查開始時間」)。因此,在正常作業期間最佳化回應時間與將開始時間最小化以判斷理想的初始容量設定之間,需要平衡的決策。 - 調整容量上限
作用中資料來源連線的數目會隨著資料庫的延遲而增加。在進行的測試中,遠端區域中的伺服器最多可顯示 2x 個作用中連線,而非與資料庫共置的伺服器 (請參閱「複查壓力測試」)。監督您應用程式中的使用狀況,並考慮這樣做來正確調整 WebLogic 資料來源和資料庫階段作業的大小。
設定 Web 伺服器
若要減少跨區域的流量,請勿在 Oracle WebLogic Server 路由區段中使用動態伺服器清單組態。請改為設定伺服器的靜態清單,將參數 DynamicServerList 設為 OFF。這有較慢的失敗偵測洞穴:當 WebLogic 伺服器當機時,HTTP 伺服器偵測失敗的時間會比使用動態清單的時間長。此外,如果新增伺服器,則需要更新組態。不過,它可以改善系統的效能。
下列摘錄自 Oracle HTTP Server 中的 mod_wl_ohs.conf 檔案,提供遞送至 SOA 基礎架構 Web 應用程式的必要組態範例。
在區域 1 中:
<Location /soa-infra>
WLSRequest ON
WebLogicCluster region1_server1.example.com:7004,region1_server2.example.com:7004
DynamicServerList OFF
</Location>在區域 2 中:
<Location /soa-infra>
WLSRequest ON
WebLogicCluster region2_server1.example.com:7004,region2_server2.example.com:7004
DynamicServerList OFF
</Location>設定負載均衡器
在每個負載平衡器上,以相同的 SSL 憑證在兩個區域中設定監聽器。設定後端伺服器,讓區域 1 中的負載平衡器包含來自區域 1 的 Oracle HTTP Server (OHS) 執行處理 (如果系統未使用 Web 伺服器,則備份的伺服器為 WebLogic 來自區域 1 的伺服器,而區域 2 的負載平衡器則包含來自區域 2 的 OHS 伺服器 (如果系統未使用 Web 伺服器,則後端伺服器是來自區域 2 的 WebLogic 伺服器)。
設定狀況檢查以判斷後端伺服器的使用狀態,使用正確反映應用程式狀態的 URL。這可防止將流量遞送至執行 Oracle WebLogic Server 但應用程式本身無法使用時,如果狀況檢查僅針對根相關資訊環境 (/),則可能會發生這種情況。不過,由於頻繁的檢查可能會超載支援的伺服器,因此請避免使用大量資源的狀況檢查。例如,對於 Oracle SOA ,建議的狀況檢查 URL 為 /soa-infra/services/isSoaServerReady 。
關於全域負載平衡
在內部部署實作中,這在傳統上會與全域負載平衡器一起實作,該負載平衡器負責智慧路由,通常是以來源的 IP 位址為基礎。此全域負載平衡器通常位於其中一個網站,並在另一個網站備份以進行容錯移轉。
在 Oracle Cloud Infrastructure (OCI) 中,沒有專屬的全球負載平衡器服務。不過,您可以使用流量管理原則來實現全域負載平衡功能。
使用 OCI 流量管理操控原則作為全球負載平衡器
流量管理操控原則會針對網域名稱系統 (DNS) 查詢提供智慧型回應,這表示根據原則中定義的邏輯,查詢可能會提供不同的答案。有多種原則類型:
- 負載平衡器原則
負載平衡器原則會將流量分散到多個端點。您可以將端點指定為等重,以便將流量平均分配到整個端點,也可以為比率負載平衡指定自訂加權。Oracle Cloud Infrastructure Health Checks 會運用監控器和隨選探測來評估端點的狀況。如果端點狀況不良,DNS 流量會自動分配到其他端點。
- 容錯移轉原則
容錯移轉原則可讓您排列原則中提供答案的優先順序 (例如,主要和次要)。OCI Health Checks 會運用監控器和隨選探測來評估原則中答案的狀況。如果主要答案狀況不良,系統會自動將 DNS 流量導向至次要答案。
- 地理位置操控原則
地理位置操控原則會根據一般使用者的位置,將 DNS 流量分配給不同的端點。客戶可以定義地理區域,其中包含原始洲、國家或州 / 省 (北美) 組成,並為每個區域定義個別的端點或端點集。
- ASN 操控原則
ASN 操控原則可讓您根據自治式系統號碼 (ASN) 操控 DNS 流量。可以將源自特定 ASN 或 ASN 組的 DNS 查詢導向至指定的端點。
- IP 前綴操控原則
IP 前置詞操控原則可讓客戶根據原始查詢的 IP 前置詞 (IP Prefix) 引導 DNS 流量。
選擇最符合您需求的原則。延伸叢集部署最合適的選項為地理位置操控原則和 IP 前置碼操控原則。容錯移轉原則適用於只在其中一個網站執行的服務,例如 WebLogic Remote Console 。
無論原則類型為何,您都必須定義 OCI 狀況檢查,以驗證網站的可用性。這可避免流量到達停止伺服器或無法使用應用程式的網站。請確定允許來自觀察點的內送流量,這些觀察點會對您正在檢查的 OCI 負載平衡器連接埠執行狀況檢查。
下圖顯示全球負載平衡與 OCI 流量管理操控原則。
global-load-balancer-steering-policies-oracle.zip
使用 OCI 流量管理操控原則模擬全域負載平衡器時:
- 容錯移轉反應時間
網站失敗的回應時間取決於狀況檢查間隔 (判斷網站標示為無法使用多快),以及 DNS 記錄的存留時間值 (TTL)。即使將某個網站標記為無法使用,並將流量導向另一個位置之後,用戶端仍會收到更新的 IP 位址,直到先前的 DNS TTL 在其本機快取中到期為止。為了將容錯移轉延遲降至最低,建議設定低原則 TTL 值。
- 階段作業持續性限制
由於與這些原則的負載平衡依賴 DNS 回應值,因此階段作業持續性沒有內建機制。因此,使用隨機或簡單的負載平衡器原則時,提供給從屬端的 DNS 答案可以隨時變更,這可能會影響需要持續性的應用程式階段作業。如果您的應用程式需要持續性階段作業,請確定已在以地理位置為基礎的規則中明確定義所有可能的從屬端位置,並避免使用隨機或負載平衡器操控演算法。
以下是部署在法蘭克福和阿姆斯特丹區域的 Oracle Fusion Middleware (FMW) 延伸叢集系統之 OCI 流量管理操控原則的範例組態,前端為三個:一個用於 Oracle SOA 、一個用於 OSB,另一個用於 WebLogic Remote Console 。法蘭克福負載平衡器 (LBR) 的 IP 為 111.111.111.111,而阿姆斯特丹 LBR 的 IP 為 222.222.222.222。在此範例中,操控原則定義下列規則:
-
對於 SOA 和 OSB 前端,來自德國、歐洲、亞洲和南美洲位置的客戶將從 DNS 取得 Frankfurt 負載平衡器的 IP 作為主要答案。
-
針對 SOA 和 OSB 前端,荷蘭、非洲、大洋洲和北美位置的客戶將從 DNS 取得 Amsterdam 負載平衡器的 IP 作為主要答案。
-
對於任何其他用戶端 (由於地理位置規則中包含所有區域,因此並非預期),DNS 會傳回預設答案,以便將它們重新導向至法蘭克福。
-
每個前端都會定義 OCI 狀況檢查,因此如果主要項目標示為無法使用,系統就會將流量操控至替代 IP 記錄。
-
WebLogic Remote Console 前端使用容錯移轉模型。DNS 會為所有從屬端傳回 Frankfurt 負載平衡器的 IP。當法蘭克福的狀況檢查失敗時,DNS 會傳回阿姆斯特丹負載平衡器的 IP。
這些是定義的 OCI 流量管理操控原則:
-
用於存取 SOA 前端的地理位置操控原則。
組態料號 範例值 原則名稱
strecthed_cluster_steering_policy-SOA
樣板
地理位置操控
原則 TTL
60
回答 Pool1 (Frankfurt_Pool)
姓名:Frankfurt_LBR_IP
類型:A
資料:111.111.111.111
答案集區 2 (Amsterdam_Pool)
姓名:Amsterdam_LBR_IP
類型:A
資料:222.222.222.222
地理位置操控規則
地理位置:德國、歐洲、亞洲、南美洲
集區優先順序 1:Frankfurt_Pool
池優先權 2:Amsterdam_Pool
地理位置操控規則 1
地理位置:荷蘭,非洲,大洋洲,北美
集區優先順序 1:Amsterdam_Pool
池優先權 2:Frankfurt_Pool
全域全部擷取
回答 Pool1 (Frankfurt_Pool)
連附狀況檢查
要求類型:HTTP
狀況檢查:
SOA_IS_ALIVE(HTTPS)連附的網域
soafrontend.example.com
-
用於存取 OSB 前端的地理位置操控原則。
組態料號 範例值 原則名稱
strecthed_cluster_steering_policy- 作業系統
樣板
地理位置操控
原則 TTL
60
答案集區 1 (Frankfurt_Pool)
姓名:Frankfurt_LBR_IP
類型:A
資料:111.111.111.111
答案集區 2 (Amsterdam_Pool)
姓名:Amsterdam_LBR_IP
類型:A
資料:222.222.222.222
地理位置操控規則
地理位置:德國、歐洲、亞洲、南美洲
集區優先順序 1:Frankfurt_Pool
池優先權 2:Amsterdam_Pool
地理位置操控規則 1
地理位置:荷蘭,非洲,大洋洲,北美
集區優先順序 1:Amsterdam_Pool
池優先權 2:Frankfurt_Pool
全域全部擷取
回答 Pool1 (Frankfurt_Pool)
連附狀況檢查
要求類型:HTTP
狀況檢查:
OSB_IS_ALIVE(HTTPS)連附的網域
osbfrontend.example.com
-
容錯移轉原則是用於存取 WebLogic Remote Console 。在正常作業期間,管理伺服器只會在其中一個網站執行 (在此例中為 Frankfurt)。只有當網站發生故障時,它才會在其他網站啟動。因此,WebLogic Remote Console 的存取權限和 EM 是由容錯移轉原則控制。
組態料號 範例值 原則名稱
strecthed_cluster_steering_policy- 管理
樣板
容錯移轉
原則 TTL
60
回答 Pool1 (Frankfurt_Pool)
姓名:Frankfurt_LBR_IP
類型:A
資料:111.111.111.111
答案集區 2 (Amsterdam_Pool)
姓名:Amsterdam_LBR_IP
類型:A
資料:222.222.222.222
集區優先順序 1
Frankfurt_Pool
集區優先順序 2
Amsterdam_Pool
連附狀況檢查
要求類型:HTTP
狀況檢查:
EM_IS_ALIVE(HTTPS)連附的網域
admin.example.com
這是每個 DNS 操控原則所使用的 OCI 狀況檢查組態:
-
SOA 前端的狀況檢查。SOA 提供簡單頁面來驗證
/soa-infra/services/isSoaServerReady路徑中的 SOA 狀態。因此,此狀況檢查會對該路徑執行 HTTPS 的 HEAD 要求,以驗證 SOA 應用程式是否可用。Thehostheader is necessary to specify the front end name you want to test (in this example,soafrontend.example.com) when using named virtual hosts on the web servers and load balancers.組態料號 範例值 狀況檢查名稱
SOA_IS_ALIVE
目標
111.111.111.111 (法蘭克福 LBR IP)
222.222.222.222 (阿姆斯特丹 LBR IP)
觀察點
Microsoft Azure 北歐
Google 美國東部
Type
HTTP
協定
HTTPS
連接埠
443
路徑
/soa-infra/services/isSoaServerReady標頭
主機:soafrontend.example.com:443
方法
HEAD
Interval
30 秒
Timeout
10 秒
-
OSB 前端的狀況檢查。OSB 不會為其服務實行狀況 URL。某些 URL 通常用於驗證 OSB 的狀態 (例如
/sbinspection.wsil) 需要驗證,而 OCI Health Checks 不支援authorization標頭。因此,若要驗證 OSB 的狀態,請部署簡單的自訂 REST 代理主機服務。此 OCI 狀況檢查會透過 HTTPS 對這類端點執行 HEAD 要求。Thehostheader is necessary to specify the front end name you want to test (in this example,osbfrontend.example.com) when using named virtual hosts on the web servers and load balancers.組態料號 範例值 狀況檢查名稱
OSB_IS_ALIVE
目標
111.111.111.111 (法蘭克福 LBR IP)
222.222.222.222 (阿姆斯特丹 LBR IP)
觀察點
Microsoft Azure 北歐
Google 美國東部
Type
HTTP
協定
HTTPS
連接埠
443
路徑
/
default/isOSBReadySample標頭
主機:osbfrontend.example.com:443
方法
HEAD
Interval
30 秒
Timeout
10 秒
-
WebLogic Remote Console 前端
EM_IS_ALIVE的狀況檢查。OCI 狀況檢查會對路徑
/em/faces/targetauth/emasLogin執行 HEAD 要求,以驗證 FMW Control 主控台的狀態。組態料號 範例值 狀況檢查名稱
SOA_IS_ALIVE
目標
111.111.111.111 (法蘭克福 LBR IP)
222.222.222.222 (阿姆斯特丹 LBR IP)
觀察點
Microsoft Azure 北歐
Google 美國東部
Type
HTTP
協定
HTTPS
連接埠
443
路徑
/em/faces/targetauth/emasLogin標頭
主機:admin.example.com:445
方法
HEAD
Interval
30 秒
Timeout
10 秒
使用第三方全域負載平衡器
它將負責在本機負載平衡器之間執行要求的智慧型路由。
GLBR 是一個負載平衡器,設定為可供所有網站和外部位置的使用者以位址方式存取。裝置提供一個虛擬伺服器,對應至任何從屬端可存取的網域名稱系統 (DNS) 名稱,不論要連線的網站為何。
GLBR 會根據設定的條件和規則,將流量導向至任一個網站。這些條件可以用戶端的 IP 為基礎,例如這應該用來建立保存設定檔,讓 GLBR 能夠在起始和後續的要求時,將使用者對應至相同的網站。GLBR 會維護一個包含所有本機負載平衡器位址的集區。當其中一個網站發生失敗時,系統會自動將使用者重新導向至存留的作用中網站。
在每個網站中,本機負載平衡器會接收來自 GLBR 的要求,並將要求導向適當的 HTTP 伺服器。為了消除不需要的路由,GLBR 也會設定特定規則,將回呼僅傳遞至產生回呼之伺服器本端的 LBR。例如,這對於 Oracle SOA 服務的內部用戶非常有用。這些 GLBR 規則摘要如下:
-
如果要求來自 site1 (例如,源自網站 1 中 WebLogic 伺服器的要求),GLBR 會遞送至 site1 中的 LBR。
-
如果要求來自 site2 (例如,來自網站 2 中 WebLogic 伺服器的要求),GLBR 會遞送至 site2 中的 LBR。
-
如果要求來自任何其他地址 (用戶端呼叫),GLBR 載入會平衡兩個 LBR 的連線。
-
您可以在 GLBR 中定義額外的路由規則,以將特定從屬端遞送至特定網站 (例如,這兩個網站可能會根據每一種情況的硬體資源提供不同的回應時間)。
設定其他資源
這些外部資源的組態詳細資訊超出此文件的範圍。不過,在兩個區域中,這些資源必須一致,才能提供統一的行為。
例如,在 Oracle SOA 中,非同步回呼可能會重新填入在不同區域中起始的執行處理。同樣地,在自動復原的情況下,任何 Oracle WebLogic Server 皆可擔任叢集主要資料庫的角色,並在任一區域中執行復原作業。為了確保這些流程順暢運作並提供一致的行為,必須從兩個區域存取相同的外部資源。
