> 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/zoom-workplace/zoom-phone/zoom-phone-local-survivability-field-guide/before-you-begin/hardware-deployment-considerations.md).

# 硬體部署注意事項

了解如何在支援的虛擬化平台上，將 Zoom Node ZPLS 模組部署到虛擬機器

本頁概述如何在支援的 hypervisor 上使用虛擬機器部署 Zoom Node ZPLS 模組。內容提供詳細的設定選項，並依不同硬體能力量身調整，以確保在各種營運需求下都能達到最佳效能。

### 支援的 Hypervisor

#### <mark style="color:藍色;">客戶必須在執行於受支援 hypervisor 上的虛擬機器中安裝 Zoom Node 軟體</mark>

作為 Zoom Node 工作負載，ZPLS 模組必須安裝在執行 Zoom Node 平台的虛擬機器上，位於一個 [受支援的 hypervisor](https://support.zoom.us/hc/en-us/articles/8427127286157-Deploying-a-Zoom-Node-management-server)。更多關於 Zoom Node 作為產品的資訊可在 [附錄中](#_a2lvsihjp0ek).

#### <mark style="color:藍色;">客戶可依據硬體能力選擇兩種組態選項之一</mark>

ZPLS 模組支援兩種組態，取決於虛擬機器的硬體能力。這些能力如下：

|             | 組態選項 1                                       | 組態選項 2                                        |
| ----------- | -------------------------------------------- | --------------------------------------------- |
| **硬體規格**    | <p>8 CPU</p><p>16 GB RAM</p><p>80 GB HDD</p> | <p>16 CPU</p><p>16 GB RAM</p><p>80 GB HDD</p> |
| **總註冊數**    | 2000                                         | 5000                                          |
| **最大同時通話數** | 240                                          | 480                                           |
| **每秒通話數**   | 2                                            | 4                                             |
| **每秒註冊數**   | 60                                           | 400                                           |

{% hint style="info" %}
如果啟用存活能力的站點內端點數量超過該站點的部署能力，ZPLS 模組將採先到先服務原則處理註冊。建議客戶新增額外模組，或使用 Zoom Phone 政策設定 [**本地生存模式**](#_ah8xua8wdq10) 來優先排序哪些使用者支援存活性故障切換。
{% endhint %}

### 模組擴充與韌性

#### <mark style="color:藍色;">ZPLS 模組支援叢集，以進一步擴充和／或提升韌性</mark>

客戶可將 ZPLS 模組群組在一起，每個站點最多 20 個模組（或每個帳戶共 100 台 Node 裝置），以增加備援或擴充能力。

{% hint style="info" %}
此功能目前處於 Beta 版，且需要開立技術支援單才能啟用。
{% endhint %}

#### <mark style="color:藍色;">擴充可提升站點支援的裝置容量</mark>

增加 ZPLS 模組數量會以線性方式提升每個站點的能力，每增加一個模組皆如此。例如，若一個模組可支援總計 5,000 個註冊，部署五個模組將可將支援量提高至 25,000 個註冊。

#### <mark style="color:藍色;">備援會新增模組以提升韌性，但不會擴充站點的裝置容量</mark>

當 ZPLS 模組用於備援時，備援模組不會計入支援分機總數。相反地，這些模組處於「hot standby」狀態，僅在主要模組失效時才會接手。例如，一個主要模組和一個備援模組合計可支援 5,000 個註冊，因此若主要模組失效，備援模組不會因裝置數超過其支援上限而超量配置。

#### <mark style="color:藍色;">具擴充與備援的 ZPLS 部署範例</mark>

為方便說明，以下範例示範具備額外擴充與備援的部署。

{% hint style="success" %}
**範例**:

某醫院需要支援最多 10,000 個已註冊分機以確保存活能力。為達成此目標，該醫院正在部署四個 ZPLS 模組。

前兩個模組各可支援 5,000 個註冊，總容量可達 10,000 個註冊。然而，考量到韌性的重要性，該醫院也部署了另外兩個模組，作為主要模組的備援。

在此情境下，該醫院現在已部署主要與次要的存活性硬體。若主要模組發生故障，備援模組將接手以維持不中斷的服務，同時仍可支援最多 10,000 台已註冊裝置。
{% endhint %}

### 站點設計注意事項

#### <mark style="color:藍色;">站點會依據地點將 Zoom Phone 使用者分組，以套用共通的電話設定與政策</mark>

A **站點** 是 Zoom Phone 內使用的特定術語，會將具有共同特徵的使用者——例如共用存取碼、地址、SIP 區域、部門或政策——分組成 Zoom 網頁入口網站中的單一可管理群組。對某些客戶而言，單一站點可能代表其企業中的所有使用者，且可跨越園區或地點內的多棟建築；對其他客戶而言，則可能需要多個站點，視您的業務需求而定。若要進一步瞭解站點或站點管理， [請參閱 Zoom 的支援中心](https://support.zoom.com/hc/en/article?id=zm_kb\&sysparm_article=KB0069716).

#### <mark style="color:藍色;">Zoom Phone 支援單站點與多站點設計</mark>

在帳戶中設定 Zoom Phone 站點主要有兩種設計：

1. **單站點**：在單一 Zoom Phone 站點中代表帳戶內的所有使用者，可能跨越多棟建築或多個地點。
2. **多站點**：分別代表按地點、建築、部門或功能劃分的使用者區段，各自擁有自己的站點。

<div data-with-frame="true"><img src="https://content.gitbook.com/content/ctBXUMeBy4rtLMmMkKRG/blobs/oIvxHDcxrmw7DhWRyObf/Unknown%20image" alt=""></div>

{% hint style="info" %}
現有 Zoom 客戶的帳戶管理員可透過 [**公司資訊**](https://zoom.us/pbx/page/telephone/settings#/settings/multi-sites?page_number=1\&page_size=15\&keyword=) 頁面查看目前的站點設計，該頁面可在網頁入口網站的 **電話系統管理** 選單中找到。
{% endhint %}

#### <mark style="color:藍色;">每個 ZPLS 模組一次只能與一個站點關聯</mark>

如前所述，ZPLS 模組是 [第三優先註冊器](#_7itj40mx1dut) 適用於受支援裝置，排在主要與次要 SIP 區域之後。由於裝置在開機過程中會接收其 SRV 清單，而這些清單與其站點設定相關聯，因此 **每個 ZPLS 模組一次只能與一個站點關聯**.

#### <mark style="color:藍色;">每個站點可同時支援最多 20 個 ZPLS 模組</mark>

雖然每個 ZPLS 模組一次只能與一個站點關聯，但一個站點可在一個群組中支援最多 20 個 ZPLS 模組，以擴大每個站點的存活能力。

{% hint style="info" %}
此功能目前處於 Beta 版，且需要開立技術支援單才能啟用。
{% endhint %}

#### <mark style="color:藍色;">若模組連接至共用網路，ZPLS 模組支援跨站點通話</mark>

不同站點的 ZPLS 模組在存活事件期間，只要裝置可在本地網路中被發現，就支援跨站點通話。例如，若某企業園區有三棟建築，每棟建築各有自己的電話站點，則各站點的 ZPLS 模組可在園區區域網路上進行站點對站點通話。

{% hint style="info" %}
此功能目前處於 Beta 版，且需要開立技術支援單才能啟用。
{% endhint %}

#### <mark style="color:藍色;">在部署 ZPLS 之前，帳戶應先瞭解哪種站點組態最適合其需求</mark>

由於每個 ZPLS 模組一次只能與一個站點關聯，因此站點設計是帳戶內部署 ZPLS 服務時最重要的因素之一。基於此，客戶應瞭解哪種站點組態最能滿足其實際業務與存活需求，因為每新增一個啟用存活功能的站點，都至少需要再增加一個 ZPLS 模組。

#### <mark style="color:藍色;">單站點設計較易管理，且可透過單一 ZPLS 模組提供存活能力，但在使用者設定與政策方面的彈性較低</mark>

單站點設計可將帳戶內所有使用者整合至單一、統一的群組，從而簡化 Zoom Phone 設定與政策管理。這個單一使用者群組為企業提供簡單直接的管理方式並降低複雜度，讓管理流程更容易。此外，只要站點的使用者數量不超過 [單一模組的能力](#_rx0i1j9xofnc).

然而，單站點設計的簡單性也伴隨著限制。具體而言，單站點設計因其「一體適用」的特性而彈性較低，可能不適合多個部門、且需求各異的所有部署情境。此外，若 [本地網路失敗](#_gzpf5m70jl3i).

#### <mark style="color:藍色;">多站點設計在使用者設定與政策方面提供更高彈性，但每個啟用存活功能的站點都需要一個 ZPLS 模組，而且管理起來也更複雜</mark>

多站點設計透過將使用者分隔為多個群組並提供更細緻的設定控制，為企業在使用者設定與政策方面提供額外彈性。此設計使組織能夠精細調整通訊組態，以滿足跨越不同站點的特定需求，從而針對各種部門、情境或需求提供更精緻且更具適應性的使用者體驗。此外，多站點部署可支援 [跨站點通訊](#_a42hwaw1pfmx) ，前提是各站點透過共用網路連線。

然而，管理多站點設計需要仔細注意各站點獨特需求的細節，這可能需要更高程度的管理工作。此外，由於每個 ZPLS 模組一次只能指派給一個站點，因此每個啟用存活功能的站點都需要一個 ZPLS 模組與授權，這可能導致部署更耗費資源。

{% hint style="info" %}
在多站點設計中，客戶可靈活選擇哪些站點要設定為存活功能。站點 *而非* 在標準連線恢復之前，ZPLS 模組仍將無法撥打或接聽電話。
{% endhint %}

### 網路故障

#### <mark style="color:藍色;">若站點的本地網路失敗，存活能力可能會受到影響</mark>

雖然 ZPLS 模組的設計宗旨是在服務受影響事件期間提供本地電話存活能力，但若站點的本地網路失敗，存活能力可能會受到影響。以下兩節將說明這些情境。

#### <mark style="color:藍色;">單站點本地網路故障</mark>

在單站點設計中，一棟或多棟建築透過本地或園區區域網路連線，並在 Zoom Phone 中以單一站點表示。此組態假設同一地點內所有使用者與建築之間共用同一網路，且跨建築通訊不依賴任何外部網路（例如網際網路）。

在這種站點設計下，企業可以只用一個 ZPLS 模組，就為單一站點或地點內的所有使用者提供本地存活能力；然而，若本地或園區網路中斷而影響跨建築通訊，這種設計就會受到影響。以下範例說明本地網路故障如何影響單站點部署。

<div data-with-frame="true"><img src="https://content.gitbook.com/content/ctBXUMeBy4rtLMmMkKRG/blobs/Ri12tqNIQd9vtbMpNzqe/Unknown%20image" alt=""></div>

{% hint style="success" %}
**範例：**

某公司正在為一個單一 Zoom Phone 站點部署 ZPLS 模組，該站點由透過園區區域網路連線的 A、B 和 C 棟建築組成。ZPLS 模組位於 A 棟，並且是 **不** 連接到 SBC，以便透過 PSTN 進行對外通話。

若發生外部網際網路服務故障或服務受影響事件，站點內的任何使用者都可以撥打同一 *個* 站點中的其他使用者，只要兩位使用者都能透過園區區域網路連線到 ZPLS 模組。

然而，若園區區域網路中斷，B 棟與 C 棟內的使用者在 A 棟中的 ZPLS 模組無法連線時便無法撥打電話。因此，B 棟與 C 棟的使用者必須等到園區區域網路恢復後才能使用存活性通話。
{% endhint %}

下表示範多棟建築的單站點設計中的 Zoom Phone 存活能力：

| 來自建築的通話      | 在外部網際網路故障期間可聯繫這些位置 | 在園區網路故障期間可聯繫這些位置 |
| ------------ | ------------------ | ---------------- |
| A 棟（ZPLS 主機） | ☑️ A、B 和 C 棟       | ☑️ A 棟 *僅*       |
| B 棟          | ☑️ A、B 和 C 棟       | ✖️               |
| C 棟          | ☑️ A、B 和 C 棟       | ✖️               |

#### <mark style="color:藍色;">沒有 SBC 的多站點本地網路故障</mark>

在多站點設計中，每棟建築或地點（例如樓層、衛星辦公室等）都在 Zoom Phone 中獨立以唯一站點表示。此組態假設每個站點都有一個 ZPLS 模組，且各站點透過共用的園區區域網路連線。

在這種站點設計下，每個站點都支援自己的 ZPLS 模組，讓同一棟建築內的使用者在存活模式啟用時可彼此通話。此外，當多個具有 ZPLS 模組的站點透過共用網路連線時，只要本地網路仍在運作，使用者就可以撥打 \_其他\_ 站點的使用者。不過，若園區區域網路中斷而影響跨建築通訊，這種設計就會受到影響。以下範例說明園區網路故障如何影響多站點部署。

<div data-with-frame="true"><img src="https://content.gitbook.com/content/ctBXUMeBy4rtLMmMkKRG/blobs/YleKIF0uXoN12c2dmNNB/Unknown%20image" alt=""></div>

{% hint style="success" %}
**範例：**

某公司正在其多棟建築的園區內部署 ZPLS 模組，該園區由 A、B 和 C 棟組成。每棟建築在 Zoom Phone 中都是唯一站點，並維護一個站點專屬的 ZPLS 模組。園區內所有建築都透過園區區域網路連線，且跨建築通訊不依賴外部網際網路服務。

在此範例中，若發生外部網際網路服務故障、園區網路中斷或服務受影響事件，位於某站點內的任何使用者都可以撥打同一站點內的其他使用者。然而，由於每棟建築都是唯一站點，且使用者會向其站點專屬模組註冊，若園區網路失效，ZPLS 模組便無法傳遞跨站點通話。相反地，使用者將只能撥打本地站點內的其他使用者。
{% endhint %}

下表示範上述範例在具互連園區網路的多站點設計中的 Zoom Phone 存活能力：

| 來自建築的通話      | 在外部網際網路故障期間可聯繫這些位置 | 在園區網路故障期間可聯繫這些位置 |
| ------------ | ------------------ | ---------------- |
| A 棟（ZPLS 主機） | ☑️ A、B 和 C 棟       | ☑️ A 棟           |
| B 棟（ZPLS 主機） | ☑️ A、B 和 C 棟       | ☑️ B 棟           |
| C 棟（ZPLS 主機） | ☑️ A、B 和 C 棟       | ☑️ C 棟           |

#### <mark style="color:藍色;">若本地網路失敗，只要每個站點都連接到 SBC 並啟用呼叫轉接，也可透過 PSTN 支援跨站點通話</mark>

在本地網路失敗時，將 ZPLS 模組與 SBC 以及每個站點的 PSTN 連線整合的多站點設計客戶，可在 [啟用呼叫轉接時](#_2v7qst7vxwaa)啟用。設定後，存活模式期間撥打的電話會從使用者的客戶端路由至 PSTN，再到第二個站點的 SBC 和 ZPLS 模組，最後到達受話者的裝置。以下圖示概述此組態：

<div data-with-frame="true"><img src="https://content.gitbook.com/content/ctBXUMeBy4rtLMmMkKRG/blobs/TxOX1dZyselC2SFLiXSu/Unknown%20image" alt=""></div>

{% hint style="danger" %}
此組態 **需要** 配置於 SBC 上的 E.164 電話號碼處理。
{% endhint %}

下表也示範在具有獨立 SBC 的多站點設計中，Zoom Phone 的存活能力：

| 來自建築的通話      | 在外部網際網路故障期間可聯繫這些位置 | 在園區網路故障期間可聯繫這些位置 |
| ------------ | ------------------ | ---------------- |
| A 棟（ZPLS 主機） | ☑️ A、B 和 C 棟       | ☑️ A、B 和 C 棟     |
| B 棟（ZPLS 主機） | ☑️ A、B 和 C 棟       | ☑️ A、B 和 C 棟     |
| C 棟（ZPLS 主機） | ☑️ A、B 和 C 棟       | ☑️ A、B 和 C 棟     |

#### <mark style="color:藍色;">流動使用者始終會向與其主站點相關聯的 ZPLS 模組註冊</mark>

當使用者或裝置新增至 Zoom Phone 時，在帳戶管理員另行更新之前，「主」站點會靜態關聯至該使用者或裝置。這表示若使用者移至其所關聯主站點以外的實體位置，例如隸屬於不同站點的辦公大樓，Zoom 不會動態調整與該使用者綁定的站點。因此，如果使用者與 Zoom Phone 資料中心失去連線，使用者將嘗試向與其主站點相關聯的 ZPLS 模組註冊，即使他們身處不同位置也是如此。

{% hint style="success" %}
**範例：**

某位位於多站點園區中的使用者以 A 棟（站點 A）為據點，並暫時前往 B 棟（站點 B）開會。當他位於 B 棟時，發生了一個服務受影響事件，並啟用存活模式。雖然該使用者位於 B 棟，但由於站點 A 是其主站點，使用者的客戶端會嘗試連線至配置在 A 棟主站點的 ZPLS 模組。

在此情境中，使用者的存活狀態取決於使用者裝置能否透過園區區域網路向其主站點內的 ZPLS 模組註冊。如果當使用者離開主站點時園區區域網路中斷，該使用者便無法受益於存活模組。
{% endhint %}


---

# 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/zoom-workplace/zoom-phone/zoom-phone-local-survivability-field-guide/before-you-begin/hardware-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.