> 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/dich-vu-doanh-nghiep-lon-nang-cao/zoom-node/zoom-node-deployment-field-guide/zoom-node-deployment-considerations.md).
# Các 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ợ các Mô-đun Dịch vụ khác nhau như Zoom Meetings Hybrid và Zoom Phone Local Survivability (ZPLS). Các triển khai điển hình với một Địa chỉ IP chuyên dụng có thể trô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ể cho 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 Địa chỉ IP và chứng chỉ (CN/SANs) 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 Địa chỉ IP chuyên dụng và tên máy chủ
Hình trên tóm tắt các yêu cầu cấu hình Địa chỉ 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 dưới đây phân tích chi tiết Node ví dụ và bao gồm proxy Đang hoạt động và các Mô-đun Dịch vụ MMR:
| 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 cốt 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 yêu cầu: năm (5)
{% endhint %}
Hình trên phác thảo cấu hình tối thiểu cần có để triển khai **Khả năng duy trì cục bộ của Zoom Phone (ZPLS)**. ZPLS cho phép dịch vụ điện thoại tiếp tục khả dụng trong trường hợp xảy ra Sự kiện gián đoạn internet hoặc đám mây bằng cách chạy logic khả năng duy trì 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 đưa vào 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 cốt lõi |
| Mô-đun ZPLS | `zplsl.customer.com` | Tên thay thế của chủ thể | logic khả năng duy trì cục bộ của Zoom Phone |
**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 sắm (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 đúng cách cho giao tiếp an toàn giữa các mô-đun.
**Yêu cầu về Địa chỉ IP**
| Chỉ số | Giá trị / Mô tả |
| -------------------------------- | --------------------------------------------------------- |
| Tổng số Địa chỉ IP được yêu cầu | 5 (phân bổ chung) |
| Được sử dụng trong ngữ cảnh ZPLS | 2 Địa chỉ IP (1 cho Hệ điều hành Node, 1 cho mô-đun ZPLS) |
Mặc dù cần năm (5) Địa chỉ IP cho triển khai chung, **chỉ hai (2) Địa chỉ IP đang hoạt động được sử dụng** trong triển khai ZPLS: một cho mỗi mô-đun, 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 máy ảo Node. Bạn không thể đặt ZPLS đồng vị trí với các mô-đun Zoom khác trên cùng một máy ảo.
{% endhint %}
Các sơ đồ này so sánh như thế nào? Hình đầu tiên cho thấy một ví dụ về triển khai Zoom Meetings Hybrid. Hình thứ hai cho thấy một ví dụ về triển khai Zoom Phone Local Survivability.
Bạn có thể chia sẻ 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à Tên thay thế chủ thể (SANs) cần thiết.
### Tùy chọn 2: Zoom Meetings Hybrid được triển khai với Địa chỉ 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ư trong sơ đồ Zoom Meetings Hybrid ở Tùy chọn 1. Tuy nhiên, trong triển khai này, **Hệ điều hành Node chia sẻ Địa chỉ IP của nó với mô-đun đầu tiên được triển khai** (thường là Zoom Trình kết nối Proxy, ZCP). Điều này giúp giảm mức sử dụng Địa chỉ 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 đưa vào 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` |
Các chứng chỉ phải bao gồm tất cả SANs để 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 yêu cầu | 4 |
| Chiến lược chia sẻ Địa chỉ IP | Hệ điều hành Node chia sẻ IP với mô-đun đầu tiên (ZCP) |
| Các Địa chỉ IP riêng lẻ cần cho | ZCP/MMR1, MMR2, MMR3 |
{% hint style="info" %}
Khi Địa chỉ IP là **đượ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à cần thiết. Thiết kế này tối ưu hóa 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 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 một máy chủ** là hợp lệ.
Tên máy chủ sau phải được cấu hình trong DNS và 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 khả năng duy trì cục bộ của Zoom Phone |
**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 máy chủ là đủ vì cả Hệ điều hành và mô-đun ZPLS đều chia sẻ 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 yêu cầu | 1 |
| Chiến lược chia sẻ Địa chỉ IP | Hệ điều hành Node và ZPLS chia sẻ một Địa chỉ IP duy nhất |
| 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 máy chủ (chỉ CN) là chấp nhận được
* Chỉ cần một (1) Địa chỉ IP cho việc triển khai do việc chia sẻ Địa chỉ IP giữa Hệ điều hành và mô-đun
* Không hỗ trợ việc đặt thêm mô-đun đồ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 triển khai của bạn
Mỗi Mô-đun Dịch vụ được triển khai trên Zoom Node yêu cầu một chứng chỉ hợp lệ được ký bởi một Cơ quan cấp chứng chỉ (CA) được công chúng tin cậy từ danh sách tin cậy chứng chỉ của Zoom Node. Điều này bao gồm các CA 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 sáng tạo này tự động hóa việc đăng ký và gia hạn chứng chỉ an toàn với các Cơ quan cấp chứng chỉ (CA) được công chúng tin cậy. Zoom chi trả các chi phí liên quan đến việc đăng ký và gia hạn.
* **Tự 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 công chúng tin cậy. Bạn tự xử lý việc đăng ký và gia hạn chứng chỉ. Có thêm các cân nhắc liên quan đến khả năng của Zoom Node về tối đa năm tên máy chủ/SANs 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 hơn 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 công chúng tin cậy cho nền tảng Zoom Node, cũng như bất kỳ mô-đun nào được triển khai trên đó. Việc gia hạn chứng chỉ cũng được tự động xử lý. Điều này đơ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.
#### Hiểu về việc đăng ký và gia hạn chứng chỉ Auto PKI
Kịch bản sau có thể giúp bạn hiểu cách thức đăng ký và gia hạn chứng chỉ hoạt động.
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ỉ này không bao giờ được 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, 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 tên DNS theo định dạng `..zoomonprem.com`. Các tên miền này được cấu hình với các bản ghi A/AAAA.
4. **Yêu cầu tên DNS được đặt trước**: Yêu cầu một tên DNS được dành trước 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 Common Name (CN).
6. **Cấp chứng chỉ**: Gửi Yêu cầu ký chứng chỉ (CSR) tới dịch vụ Auto PKI trong Zoom cloud. Sau đó, dịch vụ này làm việc với các nhà cung cấp CA để cấp chứng chỉ, bao gồm danh sách SAN và trường CN từ bước trước.
7. **Bộ nhớ cục bộ**: Ghi chứng chỉ x509 mới được cấp từ bước trước và khóa riêng tương ứng của nó (được tạo trước đó) vào bộ nhớ cục bộ, giúp chúng sẵn sà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 theo 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 ký công khai của riêng mình 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 ai đã quen 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 truy cập đến từ hơn một tên máy chủ (CN của chứng chỉ). Tất cả các tên máy chủ được dùng cho Node và mọi dịch vụ đã triển khai phải có thể được phân giải công khai bởi các dịch vụ đám mây của Zoom.
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ỉ cho một máy chủ đơn lẻ thông thường 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, 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ì đơn giản**
Một chứng chỉ ký tự đại diện có thể mã hóa lưu lượng truy cập từ bất kỳ tên máy chủ 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 truy cập 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ỉ wildcard, 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 yêu cầu rằng tất cả các Dịch vụ được triển khai đều sử dụng một Fully Qualified Domain Name (FQDN) từ miền wildcard.
Điều này giúp giảm bớt công sức triển khai dịch vụ trên Node: bạn không cần biết tên của 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 bạn sẽ sử dụng cho Node (tối đa một \[1]) và bất kỳ Dịch vụ nào 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 %}
Một 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 các tên Node dự kiến và tên của tất cả các dịch vụ sẽ được triển khai trên Node. Ví dụ, với một mô-đun như ZPLS, chỉ 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 bổ sung cho hostname của dịch vụ ZPLS.
Bảng sau đây có thể được dùng làm ví dụ:
| Tên máy chủ (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 IP cộng thêm hai dịch vụ bổ sung trên các IP riêng biệt. Thay “company.com” bằng tên miền thực tế của bạn và sử dụng địa chỉ IP của mạng của bạn.
**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ể được phân giải công khai để có thể thiết lập sự tin cậy hai chiều. Tất cả các tên máy chủ Zoom Node và tất cả các tên máy chủ dịch vụ được triển khai trên các Node phải được đưa vào vùng DNS.
Nếu Tổ chức của bạn vận hành các dịch vụ DNS hoặc các miền nội bộ và bên ngoài riêng biệt, các tên máy chủ của Zoom Node cần được lưu trữ trong một vùng có thể phân giải được bởi các máy chủ DNS bên ngoài của bạn (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/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.