Zoom Node展開に関する考慮事項
さまざまな展開例がZoom NodeおよびZoom Nodeサービスモジュールをどのようにサポートするかについて詳しく学びます。
このセクションでは、Zoom Node が Zoom Meetings Hybrid や Zoom Phone Local Survivability (ZPLS) のようなさまざまなサービスモジュールをどのようにサポートできるかのいくつかの例を示します。専用 IP アドレスを使用した典型的なデプロイは、以下の一連の図のようになります。
Zoom Node にデプロイされる各サービスには固有の IP アドレスが必要です。ノードに管理用の特定のアドレスが割り当てられ、ノード上にデプロイされる各サービス（最大4つ）ごとに1つずつ割り当てられている場合、Zoom Node には最大で5個の IP アドレスが割り当てられます。単一サービス（例えば ZPLS）のみを実行する Zoom Node は、ノードとサービスが同じ IP アドレスを共有するように割り当てられている場合、単一の IP アドレスで展開できます。
以下にいくつかのデプロイオプションを示します。さまざまなデプロイオプションにおける IP と証明書（CN/SAN）の数に注意してください。
オプション 1: 専用 IP とホスト名でデプロイされた Zoom Meetings Hybrid
上図は、デプロイのための IP と証明書の構成要件を要約したものです Zoom Meetings Hybrid オンプレミスまたはハイブリッドクラウド環境でのデプロイにおける。
下の表は例のノードを分解し、そのアクティブなプロキシおよび MMR サービスモジュールを含みます:
ノード OS
node1.customer.com
コモンネーム (CN)
コアオーケストレーション
Zoom Connector Proxy
zcp1.customer.com
サブジェクト代替名 (SAN)
シグナリングおよびセッション制御
メディアモジュールルーター 1
mmr1.customer.com
サブジェクト代替名 (SAN)
メディアルーティングと処理
メディアモジュールルーター 2
mmr2.customer.com
サブジェクト代替名 (SAN)
メディアルーティングと処理
メディアモジュールルーター 3
mmr3.customer.com
サブジェクト代替名 (SAN)
メディアルーティングと処理
各モジュールに専用の固定 IP アドレスを割り当てる必要があります。必要な合計 IP アドレス数: 5 (五つ)
上図は、デプロイに必要な最小構成を概説しています Zoom Phone Local Survivability (ZPLS)。ZPLS は、サバイバビリティロジックを Zoom Node VM 上でローカルに実行することにより、インターネットやクラウドの障害発生時にも電話サービスを継続して利用可能にします。
以下のホスト名を DNS に設定し、TLS 証明書に含める必要があります:
node1.customer.comzplsl.customer.com
ホスト名の機能マッピング
ノード OS
node1.customer.com
コモンネーム (CN)
コアオーケストレーション
ZPLS モジュール
zplsl.customer.com
サブジェクト代替名
Zoom Phone Local Survivability ロジック
TLS 証明書の構成
コモンネーム (CN)
node1.customer.com
サブジェクト代替名（SAN）
zplsl.customer.com
証明書は上記の CN と SAN を含むように生成または調達（公開 CA またはプライベート CA）する必要があります。これにより、安全なモジュール間通信のための適切な TLS 検証が可能になります。
IP アドレス要件
必要な合計 IP アドレス数
5（一般的な割り当て）
ZPLS コンテキストでの使用
2 IP（1 はノード OS、1 は ZPLS モジュール用）
一般的なデプロイには 5 個の IP が必要ですが、 ZPLS デプロイでは実際に使用される IP アドレスは 2 個のみであり：モジュールごとに 1 つ、 専用のノード VM 上で動作します.
ZPLS はノード VM ごとに 1 つのモジュールのみを許可します。ZPLS を同じ VM に他の Zoom モジュールと共存させることはできません。
これらの図はどのように比較されますか？最初の画像は Zoom Meetings Hybrid デプロイの例を示しています。2 番目の画像は Zoom Phone Local Survivability のデプロイ例を示しています。
必要に応じて OS と最初のモジュール間で最初の IP/ホスト名を共有することで、必要な IP アドレス、ホスト名、およびサブジェクト代替名（SAN）の数を減らすことができます。
オプション 2: 共有 IP と共有ホスト名でデプロイされた Zoom Meetings Hybrid
この構成は、オプション 1 の Zoom Meetings Hybrid 図に示されているノード構造を繰り返します。ただし、このデプロイでは、 ノード OS が最初にデプロイされたモジュールと IP アドレスを共有します （通常は Zoom Connector Proxy、ZCP）。これにより、TLS と機能要件を維持しつつ IP の利用を削減できます。
以下のホスト名を DNS に設定し、TLS 証明書に含める必要があります:
zcp1.customer.commmr1.customer.commmr2.customer.commmr3.customer.com
ホスト名の機能マッピング
ZCP（Zoom Connector Proxy）
zcp1.customer.com
コモンネーム (CN)
シグナリングおよびセッション制御
メディアモジュールルーター 1
mmr1.customer.com
サブジェクト代替名 (SAN)
メディアルーティングと処理
メディアモジュールルーター 2
mmr2.customer.com
サブジェクト代替名 (SAN)
メディアルーティングと処理
メディアモジュールルーター 3
mmr3.customer.com
サブジェクト代替名 (SAN)
メディアルーティングと処理
TLS 証明書の構成
コモンネーム (CN)
zcp1.customer.com
サブジェクト代替名（SAN）
mmr1.customer.com, mmr2.customer.com, mmr3.customer.com
証明書には、Zoom Node とインストールされた Zoom モジュール間の安全な TLS 通信をサポートするすべての SAN を含める必要があります。
IP アドレス要件
必要な合計 IP アドレス数
4
IP 共有戦略
ノード OS が最初のモジュール（ZCP）と IP を共有
個別に必要な IP
ZCP/MMR1、MMR2、MMR3
IP アドレスが 共有されている ノード OS と最初にデプロイされたモジュール（ZCP）間で共有されている場合、 4（四つ）の IP アドレス のみが必要です。この設計は、デプロイ基準に準拠しながら IP の使用を最適化します。
上図は、ノード OS がインストールされた ZPLS モジュールと IP アドレスを共有する最小限の ZPLS デプロイを示しています。 ノード OS がインストールされた ZPLS モジュールと IP アドレスを共有します。これは 唯一のシナリオ Zoom Node フレームワーク内で、 単一ホスト TLS 証明書 が有効とされる
DNS に設定し、TLS 証明書に含める必要があるホスト名は次のとおりです:
zplsl.customer.com
ホスト名の機能マッピング
ZPLS モジュール
zplsl.customer.com
コモンネーム (CN)
Zoom Phone Local Survivability ロジック
TLS 証明書の構成
コモンネーム (CN)
zcp1.customer.com
SAN（サブジェクト代替名）
（必要ない）
この構成では、OS と ZPLS モジュールが同じホスト名と IP アドレスを共有しているため、単一ホスト証明書で十分です。
IP アドレス要件
必要な合計 IP アドレス数
1
IP 共有戦略
ノード OS と ZPLS が単一の IP アドレスを共有
デプロイ制約
ノード VM ごとに許可されるのは 1 モジュールのみ（ZPLS のみ）
ZPLS は、Zoom Node アーキテクチャにおいて次の点で唯一サポートされるシナリオです:
単一ホスト証明書（CN のみ）が許容される
OS とモジュールの IP 共有により、デプロイに必要な IP アドレスは 1 つのみで済む
同じ VM 上への追加モジュールの共存はサポートされない
デプロイに最適な証明書管理方法を決定してください
Zoom Node にデプロイされる各サービスモジュールには、Zoom Node の証明書信頼リストにある公的に信頼された認証局（CA）によって署名された有効な証明書が必要です。これには一般的に知られている公開認証局が含まれます。
Zoom Node は 2 つの証明書管理方法を提供します:
Auto PKI：この革新的なソリューションは、公的に信頼された認証局（CA）への安全な証明書登録と更新を自動化します。登録および更新にかかる費用は Zoom が負担します。
Bring Your Own Certificate (BYOC)：このオプションでは、任意の主要な公的に信頼された CA によって署名された自分自身の証明書を提供します。証明書の登録および更新はお客様が管理します。顧客提供の証明書を使用する場合、Zoom Node が最大で 5 つのホスト名/SAN を持つ可能性がある点に関する追加の考慮事項があり、これについては以下で詳述します。
Auto PKI による自動証明書管理
Zoom Auto PKI は、Zoom Node プラットフォームおよびその上にデプロイされたモジュールのために、有効な公的に信頼された CA 証明書を自動的にインストールします。証明書の更新も自動的に処理されます。これにより、すべてのサービスと Zoom Node 自体の証明書管理が簡素化されます。
Auto PKI の証明書登録と更新の理解
以下のシナリオは、証明書の登録と更新がどのように機能するかを理解するのに役立ちます。
例えば: 管理者が新しいノードインスタンスをデプロイしました。各インスタンスには有効な x509 証明書が必要です。 証明書の秘密鍵はこのインスタンスから決して持ち出してはなりません.
Auto PKI プロセスは次の手順を実行します:
テンプレート取得：Auto PKI サービスから複数の CA プロバイダのオプションを含むすべてのサポートされている構成テンプレートを Zoom クラウド内の Auto PKI サービスから取得します。
IP アドレス収集：ノード上で実行されているサービスが使用するすべての IP アドレスを収集し、それらを Zoom クラウド内の Auto PKI サービスに送信します。
DNS 名のプロビジョニング：Auto PKI クラウドサービスは、次の形式の一連の DNS 名を返します
<instance_identifier>.<customer_identifier>.zoomonprem.com。これらのドメインは A/AAAA レコードで構成されます。予約済み DNS 名リクエスト：次の形式の予約 DNS 名をリクエストします
rsvd-<randomized_string>.<customer_identifier>.zoomonprem.com.証明書リクエスト生成：SAN フィールドに 3 番目のステップで得られた DNS 名を、CN フィールドに 4 番目のステップで得られた予約名を使用して x509 証明書リクエストを生成します。
証明書発行：CSR（証明書署名要求）を Zoom クラウド内の Auto PKI サービスに送信します。このサービスは CA ベンダーと連携して証明書を発行し、前のステップでの SAN リストと CN フィールドを含みます。
ローカルストレージ：発行された x509 証明書と、それに対応する（前に生成された）秘密鍵を書き込み、ノードインスタンス上で実行されるサービスが利用できるようにローカルストレージに格納します。
Auto PKI は、有効期限の監視と新しい証明書のリクエストを自動的に行うことで、Zoom Node 上の証明書管理を簡素化し、手動での更新作業を不要にします。
Bring Your Own Certificates (BYOC)
ローカルの Web インターフェースを使用して、Zoom Node に自身の有効な公的署名済み証明書をインストールできます。これを初期インストール時に行うことも、後から行うことも可能です。このプロセスは、Web ベースのアプリケーションに証明書をインストールした経験がある人には馴染みのある方法です。
自身の証明書を使用する場合、証明書は複数のホスト名と通信するサーバ上に配置されることを忘れないでください。したがって、選択する証明書のタイプは複数のホスト名（証明書の CN）から発生するトラフィックの暗号化をサポートする必要があります。ノードおよびデプロイされるすべてのサービスで使用されるホスト名は、Zoom のクラウドサービスから公開解決可能でなければなりません。
Zoom は 2 種類の証明書を推奨します:
ワイルドカード証明書
マルチ SAN 証明書 （マルチドメイン証明書、SAN 証明書、または UCC 証明書とも呼ばれます）
一般的な単一ホスト証明書は、Zoom Node では機能しないことが多いです（唯一例外は、Zoom Node と単一のモジュールが単一の IP アドレスおよびホスト名を共有する特定のシナリオです）。追加の文脈については、ZPLS 図を参照してください。 Zoom Node展開に関する考慮事項 セクション。
ワイルドカード証明書: シンプルさのために推奨
ワイルドカード証明書はそのドメイン内の任意のホスト名からのトラフィックを暗号化できます。例えば、*.customer.com のようなワイルドカード証明書は次のホスト名からのトラフィックを暗号化できます: host1.customer.com および host2.customer.com またはドメイン内の任意の名前 .customer.com.
Zoom Node をデプロイしてワイルドカード証明書をインストールすると、展開するすべてのサービスのトラフィックを自動的に暗号化します。ただし、そのサービス群はワイルドカードドメインの FQDN を使用する必要があります。
これにより、ノード上にサービスをデプロイする手間が最小化されます: デプロイ前にサービス名を知っておく必要はありません。ただし、マルチ SAN 証明書方式を使用する場合はサービス名を把握しておく必要があります。
マルチ SAN、マルチドメイン、SAN、または UCC 証明書
ノード（最大 1 つ）およびインストールする予定のサービス（最大 4 つ）で使用するホスト名と IP アドレスを把握しておく必要があります。
この情報は証明書登録の前に必要です.
マルチ SAN 証明書は、Zoom Node に必要です。なぜなら 5 つのホスト名からのトラフィックを暗号化できるからです。この証明書の一度きりのリクエストには、計画中のノード名およびノードにデプロイ予定のすべてのサービス名など、必要なすべての情報を事前に把握しておく必要があります。例えば ZPLS のようなモジュールでは、ノードごとに 1 つの ZPLS モジュールしかデプロイされないため、ZPLS サービスのホスト名に対しては追加で 1 つの SAN だけが必要です。
次の表は例として使用できます:
zoom-node01.company.com
10.1.50.100
zpls.company.com
10.1.50.100
zoom-recording.company.com
10.1.50.101
zoom-webinar.company.com
10.1.50.102
（サービス4 - この例では未使用）
（該当なし）
この例は典型的な構成の例で、1 つのノードが同一 IP 上で ZPLS をホストし、さらに 2 つの追加サービスが別の IP 上で動作しています。「company.com」を実際のドメインに置き換え、ネットワークの IP アドレスを使用してください。
DNS 解決の要件
Zoom はホスト名が公開で解決可能であることを要求します。これにより双方向の信頼が確立できます。すべての Zoom Node ホスト名およびノードにデプロイされたすべてのサービスホスト名は DNS ゾーンに含まれている必要があります。
組織が内部および外部で別々の DNS サービスやドメインを運用している場合、Zoom Node のホスト名は外部 DNS サーバで解決可能なゾーンにホストする必要があります（Zoom の IP 範囲のみに解決を制限することも可能です）。組織内部の Zoom ユーザーと Zoom クラウドは、同一のホスト名セットを使用して通信する必要があります。
最終更新
役に立ちましたか？