# 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 giống như bộ sơ đồ sau đây.

Mỗi dịch vụ được triển khai trên Zoom Node 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.

### <mark style="color:màu xanh dương;">Tùy chọn 1: Zoom Meetings Hybrid được triển khai với IP và hostname chuyên dụng</mark>

<figure><img src="/files/7ba14d1bb7f82a9017e15011b676a42f143fd7cf" alt=""><figcaption></figcaption></figure>

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 dưới đây phân tích Node ví dụ và bao gồm các mô-đun dịch vụ proxy Đang hoạt động và MMR của nó:

| Thành phần               | Hostname             | Vai trò chứng chỉ TLS          | Chức năng                       |
| ------------------------ | -------------------- | ------------------------------ | ------------------------------- |
| Hệ điều hành Node        | `node1.customer.com` | Common Name (CN)               | Điều phối lõi                   |
| Zoom Trình kết nối Proxy | `zcp1.customer.com`  | Subject Alternative Name (SAN) | Báo hiệu và điều khiển phiên    |
| Media Module Router 1    | `mmr1.customer.com`  | Subject Alternative Name (SAN) | Định tuyến và xử lý phương tiện |
| Media Module Router 2    | `mmr2.customer.com`  | Subject Alternative Name (SAN) | Định tuyến và xử lý phương tiện |
| Media Module Router 3    | `mmr3.customer.com`  | Subject Alternative Name (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 %}

<figure><img src="/files/03e6bde3b1310b7ad78708eb8c9149d3349bc6a6" alt=""><figcaption></figcaption></figure>

Hình ảnh ở trên phác thảo 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 khả dụng của dịch vụ điện thoại trong trường hợp 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 hostname 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 hostname**

| Thành phần        | Hostname             | Vai trò chứng chỉ TLS    | Chức năng                            |
| ----------------- | -------------------- | ------------------------ | ------------------------------------ |
| Hệ điều hành Node | `node1.customer.com` | Common Name (CN)         | Điều phối lõi                        |
| Mô-đun ZPLS       | `zplsl.customer.com` | Subject Alternative Name | logic Zoom Phone Local Survivability |

**Cấu hình chứng chỉ TLS**

| Trường                    | Giá trị              |
| ------------------------- | -------------------- |
| Common Name (CN)          | `node1.customer.com` |
| Subject Alternative Names | `zplsl.customer.com` |

Chứng chỉ phải được tạo hoặc mua sẵn (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 nội bộ.

**Yêu cầu Đị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 Địa chỉ IP (1 cho Hệ điều hành Node, 1 cho mô-đun ZPLS) |

Mặc dù cần năm (5) IP cho 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ột cho mỗi mô-đun, chạy trên một **Node VM 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 đồng thời ZPLS 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 thứ nhất hiển thị một ví dụ về triển khai kết hợp Zoom Meetings. Hình ảnh thứ hai hiển thị một ví dụ về triển khai Khả năng duy trì cục bộ Zoom Phone.

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ể (SAN) cần thiết.

### <mark style="color:màu xanh dương;">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</mark>

<figure><img src="/files/73448f11a98c170e5fc141b6b90ab233d5c31bd4" alt=""><figcaption></figcaption></figure>

Cấu hình này lặp lại cấu trúc Node như trong sơ đồ Zoom Meetings Hybrid của 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 IP trong khi vẫn duy trì TLS và các yêu cầu chức năng.

Các hostname 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 hostname**

| Thành phần                     | Hostname            | Vai trò chứng chỉ TLS          | Chức năng                       |
| ------------------------------ | ------------------- | ------------------------------ | ------------------------------- |
| ZCP (Zoom Trình kết nối Proxy) | `zcp1.customer.com` | Common Name (CN)               | Báo hiệu và điều khiển phiên    |
| Media Module Router 1          | `mmr1.customer.com` | Subject Alternative Name (SAN) | Định tuyến và xử lý phương tiện |
| Media Module Router 2          | `mmr2.customer.com` | Subject Alternative Name (SAN) | Định tuyến và xử lý phương tiện |
| Media Module Router 3          | `mmr3.customer.com` | Subject Alternative Name (SAN) | Định tuyến và xử lý phương tiện |

**Cấu hình chứng chỉ TLS**

| Trường                    | Giá trị                                                       |
| ------------------------- | ------------------------------------------------------------- |
| Common Name (CN)          | `zcp1.customer.com`                                           |
| Subject Alternative Names | `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 Đị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ẻ IP        | Hệ điều hành Node chia sẻ IP với mô-đun đầu tiên (ZCP) |
| Các IP riêng lẻ bắt buộc 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 hóa việc sử dụng IP trong khi vẫn tuân thủ các tiêu chuẩn triển khai.
{% endhint %}

<figure><img src="/files/3fd2622584d1e3c8eb99261b99f22f71cb696d8b" alt=""><figcaption></figcaption></figure>

Hình ảnh ở trên hiển thị 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 khuôn khổ Zoom Node mà **chứng chỉ TLS máy chủ đơn** là hợp lệ.

Tên máy chủ sau đây phải được cấu hình trong DNS và được đưa vào chứng chỉ TLS:

* `zplsl.customer.com`

**Ánh xạ chức năng hostname**

| Thành phần  | Hostname             | Vai trò chứng chỉ TLS | Chức năng                            |
| ----------- | -------------------- | --------------------- | ------------------------------------ |
| Mô-đun ZPLS | `zplsl.customer.com` | Common Name (CN)      | logic Zoom Phone Local Survivability |

**Cấu hình chứng chỉ TLS**

| Trường           | Giá trị             |
| ---------------- | ------------------- |
| Common Name (CN) | `zcp1.customer.com` |
| SAN              | (không bắt buộc)    |

Trong cấu hình này, chứng chỉ máy chủ đơn 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 Đị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ẻ 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 Node VM (chỉ ZPLS)       |

{% hint style="warning" %}
ZPLS là kịch bản được hỗ trợ duy nhất trong kiến trúc Zoom Node mà ở đó:

* Chứng chỉ máy chủ đơn (chỉ CN) là chấp nhận được
* Chỉ cần một (1) Địa chỉ IP cho triển khai do chia sẻ IP giữa Hệ điều hành và mô-đun
* Không hỗ trợ đặt đồng thời các mô-đun bổ sung trên cùng một VM
  {% endhint %}

### <mark style="color:màu xanh dương;">Quyết định phương pháp quản lý chứng chỉ phù hợp nhất cho các triển khai của bạn</mark>

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 cấp chứng chỉ (CA) được tin cậy công khai từ 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 khai nổi tiếng.

Zoom Node cung cấp hai phương pháp quản lý chứng chỉ:

* **PKI tự động**: Giải pháp tiên tiến này tự động hóa việc đăng ký và gia hạn chứng chỉ an toàn với các Tổ chức cấp chứng chỉ (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 chứng chỉ của riêng mình, được ký bởi bất kỳ CA được tin cậy công khai lớn nào. 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ó tối đa năm tên máy chủ/SAN của Zoom Node khi sử dụng chứng chỉ do khách hàng cung cấp, sẽ được trình bày chi tiết thêm bên dưới.

#### Quản lý chứng chỉ tự động với PKI tự động

Zoom Auto PKI tự động cài đặt các chứng chỉ CA được tin cậy công khai hợp lệ 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 đơn giản hóa việc quản lý chứng chỉ cho tất cả dịch vụ và chính Zoom Node.

#### Tìm hiểu việc đăng ký và gia hạn chứng chỉ Auto PKI

Kịch bản 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 rời khỏi phiên bản này**.

Quá 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ụ đang 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 `<instance_mã nhận diện>.<customer_mã nhận diện>.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 đã được đặt trước**: Yêu cầu một tên DNS được dành trước theo định dạng `rsvd-<randomized_string>.customer_mã nhận diện.zoomonprem.com`.
5. **Tạo yêu cầu chứng chỉ**: Tạo 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 được 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. Dịch vụ này sau đó 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ộ lưu trữ cục bộ, khiến 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 giám sát 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 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ủ. Vì vậy, loại chứng chỉ bạn Chọn phải hỗ trợ mã hóa cho lưu lượng truy cập xuất phát 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 sử dụng cho Node và bất kỳ dịch vụ nào được triển khai phải có thể được Zoom's dịch vụ đám mây phân giải công khai.

Zoom khuyến nghị hai loại chứng chỉ:

* **Chứng chỉ Wildcard**
* **Chứng chỉ Multi-SAN** (còn được gọi là Chứng chỉ Multi-Domain, Chứng chỉ SAN hoặc Chứng chỉ UCC)

{% hint style="danger" %}
Một chứng chỉ thông thường dành cho một máy chủ duy nhất 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 dùng chung 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ỉ wildcard: Được khuyến nghị vì tính đơn giản**

Chứng chỉ wildcard 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ỉ wildcard 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ỉ 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 phải sử dụng một Tên miền Đủ điều kiện (FQDN) từ miền wildcard.

Điều này giảm thiểu công sức triển khai các 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 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) tên máy chủ. 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ụ 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 cho tên máy chủ 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 sử dụng trong ví dụ này) | (N/A)         |

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. 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 đưa vào Vùng DNS.

Nếu Tổ chức của bạn sử dụng các dịch vụ DNS hoặc các miền nội bộ và bên ngoài riêng biệt, thì các tên máy chủ của Zoom Node cần được lưu trữ trong một vùng có thể được phân giải 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 phải giao tiếp bằng cùng một bộ tên máy chủ.


---

# Agent Instructions: 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:

```
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=<question>
```

The question should be specific, self-contained, and written in natural language.
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.