Consideraciones sobre la implementación de hardware

Encuentre instrucciones para implementar el módulo ZPLS de Zoom Node en máquinas virtuales mediante hipervisores compatibles

Esta página describe la implementación del módulo ZPLS de Zoom Node en una máquina virtual utilizando hipervisores compatibles. Proporciona opciones de configuración detalladas adaptadas para acomodar diferentes capacidades de hardware, garantizando un rendimiento óptimo para diversas necesidades operativas.

Hipervisores compatibles

Los clientes deben instalar el software Zoom Node en una máquina virtual que se ejecute en un hipervisor compatible

Como carga de trabajo de Zoom Node, el módulo ZPLS debe instalarse en una máquina virtual que ejecute la plataforma Zoom Node, en un hipervisor compatible. Se puede encontrar más información sobre Zoom Node como producto en el Apéndice.

Los clientes pueden elegir una de dos opciones de configuración, según las capacidades del hardware

El módulo ZPLS admite dos configuraciones, según las capacidades de hardware de la máquina virtual. Estas capacidades se enumeran a continuación:

	Opción de configuración 1	Opción de configuración 2
Especificaciones de hardware	8 CPU 16 GB de RAM 80 GB HDD	16 CPU 16 GB de RAM 80 GB HDD
Registros totales	2000	5000
Máximas llamadas concurrentes	240	480
Llamadas por segundo	2	4
Registros por segundo	60	400

Si el número de endpoints dentro de un sitio con capacidad de supervivencia supera las capacidades de implementación del sitio, el módulo ZPLS procesará los registros por orden de llegada. Se aconseja a los clientes añadir módulos adicionales o utilizar la configuración de políticas de Zoom Phone Modo de supervivencia local para priorizar qué usuarios admiten la conmutación por error de supervivencia.

Escalado y resiliencia del módulo

Los módulos ZPLS admiten agrupación para escalado y/o resiliencia adicionales

Los clientes pueden agrupar módulos ZPLS con hasta 20 módulos por sitio (o 100 dispositivos Node totales por cuenta) para mayor redundancia o escalado.

Esta función está actualmente en beta y requiere la apertura de un ticket de soporte técnico para habilitarse.

El escalado aumenta las capacidades de dispositivos que admite un sitio

Aumentar el número de módulos ZPLS mejora de forma lineal las capacidades de cada sitio por cada módulo adicional. Por ejemplo, si un módulo admite un total de 5 000 registros, desplegar cinco módulos elevará el soporte a 25 000 registros.

La redundancia añade módulos adicionales para resiliencia, pero no escala las capacidades de dispositivos de un sitio

Cuando se utiliza un módulo ZPLS con fines de redundancia, los módulos redundantes no contribuyen al número total de extensiones admitidas. En su lugar, los módulos están en “espera activa” y solo entrarán en funcionamiento si los módulos primarios fallan. Por ejemplo, un módulo primario y uno redundante admiten un total de 5 000 registros; por lo tanto, si un módulo primario falla, el módulo redundante no queda sobresuscrito con dispositivos más allá de su límite admitido.

Ejemplo de implementación de ZPLS con escalado y redundancia

Para mayor comodidad, el siguiente ejemplo muestra una implementación con escalado y redundancia adicionales.

Ejemplo:

Un hospital necesita admitir hasta 10 000 extensiones registradas para supervivencia. Para lograr esto, el hospital está desplegando cuatro módulos ZPLS.

Los dos primeros módulos son capaces de admitir 5 000 registros cada uno, lo que resulta en una capacidad total de hasta 10 000 registros. Sin embargo, reconociendo la importancia de la resiliencia, el hospital también está desplegando dos módulos adicionales como copias de seguridad redundantes de los módulos primarios.

En este escenario, el hospital ahora tiene hardware de supervivencia primario y secundario desplegado. Ahora, si un módulo primario sufre una falla, el/los módulo(s) redundante(s) asumirán el control para mantener el servicio sin interrupciones, continuando con el soporte de hasta 10 000 dispositivos registrados.

Consideraciones de diseño de sitio

Los sitios agrupan a los usuarios de Zoom Phone por ubicación para configuraciones y políticas telefónicas comunes

Un sitio es un término específico utilizado en Zoom Phone que agrupa a los usuarios con características compartidas —como un código de acceso común, dirección, zona SIP, departamento o políticas— en un único grupo gestionable dentro del portal web de Zoom. Para algunos clientes, un único sitio puede representar a todos los usuarios dentro de su empresa y puede abarcar varios edificios dentro de un campus o ubicación; para otros, pueden requerirse varios sitios según las necesidades empresariales. Para obtener más información sobre sitios o la gestión de sitios, consulte el centro de soporte de Zoom.

Zoom Phone admite diseños de sitio único y multi-sitio

Existen dos diseños principales para configurar los sitios de Zoom Phone dentro de una cuenta:

1. Sitio único: Representando a todos los usuarios dentro de una cuenta, potencialmente abarcando varios edificios o ubicaciones, dentro de un único sitio de Zoom Phone.

2. Multi-sitio: Representando segmentos de usuarios por ubicación, edificio, departamento o función por separado, cada uno con su propio sitio.

Los administradores de cuenta de clientes actuales de Zoom pueden comprobar su diseño de sitio actual a través de la Información de la empresa página, disponible en el submenú de Gestión del sistema telefónico menú del portal web.

Cada módulo ZPLS solo puede asociarse a un sitio a la vez

Como se mencionó anteriormente, un módulo ZPLS es el registrador de tercera prioridad para dispositivos compatibles, detrás de las zonas SIP primarias y secundarias. Debido a que los dispositivos reciben sus listas SRV durante el proceso de arranque y estas listas están vinculadas a la configuración de su sitio, cada módulo ZPLS solo puede asociarse a un sitio a la vez.

Cada sitio puede admitir hasta 20 módulos ZPLS simultáneamente

Aunque cada módulo ZPLS solo puede asociarse a un sitio a la vez, un sitio puede admitir hasta 20 módulos ZPLS en un grupo, ampliando las capacidades de supervivencia de cada sitio.

Esta función está actualmente en beta y requiere la apertura de un ticket de soporte técnico para habilitarse.

Los módulos ZPLS admiten llamadas entre sitios si los módulos están conectados a una red común

Los módulos ZPLS de diferentes sitios admiten llamadas entre sitios durante un evento de supervivencia siempre que los dispositivos sean detectables dentro de la red local. Por ejemplo, si un campus empresarial tiene tres edificios, cada uno con su propio sitio telefónico, los módulos ZPLS de cada sitio pueden conectar llamadas sitio a sitio a través de la red de área de campus.

Esta función está actualmente en beta y requiere la apertura de un ticket de soporte técnico para habilitarse.

Antes de desplegar ZPLS, las cuentas deben entender qué configuración de sitio es la más adecuada para sus necesidades

Dado que cada módulo ZPLS solo puede asociarse a un sitio a la vez, el diseño del sitio es uno de los factores más importantes al desplegar el servicio ZPLS dentro de una cuenta. Por esta razón, los clientes deben comprender qué configuración de sitio es la mejor para satisfacer sus necesidades comerciales y de supervivencia prácticas, ya que cada sitio adicional habilitado para supervivencia requerirá al menos un módulo ZPLS adicional.

Un diseño de sitio único es más fácil de gestionar y proporciona supervivencia con un solo módulo ZPLS, pero ofrece menos flexibilidad para las configuraciones y políticas de usuario

Un diseño de sitio único ayuda a simplificar la gestión de las configuraciones y políticas de Zoom Phone consolidando a todos los usuarios dentro de una cuenta bajo un único grupo unificado. Este único grupo de usuarios ofrece a las empresas una administración directa y reduce la complejidad, simplificando el proceso de gestión. Además, un diseño de sitio único puede ofrecer supervivencia telefónica local con un solo módulo ZPLS, siempre que los usuarios del sitio no superen las capacidades de un solo módulo.

Sin embargo, la simplicidad de un diseño de sitio único incluye naturalmente limitaciones. En concreto, los diseños de sitio único ofrecen menos flexibilidad debido a su naturaleza de “talla única”, que puede no ser adecuada para todos los escenarios de implementación entre varios departamentos con necesidades diversas. Además, las implementaciones de sitio único pueden ser vulnerables en ciertos escenarios de supervivencia si la red local falla.

Un diseño multi-sitio ofrece más flexibilidad para las configuraciones y políticas de usuario, pero requiere un módulo ZPLS por cada sitio habilitado para supervivencia y es más complicado de gestionar

Un diseño multi-sitio ofrece a las empresas mayor flexibilidad en las configuraciones y políticas de usuario al separar a los usuarios en varios grupos con controles de configuración granulares. Este diseño permite a las organizaciones ajustar intrincadamente las configuraciones de comunicación para satisfacer requisitos específicos en diversos sitios, lo que resulta en una experiencia de usuario más refinada y adaptable para distintos departamentos, escenarios o necesidades. Además, las implementaciones multi-sitio pueden admitir comunicación entre sitios si los sitios están conectados a través de una red común.

Sin embargo, gestionar un diseño multi-sitio exige una atención cuidadosa a las complejidades de los requisitos únicos de cada sitio, lo que puede requerir un mayor nivel de esfuerzo administrativo. Además, dado que cada módulo ZPLS solo puede asignarse a un sitio a la vez, cada sitio habilitado para supervivencia requerirá un módulo y una licencia ZPLS, lo que puede contribuir a una configuración más intensiva en recursos.

En un diseño multi-sitio, los clientes tienen la flexibilidad de elegir qué sitios se configurarán para la supervivencia. Los sitios sin un módulo ZPLS permanecerá incapaz de realizar o recibir llamadas hasta que se restablezca la conectividad estándar.

Fallas de red

La supervivencia puede verse afectada si la red local de un sitio falla

Aunque los módulos ZPLS están diseñados para proporcionar supervivencia telefónica local durante eventos que afectan el servicio, la supervivencia puede verse afectada si la red local de un sitio falla. Estos escenarios se describen en las dos secciones siguientes.

Fallo de red local en sitio único

En un diseño de sitio único, uno o más edificios están conectados mediante una red local o de campus y están representados por un único sitio dentro de Zoom Phone. Esta configuración asume una red común entre todos los usuarios y edificios dentro de una ubicación, sin dependencias de red externas (por ejemplo, Internet) para la comunicación entre edificios.

Con este diseño de sitio, una empresa puede proporcionar supervivencia local a todos los usuarios dentro de un único sitio o ubicación con tan solo un módulo ZPLS; sin embargo, este diseño es vulnerable en caso de una interrupción de la red local o de campus que afecte la comunicación entre edificios. El siguiente ejemplo describe cómo un fallo de red local puede afectar una implementación de sitio único.

Ejemplo:

Una empresa está desplegando el módulo ZPLS para un único sitio de Zoom Phone, compuesto por los edificios A, B y C, que están conectados mediante una red de área de campus. El módulo ZPLS está operando en el edificio A y está no conectado a un SBC para llamadas externas a través de la RTPC.

En caso de una falla del servicio de Internet externo o de un evento que afecte al servicio, cualquier usuario contenido dentro del sitio puede llamar a otro usuario dentro del mismo sitio, siempre que ambos usuarios mantengan conectividad con el módulo ZPLS a través de la red de área de campus.

Sin embargo, en caso de una interrupción de la red de área de campus, los usuarios dentro de los edificios B y C no pueden realizar llamadas mientras el módulo ZPLS del edificio A sea inalcanzable. En consecuencia, los usuarios dentro de los edificios B y C deben esperar hasta que se restablezca la red de área de campus para realizar llamadas por supervivencia.

La siguiente tabla demuestra la supervivencia de Zoom Phone en un diseño de sitio único con varios edificios:

Llamadas originadas desde el edificio	Pueden alcanzar estas ubicaciones durante una falla externa de Internet	Pueden alcanzar estas ubicaciones durante una falla de la red de campus
Edificio A (Host ZPLS)	☑️ Edificios A, B y C	☑️ Edificio A solo
Edificio B	☑️ Edificios A, B y C	✖️
Edificio C	☑️ Edificios A, B y C	✖️

Fallo de red local multi-sitio sin un SBC

En un diseño multi-sitio, cada edificio o ubicación (por ejemplo, planta, oficina satélite, etc.) está representado de forma independiente por un sitio único dentro de Zoom Phone. Esta configuración asume que cada sitio tiene un módulo ZPLS y que los sitios están conectados mediante una red de área de campus común.

Con este diseño de sitio, cada sitio admite su propio módulo ZPLS, lo que permite a los usuarios dentro del mismo edificio llamarse entre sí cuando se activa el modo de supervivencia. Además, cuando varios sitios con un módulo ZPLS están conectados a través de una red común, los usuarios pueden llamar a usuarios en _otros_sitios, siempre que la red local siga operativa. Sin embargo, este diseño es vulnerable en caso de una interrupción de la red de área de campus que afecte la comunicación entre edificios. El siguiente ejemplo describe cómo una falla de la red de campus puede afectar una implementación multi-sitio.

Ejemplo:

Una empresa está desplegando el módulo ZPLS en su campus de varios edificios, compuesto por los edificios A, B y C. Cada edificio es un sitio único dentro de Zoom Phone y mantiene un módulo ZPLS específico del sitio. Todos los edificios del campus están conectados mediante una red de área de campus que no depende del servicio de Internet externo para las comunicaciones entre edificios.

En este ejemplo, en caso de una falla del servicio de Internet externo, una interrupción de la red del campus o un evento que afecte al servicio, cualquier usuario ubicado dentro de un sitio puede llamar a otro usuario ubicado dentro del mismo sitio. Sin embargo, dado que cada edificio es un sitio único y los usuarios se registran en sus módulos específicos del sitio, si la red del campus falla, los módulos ZPLS no pueden transportar llamadas entre sitios. En su lugar, los usuarios estarán limitados a realizar llamadas a otros usuarios dentro de su sitio local.

La siguiente tabla demuestra la supervivencia de Zoom Phone a partir del ejemplo anterior en un diseño multi-sitio con una red de campus interconectada:

Llamadas originadas desde el edificio	Pueden alcanzar estas ubicaciones durante una falla externa de Internet	Pueden alcanzar estas ubicaciones durante una falla de la red de campus
Edificio A (Host ZPLS)	☑️ Edificios A, B y C	☑️ Edificio A
Edificio B (Host ZPLS)	☑️ Edificio A, B y C	☑️ Edificio B
Edificio C (Host ZPLS)	☑️ Edificio A, B y C	☑️ Edificio C

Si una red local falla, las llamadas entre sitios también se admiten a través de la RTPC, siempre que cada sitio esté conectado a un SBC y tenga el reenvío de llamadas habilitado

En caso de una falla de la red local, los clientes con un diseño multi-sitio que integren el módulo ZPLS con un SBC y conectividad RTPC en cada sitio pueden habilitar las llamadas sitio a sitio si el reenvío de llamadas está habilitado. Cuando está configurado, las llamadas telefónicas realizadas durante el modo de supervivencia se enrutarán desde el cliente del usuario hacia la RTPC, al SBC del segundo sitio y al módulo ZPLS, llegando finalmente al dispositivo del destinatario. El diagrama siguiente proporciona una visión general de esta configuración:

Esta configuración requiere el procesamiento de números de teléfono E.164 en los SBC configurados.

La siguiente tabla también demuestra la supervivencia de Zoom Phone en un diseño multi-sitio con SBC independientes:

Llamadas originadas desde el edificio	Pueden alcanzar estas ubicaciones durante una falla externa de Internet	Pueden alcanzar estas ubicaciones durante una falla de la red de campus
Edificio A (Host ZPLS)	☑️ Edificios A, B y C	☑️ Edificios A, B y C
Edificio B (Host ZPLS)	☑️ Edificios A, B y C	☑️ Edificios A, B y C
Edificio C (Host ZPLS)	☑️ Edificios A, B y C	☑️ Edificios A, B y C

Los usuarios nómadas siempre se registran en el módulo ZPLS asociado con su sitio de origen

Cuando se añaden usuarios o dispositivos a Zoom Phone, un sitio “de origen” se asocia de forma estática con el usuario o dispositivo hasta que un administrador de la cuenta lo actualice. Esto significa que si un usuario se traslada a una ubicación física fuera de su sitio de origen asociado, como un edificio de oficinas asociado a un sitio diferente, Zoom no ajustará dinámicamente el sitio vinculado al usuario. En consecuencia, si el usuario pierde conectividad con los centros de datos de Zoom, intentará registrarse en el módulo ZPLS asociado con su sitio de origen, incluso si se encuentra en una ubicación diferente.

Ejemplo:

Un usuario en un campus multi-sitio tiene su sede en el Edificio A (Sitio A) y se traslada temporalmente al Edificio B (Sitio B) para una reunión. Mientras está en el Edificio B, ocurre un evento que afecta al servicio y se activa el modo de supervivencia. Aunque el usuario está ubicado en el Edificio B, dado que el Sitio A es su sitio de origen, el cliente del usuario intentará conectarse al módulo ZPLS provisionado en su sitio de origen en el edificio A.

En este escenario, el estado de supervivencia de un usuario se determina por la capacidad del dispositivo del usuario para registrarse en el módulo ZPLS dentro de su sitio de origen a través de la red de área de campus. Si la red de área de campus está caída mientras el usuario está fuera de su sitio de origen, el usuario no puede beneficiarse del módulo de supervivencia.