準備您的環境

Broadworks XSP 可以直接部署在網際網路上，也可位於前端為負載平衡元素（例如 F5 BIG-IP）的 DMZ 中。 為了提供地理備援，可以在兩個（或多個）資料中心部署 XSP，每個資料中心的前端都可以是負載平衡器，每個資料中心具有公用 IP 位址。 如果 XSP 位於負載平衡器後面，則 Webex 微服務和應用程式只會看到負載平衡器的 IP 位址，而 Broadworks 似乎只有一個 XSP，即使後面有多個 XSP。

在下面的範例中，XSP 部署在兩個網站（網站 A 和網站 B）。每個網站各有兩個前端為負載平衡器的 XSP。 網站 A 具有 XSP1 和 XSP2（前端為 LB1），而網站 B 具有 XSP3 和 XSP4（前端為 LB2）。 公用網路上只會顯示負載平衡器，而 XSP 位於 DMZ 私密網路中。

DNS 設定

Webex 雲端微服務必須能夠找到 Broadworks XSP 伺服器，才能連線至 Xsi 介面、驗證服務和 CTI。

Webex 雲端微服務將對設定的 XSP 主機名稱執行 DNS A/AAAA 查詢，並連線至傳回的 IP 位址。 這可以是負載平衡邊緣元素，也可以是 XSP 伺服器本身。 如果傳回多個 IP 位址，將會選取清單中的第一個 IP。 目前不支援 SRV 查找。

範例： 合作夥伴的DNS A 記錄，用於發現輪循平衡的面向網際網路的 XSP 伺服器/負載平衡器。

Failover

當 Webex 微服務向 XSP/負載平衡器傳送請求且請求失敗時，可能會發生數種狀況：

• 如果失敗是因為網路錯誤（例如： TCP、SSL），則 Webex 微服務會將該 IP 標記為已封鎖，並立即執行路由前進至下一個 IP。

• 如果錯誤碼（HTTP5xx ) 時， Webex微型服務會將IP標示為已封鎖，並立即執行到下一個IP的路由提前。

• 如果在 2 秒鐘內未收到 HTTP 回應，則請求會逾時，且 Webex 微服務會將該 IP 標記為已封鎖，並執行路由前進至下一個 IP。

每個請求會先嘗試 3 次，然後才會向微服務報告失敗。

當 IP 在封鎖清單中時，它將不會包括在向 XSP 傳送請求時嘗試的位址清單中。 在預先確定的一段時間之後，被封鎖的 IP 會過期，而且會在發出另一個請求時回到清單中進行嘗試。

如果所有 IP 位址都已封鎖，則微服務仍會嘗試從封鎖清單中隨機選取 IP 位址來傳送請求。 如果成功，則會從封鎖清單中移除該 IP 位址。

狀態

您可以在 Control Hub 中查看 Webex 雲端服務與 XSP 或負載平衡器的連接狀態。 在 BroadWorks Calling 叢集下，會針對以下每一個介面顯示連線狀態：

• XSI 動作

• XSI 活動

• 驗證服務

載入頁面時或在輸入更新期間，會更新連線狀態。 連線狀態可以是：

• 綠色： 當可以在 A 記錄查找中的其中一個 IP 上連接介面時。

• 紅色： 當 A 記錄查找中的所有 IP 無法連接且介面無法使用時。

下列服務使用微服務來連線至 XSP，並且受 XSP 介面可用性影響：

• Webex 應用程式登入

• Webex 應用程式權杖重新整理

• 不受信任的電子郵件/自行啟用

• Broadworks 服務運行狀況檢查

DNS 設定

Webex 應用程式會存取 XSP 上的擴充服務介面（XSI-Actions 和 XSI-Events）和裝置管理服務 (DMS) 服務。

若要尋找 XSI 服務， Webex應用程式會執行DNS SRV查找： _xsi-client._tcp.<webex app xsi domain> 。 SRV 會指向為 XSP 主機或 XSI 服務的負載平衡器設定的URL 。 如果 SRV 查找不可用， Webex應用程式會回退到 A/AAAA 查找。

SRV 可以解析為多個 A/AAAA 目標。 然而，每個 A/AAAA 記錄必須僅對映單一IP 位址。 如果負載平衡器/邊緣裝置後面的 DMZ 中有多個 XSP，則要求將負載平衡器設定為維護階段作業持續性，以將相同階段作業的所有請求路由至同一個 XSP。 我們要求此設定，因為用戶端的 XSI 事件活動訊號必須前往用於建立活動通道的相同 XSP。

在示例 1 中，webex-app-xsp.example.com 的 A/AAAA 記錄不存在，也不需要存在。 如果您的DNS要求必須定義一個 A/AAAA 記錄，則只應傳回 1 個IP 位址。 無論如何，仍必須為Webex應用程式定義 SRV。 如果Webex應用程式使用可解析為多個IP 位址的 A/AAAA 名稱，或者負載平衡器/ Edge 元素不維護階段作業持續性，則用戶端最終會向未建立事件通道的 XSP 傳送活動訊號。 這會導致通道被關閉，而且內部流量也會顯著增加，從而影響 XSP 的叢集效能。 因為Webex 雲端和Webex應用程式在 A/AAAA 記錄查找中具有不同的需求，所以您必須為Webex 雲端和Webex應用程式使用單獨的 FQDN 才能存取 XSP。 如範例所示， Webex 雲端使用 A 記錄 webex-cloud-xsp.example.com ，且Webex應用程式使用 SRV _xsi-client._tcp.webex-app-xsp.example.com 。

範例 1 — 多個 XSP，每個 XSP 都位於不同的負載平衡器之後

在此範例中，SRV 指向多個 A 記錄，每個 A 記錄指向不同地點的不同負載平衡器。 Webex應用程式將一律使用清單中的第一個IP 位址，且僅在第一個記錄關閉時才會移至下一個記錄。

範例 2 — 單個負載平衡器後有多個 XSP（使用TLS橋接器）

對於初始請求，負載平衡器會選擇一個隨機 XSP。 該 XSP 會返回Webex應用程式包含在未來請求中的 Cookie。 對於未來的請求，負載平衡器使用 Cookie 將連線路由到正確的 XSP，確保事件通道不會中斷。

DMS URL

在登入程序期間，Webex 應用程式還將擷取 DMS URL 以下載其設定檔案。 將剖析 URL 中的主機，並且 Webex 應用程式將對主機執行 DNS A/AAAA 查找以連線至託管 DMS 服務的 XSP。

範例： DNS A 記錄，用於透過 Webex 應用程式探索循環平衡的網際網路對向 XSP 伺服器/負載平衡器來透過 DMS 下載設定檔案：

Webex 應用程式如何尋找 XSP 位址

用戶端嘗試使用下列 DNS 流程來尋找 XSP 節點：

1. 用戶端最初會從 Webex 雲端擷取 Xsi-Actions/Xsi-Events URL（當您建立關聯的 BroadWorks Calling 叢集時輸入這些 URL）。 Xsi 主機名稱/網域會從 URL 剖析，用戶端則會執行 SRV 查找，如下所示：

   1. 用戶端會對 _xsi-client._tcp 執行 SRV 查詢。<xsi domain="">

   2. 如果 SRV 查找返回一個或多個 A/AAAA 目標：

      1. 用戶端會對那些目標執行 A/AAAA 查詢，並快取返回的 IP 位址。

      2. 用戶端根據 SRV 優先順序，然後是權數（或隨機，如果全部相等），連線至其中一個目標（並因此透過單一 IP 位址連線至及其 A/AAAA 記錄）。

   3. 如果 SRV 查找未返回任何目標：

      用戶端會對 Xsi 根參數執行 A/AAAA 查詢，然後嘗試連線至返回的 IP 位址。 這可以是負載平衡邊緣元素，也可以是 XSP 伺服器本身。

      如上所述，出於相同的原因，A/AAAA 記錄必須解析為一個 IP 位址。

2. （可選）您隨後可以使用下列標籤在 Webex 應用程式的裝置設定中提供自訂 XSI-Actions/XSI-Events 詳細資訊：

   <protocols>
   	<xsi>
   		<paths>
   			<root>%XSI_ROOT_WXT%</root>
   			<actions>%XSI_ACTIONS_PATH_WXT%</actions>
   			<events>%XSI_EVENTS_PATH_WXT%</events>
   		</paths>
   	</xsi>
   </protocols>

   1. 這些設定參數會優先於 Control Hub 中 BroadWorks 叢集的任何設定。

   2. 如果存在，用戶端會與透過 BroadWorks 叢集設定接收的原始 XSI 位址作比較。

   3. 如果偵測到任何差異，用戶端會重新初始化其 XSI Actions/ XSI Events 連線。 第一步是執行步驟 1 中所列的相同DNS查找程序 – 這一次請求在%XSI_ROOT_WXT%參數從其組態檔中。

      如果您使用此標籤來變更 Xsi 介面，請務必建立對應的 SRV 記錄。

Failover

在登入期間，Webex 應用程式會針對 _xsi-client._tcp.<xsi domain=""> 執行 DNS SRV 查詢、建立主機清單，然後依次根據 SRV 優先順序和加權來與其中一個主機連線。 此連接的主機將成為所有未來請求的選定主機。 隨後會向選定主機開啟活動通道，並定期傳送活動訊號來驗證該通道。 在第一個請求之後傳送的所有請求都包括 HTTP 回應中傳回的 Cookie，因此，負載平衡器必須保持階段作業持續性（親和性）並一律將請求傳送至相同的後端 XSP 伺服器。

如果對主持人的請求或活動訊號請求失敗，則可能會發生數種狀況：

• 如果失敗是因為網路錯誤（例如： TCP、SSL），Webex 應用程式路由會立即移到清單上的下一個主機。

• 如果錯誤碼（HTTP5xx ) 時， Webex應用程式將該IP 位址標示為已封鎖，並路由前進到清單上的下一個主持人。

• 如果在一段時間內未收到回應，則請求會因逾時而被視為失敗，並會將下一個請求傳送給下一個主機。 但是，逾時請求會被視為失敗。 某些請求會在失敗後重試（這會增加重試時間）。 不會重試假設為非重要的請求。

當成功嘗試新主機時，如果該主機存在於清單中，則它會成為新的選定主機。 在嘗試清單中的最後一個主機之後，Webex 應用程式將回滾至第一個主機。

在活動訊號的情況下，如果連續發生兩個請求失敗，則 Webex 應用程式將重新初始化活動通道。

請注意，Webex 應用程式不會執行容錯回復，而且 DNS 服務探索僅在登入時執行一次。

在登入期間，Webex 應用程式會嘗試透過 XSP/Dms 介面下載設定檔案。 它會在所擷取的 DMS URL 中對主機執行 A/AAAA 記錄查詢，並連線至第一個 IP。 它將首先嘗試傳送使用 SSO 權杖下載設定檔案的請求。 如果出於任何原因失敗，將會重試，但會使用裝置使用者名稱和密碼。