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

# 硬體部署考量

本頁概述了在受支援的 Hypervisor 上，使用虛擬機器部署 Zoom Node ZPLS 模組的方式。內容提供了針對不同硬體能力量身打造的詳細設定選項，確保可因應各種營運需求而達到最佳效能。

### 受支援的 Hypervisors

#### <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 模組用於備援用途時，備援模組不會計入支援分機總數。相反地，這些模組會處於「熱備援」狀態，只有在主要模組失效時才會接手。例如，一個主要模組加上一個備援模組可支援總共 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>

一個 **站點** 是 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="/files/4b5741ed29ebb0d5e2ac2eff317080c6cfbbb9db" 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="/files/4aecadd78381e30e41df34ef572c95036305dcdc" 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="/files/341215721d498b8a5322c658b9b94e7c51c94385" 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="/files/ec58fc03e89a60f1b1a79c61ec1069a6a018ebbb" 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.