# 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 o Zoom Meetings Hybrid e o 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 estiverem 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 Hybrid implantado com IPs e nomes de host dedicados</mark>

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

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

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

| Componente                    | Nome do host         | Função do certificado TLS         | Função                              |
| ----------------------------- | -------------------- | --------------------------------- | ----------------------------------- |
| SO do nó                      | `node1.customer.com` | Nome Comum (CN)                   | Orquestração central                |
| Proxy do Conector Zoom        | `zcp1.customer.com`  | Nome Alternativo do Assunto (SAN) | Sinalização e controlo 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 **Zoom Phone Local Survivability (ZPLS)**. O ZPLS permite a disponibilidade contínua do serviço telefônico em caso de interrupção da internet ou da nuvem, executando a lógica de survivability localmente em uma VM do Zoom Node.

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

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

**Mapeamento Funcional do Nome de Host**

| Componente  | Nome do host         | Função do 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 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 (CA pública ou privada) para incluir tanto o CN quanto os SANs listados acima. Isso permite a validação adequada do TLS para uma comunicação segura entre módulos.

**Requisitos do 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 Node SO, 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 em uso ativo** na implantação do ZPLS: um por módulo, executando em um **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 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 compartilhado e um nome de host compartilhado</mark>

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

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

Os seguintes nomes de host 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 do Nome de Host**

| Componente                    | Nome do host        | Função do certificado TLS         | Função                              |
| ----------------------------- | ------------------- | --------------------------------- | ----------------------------------- |
| ZCP (Proxy do Conector Zoom)  | `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 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 do endereço IP**

| Métrica                              | Valor / Descrição                                     |
| ------------------------------------ | ----------------------------------------------------- |
| Total de endereços IP necessários    | 4                                                     |
| Estratégia de Compartilhamento de IP | O SO do nó compartilha 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 Node e o primeiro módulo implantado (ZCP), apenas **quatro (4) endereços IP** são necessários. Este design otimiza o uso de IPs, mantendo ainda a conformidade com os padrões 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 nó SO compartilha seu endereço IP com o módulo ZPLS instalado**. Isto é o **apenas cenário** no framework Zoom Node em que um **certificado TLS de um único anfitrião** é válido.

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

* `zplsl.customer.com`

**Mapeamento Funcional do Nome de Host**

| 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 obrigatório)   |

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

**Requisitos do endereço IP**

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

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

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

### <mark style="color:azul;">Decida qual método de gestão de certificados funciona melhor para as suas implantaçõ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) com confiança pública da lista de confiança de certificado do Zoom Node. Isto inclui autoridades públicas bem conhecidas.

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

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

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

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

#### Compreender a Inscrição e Renovação de Certificado da PKI Automática

O cenário seguinte pode ajudá-lo a compreender como funciona a inscrição e renovação de certificado.

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

1. **Recuperação de Modelo**: Faz o pull 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 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`. Esses domínios estão configurados com registros A/AAAA.
4. **Solicitação 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 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 Common Name (CN).
6. **Emissão de certificado**: Envia a Solicitação de Assinatura de Certificado (CSR) para o serviço Auto PKI na Zoom cloud. Este serviço, em seguida, 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 recém-emitido da etapa anterior e a sua chave privada correspondente (gerada anteriormente) no armazenamento local, tornando-os Disponíveis para serviços em execução na instância do Node.

O PKI automático simplifica a gestão de certificados no Zoom Node ao monitorizar 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, 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 isso, o tipo de certificado que escolher deve suportar criptografia para 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 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: Recomendado pela simplicidade**

Um certificado wildcard pode criptografar o tráfego de qualquer hostname no domínio. Por exemplo: um certificado wildcard 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 wildcard, ele criptografará automaticamente o tráfego de 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 wildcard.

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 conhecer os nomes dos serviços se estiver usando o método de certificado multi-SAN.

**Certificados Multi-SAN, Multi-Domínio, SAN ou UCC**

{% hint style="warning" %}
Você deve conhecer os hostnames e endereços IP que usará para o Node (até um \[1]) e quaisquer Serviços que irá instalar (até quatro \[4]).

**Estas 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 requer conhecimento prévio de todas as informações necessárias, incluindo nomes planejados dos Zoom 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 do 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 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 utilize os endereços IP da sua rede.

**Requisitos de Resolução de DNS**

O Zoom requer que os nomes de host sejam publicamente resolvíveis para que a confiança bidirecional possa ser estabelecida. Todos os nomes de host do Zoom Node e todos os nomes de host de serviços implantados nos Nodes 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 que seja resolvível pelos seus servidores de DNS externos (pode ser restrito para 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: 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.