> 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 位址。如果節點已指派一個用於管理的特定位址，以及每個部署在該節點上的服務各一個位址（最多四個），則 Zoom Node 最多會被指派五（5）個 IP 位址。若 Zoom Node 只執行單一服務（例如 ZPLS），且節點與服務設定為共用相同的 IP 位址，則可使用單一 IP 位址進行部署。

下方顯示多種部署選項。請注意各種部署選項所需的 IP 數量與憑證（CN/SANs）。

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

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

上圖摘要說明部署時的 IP 與憑證設定需求 **Zoom Meetings Hybrid** 於內部部署或混合雲環境中。

下表拆解了範例節點，並包含其作用中的 Proxy 與 MMR 服務模組：

| 元件                   | 主機名稱                 | TLS 憑證角色    | 功能        |
| -------------------- | -------------------- | ----------- | --------- |
| 節點 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） | 媒體路由與處理   |

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

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

上圖說明部署 **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 與 SANs 的憑證（公有或私有 CA）。這可讓模組內部之間的安全通訊獲得正確的 TLS 驗證。

**IP 位址需求**

| 指標           | 值 / 說明                         |
| ------------ | ------------------------------ |
| 所需 IP 位址總數   | 5（一般配置）                        |
| 在 ZPLS 情境中使用 | 2 個 IP（1 個給節點 OS，1 個給 ZPLS 模組） |

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

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

這些圖示如何比較？第一張圖顯示 Zoom Meetings Hybrid 部署的範例。第二張圖顯示 Zoom Phone Local Survivability 部署的範例。

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

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

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

此設定重複了在選項 1 Zoom Meetings Hybrid 圖示中所見的節點結構。然而，在此部署中， **節點 OS 與第一個已部署模組** （通常是 Zoom Connector Proxy，ZCP）共用其 IP 位址。這可在維持 TLS 與功能需求的同時，減少 IP 使用量。

下列主機名稱必須在 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` |

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

**IP 位址需求**

| 指標          | 值 / 說明                 |
| ----------- | ---------------------- |
| 所需 IP 位址總數  | 4                      |
| IP 共用策略     | 節點 OS 與第一個模組共用 IP（ZCP） |
| 需要個別 IP 的項目 | ZCP/MMR1、MMR2、MMR3     |

{% hint style="info" %}
當 IP 位址 **共用** 於節點 OS 與第一個已部署模組（ZCP）之間時，只需要 **四（4）個 IP 位址** 。此設計可在符合部署標準的同時，最佳化 IP 使用。
{% endhint %}

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

上圖顯示一個最小化的 ZPLS 部署，其中 **節點 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 共用策略    | 節點 OS 與 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 提供兩種憑證管理方法：

* **Auto PKI**: 這項創新解決方案會自動以公開信任的憑證授權單位（CA）完成安全憑證註冊與更新。Zoom 會承擔註冊與更新的相關費用。
* **自備憑證（BYOC）**: 使用此選項時，您可提供自己的憑證，並由任何主要公開信任的 CA 簽署。您需自行處理憑證註冊與更新。若使用客戶提供的憑證，對於 Zoom Node 最多可支援五個主機名稱/SANs 也有額外考量，詳情如下。

#### 使用 Auto PKI 自動管理憑證

Zoom Auto PKI 會自動為 Zoom Node 平台以及其上部署的任何模組安裝有效的公開信任 CA 憑證。憑證更新也會自動處理。這簡化了所有服務以及 Zoom Node 本身的憑證管理。

#### 了解 Auto PKI 憑證註冊與更新

以下情境可幫助您了解憑證註冊與更新的運作方式。

例如：管理員已部署一個新的節點執行個體。每個執行個體都需要一張有效的 x509 憑證。 **憑證的私密金鑰絕不能離開此執行個體**.

Auto PKI 流程會執行以下步驟：

1. **範本擷取**: 從 Zoom 雲端中的 Auto PKI 服務擷取所有支援的設定範本，包括多個 CA 提供者的選項。
2. **IP 位址收集**: 收集節點上執行之服務使用的所有 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 欄位，並使用第四步驟中的保留名稱作為一般名稱（CN）欄位，產生 x509 憑證請求。
6. **憑證簽發**: 將憑證簽署要求（CSR）傳送至 Zoom 雲端中的 Auto PKI 服務。接著此服務會與 CA 供應商合作簽發憑證，其中包含前一步驟中的 SAN 清單與 CN 欄位。
7. **本機儲存**: 將上一個步驟中新簽發的 x509 憑證及其對應的私密金鑰（先前產生）寫入本機儲存，使節點執行個體上的服務可使用。

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

#### 自備憑證（BYOC）

您可以使用本機 Web 介面，在 Zoom Node 上安裝自己有效且由公開單位簽署的憑證。您可以在初次安裝期間或稍後進行。對於習慣在網頁型應用程式中安裝憑證的人來說，這個流程會很熟悉。

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

Zoom 建議使用兩種憑證：

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

{% hint style="danger" %}
一般的單一主機憑證無法與 Zoom Node 搭配使用，除非是 Zoom Node 與單一模組共用單一 IP 位址與主機名稱的特定情境。若需更多背景資訊，請參閱 [#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）。

這可將在節點上部署服務所需的工作量降到最低：在部署前您不需要先知道服務名稱。不過，若使用多 SAN 憑證方法，您就需要知道服務名稱。

**多 SAN、多網域、SAN 或 UCC 憑證**

{% hint style="warning" %}
您必須知道將用於節點的主機名稱與 IP 位址（最多一 \[1] 個），以及您將安裝的任何服務（最多四 \[4] 個）。

**在申請憑證前必須先備妥這些資訊**.
{% endhint %}

Zoom Node 需要多 SAN 憑證，因為它可加密來自五（5）個主機名稱的流量。此憑證的一次性請求需要事先知道所有必要資訊，包括預計的節點名稱以及所有預計部署於節點上的服務名稱。例如，若使用像 ZPLS 這類模組，每個節點只部署一個 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 - 本範例未使用）              | （不適用）         |

此範例為典型設定，其中一個節點在相同 IP 上承載 ZPLS，另外兩個服務則使用各自獨立的 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/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.