Call Connector アーキテクチャのハイブリッド通話サービスがサポート終了 (EOL) したため、サービスは正式にサポートされなくなりました。ハイブリッド サービスの Expressway の将来の容量計画には Call Connector を含めないようにしてください。

この記事では、ハイブリッド カレンダー サービス Cisco TMS と Office 365 統合の容量計画、または Google Calendar と Cisco TMS 統合の容量計画については説明していません。容量情報については、「Cisco Webex ハイブリッド カレンダー サービス展開ガイド」を参照してください。

この記事では、容量についてのプランを立てることに関した質問と、ユーザーのスケーリングを計算する方法について説明します。シナリオをモデル化する際には、ハイブリッド サービス容量の計算機を使ってみてください。

プランニングの考慮事項

ハイブリッド サービスのユーザー数に適した容量のプランを立てる際には、以下の質問を考慮してください。

  • どのようなハイブリッド サービスが必要でしょうか?

    Expressway はハイブリッド通話サービス、ハイブリッド カレンダーサービス、ハイブリッド メッセージ サービスのコネクタをホストできます。

  • 各サービスに何人のユーザーがいますか?

    各サービスに存在するユーザーが多ければ多いほど、よりサービスに専用の Expressway クラスターが必要になるでしょう。ユーザー数が少ない場合には、共有クラスター (共存) で複数接続することも意味のある選択肢です。

  • 変更する必要がありますか?

    小規模な、1 つの Expressway クラスターで組織の早期採用者のグループにサービスを提供することから始めて、将来のロールアウトでの成長を予想してプランを立てることもできます。共有モデルから専用モデルに移行したり、発展した要件を満たしたりするために既存の要件をスケール化することが可能です。

寄与要因

ここでは、以下の変数の観点からクラスターの容量を定義します。

  • ノード サイズ—各 Expressway 仮想マシンには、VM に割り当てられたリソースによってインストール時に決定される「VM サイズ」があります。Expressway インストール ガイドはそれらの要件を説明します。Expressway がすでにある場合、Expressway インターフェイスの [ステータス] > [システム情報] ページで VM のサイズを確認できます。

  • ノード カウント—Expressway クラスタは 1 ~ 6 つのノードで構成される場合があります。これらは同じノード サイズであり、同じソフトウェア バージョンを実行している必要があります。

  • サービス継続性戦略: サービスはユーザーに継続的にサービスを提供するために戦略を使用します。カレンダー サービスとメッセージ サービスではフェイルオーバーを実行します。

    これらの戦略については、サービス継続性戦略および専用クラスターの拡大の表で詳しく説明します。

  • 共存: コネクタが Expressway クラスタを共有すると、各サービスで使用可能なリソースは、専用クラスタと比較して大幅に低下します。

    コネクター ホストが、それ以外にも、企業間通話 (B2B) やモバイルおよびリモート アクセス (B2B) といった、Expressway ベースのサービスをホストしている場合もあります。この種の共存をサポートしている、限界のあるシナリオに関してここで示しているスケール数は、当社での試験結果に合わせて制限されています。コネクタがホストしている Expressway クラスターを、本記事での説明を超えて、他のサービスと共有してはなりません。そのような構成はサポートされていません。

  • サービス固有の制限—たとえば、カレンダー コネクタは主に Microsoft Exchange ユーザーを対象とし、Office 365 ユーザーの数が制限されています。

専用 Expressway クラスターの計算

当社はテストとトライアルで収集した根拠に基づき、専用の単一 Expressway が管理できるサービス (「1 つのクラスター」) を利用可能なユーザー数に対し、厳しい制限を設けています。

表1。 専用の単一 Expressway でユーザー数制限
Expressway のノード サイズハイブリッド カレンダー サービスのスケールハイブリッド メッセージ サービスのスケール
1. 小さく50005000
2. 標準100006500
3. 大きく1500015000

サービス継続性アルゴリズムを使用して、以下の表で説明されている通り単一ノード数から複数ノード クラスターまで推定します。説明なしで結果が欲しい場合、参照してください。

表 2. サービス継続性戦略および専用クラスターのスケール

比較

Hybrid Calendar Service

ハイブリッドメッセージサービス

1. モデル

フェールオーバー モデル

フェールオーバー モデル

2. 説明

各ユーザーをクラスター内の 1 つのノードに割り当てます。これによりユーザーは、すべてのノードにアクセスできるようになります

あるノードがダウンした場合には、もう一方のノード群の対応するノードから、ユーザー割り当てを再度作成します。

ノードがバックアップされると、すべてのアクティブなノードにわたってユーザー割り当ての再配分を行います。

各ユーザーをクラスター内の 1 つのノードに割り当てます。これによりユーザーは、すべてのノードにアクセスできるようになります

あるノードがダウンした場合には、もう一方のノード群の対応するノードから、ユーザー割り当てを再度作成します。

ノードがバックアップされると、すべてのアクティブなノードにわたってユーザー割り当ての再配分を行います。

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 におけるすべての専用ケースと共存ケースでの最大ユーザー数を示しています。

表 3. 専用または共存シナリオでの単一中規模 Expressway のスケール
Expressway の目的カレンダー サービスのユーザーメッセージ サービスのユーザー

カレンダー サービス専用

10,000

メッセージ サービス専用

6,500

カレンダー サービスとメッセージ サービスにより共有

4,000

4,000

カレンダー サービス、通話サービス、メッセージ サービスにより共有

2,300

2,300

すべてのクラスター サイズでのすべての共存状態を網羅しているわけではありません。代わりに、既存のハイブリッド サービス展開の容量をモニターするか、新しい展開のプランのために計算機を使用してください。

計算機を使えば、コネクタ、ノード サイズ、およびノード数を選択して、展開をモデリングすることができます。このセクションの残りの部分では、モデルを基にユーザー数を計算する方法について説明します。

専用の Expressway で行ったように、複数ノードのユーザー数を決定するため、共有 Expressways のアルゴリズムの外挿を行います。専用の場合との違いは、クラスターの特定サービスのユーザースケールを得るために、適切なサービス継続性の計算を適用する点にあります。クラスターのユーザー スケールは計算できません。クラスターが競合する、ユーザーベースのサービス継続性戦略をホストしているからです。

表 4. 中程度ノードのクラスターのユーザー容量

クラスターの目的

1、2、3 ノードのハイブリッド メッセージ サービスのユーザー

メッセージ サービス専用

6,500

6,500

13,000

追加の貢献要因

ユーザー容量を減少させるクラスターのリソースの需要を競争している場合があります。既知の問題例は以下の通りです:

カレンダー サービス—コネクタ ホストは O365 ユーザーにもサービスを提供する可能性があります。ここに表示される数字や計算は、オンプレミス Exchange インフラストラクチャのみがカレンダー サービスを提供していることを仮定しています。「ハイブリッド カレンダー サービス」についての詳細は、この記事のカレンダー サービス セクションにいくつかの数字や図があります。

通話処理—コネクタ ホストは、通話シグナリングとメディアも処理できます。これは実質的に、顧客の組織と Webex クラウドの「ビジネス間」統合です。これにより、「他の Expressway ソリューションとの一貫性」に記述されているとおり、容量が削減されます。

Control Hub を使用すると、ハイブリッド サービス Expressway の各リソースにおける現在のユーザー容量の割合を表示できます。容量が許容範囲内であるかどうかを確認するためのカラーバーが表示されます。この表示により、ハイブリッドサービスの展開の正常性を評価し、より多くの Expressways が必要な時の指針となります。

  • —Expressways は許容される容量上限に達しています。(1%–60%)

  • オレンジ—十分な Expressways がありますが、容量上限に達しています。(61%–90%)

  • —十分な Expressways がないため、追加する必要があります。(91% 以上)

    Expressway がリソース グループ内にある場合には、そのリソース グループ内で、クラスターのフィルター済みビューの下に容量インジケータが表示されます。

  • リソース グループのない展開の場合 (デフォルト):

    1. https://admin.webex.com の顧客ビューから、[サービス] > [ハイブリッド] の順に移動し、ハイブリッド サービス カードまでスクロールして Expressway リソースで各サービスに対して使用されている容量の割合を表示します。

  • リソース グループのある展開について:

    1. https://admin.webex.com の顧客ビューから、[サービス] > [ハイブリッド] の順に移動し、ハイブリッド サービス カードまでスクロールし、[リソース][すべてを表示] をクリックします。

      容量バーは、リソース グループ外のクラスターの容量のみ示します。すべてのクラスターが 1 つ以上のリソース グループの一部である場合や、構成されているクラスターがないサービスの場合、容量バーは表示されません。

    2. 容量値が N/A の場合、[フィルターしてリソース グループおよび容量を確認する] からリソース グループを選択します。

      値が更新され、リソース グループのクラスターで使用されている容量のパーセンテージと、カラーコーディングが表示され、その健全性を示します。

注意点

  • クラスター容量は、ノード サイズ、Expressway クラスターのノード数、クラスターで実行しているサービス数、高可用性またはフェールオーバー戦略に応じて異なります。詳細については、カレンダーおよびメッセージのスケーリングのセクションを個々に参照してください。

  • 共存を構成すると、既存のサービスのユーザー スケールは減少します。容量のアルゴリズムでは、あらゆるユーザーがすべてのサービスを使用することを前提としています。

    共存は、複数のサービスを試験している場合、または小規模なスケールで展開する場合に推奨します。サービスを実運用する場合、または大規模なスケールで展開する場合には、それぞれのハイブリッド サービスを専用の Expressway クラスターで実行することを推奨します。

次に行うこと

ハイブリッド サービスに Expressways をさらに追加するには、クラウドにコネクタのホストを登録し、既存のクラスタにそれらを追加するための展開ガイドのステップを使用してください。

ハイブリッド カレンダー サービス ユーザーをサービスするための Expressway クラスタの容量は、構成されている Expressway-C ノードのサイズ、Expressway クラスタ内のノード数、およびサービスの継続性戦略によって異なります。

次の表は、異なるハイブリッド カレンダー環境専用の単一の Expressway の最大ユーザー数を示しています。

表 5. 1 つの専用 Expressway のハイブリッド カレンダー容量

カレンダー環境

小規模 Expressway

中程度 Expressway

大規模 Expressway

オンプレミス Exchange のみ

5,000 ユーザー

10,000 ユーザー

15,000 ユーザー

Office 365 のみ*

1,000 ユーザー

1,000 ユーザー

1,000 ユーザー

オンプレミス Exchange および Office 365* (Hybrid Exchange 展開)

5,000 人の合計ユーザーのうち最大 1,000 Office 365 ユーザー

10,000 人の合計ユーザーのうち最大 1,000 Office 365 ユーザー

15,000 人の合計ユーザーのうち最大 1,000 Office 365 ユーザー

* スケールの制限を避けるため、オンプレミスのコネクタを使用する代わりに、クラウドベースのカレンダー サービスを使用することを推奨します。Expressway ベースのハイブリッド カレンダーの場合、クラスターあたり 1,000 の Office 365 ユーザー容量制限は、クラスターのノード サイズまたはカウントとは関係ありません。この制限は、Microsoft クラウド サービスとのインタラクションに由来し、オンプレミス Expressway 展開のスケールからではありません。

専用クラスタのクラスタ タイプ別のハイブリッド カレンダー ユーザー容量

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

ハイブリッド カレンダーオンプレミス Exchange および Office 365 ユーザー容量

ハイブリッド カレンダー サービス ユーザーの 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 名に制限されます。

表 6 専用クラスタのハイブリッド カレンダー サービス ユーザー容量

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

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

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

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

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

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

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

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

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

各 6 ノードの 2 つのクラスタ。クラスタ A はノードごとに 12,500 ユーザーをホスト(合計 75,000 ユーザー)し、クラスタ B はノードごとに 8500 ユーザーをホスト(合計 51,000 ユーザー)します。ハイブリッド カレンダー サービスに割り当てられるユーザーは合計で 126,000 名です。
指定

ハイブリッド クラスタ カレンダー サービスは、ユーザー数が 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 の 1 つのノードが利用できなくなった

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

クラスタ A の 2 つのノードが使用できなくなった

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

アクティブ ノード間での復元とユーザーの再分布

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

データセンター損失の影響

ハイブリッド メッセージ ユーザーにサービスを提供するための Expressway クラスタの容量は、構成されている Expressway ノードのサイズ、クラスタ内のノード数、およびサービス継続性戦略によって異なります。

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

表 7 1 つの専用 Expressway でのハイブリッド メッセージ ユーザー容量

小規模 Expressway

中程度 Expressway

大規模 Expressway

5,000 ユーザー

6,500 ユーザー

15,000 ユーザー

専用コネクタ ホスト クラスタでのハイブリッド メッセージ ユーザー スケール

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

共存の例: クラスタ タイプ別のハイブリッド メッセージとカレンダー サービスのユーザー スケール

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

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

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

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

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

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

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

サービス

2 つの小規模ノード

2 つの中程度ノード

2 つの大規模ノード

カレンダー サービスのユーザー

1,300

2,300

3,000

メッセージ サービスのユーザー

1,300

2,300

3,000

紹介

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

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

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

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

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

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

表 9 通話トラバーサルを使用したカレンダー サービスのユーザー スケール

サービス

2 つの小規模ノード クラスター

2 つの中程度ノード クラスター

2 つの大規模ノード クラスター

Calendar Service

オンプレミス 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 ベースのハイブリッド カレンダーの場合、クラスターあたり 1,000 の Office 365 ユーザー容量制限は、クラスターのノード サイズまたはカウントとは関係ありません。この制限は、Microsoft クラウド サービスとのインタラクションに由来し、オンプレミス Expressway 展開のスケールからではありません。

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

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

表 10 小規模 MRA Expressway-C でのカレンダー コネクタのスケール

Expressway の目的

1 つの小規模な Expressway クラスター

2 つの小規模な Expressway クラスター

カレンダー サービスのユーザー数 (Exchange へのオンプレミス コネクタ)

500 ユーザー

500 ユーザー

モバイルおよびリモート アクセスのユーザー

100

100