> 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/zh-tw/jin-jie-qi-ye-fu-wu/zoom-node/zoom-node-deployment-field-guide/zoom-node-deployment-considerations.md).

# Zoom Node 部署考量

本節包含數個範例，說明 Zoom Node 如何支援各種服務模組，例如 Zoom Meetings Hybrid 和 Zoom Phone Local Survivability（ZPLS）。採用專用 IP 位址的典型部署可如下圖所示。

在 Zoom Node 上部署的每個服務都需要一個唯一的 IP 位址。如果 Node 已被指派一個用於管理的特定位址，且在 Node 上部署的每個服務（最多四個）各有一個位址，那麼 Zoom Node 最多可分配五個（5）IP 位址。若某個 Zoom Node 只執行單一服務（例如 ZPLS），且 Node 與該服務被設定共用相同的 IP 位址，則可只部署一個 IP 位址。

下方顯示了幾種部署選項。請注意各部署選項的 IP 數量與憑證（CN/SAN）數量。

### <mark style="color:藍色;">選項 1：以專用 IP 與主機名稱部署 Zoom Meetings Hybrid</mark>

<figure><img src="/files/9fe2908990bdca6677cc773469a885fb374ec7ed" alt=""><figcaption></figcaption></figure>

上圖概述了部署下列項目時所需的 IP 與憑證設定需求 **Zoom Meetings Hybrid** 於內部部署或混合雲環境中。

下表細分了範例 Node，並包含其作用中的 Proxy 與 MMR 服務模組：

| 元件                   | 主機名稱                 | TLS 憑證角色    | 功能          |
| -------------------- | -------------------- | ----------- | ----------- |
| Node 作業系統            | `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） | 媒體路由與處理     |

{% hint style="info" %}
您必須為每個模組指派專用的靜態 IP 位址。所需 IP 位址總數：五個（5）
{% endhint %}

<figure><img src="/files/c0b8c4c4cd4d7fb12730472d5baf052755388f3e" alt=""><figcaption></figcaption></figure>

上圖說明了部署以下項目所需的最低設定 **Zoom Phone Local Survivability（ZPLS）**。ZPLS 透過在 Zoom Node VM 上本機執行存活能力邏輯，在網際網路或雲端中斷時仍可持續提供電話服務。

必須在 DNS 中設定下列主機名稱，並將其納入 TLS 憑證：

* `node1.customer.com`
* `zplsl.customer.com`

**主機名稱功能對應**

| 元件        | 主機名稱                 | TLS 憑證角色 | 功能                                |
| --------- | -------------------- | -------- | --------------------------------- |
| Node 作業系統 | `node1.customer.com` | 一般名稱（CN） | 核心協調                              |
| ZPLS 模組   | `zplsl.customer.com` | 主體替代名稱   | Zoom Phone Local Survivability 邏輯 |

**TLS 憑證設定**

| 欄位       | 值                    |
| -------- | -------------------- |
| 一般名稱（CN） | `node1.customer.com` |
| 主體替代名稱   | `zplsl.customer.com` |

必須產生或取得憑證（公有或私有 CA），以納入上述列出的 CN 與 SAN。這可確保內部模組間通訊的 TLS 驗證正確無誤，並提供安全保障。

**IP 位址需求**

| 指標           | 值／說明                                  |
| ------------ | ------------------------------------- |
| 所需 IP 位址總數   | 5（一般分配）                               |
| 在 ZPLS 情境中使用 | 2 個 IP（1 個用於 Node 作業系統，1 個用於 ZPLS 模組） |

雖然一般部署需要五（5）個 IP， **但實際上只有兩（2）個 IP 位址在使用中** 於 ZPLS 部署中：每個模組各一個，執行於 **專用的 Node VM**.

{% hint style="warning" %}
ZPLS 每個 Node VM 只允許一個模組。您不能將 ZPLS 與其他 Zoom 模組共置於同一個 VM 上。
{% endhint %}

這些圖表有何差異？第一張圖顯示 Zoom Meetings Hybrid 部署的範例。第二張圖顯示 Zoom Phone Local Survivability 部署的範例。

如有需要，您可以讓 OS 與第一個模組共用第一個 IP／主機名稱，以減少所需的 IP 位址、主機名稱與主體替代名稱（SAN）數量。

### <mark style="color:藍色;">選項 2：以共用 IP 與共用主機名稱部署 Zoom Meetings Hybrid</mark>

<figure><img src="/files/455cd5b00d31ec23bf869b89d40998bc043a6a81" alt=""><figcaption></figcaption></figure>

此設定重複了選項 1 Zoom Meetings Hybrid 圖表中所見的 Node 架構。然而，在此部署中， **Node 作業系統會與第一個部署的模組共用其 IP 位址** （通常為 Zoom Connector Proxy，ZCP）。這可減少 IP 使用量，同時仍符合 TLS 與功能需求。

必須在 DNS 中設定下列主機名稱，並將其納入 TLS 憑證：

* `zcp1.customer.com`
* `mmr1.customer.com`
* `mmr2.customer.com`
* `mmr3.customer.com`

**主機名稱功能對應**

| 元件                        | 主機名稱                | TLS 憑證角色    | 功能          |
| ------------------------- | ------------------- | ----------- | ----------- |
| 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`                                           |
| 主體替代名稱   | `mmr1.customer.com`, `mmr2.customer.com`, `mmr3.customer.com` |

憑證必須包含所有 SAN，以支援 Zoom Node 與已安裝 Zoom 模組之間的安全 TLS 通訊。

**IP 位址需求**

| 指標          | 值／說明                      |
| ----------- | ------------------------- |
| 所需 IP 位址總數  | 4                         |
| IP 共用策略     | Node 作業系統與第一個模組（ZCP）共用 IP |
| 下列項目需要獨立 IP | ZCP/MMR1、MMR2、MMR3        |

{% hint style="info" %}
當 IP 位址 **共用** 於 Node 作業系統與第一個部署的模組（ZCP）之間時，僅需 **四個（4）IP 位址** 即可。此設計可最佳化 IP 使用，同時仍符合部署標準。
{% endhint %}

<figure><img src="/files/3be73769afdbe16b3de9c77374de49141c78ef0c" alt=""><figcaption></figcaption></figure>

上圖顯示了一個最小化的 ZPLS 部署，其中 **Node 作業系統與已安裝的 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` |
| SAN      | （不需要）               |

在此設定中，由於 OS 與 ZPLS 模組共用相同的主機名稱與 IP 位址，因此單主機憑證已足夠。

**IP 位址需求**

| 指標         | 值／說明                        |
| ---------- | --------------------------- |
| 所需 IP 位址總數 | 1                           |
| IP 共用策略    | Node 作業系統與 ZPLS 共用單一 IP 位址  |
| 部署限制       | 每個 Node VM 只允許一個模組（僅限 ZPLS） |

{% hint style="warning" %}
ZPLS 是 Zoom Node 架構中唯一支援以下情境的情況：

* 單主機憑證（僅 CN）可接受
* 由於 OS 與模組共用 IP，因此部署只需要一（1）個 IP 位址
* 不支援在同一個 VM 上與其他模組共置
  {% endhint %}

### <mark style="color:藍色;">請決定哪種憑證管理方式最適合您的部署</mark>

在 Zoom Node 上部署的每個服務模組都需要一張有效憑證，且必須由 Zoom Node 憑證信任清單中的公眾信任憑證授權單位（CA）簽署。這包括知名的公有授權單位。

Zoom Node 提供兩種憑證管理方式：

* **自動 PKI**：此創新解決方案可與公眾信任的憑證授權單位（CA）自動化進行安全憑證註冊與更新。Zoom 會負擔註冊與更新相關費用。
* **自備憑證（BYOC）**：使用此選項時，您提供自己的憑證，並由任何主要的公眾信任 CA 簽署。您需自行處理憑證註冊與更新。當使用客戶提供的憑證時，Zoom Node 最多可使用五個主機名稱/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_identifier>.<customer_identifier>.zoomonprem.com`。這些網域會設定 A/AAAA 記錄。
4. **保留 DNS 名稱請求**：請求格式如下的保留 DNS 名稱 `rsvd-<randomized_string>.<customer_identifier>.zoomonprem.com`.
5. **憑證請求產生**：使用第三步驟中的 DNS 名稱作為 SAN 欄位，並使用第四步驟中的保留名稱作為 Common Name（CN）欄位，產生 x509 憑證請求。
6. **憑證簽發**：將憑證簽署要求（CSR）傳送至 Zoom 雲端的 Auto PKI 服務。接著此服務會與 CA 供應商合作簽發憑證，其中包含前一步驟中的 SAN 清單與 CN 欄位。
7. **本機儲存**：將上一步驟中新簽發的 x509 憑證及其對應的私密金鑰（先前產生）寫入本機儲存，使 Node 執行個體上的服務可使用。

Auto PKI 會自動監控到期日並請求新憑證，讓 Zoom Node 上的憑證管理更簡化，免去手動更新的需要。

#### 自備憑證（BYOC）

您可以使用本機網頁介面，在 Zoom Node 上安裝您自己的有效、經公有機構簽署的憑證。您可以在初始安裝期間或稍後執行。對於已習慣在網頁型應用程式上安裝憑證的人來說，這個流程會很熟悉。

如果您選擇使用自己的憑證，請記住該憑證會位於一台與多個主機名稱通訊的伺服器上。因此，您所選擇的憑證類型必須支援來自多個主機名稱（憑證 CN）的流量加密。Node 與任何已部署服務所使用的所有主機名稱，都必須可由 Zoom 的雲端服務公開解析。

Zoom 建議使用兩種憑證：

* **萬用字元憑證**
* **多 SAN 憑證** （亦稱為多網域憑證、SAN 憑證或 UCC 憑證）

{% hint style="danger" %}
一般的單主機憑證無法與 Zoom Node 搭配使用，唯有在 Zoom Node 與單一模組共用單一 IP 位址與主機名稱的特定情境下例外。若要了解更多背景資訊，請參閱下方中的 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 %}

由於多 SAN 憑證可加密五（5）個主機名稱的流量，因此對 Zoom Node 而言是必要的。申請此憑證的一次性請求需要事先知道所有必要資訊，包括計畫中的 Node 名稱以及預計部署到 Node 上的所有服務名稱。例如，若是像 ZPLS 這類模組，每個 Node 只會部署一個 ZPLS 模組，因此 ZPLS 服務主機名稱只需要額外一個 SAN。

下表可作為範例：

| 主機名稱（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-webinar.company.com`   | `10.1.50.102` |
| （服務 4－此範例未使用）                | （不適用）         |

此範例為典型設定：一個 Node 在相同 IP 上託管 ZPLS，並在不同 IP 上託管另外兩個服務。請將「company.com」替換為您的實際網域，並使用您網路中的 IP 位址。

**DNS 解析需求**

Zoom 要求主機名稱必須可公開解析，才能建立雙向信任。所有 Zoom Node 主機名稱以及部署在 Nodes 上的所有服務主機名稱，都必須包含在 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/zh-tw/jin-jie-qi-ye-fu-wu/zoom-node/zoom-node-deployment-field-guide/zoom-node-deployment-considerations.md?ask=<question>&goal=<endgoal>
```

`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.