Cisco Meeting Serverのロードバランシングロジック

概要

このドキュメントでは、Cisco Meeting Server(CMS)（旧称Acano製品）のロードバランシングロジックについて説明します。このロジックについては、ロードバランシングのホワイトペーパーで説明しています。このドキュメントでは、このプロセスをフローチャートで視覚化し、選択アルゴリズムについて詳しく説明します。

前提条件

要件

次の項目に関する知識があることが推奨されます。

• Cisco Meeting Server Call Bridgeコンポーネント（およびそのクラスタリング）
• Cisco Meeting Server APIの設定

使用するコンポーネント

このドキュメントの情報は、Cisco Meeting Serverバージョン2.4.xに基づくものです。

このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、初期（デフォルト）設定の状態から起動しています。本稼働中のネットワークでは、各コマンドによって起こる可能性がある影響を十分確認してください。

CMSのロードバランシングアルゴリズムとは何ですか。

ロードバランシングは、会議リソースを効率的に使用するためにCMSバージョン2.1で導入されました。同じスペースをホストするCall Bridge間のディストリビューションコールの数を最小限に抑えようとします。このメカニズムは、Session Initiation Protocol(SIP)のReplacesヘッダーに基づいており、コール制御としてCisco Unified Communications Manager(CUCM)でサポートされています。また、ExpresswayバージョンX8.11（以降）とCMSバージョン2.4以降を組み合わせて使用することもできます。CMAコール（シッククライアントとWebRTCタイプの両方）は、CMSバージョン2.3以降でもロードバランシングできます。

注：現時点では、Lync/Skype通話のロードバランシングはどのCMSバージョンでもサポートされていないため、このフローチャートは適用されません。

注：ロードバランシングロジックはCMSスペースへのコールにのみ適用され、現時点ではゲートウェイコール（P2Pコール）またはデュアルホームコールには適用されません。

ロードバランシングのプロセスは、ホワイトペーパーの「ロードバランシングで設定を使用する方法」の項(「着信コールのロードバランシングのためのコールブリッジの設定」)で説明されています。これはテキスト形式で表示され、フローチャートで視覚化されています（ダウンロード）。

フローチャートでは、いくつかの略語と用語を使用しています。

• CB = Call Bridge
• ExistingConferenceLoadLimit = existingConferenceLoadLimitBasisPoints * loadLimit
  （デフォルトでは、existingConferenceLoadLimitBasisPointsは8000に相当し、80 %に相当します）
• NewConferenceLoadLimit = newConferenceLoadLimitBasisPoints * loadLimit
  （デフォルトでは、newConferenceLoadLimitBasisPointsは5000に相当し、50 %に相当します）。

MediaProcessingLoadが参照されている場合、コールが着信した特定のCall Bridgeに関して表示されます。このロード値は、/system/loadのAPI GETを使用してリアルタイムで確認でき、その時点でこのCall Bridgeによって処理される実際のロードを示します。

右端の下のボックスでコールを終了すると、コールは最も高いプライオリティを持つサーバにリダイレクトされます。これは、Call Bridgeサーバ自体の場合も、Call Bridgeグループ内でコールが発生した別のサーバの場合もあります。負荷に基づいて決定が行われず、スペースがCall Bridge上ですでにアクティブであるかどうかについては、複数のCall Bridgeと関連があります。この場合、最終的な決定は、各スペースに割り当てられているデフォルトのCall Bridgeプリファレンスに基づいて行われます。このCall Bridgeプリファレンスは、スペースの作成時に自動的に割り当てられ、複数の属性のハッシュ値に基づいているため設定できません。この結果、すべてのCall Bridgeで異なるスペースに対して均等（ランダム）な分配が行われます。

特定のスペースのCall Bridgeプリファレンスを表示するには、次の例に示すように、CMSイベントログでこれを確認する必要があります。

ロードバランシングアルゴリズムの例

このセクションでは、考えられるシナリオの例と、コールが到達したCMSのイベントログに、フローチャートで説明されているロードバランシングプロセスがどのように示されるかについて説明します。

これらの例では、3つのCall Bridgeで構成されるCall Bridge Groupでラボ設定が使用されています。existingConferenceLoadLimitBasisPoints設定とnewConferenceLoadLimitBasisPoints設定は、それぞれloadLimit値の80 %と50 %に対応するデフォルト値に設定されました。

特定のCall Bridgeの現在のMediaProcessingLoadを確認するには、https://<ip-or-fqdn-of-callbridge>:<webadmin-port>/api/v1/system/loadを参照し、図に示すようにAPIまたはadminアカウントでログインします。

例1:Call Bridgeに負荷がない

この例では、どのCall Bridgeでもアクティブなコールはありません。したがって、すべてのサーバのMediaProcessingLoadは0になります。

（CMSとコール制御デバイスの両方でロードバランシングが有効な）Call Bridge（ここでcluster1）のいずれかにコールを発信すると、コールが着信したCall Bridgeのイベントログを確認できます。

2018-12-29  10:51:29.490  Info     call 75: incoming SIP call from "sip:1060@steven.lab" to local URI "sip:stejanss.space@cluster.steven.lab"
2018-12-29  10:51:29.565  Info     replace query for conference 4d2542b2-8e72-45f5-a66c-f8a95f355f93: response from 'cluster1' (priority: 1, load level: 0, conference is running: 0)
2018-12-29  10:51:29.712  Info     replace query for conference 4d2542b2-8e72-45f5-a66c-f8a95f355f93: response from 'cluster2' (priority: 2, load level: 0, conference is running: 0)
2018-12-29  10:51:29.717  Info     replace query for conference 4d2542b2-8e72-45f5-a66c-f8a95f355f93: response from 'cluster3' (priority: 0, load level: 0, conference is running: 0)
2018-12-29  10:51:29.717  Info     replace query for conference 4d2542b2-8e72-45f5-a66c-f8a95f355f93: using remote server 'cluster3' (priority: 0, load level: 0, conference is running: 0)
2018-12-29  10:51:29.717  Info     replacing call 'f8eeea46e0f0790a@10.10.50.13' to conference 4d2542b2-8e72-45f5-a66c-f8a95f355f93 on server 'cluster3'
2018-12-29  10:51:29.876  Info     call 75: ending; remote SIP cancel (remote cancel) - not connected after 0:00

この画面では、Call Bridgeグループ内の各Call Bridgeに対するreplaceクエリ行を確認できます。この行には、3つのセクションに分割されたロードバランシングアルゴリズムが表示されます。

• priority：そのスペースのコールブリッジプリファレンス
• load level：その時点でのCall Bridgeの負荷レベル
• conference is running：スペースがそのCall Bridgeでアクティブかどうかを示すブール値

その時点ではシステムにコールが発信されていないため、どのシステムにも負荷がなく（すべて0）、会議はどこにも実行されていません（すべて0）。この点に関して、最終的な決定はスペースのCall Bridgeプリファレンスに基づいて行われます。優先順位が低い方が優先されるため、置換中のコール回線から見て、ここでコールはcluster3という名前のCall Bridgeに置き換えられます。

Call Bridge cluster3で、この置換コールを示すイベントログ行を確認できます(また、このコールがどのCall Bridgeから来たか（ここではcluster1）、および同じ会議IDとコールIDを持っているか)。

2018-12-29  10:51:29.784  Info     replacing call 'f8eeea46e0f0790a@10.10.50.13' from server 'cluster1' into conference 4d2542b2-8e72-45f5-a66c-f8a95f355f93
2018-12-29  10:51:29.787  Info     call 193: outgoing SIP call to "1060@steven.lab" from space "Steven Janssens's space"
2018-12-29  10:51:29.792  Info     call 193: setting up UDT RTP session for DTLS (combined media and control)
2018-12-29  10:51:29.909  Info     call 193: compensating for far end not matching payload types
2018-12-29  10:51:29.911  Info     participant "1060@steven.lab" joined space bc218bfb-3bda-44f6-89a7-80d8dd616a80 (Steven Janssens's space)

コールが最も低いプライオリティ値（このスペースではcluster3）を持つCall Bridgeにすでに固定されている場合でも、イベントログには同じreplaceクエリ行が表示されますが、この時点でローカルサーバが使用されており、置換コール行はないことが示されています。

2018-12-29  11:05:25.202  Info     call 194: incoming SIP call from "sip:1060@steven.lab" to local URI "sip:stejanss.space@cluster.steven.lab"
2018-12-29  11:05:25.233  Info     replace query for conference 4d2542b2-8e72-45f5-a66c-f8a95f355f93: response from 'cluster3' (priority: 0, load level: 0, conference is running: 0)
2018-12-29  11:05:25.376  Info     replace query for conference 4d2542b2-8e72-45f5-a66c-f8a95f355f93: response from 'cluster2' (priority: 2, load level: 0, conference is running: 0)
2018-12-29  11:05:25.378  Info     replace query for conference 4d2542b2-8e72-45f5-a66c-f8a95f355f93: response from 'cluster1' (priority: 1, load level: 0, conference is running: 0)
2018-12-29  11:05:25.378  Info     replace query for conference 4d2542b2-8e72-45f5-a66c-f8a95f355f93: using local server 'cluster3' (priority: 0, load level: 0, conference is running: 0)
2018-12-29  11:05:25.380  Info     call 194: setting up UDT RTP session for DTLS (combined media and control)
2018-12-29  11:05:25.404  Info     participant "1060@steven.lab" joined space bc218bfb-3bda-44f6-89a7-80d8dd616a80 (Steven Janssens's space)

例2:Call Bridgeグループ内のスペースにすでに参加しているユーザ

この例では、例1に示すように、スペースはコールブリッジグループ内ですでにアクティブになっており、エンドポイント1060@steven.labがスペースにコールされています。

この場合、次の2つの状況があります。

1.このスペースをホストするCall Bridgeの負荷は既存の会議のしきい値よりも低いため、コールを受け入れることができます。

2.このスペースをホストするCall Bridgeの負荷が既存の会議のしきい値を超えているため、CMSは別のCall Bridgeへのコールの置き換えを試みます。

シナリオ 1.既存の会議のしきい値(80 %)よりも低いアクティブな領域と負荷

スペースがまだアクティブになっていないCall Bridgeにコールが到達した場合、そのスペースがCall Bridge上で名前cluster3でアクティブであることがイベントログに示されます。スペースがそこでアクティブであり、そのサーバの負荷が既存のしきい値(負荷レベル：0)よりも低いため、コールが置き換えられます。

2018-12-29  11:48:17.419  Info     call 82: incoming SIP call from "sip:800999@steven.lab" to local URI "sip:stejanss.space@cluster.steven.lab"
2018-12-29  11:48:17.477  Info     replace query for conference 4d2542b2-8e72-45f5-a66c-f8a95f355f93: response from 'cluster1' (priority: 1, load level: 0, conference is running: 0)
2018-12-29  11:48:17.607  Info     replace query for conference 4d2542b2-8e72-45f5-a66c-f8a95f355f93: response from 'cluster2' (priority: 2, load level: 0, conference is running: 0)
2018-12-29  11:48:17.607  Info     replace query for conference 4d2542b2-8e72-45f5-a66c-f8a95f355f93: response from 'cluster3' (priority: 0, load level: 0, conference is running: 1)
2018-12-29  11:48:17.607  Info     replace query for conference 4d2542b2-8e72-45f5-a66c-f8a95f355f93: using remote server 'cluster3' (priority: 0, load level: 0, conference is running: 1)
2018-12-29  11:48:17.607  Info     replacing call '4c28197eaebba178@10.10.2.250' to conference 4d2542b2-8e72-45f5-a66c-f8a95f355f93 on server 'cluster3'

会議が実行中の場合、最初にプライオリティが優先されるため、既存の会議しきい値よりも下位のロードレベルを持つ複数の候補が存在する場合は、プライオリティ値に従ってコールブリッジプリファレンスに移動します。しかし、ここではそうではありません。

シナリオ 2.既存の会議のしきい値(80 %)を超えるアクティブな領域と負荷

この場合、コールはそのCall Bridgeに置き換えられませんが、グループ内で使用可能なリソースを持つ別のCall Bridgeを探します。最初に、負荷が50 %（新しい会議のしきい値）未満のCall Bridgeがあるかどうかを確認し、まずそれらのCall Bridgeをロードします。このしきい値に満たない場合は、80 %（既存の会議しきい値）未満の使用可能な会議があるかどうかを確認します。

例1および2（シナリオ1）のコール後にCall Bridge cluster3の負荷をチェックすると、2000の負荷が表示されます。

そのCall Bridge cluster3のloadLimitが（例として）2250に設定されていると仮定すると、このCall Bridgeは0.80 * 2250 = 1800として計算される既存の会議しきい値を超えています

このシナリオで差別化を行うケースはまだ2つあります。

ケース1：グループ内の複数のサーバの負荷が新しい会議のしきい値(50 %)を下回っている

グループ内の他の2台のサーバでは、まだコールが処理されていないため、負荷は0のままであるため、両方のサーバでコールを処理できます。したがって、最終的な決定は、このスペースのCall Bridgeプリファレンスに基づいて行われます。Call Bridge cluster3はすでに満杯であるため、システムはcluster1とcluster2から最も低い優先順位を選択します。この場合はcluster1です。

2018-12-29  12:11:03.211  Info     call 86: incoming encrypted SIP audio call from "sip:2001@steven.lab" to local URI "sip:stejanss.space@cluster.steven.lab"
2018-12-29  12:11:03.263  Info     replace query for conference 4d2542b2-8e72-45f5-a66c-f8a95f355f93: response from 'cluster1' (priority: 1, load level: 0, conference is running: 0)
2018-12-29  12:11:03.405  Info     replace query for conference 4d2542b2-8e72-45f5-a66c-f8a95f355f93: response from 'cluster2' (priority: 2, load level: 0, conference is running: 0)
2018-12-29  12:11:03.412  Info     replace query for conference 4d2542b2-8e72-45f5-a66c-f8a95f355f93: response from 'cluster3' (priority: 0, load level: 2, conference is running: 1)
2018-12-29  12:11:03.412  Info     replace query for conference 4d2542b2-8e72-45f5-a66c-f8a95f355f93: using local server 'cluster1' (priority: 1, load level: 0, conference is running: 0)
2018-12-29  12:11:03.415  Info     call 86: setting up UDT RTP session for DTLS (combined media and control)
2018-12-29  12:11:03.434  Info     participant "2001@steven.lab" joined space bc218bfb-3bda-44f6-89a7-80d8dd616a80 (Steven Janssens's space)

cluster3コールブリッジのロードレベル：2は、既存の会議しきい値を超えたことを示すため、スペースがアクティブであったにもかかわらず、コールはそのサーバにロードバランシングされません。その代わりに、ロードレベルが0（使用率が50 %未満）の他のCall Bridgeの最小スペース優先度（この場合はcluster1）を調べます。

ケース2：グループ内で、負荷が新しい会議のしきい値(50 %)または既存の会議のしきい値(80 %)よりも低いサーバが1台のみ

最後のコール（およびcluster2への他のスペースへのコール）の後、説明した負荷がCall Bridgeで確認されました。

• クラスタ1 - 1200
• クラスタ2 - 400
• クラスタ3:4000

ここで、cluster1 Call Bridgeに設定されているloadLimitが1300であると仮定します。このCall Bridgeは、0.50 * 1300 = 650として計算される新しい会議しきい値と、0.80 * 1300 = 1040の既存の会議しきい値を超えます。

同じスペースのCall Bridge cluster3に新しいWebRTCコールが着信した場合、このスペースはcluster1とcluster3の両方でアクティブですが、両方とも既存の会議のしきい値を超えています。そのため、新しい会議のしきい値(50 %)または既存の会議のしきい値(80 %)で別のサーバを探します。この場合、cluster2だけが既存の会議のしきい値を下回りますが、cluster2コールブリッジで処理される別のスペースへの別のコールが原因で、すでに新しい会議のしきい値を超えています。

2018-12-29  12:45:33.162  Info     instantiating user "guest1685904798@cluster.steven.lab"
2018-12-29  12:45:33.162  Info     replace query for conference 4d2542b2-8e72-45f5-a66c-f8a95f355f93: response from 'cluster3' (priority: 0, load level: 2, conference is running: 1)
2018-12-29  12:45:33.299  Info     replace query for conference 4d2542b2-8e72-45f5-a66c-f8a95f355f93: response from 'cluster1' (priority: 1, load level: 2, conference is running: 1)
2018-12-29  12:45:33.299  Info     replace query for conference 4d2542b2-8e72-45f5-a66c-f8a95f355f93: response from 'cluster2' (priority: 2, load level: 1, conference is running: 0)
2018-12-29  12:45:33.299  Info     replace query for conference 4d2542b2-8e72-45f5-a66c-f8a95f355f93: using remote server 'cluster2' (priority: 2, load level: 1, conference is running: 0)

ここでは、Cluster2のloadLimit値は600に設定されています。新しいコールが着信する前の現在の負荷が400の場合、新しい会議のしきい値である0.5 * 600 = 300を超えていますが、既存の会議の制限である0.8 * 600 = 480を超えていません。したがって、これはload level: 1として置換クエリに表示されます（Call Bridgeが80 %のしきい値を超えている場合は2ではなく）。

例3：既存の会議のしきい値を使用したCall Bridgeでのコールランディング

この場合、ロードバランシングアルゴリズムは実行されません。これは、488 Responseをコール制御デバイスに返信し、グループ内の別のCall Bridgeにコールをルーティングするか（80 %の制限を下回る可能性があります）、現在のグループがリソース不足の場合に別のCall Bridgeグループにルーティングするか（フォールバックオプションとして）を決定する方が適切であるためです。

イベントログは、この部分が容量超過になったことを報告するだけなので、この部分の詳細は明示的には示しません。

2018-12-29  12:49:13.352  Info     call 88: incoming encrypted SIP call from "sip:2020@steven.lab" to local URI "sip:stejanss.space@cluster.steven.lab"
2018-12-29  12:49:13.399  Info     call 88: ending; local teardown, system participant limit reached - not connected after 0:00

コールがロードを処理できる別のCall Bridge（cluster2など）に送信されると、同じロードバランシングアルゴリズムが表示されます。

2018-12-29  12:49:13.434  Info     call 624: incoming encrypted SIP call from "sip:2020@steven.lab" to local URI "sip:stejanss.space@cluster.steven.lab"
2018-12-29  12:49:13.475  Info     replace query for conference 4d2542b2-8e72-45f5-a66c-f8a95f355f93: response from 'cluster2' (priority: 2, load level: 1, conference is running: 0)
2018-12-29  12:49:13.614  Info     replace query for conference 4d2542b2-8e72-45f5-a66c-f8a95f355f93: response from 'cluster3' (priority: 0, load level: 2, conference is running: 1)
2018-12-29  12:49:13.614  Info     replace query for conference 4d2542b2-8e72-45f5-a66c-f8a95f355f93: using local server 'cluster2' (priority: 2, load level: 1, conference is running: 0)
2018-12-29  12:49:13.618  Info     call 624: setting up UDT RTP session for DTLS (combined media and control)
2018-12-29  12:49:13.621  Info     call 624: starting DTLS UDT media negotiation (as initiator)
2018-12-29  12:49:13.640  Info     participant "2020@steven.lab" joined space bc218bfb-3bda-44f6-89a7-80d8dd616a80 (Steven Janssens's space)

注：ゲートウェイコールの場合、CMSは代わりに486 SIPエラーメッセージを返します。デフォルトでは、CUCMはStop Routing on User Busy Flagのサービスパラメータに従ってルーティングを停止するため、この設定を変更して、他のコールブリッジへのゲートウェイコールのフォールバックを許可することもできます。