# 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 mediante 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](https://support.zoom.us/hc/en-us/articles/8427127286157-Deploying-a-Zoom-Node-management-server). Puede encontrarse más información sobre Zoom Node como producto [en el Apéndice](#_a2lvsihjp0ek).
#### Los Clientes pueden elegir 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 endpoints dentro de un sitio con soporte de resiliencia supera las capacidades de implementación de un sitio, el módulo ZPLS procesará los registros por orden de llegada. Se recomienda a los Clientes añadir módulos adicionales, o usar la Configuración de Zoom Phone Policy [**Modo de supervivencia local**](#_ah8xua8wdq10) para priorizar qué usuarios admiten la conmutación por error de resiliencia.
{% 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 se encuentra actualmente en beta y requiere una entrada de soporte técnico para habilitarse.
{% endhint %}
#### El escalado aumenta las capacidades de dispositivos admitidas 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, implementar 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 un módulo ZPLS se utiliza con fines de redundancia, los módulos redundantes no contribuyen al número total de extensiones admitidas. En cambio, los módulos están 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, por lo que, si falla un módulo primario, 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 una implementación con escalado y redundancia adicionales.
{% hint style="success" %}
**Ejemplo**:
Un hospital debe admitir hasta 10,000 extensiones registradas para resiliencia. Para lograrlo, 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 seguridad redundantes para los módulos primarios.
En este escenario, el hospital ahora tiene implementado hardware de resiliencia primario y secundario. Ahora, si un módulo primario encuentra una falla, el módulo o 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 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 dentro de su negocio, y puede abarcar varios edificios dentro de un campus o ubicación; para otros, pueden requerirse varios sitios según sus necesidades comerciales. Para obtener más información sobre 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 sitios de Zoom Phone dentro de una cuenta:
1. **Un solo sitio**: Representa a todos los usuarios dentro de una cuenta, posiblemente 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 el diseño de su 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 telefónico** 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 compatibles, detrás de las zonas SIP primaria y secundaria. Como 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 resiliencia de cada sitio.
{% hint style="info" %}
Esta característica se encuentra actualmente en beta y requiere una entrada de soporte técnico para habilitarse.
{% 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 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 un campus empresarial 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.
{% hint style="info" %}
Esta característica se encuentra actualmente en beta y requiere una entrada de soporte técnico para habilitarse.
{% endhint %}
#### 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 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 comerciales y de resiliencia, ya que cada sitio adicional habilitado para resiliencia requerirá al menos un módulo ZPLS adicional.
#### Un diseño de un solo sitio es más fácil de administrar y proporciona resiliencia 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 optimizar la administració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 menor complejidad, lo que simplifica el proceso de administración. Además, un diseño de un solo sitio puede ofrecer resiliencia 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”, lo que puede no adaptarse a 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 por cada sitio con soporte de resiliencia y es más complicado de administrar
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 manera 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](#_a42hwaw1pfmx) si los sitios están conectados a través de una red común.
Sin embargo, administrar un diseño de varios sitios exige prestar 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 con soporte de resiliencia 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 resiliencia. Sitios *sin* un módulo ZPLS permanecerá sin poder realizar ni recibir llamadas hasta que se restablezca la conectividad estándar.
{% endhint %}
### 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 un solo sitio, uno o más edificios están conectados a través de una red local o de área de 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 dependencias de red 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 ú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 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 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 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 de campus.
Sin embargo, en caso de una interrupción de la red de área de 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 de campus para realizar llamadas con resiliencia.
{% endhint %}
La siguiente tabla demuestra la resiliencia de Zoom Phone en un diseño de un solo sitio con varios edificios:
| Llamadas originadas desde el edificio | Pueden llegar a estas ubicaciones durante un fallo de Internet externo | Pueden llegar a estas ubicaciones durante un fallo de red de campus |
| ------------------------------------- | ---------------------------------------------------------------------- | ------------------------------------------------------------------- |
| Edificio A (anfitrión de 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 un SBC
En un diseño de varios sitios, cada edificio o ubicación (por ejemplo, piso, oficina satélite, 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 común de área de campus.
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á activado. 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 de \_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 un fallo de red de 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 con 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 para ese sitio. Todos los edificios dentro del campus están conectados a través de 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 un fallo del servicio de Internet externo, una interrupción de la red de 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 de 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 resiliencia de Zoom Phone del ejemplo anterior en un diseño de varios sitios con una red de campus interconectada:
| Llamadas originadas desde el edificio | Pueden llegar a estas ubicaciones durante un fallo de Internet externo | Pueden llegar a estas ubicaciones durante un fallo de red de campus |
| ------------------------------------- | ---------------------------------------------------------------------- | ------------------------------------------------------------------- |
| Edificio A (anfitrión de ZPLS) | ☑️ Edificios A, B y C | ☑️ Edificio A |
| Edificio B (anfitrión de ZPLS) | ☑️ Edificios A, B y C | ☑️ Edificio B |
| Edificio C (anfitrión de 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 desvío de llamadas
En caso de un fallo de la 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 desvío de llamadas está habilitado](#_2v7qst7vxwaa). Cuando se configura, las llamadas telefónicas realizadas durante el modo de resiliencia 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 ofrece una visión general de esta configuración:
{% hint style="danger" %}
Esta configuración **requiere** procesamiento de números telefónicos E.164 en los SBC configurados.
{% endhint %}
La siguiente tabla también demuestra la resiliencia de Zoom Phone en un diseño de varios sitios con SBC independientes:
| Llamadas originadas desde el edificio | Pueden llegar a estas ubicaciones durante un fallo de Internet externo | Pueden llegar a estas ubicaciones durante un fallo de red de campus |
| ------------------------------------- | ---------------------------------------------------------------------- | ------------------------------------------------------------------- |
| Edificio A (anfitrión de ZPLS) | ☑️Edificios A, B y C | ☑️Edificios A, B y C |
| Edificio B (anfitrión de ZPLS) | ☑️Edificios A, B y C | ☑️Edificios A, B y C |
| Edificio C (anfitrión de 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 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 trabaja 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 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 resiliencia.
{% endhint %}
---
# Agent Instructions: 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:
```
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=
```
The question should be specific, self-contained, and written in natural language.
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.