Consideraciones para la implementación de hardware
Encuentre instrucciones para implementar el módulo Zoom Node ZPLS 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 mediante hipervisores compatibles. Proporciona opciones de configuración detalladas adaptadas para acomodar distintas capacidades de hardware, garantizando un rendimiento óptimo para diversas necesidades operativas.
Hipervisores compatibles
Los clientes deben instalar el software de 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 seleccionar una de dos opciones de configuración, según las capacidades de 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:
Especificaciones de hardware
8 CPU
16 GB de RAM
80 GB de HDD
16 CPU
16 GB de RAM
80 GB de HDD
Total de registros
2000
5000
Máximo de llamadas simultáneas
240
480
Llamadas por segundo
2
4
Registros por segundo
60
400
Escalado y resiliencia del módulo
Los módulos ZPLS admiten clustering para un escalado y/o resiliencia adicionales
Los clientes pueden agrupar módulos ZPLS con hasta 20 módulos por sitio (o 100 dispositivos Node en total por cuenta) para redundancia o escalado adicionales.
El escalado aumenta las capacidades de dispositivos admitidos de un sitio
Ampliar el número de módulos ZPLS mejora linealmente 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á la capacidad a 25,000 registros.
La redundancia añade módulos adicionales para 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 quedan en “espera activa” 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, de modo que, si falla un módulo primario, el módulo redundante no se sobrecargará 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 debe admitir hasta 10,000 extensiones registradas para contar con resiliencia. Para lograrlo, el hospital está implementando cuatro módulos ZPLS.
Los dos primeros módulos pueden admitir 5,000 registros cada uno, lo que da una capacidad total de hasta 10,000 registros. Sin embargo, reconociendo la importancia de la resiliencia, el hospital también está implementando dos módulos adicionales como copias de respaldo redundantes de los módulos primarios.
En este escenario, el hospital ya tiene implementado hardware de resiliencia primario y secundario. Ahora, si un módulo primario sufre una falla, el/los módulo(s) redundante(s) tomarán el control para mantener un servicio ininterrumpido, mientras siguen admitiendo hasta 10,000 dispositivos registrados.
Consideraciones de diseño del sitio
Los sitios agrupan a los usuarios de Zoom Phone por ubicación para ajustes y políticas comunes de telefonía
Un sitio es un término específico utilizado dentro de Zoom Phone que agrupa a 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 manejable dentro del portal web de Zoom. Para algunos clientes, un solo sitio puede representar a todos los usuarios de su empresa y abarcar varios edificios dentro de un campus o ubicación; para otros, pueden requerirse varios sitios según las necesidades de su negocio. Para obtener más información sobre sitios o la administración de sitios, consulte el Centro de soporte de Zoom.
Zoom Phone admite diseños de un solo sitio y de varios sitios
Hay dos diseños principales para configurar sitios de Zoom Phone dentro de una cuenta:
Sitio único: Representa a todos los usuarios dentro de una cuenta, potencialmente abarcando varios edificios o ubicaciones, dentro de un solo sitio de Zoom Phone.
Varios sitios: Representa segmentos de usuarios por ubicación, edificio, departamento o función por separado, cada uno con su propio sitio.
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 dispositivos compatibles, 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 solo grupo, ampliando las capacidades de resiliencia de cada sitio.
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 distintos sitios admiten llamadas entre sitios durante un evento de resiliencia siempre que los dispositivos sean detectables dentro de la red local. Por ejemplo, si el campus de una empresa tiene tres edificios, cada uno con su propio sitio telefónico, los módulos ZPLS de cada sitio pueden conectar llamadas de sitio a sitio a través de la red de área del campus.
Antes de implementar ZPLS, las cuentas deben comprender qué configuración de sitio se adapta mejor a sus necesidades
Debido a que cada módulo ZPLS solo puede asignarse a 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 este motivo, los clientes deben comprender qué configuración de sitio es mejor para satisfacer sus necesidades prácticas de negocio y de resiliencia, ya que cada sitio adicional habilitado para resiliencia requerirá al menos un módulo ZPLS adicional.
Un diseño de sitio único es más fácil de administrar y proporciona resiliencia con un solo módulo ZPLS, pero ofrece menos flexibilidad para los ajustes y políticas de usuario
Un diseño de sitio único ayuda a simplificar la administración de los ajustes y políticas de Zoom Phone al consolidar a todos los usuarios dentro de una cuenta bajo un único grupo unificado. Este grupo único de usuarios ofrece a las empresas una administración sencilla y una menor complejidad, simplificando el proceso de administración. Además, un diseño de sitio único puede ofrecer resiliencia telefónica local con un solo módulo ZPLS, siempre que los usuarios del sitio no superen la capacidad de un solo 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 de “talla única”, lo que puede no adaptarse a todos los escenarios de implementación en varios departamentos con necesidades variables. Además, las implementaciones de sitio único pueden ser vulnerables en ciertos escenarios de resiliencia si la red local falla.
Un diseño de varios sitios ofrece más flexibilidad para los ajustes y políticas de usuario, pero requiere un módulo ZPLS por cada sitio con resiliencia habilitada y es más complicado de administrar
Un diseño de varios sitios ofrece a las empresas mayor flexibilidad en los ajustes 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 de forma detallada las configuraciones de comunicación para satisfacer requisitos específicos en diversos sitios, lo que da como resultado una experiencia de usuario más refinada y adaptable para distintos departamentos, escenarios o necesidades. Además, las implementaciones de varios sitios 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 de varios sitios exige prestar una atención cuidadosa a las particularidades de los requisitos únicos de cada sitio, lo que puede requerir un mayor nivel de esfuerzo administrativo. Además, debido a que cada módulo ZPLS solo puede asignarse a un sitio a la vez, cada sitio habilitado para resiliencia requerirá un módulo ZPLS y una licencia, lo que puede contribuir a una configuración más intensiva en recursos.
Fallos de red
La resiliencia puede verse afectada si falla la red local de un sitio
Aunque los módulos ZPLS están diseñados para proporcionar resiliencia telefónica local durante eventos que afectan al servicio, la resiliencia puede verse afectada si falla la red local de un sitio. Estos escenarios se describen en las dos secciones siguientes.
Fallo de red local de un solo sitio
En un diseño de sitio único, uno o más edificios están conectados a través de una red local o de área del campus, y se representan mediante 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 ninguna dependencia de redes externas (por ejemplo, Internet) para la comunicación entre edificios.
Con este diseño de sitio, una empresa puede proporcionar resiliencia local a todos los usuarios dentro de un solo 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 área del campus que afecte la comunicación entre edificios. El siguiente ejemplo describe cómo un fallo de red local puede afectar a una implementación de sitio único.
Ejemplo:
Una empresa está implementando el módulo ZPLS para un único sitio de Zoom Phone, compuesto por los edificios A, B y C, que están conectados a través de una red de área del campus. El módulo ZPLS está operativo en el edificio A y está no conectado a un SBC para llamadas externas a través de la RTPC.
En caso de un fallo del servicio externo de Internet o de un evento que afecte al servicio, cualquier usuario incluido dentro del sitio puede llamar a otro usuario dentro del mismo sitio, siempre que ambos usuarios mantengan la conectividad al 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 del edificio A no sea accesible. En consecuencia, los usuarios de los edificios B y C deben esperar hasta que se restablezca la red de área del campus para realizar llamadas con resiliencia.
La siguiente tabla muestra la resiliencia de Zoom Phone en un diseño de un solo sitio con varios edificios:
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 en varios sitios sin SBC
En un diseño de varios sitios, cada edificio o ubicación (p. ej., planta, oficina remota, etc.) se representa de forma independiente mediante 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 a través de una red de área del 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 el modo de resiliencia está activo. 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 del campus que afecte la comunicación entre edificios. El siguiente ejemplo describe cómo un fallo de la red del campus puede afectar a una implementación de varios sitios.
Ejemplo:
Una empresa está implementando el módulo ZPLS dentro de 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 dentro del campus están conectados a través de una red de área del campus que no depende del servicio externo de Internet para las comunicaciones entre edificios.
En este ejemplo, en caso de un fallo del servicio externo de Internet, 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, como 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 quedarán limitados a realizar llamadas a otros usuarios dentro de su sitio local.
La siguiente tabla muestra la resiliencia de Zoom Phone del ejemplo anterior en un diseño de varios sitios con una red de campus interconectada:
Edificio A (anfitrión ZPLS)
☑️ Edificios A, B y C
☑️ Edificio A
Edificio B (anfitrión ZPLS)
☑️ Edificios A, B y C
☑️ Edificio B
Edificio C (anfitrión ZPLS)
☑️ Edificios A, B y C
☑️ Edificio C
Si falla una red local, también se admite la llamada entre sitios a través de la RTPC, siempre que cada sitio esté conectado a un SBC y tenga habilitado el desvío de llamadas
En caso de un fallo de red local, los clientes con un diseño de varios sitios que integra el módulo ZPLS con un SBC y conectividad RTPC en cada sitio pueden habilitar las llamadas de sitio a sitio si el desvío de llamadas está habilitado. Cuando se configura, las llamadas telefónicas realizadas durante el modo de resiliencia se enrutarán desde el cliente del usuario a la RTPC, luego al SBC y al módulo ZPLS del segundo sitio y, por último, llegarán 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 muestra la resiliencia de Zoom Phone en un diseño de varios sitios con SBC independientes:
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 añaden usuarios o dispositivos a Zoom Phone, un sitio “de origen” se asocia estáticamente con el usuario o dispositivo hasta que un administrador de 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 otro sitio, Zoom no ajustará dinámicamente el sitio vinculado al usuario. En consecuencia, si el usuario pierde conectividad con los centros de datos de Zoom Phone, 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 de varios sitios tiene su base 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 resiliencia. Aunque el usuario se encuentra dentro del Edificio B, como el Sitio A es su sitio de origen, el cliente del usuario intentará conectarse al módulo ZPLS aprovisionado en su sitio de origen dentro del edificio A.
En este escenario, el estado de resiliencia 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 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 resiliencia.
Última actualización
¿Te fue útil?