Zero-downtime update

New maintenance releases are delivered every 2 months, and each new release contains numerous enhancements that enable new or improved services. Naturally, telco operators want to maintain an up-to-date system to uphold their competitive edge – and this must be done without any negative impact on the end user.

Zero-downtime update (ZDU) technology allows you to perform software upgrades at any time without any noticeable impact on end users.

ZDU utilizes PortaSwitch site-redundant architecture – for which the dispatching SBC must be deployed at least on two dedicated servers. Follow the Configure Dispatching SBC for ZDU in site-redundant PortaSwitch section for more details.

The upgrade is performed using the following procedure:

1. First, the usual upgrade preparation is performed (verification of custom modifications, hardware check for compatibility with new OS, etc.).
2. Though PortaSIP on main site A is switched to “maintenance” mode, active calls remain connected until they are completed.
3. After all existing calls are completed on site A and there is no more live traffic there, the upgrade process begins on that site. A new version of code is installed on all servers, database changes are applied and servers are rebooted (excluding the dispatching SBC).
4. The dispatching SBC starts to send new registration and call initiation attempts to secondary site B that is switched to stand-alone mode.
5. After all existing calls are completed on site A and there is no more live traffic there, the upgrade process begins on that site. A new version of code is installed on all servers, database changes are applied and servers are rebooted (excluding the dispatching SBC).
6. The dispatching SBC cluster undergoes the update process sequentially: standby mode is enabled on the first dispatching SBC node. The virtual IP address is switched to the second node, which becomes active and handles all call and registration requests. Then the update process starts on the first node. Upon completion, the update process starts on the second node. The second node is put into standby and the virtual IP address switches to the first node, which then becomes active. After the update on the second node completes, its standby mode is disabled.

   

7. Throughout this time, customers are able to use services via site B as usual; calls are charged, balances are updated accordingly and xDRs are written. Find the list of limitations in the Stand-alone mode restrictions section.
8. Finally, when the upgrade is completed on site A and all services there are verified to be working properly, site A becomes activated. The synchronization process with site B begins, and changes in balances and xDRs accumulated on site B while in stand-alone mode are applied to the main database on site A.
9. All new customer calls are directed to site A (using the same tools as described earlier). Any calls in progress on site B finish normally.
10. When site B has fully synchronized its data with site A and there are no more “live” calls there, the update process begins on site B. It replicates all the changes in the database structure from site A, a new version of the software is installed and its servers are rebooted.
11. When the update finishes, site B returns to its standard operational mode: PortaSIP servers there may be used in conjunction with the main site to process calls; the billing servers and database are in stand-by mode and data changes on site A are replicated to site B so it has an up-to-date copy of all service configurations.

If you provide Internet access services and want to use ZDU, your NAS must support two connections – active and fallback. Your engineers should configure the active connection to send requests to the RADIUS server on the main site and the fallback connection to send requests to the RADIUS server on the secondary site. During the update, the NAS can automatically switch from the active to the fallback connection and back.