> 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/es/zoom-workplace/zoom-phone/zoom-phone-local-survivability-field-guide/before-you-begin/hardware-deployment-considerations.md). # Consideraciones para la implementación de hardware Esta página describe la implementación del módulo Zoom Node ZPLS en una máquina virtual usando hipervisores compatibles. Proporciona opciones de configuración detalladas adaptadas para acomodar diferentes capacidades de hardware, lo que garantiza 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](https://support.zoom.us/hc/en-us/articles/8427127286157-Deploying-a-Zoom-Node-management-server). Puede encontrar más información sobre Zoom Node como producto [en el Apéndice](#_a2lvsihjp0ek). #### 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: | | Opción de Configuración 1 | Opción de Configuración 2 | | ---------------------------------- | -------------------------------------------------- | --------------------------------------------------- | | **Especificaciones de hardware** |

8 CPU

16 GB de RAM

HDD de 80 GB

|

16 CPU

16 GB de RAM

HDD de 80 GB

| | **Total de registros** | 2000 | 5000 | | **Máximo de llamadas simultáneas** | 240 | 480 | | **Llamadas por segundo** | 2 | 4 | | **Registros por segundo** | 60 | 400 | {% hint style="info" %} Si el número de terminales dentro de un sitio habilitado para supervivencia supera las capacidades de implementación de un sitio, el módulo ZPLS procesará los registros por orden de llegada. Se aconseja a los Clientes que añadan módulos adicionales o utilicen la configuración de Política de Zoom Phone [**Modo de supervivencia local**](#_ah8xua8wdq10) para priorizar qué usuarios admiten la conmutación por error de supervivencia. {% endhint %} ### Escalado y resiliencia del módulo #### Los módulos ZPLS admiten agrupación en clúster 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. {% hint style="info" %} Esta característica está actualmente en versión beta y requiere habilitarse mediante una entrada de soporte técnico. {% endhint %} #### El escalado aumenta las capacidades de dispositivos admitidas de un sitio Expandir 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, 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 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 se activarán si fallan los módulos principales. Por ejemplo, un módulo principal y uno redundante admiten un total de 5,000 registros, por lo que si falla un módulo principal, el módulo redundante no se sobrecarga 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 y redundancia adicionales. {% hint style="success" %} **Ejemplo**: Un hospital debe admitir hasta 10,000 extensiones registradas para supervivencia. Para lograr esto, el hospital está implementando cuatro módulos ZPLS. Los dos primeros módulos son capaces de admitir 5,000 registros cada uno, lo que da como resultado 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 principales. En este escenario, el hospital ahora tiene implementado hardware primario y secundario de supervivencia. Ahora, si un módulo principal sufre un fallo, el o los módulos redundantes tomarán el control para mantener el servicio ininterrumpido, mientras continúan admitiendo hasta 10,000 dispositivos registrados. {% endhint %} ### Consideraciones de diseño del sitio #### Los sitios agrupan a los usuarios de Zoom Phone por ubicación para las configuraciones y políticas comunes de telefonía Una **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 administrable dentro del portal web de Zoom. Para algunos Clientes, un solo sitio puede representar a todos los usuarios de su negocio y puede 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 los sitios o la administración de sitios, [consulte el Centro de soporte de Zoom](https://support.zoom.com/hc/en/article?id=zm_kb\&sysparm_article=KB0069716). #### Zoom Phone admite diseños de un solo sitio y de varios sitios Hay dos diseños principales para configurar los sitios de Zoom Phone dentro de una cuenta: 1. **Un solo sitio**: Representa a todos los usuarios dentro de una cuenta, potencialmente abarcando varios edificios o ubicaciones, dentro de un único sitio de Zoom Phone. 2. **Varios sitios**: Representa segmentos de usuarios por ubicación, edificio, departamento o función por separado, cada uno con su propio sitio.
{% hint style="info" %} 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**](https://zoom.us/pbx/page/telephone/settings#/settings/multi-sites?page_number=1\&page_size=15\&keyword=) página, disponible en el **Administración del sistema de telefonía** menú del portal web. {% endhint %} #### 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](#_7itj40mx1dut) para dispositivos admitidos, detrás de las zonas SIP primaria y secundaria. Debido a que los dispositivos reciben sus listas SRV durante el proceso de inicio, 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. {% hint style="info" %} Esta característica está actualmente en versión beta y requiere habilitarse mediante una entrada de soporte técnico. {% endhint %} #### 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 entre sitios a través de la red de área del campus. {% hint style="info" %} Esta característica está actualmente en versión beta y requiere habilitarse mediante una entrada de soporte técnico. {% endhint %} #### Antes de implementar ZPLS, las cuentas deben entender qué configuración de sitio se adapta mejor a sus necesidades Debido a 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 prácticas de negocio y supervivencia, ya que cada sitio adicional habilitado para supervivencia requerirá al menos un módulo ZPLS adicional. #### Un diseño de un solo sitio es más fácil de gestionar y ofrece supervivencia con un solo módulo ZPLS, pero ofrece menos flexibilidad para la configuración y las políticas de los usuarios Un diseño de un solo sitio ayuda a simplificar la gestión de las configuraciones 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, lo que simplifica el proceso de gestión. Además, un diseño de un solo sitio 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](#_rx0i1j9xofnc). Sin embargo, la simplicidad de un diseño de un solo sitio incluye naturalmente limitaciones. En concreto, los diseños de un solo sitio ofrecen menos flexibilidad debido a su naturaleza de “talla única”, que puede no ser adecuada para todos los escenarios de implementación en varios departamentos con necesidades variables. Además, las implementaciones de un solo sitio pueden ser vulnerables en ciertos escenarios de supervivencia si la [red local falla](#_gzpf5m70jl3i). #### Un diseño de varios sitios ofrece más flexibilidad para la configuración y las políticas de los usuarios, pero requiere un módulo ZPLS para cada sitio habilitado para supervivencia y es más complicado de gestionar Un diseño de varios sitios ofrece a las empresas mayor flexibilidad en la configuración y las políticas de los usuarios al separar a los usuarios en varios grupos con controles de configuración granulares. Este diseño permite a las organizaciones ajustar de forma minuciosa 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 diversos departamentos, escenarios o necesidades. Además, las implementaciones de varios sitios pueden admitir [comunicación entre sitios](#_a42hwaw1pfmx) 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 mucha atención 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 supervivencia requerirá un módulo ZPLS y una licencia, lo que puede contribuir a una configuración que consume más recursos. {% hint style="info" %} En un diseño de varios sitios, los Clientes tienen la flexibilidad de elegir qué sitios se configurarán para supervivencia. Los sitios *sin* un módulo ZPLS seguirá sin poder realizar ni recibir llamadas hasta que se restablezca la conectividad estándar. {% endhint %} ### Fallos de red #### La supervivencia puede verse afectada si falla la red local de un sitio Aunque los módulos ZPLS están diseñados para proporcionar supervivencia telefónica local durante eventos que afectan al servicio, la supervivencia 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 un solo sitio, uno o más edificios están conectados a través de una red local o de área del campus, y están representados por un único sitio dentro de Zoom Phone. Esta configuración supone 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 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 un solo sitio.
{% hint style="success" %} **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á operando 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 de Internet externo 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 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 dentro del edificio A no esté accesible. En consecuencia, los usuarios de los edificios B y C deben esperar hasta que se restablezca la red de área del campus para las llamadas de supervivencia. {% endhint %} La siguiente tabla demuestra la supervivencia de Zoom Phone en un diseño de un solo sitio con varios edificios: | Llamadas originadas desde el edificio | Puede llegar a estas ubicaciones durante un fallo de Internet externo | Puede llegar a estas ubicaciones durante un fallo 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 de varios sitios sin un SBC En un diseño de varios sitios, cada edificio o ubicación (por ejemplo, piso, oficina satélite, etc.) está representado de forma independiente por un sitio único dentro de Zoom Phone. Esta configuración supone 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 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 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.
{% hint style="success" %} **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 de Internet externo para las comunicaciones entre edificios. En este ejemplo, en caso de un fallo 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, 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 estarán limitados a realizar llamadas a otros usuarios dentro de su sitio local. {% endhint %} La siguiente tabla demuestra la supervivencia de Zoom Phone del ejemplo anterior en un diseño de varios sitios con una red de campus interconectada: | Llamadas originadas desde el edificio | Puede llegar a estas ubicaciones durante un fallo de Internet externo | Puede llegar a estas ubicaciones durante un fallo de la red del campus | | ------------------------------------- | --------------------------------------------------------------------- | ---------------------------------------------------------------------- | | 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, las llamadas entre sitios también son compatibles a través de la RTPC, siempre que cada sitio esté conectado a un SBC y tenga habilitado el reenví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 entre sitios si [el reenvío de llamadas está habilitado](#_2v7qst7vxwaa). Cuando se configura, las llamadas telefónicas realizadas durante el modo de supervivencia se enrutarán desde el cliente del usuario a la RTPC, al SBC del segundo sitio y al módulo ZPLS, llegando finalmente al dispositivo del destinatario. El siguiente diagrama proporciona una visión general de esta configuración:
{% hint style="danger" %} Esta configuración **requiere** el procesamiento de números de teléfono E.164 en los SBC configurados. {% endhint %} La siguiente tabla también demuestra la supervivencia de Zoom Phone en un diseño de varios sitios con SBC independientes: | Llamadas originadas desde el edificio | Puede llegar a estas ubicaciones durante un fallo de Internet externo | Puede llegar a estas ubicaciones durante un fallo 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 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 con 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 Phone, intentará registrarse en el módulo ZPLS asociado con su sitio de origen, incluso si se encuentra en una ubicación diferente. {% hint style="success" %} **Ejemplo:** Un usuario en un campus de varios sitios se encuentra 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 se encuentra dentro del Edificio B, debido a 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 dentro del 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 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. {% 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/es/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.