# Considerações sobre implantação de hardware

Esta página descreve a implantação do módulo Zoom Node ZPLS em uma máquina virtual usando hipervisores suportados. Ela fornece opções de configuração detalhadas adaptadas para acomodar diferentes capacidades de hardware, garantindo desempenho ideal para várias necessidades operacionais.

### Hipervisores suportados

#### <mark style="color:azul;">Os clientes devem instalar o software Zoom Node em uma máquina virtual executando um hipervisor suportado</mark>

Como uma carga de trabalho do Zoom Node, o módulo ZPLS deve ser instalado em uma máquina virtual executando a plataforma Zoom Node, em um [hipervisor suportado](https://support.zoom.us/hc/en-us/articles/8427127286157-Deploying-a-Zoom-Node-management-server). Mais informações sobre o Zoom Node como produto podem ser encontradas [no Apêndice](#_a2lvsihjp0ek).

#### <mark style="color:azul;">Os clientes podem escolher uma de duas opções de configuração, dependendo das capacidades de hardware</mark>

O módulo ZPLS oferece duas configurações, dependendo das capacidades de hardware da máquina virtual. Essas capacidades estão listadas abaixo:

|                                   | Opção de configuração 1                         | Opção de configuração 2                          |
| --------------------------------- | ----------------------------------------------- | ------------------------------------------------ |
| **Especificações de hardware**    | <p>8 CPU</p><p>16 GB de RAM</p><p>80 GB HDD</p> | <p>16 CPU</p><p>16 GB de RAM</p><p>80 GB HDD</p> |
| **Registros totais**              | 2000                                            | 5000                                             |
| **Chamadas concorrentes máximas** | 240                                             | 480                                              |
| **Chamadas por segundo**          | 2                                               | 4                                                |
| **Registros por segundo**         | 60                                              | 400                                              |

{% hint style="info" %}
Se o número de terminais dentro de um site com sobrevivência habilitada exceder as capacidades de implantação do site, o módulo ZPLS processará os registros por ordem de chegada. Recomenda-se que os clientes adicionem módulos adicionais ou usem a configuração de política do Zoom Phone [**Modo de sobrevivência local**](#_ah8xua8wdq10) para priorizar quais usuários recebem suporte ao failover de sobrevivência.
{% endhint %}

### Dimensionamento e resiliência do módulo

#### <mark style="color:azul;">Os módulos ZPLS suportam clustering para dimensionamento adicional e/ou resiliência</mark>

Os clientes podem agrupar módulos ZPLS com até 20 módulos por site (ou 100 dispositivos Node por conta) para redundância ou dimensionamento adicionais.

{% hint style="info" %}
Esse recurso está atualmente em versão beta e requer um ticket de suporte técnico para ser habilitado.
{% endhint %}

#### <mark style="color:azul;">O dimensionamento aumenta as capacidades de dispositivos suportadas por um site</mark>

Aumentar o número de módulos ZPLS amplia linearmente as capacidades de cada site para cada módulo adicional. Por exemplo, se um módulo suporta um total de 5.000 registros, implantar cinco módulos elevará o suporte para 25.000 registros.

#### <mark style="color:azul;">A redundância adiciona módulos adicionais para resiliência, mas não amplia as capacidades de dispositivos de um site</mark>

Quando um módulo ZPLS é utilizado para fins de redundância, os módulos redundantes não contribuem para o número total de ramais suportados. Em vez disso, os módulos ficam em “standby quente” e só entram em ação se os módulos primários falharem. Por exemplo, um módulo primário e um módulo redundante suportam um total de 5.000 registros; portanto, se um módulo primário falhar, o módulo redundante não fica sobrecarregado com dispositivos além do seu limite suportado.

#### <mark style="color:azul;">Exemplo de implantação do ZPLS com dimensionamento e redundância</mark>

Para maior conveniência, o exemplo a seguir demonstra a implantação com dimensionamento e redundância adicionais.

{% hint style="success" %}
**Exemplo**:&#x20;

Um hospital precisa suportar até 10.000 ramais registrados para sobrevivência. Para isso, o hospital está implantando quatro módulos ZPLS.

Os dois primeiros módulos são capazes de suportar 5.000 registros cada, resultando em uma capacidade total de até 10.000 registros. No entanto, reconhecendo a importância da resiliência, o hospital também está implantando dois módulos adicionais como backups redundantes para os módulos primários.

Nesse cenário, o hospital agora possui hardware de sobrevivência primário e secundário implantado. Assim, se um módulo primário sofrer uma falha, o(s) módulo(s) redundante(s) assumirá(ão) para manter o serviço ininterrupto, continuando a suportar até 10.000 dispositivos registrados.
{% endhint %}

### Considerações sobre o projeto do site

#### <mark style="color:azul;">Os sites agrupam os usuários do Zoom Phone por local para configurações e políticas de telefonia comuns</mark>

Um **site** é um termo específico usado no Zoom Phone que agrupa usuários com características compartilhadas — como um código de acesso comum, endereço, zona SIP, departamento ou políticas — em um único grupo gerenciável no portal web do Zoom. Para alguns clientes, um único site pode representar todos os usuários dentro de sua empresa e pode abranger vários prédios em um campus ou local; para outros, vários sites podem ser necessários, dependendo das necessidades do seu negócio. Para mais informações sobre sites ou gerenciamento de sites, [consulte o centro de suporte da Zoom](https://support.zoom.com/hc/en/article?id=zm_kb\&sysparm_article=KB0069716).

#### <mark style="color:azul;">O Zoom Phone suporta designs de site único e multi-site</mark>

Existem dois designs principais para configurar sites do Zoom Phone dentro de uma conta:

1. **Site único**: Representando todos os usuários dentro de uma conta, potencialmente abrangendo vários prédios ou locais, dentro de um único site do Zoom Phone.
2. **Multi-site**: Representando segmentos de usuários por local, prédio, departamento ou função separadamente, cada um com seu próprio site.

<div data-with-frame="true"><img src="https://content.gitbook.com/content/ctBXUMeBy4rtLMmMkKRG/blobs/oIvxHDcxrmw7DhWRyObf/Unknown%20image" alt=""></div>

{% hint style="info" %}
Os administradores da conta de clientes atuais do Zoom podem verificar seu design de site atual por meio da [**Informações da Empresa**](https://zoom.us/pbx/page/telephone/settings#/settings/multi-sites?page_number=1\&page_size=15\&keyword=) página, disponível no **Gerenciamento do Sistema Telefônico** menu do portal web.
{% endhint %}

#### <mark style="color:azul;">Cada módulo ZPLS só pode ser associado a um site por vez</mark>

Como mencionado anteriormente, um módulo ZPLS é o [registrador de terceira prioridade](#_7itj40mx1dut) para dispositivos suportados, atrás das zonas SIP primária e secundária. Como os dispositivos recebem suas listas SRV durante o processo de inicialização e essas listas estão vinculadas à configuração do site, **cada módulo ZPLS só pode ser associado a um site por vez**.

#### <mark style="color:azul;">Cada site pode suportar até 20 módulos ZPLS simultaneamente</mark>

Embora cada módulo ZPLS só possa ser associado a um site por vez, um site pode suportar até 20 módulos ZPLS em um grupo, expandindo as capacidades de sobrevivência de cada site.

{% hint style="info" %}
Esse recurso está atualmente em versão beta e requer um ticket de suporte técnico para ser habilitado.
{% endhint %}

#### <mark style="color:azul;">Os módulos ZPLS suportam chamadas entre sites se os módulos estiverem conectados a uma rede comum</mark>

Os módulos ZPLS de diferentes sites suportam chamadas entre sites durante um evento de sobrevivência desde que os dispositivos sejam detectáveis dentro da rede local. Por exemplo, se um campus empresarial possui três prédios, cada um com seu próprio site telefônico, os módulos ZPLS de cada site podem conectar chamadas site-a-site pela rede de campus.

{% hint style="info" %}
Esse recurso está atualmente em versão beta e requer um ticket de suporte técnico para ser habilitado.
{% endhint %}

#### <mark style="color:azul;">Antes de implantar o ZPLS, as contas devem entender qual configuração de site é mais adequada às suas necessidades</mark>

Como cada módulo ZPLS só pode ser associado a um site por vez, o design do site é um dos fatores mais importantes ao implantar o serviço ZPLS em uma conta. Por esse motivo, os clientes devem entender qual configuração de site é melhor para atender às suas necessidades práticas de negócios e de sobrevivência, já que cada site adicional habilitado para sobrevivência exigirá pelo menos mais um módulo ZPLS.

#### <mark style="color:azul;">Um design de site único é mais fácil de gerenciar e fornece sobrevivência com um único módulo ZPLS, mas oferece menos flexibilidade para configurações e políticas de usuário</mark>

Um design de site único ajuda a simplificar o gerenciamento das configurações e políticas do Zoom Phone, consolidando todos os usuários de uma conta em um único grupo unificado. Esse único grupo de usuários oferece às empresas administração direta e complexidade reduzida, simplificando o processo de gerenciamento. Além disso, um design de site único pode oferecer sobrevivência telefônica local com um único módulo ZPLS, desde que os usuários do site não excedam as [capacidades de um único módulo](#_rx0i1j9xofnc).

No entanto, a simplicidade de um design de site único naturalmente inclui limitações. Especificamente, designs de site único oferecem menos flexibilidade devido à sua natureza “tamanho único”, o que pode não atender a todos os cenários de implantação em vários departamentos com necessidades variadas. Além disso, implantações de site único podem ser vulneráveis em certos cenários de sobrevivência se a [rede local falhar](#_gzpf5m70jl3i).

#### <mark style="color:azul;">Um design multi-site oferece mais flexibilidade para configurações e políticas de usuário, mas requer um módulo ZPLS para cada site habilitado para sobrevivência e é mais complicado de gerenciar</mark>

Um design multi-site oferece às empresas flexibilidade adicional nas configurações e políticas de usuário ao separar os usuários em vários grupos com controles granulares de configuração. Esse design permite que as organizações ajustem detalhadamente as configurações de comunicação para atender a requisitos específicos em diversos sites, resultando em uma experiência de usuário mais refinada e adaptável para diferentes departamentos, cenários ou necessidades. Além disso, implantações multi-site podem suportar [comunicação entre sites](#_a42hwaw1pfmx) se os sites estiverem conectados por uma rede comum.

No entanto, gerenciar um design multi-site exige atenção cuidadosa às particularidades de cada site, o que pode requerer um nível maior de esforço administrativo. Além disso, como cada módulo ZPLS só pode ser designado a um site por vez, cada site habilitado para sobrevivência exigirá um módulo e licença ZPLS, o que pode contribuir para uma configuração mais intensiva em recursos.

{% hint style="info" %}
Em um design multi-site, os clientes têm a flexibilidade de escolher quais sites serão configurados para sobrevivência. Os sites *sem* um módulo ZPLS permanecerá incapaz de efetuar ou receber chamadas até que a conectividade padrão seja restaurada.
{% endhint %}

### Falhas de rede

#### <mark style="color:azul;">A sobrevivência pode ser afetada se a rede local de um site falhar</mark>

Embora os módulos ZPLS sejam projetados para fornecer sobrevivência telefônica local durante eventos que impactem o serviço, a sobrevivência pode ser afetada se a rede local de um site falhar. Esses cenários são descritos nas duas seções a seguir.

#### <mark style="color:azul;">Falha de rede local em site único</mark>

Em um design de site único, um ou mais prédios estão conectados por uma rede local ou de campus e são representados por um único site no Zoom Phone. Essa configuração pressupõe uma rede comum entre todos os usuários e prédios dentro de um local, sem dependências de rede externa (por exemplo, a Internet) para comunicação entre prédios.

Com esse design de site, uma empresa pode fornecer sobrevivência local a todos os usuários dentro de um único site ou local com apenas um módulo ZPLS; no entanto, esse design é vulnerável no caso de uma interrupção da rede local ou do campus que afete a comunicação entre prédios. O exemplo a seguir descreve como uma falha de rede local pode afetar uma implantação de site único.

<div data-with-frame="true"><img src="https://content.gitbook.com/content/ctBXUMeBy4rtLMmMkKRG/blobs/Ri12tqNIQd9vtbMpNzqe/Unknown%20image" alt=""></div>

{% hint style="success" %}
**Exemplo:**

Uma empresa está implantando o módulo ZPLS para um único site do Zoom Phone, composto pelos prédios A, B e C, que estão conectados por uma rede de campus. O módulo ZPLS está operando no Prédio A e está **não** conectado a um SBC para chamadas externas através da PSTN.

No caso de uma falha no serviço de internet externa ou de um evento que impacte o serviço, qualquer usuário contido no site pode ligar para outro usuário dentro do *mesmo* site, desde que ambos os usuários mantenham conectividade com o módulo ZPLS através da rede de campus.

No entanto, no caso de uma interrupção da rede de campus, os usuários nos prédios B e C não conseguem realizar chamadas enquanto o módulo ZPLS no Prédio A estiver inacessível. Consequentemente, os usuários nos prédios B e C devem aguardar até que a rede de campus seja restabelecida para realizar chamadas de sobrevivência.
{% endhint %}

A tabela a seguir demonstra a sobrevivência do Zoom Phone em um design de site único em vários prédios:

| Chamadas originadas do prédio | Podem alcançar estes locais durante uma falha da Internet externa | Podem alcançar estes locais durante uma falha na rede do campus |
| ----------------------------- | ----------------------------------------------------------------- | --------------------------------------------------------------- |
| Prédio A (Host ZPLS)          | ☑️Prédios A, B e C                                                | ☑️ Prédio A *apenas*                                            |
| Prédio B                      | ☑️Prédios A, B e C                                                | ✖️                                                              |
| Prédio C                      | ☑️Prédios A, B e C                                                | ✖️                                                              |

#### <mark style="color:azul;">Falha de rede local multi-site sem um SBC</mark>

Em um design multi-site, cada prédio ou local (por exemplo, andar, escritório satélite etc.) é representado de forma independente por um site único no Zoom Phone. Essa configuração pressupõe que cada site tenha um módulo ZPLS e que os sites estejam conectados por uma rede de campus comum.

Com esse design de site, cada site suporta seu próprio módulo ZPLS, permitindo que os usuários dentro do mesmo prédio se comuniquem quando o modo de sobrevivência é ativado. Além disso, quando vários sites com um módulo ZPLS estão conectados por uma rede comum, os usuários podem ligar para usuários em \_outros\_sites\_, desde que a rede local permaneça operacional. No entanto, esse design é vulnerável no caso de uma interrupção da rede de campus que afete a comunicação entre prédios. O exemplo a seguir descreve como uma falha na rede do campus pode afetar uma implantação multi-site.

<div data-with-frame="true"><img src="https://content.gitbook.com/content/ctBXUMeBy4rtLMmMkKRG/blobs/YleKIF0uXoN12c2dmNNB/Unknown%20image" alt=""></div>

{% hint style="success" %}
**Exemplo:**

Uma empresa está implantando o módulo ZPLS em seu campus com vários prédios, composto pelos prédios A, B e C. Cada prédio é um site único no Zoom Phone e mantém um módulo ZPLS específico para o site. Todos os prédios do campus estão conectados por uma rede de campus que não depende do serviço de internet externo para comunicações entre prédios.

Neste exemplo, no caso de uma falha no serviço de internet externa, interrupção da rede do campus ou evento que impacte o serviço, qualquer usuário localizado em um site pode ligar para outro usuário localizado no mesmo site. No entanto, como cada prédio é um site único e os usuários registram-se nos módulos específicos de seu site, se a rede do campus falhar, os módulos ZPLS não poderão transportar chamadas entre sites. Em vez disso, os usuários ficarão limitados a realizar chamadas para outros usuários dentro de seu site local.
{% endhint %}

A tabela a seguir demonstra a sobrevivência do Zoom Phone do exemplo acima em um design multi-site com uma rede de campus interconectada:

| Chamadas originadas do prédio | Podem alcançar estes locais durante uma falha da Internet externa | Podem alcançar estes locais durante uma falha na rede do campus |
| ----------------------------- | ----------------------------------------------------------------- | --------------------------------------------------------------- |
| Prédio A (Host ZPLS)          | ☑️ Prédios A, B e C                                               | ☑️ Prédio A                                                     |
| Prédio B (Host ZPLS)          | ☑️ Prédio A, B e C                                                | ☑️ Prédio B                                                     |
| Prédio C (Host ZPLS)          | ☑️ Prédio A, B e C                                                | ☑️ Prédio C                                                     |

#### <mark style="color:azul;">Se uma rede local falhar, a chamada entre sites também é suportada pela PSTN, desde que cada site esteja conectado a um SBC e tenha o encaminhamento de chamadas habilitado</mark>

No caso de uma falha de rede local, clientes com um design multi-site que integrem o módulo ZPLS com um SBC e conectividade PSTN em cada site podem habilitar chamadas site-a-site se [o encaminhamento de chamadas estiver habilitado](#_2v7qst7vxwaa). Quando configurado, as chamadas telefônicas realizadas durante o modo de sobrevivência serão roteadas do cliente do usuário para a PSTN, para o SBC do segundo site e para o módulo ZPLS, finalmente chegando ao dispositivo do destinatário. O diagrama a seguir fornece uma visão geral dessa configuração:

<div data-with-frame="true"><img src="https://content.gitbook.com/content/ctBXUMeBy4rtLMmMkKRG/blobs/TxOX1dZyselC2SFLiXSu/Unknown%20image" alt=""></div>

{% hint style="danger" %}
Essa configuração **requer** processamento de número de telefone E.164 nos SBCs configurados.
{% endhint %}

A tabela a seguir também demonstra a sobrevivência do Zoom Phone em um design multi-site com SBCs independentes:

| Chamadas originadas do prédio | Podem alcançar estes locais durante uma falha da Internet externa | Podem alcançar estes locais durante uma falha na rede do campus |
| ----------------------------- | ----------------------------------------------------------------- | --------------------------------------------------------------- |
| Prédio A (Host ZPLS)          | ☑️Prédios A, B e C                                                | ☑️Prédios A, B e C                                              |
| Prédio B (Host ZPLS)          | ☑️Prédios A, B e C                                                | ☑️Prédios A, B e C                                              |
| Prédio C (Host ZPLS)          | ☑️Prédios A, B e C                                                | ☑️Prédios A, B e C                                              |

#### <mark style="color:azul;">Usuários nômades sempre se registram no módulo ZPLS associado ao seu site de origem</mark>

Quando usuários ou dispositivos são adicionados ao Zoom Phone, um site “de origem” é associado estaticamente ao usuário ou dispositivo até ser atualizado por um administrador da conta. Isso significa que se um usuário se deslocar para uma localização física fora do seu site de origem, como um prédio de escritórios associado a um site diferente, o Zoom não ajustará dinamicamente o site vinculado ao usuário. Consequentemente, se o usuário perder conectividade com os data centers do Zoom Phone, o usuário tentará se registrar no módulo ZPLS associado ao seu site de origem, mesmo que esteja em outro local.

{% hint style="success" %}
**Exemplo:**

Um usuário em um campus multi-site tem sua base no Prédio A (Site A) e se desloca temporariamente para o Prédio B (Site B) para uma reunião. Enquanto estiver no Prédio B, ocorre um evento que impacta o serviço e o modo de sobrevivência é ativado. Embora o usuário esteja localizado no Prédio B, como o Site A é seu site de origem, o cliente do usuário tentará conectar-se ao módulo ZPLS provisionado em seu site de origem no Prédio A.

Nesse cenário, o status de sobrevivência de um usuário é determinado pela capacidade do dispositivo do usuário em se registrar no módulo ZPLS dentro do seu site de origem através da rede de campus. Se a rede de campus estiver fora do ar enquanto o usuário estiver fora do seu site de origem, o usuário não poderá se beneficiar do módulo de sobrevivência.
{% endhint %}