Consideraciones para el despliegue de hardware

Encuentre instrucciones para desplegar el módulo ZPLS de Zoom Node en máquinas virtuales usando 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. 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, dependiendo de 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
Llamadas concurrentes máximas	240	480
Llamadas por segundo	2	4
Registros por segundo	45	90

Si el número de terminales dentro de un sitio habilitado para supervivencia supera las capacidades de implementación del sitio, el módulo ZPLS procesará los registros por orden de llegada. Se recomienda a los clientes agregar módulos adicionales o utilizar la configuración de la política de Zoom Phone Modo de supervivencia local para priorizar qué usuarios admiten el conmutador por fallo de supervivencia.

Escalado y resiliencia del módulo

Los módulos ZPLS admiten agrupamiento para mayor escalado y/o resiliencia

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

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

El escalado aumenta las capacidades de dispositivos soportadas por un sitio

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

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

Cuando un módulo ZPLS se utiliza 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 caliente" y solo entrarán en funcionamiento si fallan los módulos primarios. 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 demuestra la implementación con escalado adicional y redundancia.

Ejemplo:

Un hospital debe 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 soportar 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. Si un módulo primario sufre una falla, el/los módulo(s) redundantes tomarán el control para mantener el servicio ininterrumpido, continuando a la vez con el soporte de hasta 10 000 dispositivos registrados.

Consideraciones de diseño del 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 dentro de 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 solo grupo manejable dentro del portal web de Zoom. Para algunos clientes, un único sitio puede representar a todos los usuarios dentro de su negocio y puede abarcar varios edificios dentro de un campus o ubicación; para otros, pueden requerirse múltiples sitios según sus necesidades comerciales. Para 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

Hay 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, abarcando potencialmente varios edificios o ubicaciones, dentro de un solo 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 los 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 Administración del sistema telefónico menú del portal web.

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

Como se mencionó anteriormente, un módulo ZPLS es el registrador de tercera prioridad para los dispositivos compatibles, por detrás de las zonas SIP primaria y secundaria. 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 con un sitio a la vez.

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

Aunque cada módulo ZPLS solo puede asociarse con 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 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 del campus.

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

Antes de desplegar ZPLS, las cuentas deben entender qué configuración de sitio se adapta mejor a sus necesidades

Dado que cada módulo ZPLS solo puede asociarse con un sitio a la vez, el diseño del sitio es uno de los factores más importantes al implementar 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 al consolidar a todos los usuarios de una cuenta bajo un único grupo unificado. Este único grupo de usuarios ofrece a las empresas una administración sencilla y una menor complejidad, simplificando el proceso de gestión. Además, un diseño de sitio único puede ofrecer supervivencia telefónica local con un único módulo ZPLS, siempre que los usuarios del sitio no excedan las capacidades de un único módulo.

Sin embargo, la simplicidad de un diseño de sitio único incluye naturalmente limitaciones. Específicamente, los diseños de sitio único ofrecen menos flexibilidad debido a su naturaleza "talla única", lo que puede no ser adecuado para todos los escenarios de implementación a través de 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 para 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, resultando en una experiencia de usuario más refinada y adaptable para varios 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 prestar 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 ZPLS y una licencia, 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 siguientes dos secciones.

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 del campus que afecte la comunicación entre edificios. El siguiente ejemplo describe cómo una falla 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 un evento que afecte el 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 del campus.

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

La siguiente tabla demuestra la supervivencia de Zoom Phone en un diseño de sitio único multi-edificio:

Llamadas que se originan desde el edificio	Pueden alcanzar estas ubicaciones durante una falla externa de Internet	Pueden alcanzar estas ubicaciones durante una falla de la red del campus
Edificio A (anfitrión 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, un piso, 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 múltiples sitios con un módulo ZPLS están conectados mediante una red común, los usuarios pueden llamar a usuarios en _otros_sitios, siempre que la red local permanezca operativa. Sin embargo, este diseño es vulnerable en caso de una interrupción de la red de área del campus que afecte la comunicación entre edificios. El siguiente ejemplo describe cómo una falla de la red del campus puede afectar una implementación multi-sitio.

Ejemplo:

Una empresa está desplegando el módulo ZPLS dentro de su campus multi-edificio, 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 del 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 el servicio, cualquier usuario ubicado dentro de un sitio puede llamar a otro usuario ubicado dentro del mismo sitio. Sin embargo, debido a 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 se limitarán a realizar llamadas a otros usuarios dentro de su sitio local.

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

Llamadas que se originan desde el edificio	Pueden alcanzar estas ubicaciones durante una falla externa de Internet	Pueden alcanzar estas ubicaciones durante una falla de la red del campus
Edificio A (anfitrión ZPLS)	☑️ Edificios A, B y C	☑️ Edificio A
Edificio B (anfitrión ZPLS)	☑️ Edificio A, B y C	☑️ Edificio B
Edificio C (anfitrión ZPLS)	☑️ Edificio A, B y C	☑️ Edificio C

Si una red local falla, la llamada entre sitios también es compatible a través de la RTPC, siempre que cada sitio esté conectado a un SBC y tenga el desví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 llamadas sitio a sitio si el desví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 al RTPC, al SBC y al módulo ZPLS del segundo sitio, llegando finalmente al dispositivo del destinatario. El siguiente diagrama ofrece una visión general de esta configuración:

Esta configuración requiere Procesamiento de números telefónicos 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 que se originan desde el edificio	Pueden alcanzar estas ubicaciones durante una falla externa de Internet	Pueden alcanzar estas ubicaciones durante una falla de la red del campus
Edificio A (anfitrión ZPLS)	☑️Edificios A, B y C	☑️Edificios A, B y C
Edificio B (anfitrión ZPLS)	☑️Edificios A, B y C	☑️Edificios A, B y C
Edificio C (anfitrión 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 agregan usuarios o dispositivos a Zoom Phone, se asocia estáticamente un sitio “de origen” 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 se encuentra en el edificio B, ocurre un evento que afecta el servicio y se activa el modo de supervivencia. Aunque el usuario se encuentre en el edificio B, dado que el Sitio A es su sitio de origen, el cliente del usuario intentará conectarse al módulo ZPLS aprovisionado en su sitio de origen en el edificio A.

En este escenario, el estado de supervivencia de un usuario lo determina 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 del campus. Si la red de área del campus está caída mientras el usuario está fuera de su sitio de origen, el usuario no puede beneficiarse del módulo de supervivencia.