Hardware Deployment Considerations
Find instructions for deploying the Zoom Node ZPLS module on virtual machines using supported hypervisors
This page outlines the deployment of the Zoom Node ZPLS module on a virtual machine using supported hypervisors. It provides detailed configuration options tailored to accommodate different hardware capabilities, ensuring optimal performance for various operational needs.
Supported Hypervisors
Customers must install the Zoom Node software on a virtual machine running on a supported hypervisor
As a Zoom Node workload, the ZPLS module must be installed on a virtual machine running the Zoom Node platform, on a supported hypervisor. More information about Zoom Node as a product can be found in the Appendix.
Customers can choose one of two configuration options, depending on hardware capabilities
The ZPLS module supports two configurations, depending on the hardware capabilities of the virtual machine. These capabilities are listed below:
Hardware Specs
8 CPU
16 GB RAM
80 GB HDD
16 CPU
16 GB RAM
80 GB HDD
Total Registrations
2000
5000
Maximum Concurrent Calls
240
480
Calls Per Second
2
4
Registrations Per Second
45
90
Module Scaling and Resiliency
ZPLS modules support clustering for additional scaling and/or resiliency
Customers can group ZPLS modules together with up to 20 modules per-site (or 100 total Node devices per-account) for additional redundancy or scaling.
Scaling increases a site’s supported device capabilities
Expanding the number of ZPLS modules enhances the capabilities of each site linearly for every additional module. For example, if one module supports a total of 5,000 registrations, deploying five modules will elevate the support to 25,000 registrations.
Redundancy adds additional modules for resiliency, but does not scale a site’s device capabilities
When a ZPLS module is utilized for redundancy purposes, the redundant modules do not contribute to the total number of supported extensions. Instead, the modules are on “hot standby,” and will only engage if primary modules fail. For example, one primary and one redundant module support a total of 5,000 registrations, so if a primary module fails, the redundant module is not oversubscribed with devices beyond its supported limit.
Example of Deploying ZPLS with Scaling and Redundancy
For convenience, the following example demonstrates deployment with additional scaling and redundancy.
Example:
A hospital is required to support up to 10,000 registered extensions for survivability. To achieve this, the hospital is deploying four ZPLS modules.
The first two modules are capable of supporting 5,000 registrations each, resulting in a total capacity of up to 10,000 registrations. However, recognizing the importance of resiliency, the hospital is also deploying two additional modules as redundant backups to the primary modules.
In this scenario, the hospital now has primary and secondary survivability hardware deployed. Now, if a primary module encounters a failure, the redundant module(s) will take over to maintain uninterrupted service, while continuing to support up to 10,000 registered devices.
Site Design Considerations
Sites group Zoom Phone users together by location for common telephony settings and policies
A site is a specific term used within Zoom Phone that groups users with shared characteristics — like a common access code, address, SIP Zone, department, or policies — into a single, manageable group within the Zoom web portal. For some customers, a single site may represent all users within their business, and can span multiple buildings within a campus or location; for others, multiple sites may be required depending on your business needs. For more information on sites or site management, refer to Zoom’s support center.
Zoom Phone supports single-site and multi-site designs
There are two primary designs for configuring Zoom Phone sites within an account:
Single-site: Representing all users within an account, potentially spanning multiple buildings or locations, within a single Zoom Phone site.
Multi-site: Representing segments of users by location, building, department, or function separately, each with their own site.
Each ZPLS module can only be associated with one site at a time
As previously mentioned, a ZPLS module is the third-priority registrar for supported devices, behind primary and secondary SIP zones. Because devices receive their SRV lists during the bootup process, and these lists are tied to their site’s setting, each ZPLS module can only be associated with one site at a time.
Each site can support up to 20 ZPLS modules concurrently
Although each ZPLS module can only be associated with one site at a time, a site can support up to 20 ZPLS modules in one group, expanding the survivability capabilities of each site.
ZPLS modules support cross-site calling if the modules are connected to a common network
ZPLS modules from different sites support cross-site calling during a survivability event so long as the devices are discoverable within the local network. For instance, if a business campus has three buildings, each with their own phone site, the ZPLS modules from each site can connect site-to-site calls across the campus area network.
Before deploying ZPLS, accounts should understand which site configuration is best-suited to their needs
Because each ZPLS module can only be associated with one site at a time, site design is one of the most important factors when deploying the ZPLS service within an account. For this reason, customers should understand which site configuration is best for meeting their practical business and survivability needs, as each additional site enabled for survivability will require at least one additional ZPLS module.
A single-site design is easier to manage and provides survivability with a single ZPLS module, but offers less flexibility for user settings and policies
A single-site design helps streamline the management of Zoom Phone settings and policies by consolidating all users within an account under a single, unified group. This single user group offers businesses straightforward administration and reduced complexity, simplifying the management process. Additionally, a single-site design can offer local phone survivability with a single ZPLS module, so long as the site’s users do not exceed the capabilities of a single-module.
However, the simplicity of a single-site design naturally includes limitations. Specifically, single-site designs offer less flexibility due to their “one size fits all” nature, which may not suit all deployment scenarios across multiple departments with varying needs. Further, single-site deployments may be vulnerable in certain survival scenarios if the local network fails.
A multi-site design offers more flexibility for user settings and policies, but requires one ZPLS module for every survivability-enabled site and is more complicated to manage
A multi-site design offers businesses additional flexibility in user settings and policies by separating users into various groups with granular setting controls. This design empowers organizations to intricately adjust communication configurations to meet specific requirements across diverse sites, resulting in a more refined and adaptable user experience for various departments, scenarios, or needs. Additionally, multi-site deployments can support cross-site communication if the sites are connected through a common network.
However, managing a multi-site design demands careful attention to the intricacies of each site's unique requirements, which may require a higher level of administrative effort. Further, because each ZPLS module can only be assigned to one site at a time, each survivability-enabled site will require one ZPLS module and license, which may contribute to a more resource-intensive setup.
Network Failures
Survivability may be impacted if a site’s local network fails
Although ZPLS modules are designed to provide local phone survivability during service-impacting events, survivability can be impacted if a site’s local network fails. These scenarios are outlined in the following two sections.
Single-Site Local Network Failure
In a single-site design, one or more buildings are connected through a local or campus area network, and are represented by a single site within Zoom Phone. This configuration assumes a common network between all users and buildings within a location, without any external network dependencies (e.g., the Internet) for cross-building communication.
With this site design, a business can provide local survivability to all users within a single site or location with as little as one ZPLS module; however, this design is vulnerable in the event of a local or campus network outage that affects cross-building communication. The following example describes how a local network failure can affect a single-site deployment.
Example:
A company is deploying the ZPLS module for a single Zoom Phone site, made up of buildings A, B, and C, which are connected through a campus area network. The ZPLS module is operating in Building A and is not connected to an SBC for external calling across the PSTN.
In the event of an external internet service failure or service-impacting event, any user contained within the site can call another user within the same site, so long as both users maintain connectivity to the ZPLS module through the campus area network.
However, in the event of a campus area network outage, users within buildings B and C cannot place calls while the ZPLS module within Building A is unreachable. Consequently, users within buildings B and C must wait until the campus area network is restored for survivability calling.
The following table demonstrates Zoom Phone survivability in a multi-building single-site design:
Building A (ZPLS Host)
☑️Buildings A, B, and C
☑️ Building A only
Building B
☑️Buildings A, B, and C
✖️
Building C
☑️Buildings A, B, and C
✖️
Multi-Site Local Network Failure Without an SBC
In a multi-site design, each building or location (e.g., floor, satellite office, etc.) is independently represented by a unique site within Zoom Phone. This configuration assumes that each site has a ZPLS module, and that the sites are connected through a common campus area network.
With this site design, each site supports their own ZPLS module, allowing users within the same building to call each other when survivability mode is engaged. Further, when multiple sites with a ZPLS module are connected through a common network, users can call users at _other_sites, so long as the local network remains operational. However, this design is vulnerable in the event of a campus area network outage that affects cross-building communication. The following example describes how a campus network failure can affect a multi-site deployment.
Example:
A company is deploying the ZPLS module within their multi-building campus, made up of buildings A, B, and C. Each building is a unique site within Zoom Phone, and maintains a site-specific ZPLS module. All buildings within the campus are connected through a campus area network that does not depend on external internet service for cross-building communications.
In this example, in the event of an external internet service failure, campus network outage, or service impacting event, any user located within a site can call another user located within the same site. However, because each building is a unique site and users register to their site-specific modules, if the campus network fails, the ZPLS modules cannot transport cross-site calls. Instead, users will be limited to placing calls to other users within their local site.
The following table demonstrates Zoom Phone survivability from the above example in a multi-site design with an inter-connected campus network:
Building A (ZPLS Host)
☑️ Buildings A, B, and C
☑️ Building A
Building B (ZPLS Host)
☑️ Building A, B, and C
☑️ Building B
Building C (ZPLS Host)
☑️ Building A, B, and C
☑️ Building C
If a local network fails, cross-site calling is also supported through the PSTN, provided each site is connected to an SBC and has call forwarding enabled
In the event of a local network failure, customers with a multi-site design that integrates the ZPLS module with an SBC and PSTN connectivity at each site can enable site-to-site calling if call forwarding is enabled. When configured, phone calls placed during survivability mode will route from the user’s client to the PSTN, to the second site’s SBC and ZPLS module, finally arriving at the callee’s device. The following diagram provides an overview of this configuration:
This configuration requires E.164 phone number processing on the configured SBCs.
The following table also demonstrates Zoom Phone survivability in a multi-site design with independent SBCs:
Building A (ZPLS Host)
☑️Buildings A, B, and C
☑️Buildings A, B, and C
Building B (ZPLS Host)
☑️Buildings A, B, and C
☑️Buildings A, B, and C
Building C (ZPLS Host)
☑️Buildings A, B, and C
☑️Buildings A, B, and C
Nomadic users always register to the ZPLS module associated with their home site
When users or devices are added to Zoom Phone, a “home” site is statically associated with the user or device until otherwise updated by an account administrator. This means that if a user moves to a physical location outside of their associated home site, like an office building associated with a different site, Zoom will not dynamically adjust the site bound to the user. Consequently, if the user loses connectivity to Zoom Phone data centers, the user will attempt to register to the ZPLS module associated with their home site, even if they are in a different location.
Example:
A user in a multi-site campus is based at Building A (Site A), and temporarily moves to Building B (Site B) for a meeting. While they are in Building B, a service-impacting event occurs, and survivability mode is engaged. Although the user is located within Building B, because Site A is their home site, the user’s client will attempt to connect to the ZPLS module provisioned at their home site within building A.
In this scenario, a user’s survivability status is determined by the user device’s ability to register to the ZPLS module within their home site across the campus area network. If the campus area network is down while the user is away from their home site, the user cannot benefit from the survivability module.
Last updated
Was this helpful?