> 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 implantação de hardware Esta página descreve a implementação do módulo Zoom Node ZPLS numa máquina virtual usando hipervisores suportados. 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 numa máquina virtual em execução num hipervisor suportado Como uma carga de trabalho do Zoom Node, o módulo ZPLS deve ser instalado numa máquina virtual em execução na plataforma Zoom Node, num [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 de 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

| | **Registos totais** | 2000 | 5000 | | **Máximo de chamadas simultâneas** | 240 | 480 | | **Chamadas por segundo** | 2 | 4 | | **Registos por segundo** | 60 | 400 | {% hint style="info" %} Se o número de endpoints numa unidade com sobrevivência ativada exceder as capacidades de implementação da unidade, o módulo ZPLS processará os registos por ordem de chegada. Recomenda-se que os clientes adicionem módulos adicionais ou usem a definição da Política do Zoom Phone [**Modo de sobrevivência local**](#_ah8xua8wdq10) para priorizar quais usuários suportam a redundância de sobrevivência. {% endhint %} ### Escalonamento e resiliência do módulo #### Os módulos ZPLS suportam clustering para escalonamento adicional e/ou resiliência 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 escalonamento adicionais. {% hint style="info" %} Esta funcionalidade está atualmente em beta e requer um protocolo do suporte técnico para ser ativada. {% endhint %} #### O escalonamento aumenta as capacidades de dispositivos suportadas de uma unidade Expandir o número de módulos ZPLS melhora as capacidades de cada unidade linearmente para cada módulo adicional. Por exemplo, se um módulo suporta um total de 5.000 registos, implementar cinco módulos elevará o suporte para 25.000 registos. #### A redundância adiciona módulos adicionais para resiliência, mas não escala 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 “hot standby” e só entram 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 registos, portanto, se um módulo primário falhar, o módulo redundante não fica sobrecarregado com dispositivos para além do seu limite suportado. #### Exemplo de implementação do ZPLS com escalonamento e redundância Para conveniência, o exemplo seguinte demonstra a implementação com escalonamento e redundância adicionais. {% hint style="success" %} **Exemplo**: Um hospital precisa de suportar até 10.000 extensões registadas para sobrevivência. Para conseguir isso, o hospital está a implementar quatro módulos ZPLS. Os dois primeiros módulos são capazes de suportar 5.000 registos cada, resultando numa capacidade total de até 10.000 registos. No entanto, reconhecendo a importância da resiliência, o hospital também está a implementar dois módulos adicionais como backups redundantes dos módulos primários. Neste cenário, o hospital tem agora hardware de sobrevivência primário e secundário implementado. Agora, se um módulo primário sofrer uma falha, o(s) módulo(s) redundante(s) assumirá(ão) o controlo para manter o serviço ininterrupto, continuando a suportar até 10.000 dispositivos registados. {% endhint %} ### Considerações de design da unidade #### As unidades agrupam usuários do Zoom Phone por localização para definições e políticas comuns de telefonia A **unidade** é um termo específico usado no Zoom Phone que agrupa usuários com características partilhadas — como um código de acesso comum, endereço, zona SIP, departamento ou políticas — num único grupo gerível dentro do Portal web do Zoom. Para alguns clientes, uma única unidade pode representar todos os usuários dentro do seu negócio e pode abranger vários edifícios num campus ou localização; para outros, podem ser necessárias múltiplas unidades, dependendo das necessidades do seu negócio. Para mais informações sobre unidades ou gestão 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 multiunidade Existem dois designs principais para configurar unidades do Zoom Phone dentro de uma conta: 1. **Unidade única**: Representa 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. **Multiunidade**: Representa segmentos de usuários por localização, edifício, departamento ou função separadamente, cada um com a sua própria unidade.
{% hint style="info" %} Os administradores da conta de clientes atuais do Zoom podem verificar o design atual da sua unidade através 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 **Gestão do sistema de telefonia** menu no portal web. {% endhint %} #### Cada módulo ZPLS só pode ser associado a uma unidade de cada 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 as suas listas SRV durante o processo de arranque e essas listas estão associadas à definição da sua unidade, **cada módulo ZPLS só pode ser associado a uma unidade de cada vez**. #### Cada unidade pode suportar até 20 módulos ZPLS em simultâneo Embora cada módulo ZPLS só possa ser associado a uma unidade de cada vez, uma unidade pode suportar até 20 módulos ZPLS num único grupo, ampliando as capacidades de sobrevivência de cada unidade. {% hint style="info" %} Esta funcionalidade está atualmente em beta e requer um protocolo do suporte técnico para ser ativada. {% endhint %} #### Os módulos ZPLS suportam chamadas entre unidades se os módulos estiverem ligados 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 sejam detetáveis dentro da rede local. Por exemplo, se um campus empresarial tiver três edifícios, cada um com a sua própria unidade telefónica, os módulos ZPLS de cada unidade podem estabelecer chamadas entre unidades pela rede da área do campus. {% hint style="info" %} Esta funcionalidade está atualmente em beta e requer um protocolo do suporte técnico para ser ativada. {% endhint %} #### Antes de implementar o ZPLS, as contas devem compreender qual configuração de unidade se adequa melhor às suas necessidades Como cada módulo ZPLS só pode ser associado a uma unidade de cada vez, o design da unidade é um dos fatores mais importantes ao implementar o serviço ZPLS dentro de uma conta. Por esta razão, os clientes devem compreender qual configuração de unidade é melhor para satisfazer as suas necessidades práticas de negócio e sobrevivência, uma vez que cada unidade adicional ativada para sobrevivência exigirá pelo menos um módulo ZPLS adicional. #### Um design de unidade única é mais fácil de gerir e fornece sobrevivência com um único módulo ZPLS, mas oferece menos flexibilidade para definições e políticas de usuário Um design de unidade única ajuda a simplificar a gestão das definições e políticas do Zoom Phone, consolidando todos os usuários dentro de uma conta sob um único grupo unificado. Este grupo único de usuários oferece às empresas uma administração direta e menor complexidade, simplificando o processo de gestão. 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 as [capacidades 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 implementação em vários departamentos com necessidades variáveis. Além disso, implementações de unidade única podem ser vulneráveis em certos cenários de sobrevivência se a [rede local falhar](#_gzpf5m70jl3i). #### Um design multiunidade oferece mais flexibilidade para definições e políticas de usuário, mas requer um módulo ZPLS para cada unidade com sobrevivência ativada e é mais complicado de gerir Um design multiunidade oferece às empresas flexibilidade adicional em definições e políticas de usuário, separando os usuários em vários grupos com controlos granulares de definições. Este design capacita as organizações a ajustar intrincadamente as configurações de comunicação para satisfazer requisitos específicos em diversas unidades, resultando numa experiência de usuário mais refinada e adaptável para vários departamentos, cenários ou necessidades. Além disso, implementações multiunidade podem suportar [comunicação entre unidades](#_a42hwaw1pfmx) se as unidades estiverem ligadas através de uma rede comum. No entanto, gerir um design multiunidade exige atenção cuidadosa às particularidades dos requisitos únicos de cada unidade, o que pode exigir um nível mais elevado de esforço administrativo. Além disso, como cada módulo ZPLS só pode ser atribuído a uma unidade de cada vez, cada unidade com sobrevivência ativada exigirá um módulo ZPLS e uma licença, o que pode contribuir para uma configuração mais intensiva em recursos. {% hint style="info" %} Num design multiunidade, os clientes têm a flexibilidade de escolher quais unidades serão configuradas para sobrevivência. As unidades *sem* um módulo ZPLS permanecerá incapaz 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 sejam concebidos para fornecer sobrevivência telefónica local durante eventos que afetam 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 secções seguintes. #### Falha de rede local de unidade única Num design de unidade única, um ou mais edifícios estão ligados através de uma rede local ou de campus e são representados por uma única unidade dentro do Zoom Phone. Esta 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 este 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, este design é vulnerável no caso de uma interrupção de rede local ou de campus que afete a comunicação entre edifícios. O exemplo seguinte descreve como uma falha de rede local pode afetar uma implementação de unidade única.
{% hint style="success" %} **Exemplo:** Uma empresa está a implementar o módulo ZPLS para uma única unidade do Zoom Phone, composta pelos edifícios A, B e C, ligados através de uma rede da área do campus. O módulo ZPLS está a funcionar no Edifício A e está **não** ligado a um SBC para chamadas externas através da PSTN. No caso de uma falha externa do serviço de Internet ou de um evento que afete o serviço, qualquer usuário incluído 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 através da rede da área do campus. No entanto, no caso de uma interrupção da rede da área do campus, os usuários dos 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 dos edifícios B e C têm de esperar até que a rede da área do campus seja restaurada para realizar chamadas de sobrevivência. {% endhint %} A tabela seguinte demonstra a sobrevivência do Zoom Phone num design de unidade única com vários edifícios: | Chamadas originadas a partir do edifício | Podem alcançar estas localizações durante uma falha externa da Internet | Podem alcançar estas localizações durante uma falha da rede do campus | | ---------------------------------------- | ----------------------------------------------------------------------- | --------------------------------------------------------------------- | | Edifício A (anfitrião ZPLS) | ☑️Edifícios A, B e C | ☑️ Edifício A *apenas* | | Edifício B | ☑️Edifícios A, B e C | ✖️ | | Edifício C | ☑️Edifícios A, B e C | ✖️ | #### Falha de rede local multiunidade sem um SBC Num design multiunidade, cada edifício ou localização (por exemplo, piso, escritório satélite, etc.) é representado independentemente por uma unidade única dentro do Zoom Phone. Esta configuração pressupõe que cada unidade tem um módulo ZPLS e que as unidades estão ligadas através de uma rede comum da área do campus. Com este design de unidade, cada unidade suporta o seu próprio módulo ZPLS, permitindo que os usuários dentro do mesmo edifício liguem uns aos outros quando o modo de sobrevivência está ativado. Além disso, quando várias unidades com um módulo ZPLS estão ligadas através de uma rede comum, os usuários podem ligar para usuários em \_outras\_unidades, desde que a rede local permaneça operacional. No entanto, este design é vulnerável no caso de uma interrupção da rede da área do campus que afete a comunicação entre edifícios. O exemplo seguinte descreve como uma falha de rede do campus pode afetar uma implementação multiunidade.
{% hint style="success" %} **Exemplo:** Uma empresa está a implementar o módulo ZPLS no seu campus com vários edifícios, composto pelos edifícios A, B e C. Cada edifício é uma unidade única dentro do Zoom Phone e mantém um módulo ZPLS específico da unidade. Todos os edifícios dentro do campus estão ligados através de uma rede da área do campus que não depende do serviço externo de Internet para comunicações entre edifícios. Neste exemplo, no caso de uma falha externa do serviço de Internet, uma interrupção da rede do campus ou um evento que afete 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 única e os usuários registam-se nos seus módulos específicos da unidade, se a rede do campus falhar, os módulos ZPLS não podem 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 seguinte demonstra a sobrevivência do Zoom Phone no exemplo acima num design multiunidade com uma rede de campus interligada: | Chamadas originadas a partir do edifício | Podem alcançar estas localizações durante uma falha externa da Internet | Podem alcançar estas localizações durante uma falha da rede do 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, as chamadas entre unidades também são suportadas através da PSTN, desde que cada unidade esteja ligada a um SBC e tenha o reencaminhamento de chamadas ativado No caso de uma falha da rede local, os clientes com um design multiunidade que integra o módulo ZPLS com um SBC e conectividade PSTN em cada unidade podem ativar chamadas entre unidades se [o reencaminhamento de chamadas estiver ativado](#_2v7qst7vxwaa). Quando configurado, as chamadas telefónicas efetuadas durante o modo de sobrevivência serão encaminhadas do cliente do usuário para a PSTN, para o SBC e o módulo ZPLS da segunda unidade, chegando finalmente ao dispositivo do destinatário. O diagrama seguinte fornece uma visão geral desta configuração:
{% hint style="danger" %} Esta configuração **requer** processamento de números de telefone E.164 nos SBCs configurados. {% endhint %} A tabela seguinte também demonstra a sobrevivência do Zoom Phone num design multiunidade com SBCs independentes: | Chamadas originadas a partir do edifício | Podem alcançar estas localizações durante uma falha externa da Internet | Podem alcançar estas localizações durante uma falha da rede do 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ómadas registam-se sempre no módulo ZPLS associado à sua unidade de origem Quando os usuários ou dispositivos são adicionados ao Zoom Phone, uma unidade “de origem” é associada estaticamente ao usuário ou dispositivo até ser atualizada por um administrador da conta. Isto significa que, se um usuário se deslocar para uma localização física fora da sua unidade de origem associada, como um edifício de escritórios associado a uma unidade diferente, o Zoom não ajustará dinamicamente a unidade associada ao usuário. Consequentemente, se o usuário perder a conectividade com os centros de dados do Zoom Phone, o usuário tentará registar-se no módulo ZPLS associado à sua unidade de origem, mesmo que esteja numa localização diferente. {% hint style="success" %} **Exemplo:** Um usuário num campus multiunidade está baseado no Edifício A (Unidade A) e desloca-se temporariamente para o Edifício B (Unidade B) para uma reunião. Enquanto está no Edifício B, ocorre um evento que afeta o serviço e o modo de sobrevivência é ativado. Embora o usuário esteja localizado no Edifício B, como a Unidade A é a sua unidade de origem, o cliente do usuário tentará ligar-se ao módulo ZPLS provisionado na sua unidade de origem no edifício A. Neste cenário, o estado de sobrevivência de um usuário é determinado pela capacidade do dispositivo do usuário de registar-se no módulo ZPLS na sua unidade de origem através da rede da área do campus. Se a rede da área do campus estiver em baixo enquanto o usuário estiver longe da sua unidade de origem, o usuário não pode 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.