為混合行事歷服務使用者提供服務的 Expressway 叢集容量取決於 Expressway-C 組成節點的大小、Expressway 叢集中的節點數以及服務持續策略。

下表顯示專用於不同混合行事歷環境的單一 Expressway 上的使用者數目上限。

_{* 為了避免此比例有所限制，我們建議您使用基於雲端的「行事曆服務」而非內部部署的連接器。對於 Expressway 型混合行事歷，每個叢集將 Office 365 使用者容量限制為 1,000 個，與叢集的節點大小或數量無關；此限制源於與Microsoft雲端服務的互動，而不是源於內部部署部署 Expressway 的規模。}

請注意，使用者容量對於一個節點構成的叢集及兩個節點構成的叢集相同。這是因為行事曆服務使用容錯移轉來改進服務延續性。如果叢集中有兩個節點，而所有使用者都指定給一個節點；另一個節點是冗餘備份。如需詳細說明，請參閱計劃混合服務使用者的 Expressway 叢集容量。

用於為混合行事曆服務使用者提供服務的 Expressway 叢集容量主要取決於叢集組成節點的大小和數量，以及服務持續策略。下表顯示當您增加單一專用叢集上的節點（或節點 OVA 大小）時，該節點可以處理的使用者總容量上限。

_{* 請注意，使用者容量對於一個節點構成的叢集及兩個節點構成的叢集相同。這是因為行事曆服務使用容錯移轉來改進服務延續性。如果叢集中有兩個節點，而所有使用者都指定給一個節點；另一個節點是冗餘備份。請參閱為 Hybrid Services 使用者規劃 Expressway 叢集容量 以取得詳細說明。}

跨主機和叢集分派使用者

預設情況下，混合行事曆服務會自動跨一個叢集中的所有 Calendar Connector 平均分派和分配使用者。此分派是動態的，取決於叢集和主機的可用性，且管理員無法控制要將個別使用者分派給哪些特定節點。

在組織具有多個叢集的情況下，使用者分配取決於多種因素，包括叢集可用性、目前分派（為減少故障修復期間的翻動）以及根據最高叢集喜好設定排定的順序。管理員還可以將使用者或使用者群組分派給資源群組。資源群組因叢集而異，因此它們可讓管理員設下某幾組使用者不得分派給某個叢集的限制。

根據對使用者分派的基本瞭解並將 Expressway Calendar Connector 先決條件納入考量，管理員可以為其組織大規模部署適當的容量。假設有個 126,000 名使用者的組織要啟用混合行事曆服務，設定了下列參數：

• 使用大型 OVA 範本的 Expressway 叢集，每個叢集 6 個節點（每個節點的使用者人數上限為 15,000 名）

• 不需要資源群組

單一叢集的容量公式為 U_calN= (N-1) * U_cal1，其中 N=6 且 U_cal1=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 上的使用者數目上限。

本主題討論在多個 Hybrid Services（其中包括「行事曆服務」和「訊息服務」）的連接器之間共用連接器主機 Expressway。連接器主機未與其他基於 Expressway 的解決方案（例如 MRA 和 B2B）共用。

連接器主機叢集的容量取決於 Expressway 組成節點的大小、節點數、在叢集中執行的連接器以及服務持續策略。如需這些因素的詳細說明，請參閱計劃混合服務使用者的 Expressway 叢集容量。

此外，還有一個計算機供您用來為不同的連接器主機叢集建模，並且您可以查看您提議的叢集針對每個服務可支援的使用者數目。

一般而言，我們只建議較小型的部署（不超過兩個節點）與其他解決方案共存。如果部署超過兩個節點的容量，則需將連接器移至每個特定混合服務專用的 Expressway 叢集。

範例：含三個共存連接器的連接器主機比例

下表顯示比例和共存的範例。針對每個服務，它提供每個叢集的使用者數目上限，以及不同的連接器主機叢集規格。叢集在混合行事歷（使用內部部署Exchange）、混合通話 和混合訊息服務之間共用。

簡介

本主題討論與其他基於 Expressway 的解決方案共用連接器主機 Expressway。當您在 Expressway 上選擇用於其他目的的主機連接器時，請注意下列重要事項：

• 我們無法支援套用於專用連接器主機 Expressway 的延展性模型。將連接器主機與其他 Expressway 服務共用時，透過閱讀本文的其他主題得出的使用者數目或使用計算機計算出的使用者數目不適用。

• 本文所述的基於 Expressway 的服務與混合服務連接器的組合，以及關聯的使用者數目，是唯一受支援的情境。尚未測試過其他情境，因此您不能期望它們適用於您的環境。

基於 Expressway 的行事曆服務（含 Call Connector 和通話服務遍訪）

在這種情況下，會有兩個節點 Expressway 叢集「混合行事歷」連接器。該叢集還會針對其他 Cisco 通話解決方案（SIP 訊號和媒體）執行通話周遊。

該表顯示可與基於 Expressway 的連接器搭配使用的其他行事曆環境。基於 Expressway 的 Calendar Connector 在含兩個以上節點的叢集上不受支援。搭配 Office 365 使用雲端型的連接器以擴充規模（請參閱行事曆服務規模）。

_{† 為了避免此比例有所限制，我們建議您使用基於雲端的「行事曆服務」而非內部部署的連接器。對於 Expressway 型混合行事歷，每個叢集將 Office 365 使用者容量限制為 1,000 個，與叢集的節點大小或數量無關；此限制源於與Microsoft雲端服務的互動，而不是源於內部部署部署 Expressway 的規模。}

行事曆（具有 Mobile and Remote Access）

在此情境下，由一或兩個小型 Expressway 虛擬機器組成的 MRA 叢集用來託管 Calendar Connector。此情境假設該叢集僅用於 MRA 以及這兩個連接器。該叢集限於擁有一或兩個小型節點。