> 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 implantaçã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 Híbrido e Zoom Phone Local Survivability (ZPLS). Implantações típicas com um endereço IP dedicado podem se 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 a ele se o Node tiver recebido 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 configurados para compartilhar o mesmo endereço IP.

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

### <mark style="color:azul;">Opção 1: Zoom Meetings Híbrido 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 IP e certificado para implantar **Zoom Meetings** em ambientes locais ou de nuvem híbrida.

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

| Componente                    | Nome do host         | Função de certificado TLS         | Função                              |
| ----------------------------- | -------------------- | --------------------------------- | ----------------------------------- |
| SO do nó                      | `node1.customer.com` | Nome Comum (CN)                   | Orquestração central                |
| Zoom Conector Proxy           | `zcp1.customer.com`  | Nome Alternativo do Assunto (SAN) | Sinalização e controle de sessão    |
| Roteador do Módulo de Mídia 1 | `mmr1.customer.com`  | Nome Alternativo do Assunto (SAN) | Roteamento e processamento de mídia |
| Roteador do Módulo de Mídia 2 | `mmr2.customer.com`  | Nome Alternativo do Assunto (SAN) | Roteamento e processamento de mídia |
| Roteador do Módulo de Mídia 3 | `mmr3.customer.com`  | Nome Alternativo do Assunto (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 **Sobrevivência Local do Zoom Phone (ZPLS)**. O ZPLS permite a continuidade da disponibilidade do serviço telefônico no Evento de interrupção da internet ou da nuvem, executando a lógica de sobrevivência localmente em uma VM do Zoom Node.

Os seguintes hostnames devem ser configurados no DNS e incluídos no certificado TLS:

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

**Mapeamento Funcional de Hostname**

| Componente  | Nome do host         | Função de certificado TLS   | Função                                      |
| ----------- | -------------------- | --------------------------- | ------------------------------------------- |
| SO do nó    | `node1.customer.com` | Nome Comum (CN)             | Orquestração central                        |
| Módulo ZPLS | `zplsl.customer.com` | Nome Alternativo do Assunto | Lógica de Local Survivability 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 obtidos (AC pública ou privada) para incluir tanto o CN como os SANs listados acima. Isso permite a validação TLS adequada para uma 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 o SO do Node, 1 para o módulo ZPLS) |

Embora sejam necessários cinco (5) IPs para a implantação geral, **apenas dois (2) endereços IP estão a ser usados ativamente** na implantação ZPLS: um por módulo, executando em um **VM Node dedicada**.

{% hint style="warning" %}
O ZPLS permite apenas um módulo por VM do Node. Não é possível co-localizar o ZPLS com outros módulos do 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.

Você pode compartilhar o primeiro IP/nome de host entre o SO e o primeiro módulo, se desejar, para reduzir o número de endereços IP, nomes de host e Subject Alternative Names (SANs) necessários.

### <mark style="color:azul;">Opção 2: Zoom Meetings Hybrid implantado 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 Node conforme visto no diagrama Híbrido do Zoom Meetings da Opção 1. No entanto, nesta implementação, o **O SO do nó compartilha seu endereço IP com o primeiro módulo implantado** (tipicamente o Zoom Conector Proxy, ZCP). Isso resulta em menor utilização de IP, mantendo o TLS e os requisitos funcionais.

Os seguintes hostnames 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 Hostname**

| Componente                    | Nome do host        | Função de certificado TLS         | Função                              |
| ----------------------------- | ------------------- | --------------------------------- | ----------------------------------- |
| ZCP (Proxy do Conector Zoom)  | `zcp1.customer.com` | Nome Comum (CN)                   | Sinalização e controle de sessão    |
| Roteador do Módulo de Mídia 1 | `mmr1.customer.com` | Nome Alternativo do Assunto (SAN) | Roteamento e processamento de mídia |
| Roteador do Módulo de Mídia 2 | `mmr2.customer.com` | Nome Alternativo do Assunto (SAN) | Roteamento e processamento de mídia |
| Roteador do Módulo de Mídia 3 | `mmr3.customer.com` | Nome Alternativo do Assunto (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ó partilha 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 implantado (ZCP), apenas **quatro (4) endereços IP** são necessários. Este design otimiza a utilização de IP, ao mesmo tempo que continua a cumprir as normas de implementação.
{% endhint %}

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

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

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

* `zplsl.customer.com`

**Mapeamento Funcional de Hostname**

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

**Configuração do certificado TLS**

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

Nesta configuração, um certificado de um único anfitrião é suficiente, uma vez que tanto o SO como o módulo ZPLS partilham o mesmo nome do anfitrião 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      | O SO do Node e o ZPLS partilham um único endereço IP    |
| Restrição de implementação        | Apenas um módulo permitido por VM do Node (apenas ZPLS) |

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

* Um certificado de anfitrião único (apenas CN) é aceitável
* É necessário apenas um (1 )endereço IP para a implementação devido à partilha de endereço IP entre o SO e o 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 gestão de certificados funciona melhor para as suas implementações</mark>

Cada Módulo de Serviço implementado no Zoom Node requer um certificado válido assinado por uma Autoridade de Certificação (CA) publicamente confiável da lista de confiança de certificados do Zoom Node. Isto inclui autoridades públicas bem 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 certificados com Autoridades Certificadoras (CAs) publicamente confiáveis. O Zoom cobre os custos associados à inscrição e à renovação.
* **Traga Seu Próprio Certificado (BYOC)**: Com esta opção, você fornece seus próprios certificados, assinados por qualquer grande CA publicamente confiável. Você é responsável pela inscrição e pelas renovações dos certificados. Considerações adicionais se aplicam ao potencial do Zoom Node para até cinco nomes de host/SANs ao usar certificados fornecidos pelo cliente, detalhadas mais abaixo.

#### Gerenciamento Automático de Certificados com Auto PKI

O Zoom Auto PKI instala automaticamente certificados de CA válidos e publicamente confiáveis para a plataforma Zoom Node, bem como quaisquer módulos implantados nela. A renovação de certificados também é tratada automaticamente. Isso simplifica o gerenciamento de certificados para todos os serviços e para o próprio Zoom Node.

#### Entendendo a Inscrição e a Renovação de Certificados do Auto PKI

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

Por exemplo: Um administrador implantou uma nova instância de 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 realiza os seguintes passos:

1. **Recuperação de template**: Puxa todos os modelos de configuração compatíveis, incluindo opções para vários provedores de CA, 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 executados no Nó e os envia ao serviço Auto PKI no Zoom cloud.
3. **Provisionamento de Nome DNS**: O serviço de nuvem Auto PKI retorna 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 do pedido de certificado**: Gera uma solicitação de certificado x509, usando os nomes DNS da terceira etapa no campo SAN e o nome reservado da quarta etapa no campo Nome Comum (CN).
6. **Emissão de certificado**: Envia a solicitação de assinatura de certificado (CSR) para o serviço de Auto PKI na 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**: Grava o certificado x509 recém-emitido da etapa anterior e sua chave privada correspondente (gerada anteriormente) no armazenamento local, ficando Disponível para os serviços em execução na instância do Node.

Auto PKI simplifica o gerenciamento de certificados no Zoom Node ao monitorar automaticamente as datas de expiração 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 e assinados publicamente no Zoom Node através da interface web local. Pode fazê-lo durante a instalação inicial ou posteriormente. 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 oferecer Suporte à criptografia do tráfego proveniente 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 do Zoom.

O Zoom recomenda dois tipos de certificados:

* **Certificado curinga**
* **Certificado Multi-SAN** (também conhecido como Certificado multidomí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 no [#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 curinga: recomendados pela simplicidade**

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

Quando você implanta o Zoom Node e instala o certificado curinga, ele criptografará automaticamente o tráfego para quaisquer serviços que você implantar no Node, com a exigência de que todos os Serviços implantados usem um Nome de Domínio Totalmente Qualificado (FQDN) do domínio curinga.

Isso minimiza o esforço para implantar serviços no Node: você não precisa saber os nomes dos serviços antes de implantá-los. No entanto, você precisa saber os nomes dos serviços se estiver usando o método de certificado multi-SAN.

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

{% hint style="warning" %}
Você deve saber os nomes de host e os endereços IP que usará para o Node (até um \[1]) e quaisquer Serviços que estará instalando (até quatro \[4]).

**Essas informações são necessárias 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 exige conhecimento prévio de todas as informações necessárias, incluindo os nomes planejados do Node e os nomes de todos os serviços programados para implantação no Node. Por exemplo, com um módulo como 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 do 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 Zoom Node hospedando 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 exige que os nomes de host sejam resolvíveis publicamente para que a confiança bidirecional possa ser estabelecida. Todos os nomes de host do Zoom Node e todos os nomes de host dos serviços implantados nos Nodes devem ser incluídos na Zona DNS.

Se 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 que possa ser resolvida pelos seus servidores de DNS externos (podendo ser restrito a resolver apenas para intervalos de IP do Zoom). Seus usuários internos do Zoom e o Zoom cloud precisam 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, and the optional `goal` 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>&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.