この記事に基づいて、Webex ハイブリッド サービスを導入する際のコネクタ容量を計画してください。また、スケーラビリティの推奨事項についての説明もお読みください。 専用および共存コネクタ展開について、コネクタ クラスターのサポート対象ユーザーの最大数、サポート対象ユーザー数の制限を決定する要素、Control Hub を使用して多くの Expressways を追加する必要があるか判断する方法を見つけることができます。
Call Connector アーキテクチャのハイブリッド通話サービスはサポート終了 (EOL) となり、サービスは正式にサポートされなくなりました。 ハイブリッド サービスの Expressway の将来の容量計画には Call Connector を含めないようにしてください。 |
この記事では、ハイブリッド カレンダー サービス Cisco TMS と Office 365 統合の容量計画、または Google Calendar と Cisco TMS 統合の容量計画については説明していません。 容量の詳細については、「Cisco Webex Hybrid カレンダー サービス展開ガイド」を参照してください。 |
この記事では、容量についてのプランを立てることに関した質問と、ユーザーのスケーリングを計算する方法について説明します。 シナリオをモデル化する際には、ハイブリッド サービス容量の計算機を使ってみてください。
プランニングの考慮事項
ハイブリッド サービスのユーザー数に適した容量のプランを立てる際には、以下の質問を考慮してください。
どのようなハイブリッド サービスが必要でしょうか?
Expressway はハイブリッド通話サービス、ハイブリッド カレンダーサービス、ハイブリッド メッセージ サービスのコネクタをホストできます。
各サービスに何人のユーザーがいますか?
各サービスに存在するユーザーが多ければ多いほど、よりサービスに専用の Expressway クラスターが必要になるでしょう。 ユーザー数が少ない場合には、共有クラスター (共存) で複数接続することも意味のある選択肢です。
変更する必要がありますか?
小規模な、1 つの Expressway クラスターで組織の早期採用者のグループにサービスを提供することから始めて、将来のロールアウトでの成長を予想してプランを立てることもできます。 共有モデルから専用モデルに移行したり、発展した要件を満たしたりするために既存の要件をスケール化することが可能です。
要因
ここでは、以下の変数の観点からクラスターの容量を定義します。
ノード サイズ - 各 Expressway 仮想マシン(VM)には、VM に割り当てられたリソースごとのインストール時に決定される「VM サイズ」があります。 Expressway インストール ガイドではそれらの要件を説明しています。 Expressway がすでにある場合、Expressway インターフェイスの ページで VM のサイズを確認できます。
ノード カウント - Expressway クラスターには 1 ~ 6 個のノードがある場合があります。 これらは同じノード サイズであり、同じソフトウェア バージョンを実行している必要があります。
サービス継続性戦略 - ユーザーに確実にサービス提供を継続するため、サービスはさまざまな戦略をとります。 カレンダー サービスとメッセージ サービスではフェイルオーバーを実行します。
これらの戦略については、サービス継続性戦略および専用クラスターの拡大の表で詳しく説明します。
共存—複数のコネクタが 1 つの Expressway クラスターを共有するときには、各サービスに利用可能なリソースは、専用クラスターと比較すると大幅に少なくなります。
コネクター ホストが、それ以外にも、企業間通話 (B2B) やモバイルおよびリモート アクセス (B2B) といった、Expressway ベースのサービスをホストしている場合もあります。 この種の共存をサポートしている、限界のあるシナリオに関してここで示しているスケール数は、当社での試験結果に合わせて制限されています。 コネクタがホストしている Expressway クラスターを、本記事での説明を超えて、他のサービスと共有してはなりません。そのような構成はサポートされていません。
サービス特有の制限—たとえば、Calendar Connector は主に Microsoft Exchange ユーザーを対象とし、Office 365 ユーザーのサポート数は限られています。
専用 Expressway クラスターの計算
当社はテストとトライアルで収集した根拠に基づき、専用の単一 Expressway が管理できるサービス (「1 つのクラスター」) を利用可能なユーザー数に対し、厳しい制限を設けています。
Expressway のノード サイズ | ハイブリッド カレンダー サービスのスケール | ハイブリッド メッセージ サービスのスケール |
---|---|---|
1. 小 | 5000 | 5000 |
2. 中 | 10000 | 6500 |
3. 大きく | 15000 | 15000 |
サービス継続性アルゴリズムを使用して、以下の表で説明されている通り単一ノード数から複数ノード クラスターまで推定します。 説明なしで結果が欲しい場合、参照してください。
比較 |
ハイブリッド カレンダー サービス |
ハイブリッド メッセージ サービス |
---|---|---|
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 におけるすべての専用ケースと共存ケースでの最大ユーザー数を示しています。
Expressway の目的 | カレンダー サービスのユーザー | メッセージ サービスのユーザー |
---|---|---|
カレンダー サービス専用 | 10,000 |
— |
メッセージ サービス専用 |
— |
6,500 |
カレンダー サービスとメッセージ サービスにより共有 |
4,000 |
4,000 |
カレンダー サービス、通話サービス、メッセージ サービスにより共有 |
2,300 |
2,300 |
すべてのクラスター サイズでのすべての共存状態を網羅しているわけではありません。 代わりに、既存のハイブリッド サービス展開の容量をモニターするか、新しい展開のプランのために計算機を使用してください。
計算機を使えば、コネクタ、ノード サイズ、およびノード数を選択して、展開をモデリングすることができます。 このセクションの残りの部分では、モデルを基にユーザー数を計算する方法について説明します。 |
専用の Expressway で行ったように、複数ノードのユーザー数を決定するため、共有 Expressways のアルゴリズムの外挿を行います。 専用の場合との違いは、クラスターの特定サービスのユーザースケールを得るために、適切なサービス継続性の計算を適用する点にあります。 クラスターのユーザー スケールは計算できません。クラスターが競合する、ユーザーベースのサービス継続性戦略をホストしているからです。
クラスターの目的 |
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 がリソース グループ内にある場合には、そのリソース グループ内で、クラスターのフィルター済みビューの下に容量インジケータが表示されます。
リソース グループのない展開の場合 (デフォルト):
リソース グループのある展開について:
注意点
クラスター容量は、ノード サイズ、Expressway クラスターのノード数、クラスターで実行しているサービス数、高可用性またはフェールオーバー戦略に応じて異なります。 詳細については、カレンダーおよびメッセージのスケーリングのセクションを個々に参照してください。
共存を構成すると、既存のサービスのユーザー スケールは減少します。容量のアルゴリズムでは、あらゆるユーザーがすべてのサービスを使用することを前提としています。
共存は、複数のサービスを試験している場合、または小規模なスケールで展開する場合に推奨します。 サービスを実運用する場合、または大規模なスケールで展開する場合には、それぞれのハイブリッド サービスを専用の Expressway クラスターで実行することを推奨します。
次に行うこと
ハイブリッド サービスに Expressways をさらに追加するには、クラウドにコネクタのホストを登録し、既存のクラスタにそれらを追加するための展開ガイドのステップを使用してください。
ハイブリッド カレンダー サービス ユーザーの 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 名に制限されます。 |
Expressway のノード サイズ |
1 または 2 ノード* |
3 ノード |
4 ノード |
5 ノード |
6 ノード |
---|---|---|---|---|---|
1. 小 |
5,000 |
10,000 |
15,000 |
20,000 |
25,000 |
2. 中 |
10,000 |
20,000 |
30,000 |
40,000 |
50,000 |
3. 大きく |
15,000 |
30,000 |
45,000 |
60,000 |
75,000 |
* ノードが 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 ホスト クラスタが必要です。 次の図に示されるとおり、ユーザーも均等に分散されます。
ハイブリッド クラスタ カレンダー サービスは、ユーザー数が 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 の最大ユーザー数を示しています。
小規模 Expressway |
中程度 Expressway |
大規模 Expressway |
---|---|---|
5,000 ユーザー |
6,500 ユーザー |
15,000 ユーザー |
ユーザー数は、1 ノードのクラスターや、2 ノードのクラスターと同じです。 これはメッセージ サービスが、フェイルオーバーを使用してサービスの継続性を改善するためです。 ユーザーは、クラスターの複数のノードに均等に分散されます。 一方のノードで障害が発生した場合、そのノードのユーザーは他のノードに割り当てられます。 |
このトピックは、コネクタ ホストの Expressway を、カレンダー サービスとメッセージ サービスを含む複数のハイブリッド サービス用に、コネクタ間で共有することに関連したものです。 コネクタ ホストは、MRA や B2B など、他の Expressway ベースのソリューションとの間では共有されません。
コネクタ ホスト クラスターの容量は、構成している Expressway ノードのサイズ、ノード数、クラスターで動作しているコネクタの数、およびサービスの継続性戦略に応じて決まります。 これらの要因の詳細については、「ハイブリッド サービス ユーザーの Expressway クラスター容量を計画する」を参照してください。
また、異なるコネクタ ホスト クラスターのモデリングを行い、検討しているクラスターがサポートできる、サービスごとのユーザー数を確認するための計算機もあります。
一般的に、最大 2 つのノードがある小規模なサイズの展開に対してのみ、この機能をおすすめします。 展開が 2 つのノードの容量を超える場合、特定のハイブリッド サービス専用の各 Expressway クラスタにコネクタを移動する必要があります。
例: 3 つの共存するコネクタをホストするコネクタ ホストのスケール
次のテーブルではスケールと共存の例を示します。 これは、コネクタ ホスト クラスターの異なる仕様に基づく、各サービスでのクラスターごとのユーザーの最大数を示しています。 クラスタはハイブリッド カレンダー サービス(オンプレミスの Exchange を使用)、ハイブリッド通話サービス、ハイブリッド メッセージ サービス間で共有されます。
サービス |
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 のより大きな規模をサポートする場合は、クラウド ベースのコネクタを使用してください(「カレンダー サービス スケール」を参照)。
サービス |
2 つの小規模ノード クラスター |
2 つの中程度ノード クラスター |
2 つの大規模ノード クラスター |
|
---|---|---|---|---|
カレンダー サービス |
オンプレミス 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 の最大ユーザー数は 1,000 名です。この制限は、Microsoft クラウド サービスとのインタラクションに由来しており、オンプレミス Expressway 展開の規模とは関係していません。
モバイルおよび Remote Access を使用したカレンダー
このシナリオでは、1 つまたは 2 つの小規模 Expressway VM の MRA クラスターが、カレンダー コネクタをホストしています。 このシナリオは、クラスターが MRA と 2 つのコネクタのためだけに使用されていると仮定しています。 クラスターは 1 つまたは 2 つの小規模ノードに制限されます。
Expressway の目的 |
1 つの小規模な Expressway クラスター |
2 つの小規模な Expressway クラスター |
---|---|---|
カレンダー サービスのユーザー数 (Exchange へのオンプレミス コネクタ) |
500 ユーザー |
500 ユーザー |
モバイルおよびリモート アクセスのユーザー |
100 |
100 |