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

# Các cân nhắc về triển khai phần cứng

Trang này trình bày việc triển khai mô-đun ZPLS của Zoom Node trên máy ảo bằng các trình giám sát máy ảo được hỗ trợ. Trang cung cấp các tùy chọn cấu hình chi tiết phù hợp với nhiều khả năng phần cứng khác nhau, bảo đảm hiệu suất tối ưu cho các nhu cầu vận hành đa dạng.

### Các trình giám sát máy ảo được hỗ trợ

#### <mark style="color:xanh dương;">Khách hàng phải cài đặt phần mềm Zoom Node trên máy ảo chạy trên trình giám sát máy ảo được hỗ trợ</mark>

Là một khối lượng công việc của Zoom Node, mô-đun ZPLS phải được cài đặt trên máy ảo chạy nền tảng Zoom Node, trên một [trình giám sát máy ảo được hỗ trợ](https://support.zoom.us/hc/en-us/articles/8427127286157-Deploying-a-Zoom-Node-management-server). Bạn có thể tìm thêm thông tin về Zoom Node dưới dạng sản phẩm [trong Phụ lục](#_a2lvsihjp0ek).

#### <mark style="color:xanh dương;">Khách hàng có thể Chọn một trong hai tùy chọn cấu hình, tùy thuộc vào khả năng phần cứng</mark>

Mô-đun ZPLS hỗ trợ hai cấu hình, tùy thuộc vào khả năng phần cứng của máy ảo. Các khả năng này được liệt kê bên dưới:

|                                   | Tùy chọn cấu hình 1                          | Tùy chọn cấu hình 2                           |
| --------------------------------- | -------------------------------------------- | --------------------------------------------- |
| **Thông số phần cứng**            | <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> |
| **Tổng số lượt đăng ký**          | 2000                                         | 5000                                          |
| **Số cuộc gọi đồng thời tối đa** | 240                                          | 480                                           |
| **Số cuộc gọi mỗi giây**         | 2                                            | 4                                             |
| **Số lượt đăng ký mỗi giây**      | 60                                           | 400                                           |

{% hint style="info" %}
Nếu số lượng điểm cuối trong một cơ sở đã Bật khả năng duy trì hoạt động vượt quá khả năng triển khai của cơ sở đó, mô-đun ZPLS sẽ xử lý lượt đăng ký theo nguyên tắc đến trước được phục vụ trước. Khách hàng nên Thêm mô-đun bổ sung hoặc sử dụng Cài đặt Chính sách Zoom Phone [**Chế độ duy trì hoạt động cục bộ**](#_ah8xua8wdq10) để ưu tiên những người dùng hỗ trợ chuyển đổi dự phòng duy trì hoạt động.
{% endhint %}

### Mở rộng quy mô và khả năng phục hồi của mô-đun

#### <mark style="color:xanh dương;">Các mô-đun ZPLS hỗ trợ phân cụm để mở rộng quy mô và/hoặc tăng khả năng phục hồi</mark>

Khách hàng có thể nhóm các mô-đun ZPLS lại với nhau, tối đa 20 mô-đun cho mỗi cơ sở (hoặc tổng cộng 100 Thiết bị Node cho mỗi tài khoản) để tăng cường dự phòng hoặc mở rộng quy mô.

{% hint style="info" %}
Tính năng này hiện đang ở bản beta và cần có phiếu yêu cầu hỗ trợ kỹ thuật để được Bật.
{% endhint %}

#### <mark style="color:xanh dương;">Việc mở rộng quy mô làm tăng khả năng Thiết bị được hỗ trợ của một cơ sở</mark>

Việc mở rộng số lượng mô-đun ZPLS sẽ nâng cao khả năng của từng cơ sở theo tuyến tính với mỗi mô-đun bổ sung. Ví dụ: nếu một mô-đun hỗ trợ tổng cộng 5.000 lượt đăng ký, việc triển khai năm mô-đun sẽ nâng mức hỗ trợ lên 25.000 lượt đăng ký.

#### <mark style="color:xanh dương;">Tính dự phòng bổ sung các mô-đun để tăng khả năng phục hồi, nhưng không mở rộng khả năng Thiết bị của một cơ sở</mark>

Khi một mô-đun ZPLS được sử dụng cho mục đích dự phòng, các mô-đun dự phòng sẽ không đóng góp vào tổng số máy lẻ được hỗ trợ. Thay vào đó, các mô-đun ở trạng thái “chờ nóng” và chỉ hoạt động nếu các mô-đun chính gặp sự cố. Ví dụ: một mô-đun chính và một mô-đun dự phòng hỗ trợ tổng cộng 5.000 lượt đăng ký, do đó nếu một mô-đun chính gặp sự cố, mô-đun dự phòng sẽ không bị quá tải số lượng Thiết bị vượt quá giới hạn được hỗ trợ.

#### <mark style="color:xanh dương;">Ví dụ về triển khai ZPLS với mở rộng quy mô và dự phòng</mark>

Để thuận tiện, ví dụ sau minh họa việc triển khai với khả năng mở rộng quy mô và dự phòng bổ sung.

{% hint style="success" %}
**Ví dụ**:

Một bệnh viện cần hỗ trợ tối đa 10.000 máy lẻ đã đăng ký để duy trì hoạt động. Để đạt được điều này, bệnh viện đang triển khai bốn mô-đun ZPLS.

Hai mô-đun đầu tiên có khả năng hỗ trợ 5.000 lượt đăng ký mỗi mô-đun, cho tổng dung lượng lên đến 10.000 lượt đăng ký. Tuy nhiên, nhận thức được tầm quan trọng của khả năng phục hồi, bệnh viện cũng đang triển khai thêm hai mô-đun làm bản sao lưu dự phòng cho các mô-đun chính.

Trong trường hợp này, bệnh viện hiện đã triển khai phần cứng duy trì hoạt động chính và phụ. Khi một mô-đun chính gặp sự cố, (các) mô-đun dự phòng sẽ Tiếp nhận để duy trì dịch vụ không bị gián đoạn, đồng thời tiếp tục hỗ trợ tối đa 10.000 Thiết bị đã đăng ký.
{% endhint %}

### Các cân nhắc về thiết kế cơ sở

#### <mark style="color:xanh dương;">Các cơ sở nhóm người dùng Zoom Phone theo Vị trí để dùng chung Cài đặt và chính sách điện thoại</mark>

Một **cơ sở** là một thuật ngữ cụ thể được dùng trong Zoom Phone để nhóm những người dùng có đặc điểm chung — như mã Truy cập chung, địa chỉ, Vùng SIP, phòng ban hoặc chính sách — vào một nhóm duy nhất, có thể quản lý trong Cổng thông tin web của Zoom. Đối với một số Khách hàng, một cơ sở duy nhất có thể đại diện cho tất cả người dùng trong doanh nghiệp của họ và có thể trải rộng trên nhiều tòa nhà trong một khuôn viên hoặc Vị trí; đối với những người khác, có thể cần Nhiều địa điểm tùy theo nhu cầu Kinh doanh của bạn. Để biết thêm thông tin về các cơ sở hoặc quản lý cơ sở, [tham khảo trung tâm hỗ trợ của Zoom](https://support.zoom.com/hc/en/article?id=zm_kb\&sysparm_article=KB0069716).

#### <mark style="color:xanh dương;">Zoom Phone hỗ trợ thiết kế một cơ sở và nhiều cơ sở</mark>

Có hai thiết kế chính để cấu hình các cơ sở Zoom Phone trong một tài khoản:

1. **Một cơ sở**: Đại diện cho tất cả người dùng trong một tài khoản, có thể trải rộng trên nhiều tòa nhà hoặc vị trí, trong một cơ sở Zoom Phone duy nhất.
2. **Nhiều cơ sở**: Đại diện riêng các phân khúc người dùng theo vị trí, tòa nhà, phòng ban hoặc chức năng, mỗi phân khúc có cơ sở riêng.

<div data-with-frame="true"><img src="/files/a9696deebaa971a9fb1595ad9c8b2418eb86ade5" alt=""></div>

{% hint style="info" %}
quản trị viên tài khoản của các Khách hàng Zoom hiện tại có thể kiểm tra thiết kế cơ sở hiện tại của họ thông qua [**Thông tin công ty**](https://zoom.us/pbx/page/telephone/settings#/settings/multi-sites?page_number=1\&page_size=15\&keyword=) trang, có sẵn trong **Quản lý hệ thống điện thoại** menu trên cổng thông tin web.
{% endhint %}

#### <mark style="color:xanh dương;">Mỗi mô-đun ZPLS chỉ có thể được liên kết với một cơ sở tại một thời điểm</mark>

Như đã đề cập trước đó, một mô-đun ZPLS là [bộ đăng ký ưu tiên thứ ba](#_7itj40mx1dut) cho các Thiết bị được hỗ trợ, sau các vùng SIP chính và phụ. Vì các Thiết bị nhận danh sách SRV trong quá trình khởi động và các danh sách này gắn với Cài đặt của cơ sở, **mỗi mô-đun ZPLS chỉ có thể được liên kết với một cơ sở tại một thời điểm**.

#### <mark style="color:xanh dương;">Mỗi cơ sở có thể hỗ trợ đồng thời tối đa 20 mô-đun ZPLS</mark>

Mặc dù mỗi mô-đun ZPLS chỉ có thể được liên kết với một cơ sở tại một thời điểm, một cơ sở có thể hỗ trợ tối đa 20 mô-đun ZPLS trong một nhóm, mở rộng khả năng duy trì hoạt động của từng cơ sở.

{% hint style="info" %}
Tính năng này hiện đang ở bản beta và cần có phiếu yêu cầu hỗ trợ kỹ thuật để được Bật.
{% endhint %}

#### <mark style="color:xanh dương;">Các mô-đun ZPLS hỗ trợ cuộc gọi giữa các cơ sở nếu các mô-đun được kết nối với một mạng chung</mark>

Các mô-đun ZPLS từ các cơ sở khác nhau hỗ trợ cuộc gọi giữa các cơ sở trong một Sự kiện duy trì hoạt động, miễn là các Thiết bị có thể được phát hiện trong mạng cục bộ. Ví dụ: nếu một khuôn viên Kinh doanh có ba tòa nhà, mỗi tòa nhà có cơ sở điện thoại riêng, các mô-đun ZPLS từ mỗi cơ sở có thể kết nối các cuộc gọi từ cơ sở này đến cơ sở khác trên mạng khuôn viên.

{% hint style="info" %}
Tính năng này hiện đang ở bản beta và cần có phiếu yêu cầu hỗ trợ kỹ thuật để được Bật.
{% endhint %}

#### <mark style="color:xanh dương;">Trước khi triển khai ZPLS, các tài khoản nên hiểu cấu hình cơ sở nào phù hợp nhất với nhu cầu của họ</mark>

Vì mỗi mô-đun ZPLS chỉ có thể được liên kết với một cơ sở tại một thời điểm, thiết kế cơ sở là một trong những yếu tố quan trọng nhất khi triển khai dịch vụ ZPLS trong một tài khoản. Vì lý do này, Khách hàng nên hiểu cấu hình cơ sở nào là tốt nhất để đáp ứng các nhu cầu Kinh doanh và duy trì hoạt động thực tế của họ, vì mỗi cơ sở bổ sung được Bật để duy trì hoạt động sẽ cần ít nhất một mô-đun ZPLS bổ sung.

#### <mark style="color:xanh dương;">Thiết kế một cơ sở dễ quản lý hơn và cung cấp khả năng duy trì hoạt động với một mô-đun ZPLS duy nhất, nhưng ít linh hoạt hơn đối với Cài đặt và chính sách của người dùng</mark>

Thiết kế một cơ sở giúp tinh gọn việc quản lý Cài đặt và chính sách Zoom Phone bằng cách hợp nhất tất cả người dùng trong một tài khoản dưới một nhóm thống nhất duy nhất. Nhóm người dùng duy nhất này mang lại cho doanh nghiệp khả năng quản trị đơn giản và giảm độ phức tạp, giúp đơn giản hóa quy trình quản lý. Ngoài ra, thiết kế một cơ sở có thể cung cấp khả năng duy trì hoạt động điện thoại cục bộ chỉ với một mô-đun ZPLS, miễn là số người dùng của cơ sở không vượt quá [khả năng của một mô-đun duy nhất](#_rx0i1j9xofnc).

Tuy nhiên, sự đơn giản của thiết kế một cơ sở tự nhiên đi kèm các hạn chế. Cụ thể, thiết kế một cơ sở ít linh hoạt hơn do tính chất “một giải pháp cho tất cả”, có thể không phù hợp với mọi tình huống triển khai ở nhiều phòng ban có nhu cầu khác nhau. Hơn nữa, việc triển khai một cơ sở có thể dễ bị ảnh hưởng trong một số tình huống duy trì hoạt động nếu [mạng cục bộ gặp sự cố](#_gzpf5m70jl3i).

#### <mark style="color:xanh dương;">Thiết kế nhiều cơ sở mang lại nhiều tính linh hoạt hơn cho Cài đặt và chính sách của người dùng, nhưng yêu cầu một mô-đun ZPLS cho mỗi cơ sở được Bật duy trì hoạt động và phức tạp hơn để quản lý</mark>

Thiết kế nhiều cơ sở mang lại cho doanh nghiệp tính linh hoạt bổ sung về Cài đặt và chính sách của người dùng bằng cách phân chia người dùng thành các nhóm khác nhau với các kiểm soát Cài đặt chi tiết. Thiết kế này cho phép tổ chức tinh chỉnh cấu hình liên lạc để đáp ứng các yêu cầu cụ thể trên nhiều cơ sở khác nhau, đem lại trải nghiệm người dùng tinh tế và thích ứng hơn cho các phòng ban, tình huống hoặc nhu cầu khác nhau. Ngoài ra, triển khai nhiều cơ sở có thể hỗ trợ [liên lạc giữa các cơ sở](#_a42hwaw1pfmx) nếu các cơ sở được kết nối thông qua một mạng chung.

Tuy nhiên, việc quản lý thiết kế nhiều cơ sở đòi hỏi chú ý cẩn thận đến những điểm phức tạp trong yêu cầu riêng của từng cơ sở, điều này có thể đòi hỏi nỗ lực quản trị ở mức cao hơn. Hơn nữa, vì mỗi mô-đun ZPLS chỉ có thể được gán cho một cơ sở tại một thời điểm, mỗi cơ sở được Bật duy trì hoạt động sẽ cần một mô-đun ZPLS và giấy phép, điều này có thể góp phần tạo nên một thiết lập tiêu tốn nhiều tài nguyên hơn.

{% hint style="info" %}
Trong thiết kế nhiều cơ sở, Khách hàng có thể linh hoạt Chọn những cơ sở sẽ được cấu hình để duy trì hoạt động. Các cơ sở *mà không* một mô-đun ZPLS sẽ vẫn không thể thực hiện hoặc nhận cuộc gọi cho đến khi kết nối Tiêu chuẩn được khôi phục.
{% endhint %}

### Sự cố mạng

#### <mark style="color:xanh dương;">Khả năng duy trì hoạt động có thể bị ảnh hưởng nếu mạng cục bộ của một cơ sở gặp sự cố</mark>

Mặc dù các mô-đun ZPLS được thiết kế để cung cấp khả năng duy trì hoạt động điện thoại cục bộ trong các Sự kiện ảnh hưởng đến dịch vụ, khả năng duy trì hoạt động có thể bị ảnh hưởng nếu mạng cục bộ của một cơ sở gặp sự cố. Các tình huống này được trình bày trong hai phần sau.

#### <mark style="color:xanh dương;">Sự cố mạng cục bộ của một cơ sở</mark>

Trong thiết kế một cơ sở, một hoặc nhiều tòa nhà được kết nối qua mạng cục bộ hoặc mạng khuôn viên và được biểu thị bằng một cơ sở duy nhất trong Zoom Phone. Cấu hình này giả định có một mạng chung giữa tất cả người dùng và tòa nhà trong một Vị trí, không phụ thuộc vào mạng bên ngoài nào (ví dụ: Internet) để liên lạc giữa các tòa nhà.

Với thiết kế cơ sở này, doanh nghiệp có thể cung cấp khả năng duy trì hoạt động cục bộ cho tất cả người dùng trong một cơ sở hoặc Vị trí chỉ với một mô-đun ZPLS; tuy nhiên, thiết kế này dễ bị ảnh hưởng trong trường hợp mất mạng cục bộ hoặc mạng khuôn viên làm ảnh hưởng đến liên lạc giữa các tòa nhà. Ví dụ sau mô tả cách sự cố mạng cục bộ có thể ảnh hưởng đến việc triển khai một cơ sở.

<div data-with-frame="true"><img src="/files/d91175e8ebd4b72f140c89c36ebb0912edda5ca2" alt=""></div>

{% hint style="success" %}
**Ví dụ:**

Một công ty đang triển khai mô-đun ZPLS cho một cơ sở Zoom Phone duy nhất, gồm các tòa nhà A, B và C, được kết nối qua mạng khuôn viên. Mô-đun ZPLS đang hoạt động tại Tòa nhà A và được **không** kết nối với một SBC để thực hiện cuộc gọi bên ngoài qua Mạng điện thoại chuyển tiếp công cộng.

Trong trường hợp sự cố dịch vụ Internet bên ngoài hoặc Sự kiện ảnh hưởng đến dịch vụ, bất kỳ người dùng nào thuộc cơ sở đều có thể gọi cho người dùng khác trong *cùng* cơ sở, miễn là cả hai người dùng vẫn duy trì kết nối với mô-đun ZPLS qua mạng khuôn viên.

Tuy nhiên, trong trường hợp mạng khuôn viên gặp sự cố, người dùng trong các tòa nhà B và C không thể thực hiện cuộc gọi khi không thể truy cập mô-đun ZPLS trong Tòa nhà A. Do đó, người dùng trong các tòa nhà B và C phải chờ cho đến khi mạng khuôn viên được khôi phục để thực hiện cuộc gọi duy trì hoạt động.
{% endhint %}

Bảng sau minh họa khả năng duy trì hoạt động của Zoom Phone trong thiết kế một cơ sở gồm nhiều tòa nhà:

| Cuộc gọi xuất phát từ tòa nhà | Có thể liên lạc với các vị trí này khi xảy ra sự cố Internet bên ngoài | Có thể liên lạc với các vị trí này khi xảy ra sự cố mạng khuôn viên |
| ------------------------------ | ---------------------------------------------------------------------- | ------------------------------------------------------------------- |
| Tòa nhà A (Máy chủ ZPLS)       | ☑️Tòa nhà A, B và C                                                    | ☑️ Tòa nhà A *chỉ*                                                  |
| Tòa nhà B                      | ☑️Tòa nhà A, B và C                                                    | ✖️                                                                  |
| Tòa nhà C                      | ☑️Tòa nhà A, B và C                                                    | ✖️                                                                  |

#### <mark style="color:xanh dương;">Sự cố mạng cục bộ nhiều cơ sở không có SBC</mark>

Trong thiết kế nhiều cơ sở, mỗi tòa nhà hoặc Vị trí (ví dụ: tầng, văn phòng vệ tinh, v.v.) được biểu thị độc lập bằng một cơ sở duy nhất trong Zoom Phone. Cấu hình này giả định rằng mỗi cơ sở có một mô-đun ZPLS và các cơ sở được kết nối qua một mạng khuôn viên chung.

Với thiết kế cơ sở này, mỗi cơ sở hỗ trợ mô-đun ZPLS riêng, cho phép người dùng trong cùng một tòa nhà gọi cho nhau khi chế độ duy trì hoạt động được kích hoạt. Hơn nữa, khi nhiều cơ sở có mô-đun ZPLS được kết nối qua một mạng chung, người dùng có thể gọi cho người dùng tại \_các cơ sở\_khác, miễn là mạng cục bộ vẫn hoạt động. Tuy nhiên, thiết kế này dễ bị ảnh hưởng trong trường hợp mạng khuôn viên gặp sự cố làm ảnh hưởng đến liên lạc giữa các tòa nhà. Ví dụ sau mô tả cách sự cố mạng khuôn viên có thể ảnh hưởng đến việc triển khai nhiều cơ sở.

<div data-with-frame="true"><img src="/files/9c610858fa98af483039819a2baf40da7e60efe8" alt=""></div>

{% hint style="success" %}
**Ví dụ:**

Một công ty đang triển khai mô-đun ZPLS trong khuôn viên gồm nhiều tòa nhà A, B và C. Mỗi tòa nhà là một cơ sở riêng trong Zoom Phone và duy trì một mô-đun ZPLS dành riêng cho cơ sở. Tất cả các tòa nhà trong khuôn viên được kết nối qua một mạng khuôn viên không phụ thuộc vào dịch vụ Internet bên ngoài để liên lạc giữa các tòa nhà.

Trong ví dụ này, khi xảy ra sự cố dịch vụ Internet bên ngoài, sự cố mạng khuôn viên hoặc Sự kiện ảnh hưởng đến dịch vụ, bất kỳ người dùng nào trong một cơ sở đều có thể gọi cho người dùng khác trong cùng cơ sở. Tuy nhiên, vì mỗi tòa nhà là một cơ sở riêng và người dùng đăng ký với các mô-đun dành riêng cho cơ sở của họ, nếu mạng khuôn viên gặp sự cố, các mô-đun ZPLS không thể truyền cuộc gọi giữa các cơ sở. Thay vào đó, người dùng sẽ chỉ có thể thực hiện cuộc gọi đến những người dùng khác trong cơ sở cục bộ của họ.
{% endhint %}

Bảng sau minh họa khả năng duy trì hoạt động của Zoom Phone từ ví dụ trên trong thiết kế nhiều cơ sở có mạng khuôn viên được kết nối liên thông:

| Cuộc gọi xuất phát từ tòa nhà | Có thể liên lạc với các vị trí này khi xảy ra sự cố Internet bên ngoài | Có thể liên lạc với các vị trí này khi xảy ra sự cố mạng khuôn viên |
| ------------------------------ | ---------------------------------------------------------------------- | ------------------------------------------------------------------- |
| Tòa nhà A (Máy chủ ZPLS)       | ☑️ Tòa nhà A, B và C                                                   | ☑️ Tòa nhà A                                                        |
| Tòa nhà B (Máy chủ ZPLS)       | ☑️ Tòa nhà A, B và C                                                   | ☑️ Tòa nhà B                                                        |
| Tòa nhà C (Máy chủ ZPLS)       | ☑️ Tòa nhà A, B và C                                                   | ☑️ Tòa nhà C                                                        |

#### <mark style="color:xanh dương;">Nếu mạng cục bộ gặp sự cố, cuộc gọi giữa các cơ sở cũng được hỗ trợ qua Mạng điện thoại chuyển tiếp công cộng, với điều kiện mỗi cơ sở được kết nối với một SBC và đã Bật chuyển tiếp cuộc gọi</mark>

Trong trường hợp mạng cục bộ gặp sự cố, Khách hàng có thiết kế nhiều cơ sở tích hợp mô-đun ZPLS với SBC và kết nối Mạng điện thoại chuyển tiếp công cộng tại mỗi cơ sở có thể Bật cuộc gọi giữa các cơ sở nếu [đã Bật chuyển tiếp cuộc gọi](#_2v7qst7vxwaa). Khi được cấu hình, các cuộc gọi điện thoại thực hiện trong chế độ duy trì hoạt động sẽ được định tuyến từ ứng dụng khách của người dùng đến Mạng điện thoại chuyển tiếp công cộng, đến SBC và mô-đun ZPLS của cơ sở thứ hai, rồi cuối cùng đến Thiết bị của người nhận cuộc gọi. Sơ đồ sau cung cấp tổng quan về cấu hình này:

<div data-with-frame="true"><img src="/files/42542df0158bf7025fe5789b6a92b1d0a79a6f2f" alt=""></div>

{% hint style="danger" %}
Cấu hình này **yêu cầu** Xử lý số điện thoại E.164 trên các SBC đã cấu hình.
{% endhint %}

Bảng sau cũng minh họa khả năng duy trì hoạt động của Zoom Phone trong thiết kế nhiều cơ sở với các SBC độc lập:

| Cuộc gọi xuất phát từ tòa nhà | Có thể liên lạc với các vị trí này khi xảy ra sự cố Internet bên ngoài | Có thể liên lạc với các vị trí này khi xảy ra sự cố mạng khuôn viên |
| ------------------------------ | ---------------------------------------------------------------------- | ------------------------------------------------------------------- |
| Tòa nhà A (Máy chủ ZPLS)       | ☑️Tòa nhà A, B và C                                                    | ☑️Tòa nhà A, B và C                                                 |
| Tòa nhà B (Máy chủ ZPLS)       | ☑️Tòa nhà A, B và C                                                    | ☑️Tòa nhà A, B và C                                                 |
| Tòa nhà C (Máy chủ ZPLS)       | ☑️Tòa nhà A, B và C                                                    | ☑️Tòa nhà A, B và C                                                 |

#### <mark style="color:xanh dương;">Người dùng lưu động luôn đăng ký với mô-đun ZPLS được liên kết với cơ sở chính của họ</mark>

Khi người dùng hoặc Thiết bị được Thêm vào Zoom Phone, một cơ sở “chính” được liên kết tĩnh với người dùng hoặc Thiết bị đó cho đến khi được quản trị viên tài khoản cập nhật. Điều này có nghĩa là nếu một người dùng di chuyển đến Vị trí thực tế bên ngoài cơ sở chính liên kết của họ, chẳng hạn như tòa nhà văn phòng liên kết với một cơ sở khác, Zoom sẽ không tự động điều chỉnh cơ sở gắn với người dùng. Do đó, nếu người dùng mất kết nối với các trung tâm dữ liệu Zoom Phone, người dùng sẽ cố đăng ký với mô-đun ZPLS liên kết với cơ sở chính của họ, ngay cả khi họ đang ở một Vị trí khác.

{% hint style="success" %}
**Ví dụ:**

Một người dùng trong khuôn viên nhiều cơ sở làm việc tại Tòa nhà A (Cơ sở A) và tạm thời di chuyển đến Tòa nhà B (Cơ sở B) để tham dự một cuộc họp. Khi họ ở Tòa nhà B, một Sự kiện ảnh hưởng đến dịch vụ xảy ra và chế độ duy trì hoạt động được kích hoạt. Mặc dù người dùng ở trong Tòa nhà B, vì Cơ sở A là cơ sở chính của họ, ứng dụng khách của người dùng sẽ cố kết nối với mô-đun ZPLS được cấp phép tại cơ sở chính của họ trong tòa nhà A.

Trong trường hợp này, trạng thái duy trì hoạt động của người dùng được xác định bởi khả năng Thiết bị của người dùng đăng ký với mô-đun ZPLS trong cơ sở chính của họ qua mạng khuôn viên. Nếu mạng khuôn viên không hoạt động khi người dùng ở xa cơ sở chính, người dùng không thể hưởng lợi từ mô-đun duy trì hoạt động.
{% 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/vi/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.