NCC_Onprem_12_4_Installer.zip を、すべてのノードのホームディレクトリにコピーします。
例:scp NCC_Onprem_12_4_Installer.zip -i ssh_key.pem my-user@webrtc.corp.example.com:/home/my-user/
概要
Adobe Connect では、最新の WebRTC フレームワークを使用して、拡張オーディオおよびビデオ機能を提供しています。通常、この拡張オーディオビデオ設定は、特定の役割を持つ複数の Linux® ノードで実行されます。シグナリングノード、メディアノード、録画ノードなどです。この設定では PostgreSQL および Redis データベースも使用します。これらのデータベースは、使用状況に応じて 1 つのマシンにインストールすることも、別々のマシンにインストールすることもできます。
各ノードの設定は、まずインストーラー zip ファイルをノードにコピーして、設定ファイルを編集します。そして、依存関係インストールスクリプトを実行した後、最後にメインインストールスクリプトを実行することで行えます。このガイドでは、以下のトピックについて説明します。
これらの手順は「インストール」セクションで説明されています。
前提条件とシステム構成
拡張オーディオ / ビデオサーバー / ノードのサイズを推定
session_participants_count.sql ファイルを実行して、拡張オーディオ / ビデオサーバーのサイズを推定できます。SQL クエリの出力が、計算ツール(Excel ファイル)、Additional Enhanced A/V hardware estimator.xlsx の入力となります。
この計算ツールは、Adobe Connect の過去の使用状況に基づいて、VM の必要数を推定するのに役立ちます。この計算ツールには、次の入力項目が必要です。
- サーバーの CPU コアと RAM の数
過去 12 か月のピーク時同時セッション数と、平均出席者数を判別する際に使用する、接続された SQL クエリ数
各セッションの推定パブリッシャー数。パブリッシャーとは、会議室でのマイク(ミュートとミュート解除の両方)接続や、会議室での web カメラ(ライブと一時停止の両方)接続を行う会議出席者(主催者、プレゼンターまたは参加者)
session_participants_count.sql および Additional Enhanced A/V hardware estimator.xlsx のファイルは、いずれもインストーラーパッケージに含まれています。このパッケージから以外で入手することはできません。
FQDN と SSL 証明書の要件の推定
FQDN:
外部の Application Load Balancer 用の 1 つのパブリック DNS レコード(例:webrtc.example.com)
各メディアサーバー用の 1 つのパブリック DNS レコード(例:media-1.example.com)
SSL 証明書:
LB FQDN 用の 1 枚の SSL 証明書
メディアサーバーには TURNS の設定が推奨されているため、各メディアサーバーに 1 枚の証明書が必要
ネットワークアーキテクチャの理解
ポート開放要件
ソース | 保存先 | ポート | プロトコル | 使用 |
---|---|---|---|---|
シグナリングノード | Redis | 6379 | TCP | |
Postgres | 5432 | TCP | ||
録画ノード | 5000~5100 | TCP | ||
ASR ノード | 6000~6100 | TCP | ||
SIP または メディアサーバーノード |
5060 | UDP | SIP シグナリング用 |
|
SIP またはメディアサーバーノード |
5060 | TCP | ||
CPS サーバー | 80 | TCP | SSL を使用せずに実行している POC または デモの設定向け |
|
CPS サーバー /LB | 443 | TCP | ||
録画ノード | メディアサーバー ノード(*) |
443 | TCP | TURNS |
3478 | UDP | STUN/TURN | ||
3478 | TCP | STUN/TURN | ||
30000~65535 | UDP | SRTP(リアルタイムメディアフロー) | ||
CPS サーバー | 80 | TCP | SSL を使用せずに実行している POC または デモの設定向け |
|
CPS サーバー /LB | 443 | TCP | ||
Redis | 6379 | TCP | ||
シグナリングノード | 8090 | TCP |
||
シグナリングノード |
18443 | TCP | LB を使用せずに実行している POC またはデモの設定向け |
|
WebRTC ロードバランサー(**) | 443 | TCP |
||
メディアサーバーノード | Redis | 6379 | TCP |
|
Postgres | 5432 | TCP |
||
stun.I.google.com | 19302 | UDP | パブリック IP の検出用。NAT タイプの確認 |
|
stun1.I.google.com |
19302 | UDP | パブリック IP の検出用。NAT タイプの確認 |
|
シグナリングノード | 18443 | TCP | LB を使用せずに実行している POC または デモの設定向け |
|
メディアサーバーノード | 8445 | TCP | 複数のメディアの場合に実行しているクラスター向け |
|
WebRTC ロードバランサー(**) | 443 | TCP |
WebRTC ゲートウェイの登録用 |
|
CPS サーバー | WebRTC ロードバランサー |
443 | TCP | |
録画ノード | 80 | TCP |
録画ファイルのダウンロード | |
シグナリングノード | 18443 | TCP | LB を使用せずに実行している POC または デモの設定向け |
|
ユーザー / クライアント / インターネット | メディアサーバーノード(*) |
443 | TCP |
TURNS(TLS を介したオーディオビデオ) |
3478 | UDP | STUN/TURN |
||
3478 | TCP | STUN/TURN |
||
30000~65535 | UDP | SRTP(リアルタイムメディアフロー) |
||
CPS サーバー | 80 | TCP |
SSL を使用せずに実行している POC または デモの設定向け |
|
CPS サーバー /LB | 443 | TCP | ||
シグナリングノード | 18443 | TCP | LB を使用せずに実行している POC または デモの設定向け |
|
WebRTC ロードバランサー |
443 | TCP |
||
SIP ノード | Redis | 6379 | TCP |
ほとんどの場合、SIP サービスはメディアサーバーノードで実行 |
Postgres | 5432 | TCP |
||
WebRTC ロードバランサー |
443 | TCP |
||
シグナリングノード | 18443 | TCP | LB を使用せずに実行している POC または デモの設定向け |
|
自動キャプション /ASR ノード | Redis | 6379 | TCP | |
シグナリングノード | 8080 | TCP | メディア接続向け |
|
メディアサーバーノード(*) | 3000~65535 | UDP | SRTP(リアルタイムメディアフロー) |
|
443 | TCP |
TURNS | ||
3478 | UDP | STUN/TURN | ||
3478 | STUN/TURN | |||
シグナリングノード | 8090 | TCP |
||
CPS サーバー | 80 | TCP |
SSL を使用せずに実行している POC または デモの設定向け |
|
CPS サーバー /LB | 443 | TCP |
* ほとんどの場合、メディアサーバーにはパブリック IP アドレスがありますが、インターネット経由で Adobe Connect にアクセスする必要がない制限された環境では、プライベート IP アドレス用にポートを解放する必要があります。
** 複数のシグナリングノードへのトラフィックルーティングや、SSL オフロードのための外部 WebRTC ロード バランサーがあります。LB は、新しい WebRTC サーバーと CPS およびエンドユーザーの間のインターフェイスとして機能します。
負荷分散は、通常、以下の構成で外部の Application Load Balancer を介して行われます。
HTTPS ポート 443:シグナリングノードの HTTP ポート 18443 - CPS とエンドユーザーはこのリスナーに接続し、新しい WebRTC クラスターへのエントリポイントになります。
HTTPS ポート 443:シグナリングノードの HTTP ポート 9090 - 管理者が使用して WebRTC 管理者 web パネルに接続し、TURNS と SIP / テレフォニーを設定します。
詳しくは「拡張オーディオ / ビデオのオンプレミス設定用に負荷分散を設定する(WebRTC)」を参照してください。
拡張オーディオ / ビデオサーバーの必要システム構成
- OS - Red Hat Enterprise Linux 64 bit バージョン 8.6
- サーバーにインストールするサードパーティライブラリ(オープンソース)は次のとおりです。
- Podman 4.2.0
- Virtualenv 20.19.0
- Python 3.9
- Pip 21.3.1
- Python ライブラリ(pydantic、pyhocon、docker、redis、packaging、psycopg2-binary、python-json-logger、pystun3、coloredlogs、colorama)
典型的な拡張 AV 設定には、少なくとも 3 台の Red Hat サーバーが必要です。それぞれ、シグナリング、メディア、録画ノード用です。会議の負荷に基づく推定により、複数のメディアサーバー、録画、シグナリングノードが推奨される可能性があります。Application Load Balancer は、SSL オフロードや、CPS とシグナリングノードを使用するエンドユーザークライアント間の通信に使用されます。
負荷によっては、録画サービスコンテナをシグナリングノードで実行させて、2 台のサーバーのみで設定することもできます。
ここでは、最も一般的な 3 台のサーバー設定について詳しく説明します。
- 3 台の Red Hat サーバーをプロビジョニングします。構成については、Hardware estimator を参照してください。
- インストールには、sudo アクセス権を持つ root 以外のユーザーが必要です。
- Red Hat を新規インストールした後、新しいユーザー ID を作成します。
- RHEL で新しいユーザー ID の sudo を有効にするには、ID を wheel グループに追加します。
- su を実行して root になります。
- usermod -aG wheel your_user_id を実行します。
- ログアウトし、新しい ID を使用して再度ログインします。
- su を実行して root になります。
- シグナリングと録画ノードに静的 IP アドレスを割り当てます。
- メディアサーバーのパブリック IP アドレスをプロビジョニングして割り当てます。1:1 NAT を使用する場合は、パブリック IP をメディアサーバーのプライベート IP にマップする必要があります。
- メディアサーバーのパブリック DNS レコードを作成します。TURNS(TLS 443 を介した接続)の設定を強くお勧めします。そのため、この FQDN の SSL 証明書もプロビジョニングします。
- 3 つのノード間で必要なネットワーク ポートを開きます。「ネットワークアーキテクチャ」セクションを参照してください。
- 前のセクションで説明されているように、外部の Application Load Balancer を設定します。また、LB のパブリック DNS レコードを設定して SSL 証明書をプロビジョニングします。
インストーラー zip ファイルをコピー
-
-
必要に応じて、Jarsigner を使用し、ダウンロードした署名済み zip を確認します。Jarsigner は Java の一部としてインストールされています。
- コマンド「java -version」を使用して Java がインストールされているかどうかを確認します。Java がインストールされている場合は、Java のバージョンが出力されます。
- Java がインストールされていない場合、Java をインストールしてください。
sudo yum install java-1.8.0-openjdk-devel - 次に、ターミナルウィンドウに以下のコマンドをコピーし、「入力」をクリックします。
jarsigner -verify -verbose NCC_Onprem_12_4_Installer.zip - 確認の出力には次の要素が含まれます。
- zip 内のファイルのリスト
- アドビが認証用に提供する証明書情報
- 成功を示す「jar を確認しました」という出力メッセージ、または失敗を示す「jar を確認できません」という出力メッセージ
- 証明書情報が有効で、確認の成功を示す出力メッセージが表示された場合、ユーザーは zip の内容を使用してインストールを続けることができます。失敗した場合は、アドビサポートに連絡する必要があります。
-
ZIP を展開します。アクセス権がファイルに適切に付与されていることを確認します。
次のコマンドを使用します。明確に指定されていない限り、root/sudo アクセスでコマンドを実行しないでください。NCC_Onprem_12_4_Installer.zip
を展開します インストーラーの親ディレクトリに移動します。例:
cd ~/ncc-onprem-installer/
sudo chmod +x ExternalDependencies/install.sh
sudo chmod +x MainInstall.sh
sudo chmod +x check-connectivity.sh
sudo chmod +x uninstall.sh注意:インターネット接続のない環境またはロックダウンされた環境でセットアップを実行するには、以下のコマンドを実行します。
sudo chmod +x Externaldependecies/package-util.sh
-
依存関係インストールスクリプトを実行します。
- インターネット接続のない環境またはロックダウンされた環境でセットアップを実行するには、以下のコマンドを実行して外部依存関係をインストールします。インターネットへの接続が可能な場合は、次の手順 2 に進みます。
インストーラーの親ディレクトリに移動します。~/ncc-onprem-installer/ ディレクトリなどに移動していることを確認します。
bash ExternalDependencies/package-util.sh --install を実行します。この操作により、必要な外部依存関係がボックスにすべてインストールされます。
この操作はノードごとに 1 回必要です。
- インストーラーの親ディレクトリに移動します。~/ncc-onprem-installer/ ディレクトリなどに移動していることを確認します。
bash ExternalDependencies/install.sh を実行します。この操作により、必要な外部依存関係がボックスにすべてインストールされます。
この操作はノードごとに 1 回必要です。
- インターネット接続のない環境またはロックダウンされた環境でセットアップを実行するには、以下のコマンドを実行して外部依存関係をインストールします。インターネットへの接続が可能な場合は、次の手順 2 に進みます。
インストールプロセス
以下より、シグナリングノード、録画ノード、メディアサーバーノードの 4 つの Red Hat インスタンスに WebRTC 環境(例として)をシグナリングノード、録画ノード、メディアサーバーノード、ASR ノード。各ノードの指示について、containers.conf で設定されているサービスに細心の注意を払います。設定ファイルで、特定のサービス / コンテナのセットを使用して各ノードを設定する必要があります。
** ラボシステムでは、これらすべての「ノード」(シグナリング、録画、メディア、および ASR のサーバー)を 1 つの Linux インスタンスにインストールできます。その場合、containers.conf で、環境に必要なすべてのサーバー / コンテナに対して「count=1」を設定します。
シグナリングノード
シグナリングノードで、通常、次のサービスを実行します。各サービスは Docker コンテナとして実行されます。
- config(設定サービス)
- cas(新しい Connect API サービス)
- apigw(API ゲートウェイ / ルーター)
- liveswitch-gateway(WebRTC ゲートウェイサービス)
通常、シグナリングノードは、外部ロードバランサーを介して Connect クライアントにアクセス可能なプライベートサブネットに配置されます。
手順
-
hosts ファイルを編集します。
シグナリングノードでは、hosts ファイルを更新する必要があります。nano や vi などのテキストエディターを使用できます。
- nano や vi エディターを使用して /etc/hosts ファイルを開きます。例:sudo vi /etc/hosts
- 最後に次の行を追加します。<プライベート IP> は、このホストのプライベート IP に置き換えます。以下の各単語間のスペースに注意してください。
<プライベート IP> cas.ncc.svc.cluster.local gw.fm.ncc.internal config.ncc.svc.cluster.local pi.ncc.svc.cluster.local auth.ncc.svc.cluster.local
192.168.1.100 cas.ncc.svc.cluster.local gw.fm.ncc.internal config.ncc.svc.cluster.local pi.ncc.svc.cluster.local auth.ncc.svc.cluster.local
ASR ノードでは、hosts ファイルを更新する必要があります。nano や vi などのテキストエディターを使用できます。
- nano や vi エディターを使用して /etc/hosts ファイルを開きます。例:sudo vi /etc/hosts
- 最後に次の行を追加します。<プライベート IP> は、このホストのプライベート IP に置き換えます。以下の各単語間のスペースに注意してください。
<プライベート IP> gw.fm.ncc.internal
注意:<プライベート IP> をこのシグナリングホストのプライベート IP に変更します。
- nano や vi エディターを使用して /etc/hosts ファイルを開きます。例:sudo vi /etc/hosts
-
設定ファイルを編集します。
- ncc-onprem-installer/Config/config.conf に保存されている設定ファイルを編集します。ファイルを編集する手順は、設定ファイルにコメントとして追加されています。このファイルは、ホストごとに個別に編集する必要があります。
- 次に、ncc-onprem-installer/Config/containers.conf を編集します。ファイルを編集する手順は、ファイルにコメントとして追加されています。このファイルは、ホストごとに個別に編集する必要があります。インストールするサービスと配置するコンテナの数に応じて行います。
- 通常のシグナリングノードでは、以下をインストールします。
- casServer
- configService
- apiGateway
- gatewayServer
- redis
- postgres
- lb(オプション:追加の設定手順については、以下の「ロードバランサー」セクションを参照してください)
- 次に、上記のすべてのサービスに対して count=1 を設定し、それ以外のサービスに対して 0 を設定します。
- 重要:Config.conf を変更した後、configService に restart=1 を設定してください。
- 複数のシグナリングノードが必要な設定では、Redis および Postgres データベースは最初のノードにのみインストールされます。
- ncc-onprem-installer/Config/config.conf に保存されている設定ファイルを編集します。ファイルを編集する手順は、設定ファイルにコメントとして追加されています。このファイルは、ホストごとに個別に編集する必要があります。
-
メインインストーラースクリプトを実行します。
メインインストーラーディレクトリ cd ~/ncc-onprem-installer/ に切り替え、
メインインストーラースクリプト bash MainInstall.sh を実行します。確認メッセージを待ちます。
成功時のメッセージ:
2023-01-31 18:21:34,033 : INFO : Main : 55 : インストールに成功しました。
失敗時のメッセージ:
2023-01-31 20:04:44,849 : ERROR : Main : 59 : インストールに失敗しました。詳細については、installer.log を確認します。「トラブルシューティング」セクションを参照してください。
-
インストールを確認します。
- ヘルスチェック API
ノードのヘルスチェックについては、次の URL を参照できます。http://<プライベート IP>:18443/health。正常なレスポンスは、200 OK {"apigw":"ok"} となります。
RedHat マシンから確認する場合、CURL コマンドを使用できます。
例:curl -v http://172.31.56.203:18443/health - コンテナステータスの確認
ターミナルウィンドウで、docker ps のコマンドを実行します。
以下のような出力が表示されます。どのコンテナの「ステータス」も「再起動済み」になっていない必要があります。
- ヘルスチェック API
-
バンドルされた Nginx ロードバランサー(別名 lb コンテナ)を使用します。
インストーラーは、オープンソースの Nginx コンテナにバンドルされて、SSL オフロードできるようになります。
これは、ラボやシグナリングノードが 1 つしかない小規模な設定でのみ使用する必要があります。
LB は、シグナリングノードにインストールする必要があります。
このバンドルされた LB を使用する場合、シグナリングノードがパブリックサブネット(または DMZ)内にあり、パブリック IP を割り当てるか、1:1 NAT を介してパブリック IP にマップする必要があります。クライアントは、ポート 443 の LB URL を介してノードに直接接続します。
Connect にインターネットからアクセスする必要がない設定では、シグナリングはプライベートサブネット内にありますが、内部ネットワークからポート 443 でアクセスできます。
要件:
- 使用事例に応じたパブリック / プライベート DNS レコード
- DNS レコードの SSL 証明書
- SSL 証明書の秘密鍵
ロードバランサーの使用手順:
- mkdir -p ~/connect/loadbalancer/certs
- SSL 証明書(シグナリングノードの FQDN に対して発行されたもの)と秘密鍵を certs ディレクトリにコピーします。名前が、cert.crt と key.key であることを確認します。
- config.conf ファイルで、hostnames>lb セクションと hostnames>fqdn セクションに FQDN を追加します。これが WebRTC クラスターのエントリポイントになります。
- container.conf ファイルで、lb のカウントを 1 に更新します。
- 次に、bash MainInstall.sh を実行します。
AWS EC2 インスタンスでワイルドカード証明書を使用する場合:
- Route53 に A レコードを作成します。例えば、ワイルドカード証明書が *.example.com の場合、A レコードを webrtc.example.com として作成し、それを EC2 インスタンスの Elastic IP にマッピングします。
- ワイルドカード証明書とキーを ~/connect/loadbalancer/certs ディレクトリにコピーします。名前が、cert.crt と key.key であることを確認します。
- FQDN を追加します。例えば、hostnames>lb セクションの webrtc.example.com や hostnames>fqdn に追加します。
- container.conf ファイルで、lb のカウントを 1 に更新します。
- 次に、bash MainInstall.sh を実行します。
メディアノードで、次のサービスを実行します。
- liveswitch-media-server(メディアサーバー) - 拡張オーディオビデオの場合
- liveswitch-sip-connector(SIP サービス) - SIP を使用する場合
メディアノードはパブリックサブネット(または DMZ)内にあり、パブリック IP を割り当てるか、1:1 NAT を介してパブリック IP にマップする必要があります。クライアントは、メディアノードのパブリック IP に直接接続します。
拡張 AV(WebRTC)クライアントは ICE 方式を接続に使用し、以下のポートとプロトコルを介してメディアサーバーとのオーディオビデオストリームの確立を試みます。
- 30000~65535 の範囲の UDP ポートは、リアルタイムのメディアフローを処理します。
- UDP および TCP ポート 3478 は、STUN および TURN トラフィックを処理して、クライアントがファイアウォールを通過できるようにします。
- ポート 443 を介した TLS により、TURNS を有効にして、制限されたネットワークでのストリーミングの高可用性を確保します。
- C12 WebRTC ベースのクライアントは、ポート 443 を介した TLS に切り替える前に、すべてのオプション(TCP と UDP)を試行します。
- UDP および TCP ポート 5060 は、トランク / PBX 登録およびインバウンド / アウトバウンドコールの SIP トラフィックを処理します(SIP を使用している場合は必須)。
手順
-
メインインストーラースクリプトを実行します。
メインインストーラーディレクトリ cd ~/ncc-onprem-installer/
に切り替え、メインインストーラースクリプト bash MainInstall.sh を実行します。確認メッセージを待ちます。
成功時のメッセージ
2023-01-31 18:21:34,033 : INFO : Main : 55 : インストールに成功しました。
失敗時のメッセージ:
2023-01-31 20:04:44,849 : ERROR : Main : 59 : インストールに失敗しました。詳細については、installer.log を確認します。「トラブルシューティング」セクションを参照してください。
-
インストールを確認します。
ターミナルウィンドウで、docker ps のコマンドを実行し、liveswitch-media-server コンテナが実行されていることを確認します。
録画ノード
録画ノードは、プライベートネットワークで実行する必要があります。録画ノードでは、次の 1 つ以上のインスタンスを実行できます。
- hcr(録画コンテナ。実行可能な同時録画数は hcr コンテナの数で決まる)
- recordingserver(CPS に録画ファイルを提供するための web サーバー。録画ノードごとに 1 つ)
録画ノードは、次の方法で到達できる必要があります。
- ローカルネットワークから TCP 80。CPS で録画をダウンロード可能。
- ローカルネットワークから TCP 5000~5100。録画コンテナは、この範囲のホストポートに個別にバインド。
- ローカルネットワークから TCP 8090。
録画ノードは、メディアノードセクションに示されるポートのパブリック IP でメディアノードに接続でき、ポート 443 で CPS に接続できる必要があります。これにより、正常な録音が行われます。
手順
-
設定ファイルを編集します。
- config.conf ファイルを編集するか、シグナリングノードから ~/ ncc-onprem-installer /Config/config.conf をコピーします。
- 次に、~/ncc-onprem-installer/Config/containers.conf を編集します。ファイルを編集する手順は、ファイルにコメントとして追加されています。
- 録画サーバーノードでは、以下をインストールします。
- recordingContainer
- recordingserver
- recordingContainer
- 次に、recordingContainer に対して count >= 1 を、recordingserver に対して 1 を設定し、それ以外に対して 0 を設定します。
-
メインインストーラースクリプトを実行します。
メインインストーラーディレクトリ cd ~/ncc-onprem-installer/ncc-onprem-installer/ に切り替えます。
メインインストーラースクリプト bash MainInstall.sh を実行します。確認メッセージを待ちます。
成功時のメッセージ
2023-01-31 18:21:34,033 : INFO : Main : 55 : インストールに成功しました。
失敗時のメッセージ
2023-01-31 20:04:44,849 : ERROR : Main : 59 : インストールに失敗しました。詳細については、installer.log を確認します。「トラブルシューティング」セクションを参照してください。
-
インストールを確認します。
ターミナルウィンドウで、コマンド B を実行し、hcr と recordingserver コンテナが実行されていることを確認します。
ASR ノード
ASR ノードまたはクローズドキャプションノードは、プライベートネットワークで実行する必要があります。ASR ノードでは、ASR の 1 つ以上のインスタンスを実行できます(ASR コンテナー。ASR コンテナーの数は、クローズドキャプションを同時に実行する会議の数によって決まります)。
ASR ノードは、ローカルネットワークから TCP 6000~6100 で到達可能です。ASR コンテナーは、この範囲のホストポートに個別にバインドできます。
手順
-
設定ファイルを編集します。。
-
config.conf ファイルを編集するか、シグナリングノードから ~/ ncc-onprem-installer /Config/config.conf をコピーします。
-
次に、~/ncc-onprem-installer/Config/containers.conf を編集します。
-
ASR サーバーノードでは、次の内容をインストールします。
asrContainer
So, set count >= 1 for asrContainer
-
メインインストーラースクリプトを実行します。
メインインストーラーディレクトリ cd ~/ncc-onprem-installer/ncc-onprem-installer/ に切り替えます。
メインインストーラースクリプト bash MainInstall.sh を実行します。確認メッセージを待ちます。成功メッセージ
2023-01-31 18:21:34,033:INFO:Main:55:インストール成功。
失敗メッセージ
2023-01-31 20:04:44,849:ERROR:Main:59:インストールできませんでした。詳細については、installer.log を確認します。
環境の準備
インストーラー zip ファイルをコピーします。
-
NCC_Onprem_12_4_Installer.zip を、すべてのノードのホームディレクトリにコピーします。
例:scp NCC_Onprem_12_4_Installer.zip -i ssh_key.pem my-user@webrtc.corp.example.com:/home/my-user/ -
必要に応じて、Jarsigner を使用し、ダウンロードした署名済み zip を確認します。Jarsigner は Java の一部としてインストールされています。
- コマンド「java -version」を使用して Java がインストールされているかどうかを確認します。Java がインストールされている場合は、Java のバージョンが出力されます。
- Java がインストールされていない場合、Java をインストールしてください。
sudo yum install java-1.8.0-openjdk-devel - 次に、ターミナルウィンドウに以下のコマンドをコピーし、「入力」をクリックします。
jarsigner -verify -verbose NCC_Onprem_12_4_Installer.zip - 確認の出力には次の要素が含まれます。
- zip 内のファイルのリスト
- アドビが認証用に提供する証明書情報
- 成功を示す「jar を確認しました」という出力メッセージ、または失敗を示す「jar を確認できません」という出力メッセージ
- 証明書情報が有効で、確認の成功を示す出力メッセージが表示された場合、ユーザーは zip の内容を使用してインストールを続けることができます。失敗した場合は、アドビサポートに連絡する必要があります。
-
ZIP を展開します。アクセス権がファイルに適切に付与されていることを確認します。
次のコマンドを使用します。明確に指定されていない限り、root/sudo アクセスでコマンドを実行しないでください。NCC_Onprem_12_4_Installer.zip
を展開します インストーラーの親ディレクトリに移動します。例:
cd ~/ncc-onprem-installer/
sudo chmod +x ExternalDependencies/install.sh
sudo chmod +x MainInstall.sh
sudo chmod +x check-connectivity.sh
sudo chmod +x uninstall.sh -
依存関係インストールスクリプトを実行します。
インストーラーの親ディレクトリに移動します。
~/ncc-onprem-installer/ ディレクトリなどに移動していることを確認し、
bash ExternalDependencies/install.sh を実行します。この操作により、必要な外部依存関係がボックスにすべてインストールされます。この操作は、ノードごとに 1 回必要です。
アップグレードプロセスにはダウンタイムが必要です。
シグナリングノード
シグナリングノードで、通常、次のサービスを実行します。各サービスは Docker コンテナとして実行されます。
- config(設定サービス)
- cas(新しい Connect API サービス)
- apigw(API ゲートウェイ / ルーター)
- liveswitch-gateway(WebRTC ゲートウェイサービス)
手順
-
設定ファイルを編集します。
- ncc-onprem-installer/Config/config.conf に保存されている設定ファイルを編集します。ファイルを編集する手順は、設定ファイルにコメントとして追加されています。このファイルは、ホストごとに個別に編集する必要があります。以前のインストールの config.conf ファイルは参照用に使用できます。新しいファイルを古いファイルに置き換えないでください。新しいバージョンには重要な更新が含まれています。
- 次に、~/ncc-onprem-installer/Config/containers.conf を編集します。ファイルを編集する手順は、ファイルにコメントとして追加されています。このファイルは、ホストごとに個別に編集する必要があります。
- シグナリングノードをアップグレードする場合、通常、以下をインストールします。
- casServer
- configService
- apiGateway
- gatewayServer
- 以前のインストールのファイルを参照して、インストールするサービスと配置するコンテナの数を確認してください。以前にインストールしたすべてのサービスに対して count=1 を設定し、それ以外のサービスに対して 0 を設定します。
- 重要:Config.conf ファイルを変更した後、または新しいインストーラーを使用してアップグレードした場合、configService に restart=1 を設定してください。
- 重要:アップグレードの際、同梱されている Redis および Postgres データベースはインストールされないため、containers.conf ファイルでそれらのカウントを 0 にしておきます。
-
メインインストーラーディレクトリ cd ~/ncc-onprem-installer/
に切り替え、 メインインストーラースクリプト bash MainInstall.sh を実行します。インストーラーにより、自動でサービスが最新バージョンにアップグレードされます。確認メッセージを待ちます。
成功時のメッセージ :
2023-01-31 18:21:34,033 : INFO : Main : 55 : インストールに成功しました。
失敗時のメッセージ:
2023-01-31 20:04:44,849 : ERROR : Main : 59 : インストールに失敗しました。詳細については、installer.log を確認します。 -
インストールを確認します。
- ヘルスチェック API
ノードのヘルスチェックについては、次の URL を参照できます。http://<プライベート IP>:18443/health。正常なレスポンスは、200 OK {"apigw":"ok"} となります。RedHat マシンから確認する場合、CURL コマンドを使用できます。
例:curl -v http://172.31.56.203:18443/health コンテナステータスの確認
ターミナルウィンドウで、docker ps のコマンドを実行します。
以下のような出力が表示されます。どのコンテナの「ステータス」も「再起動済み」になっていない必要があります
- ヘルスチェック API
メディアサーバーノード
メディアノードで、次のサービスを実行します。
- liveswitch-media-server(メディアサーバー) - 拡張オーディオビデオの場合
- liveswitch-sip-connector(SIP サービス) - SIP を使用する場合
手順
-
設定ファイルを編集します。。
-
config.conf ファイルを編集するか、シグナリングノード ~/ncc-onprem-installer /Config/config.conf からファイルをコピーします。以前のインストールの config.conf ファイルは参照用に使用できます。新しいファイルを古いファイルに置き換えないでください。新しいバージョンには重要な更新が含まれています。
注意:制限された環境の場合は、gatewayServer セクションの externalStunUrls0 と externalStunUrls1 のエントリを空白にします。例:externalStunUrls0=""、externalStunUrls1=""。
-
次に、~/ncc-onprem-installer/Config/containers.conf を編集します。ファイルを編集する手順は、ファイルにコメントとして追加されています。
-
次に、~/ncc-onprem-installer/Config/containers.conf を編集します。ファイルを編集する手順は、ファイルにコメントとして追加されています。
-
メディアサーバーノードでは、以下をアップグレードします。
- mediaServer
- sipServer(SIP / テレフォニーが必要な場合)
-
以前のインストールのファイルを参照して、インストールするサービスと配置するコンテナの数を確認してください。以前にインストールしたすべてのサービスに対して count=1 を設定し、それ以外のサービスに対して 0 を設定します。
-
mediaServer ブロックで、mediaNodePublicIP および mediaNodePublicFQDN の値を更新します。詳しくは、インラインコメントを参照してください。
-
-
メインインストーラースクリプトを実行します
メインインストーラーディレクトリ cd ~/ncc-onprem-installer/
に切り替え、メインインストーラースクリプト bash MainInstall.sh を実行します。インストーラーにより、自動でサービスが最新バージョンにアップグレードされます。確認メッセージを待ちます。
成功時のメッセージ:
2023-01-31 18:21:34,033 : INFO : Main : 55 : インストールに成功しました。
失敗時のメッセージ:
2023-01-31 20:04:44,849 : ERROR : Main : 59 : インストールに失敗しました。詳細については、installer.log を確認します。「トラブルシューティング」セクションを参照してください。
-
インストールを確認します。
ターミナルウィンドウで、docker ps のコマンドを実行し、liveswitch-media-server コンテナと liveswitch-sip-connector(オプションのインストール)コンテナが実行されていることを確認します。
録画ノード
録画ノードは、プライベートネットワークで実行する必要があります。録画ノードでは、次の 1 つ以上のインスタンスを実行できます。
hcr(録画コンテナ。hcr コンテナの数は、実行可能な同時録画数と同じ)
手順
-
設定ファイルを編集します。
- config.conf ファイルを編集するか、シグナリングノードから ~/ ncc-onprem-installer /Config/config.conf をコピーします。以前のインストールの config.conf ファイルは参照用に使用できます。新しいファイルを古いファイルに置き換えないでください。新しいバージョンには重要な更新が含まれています。
- 次に、~/ncc-onprem-installer/Config/containers.conf を編集します。ファイルを編集する手順は、ファイルにコメントとして追加されています。
- 録画サーバーノードでは、以下をアップグレードします。
- recordingContainer
- 以前のインストールディレクトリの containers.conf を参照して、recordingContainer の count を同じ値に設定し、それ以外のサービスに対して 0 を設定してください。
- config.conf ファイルを編集するか、シグナリングノードから ~/ ncc-onprem-installer /Config/config.conf をコピーします。以前のインストールの config.conf ファイルは参照用に使用できます。新しいファイルを古いファイルに置き換えないでください。新しいバージョンには重要な更新が含まれています。
-
メインインストーラースクリプトを実行します。
メインインストーラーディレクトリ cd ~/ncc-onprem-installer/ncc-onprem-installer/
に切り替え、メインインストーラースクリプト bash MainInstall.sh を実行します。インストーラーにより、自動でサービスが最新バージョンにアップグレードされます。確認メッセージを待ちます。
成功時のメッセージ:
2023-01-31 18:21:34,033 : INFO : Main : 55 : インストールに成功しました。
失敗時のメッセージ:
2023-01-31 20:04:44,849 : ERROR : Main : 59 : インストールに失敗しました。詳細については、installer.log を確認します。「トラブルシューティング」セクションを参照してください。
-
インストールを確認します。
ターミナルウィンドウで、docker ps のコマンドを実行し、hcr コンテナが実行されていることを確認します。
次の手順は、すべての Adobe Connect 12(CPS)サーバーで実行する必要があります。
- 次の設定を、<インストールディレクトリ>/Connect/custom.ini にあるすべての Connect サーバーの custom.ini に追加します。
# CAS ディスカバリ URLのカンマ区切りリスト
# 可能な値
WEBRTC_CAS_DISCOVERY_URLS=http://<シグナリングノードの IP>:18443/api/cps/ingest
WEBRTC_CAS_DISCOVERY_URLS=http://<ロードバランサーの URL>/api/cps/ingest
# CAS へのリクエストの署名に使用される CAS の共有秘密。シグナリングノードの config.conf ファイルの hmac セクションに設定したものを入力。
WEBRTC_CAS_SHARED_SECRET=CorrectHorseBatteryStaple - ファイルを保存し、connectpro サービスを再起動します。
インストール後のプロセス
-
ネットワーク接続を確認します。
接続テストワークフローを実行して、異なるノード間のネットワーク接続を確認します。
- シグナリングノードにログインします。
- インストーラーの親ディレクトリに移動します。例:
cd ~/ncc-onprem-installer/ncc-onprem-installer/ - bash check-connectivity.sh のコマンドを実行します。
- 接続ツールは、 Config.conf ファイルで指定された値を使用して、次のような基本的なネットワークテストを実行します。
- 異なるサービス間の HTTP リクエスト
- 必要な TCP および UDP ポートでのネットワーク接続テスト
- 名前解決
- データベース接続
- このテストで、ノードとサービス間の必要な接続をチェックして結果を共有します。ネットワーク接続の問題を診断するのに役立ちます。
-
拡張オーディオビデオを使用した Adobe Connect 会議をテストします。
- 新規会議を作成して、拡張オーディオ / ビデオオプションが選択されていることを確認します。
- 会議室に参加し、マイクとカメラをオンにします。
- 可能であれば、別の PC またはモバイルデバイスからも会議室に参加し、オーディオビデオの状態を確認します。
- スクリーン共有を試す
- 録画を開始。30 秒待って停止。次に、録画にアクセスできるかどうかを確認
追加機能の設定
SIP を設定
SIP を設定するには、FM 管理者 web パネルにアクセスする必要があります。
-
http://<ロードバランサーのアドレス>:9090/admin にアクセスし、config.conf で設定されているユーザー名とパスワードを使ってログインします。ロードバランサーを使用していない場合は、http://<シグナリングノードのアドレス>:9090/admin にアクセスします。
-
アプリケーション/adobeconnect の順に移動し、下にスクロールして「チャンネル」を表示します。「デフォルト(*)」および「ブロードキャスト-*」の両方のチャンネルグループ用に、「SIP アウトバウンド発信者 ID 設定」を設定します。
-
メインメニューから「導入」に移動し「SIP 設定」を編集します。
FM 管理者への TURNS 証明書のアップロード
TURNS バインディングの SSL 終端を提供するには、FM 管理者パネルに証明書をアップロードします。
証明書は PFX 形式であることが必要です。
次の手順に従います。
-
http://<ロードバランサーのアドレス>:9090/admin にアクセスし、config.conf で設定されているユーザー名とパスワードを使ってログインします。ロードバランサーを使用していない場合は、http://<シグナリングノードのアドレス>:9090/admin にアクセスします。
-
「証明書」に移動します。
-
「ファイル証明書」で「+」記号を選択し、使用するドメインの証明書をアップロードします。
TURNS バインディングの設定
この設定は、TURN 通信を安全に実施するために必要です。
前のセクションで説明した証明書をアップロード済みの場合は、次の手順を実行します。
-
「導入」に移動し「デフォルト」を選択します。
-
「詳細設定」セクションまで下にスクロールします。
-
アップロード済みの証明書で「TURNS バインディング」を設定します。
アンインストール
-
インストーラールートディレクトリ(ルートディレクトリに uninstall.sh あり)cd ~/ncc_onprem_installer に変更します。
-
bash uninstall.sh を実行します。
-
Postgres および Redis データベースのデータディレクトリをシグナリングノードから削除するには、次のコマンドを実行します。
sudo rm -rf ~/connect
この操作により、NCC コンポーネントと画像がシステムからすべて削除されます。ただし、外部依存関係(Python、PIP、Virtualenv および Python パッケージ)は削除されません。
docker.errors.DockerException: Error while fetching server API version: ('Connection aborted.', FileNotFoundError(2, 'No such file or directory'))
このエラーメッセージは、DOCKER_HOST 環境変数が正しく設定されていない場合に表示されます。次の手順に従います。
- インストーラーの親ディレクトリに移動します。例:
cd ~/ncc-onprem-installer/
- source ~/.bash_profile のコマンドを実行します。
上記の手順で問題が解決しない場合は、次の手順に従います。
- sudo yum remove podman-remote を実行して Podman を削除します。
- 現在のユーザーからログアウトし、再度ログインします。
- インストーラーの親ディレクトリに移動します。例:
cd ~/ncc-onprem-installer/
- bash ExternalDependencies/install.sh を実行します。
明確に指定されていない限り、root/sudo アクセスでコマンドを実行しないでください。
2023-03-22 03:27:12 : ERROR : Main : 48 : Postgres の起動に失敗しました。
このエラーメッセージは、権限の問題により Postgres Docker コンテナがホストボリュームをマウントできない場合に表示されます。次の手順に従います。
- インストーラーの親ディレクトリに移動します。例:
cd ~/ncc-onprem-installer/ - docker load -i images/postgres.tar.gz のコマンドを実行します。
- 次に、以下のコマンドを実行します。
docker run -d \
--env POSTGRES_PASSWORD='PostPass1234' \
--volume ~/connect/postgres/data:/var/lib/postgresql/data \
--publish 5432:5432 \
--network host \
--user 0 \
--restart always \
--name postgres \
docker-connect-release.dr-uw2.adobeitc.com/ncc-onprem/postgres:12.4.1 - これにより、ホストディレクトリの権限の問題が解決します。
- 次に、以下のコマンドを実行して、Postgres Docker コンテナを削除します。
docker rm -f postgres - 最後に、MainInstaller を再度実行します。
bash MainInstall.sh
pydantic.errors.PydanticImportError:「BaseSettings」は「pydantic-settings」パッケージに移動されました。詳しくは、https://docs.pydantic.dev/2.0/migration/#basesettings-has-moved-to-pydantic-settings を参照してください。
次の手順に従います。
- インストーラーの親ディレクトリに移動します。例:
cd ~/ncc-onprem-installer/ - source bin/activate
コマンドを実行します。 - 次に、このコマンドを実行して Pydatic をアンインストールします。
python3 -m pip uninstall pydantic - このコマンドを実行して Pydatic を再インストールします。
python3 -m pip install "pydantic==1.*"
- 最後に、MainInstaller を再度実行します。
bash MainInstall.sh
メディアサーバーには 1:1 の NAT が必要です。つまり、メディアサーバーのインターネットへの出入りは、すべてパブリック IP を使用する必要があります。 ルーターまたはファイアウォールでメディアサーバー用に 1:1 NAT を設定すると、メディアサーバーは STUN プロトコルを使用するためにそのパブリック IP を自動検出します。WebRTC ゲートウェイの管理インターフェイスに移動し、メディアバーがパブリック IP アドレスを検出できることを確認してください。
https://adminwebrtc.yourdomain.com/admin/#/servers
1:1 NAT が正常に機能した後でも、クライアントからメディアサーバーに到達できない
WebRTC クライアントは ICE を使用し、以下の順序でメディアサーバーとの音声・映像ストリームの確立を試みます。
UDP(ポート範囲:35000~65535)
TCP(ポート 3478 を超える)
TLS(ポート 443 を超える)
C12 WebRTC ベースのクライアントは、ポート 443 を超える TLS に切り替える前に、すべてのオプション(TCP と UDP)を試行します。
Connect 12.4.1 は、デフォルトで CPS、WebRTC、New Connect Cluster(通称 NCC)が同じ VLAN/VPC またはブロードキャストドメインにあることを前提に設計されています。異なるネットワークに設置されている場合は、CPS と NCC/WebRTC 間で適切なレイヤー 3 ルーティングを行い、双方向のネットワーク接続を確保するようにしてください。
CPS と NCC 間のネットワーク接続を確認するには、CURL と Telnet を使用します。
CPS と NCC 接続は、HTTPS でのみ動作します。
以下のエラーが FMGW コンテナログに表示されます。2 つ目の Redis インスタンスは、セカンダリ として実行するように設定されています。
エラー [FM.LiveSwitch.Signalling.Server.IdleThread][-] 2022-07-21T12:46:29.439Z アイドルスレッドで予期しないエラーが発生しました。
StackExchange.Redis.RedisServerException: READONLY 読み取り専用セカンダリに対して書き込むことはできません。
解決策:
Redis サービスに対応する設定ファイルを開き、属性「slave-read-only」の値を「no」に変更します。
回避策として、次の手順に従います。
- cd ncc-onprem-installer.
- mv Images images.
- sed -i 's/Images\//images\//' Installer/utils/global_constants.py.
- アンインストール - uninstall.sh を実行します。
- 再インストール - MainInstall.sh を実行します。
現時点では、ログの Influx DB 例外を無視できます。
インスタンスを再起動し、Docker コンテナを再起動した後に CAS コンテナのログを確認すると、例外が表示されます。
この問題を解決するには、CAS コンテーを再起動します。docker restart cas と入力します。