はじめに
このドキュメントでは、WebRTCサーバに大量のセッションが配置された後のセッション漏出に関するCisco Bug ID CSCvt73723の検出と回避策について説明します。その結果、ユーザはWebBridgeにログインできなくなったり、ゲストとして参加できなくなったりします。
前提条件
要件
次の項目に関する知識があることが推奨されます。
- Cisco Meeting Server(CMS)(CallBridgeおよびWebBridgeコンポーネント)
使用するコンポーネント
このドキュメントの情報は、Cisco Meeting Server(CMS)に基づくもので、特にWebBridge 2/CMA WebRTCコンポーネントに関連するものです。このドキュメントは、バージョン2.9で導入された新しいWebBridge 3/CMS Web appコンポーネントには適用されません。
このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、クリアな(デフォルト)設定で作業を開始しています。本稼働中のネットワークでは、各コマンドによって起こる可能性がある影響を十分確認してください。
CSCvt73723 – 大量のセッションがサーバ上に置かれた後で、WebRTCサーバがセッションをリークする
このバグを特定するには、どうすればよいですか。
エンドユーザの観点から見ると、ハード制限に達した後は他のユーザが会議に参加できないという症状が現れます。ログで、(このFAQによる)webbridgeの統計情報が149に達したことを突き止めても、必ずしもこれらすべてがリークされたセッションであることを意味しているわけではありません。これは、Web Bridgeがハードリミットに達し、新しい接続が許可されていないことを意味します。
「webbridge」:情報:[DEBUGGING] Stats 149, c:3477, d:3170
これらのリークしたセッションの数の計算はもう少し複雑で、CMAデスクトップクライアントまたはiOSクライアントを使用していない場合に実行できます。バージョン2.8以降、Call Bridgeは5分ごとにCMAセッション数(CMA WebRTC + CMAデスクトップクライアント+ CMA iOSクライアント)を報告します。これは「CMA」として報告されることに注意してください:「X/Y」。ここで、XはアクティブなCMAセッションの現在の数であり、Yは過去5分間のピークです。
情報:統計: {"callLegsPS": 1, "callLegs": "20/24", "CMA": "14/17", "sip": {"std": "0/1", "peer": "6/6"}}
Call Bridgeが14の現在のセッションを報告しているからといって、同じ場所に設置されているWeb Bridgeも14のセッションを報告しているということにはなりません。このマッピングは、単一の統合サーバでは1:1ですが、クラスタ化された導入では、Web Bridgeセッションは異なるCall Bridgeでコールをインスタンス化できます(特に、ロードバランシングが有効な場合、これはCMAのデフォルトです)。
したがって、1つの導入環境でリークしたセッションの合計数を計算するには、すべてのWeb Bridge統計情報からのアクティブセッションを組み合わせて、報告されたCMA Call Bridge統計情報と比較する必要があります。
どうすれば、この問題を回避できますか。
導入環境がこの状況に当てはまる頻度に応じて(数日ごとに1回または数週間ごとに1回)、リークしたセッションを消去してアクティブセッション数を0にリセットするWeb Bridgeを再起動することを推奨する必要があります。当然のことながら、これが日々の雑用となれば、この作業がコードブロックごとにスクリプトを使用して容易になる理由は面倒です。
################################################################
#### Cisco Meeting Server ####
#### Webbridge restart ####
#### Workaround for CSCvt73723 ####
#### feedback: willwoo@cisco.com ####
################################################################
#--------------------------------------------------------------
# ---------- DISCLAIMER ----------
#--------------------------------------------------------------
# Please note this script is NOT maintained or supported by Cisco.
# This is to be run at entirely your own risk.
# This script is not intended for redistribution
# Tested with python 3.7.4
#--------------------------------------------------------------
#--------------------------------------------------------------
# ---------- Libraries to import ----------
#--------------------------------------------------------------
import paramiko
import time
import datetime
#--------------------------------------------------------------
#--------------------------------------------------------------
# ---------- Deployment parameters to change ----------
#--------------------------------------------------------------
# WB Inventory - just extend or modify the below to match your deployment requirements.
# Enter the MMP IP of the server (can differ from interface webbridge service is running)
webbridges ={1:"127.0.0.1",2:"127.0.0.1",3:"127.0.0.1",4:"127.0.0.1"}
mmp_username = "admin" # MMP username
mmp_password = "password" # MMP password
#--------------------------------------------------------------
def mmp_webbridge_restart(mmp_address,uname,pword):
conn = paramiko.SSHClient()
conn.set_missing_host_key_policy(paramiko.AutoAddPolicy())
try:
conn.connect(mmp_address, 22, uname, pword)
stdin, stdout, stderr = conn.exec_command('webbridge restart')
time.sleep(1)
conn.close()
print_log_message('Webbridge on server: ' + mmp_address + ' restarted successfully')
except Exception as error:
print_log_message('Failed to restart webbridge on server ' + mmp_address + '. Error:')
print_log_message(str(error))
pass
def print_log_message(message):
time_stamp = datetime.datetime.now(datetime.timezone.utc)
time_stamp = str(time_stamp)
file = open('webbridge_restart_logs.txt', 'a')
file.write(time_stamp + " " + message + "\n")
file.close()
if __name__ == '__main__':
for wb in webbridges:
mmp_webbridge_restart(webbridges[wb], mmp_username, mmp_password)
################################################################
このスクリプトには若干の編集(29 ~ 30行目のクレデンシャルと27行目の導入でのWebブリッジのIPアドレス)が必要で、予想される負荷がない場合やメンテナンス時間帯にのみ実行する必要があります。このスクリプトは、アクティブなセッションをチェックせず、リストされているすべてのサーバで「webbridge restart」コマンドを実行するだけで、アクティブなWebRTCセッションは終了します。
このスクリプトを自動化するには、cronジョブをセットアップするか、タスクスケジューラを備えたWindows 10 PC上で実行します。Win 10 PCにPython 3.4+がインストールされていると仮定すると、次の手順を実行できます。
1.タスクスケジューラを開く
2. [基本タスクの作成]を選択します。
2.1このタスクの名前/説明を入力する
2.2このタスクを実行する頻度と時間を選択します(ここでは毎週土曜日の午前2時のオフピーク時にのみ実行することをお勧めします)。
2.3実行するアクション:「プログラムの開始」を選択
2.4アクション:
*プログラム/スクリプト: C:\<python.exeへのパス>
(python.exeへのパスがわからない場合は、cmdに移動して次のように入力します。 python -c "import sys; print(sys.executable)")
*引数の追加(オプション):webbridge_restart.py(またはpythonスクリプトの名前)
* Start in (オプション):C:\<path to webbridge_restart.py>
cronジョブを実行しているコンピュータは、設定されているCMSサーバのMMPにアクセスできる必要があります。スクリプトの実行後、webbridge_restart_logs.txtファイルが作成されます。このファイルには、さまざまなWebBridgeの再起動の詳細と、発生する可能性のある障害が含まれています。この例では、10.48.79.194への接続が成功した場合と、127.0.0.1への接続が失敗した場合(実際にはPCのループバックアドレス)を示しています。
2020-06-08 14:53:18.149915+00:00 Webbridge on server: 10.48.79.194 restarted successfully 2020-06-08 14:53:19.165543+00:00 Failed to restart webbridge on server 127.0.0.1. Error: 2020-06-08 14:53:19.165543+00:00 [Errno None] Unable to connect to port 22 on 127.0.0.1
スクリプトが正常に機能することをテストする方法は?
スクリプトの実行元となるPCにPythonがインストールされている場合は、最初に次の手順で手動でスクリプトを実行できます。
- cmdを開き、「cd」コマンドを使用してスクリプトの場所を参照します
- コマンド「python webbridge_restart.py」を使用してPythonファイルを実行します
- 'paramiko'モジュールがインストールされていないことを示すエラーが表示される場合は、'pip install paramiko'コマンドを使用して追加のライブラリをインストールする必要があります
- 完了したら、「python webbridge_restart.py」を使用してスクリプトを再実行できます(注:これによりwebbridgeが再起動し、現在実行中のWebRTC接続が切断されます)
正常に実行された場合は、webbridge_restart_logs.txtファイルで結果を確認できます。
この問題はいつ修正される予定ですか?
これは新しいバグではなく、Web Bridge 2 / CMA WebRTCでこれを修正する計画はありません。新しいWeb Bridge 3/CMS Webアプリ(2.9以降で利用可能)は完全に再設計されているため、このバグの影響を受けません。この問題の影響を大きく受けるお客様は、新しいCMS Webアプリケーションへの移行を検討する必要があります(ただし、2.9リリースのWeb Bridge 2と同等の機能はまだ提供されていません)。詳細については、CMS 2.9およびcms Webアプリケーションのリリースノートを参照してください)。
関連情報