用於為混合行事曆服務使用者提供服務的 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 叢集容量。}

跨主機和叢集分派使用者

預設情況下，混合行事曆服務會自動跨一個叢集中的所有 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 使用者容量限制為每個叢集 1000 個使用者，與叢集的節點大小或計數無關；此限制是根據與 Microsoft 雲端服務互動得出的，而不是根據內部部署 Expressway 部署的比例得出的。}

行事曆（具有 Mobile and Remote Access）

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