ハイブリッド カレンダー サービス ユーザーの Expressway クラスタの容量は、主にクラスタのサイズとノード数、およびサービスの継続性戦略によって異なります。 次の表は、単一の専用クラスタでノード（またはノード OVA サイズ）を増やす場合にクラスタが扱うことのできる最大ユーザー数を示しています。

Office 365 ユーザーのハイブリッド Exchange 環境では、クラスタのノード数またはサイズとは関係なく、クラスタあたり Office 365 ユーザー 1,000 名の制限があります。 Office 365 ユーザーを処理する望ましい方法はクラウドベースのサービスです。 Office 365 ユーザーを Expressway でホストするのは一時的とすることを強くおすすめします。 この制限は、Microsoft クラウド サービスとのインタラクションに由来しており、オンプレミスの Expressway 展開のスケールに関連するものではありません。 たとえば、小規模な Expressway ノードが 1 つある場合、容量は Office 365 ユーザー 1,000 名と Microsoft Exchange ユーザー 4,000 名に制限されます。 6 つの小規模ノードのクラスタがある場合、容量は Office 365 ユーザー 1,000 名と Microsoft Exchange ユーザー 24,000 名に制限されます。

_{* ノードが 1 つのクラスタと、ノードが 2 つのクラスタのユーザー数はと同じです。 これはカレンダー サービスがフェイルオーバーを使用してサービスの継続性を向上するためです。 クラスターに 2 つのノードがあるとき、すべてのユーザーが 1 つのノードに割り当てられます。他のノードは冗長性のバックアップです。 詳細については、「ハイブリッド サービス ユーザーの Expressway クラスター容量を計画する」を参照してください。}

ホストとクラスタ間でのユーザー割り当て

デフォルトでは、ハイブリッド カレンダー サービスは自動的に、クラスタ内のすべての Calendar Connector にユーザーを均等に割り当てて分散させます。 割り当ては可用性に基づいて動的に決められ、管理者は個々のユーザーが特定のノードに割り当てられるように制御することはできません。

組織に複数のクラスタがある場合、ユーザーの分布はクラスタの可用性、現在の割り当て（障害回復中の場合は軽減）、最も優先順位の高いクラスタに基づくソート順を含む、複数の要因に基づいて決まります。 管理者はユーザーまたはユーザー グループをリソース グループに割り当てる権限も有しています。 リソース グループはクラスタ特有のグループです。管理者は特定のユーザー グループを特定のクラスタに割り当てるよう強制できます。

このユーザー割り当ての基礎知識と、Expressway Calendar Connector の前提条件を考慮することで、管理者は組織の規模に合わせて適切な容量を実装することができます。 次のパラメータに基づき、126,000 名のユーザーの組織でハイブリッド カレンダー サービスを有効にする例を確認しましょう。

• 大規模な OVA テンプレートを使用している 6 ノードの Expressway クラスタ（1 ノードあたり最大 15,000 ユーザー）

• リソース グループは必要ありません

単一クラスタの容量式、U_calN= (N-1) *U_cal1（N=6 および U_cal1=15,000）（大規模な OVA テンプレートを使用）により、最大 75,000 名のユーザーが導かれます。 カレンダー サービスの展開の合計ユーザー数が 126,000 名の場合、複数の Calendar Connector ホスト クラスタが必要です。 次の図に示されるとおり、ユーザーも均等に分散されます。

ハイブリッド クラスタ カレンダー サービスは、ユーザー数が 75,000 名に達するまで、まずクラスタ A にユーザーを追加し、残りのユーザーをクラスタ B に割り当てます。ユーザーはクラスタ内のすべてのノードに、ランダムかつ均等に分散されます。 この例は、RTP と PDX のデータセンター全体の、Calendar Connector ホスト ノード（2 つの各クラスタ内）での均等な配分を示しています。 各ノードは同じ OVA テンプレートを使用し、Expressway の高可用性ガイドラインに従います。 Calendar Connector は 5+1 冗長モデルで Expressway クラスタ ロジックを使用し、高可用性シナリオを実現します。

Calendar Connector にすべてのユーザーが割り当てられた状態で、クラスタで障害が発生した場合に何が起こるかを調べてみましょう。 次の図は、単一ノードの障害を示しています。 クラスタ A の障害ノード 5A に割り当てられていたユーザーは、クラスタの別のノードにフェイルオーバーしました。 単一ノードの最大ユーザー数は 15,000 名で、クラスタ A に残っている各ノードには、最初にノード 5A に割り当てられていたユーザーから 2,500 が追加されます。 クラスタ B またはクラスタ B に割り当てられたユーザーへの変更または影響はありません。

クラスタ A は引き続き最大容量で稼働しており、クラスタの各操作ノードが最大容量である 15,000 ユーザー/ノードに達しています。 したがって、クラスタ A の別のノード（次の図のノード 4A など）が利用できなくなった場合は、クラスタ B が追加のユーザー 負荷を引き受ける責任を負います。 ノード 4A の 15,000 名のユーザーが改めてクラスタ B に割り当てられ、クラスタ B 内のすべてのノードに均等に分散されます。

ノード 4A と 5A が復元すると、クラスタ A のユーザーはクラスタのノード全体に再分配されます。 クラスタ B にフェイルオーバーしたユーザーは、この復元フェーズ中はクラスタ B に残ります。クラスタ間の不必要なユーザー割り当てを避けるためです。その結果は次の図のとおりです。

大規模な ハイブリッド カレンダー サービスの展開を計画する上で注意すべき重要な項目は、展開で障害が発生した場合の影響を理解することです。 同じ 126,000 名のユーザーの展開を使用しているが、データセンター全体が失われた場合、Calendar Connector ノードにユーザーが割り当てられない可能性があります。 このタイプのシナリオでのサービス停止を防ぐには、3 つ目のクラスタを用意し、影響を受けたユーザーを再分布かつ処理する必要があります。

ユーザー向けにハイブリッド メッセージ サービスを行う Expressway クラスタの容量は、構成している Expressway ノードのサイズ、クラスタのノード数、サービスの構成戦略によって異なります。

次の表は、ハイブリッド メッセージ サービスに使用される単一の Expressway の最大ユーザー数を示しています。

ユーザー数は、1 ノードのクラスターや、2 ノードのクラスターと同じです。 これはメッセージ サービスが、フェイルオーバーを使用してサービスの継続性を改善するためです。 ユーザーは、クラスターの複数のノードに均等に分散されます。 一方のノードで障害が発生した場合、そのノードのユーザーは他のノードに割り当てられます。

このトピックは、コネクタ ホストの Expressway を、カレンダー サービスとメッセージ サービスを含む複数のハイブリッド サービス用に、コネクタ間で共有することに関連したものです。 コネクタ ホストは、MRA や B2B など、他の Expressway ベースのソリューションとの間では共有されません。

コネクタ ホスト クラスターの容量は、構成している Expressway ノードのサイズ、ノード数、クラスターで動作しているコネクタの数、およびサービスの継続性戦略に応じて決まります。 これらの要因の詳細については、「ハイブリッド サービス ユーザーの Expressway クラスター容量を計画する」を参照してください。

また、異なるコネクタ ホスト クラスターのモデリングを行い、検討しているクラスターがサポートできる、サービスごとのユーザー数を確認するための計算機もあります。

一般的に、最大 2 つのノードがある小規模なサイズの展開に対してのみ、この機能をおすすめします。 展開が 2 つのノードの容量を超える場合、特定のハイブリッド サービス専用の各 Expressway クラスタにコネクタを移動する必要があります。

例: 3 つの共存するコネクタをホストするコネクタ ホストのスケール

次のテーブルではスケールと共存の例を示します。 これは、コネクタ ホスト クラスターの異なる仕様に基づく、各サービスでのクラスターごとのユーザーの最大数を示しています。 クラスタはハイブリッド カレンダー サービス（オンプレミスの Exchange を使用）、ハイブリッド通話サービス、ハイブリッド メッセージ サービス間で共有されます。

紹介

このトピックは、コネクタ ホストの Expressway を、他の Expressway ベースのソリューションと共有することについて説明しています。 他の目的で使用している Expressway で、コネクタをホストすることにした場合、以下の重要な注意事項が当てはまります。

• 専用のコネクタ ホスト Expressway に当てはまるスケーラビリティ モデルはサポートできません。 この記事の他のトピックで読んだ事柄を基にした、または計算機から得られたユーザー数は、コネクタ ホストを他の　Expressway サービスと共有している場合には適用されません。

• Expressway ベースのサービスと、この記事で説明されているハイブリッド サービス コネクタの組み合わせ、および関連するユーザー数は、サポートされているシナリオに限られます。 他のシナリオはテストしていないため、それらが自分の環境で動作すると期待することことはできません。

Expressway ベースのカレンダー サービスと、通話コネクタおよび通話サービス トラバーサル

このシナリオでは、2 ノードの Expressway クラスター ハイブリッド カレンダー サービス コネクタです。 このクラスターは、他の Cisco 通話ソリューション (SIP シグナリングとメディア) の通話トラバーサルも行っています。

表には、Expressway ベースのコネクタとともに使用できる、いくつかのカレンダー環境を示しています。 Expressway ベースのカレンダ－ コネクタは、2 ノードよりも多くのノードから構成されるクラスターではサポートされていません。 Office 365 のより大きな規模をサポートする場合は、クラウド ベースのコネクタを使用してください（「カレンダー サービス スケール」を参照）。

_{† スケールの制限を避けるため、オンプレミスのコネクタを使用する代わりに、クラウドベースのカレンダー サービスを使用することを推奨します。 Expressway ベースのハイブリッド カレンダー サービスの場合、クラスタのノード サイズや数に関係なく、クラスタあたりの Office 365 の最大ユーザー数は 1,000 名です。この制限は、Microsoft クラウド サービスとのインタラクションに由来しており、オンプレミス Expressway 展開の規模とは関係していません。}

モバイルおよび Remote Access を使用したカレンダー

このシナリオでは、1 つまたは 2 つの小規模 Expressway VM の MRA クラスターが、カレンダー コネクタをホストしています。 このシナリオは、クラスターが MRA と 2 つのコネクタのためだけに使用されていると仮定しています。 クラスターは 1 つまたは 2 つの小規模ノードに制限されます。