> For the complete documentation index, see [llms.txt](https://library.zoom.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://library.zoom.com/technical-library/ja/naentpuraizusbisu/zoom-node/zoom-node-deployment-field-guide/zoom-node-deployment-considerations.md). # Zoom Node導入時の考慮事項 さまざまな導入例がZoom NodeおよびZoom Nodeサービスモジュールをどのようにサポートするかについて詳しくご確認ください このセクションには、Zoom Node が Zoom Meetings Hybrid や Zoom Phone Local Survivability (ZPLS) などのさまざまなサービスモジュールをサポートできる方法の例がいくつか含まれています。専用の IPアドレス を使用した一般的なデプロイは、以下の図の集合のようになります。 Zoom Node にデプロイされる各サービスには、一意の IPアドレス が必要です。ノードに管理用の特定のアドレスと、ノード上でデプロイされる各サービス用に 1 つずつ（最大 4 つ）割り当てられている場合、Zoom Node には最大 5 つの IPアドレス が割り当てられます。ZPLS などの単一サービスを実行する Zoom Node は、ノードとサービスが同じ IPアドレス を共有するように割り当てられている場合、1 つの IPアドレス でデプロイできます。 以下に、いくつかのデプロイ オプションを示します。各デプロイ オプションにおける IP の数と証明書（CN/SANs）に注意してください。 ### オプション 1: 専用 IP とホスト名でデプロイされた Zoom Meetings Hybrid
上の画像は、デプロイに必要な IP と証明書の構成要件を要約しています。 **Zoom Meetings Hybrid** オンプレミスまたはハイブリッド クラウド環境で。 以下の表では、例のノードを詳しく示し、そのアクティブ プロキシと MMR サービスモジュールを含めています: | コンポーネント | ホスト名 | TLS 証明書ロール | 機能 | | --------------- | -------------------- | --------------- | -------------- | | ノード OS | `node1.customer.com` | コモンネーム (CN) | コア オーケストレーション | | Zoom コネクタ プロキシ | `zcp1.customer.com` | サブジェクト代替名 (SAN) | シグナリングとセッション制御 | | メディアモジュールルーター 1 | `mmr1.customer.com` | サブジェクト代替名 (SAN) | メディアのルーティングと処理 | | メディアモジュールルーター 2 | `mmr2.customer.com` | サブジェクト代替名 (SAN) | メディアのルーティングと処理 | | メディアモジュールルーター 3 | `mmr3.customer.com` | サブジェクト代替名 (SAN) | メディアのルーティングと処理 | {% hint style="info" %} 各モジュールには専用の静的 IPアドレス を割り当てる必要があります。必要な IPアドレス の合計: 5 {% endhint %}
上の画像は、デプロイに必要な最小構成を示しています。 **Zoom Phone ローカル継続性（ZPLS）**。ZPLS は、Zoom Node VM 上で復旧ロジックをローカルに実行することで、インターネットやクラウドの障害が発生した場合でも電話サービスの継続的な可用性を実現します。 以下のホスト名を DNS に設定し、TLS 証明書に含める必要があります: * `node1.customer.com` * `zplsl.customer.com` **ホスト名の機能マッピング** | コンポーネント | ホスト名 | TLS 証明書ロール | 機能 | | ---------- | -------------------- | ----------- | ------------------------------------ | | ノード OS | `node1.customer.com` | コモンネーム (CN) | コア オーケストレーション | | ZPLS モジュール | `zplsl.customer.com` | サブジェクト代替名 | Zoom Phone Local Survivability のロジック | **TLS 証明書の構成** | フィールド | 値 | | ----------- | -------------------- | | コモンネーム (CN) | `node1.customer.com` | | サブジェクト代替名 | `zplsl.customer.com` | 上記の CN と SAN を両方含むように、証明書は生成または入手（公開 CA またはプライベート CA）する必要があります。これにより、モジュール間の安全な通信に対して適切な TLS 検証が可能になります。 **IPアドレスの要件** | 指標 | 値 / 説明 | | --------------- | -------------------------------------- | | 必要な IPアドレス の合計 | 5（一般的な割り当て） | | ZPLS のコンテキストで使用 | 2 個の IP（1 つはノード OS 用、1 つは ZPLS モジュール用） | 一般的なデプロイには 5 個の IP が必要ですが、 **実際に使用される IPアドレス は 2 つだけです** ZPLS のデプロイでは、モジュールごとに 1 つ、ある **専用のNode VM**. {% hint style="warning" %} ZPLS では、Node VM ごとに 1 つのモジュールしか許可されません。同じ VM に ZPLS を他の Zoom モジュールと同居させることはできません。 {% endhint %} これらの図はどう違いますか？ 1 枚目の画像は、Zoom Meetings Hybrid デプロイの例を示しています。2 枚目の画像は、Zoom Phone Local Survivability デプロイの例を示しています。 必要に応じて、最初の IP/ホスト名を OS と最初のモジュールで共有し、必要な IPアドレス、ホスト名、Subject Alternative Names（SAN）の数を減らすことができます。 ### オプション 2: 共有 IP と共有ホスト名でデプロイされた Zoom Meetings Hybrid
この構成では、オプション 1 の Zoom Meetings Hybrid 図に見られる Node 構造が繰り返されています。ただし、このデプロイでは、 **Node OS は、最初にデプロイされたモジュールと IPアドレスを共有します** （通常は Zoom コネクタ Proxy、ZCP）。これにより、TLS と機能要件を維持しながら、IP の使用量を削減できます。 以下のホスト名を DNS に設定し、TLS 証明書に含める必要があります: * `zcp1.customer.com` * `mmr1.customer.com` * `mmr2.customer.com` * `mmr3.customer.com` **ホスト名の機能マッピング** | コンポーネント | ホスト名 | TLS 証明書ロール | 機能 | | -------------------- | ------------------- | --------------- | -------------- | | ZCP（Zoom コネクタ 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` | | サブジェクト代替名 | `mmr1.customer.com`, `mmr2.customer.com`, `mmr3.customer.com` | 証明書には、Zoom Node とインストールされた Zoom モジュール間の安全な TLS 通信を可能にするため、すべての SAN を含める必要があります。 **IPアドレスの要件** | 指標 | 値 / 説明 | | ---------------- | --------------------------------- | | 必要な IPアドレス の合計 | 4 | | IP共有戦略 | Node OS は最初のモジュール（ZCP）と IP を共有します | | 個別の IPアドレスが必要なのは | ZCP/MMR1、MMR2、MMR3 | {% hint style="info" %} IPアドレスが **共有される** Node OS と最初にデプロイされるモジュール（ZCP）の間で、次のものだけが **4（4）個の IPアドレス** 必要です。この設計は、デプロイ基準に準拠しながら、IP の使用を最適化します。 {% endhint %}
上の画像は、最小構成の ZPLS デプロイメントで、そこでは **Node OS は、インストールされた ZPLS モジュールとIPアドレスを共有します**。これは **唯一のケースです** Zoom Node フレームワークにおいて、 **単一ホストの TLS 証明書** が有効となるのはこれだけです。 次のホスト名を DNS に設定し、TLS 証明書に含める必要があります: * `zplsl.customer.com` **ホスト名の機能マッピング** | コンポーネント | ホスト名 | TLS 証明書ロール | 機能 | | ---------- | -------------------- | ----------- | ------------------------------------ | | ZPLS モジュール | `zplsl.customer.com` | コモンネーム (CN) | Zoom Phone Local Survivability のロジック | **TLS 証明書の構成** | フィールド | 値 | | ----------- | ------------------- | | コモンネーム (CN) | `zcp1.customer.com` | | SANs | （不要） | この構成では、OS と ZPLS モジュールの両方が同じホスト名とIPアドレスを共有するため、単一ホストの証明書で十分です。 **IPアドレスの要件** | 指標 | 値 / 説明 | | -------------- | --------------------------------- | | 必要な IPアドレス の合計 | 1 | | IP共有戦略 | Node OSとZPLSは単一のIPアドレスを共有します | | デプロイメントの制約 | Node VMごとに許可されるモジュールは1つのみ（ZPLSのみ） | {% hint style="warning" %} ZPLSは、Zoom Nodeアーキテクチャでサポートされる唯一のシナリオであり、以下の条件を満たします： * 単一ホストの証明書（CNのみ）が許容されます * OSとモジュール間でIPを共有するため、デプロイメントに必要なIPアドレスは1つ（1）のみです * 同じVM上で追加モジュールを併置することはサポートされていません {% endhint %} ### デプロイメントに最適な証明書管理方法を選択します Zoom Nodeにデプロイされる各サービスモジュールには、Zoom Nodeの証明書信頼リストに含まれる、一般に信頼されている認証局（CA）によって署名された有効な証明書が必要です。これには、広く知られたパブリック認証局が含まれます。 Zoom Nodeには、2つの証明書管理方法があります： * **Auto PKI**: この革新的なソリューションは、公開で信頼された証明機関（CA）による安全な証明書の登録と更新を自動化します。Zoom は、登録および更新に関連する費用を負担します。 * **独自の証明書を持ち込む（BYOC）**: このオプションでは、主要な公開で信頼された CA によって署名された証明書をご自身で用意します。証明書の登録と更新はお客様が行います。顧客提供の証明書を使用する場合、Zoom Node が最大 5 つのホスト名/SAN に対応できる可能性がある点について追加の考慮事項があります。詳細は以下で説明します。 #### Auto PKI による証明書の自動管理 Zoom Auto PKI は、Zoom Node プラットフォームおよびそこにデプロイされたすべてのモジュール向けに、有効な公開で信頼された CA 証明書を自動的にインストールします。証明書の更新も自動的に処理されます。これにより、すべてのサービスと Zoom Node 自体の証明書管理が簡素化されます。 #### Auto PKI の証明書登録と更新の理解 以下のシナリオは、証明書の登録と更新の仕組みを理解するのに役立ちます。 例：管理者が新しい Node インスタンスをデプロイしました。各インスタンスには有効な x509 証明書が必要です。 **証明書の秘密鍵は、決してこのインスタンスを退出してはなりません**. Auto PKI のプロセスは次の手順を実行します: 1. **テンプレートの取得**: Zoomクラウドの Auto PKI サービスから、複数の CA プロバイダー向けオプションを含む、サポートされているすべての構成テンプレートを取得します。 2. **IP アドレスの収集**: Node で実行中のサービスが使用しているすべての IP アドレスを収集し、Zoomクラウドの Auto PKI サービスに送信します。 3. **DNS 名のプロビジョニング**: Auto PKI クラウドサービスは、次の形式の DNS 名のセットを返します `..zoomonprem.com`. これらのドメインは A/AAAA レコードで構成されます。 4. **予約済み DNS 名の要求**: 次の形式で予約済み DNS 名を要求します `rsvd-..zoomonprem.com`. 5. **証明書要求の生成**: SAN フィールドに第 3 ステップの DNS 名を、Common Name (CN) フィールドに第 4 ステップの予約名を使用して、x509 証明書要求を生成します。 6. **証明書の発行**: 証明書署名要求 (CSR) を Zoomクラウドの Auto PKI サービスに送信します。このサービスはその後、CA ベンダーと連携して、前のステップの SAN リストと CN フィールドを含む証明書を発行します。 7. **ローカル ストレージ**: 最後のステップで新たに発行された x509 証明書と、それに対応する秘密鍵（以前に生成済み）を書き込み、Node インスタンス上で実行中のサービスが利用できるようにします。 Auto PKI は、証明書の有効期限を自動監視し、新しい証明書を要求することで Zoom Node の証明書管理を簡素化し、手動更新の必要性をなくします。 #### 独自の証明書を持ち込む (BYOC) ローカル Web インターフェースを使用して、独自の有効な公開署名済み証明書を Zoom Node にインストールできます。これを初回インストール時に行うことも、後から行うこともできます。この手順は、Web ベースのアプリケーションに証明書をインストールしたことがある人にはおなじみでしょう。 独自の証明書を使用する場合は、証明書が複数のホスト名と通信するサーバー上にあることを忘れないでください。したがって、選択する証明書の種類は、1 つを超えるホスト名（証明書 CN）から発信されるトラフィックの暗号化をサポートしている必要があります。Node とデプロイするすべてのサービスで使用するホスト名はすべて、Zoom のクラウドサービスから公開解決可能でなければなりません。 Zoom は次の 2 種類の証明書を推奨しています: * **ワイルドカード証明書** * **マルチ SAN 証明書** (マルチドメイン証明書、SAN 証明書、または UCC 証明書とも呼ばれます) {% hint style="danger" %} 通常の単一ホスト証明書は、Zoom Node と単一のモジュールで 1 つの IP アドレスとホスト名を共有する特定のシナリオを除き、Zoom Node では使用できません。追加のコンテキストについては、の ZPLS 図を参照してください [#option-2-zoom-meetings-hybrid-deployed-with-a-shared-ip-and-shared-hostname](#option-2-zoom-meetings-hybrid-deployed-with-a-shared-ip-and-shared-hostname "mention") セクション。 {% endhint %} **ワイルドカード証明書: シンプルさのために推奨** ワイルドカード証明書は、ドメイン内の任意のホスト名からのトラフィックを暗号化できます。たとえば、\*.customer.com のようなワイルドカード証明書は、次のものからのトラフィックを暗号化できます `host1.customer.com` および `host2.customer.com` または、内の任意の名前 `.customer.com`. Zoom Node をデプロイしてワイルドカード証明書をインストールすると、デプロイするすべてのサービスがワイルドカード ドメインの FQDN を使用することを条件に、Node 上でデプロイしたあらゆるサービスのトラフィックを自動的に暗号化します。 これにより、Node 上でのサービスのデプロイに必要な作業が最小限に抑えられます。デプロイする前にサービス名を知る必要はありません。ただし、マルチ SAN 証明書方式を使用する場合は、サービス名を把握しておく必要があります。 **マルチ SAN、マルチドメイン、SAN、または UCC 証明書** {% hint style="warning" %} Node で使用するホスト名と IP アドレス（最大 1 つ）および、インストールするすべてのサービス（最大 4 つ）を把握しておく必要があります。 **証明書の登録前に、この情報が必要です**. {% endhint %} 5 つのホスト名からのトラフィックを暗号化するため、Zoom Node にはマルチ SAN 証明書が必要です。この証明書を 1 回だけ要求するには、計画済みの Node 名や、Node にデプロイする予定のすべてのサービス名など、必要なすべての情報を事前に把握しておく必要があります。たとえば、ZPLS のようなモジュールでは、1 つの Node に 1 つの ZPLS モジュールしかデプロイされないため、ZPLS サービスのホスト名に必要な追加の SAN は 1 つだけです。 次の表を例として使用できます: | ホスト名 (SAN) | IPアドレス | | ---------------------------- | ------------- | | `zoom-node01.company.com` | `10.1.50.100` | | `zpls.company.com` | `10.1.50.100` | | `zoom-recording.company.com` | `10.1.50.101` | | `zoom-ウェビナー.company.com` | `10.1.50.102` | | (サービス 4 - この例では使用されません) | (N/A) | これは典型的な構成の例で、1 つの Node が同じ IP 上で ZPLS をホストし、さらに別の 2 つのサービスが別々の IP 上でホストされています。『company.com』を実際のドメインに置き換え、ネットワークの IP アドレスを使用してください。 **DNS 解決要件** 双方向の信頼関係を確立できるように、Zoom ではホスト名が公開解決可能であることを要求しています。Node にあるすべての Zoom Node ホスト名と、デプロイされたすべてのサービス ホスト名を DNS ゾーンに含める必要があります。 組織が内部および外部のDNSサービスまたはドメインを分けて運用している場合、Zoom Node のホスト名は、外部DNSサーバーで名前解決可能なゾーンにホストする必要があります（ZoomのIP範囲に対してのみ解決するように制限できます）。社内のZoomユーザーとZoomクラウドは、同じホスト名セットを使用して通信する必要があります。 --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://library.zoom.com/technical-library/ja/naentpuraizusbisu/zoom-node/zoom-node-deployment-field-guide/zoom-node-deployment-considerations.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.