> 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 Meetings Hybrid や Zoom Phone Local Survivability (ZPLS) のようなさまざまな Service Modules をどのようにサポートできるかについてのいくつかの例が含まれています。専用のIPアドレスを使用する一般的な導入は、次の図のコレクションのようになります。 Zoom Node に導入されるすべてのサービスには、一意のIPアドレスが必要です。Zoom Node には、Node に管理用の特定のアドレスが割り当てられ、さらに Node 上に導入される各サービス（最大4つ）に1つずつ割り当てられる場合、最大5つのIPアドレスが割り当てられます。単一のサービス（ZPLS など）を実行する Zoom Node は、Node とサービスが同じIPアドレスを共有するように割り当てられている場合、単一のIPアドレスで導入できます。 以下にいくつかの導入オプションを示します。さまざまな導入オプションにおける IP の数と証明書（CN/SANs）に注意してください。 ### オプション 1: 専用 IP とホスト名で導入された Zoom Meetings Hybrid
上の画像は、導入するための IP および証明書の構成要件を要約しています **Zoom Meetings Hybrid** オンプレミスまたはハイブリッド クラウド環境で。 以下の表は、Node の例を詳細に示しており、そのアクティブなプロキシおよび MMR Service Modules が含まれています。 | コンポーネント | ホスト名 | TLS 証明書ロール | 機能 | | ----------------- | -------------------- | --------------- | ---------------- | | Node 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 Local Survivability (ZPLS)**。ZPLS は、Zoom Node VM 上で survivability ロジックをローカルに実行することにより、インターネットまたはクラウドの中断が発生したイベントにおいても、電話サービスの継続的な可用性を可能にします。 次のホスト名を DNS に構成し、TLS 証明書に含める必要があります。 * `node1.customer.com` * `zplsl.customer.com` **ホスト名機能マッピング** | コンポーネント | ホスト名 | TLS 証明書ロール | 機能 | | ---------- | -------------------- | ----------- | ----------------------------------- | | Node OS | `node1.customer.com` | コモンネーム (CN) | コア オーケストレーション | | ZPLS モジュール | `zplsl.customer.com` | サブジェクト代替名 | Zoom Phone Local Survivability ロジック | **TLS 証明書構成** | フィールド | 値 | | ----------- | -------------------- | | コモンネーム (CN) | `node1.customer.com` | | サブジェクト代替名 | `zplsl.customer.com` | 証明書は、上記の CN と SAN の両方を含めるように生成または調達する必要があります（公開または非公開 CA）。これにより、安全なモジュール間通信のための適切な TLS 検証が可能になります。 **IPアドレス 要件** | 指標 | 値 / 説明 | | -------------- | ---------------------------------------- | | 必要な IPアドレス の合計 | 5（一般的な割り当て） | | ZPLS コンテキストで使用 | 2 つの IP（1 つは Node OS 用、1 つは ZPLS モジュール用） | 一般的な導入では 5 つの IP が必要ですが、 **実際にアクティブに使用される IPアドレス は 2 つだけです** ZPLS デプロイメントでは、モジュールごとに 1 つ、ある **専用の Node VM**. {% hint style="warning" %} ZPLS では、Node VM ごとに 1 つのモジュールしか許可されません。ZPLS を同じ VM 上の他の Zoom モジュールと同居させることはできません。 {% endhint %} これらの図はどのように比較されますか？ 1 枚目の画像は、Zoom Meetings のハイブリッドデプロイメントの例を示しています。2 枚目の画像は、Zoom Phone Local Survivability デプロイメントの例を示しています。 必要に応じて、最初の IP/ホスト名を OS と最初のモジュール間で共有し、必要な IP アドレス、ホスト名、および Subject Alternative Names (SANs) の数を減らすことができます。 ### オプション 2: 共有 IP と共有ホスト名でデプロイされた Zoom Meetings のハイブリッド
この構成は、オプション 1 の Zoom Meetings ハイブリッド図で見られる 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つの 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アドレス共有のため、デプロイには 1 つのIPアドレスのみが必要です * 同じVM上での追加モジュールの共存はサポートされていません {% endhint %} ### デプロイに最適な証明書管理方法を選択してください Zoom Node にデプロイされる各 Service Module には、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. **テンプレートの取得**：複数のCAプロバイダー向けオプションを含む、サポートされているすべての構成テンプレートを、Zoomクラウド内のAuto PKIサービスから取得します。 2. **IPアドレスの収集**：Node上で実行されているサービスによって使用されるすべてのIPアドレスを収集し、Zoomクラウド内のAuto PKIサービスに送信します。 3. **DNS名のプロビジョニング**：Auto PKIクラウドサービスは、次の形式のDNS名のセットを返します `..zoomonprem.com`。これらのドメインはA/AAAAレコードで構成されます。 4. **予約済みDNS名リクエスト**: 次の形式で予約済みDNS名を要求します `rsvd-..zoomonprem.com`. 5. **証明書リクエスト生成**: 第3ステップのDNS名をSANフィールドに、また第4ステップの予約名をCommon Name（CN）フィールドに使用して、X.509証明書リクエストを生成します。 6. **証明書発行**: 証明書署名要求（CSR）をZoomクラウド内のAuto PKIサービスに送信します。このサービスはその後、CAベンダーと連携して証明書を発行し、前のステップのSANリストとCNフィールドを含めます。 7. **ローカルストレージ**: 直前のステップで新たに発行されたX.509証明書と、その対応する秘密鍵（以前に生成済み）をローカルストレージに書き込み、Nodeインスタンス上で実行されるサービスから利用できるようにします。 Auto PKIは、期限切れ日を自動的に監視し、新しい証明書を要求することでZoom Node上の証明書管理を簡素化し、手動での更新を不要にします。 #### 独自の証明書を持ち込む (BYOC) ローカルのWebインターフェースを使用して、独自の有効な公開署名付き証明書を Zoom Node にインストールできます。これは、初回インストール時または後から行うことができます。この手順は、Webベースのアプリケーションに証明書をインストールすることに慣れている方にはなじみのあるものです。 独自の証明書を使用する場合、証明書は複数のホスト名と通信するサーバー上に配置されることを覚えておいてください。したがって、選択する証明書の種類は、複数のホスト名（証明書CN）から発信されるトラフィックの暗号化をサポートしている必要があります。Node およびデプロイされたサービスで使用されるすべてのホスト名は、Zoom のクラウドサービスから公開解決可能でなければなりません。 Zoom では、次の2種類の証明書を推奨しています。 * **ワイルドカード証明書** * **マルチSAN証明書** （マルチドメイン証明書、SAN証明書、または UCC 証明書としても知られています） {% hint style="danger" %} 一般的な単一ホストの証明書は、Zoom Node と単一のモジュールの間で単一の 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 \[1] 件）、およびインストールするサービス（最大 4 \[4] 件）を把握しておく必要があります。 **この情報は、証明書を登録する前に必要です**. {% endhint %} Zoom Node には、5 つのホスト名からのトラフィックを暗号化するため、マルチ SAN 証明書が必要です。この証明書の 1 回限りの要求には、計画されている Node 名および Node に展開予定のすべてのサービス名を含む、必要なすべての情報を事前に把握しておく必要があります。たとえば、ZPLS のようなモジュールでは、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つのノードが同じ IP 上で ZPLS をホストし、さらに 2 つの追加サービスが別々の IP 上にある典型的な構成です。“company.com” を実際のドメインに置き換え、ネットワークの IP アドレスを使用してください。 **DNS 解決要件** Zoomでは、双方向の信頼関係を確立できるよう、ホスト名が公開解決可能である必要があります。すべての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.