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)	メディアのルーティングと処理

各モジュールには専用の静的 IPアドレス を割り当てる必要があります。必要な IPアドレス の合計: 5

上の画像は、デプロイに必要な最小構成を示しています。 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.

ZPLS では、Node VM ごとに 1 つのモジュールしか許可されません。同じ VM に ZPLS を他の Zoom モジュールと同居させることはできません。

これらの図はどう違いますか？ 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

IPアドレスが 共有される Node OS と最初にデプロイされるモジュール（ZCP）の間で、次のものだけが 4（4）個の IPアドレス 必要です。この設計は、デプロイ基準に準拠しながら、IP の使用を最適化します。

上の画像は、最小構成の 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のみ）

ZPLSは、Zoom Nodeアーキテクチャでサポートされる唯一のシナリオであり、以下の条件を満たします：

• 単一ホストの証明書（CNのみ）が許容されます

• OSとモジュール間でIPを共有するため、デプロイメントに必要なIPアドレスは1つ（1）のみです

• 同じVM上で追加モジュールを併置することはサポートされていません

デプロイメントに最適な証明書管理方法を選択します

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 名のセットを返します <instance_識別子>.<customer_識別子>.zoomonprem.com. これらのドメインは A/AAAA レコードで構成されます。

4. 予約済み DNS 名の要求: 次の形式で予約済み DNS 名を要求します rsvd-<randomized_string>.<customer_識別子>.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 証明書とも呼ばれます)

通常の単一ホスト証明書は、Zoom Node と単一のモジュールで 1 つの IP アドレスとホスト名を共有する特定のシナリオを除き、Zoom Node では使用できません。追加のコンテキストについては、の ZPLS 図を参照してください Zoom Node のデプロイメントに関する考慮事項 セクション。

ワイルドカード証明書: シンプルさのために推奨

ワイルドカード証明書は、ドメイン内の任意のホスト名からのトラフィックを暗号化できます。たとえば、*.customer.com のようなワイルドカード証明書は、次のものからのトラフィックを暗号化できます host1.customer.com および host2.customer.com または、内の任意の名前 .customer.com.

Zoom Node をデプロイしてワイルドカード証明書をインストールすると、デプロイするすべてのサービスがワイルドカード ドメインの FQDN を使用することを条件に、Node 上でデプロイしたあらゆるサービスのトラフィックを自動的に暗号化します。

これにより、Node 上でのサービスのデプロイに必要な作業が最小限に抑えられます。デプロイする前にサービス名を知る必要はありません。ただし、マルチ SAN 証明書方式を使用する場合は、サービス名を把握しておく必要があります。

マルチ SAN、マルチドメイン、SAN、または UCC 証明書

Node で使用するホスト名と IP アドレス（最大 1 つ）および、インストールするすべてのサービス（最大 4 つ）を把握しておく必要があります。

証明書の登録前に、この情報が必要です.

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クラウドは、同じホスト名セットを使用して通信する必要があります。