> 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/zoom-workplace/zoom-phone/zoom-phone-local-survivability-field-guide/before-you-begin/hardware-deployment-considerations.md).
# Considerações sobre a implantação de hardware
Esta página descreve a implantação do módulo Zoom Node ZPLS numa 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
#### Os clientes devem instalar o software Zoom Node em uma máquina virtual executada em um hipervisor suportado
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).
#### Os clientes podem escolher uma das duas opções de configuração, dependendo das capacidades de hardware
O módulo ZPLS suporta 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** | 8 CPU
16 GB de RAM
80 GB de HDD
| 16 CPU
16 GB de RAM
80 GB de HDD
|
| **Registros totais** | 2000 | 5000 |
| **Chamadas simultâneas máximas** | 240 | 480 |
| **Chamadas por segundo** | 2 | 4 |
| **Registros por segundo** | 60 | 400 |
{% hint style="info" %}
Se o número de endpoints em uma unidade com suporte a sobrevivência exceder as capacidades de implantação de uma unidade, o módulo ZPLS processará os registros por ordem de chegada. Os clientes são aconselhados a Adicionar módulos adicionais ou usar a configuração de Política do Zoom Phone [**Modo de sobrevivência local**](#_ah8xua8wdq10) para priorizar quais usuários suportam o failover de sobrevivência.
{% endhint %}
### Escalabilidade e resiliência do módulo
#### Os módulos ZPLS suportam clustering para escalabilidade e/ou resiliência adicionais
Os clientes podem agrupar módulos ZPLS com até 20 módulos por unidade (ou 100 dispositivos Node no total por conta) para redundância ou escalabilidade adicionais.
{% hint style="info" %}
Este recurso está atualmente em beta e requer um protocolo do suporte técnico para ser Habilitado.
{% endhint %}
#### A escalabilidade aumenta as capacidades de dispositivos suportadas por uma unidade
Expandir o número de módulos ZPLS aprimora linearmente as capacidades de cada unidade a cada módulo adicional. Por exemplo, se um módulo oferece suporte a um total de 5.000 registros, implantar cinco módulos elevará o suporte para 25.000 registros.
#### A redundância adiciona módulos adicionais para resiliência, mas não amplia as capacidades de dispositivos de uma unidade
Quando um módulo ZPLS é utilizado para fins de redundância, os módulos redundantes não contribuem para o número total de extensões suportadas. Em vez disso, os módulos ficam em “standby quente” e só entrarão em ação se os módulos primários falharem. Por exemplo, um módulo primário e um redundante suportam um total de 5.000 registros, então, se um módulo primário falhar, o módulo redundante não ficará sobrecarregado com dispositivos além de seu limite suportado.
#### Exemplo de implantação do ZPLS com escalabilidade e redundância
Por conveniência, o exemplo a seguir demonstra a implantação com escalabilidade e redundância adicionais.
{% hint style="success" %}
**Exemplo**:
Um hospital precisa oferecer suporte a até 10.000 extensões registradas 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 um, 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 cópias de segurança redundantes para os módulos primários.
Nesse cenário, o hospital agora tem hardware de sobrevivência primário e secundário implantado. Agora, se um módulo primário encontrar uma falha, os módulos redundantes irão assumir o controle para manter o serviço ininterrupto, enquanto continuam a oferecer suporte a até 10.000 dispositivos registrados.
{% endhint %}
### Considerações sobre o design da unidade
#### As unidades agrupam os usuários do Zoom Phone por localização para configurações e políticas comuns de telefonia
A **unidade** é 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 dentro do Portal web do Zoom. Para alguns clientes, uma única unidade pode representar todos os usuários dentro da sua organização corporativa, e pode abranger vários edifícios dentro de um campus ou localização; para outros, múltiplas unidades podem ser necessárias dependendo das necessidades do seu negócio. Para mais informações sobre unidades ou gerenciamento de unidades, [consulte a Central de suporte do Zoom](https://support.zoom.com/hc/en/article?id=zm_kb\&sysparm_article=KB0069716).
#### O Zoom Phone suporta designs de unidade única e de múltiplas unidades
Há dois designs principais para configurar unidades do Zoom Phone em uma conta:
1. **Unidade única**: Representando todos os usuários dentro de uma conta, potencialmente abrangendo vários edifícios ou localizações, dentro de uma única unidade do Zoom Phone.
2. **Múltiplas unidades**: Representando segmentos de usuários por localização, edifício, departamento ou função separadamente, cada um com sua própria unidade.
{% hint style="info" %}
Os administradores da conta dos clientes atuais do Zoom podem verificar o design atual da sua unidade 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 de telefonia** menu no Portal web do Zoom.
{% endhint %}
#### Cada módulo ZPLS só pode ser associado a uma unidade por vez
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 da sua unidade, **cada módulo ZPLS só pode ser associado a uma unidade por vez**.
#### Cada unidade pode suportar até 20 módulos ZPLS simultaneamente
Embora cada módulo ZPLS só possa ser associado a uma unidade por vez, uma unidade pode suportar até 20 módulos ZPLS em um grupo, ampliando as capacidades de sobrevivência de cada unidade.
{% hint style="info" %}
Este recurso está atualmente em beta e requer um protocolo do suporte técnico para ser Habilitado.
{% endhint %}
#### Os módulos ZPLS suportam chamadas entre unidades se os módulos estiverem conectados a uma rede comum
Os módulos ZPLS de diferentes unidades suportam chamadas entre unidades durante um evento de sobrevivência, desde que os dispositivos possam ser descobertos na rede local. Por exemplo, se um campus empresarial tiver três edifícios, cada um com sua própria unidade telefônica, os módulos ZPLS de cada unidade podem conectar chamadas entre unidades pela rede de campus.
{% hint style="info" %}
Este recurso está atualmente em beta e requer um protocolo do suporte técnico para ser Habilitado.
{% endhint %}
#### Antes de implantar o ZPLS, as contas devem entender qual configuração de unidade é mais adequada às suas necessidades
Como cada módulo ZPLS só pode ser associado a uma unidade por vez, o design da unidade é 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 unidade é melhor para atender às suas necessidades práticas de negócio e de sobrevivência, pois cada unidade adicional habilitada para sobrevivência exigirá pelo menos um módulo ZPLS adicional.
#### Um design de unidade única é mais fácil de gerenciar e oferece sobrevivência com um único módulo ZPLS, mas oferece menos flexibilidade para as configurações e políticas dos usuários
Um design de unidade única ajuda a simplificar o gerenciamento das Configurações e políticas do Zoom Phone, consolidando todos os usuários de uma conta em um grupo único e unificado. Esse grupo único de usuários oferece às empresas uma administração simples e menos complexidade, simplificando o processo de gerenciamento. Além disso, um design de unidade única pode oferecer sobrevivência telefônica local com um único módulo ZPLS, desde que os usuários da unidade não excedam a [capacidade de um único módulo](#_rx0i1j9xofnc).
No entanto, a simplicidade de um design de unidade única inclui naturalmente limitações. Especificamente, designs de unidade única oferecem menos flexibilidade devido à sua natureza “tamanho único”, o que pode não ser adequado para todos os cenários de implantação em vários departamentos com necessidades variadas. Além disso, implantações de unidade única podem ser vulneráveis em certos cenários de sobrevivência se a [rede local falhar](#_gzpf5m70jl3i).
#### Um design de múltiplas unidades oferece mais flexibilidade para as configurações e políticas dos usuários, mas exige um módulo ZPLS para cada unidade habilitada para sobrevivência e é mais complicado de gerenciar
Um design de múltiplas unidades oferece às empresas flexibilidade adicional nas configurações e políticas dos usuários, separando os usuários em vários grupos com controles granulares de configuração. Esse design capacita as organizações a ajustar de forma detalhada as configurações de comunicação para atender requisitos específicos em diversas unidades, resultando em uma experiência de usuário mais refinada e adaptável para vários departamentos, cenários ou necessidades. Além disso, implantações de múltiplas unidades podem suportar [comunicação entre unidades](#_a42hwaw1pfmx) se as unidades estiverem conectadas por uma rede comum.
No entanto, gerenciar um design de múltiplas unidades exige atenção cuidadosa às complexidades dos requisitos exclusivos de cada unidade, o que pode exigir um nível mais alto de esforço administrativo. Além disso, como cada módulo ZPLS só pode ser atribuído a uma unidade por vez, cada unidade habilitada para sobrevivência exigirá um módulo ZPLS e uma licença, o que pode contribuir para uma configuração mais intensiva em recursos.
{% hint style="info" %}
Em um design de múltiplas unidades, os clientes têm a flexibilidade de escolher quais unidades serão configuradas para sobrevivência. As unidades *sem* um módulo ZPLS permanecerá sem capacidade de fazer ou receber chamadas até que a conectividade padrão seja restaurada.
{% endhint %}
### Falhas de rede
#### A sobrevivência pode ser afetada se a rede local de uma unidade falhar
Embora os módulos ZPLS tenham sido projetados para oferecer sobrevivência telefônica local durante eventos que impactam o serviço, a sobrevivência pode ser afetada se a rede local de uma unidade falhar. Esses cenários estão descritos nas duas seções a seguir.
#### Falha de rede local em unidade única
Em um design de unidade única, um ou mais edifícios são conectados por uma rede local ou de campus e são representados por uma única unidade no Zoom Phone. Essa configuração pressupõe uma rede comum entre todos os usuários e edifícios dentro de uma localização, sem quaisquer dependências de rede externas (por exemplo, a Internet) para comunicação entre edifícios.
Com esse design de unidade, uma empresa pode fornecer sobrevivência local a todos os usuários dentro de uma única unidade ou localização com apenas um módulo ZPLS; no entanto, esse design é vulnerável no evento de uma interrupção na rede local ou de campus que afete a comunicação entre edifícios. O exemplo a seguir descreve como uma falha de rede local pode afetar uma implantação de unidade única.
{% hint style="success" %}
**Exemplo:**
Uma empresa está implantando o módulo ZPLS para uma única unidade do Zoom Phone, composta pelos edifícios A, B e C, que estão conectados por uma rede de campus. O módulo ZPLS está operando no Edifício A e está **não** conectado a um SBC para chamadas externas pela PSTN.
Em caso de falha externa do serviço de internet ou de um evento que impacte o serviço, qualquer usuário contido na unidade pode ligar para outro usuário dentro da *mesma* unidade, desde que ambos os usuários mantenham conectividade com o módulo ZPLS por meio da rede de campus.
No entanto, no evento de uma interrupção da rede de campus, usuários nos edifícios B e C não podem fazer chamadas enquanto o módulo ZPLS no edifício A estiver inacessível. Consequentemente, os usuários nos edifícios B e C devem aguardar até que a rede de campus seja restaurada para chamadas de sobrevivência.
{% endhint %}
A tabela a seguir demonstra a sobrevivência do Zoom Phone em um design de unidade única com vários edifícios:
| Chamadas originadas do edifício | Podem alcançar estes locais durante uma falha externa da Internet | Podem alcançar estes locais durante uma falha da rede de campus |
| ------------------------------- | ----------------------------------------------------------------- | --------------------------------------------------------------- |
| Edifício A (Anfitrião ZPLS) | ☑️Edifícios A, B e C | ☑️ Edifício A *somente* |
| Edifício B | ☑️Edifícios A, B e C | ✖️ |
| Edifício C | ☑️Edifícios A, B e C | ✖️ |
#### Falha de rede local em múltiplas unidades sem um SBC
Em um design de múltiplas unidades, cada edifício ou localização (por exemplo, andar, escritório satélite etc.) é representado de forma independente por uma unidade exclusiva dentro do Zoom Phone. Essa configuração pressupõe que cada unidade tenha um módulo ZPLS e que as unidades estejam conectadas por uma rede comum de campus.
Com esse design de unidade, cada unidade suporta seu próprio módulo ZPLS, permitindo que os usuários dentro do mesmo edifício se liguem uns aos outros quando o modo de sobrevivência estiver ativado. Além disso, quando várias unidades com um módulo ZPLS estão conectadas por uma rede comum, os usuários podem ligar para usuários em \_outras\_unidades, desde que a rede local permaneça operacional. No entanto, esse design é vulnerável no evento de uma interrupção da rede de campus que afete a comunicação entre edifícios. O exemplo a seguir descreve como uma falha de rede de campus pode afetar uma implantação de múltiplas unidades.
{% hint style="success" %}
**Exemplo:**
Uma empresa está implantando o módulo ZPLS em seu campus com vários edifícios, composto pelos edifícios A, B e C. Cada edifício é uma unidade exclusiva dentro do Zoom Phone e mantém um módulo ZPLS específico da unidade. Todos os edifícios dentro do campus estão conectados por uma rede de campus que não depende de serviço externo de internet para comunicações entre edifícios.
Neste exemplo, em caso de falha de serviço externo de internet, interrupção da rede de campus ou evento que impacte o serviço, qualquer usuário localizado dentro de uma unidade pode ligar para outro usuário localizado dentro da mesma unidade. No entanto, como cada edifício é uma unidade exclusiva e os usuários se registram em seus módulos específicos da unidade, se a rede de campus falhar, os módulos ZPLS não poderão transportar chamadas entre unidades. Em vez disso, os usuários ficarão limitados a fazer chamadas para outros usuários dentro da sua unidade local.
{% endhint %}
A tabela a seguir demonstra a sobrevivência do Zoom Phone no exemplo acima em um design de múltiplas unidades com uma rede de campus interconectada:
| Chamadas originadas do edifício | Podem alcançar estes locais durante uma falha externa da Internet | Podem alcançar estes locais durante uma falha da rede de campus |
| ------------------------------- | ----------------------------------------------------------------- | --------------------------------------------------------------- |
| Edifício A (Anfitrião ZPLS) | ☑️ Edifícios A, B e C | ☑️ Edifício A |
| Edifício B (Anfitrião ZPLS) | ☑️ Edifícios A, B e C | ☑️ Edifício B |
| Edifício C (Anfitrião ZPLS) | ☑️ Edifícios A, B e C | ☑️ Edifício C |
#### Se uma rede local falhar, chamadas entre unidades também são suportadas pela PSTN, desde que cada unidade esteja conectada a um SBC e tenha o encaminhamento de chamadas ativado
No evento de uma falha da rede local, os clientes com um design de múltiplas unidades que integra o módulo ZPLS com um SBC e conectividade PSTN em cada unidade podem habilitar chamadas entre unidades se [o encaminhamento de chamadas estiver ativado](#_2v7qst7vxwaa). Quando configurado, as chamadas telefônicas feitas durante o modo de sobrevivência seguirão do cliente do usuário para a PSTN, para o SBC da segunda unidade e para o módulo ZPLS, chegando por fim ao dispositivo do destinatário. O diagrama a seguir fornece uma visão geral dessa configuração:
{% hint style="danger" %}
Esta 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 de múltiplas unidades com SBCs independentes:
| Chamadas originadas do edifício | Podem alcançar estes locais durante uma falha externa da Internet | Podem alcançar estes locais durante uma falha da rede de campus |
| ------------------------------- | ----------------------------------------------------------------- | --------------------------------------------------------------- |
| Edifício A (Anfitrião ZPLS) | ☑️Edifícios A, B e C | ☑️Edifícios A, B e C |
| Edifício B (Anfitrião ZPLS) | ☑️Edifícios A, B e C | ☑️Edifícios A, B e C |
| Edifício C (Anfitrião ZPLS) | ☑️Edifícios A, B e C | ☑️Edifícios A, B e C |
#### Os usuários nômades sempre se registram no módulo ZPLS associado à sua unidade principal
Quando usuários ou dispositivos são adicionados ao Zoom Phone, uma unidade “principal” é associada estaticamente ao usuário ou dispositivo até que seja atualizada por um administrador da conta. Isso significa que, se um usuário se mudar para uma localização física fora de sua unidade principal associada, como um prédio de escritórios associado a uma unidade diferente, o Zoom não ajustará dinamicamente a unidade vinculada ao usuário. Consequentemente, se o usuário perder a conectividade com os data centers do Zoom Phone, o usuário tentará se registrar no módulo ZPLS associado à sua unidade principal, mesmo que esteja em uma localização diferente.
{% hint style="success" %}
**Exemplo:**
Um usuário em um campus de múltiplas unidades está baseado no Edifício A (Unidade A) e, temporariamente, muda para o Edifício B (Unidade B) para uma reunião. Enquanto está no Edifício B, ocorre um evento que impacta o serviço e o modo de sobrevivência é ativado. Embora o usuário esteja localizado no Edifício B, como a Unidade A é sua unidade principal, o cliente do usuário tentará se conectar ao módulo ZPLS provisionado em sua unidade principal no edifício A.
Nesse cenário, o status de sobrevivência do usuário é determinado pela capacidade do dispositivo do usuário de se registrar no módulo ZPLS dentro da sua unidade principal ao longo da rede de campus. Se a rede de campus estiver fora do ar enquanto o usuário estiver ausente da sua unidade principal, o usuário não poderá se beneficiar do módulo de sobrevivência.
{% endhint %}
---
# 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/zoom-workplace/zoom-phone/zoom-phone-local-survivability-field-guide/before-you-begin/hardware-deployment-considerations.md?ask=&goal=
```
`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.