> 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/cac-dich-vu-doanh-nghiep-lon-nang-cao/zoom-node/zoom-node-deployment-field-guide/zoom-node-deployment-considerations.md).
# Những lưu ý khi triển khai Zoom Node
Phần này chứa một số ví dụ về cách Zoom Node có thể hỗ trợ nhiều Mô-đun Dịch vụ khác nhau như Zoom Meetings Hybrid và Zoom Phone Local Survivability (ZPLS). Các cách triển khai điển hình với Địa chỉ IP chuyên dụng có thể giống như bộ sơ đồ sau đây.
Mọi dịch vụ được triển khai trên Zoom Node đều yêu cầu một Địa chỉ IP duy nhất. Một Zoom Node sẽ có tối đa năm (5) Địa chỉ IP được Chỉ định cho nó nếu Node đã được Chỉ định một địa chỉ cụ thể để quản lý và một địa chỉ cho mỗi dịch vụ được triển khai (tối đa bốn) trên Node. Một Zoom Node chạy một dịch vụ duy nhất (chẳng hạn như ZPLS) có thể được triển khai với một Địa chỉ IP duy nhất nếu Node và dịch vụ được Chỉ định để dùng chung cùng một Địa chỉ IP.
Một số tùy chọn triển khai được hiển thị bên dưới. Lưu ý số lượng IP và chứng chỉ (CN/SAN) cho các tùy chọn triển khai khác nhau.
### Tùy chọn 1: Zoom Meetings Hybrid được triển khai với các IP và tên máy chủ chuyên dụng
Hình ảnh ở trên tóm tắt các yêu cầu cấu hình IP và chứng chỉ để triển khai **Zoom Meetings Hybrid** trong môi trường tại chỗ hoặc đám mây lai.
Bảng bên dưới phân tích Node ví dụ và bao gồm proxy đang hoạt động cùng các Mô-đun Dịch vụ MMR của nó:
| Thành phần | Tên máy chủ | Vai trò Chứng chỉ TLS | Chức năng |
| ---------------------------------- | -------------------- | ------------------------------ | ------------------------------- |
| Hệ điều hành Node | `node1.customer.com` | Tên chung (CN) | Điều phối lõi |
| Proxy Trình kết nối Zoom | `zcp1.customer.com` | Tên thay thế của chủ thể (SAN) | Báo hiệu và điều khiển phiên |
| Bộ định tuyến Mô-đun Phương tiện 1 | `mmr1.customer.com` | Tên thay thế của chủ thể (SAN) | Định tuyến và xử lý phương tiện |
| Bộ định tuyến Mô-đun Phương tiện 2 | `mmr2.customer.com` | Tên thay thế của chủ thể (SAN) | Định tuyến và xử lý phương tiện |
| Bộ định tuyến Mô-đun Phương tiện 3 | `mmr3.customer.com` | Tên thay thế của chủ thể (SAN) | Định tuyến và xử lý phương tiện |
{% hint style="info" %}
Bạn phải Chỉ định cho mỗi mô-đun một Địa chỉ IP tĩnh chuyên dụng. Tổng số Địa chỉ IP cần có: năm (5)
{% endhint %}
Hình ảnh ở trên nêu rõ cấu hình tối thiểu cần thiết để triển khai **Zoom Phone Local Survivability (ZPLS)**. ZPLS cho phép duy trì tính sẵn sàng của dịch vụ điện thoại trong trường hợp internet hoặc đám mây bị gián đoạn bằng cách chạy logic survivability cục bộ trên một máy ảo Zoom Node.
Các tên máy chủ sau phải được cấu hình trong DNS và được bao gồm trong chứng chỉ TLS:
* `node1.customer.com`
* `zplsl.customer.com`
**Ánh xạ chức năng tên máy chủ**
| Thành phần | Tên máy chủ | Vai trò Chứng chỉ TLS | Chức năng |
| ----------------- | -------------------- | ------------------------ | ------------------------------------ |
| Hệ điều hành Node | `node1.customer.com` | Tên chung (CN) | Điều phối lõi |
| Mô-đun ZPLS | `zplsl.customer.com` | Tên thay thế của chủ thể | Logic Zoom Phone Local Survivability |
**Cấu hình Chứng chỉ TLS**
| Trường | Giá trị |
| ---------------------------- | -------------------- |
| Tên chung (CN) | `node1.customer.com` |
| Các tên thay thế của chủ thể | `zplsl.customer.com` |
Chứng chỉ phải được tạo hoặc mua (CA công khai hoặc riêng tư) để bao gồm cả CN và các SAN được liệt kê ở trên. Điều này cho phép xác thực TLS phù hợp cho giao tiếp nội bộ giữa các mô-đun một cách an toàn.
**Yêu cầu về Địa chỉ IP**
| Chỉ số | Giá trị / Mô tả |
| -------------------------------- | ------------------------------------------------- |
| Tổng số Địa chỉ IP cần có | 5 (phân bổ chung) |
| Được sử dụng trong ngữ cảnh ZPLS | 2 IP (1 cho Hệ điều hành Node, 1 cho mô-đun ZPLS) |
Trong khi năm (5) IP là bắt buộc cho việc triển khai chung, **chỉ có hai (2) địa chỉ IP đang được sử dụng tích cực** trong triển khai ZPLS: mỗi mô-đun một cái, chạy trên một **máy ảo Node chuyên dụng**.
{% hint style="warning" %}
ZPLS chỉ cho phép một mô-đun trên mỗi Node VM. Bạn không thể đặt ZPLS cùng vị trí với các mô-đun Zoom khác trên cùng một VM.
{% endhint %}
Các sơ đồ này so sánh như thế nào? Hình ảnh đầu tiên cho thấy một ví dụ về triển khai Zoom Meetings Hybrid. Hình ảnh thứ hai cho thấy một ví dụ về triển khai Zoom Phone Local Survivability.
Bạn có thể chia sẻ địa chỉ IP/tên máy chủ đầu tiên giữa Hệ điều hành và mô-đun đầu tiên, nếu muốn, để giảm số lượng địa chỉ IP, tên máy chủ và Subject Alternative Names (SANs) cần thiết.
### Tùy chọn 2: Zoom Meetings Hybrid được triển khai với IP dùng chung và tên máy chủ dùng chung
Cấu hình này lặp lại cấu trúc Node như thấy trong sơ đồ Zoom Meetings Hybrid của Tùy chọn 1. Tuy nhiên, trong triển khai này, **Node Hệ điều hành chia sẻ Địa chỉ IP của nó với mô-đun được triển khai đầu tiên** (thường là Zoom Trình kết nối Proxy, ZCP). Điều này giúp giảm việc sử dụng IP trong khi vẫn duy trì TLS và các yêu cầu chức năng.
Các tên máy chủ sau phải được cấu hình trong DNS và được bao gồm trong chứng chỉ TLS:
* `zcp1.customer.com`
* `mmr1.customer.com`
* `mmr2.customer.com`
* `mmr3.customer.com`
**Ánh xạ chức năng tên máy chủ**
| Thành phần | Tên máy chủ | Vai trò Chứng chỉ TLS | Chức năng |
| ---------------------------------- | ------------------- | ------------------------------ | ------------------------------- |
| ZCP (Zoom Trình kết nối Proxy) | `zcp1.customer.com` | Tên chung (CN) | Báo hiệu và điều khiển phiên |
| Bộ định tuyến Mô-đun Phương tiện 1 | `mmr1.customer.com` | Tên thay thế của chủ thể (SAN) | Định tuyến và xử lý phương tiện |
| Bộ định tuyến Mô-đun Phương tiện 2 | `mmr2.customer.com` | Tên thay thế của chủ thể (SAN) | Định tuyến và xử lý phương tiện |
| Bộ định tuyến Mô-đun Phương tiện 3 | `mmr3.customer.com` | Tên thay thế của chủ thể (SAN) | Định tuyến và xử lý phương tiện |
**Cấu hình Chứng chỉ TLS**
| Trường | Giá trị |
| ---------------------------- | ------------------------------------------------------------- |
| Tên chung (CN) | `zcp1.customer.com` |
| Các tên thay thế của chủ thể | `mmr1.customer.com`, `mmr2.customer.com`, `mmr3.customer.com` |
Chứng chỉ phải bao gồm tất cả SAN để Hỗ trợ giao tiếp TLS an toàn giữa Zoom Node và các mô-đun Zoom đã cài đặt.
**Yêu cầu về Địa chỉ IP**
| Chỉ số | Giá trị / Mô tả |
| ----------------------------- | -------------------------------------------------------------- |
| Tổng số Địa chỉ IP cần có | 4 |
| Chiến lược chia sẻ Địa chỉ IP | Hệ điều hành Node chia sẻ Địa chỉ IP với mô-đun đầu tiên (ZCP) |
| Yêu cầu Địa chỉ IP riêng cho | ZCP/MMR1, MMR2, MMR3 |
{% hint style="info" %}
Khi Địa chỉ IP **được chia sẻ** giữa Hệ điều hành Node và mô-đun đầu tiên được triển khai (ZCP), chỉ **bốn (4) Địa chỉ IP** là bắt buộc. Thiết kế này tối ưu việc sử dụng Địa chỉ IP trong khi vẫn tuân thủ các tiêu chuẩn triển khai.
{% endhint %}
Hình ảnh trên cho thấy một triển khai ZPLS tối thiểu, trong đó **Hệ điều hành Node chia sẻ Địa chỉ IP của nó với mô-đun ZPLS đã cài đặt**. Đây là **kịch bản duy nhất** trong khung Zoom Node nơi một **chứng chỉ TLS cho một máy chủ duy nhất** là hợp lệ.
Tên máy chủ sau phải được cấu hình trong DNS và được bao gồm trong chứng chỉ TLS:
* `zplsl.customer.com`
**Ánh xạ chức năng tên máy chủ**
| Thành phần | Tên máy chủ | Vai trò Chứng chỉ TLS | Chức năng |
| ----------- | -------------------- | --------------------- | ------------------------------------ |
| Mô-đun ZPLS | `zplsl.customer.com` | Tên chung (CN) | Logic Zoom Phone Local Survivability |
**Cấu hình Chứng chỉ TLS**
| Trường | Giá trị |
| -------------- | ------------------- |
| Tên chung (CN) | `zcp1.customer.com` |
| SANs | (không bắt buộc) |
Trong cấu hình này, một chứng chỉ một người chủ trì là đủ vì cả Hệ điều hành và mô-đun ZPLS đều dùng chung cùng một tên máy chủ và Địa chỉ IP.
**Yêu cầu về Địa chỉ IP**
| Chỉ số | Giá trị / Mô tả |
| ----------------------------- | ------------------------------------------------------- |
| Tổng số Địa chỉ IP cần có | 1 |
| Chiến lược chia sẻ Địa chỉ IP | Hệ điều hành của Node và ZPLS dùng chung một Địa chỉ IP |
| Ràng buộc triển khai | Chỉ cho phép một mô-đun trên mỗi máy ảo Node (chỉ ZPLS) |
{% hint style="warning" %}
ZPLS là kịch bản duy nhất được hỗ trợ trong kiến trúc Zoom Node, trong đó:
* Một chứng chỉ một người chủ trì (chỉ CN) là chấp nhận được
* Chỉ cần một (1) Địa chỉ IP cho việc triển khai do chia sẻ Địa chỉ IP giữa Hệ điều hành và mô-đun
* Không hỗ trợ đặt thêm các mô-đun khác cùng vị trí trên cùng một máy ảo
{% endhint %}
### Hãy quyết định phương thức quản lý chứng chỉ nào phù hợp nhất cho các lần triển khai của bạn
Mỗi Mô-đun Dịch vụ được triển khai trên Zoom Node đều yêu cầu một chứng chỉ hợp lệ được ký bởi một Tổ chức Chứng thực (CA) được tin cậy công khai có trong danh sách tin cậy chứng chỉ của Zoom Node. Điều này bao gồm các tổ chức công cộng nổi tiếng.
Zoom Node cung cấp hai phương thức quản lý chứng chỉ:
* **Auto PKI**: Giải pháp đổi mới này tự động hóa việc đăng ký và gia hạn chứng chỉ bảo mật với các Tổ chức Chứng thực (CA) được tin cậy công khai. Zoom chi trả các chi phí liên quan đến việc đăng ký và gia hạn.
* **Mang chứng chỉ của riêng bạn (BYOC)**: Với tùy chọn này, bạn cung cấp các chứng chỉ của riêng mình, được ký bởi bất kỳ CA lớn nào được tin cậy công khai. Bạn tự xử lý việc đăng ký và gia hạn chứng chỉ. Các cân nhắc bổ sung được áp dụng liên quan đến khả năng của Zoom Node hỗ trợ tối đa năm hostname/SAN khi sử dụng các chứng chỉ do khách hàng cung cấp, được trình bày chi tiết thêm bên dưới.
#### Quản lý Chứng chỉ Tự động với Auto PKI
Zoom Auto PKI tự động cài đặt các chứng chỉ CA hợp lệ được tin cậy công khai cho nền tảng Zoom Node, cũng như mọi mô-đun được triển khai trên đó. Việc gia hạn chứng chỉ cũng được xử lý tự động. Điều này giúp đơn giản hóa việc quản lý chứng chỉ cho tất cả các dịch vụ và chính Zoom Node.
#### Tìm hiểu về Đăng ký và Gia hạn Chứng chỉ Auto PKI
Tình huống sau đây có thể giúp bạn hiểu cách hoạt động của việc đăng ký và gia hạn chứng chỉ.
Ví dụ: Một quản trị viên đã triển khai một phiên bản Node mới. Mỗi phiên bản yêu cầu một chứng chỉ x509 hợp lệ. **Khóa riêng của chứng chỉ không bao giờ được phép Rời khỏi phiên bản này**.
Quy trình Auto PKI thực hiện các bước sau:
1. **Truy xuất mẫu**: Tải tất cả các mẫu cấu hình được hỗ trợ, bao gồm các tùy chọn cho nhiều nhà cung cấp CA khác nhau, từ dịch vụ Auto PKI trong Zoom cloud.
2. **Thu thập Địa chỉ IP**: Thu thập tất cả các địa chỉ IP được sử dụng bởi các dịch vụ chạy trên Node và gửi chúng đến dịch vụ Auto PKI trong Zoom cloud.
3. **Cấp phát tên DNS**: Dịch vụ đám mây Auto PKI trả về một tập hợp các tên DNS theo định dạng `..zoomonprem.com`. Các miền này được cấu hình bằng các bản ghi A/AAAA.
4. **Yêu cầu tên DNS dành riêng**: Yêu cầu một tên DNS dành riêng theo định dạng `rsvd-..zoomonprem.com`.
5. **Tạo yêu cầu chứng chỉ**: Tạo một yêu cầu chứng chỉ x509, sử dụng các tên DNS từ bước thứ ba trong trường SAN và tên dành riêng từ bước thứ tư trong trường Tên Chung (CN).
6. **Cấp phát chứng chỉ**: Gửi Yêu cầu Ký Chứng chỉ (CSR) đến dịch vụ Auto PKI trong đám mây Zoom. Sau đó, dịch vụ này làm việc với các nhà cung cấp CA để cấp phát chứng chỉ, bao gồm danh sách SAN và trường CN từ bước trước.
7. **Lưu trữ cục bộ**: Ghi chứng chỉ x509 vừa được cấp từ bước cuối cùng và khóa riêng tương ứng của nó (được tạo trước đó) vào bộ lưu trữ cục bộ, giúp chúng khả dụng cho các dịch vụ đang chạy trên phiên bản Node.
Auto PKI đơn giản hóa việc quản lý chứng chỉ trên Zoom Node bằng cách tự động theo dõi ngày hết hạn và yêu cầu chứng chỉ mới, loại bỏ nhu cầu gia hạn thủ công.
#### Mang chứng chỉ của riêng bạn (BYOC)
Bạn có thể cài đặt các chứng chỉ hợp lệ của riêng mình, được ký công khai, trên Zoom Node bằng giao diện web cục bộ. Bạn có thể thực hiện việc này trong quá trình cài đặt ban đầu hoặc vào thời điểm sau đó. Quy trình này sẽ quen thuộc với những người đã quen với việc cài đặt chứng chỉ trên các ứng dụng dựa trên web.
Nếu bạn chọn sử dụng các chứng chỉ của riêng mình, hãy nhớ rằng chứng chỉ sẽ nằm trên một máy chủ giao tiếp với nhiều tên máy chủ. Do đó, loại chứng chỉ bạn Chọn phải hỗ trợ mã hóa cho lưu lượng bắt nguồn từ nhiều tên máy chủ (CN của chứng chỉ). Tất cả tên máy chủ được sử dụng cho Node và mọi dịch vụ đã triển khai phải được các dịch vụ đám mây của Zoom phân giải công khai.
Zoom khuyến nghị hai loại chứng chỉ:
* **Chứng chỉ ký tự đại diện**
* **Chứng chỉ Multi-SAN** (còn được gọi là chứng chỉ đa miền, chứng chỉ SAN hoặc chứng chỉ UCC)
{% hint style="danger" %}
Một chứng chỉ một người chủ trì điển hình sẽ không hoạt động với Zoom Node, ngoại trừ trường hợp cụ thể khi một Địa chỉ IP và tên máy chủ duy nhất được chia sẻ giữa Zoom Node và một mô-đun duy nhất. Để biết thêm ngữ cảnh, hãy xem sơ đồ ZPLS trong [#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") phần.
{% endhint %}
**Chứng chỉ ký tự đại diện: Được khuyến nghị vì sự đơn giản**
Chứng chỉ ký tự đại diện có thể mã hóa lưu lượng từ bất kỳ hostname nào trong miền. Ví dụ: Một chứng chỉ ký tự đại diện như \*.customer.com có thể mã hóa lưu lượng từ `host1.customer.com` và `host2.customer.com` hoặc bất kỳ tên nào trong `.customer.com`.
Khi bạn triển khai Zoom Node và cài đặt chứng chỉ ký tự đại diện, nó sẽ tự động mã hóa lưu lượng cho bất kỳ dịch vụ nào bạn triển khai trên Node với điều kiện tất cả các Dịch vụ được triển khai đều sử dụng Tên miền đủ điều kiện (FQDN) từ miền ký tự đại diện.
Điều này giảm thiểu công sức triển khai dịch vụ trên Node: bạn không cần biết tên các dịch vụ trước khi triển khai chúng. Tuy nhiên, bạn cần biết tên dịch vụ nếu sử dụng phương pháp chứng chỉ multi-SAN.
**Chứng chỉ Multi-SAN, Multi-Domain, SAN, hoặc UCC**
{% hint style="warning" %}
Bạn phải biết các hostname và địa chỉ IP mà bạn sẽ sử dụng cho Node (tối đa một \[1]) và bất kỳ Dịch vụ nào mà bạn sẽ cài đặt (tối đa bốn \[4]).
**Thông tin này được yêu cầu trước khi đăng ký một chứng chỉ**.
{% endhint %}
Chứng chỉ Multi-SAN là cần thiết cho Zoom Node vì nó mã hóa lưu lượng từ năm (5) hostname. Một yêu cầu một lần cho chứng chỉ này đòi hỏi phải biết trước tất cả thông tin cần thiết, bao gồm tên Node dự kiến và tên của tất cả các dịch vụ được lên kế hoạch triển khai trên Node. Ví dụ, với một mô-đun như ZPLS, chỉ có một mô-đun ZPLS được triển khai trên mỗi Node, vì vậy chỉ cần thêm một SAN nữa cho hostname dịch vụ ZPLS.
Bảng sau có thể được dùng làm một ví dụ:
| Hostname (SAN) | Địa chỉ 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-hội thảo trực tuyến.company.com` | `10.1.50.102` |
| (Dịch vụ 4 - không được dùng trong ví dụ này) | (Không áp dụng) |
Ví dụ này là một cấu hình điển hình, với một Node lưu trữ ZPLS trên cùng một địa chỉ IP, cùng với hai dịch vụ bổ sung trên các địa chỉ IP riêng biệt. Hãy thay “company.com” bằng tên miền thực tế của bạn và sử dụng các địa chỉ IP của mạng bạn.
**Các yêu cầu phân giải DNS**
Zoom yêu cầu các tên máy chủ phải có thể phân giải công khai để có thể thiết lập quan hệ tin cậy hai chiều. Tất cả tên máy chủ Zoom Node và tất cả tên máy chủ dịch vụ được triển khai trên các Node phải được bao gồm trong DNS Zone.
Nếu Tổ chức của bạn vận hành các dịch vụ hoặc miền DNS nội bộ và bên ngoài riêng biệt, tên máy chủ Zoom Node cần được lưu trữ trong một vùng mà máy chủ DNS bên ngoài của bạn có thể phân giải (có thể giới hạn chỉ phân giải cho các dải IP của Zoom). Người dùng Zoom nội bộ của bạn và đám mây Zoom cần giao tiếp bằng cùng một bộ tên máy chủ.
---
# 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/cac-dich-vu-doanh-nghiep-lon-nang-cao/zoom-node/zoom-node-deployment-field-guide/zoom-node-deployment-considerations.md?ask=&goal=
```
`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.