使用本文來規劃 Webex Hybrid Services 部署的連接器容量,並瞭解延展性建議。 對於專用連接器部署和共駐連接器部署,您將找到連接器叢集的支援使用者數上限、決定支援使用者限制的因素以及如何使用 Control Hub 來評估是否需要新增更多的 Expressway。
Call Connector 架構上的混合通話服務已結束生命週期 (EOL),因此該服務不再受正式支援。 不應該考量使用 Call Connector 來規劃 Hybrid Services 的 Expressway 容量。 |
本文不涉及混合行事曆服務 Cisco TMS 與 Office 365 之整合或 Cisco TMS 與 Google Calendar 之整合的容量規劃。 如需容量資訊,請參閱 Cisco Webex 混合行事曆服務部署指南。 |
本文用來解決您關注的容量規劃問題並說明如何計算使用者比例。 若要給您的情境建模,請嘗試使用 Hybrid Services 容量計算機。
規劃注意事項
規劃 Hybrid Services 使用者群體的 Expressway 容量時,請考量下列問題:
您需要哪些混合服務?
Expressway 可以託管「混合通話服務」、「混合行事曆服務」和「混合訊息服務」的連接器。
每個服務可以有多少使用者?
每個服務的使用者越多,您越可能希望為服務提供專用 Expressway 叢集。 對於較小的群體,在一個共用叢集中執行多個連接器(共存)是一個有效的選擇。
您的需求將改變嗎?
您可能想要從較小的群體開始(其中含有一個 Expressway 叢集,用來將服務提供給組織中的一組早期採用者),然後針對未來推出的項目規劃容量增長。 您可以從共用模型移轉至專用模型,或者延展您的現有叢集,以符合不斷發展的需求。
影響因素
根據下列變數定義叢集的容量:
節點大小 — 每個 Expressway 虛擬機器具有由安裝時指定給虛擬機器的資源決定的「虛擬機器大小」。 Expressway 安裝指南說明了這些需求。 如果您已經具有 Expressway,則虛擬機器大小會顯示在 Expressway 介面的 頁面上。
節點計數 — 一個 Expressway 叢集可能具有一到六個節點。 它們必須具有相同的節點大小,並且執行相同的軟體版本。
服務持續策略 — 服務使用策略來確保持續提供服務給使用者。 行事曆服務和訊息服務使用容錯移轉策略。
在專用叢集的服務持續策略和比例表中詳細說明了策略。
共存 — 如果連接器共用 Expressway 叢集,則較之專用叢集,提供給每個服務的資源明顯少一些。
您的連接器主機上或許還存在其他基於 Expressway 的服務,例如「企業對企業通話 (B2B)」或 Mobile and Remote Access (MRA)。 在此類型的共存受支援的限制情境下,我們在這裡記錄的比例數目限於經過測試的數目。 在本文所述範圍之外,不得將連接器主機 Expressway 叢集與其他服務共用;此行為不受支援。
服務特定限制 — 例如,Calendar Connector 主要針對 Microsoft Exchange 使用者,只支援有限數量的 Office 365 使用者。
專用 Expressway 叢集計算
我們根據在測試及試用期間收集的證明,將硬性限制設為專用單一 Expressway 可以管理的服務使用者數(一個「只含一個節點的叢集」)。
Expressway 節點大小 | 混合行事曆服務比例 | 混合訊息服務比例 |
---|---|---|
1. 小 | 5000 | 5000 |
2. 中 | 10000 | 6500 |
3. 大 | 15000 | 15000 |
我們使用服務持續演算法,將單一節點數目擴大至多個節點叢集,如下表所述。 如果您需要結果,但不需要說明,請參閱:
比較 |
混合行事曆服務 |
混合訊息服務 |
---|---|---|
1. 型號 |
容錯移轉模型 |
容錯移轉模型 |
2. 說明 |
將每個使用者指定給叢集中的一個節點。 這樣做可將使用者散佈在所有節點中。 如果某個節點關閉,我們會在其他節點上重建使用者從該節點進行的指定。 當節點重新啟動時,我們會重新平衡使用者在所有活動節點之間的進行的指定。 |
將每個使用者指定給叢集中的一個節點。 這樣做可將使用者散佈在所有節點中。 如果某個節點關閉,我們會在其他節點上重建使用者從該節點進行的指定。 當節點重新啟動時,我們會重新平衡使用者在所有活動節點之間的進行的指定。 |
3. 公式 |
UcalN= (N-1) * Ucal1 |
UmsgN= (N-1) * Umsg1 |
4. 定義 |
地點: UcalN 是行事曆服務使用者的「包含 N 個節點的叢集」容量 N 是節點計數 Ucal1 是行事曆服務使用者的單一節點容量 |
地點: UmsgN 是訊息服務使用者的「包含 N 個節點的叢集」容量 N 是節點計數 Umsg1 是訊息服務使用者的單一節點容量 |
5. 附註 |
如果 N = 1,表示沒有容錯移轉。 如果 N > 1,表示容錯移轉會自動進行並且是必要的。 如果 N = 2,表示容量和 N = 1 時相同,但服務的持續性更佳。 N >= 3 或使用更大的節點大小時比例更佳。 |
如果 N = 1,表示沒有容錯移轉。 如果 N > 1,表示容錯移轉會自動進行並且是必要的。 如果 N = 2,表示容量和 N = 1 時相同,但服務的持續性更佳。 N >= 3 或使用更大的節點大小時比例更佳。 |
共用 Expressway 叢集計算
我們的演算法假定共存連接器成比例地共用單一節點的資源。 此演算法在節點上謹慎設定每種使用者的限制。
例如,下表顯示單個中型 Expressway 上所有專用案例和共存案例的使用者數目上限。
Expressway 用途 | 行事曆服務使用者 | 訊息服務使用者 |
---|---|---|
專用於行事曆服務 | 10,000 |
— |
專用於訊息服務 |
— |
6,500 |
由行事曆服務和訊息服務共用 |
4,000 |
4,000 |
由行事曆、通話和訊息服務共用 |
2,300 |
2,300 |
我們無法詳盡列出所有叢集大小的所有共存狀態。 相反地,您可以監控現有 Hybrid Services 部署的容量,也可以使用計算機來規劃新部署。
您可以使用計算機來選擇連接器、節點大小和節點計數,以便可以對部署建模。 本節的剩餘部分說明它如何根據模型來計算使用者數目。 |
正如我們對專用 Expressway 所做的一樣,我們擴大共用 Expressway 的演算法以確定多個節點的使用者數目。 與專用案例的差異是我們會套用適當的服務持續計算,以取得叢集上特定服務的使用者比例。 我們無法計算叢集的使用者比例,因為叢集上託管競爭的基於使用者的服務持續策略。
叢集用途 |
1、2 及 3 個節點的混合訊息服務使用者 |
||
---|---|---|---|
專用於訊息服務 |
6,500 |
6,500 |
13,000 |
其他影響因素
對叢集資源可能存在競爭需求,這將減小使用者容量。 已知範例如下:
行事曆服務 — 連接器主機也可能會服務 O365 使用者。 這裡顯示的數目和計算假定只有您的內部部署 Exchange 基礎結構會提供行事曆服務。 我們在本文的行事曆服務章節中提供了一些數字和圖形,供您進一步瞭解「混合」行事曆服務。
呼叫處理 — 連接器主機也可能會處理呼叫訊號和媒體。 這實際上是組織與 Webex 雲端之間的「企業對企業」整合。 這樣會減少容量,如與其他 Expressway 解決方案共存中所述。
您可以使用 Control Hub 來檢視每個混合服務 Expressway 資源的目前使用者容量百分比值。 色彩條指示容量是否在可接受的限制範圍內。 此檢視可讓您評估混合服務部署的健康情況,並幫您指出何時需要更多的 Expressway。
綠色 — 您的 Expressway 處於可接受的容量限制範圍內。 (1%–60%)
琥珀色 — 您具有足夠的 Expressway,但快要達到容量限制。 (61%-90%)
紅色 — 您沒有足夠的 Expressway,必須新增更多 Expressway。(91% 及以上)
如果您的 Expressway 位於資源群組,則容量指示器會出現在資源群組中叢集的篩選檢視下。
對於不含資源群組的部署(預設值):
對於含有資源群組的部署:
要牢記的事項
叢集容量可能會改變,取決於節點大小、Expressway 叢集中的節點數、在叢集中執行的服務數量以及高可用性或容錯移轉策略。 如需相關資訊,請參閱個別行事曆以及訊息比例等區段。
共存可減少現有服務的使用者比例;容量演算法假設每個使用者都在使用所有服務。
若要試用多個服務或者您擁有小型部署,建議您使用共存。 對於生產中的服務或大型部署,建議您在專用 Expressway 叢集上執行不同的混合服務。
後續動作
若要為混合服務新增更多 Expressway,請使用用於向雲端註冊連接器主機並將它們新增至現有叢集的部署指南步驟:
用於為混合行事曆服務使用者提供服務的 Expressway 叢集容量主要取決於叢集組成節點的大小和數量,以及服務持續策略。 下表顯示當您增加單一專用叢集上的節點(或節點 OVA 大小)時,該節點可以處理的使用者總容量上限。
在 Office 365 使用者的混合 Exchange 環境中,每個叢集 365 名使用者可使用的節點數量上限為 1,000 個,與該叢集的節點數或大小無關。 處理 Office 365 使用者時最好使用雲端型服務。 我們強烈建議您僅限於將 Office 365 使用者暫時託管給 Expressway。 此限制是因與 Microsoft 雲端服務的互動情況所致,與內部部署的 Expressway 規模無關。 例如,如果您有一個小型 Expressway 節點,則您的容量上限為 1,000 個 Office 365 使用者和 4,000 個 Microsoft Exchange 使用者。 如果您有 6 個小型節點,則您的容量上限為 1,000 個 Office 365 使用者加上 24,000 個 Microsoft Exchange 使用者。 |
Expressway 節點大小 |
1 或 2 個節點* |
3 個節點 |
4 個節點 |
5 個節點 |
6 個節點 |
---|---|---|---|---|---|
1. 小 |
5K |
10K |
15K |
20K |
25K |
2. 中 |
10K |
20K |
30K |
40K |
50K |
3. 大 |
15K |
30K |
45K |
60K |
75K |
* 請注意,使用者容量對於一個節點構成的叢集及兩個節點構成的叢集相同。 這是因為行事曆服務使用容錯移轉來改進服務延續性。 如果叢集中有兩個節點,而所有使用者都指定給一個節點;另一個節點是冗餘備份。 如需詳細說明,請參閱計劃混合服務使用者的 Expressway 叢集容量。
跨主機和叢集分派使用者
預設情況下,混合行事曆服務會自動跨一個叢集中的所有 Calendar Connector 平均分派和分配使用者。 此分派是動態的,取決於叢集和主機的可用性,且管理員無法控制要將個別使用者分派給哪些特定節點。
在組織具有多個叢集的情況下,使用者分配取決於多種因素,包括叢集可用性、目前分派(為減少故障修復期間的翻動)以及根據最高叢集喜好設定排定的順序。 管理員還可以將使用者或使用者群組分派給資源群組。 資源群組因叢集而異,因此它們可讓管理員設下某幾組使用者不得分派給某個叢集的限制。
根據對使用者分派的基本瞭解並將 Expressway Calendar Connector 先決條件納入考量,管理員可以為其組織大規模部署適當的容量。 假設有個 126,000 名使用者的組織要啟用混合行事曆服務,設定了下列參數:
使用大型 OVA 範本的 Expressway 叢集,每個叢集 6 個節點(每個節點的使用者人數上限為 15,000 名)
不需要資源群組
單一叢集的容量公式為 UcalN= (N-1) * Ucal1,其中 N=6 且 Ucal1=15,000(使用大型 OVA 範本)最多可產生 75,000 個使用者。 行事曆服務部署總共有 126,000 名使用者,需要多個 Calendar Connector 主機叢集。 使用者會平均分配,如下圖所示:
混合行事曆服務會先將使用者新增加叢集 A,直到該叢集達到 75,000 名使用者的容量,然後將其餘使用者分派給叢集 B。這些使用者隨機且平均地分配給該叢集內的所有節點。 此範例顯示 Calendar Connector 主機節點(兩個叢集中的每一個叢集內)平均分佈在 RTP 和 PDX 資料中心內。 每個節點都使用相同的 OVA 範本,並遵守 Expressway 高可用性準則。 Calendar Connector 使用 Expressway 5+1 備援模式的叢集邏輯,以達到高可用性的效果。
在所有使用者都分派給 Calendar Connector 的情況下,讓我們來看看萬一某個叢集發生故障時,會有什麼後果。 下圖顯示一個節點故障。 原本分派給故障節點(叢集 A 中的 5A)的使用者,現在已容錯移轉至該叢集中的其餘節點。 一個節點最多可容納 15,000 名使用者,而叢集 A 中的其餘每個節點都會新增 2,500 名原本分派給節點 5A 的使用者。 對於叢集 B 或分派給叢集 B 的使用者,則沒有變更或影響。
叢集 A 仍然處於容量上限,且該叢集中的每個操作節點現在都達到容量上限(每個節點 15,000 名使用者)。 因此,如果叢集 A 中的另一個節點變得無法使用(例如下圖中的節點 4A),則叢集 B 就必須承擔起其他使用者負載。 節點 4A 的 15,000 名使用者現在被重新分派給叢集 B,並且平均地分配給該叢集 B 中的所有節點。
當節點 4A 和 5A 修復時,叢集 A 的使用者就會重新分配給該叢集上的所有節點。 在此修復階段期間,容錯移轉至叢集 B 的使用者會留在叢集 B 上,以避免節點間不必要的使用者分派,如下圖所示。
規劃大規模混合行事曆服務部署時務必注意的一個要項,就是瞭解故障對部署造成的影響。 如果使用相同的 126,000 名使用者進行部署,但整個資料中心剛好故障,則可能有些使用者未分派給 Calendar Connector 節點。 為了防止此類情況下的服務中斷,客戶需有第三個叢集以供重新分配並處理受影響的使用者時使用。
用於為混合訊息服務使用者提供服務的 Expressway 叢集容量取決於 Expressway 組成節點的大小、叢集中的節點數以及服務持續策略。
下表顯示了用於混合訊息服務的單個 Expressway 上的使用者人數上限。
小型 Expressway |
中等 Expressway |
大型 Expressway |
---|---|---|
5,000 個使用者 |
6,500 個使用者 |
15,000 個使用者 |
含一個節點的叢集和含兩個節點的叢集擁有相同的使用者數目。 這是因為訊息服務使用容錯移轉來改進服務持續性。 使用者在叢集中的多個節點之間均勻分佈: 如果一個節點發生故障,則該節點的使用者會被指定給其他節點。 |
本主題討論在多個 Hybrid Services(其中包括「行事曆服務」和「訊息服務」)的連接器之間共用連接器主機 Expressway。 連接器主機未與其他基於 Expressway 的解決方案(例如 MRA 和 B2B)共用。
連接器主機叢集的容量取決於 Expressway 組成節點的大小、節點數、在叢集中執行的連接器以及服務持續策略。 如需這些因素的詳細說明,請參閱計劃混合服務使用者的 Expressway 叢集容量。
此外,還有一個計算機供您用來為不同的連接器主機叢集建模,並且您可以查看您提議的叢集針對每個服務可支援的使用者數目。
一般而言,我們只建議較小型的部署(不超過兩個節點)與其他解決方案共存。 如果部署超過兩個節點的容量,則需將連接器移至每個特定混合服務專用的 Expressway 叢集。
範例: 含三個共存連接器的連接器主機比例
下表顯示比例和共存的範例。 針對每個服務,它提供每個叢集的使用者數目上限,以及不同的連接器主機叢集規格。 混合行事曆服務(使用內部部署 Exchange)、混合通話服務及混合訊息服務會共用該叢集。
服務 |
兩個小型節點 |
兩個中型節點 |
兩個大型節點 |
---|---|---|---|
行事曆服務使用者 |
1,300 |
2,300 |
3,000 |
訊息服務使用者 |
1,300 |
2,300 |
3,000 |
簡介
本主題討論與其他基於 Expressway 的解決方案共用連接器主機 Expressway。 當您在 Expressway 上選擇用於其他目的的主機連接器時,請注意下列重要事項:
我們無法支援套用於專用連接器主機 Expressway 的延展性模型。 將連接器主機與其他 Expressway 服務共用時,透過閱讀本文的其他主題得出的使用者數目或使用計算機計算出的使用者數目不適用。
本文所述的基於 Expressway 的服務與混合服務連接器的組合,以及關聯的使用者數目,是唯一受支援的情境。 尚未測試過其他情境,因此您不能期望它們適用於您的環境。
基於 Expressway 的行事曆服務(含 Call Connector 和通話服務遍訪)
在此情境中,由兩個節點組成的 Expressway 叢集用來託管混合行事曆服務連接器。 該叢集還會針對其他 Cisco 通話解決方案(SIP 訊號和媒體)執行通話周遊。
該表顯示可與基於 Expressway 的連接器搭配使用的其他行事曆環境。 基於 Expressway 的 Calendar Connector 在含兩個以上節點的叢集上不受支援。 搭配 Office 365 使用雲端型的連接器以擴充規模(請參閱行事曆服務規模)。
服務 |
含兩個小型節點的叢集 |
含兩個中型節點的叢集 |
含兩個大型節點的叢集 |
|
---|---|---|---|---|
行事曆服務 |
內部部署 Exchange |
500 個使用者 |
1,000 個使用者 |
1,000 個使用者 |
Office 365† |
500 個使用者 |
1,000 個使用者 |
1,000 個使用者 |
|
內部部署 Exchange 和 Office 365(Hybrid Exchange 部署) |
兩者的使用者數上限為 500 |
兩者的使用者數上限為 1,000 |
兩者的使用者數上限為 1,000 |
|
通話遍訪 |
200 個音訊階段作業 100 個視訊階段作業 |
200 個音訊階段作業 100 個視訊階段作業 |
1,000 個音訊階段作業 500 個視訊階段作業 |
† 為了避免此比例有所限制,我們建議您使用基於雲端的「行事曆服務」而非內部部署的連接器。 若使用 Expressway 型的混合行事曆服務,Office 365 使用者容量限制為每個叢集 1000 個使用者,與叢集的節點大小或計數無關;此限制是根據與 Microsoft 雲端服務互動得出的,而不是根據內部部署 Expressway 部署的比例得出的。
行事曆(具有 Mobile and Remote Access)
在此情境下,由一或兩個小型 Expressway 虛擬機器組成的 MRA 叢集用來託管 Calendar Connector。 此情境假設該叢集僅用於 MRA 以及這兩個連接器。 該叢集限於擁有一或兩個小型節點。
Expressway 用途 |
含一個小型 Expressway-C 的叢集 |
含兩個小型 Expressway-C 的叢集 |
---|---|---|
行事曆服務使用者(Exchange 的內部部署連接器) |
500 個使用者 |
500 個使用者 |
Mobile and Remote Access 使用者 |
100 |
100 |