> 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/pt/servicos-empresariais-avancados/zoom-node/zoom-node-deployment-field-guide/zoom-node-deployment-considerations.md).

# Considerações sobre a implementação do Zoom Node

Esta seção contém vários exemplos de como o Zoom Node pode suportar vários Módulos de Serviço como Zoom Meetings Hybrid e Zoom Phone Local Survivability (ZPLS). Implementações típicas com um endereço IP dedicado podem parecer com a seguinte coleção de diagramas.

Cada serviço implantado no Zoom Node requer um endereço IP exclusivo. Um Zoom Node terá até cinco (5) endereços IP atribuídos se o Node tiver sido atribuído a um endereço específico para gerenciamento e um para cada serviço implantado (até quatro) no Node. Um Zoom Node executando um único serviço (como ZPLS) pode ser implantado com um único endereço IP se o Node e o serviço forem atribuídos para compartilhar o mesmo endereço IP.

Várias opções de implementação são mostradas abaixo. Observe o número de endereços IP e certificados (CN/SANs) para as várias opções de implementação.

### <mark style="color:azul;">Opção 1: Zoom Meetings Hybrid implantado com endereços IP dedicados e nomes de host</mark>

<figure><img src="/files/28c4468b1e417c52a06987b9ab39449592d3af82" alt=""><figcaption></figcaption></figure>

A imagem acima resume os requisitos de configuração de endereço IP e certificado para implantar **Zoom Meetings Hybrid** em ambientes locais ou de nuvem híbrida.

A tabela abaixo detalha o exemplo de Node e inclui seus Módulos de Serviço proxy e MMR Ativo:

| Componente                    | Nome do host         | Função do certificado TLS         | Função                              |
| ----------------------------- | -------------------- | --------------------------------- | ----------------------------------- |
| Nó SO                         | `node1.customer.com` | Nome Comum (CN)                   | Orquestração central                |
| Proxy do Conector Zoom        | `zcp1.customer.com`  | Nome Alternativo do Sujeito (SAN) | Sinalização e controlo de sessão    |
| Roteador do Módulo de Mídia 1 | `mmr1.customer.com`  | Nome Alternativo do Sujeito (SAN) | Roteamento e processamento de mídia |
| Roteador do Módulo de Mídia 2 | `mmr2.customer.com`  | Nome Alternativo do Sujeito (SAN) | Roteamento e processamento de mídia |
| Roteador do Módulo de Mídia 3 | `mmr3.customer.com`  | Nome Alternativo do Sujeito (SAN) | Roteamento e processamento de mídia |

{% hint style="info" %}
Você deve Atribuir a cada módulo um endereço IP estático dedicado. Total de endereços IP necessários: cinco (5)
{% endhint %}

<figure><img src="/files/c729bc3e0ada6d257360890174f41a9b932f986b" alt=""><figcaption></figcaption></figure>

A imagem acima descreve a configuração mínima necessária para implantar **Zoom Phone Local Survivability (ZPLS)**. ZPLS permite a disponibilidade contínua do serviço telefónico no Evento de interrupção da internet ou da nuvem, executando a lógica de sobrevivência localmente numa VM do Zoom Node.

Os seguintes nomes de anfitrião devem ser configurados no DNS e incluídos no certificado TLS:

* `node1.customer.com`
* `zplsl.customer.com`

**Mapeamento Funcional de Nome de Anfitrião**

| Componente  | Nome do host         | Função do certificado TLS   | Função                                      |
| ----------- | -------------------- | --------------------------- | ------------------------------------------- |
| Nó SO       | `node1.customer.com` | Nome Comum (CN)             | Orquestração central                        |
| Módulo ZPLS | `zplsl.customer.com` | Nome Alternativo do Assunto | Lógica de Sobrevivência Local do Zoom Phone |

**Configuração do certificado TLS**

| Campo                         | Valor                |
| ----------------------------- | -------------------- |
| Nome Comum (CN)               | `node1.customer.com` |
| Nomes Alternativos do Assunto | `zplsl.customer.com` |

Os certificados devem ser gerados ou adquiridos (AC pública ou privada) para incluir tanto o CN quanto os SANs listados acima. Isso permite a validação TLS adequada para comunicação segura entre módulos.

**Requisitos de endereço IP**

| Métrica                           | Valor / Descrição                               |
| --------------------------------- | ----------------------------------------------- |
| Total de Endereços IP Necessários | 5 (alocação geral)                              |
| Usado no contexto ZPLS            | 2 IPs (1 para SO do Node, 1 para o módulo ZPLS) |

Embora sejam necessários cinco (5) IPs para a implementação geral, **apenas dois (2) endereços IP são usados ativamente** na implementação do ZPLS: um por módulo, a correr num **VM Node dedicada**.

{% hint style="warning" %}
O ZPLS permite apenas um módulo por Node VM. Você não pode co-localizar o ZPLS com outros módulos Zoom na mesma VM.
{% endhint %}

Como estes diagramas se comparam? A primeira imagem mostra um exemplo de uma implementação híbrida do Zoom Meetings. A segunda imagem mostra um exemplo de uma implementação de sobrevivência local do Zoom Phone.

Pode partilhar o primeiro IP/hostname entre o SO e o primeiro módulo, se desejar, para reduzir o número de endereços IP, hostnames e Subject Alternative Names (SANs) necessários.

### <mark style="color:azul;">Opção 2: Zoom Meetings Hybrid implementado com um IP partilhado e um nome de host partilhado</mark>

<figure><img src="/files/7447550dfa6aa5bd2d3040411b339e9620e90c80" alt=""><figcaption></figcaption></figure>

Esta configuração repete a estrutura do Node, como visto no diagrama Hybrid de Zoom Meetings da Opção 1. No entanto, nesta implementação, o **O SO do nó compartilha o seu endereço IP com o primeiro módulo implantado** (normalmente o Zoom Conector Proxy, ZCP). Isso resulta em uma utilização reduzida de IP, mantendo o TLS e os requisitos funcionais.

Os seguintes nomes de anfitrião devem ser configurados no DNS e incluídos no certificado TLS:

* `zcp1.customer.com`
* `mmr1.customer.com`
* `mmr2.customer.com`
* `mmr3.customer.com`

**Mapeamento Funcional de Nome de Anfitrião**

| Componente                    | Nome do host        | Função do certificado TLS         | Função                              |
| ----------------------------- | ------------------- | --------------------------------- | ----------------------------------- |
| ZCP (Zoom Conector Proxy)     | `zcp1.customer.com` | Nome Comum (CN)                   | Sinalização e controlo de sessão    |
| Roteador do Módulo de Mídia 1 | `mmr1.customer.com` | Nome Alternativo do Sujeito (SAN) | Roteamento e processamento de mídia |
| Roteador do Módulo de Mídia 2 | `mmr2.customer.com` | Nome Alternativo do Sujeito (SAN) | Roteamento e processamento de mídia |
| Roteador do Módulo de Mídia 3 | `mmr3.customer.com` | Nome Alternativo do Sujeito (SAN) | Roteamento e processamento de mídia |

**Configuração do certificado TLS**

| Campo                         | Valor                                                         |
| ----------------------------- | ------------------------------------------------------------- |
| Nome Comum (CN)               | `zcp1.customer.com`                                           |
| Nomes Alternativos do Assunto | `mmr1.customer.com`, `mmr2.customer.com`, `mmr3.customer.com` |

Os certificados devem incluir todos os SANs para Suporte à comunicação TLS segura entre o Zoom Node e os módulos Zoom instalados.

**Requisitos de endereço IP**

| Métrica                           | Valor / Descrição                                       |
| --------------------------------- | ------------------------------------------------------- |
| Total de Endereços IP Necessários | 4                                                       |
| Estratégia de Partilha de IP      | O SO do nó compartilha o IP com o primeiro módulo (ZCP) |
| IPs individuais necessários para  | ZCP/MMR1, MMR2, MMR3                                    |

{% hint style="info" %}
Quando o endereço IP é **partilhado** entre o SO do Node e o primeiro módulo implementado (ZCP), apenas **quatro (4) endereços IP** são necessários. Este design otimiza o uso de IP, ao mesmo tempo que continua a cumprir os padrões de implementação.
{% endhint %}

<figure><img src="/files/569a60807b75c5b64cf3b8cfb4142fb0057b6e16" alt=""><figcaption></figcaption></figure>

A imagem acima mostra uma implementação mínima do ZPLS em que o **O SO do nó compartilha seu endereço IP com o módulo ZPLS instalado**. Isto é o **apenas cenário** no framework Zoom Node onde um **certificado TLS de anfitrião único** é válido.

O seguinte nome de anfitrião deve ser configurado no DNS e incluído no certificado TLS:

* `zplsl.customer.com`

**Mapeamento Funcional de Nome de Anfitrião**

| Componente  | Nome do host         | Função do certificado TLS | Função                                      |
| ----------- | -------------------- | ------------------------- | ------------------------------------------- |
| Módulo ZPLS | `zplsl.customer.com` | Nome Comum (CN)           | Lógica de Sobrevivência Local do Zoom Phone |

**Configuração do certificado TLS**

| Campo           | Valor               |
| --------------- | ------------------- |
| Nome Comum (CN) | `zcp1.customer.com` |
| SANs            | (não necessário)    |

Nesta configuração, um certificado de anfitrião único é suficiente, uma vez que tanto o SO quanto o módulo ZPLS compartilham o mesmo hostname e endereço IP.

**Requisitos de endereço IP**

| Métrica                           | Valor / Descrição                                       |
| --------------------------------- | ------------------------------------------------------- |
| Total de Endereços IP Necessários | 1                                                       |
| Estratégia de Partilha de IP      | SO do Node e ZPLS compartilham um único endereço IP     |
| Restrição de implantação          | Apenas um módulo permitido por VM do Node (apenas ZPLS) |

{% hint style="warning" %}
ZPLS é o único cenário suportado na arquitetura do Zoom Node em que:

* Um certificado de anfitrião único (apenas CN) é aceitável
* Apenas um (1 )endereço IP é necessário para a implantação devido ao compartilhamento de IP entre SO e módulo
* A co-localização de módulos adicionais na mesma VM não é suportada
  {% endhint %}

### <mark style="color:azul;">Decida qual método de gerenciamento de certificado funciona melhor para suas implantações</mark>

Cada Módulo de Serviço implantado no Zoom Node requer um certificado válido assinado por uma Autoridade de Certificação (CA) de confiança pública da lista de confiança de certificados do Zoom Node. Isso inclui autoridades públicas amplamente conhecidas.

O Zoom Node oferece dois métodos de gestão de certificados:

* **Auto PKI**: Esta solução inovadora automatiza a inscrição e a renovação seguras de certificado com Autoridades de Certificação (CAs) de confiança pública. O Zoom cobre os custos associados à inscrição e à renovação.
* **Traga Seu Próprio Certificado (BYOC)**: Com esta opção, você fornece os seus próprios certificados, assinados por qualquer grande CA de confiança pública. Você gerencia a inscrição e as renovações de certificado. Aplicam-se considerações adicionais relativamente ao potencial do Zoom Node para até cinco hostnames/SANs ao usar certificados fornecidos pelo cliente, que são detalhadas mais abaixo.

#### Gestão Automática de Certificado com Auto PKI

O Zoom Auto PKI instala automaticamente certificados válidos de CAs de confiança pública para a plataforma Zoom Node, bem como para quaisquer módulos implantados nela. A renovação do certificado também é tratada automaticamente. Isso simplifica a gestão de certificados para todos os serviços e para o próprio Zoom Node.

#### Compreender a Inscrição e a Renovação de Certificado do Auto PKI

O cenário a seguir pode ajudar você a entender como a inscrição e a renovação de certificado funcionam.

Por exemplo: Um administrador implantou uma nova instância Node. Cada instância requer um certificado x509 válido. **A chave privada do certificado nunca deve sair desta instância**.

O processo Auto PKI executa as seguintes etapas:

1. **Recuperação de Modelo**: Faz a leitura de todos os modelos de configuração compatíveis, incluindo opções para vários provedores de CA, a partir do serviço Auto PKI no Zoom cloud.
2. **Coleta de endereço IP**: Reúne todos os endereços IP usados por serviços em execução no Node e os envia para o serviço Auto PKI no Zoom cloud.
3. **Provisionamento de Nome DNS**: O serviço de nuvem Auto PKI devolve um conjunto de nomes DNS no formato `<instance_identificador>.<customer_identificador>.zoomonprem.com`. Estes domínios estão configurados com registos A/AAAA.
4. **Pedido de Nome DNS Reservado**: Solicita um nome DNS reservado no formato `rsvd-<randomized_string>.<customer_identificador>.zoomonprem.com`.
5. **Geração de solicitação de certificado**: Gera um pedido de certificado x509, usando os nomes DNS da terceira etapa no campo SAN e o nome reservado da quarta etapa no campo Common Name (CN).
6. **Emissão de certificado**: Envia a solicitação de assinatura de certificado (CSR) para o serviço Auto PKI no Zoom cloud. Este serviço então trabalha com fornecedores de CA para emitir o certificado, que inclui a lista SAN e o campo CN da etapa anterior.
7. **Armazenamento local**: Escreve o certificado x509 recentemente emitido da etapa anterior e a respetiva chave privada (gerada anteriormente) no armazenamento local, tornando-os disponíveis para serviços em execução na instância Node.

O PKI automático simplifica a gestão de certificado no Zoom Node ao monitorizar automaticamente as datas de validade e solicitar novos certificados, eliminando a necessidade de renovação manual.

#### Traga os Seus Próprios Certificados (BYOC)

Pode instalar os seus próprios certificados válidos, assinados publicamente, no Zoom Node utilizando a interface web local. Pode fazê-lo durante a instalação inicial ou mais tarde. O processo será familiar para quem está habituado a instalar certificados em aplicações baseadas na web.

Se optar por utilizar os seus próprios certificados, lembre-se de que o certificado estará num servidor que comunica com vários nomes de anfitrião. Por conseguinte, o tipo de certificado que Escolher deve suportar criptografia para tráfego originado a partir de mais de um nome de anfitrião (CN do certificado). Todos os nomes de anfitrião utilizados para o Node e quaisquer serviços implementados devem poder ser resolvidos publicamente pelos serviços de nuvem da Zoom.

A Zoom recomenda dois tipos de certificados:

* **Certificado wildcard**
* **Certificado Multi-SAN** (também conhecido como certificado multi-domínio, certificado SAN ou certificado UCC)

{% hint style="danger" %}
Um certificado típico de anfitrião único não funcionará com o Zoom Node, exceto no cenário específico em que um único endereço IP e nome de anfitrião são partilhados entre o Zoom Node e um único módulo. Para contexto adicional, consulte o diagrama ZPLS na [#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") secção.
{% endhint %}

**Certificados wildcard: Recomendados pela simplicidade**

Um certificado wildcard pode encriptar o tráfego de qualquer nome de anfitrião no domínio. Por exemplo: Um certificado wildcard como \*.customer.com pode encriptar o tráfego de `host1.customer.com` e `host2.customer.com` ou qualquer nome dentro de `.customer.com`.

Quando implementa o Zoom Node e instala o certificado wildcard, este irá encriptar automaticamente o tráfego de quaisquer serviços que implemente no Node, com a exigência de que todos os Services implementados utilizem um Fully Qualified Domain Name (FQDN) do domínio wildcard.

Isto minimiza o esforço para implementar serviços no Node: não precisa de saber os nomes dos serviços antes de os implementar. No entanto, precisa de conhecer os nomes dos serviços se estiver a utilizar o método de certificado multi-SAN.

**Certificados Multi-SAN, Multi-Domain, SAN ou UCC**

{% hint style="warning" %}
Tem de conhecer os nomes de anfitrião e os endereços IP que irá utilizar para o Node (até um \[1]) e quaisquer Services que irá instalar (até quatro \[4]).

**Esta informação é necessária antes de inscrever um certificado**.
{% endhint %}

Um certificado Multi-SAN é necessário para o Zoom Node porque ele criptografa o tráfego de cinco (5) nomes de host. Uma solicitação única para este certificado requer conhecimento prévio de todas as informações necessárias, incluindo os nomes planejados dos Nodes e os nomes de todos os serviços programados para implantação no Node. Por exemplo, com um módulo como o ZPLS, apenas um módulo ZPLS é implantado por Node, então apenas um SAN adicional é necessário para o nome de host do serviço ZPLS.

A tabela a seguir pode ser usada como exemplo:

| Nome de host (SAN)                    | endereço 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-webinar.company.com`            | `10.1.50.102` |
| (Serviço 4 - não usado neste exemplo) | (N/D)         |

Este exemplo é de uma configuração típica, com um Node a alojar o ZPLS no mesmo IP, além de dois serviços adicionais em IPs separados. Substitua “company.com” pelo seu domínio real e use os endereços IP da sua rede.

**Requisitos de resolução de DNS**

O Zoom requer que os nomes de anfitrião sejam resolúveis publicamente, para que possa ser estabelecida confiança bidirecional. Todos os nomes de anfitrião do Zoom Node e todos os nomes de anfitrião dos serviços implementados nos Nós devem ser incluídos na zona DNS.

Se a sua Organização executa serviços ou domínios de DNS internos e externos separados, os nomes de host do Zoom Node precisam ser hospedados em uma zona resolvível pelos seus servidores DNS externos (podem ser restringidos para resolver apenas para intervalos de IP do Zoom). Os seus utilizadores do Zoom internos e a Zoom cloud precisam de se comunicar usando o mesmo conjunto de nomes de host.


---

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

```
GET https://library.zoom.com/technical-library/pt/servicos-empresariais-avancados/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.