Updating anynode in High Availability Setup
When upgrading from anynode 4.12.x or earlier to anynode 4.14.x or newer, both systems in the High Availability setup must be updated first before Hot Standby functionality can operate again.
In this chapter, we will discuss the process of updating anynode in a High-Availability Setup to ensure minimal downtime. The recommended approach is to start by updating the Standby System, followed by the Main System. This strategy helps maintain system availability, as there is typically no downtime while the Standby System is being updated and only a brief downtime during the subsequent Handover to the Standby System to update the Main System.
We will guide you through each step of the update process, from verifying the link between the systems and performing a Handover to ensuring all services are running correctly on the updated systems. You'll learn how to handle potential errors that may arise when versions between the Main and Replica do not match, and how to set the Main System to Out of Service to prevent unintended role changes during the update.
By following these steps, you can ensure a smooth update process with minimal disruption to your anynode high-availability environment.
It is also possible to perform an operating system update during these steps. If you only want to update the operating system of one of the systems, you only need to follow the steps for updating that specific system. In this case, an anynode update is not required; only the OS update needs to be performed. More information on upgrading a Linux system can be found in the Installation & Maintenance TechNote
Considerations for Updating anynode in a High-Availability Environment
When updating anynode in a High Availability (HA) environment, there are several important considerations to ensure a smooth update process. Here are key factors to keep in mind:
-
Backup: Before initiating the update, perform a comprehensive backup of the current configuration, settings, and any critical data. This ensures that, in the event of any issues during the update, you can quickly restore the system to its previous state.
-
Hot Standby Failover: If your HA setup includes failover capabilities, plan for the possibility of Hot Standby failover during the update process. Ensure that failover mechanisms are in place and tested to guarantee uninterrupted service.
-
Rollback Plan: Develop a rollback plan in case the update encounters unforeseen issues. This plan should include steps to revert to the previous version while minimizing downtime and service disruption.
-
Testing: Prior to updating the production environment, perform the update in a test or staging environment that replicates the HA setup. This allows you to identify and address any issues or conflicts specific to your configuration before applying the update in a live environment.
Even if it is usually not needed afterward, we recommend taking a snapshot of the system if it is a virtual system. Otherwise, create a system image and store it in a secure location beforehand.
By carefully planning and executing the update process in a High Availability environment, you can minimize the risk of service disruptions and ensure the continued reliability of your anynode deployment.
With the anynode Hot Standby feature, you define important rules so that a secondary anynode system can take over in an emergency or update process as part of a High Availability configuration. Via the graphical user interface of this feature, all conditions for a switchover to the secondary Standby System and back can be individually set. For more details on the graphical Hot Standby user interface, we recommend watching our Hot Standby video tutorial.
During the update process, both systems will be temporarily unavailable. Therefore, the update must be performed during a scheduled maintenance window.
The typical update procedure with the anynode Hot Standby feature, is as follows:
-
Create backup of Main System (see chapter Backup and Restore in the Installation and Maintenance Masterclass for details)
-
Create backup of Standby System.
-
Check initial state: anynode (main) is active, anynode (standby) is inactive.
-
Activate maintenance mode on the Standby System.
-
Perform the update on the Standby System first.
-
Verify that the anynode frontend displays the correct version after the update.
-
Enable maintenance mode on the Main System, transferring the active role to standby.
Activate the maintenance mode on the Main System only after ensuring that the maintenance mode is still active on the Standby System. This ensures that both systems do not attempt to connect their nodes simultaneously. This precaution is necessary due to the version discrepancy at this step. If the anynode versions on the Main System and the Standby System are different, the Hot Standby feature will not function correctly.
-
Disable maintenance mode on the Standby System.
-
Perform the update on the Main System as outlined in the previous steps.
-
If the Main System updates successfully: Disable maintenance mode on the Main System.
-
When convenient, switch the active role back to the Main System.
This procedure ensures a controlled update process with minimal downtime and the ability to roll back to the previous version if issues arise during the update. Always perform updates during a maintenance window to minimize the impact on users.
When updating the systems, it is generally recommended to start with the Standby System. After that, the Main System is updated. This approach typically ensures no downtime while the Standby System is being updated and only a brief downtime during the subsequent to the Standby System to update the Main System.
The update process ensures that you always have one system active during the update, minimizing downtime as much as possible. In the first step, you must ensure that the Main System is the active system.
During the period when only the Replica System is updated and not the Main System, it will not be possible to make any configuration changes on the Replica System.
This step is not mandatory. However, to ensure that the Standby System does not unexpectedly become active if the Link is missing after an update, you can set the Initial standby timeout timer under Communication parameters and timer settings to 20,000 minutes. This is almost 14 days and should provide enough time to react in the unlikely event that no Link is established.
This timer ensures that after a restart of the Standby System, the specified time must pass before the Standby System can assume the active status. By default, this timer is set to 30 seconds, and it should be reset to the default value after both systems have been updated.
The easiest way to do this is by locking the setting again, which will automatically revert it to the default value.
Now, the update on the Replica System can be performed following the instructions in the Installation & Maintenance TechNote
After completing the update, access the frontend of the Replica System directly to ensure that the update was successful.
Make sure that all services are running on the same, new version. You can find this information under the Information section.
When you enter the Replica System through the Main systems frontend, you won't see the right version of the Frontend Service. It will show the Frontend version of the Main System.
If you try to access the Replica System from the Main Frontend after updating only the Replica, you will encounter an error because the Master and Replica versions are not the same.
The error message reads, "This Frontend is incompatible with the current anynode. If you change settings, these may corrupt your configuration! Please update Frontend or anynode in such a way that they are related." This error essentially means that to make changes on the Replica System, you must first update the Main System as well.
After updating the Standby System, it's important to ensure that the link between the systems is active again. A deactivated link typically only occurs after major updates where changes to anynode's IPC connections have been made. However, this is not common and doesn't happen frequently.
If the link is not active, first ensure that all services on the Standby System are running (in service). If the link remains inactive, you can proceed with updating the Main System to bring both anynodes to the same version. However, this might result in some downtime and should only be performed during a maintenance window.
In case of uncertainty, contact TE-SYSTEMS support or the partner from whom you purchased anynode. (Partners contact TE-SYSTEMS directly, while customers must go through their partner.)
If the link between both systems is active, perform a . During this Hand over, any ongoing calls will be interrupted, so it should only be done during a scheduled maintenance window. However, the Standby System should quickly take over operations, allowing new calls to be established promptly.
On the Replica System, ensure that all connections are active and that calls are being successfully processed.
Set the Main System to out of service by using the button.
This step is necessary only if there are active calls on the other system. If the update is taking place during a maintenance window, this setting is not required.
This step is performed to prevent the Main System from unintentionally assuming the active role in case the link is lost after the update. It ensures that the Standby System can continue operating without interruption, even while the Main System is being updated.
Confirm out of service by clicking .
You can now proceed with updating the Main System by following the instructions in the Installation & Maintenance TechNote
Check the versions on the Main System under Information in the Local Backend.
Ensure that the versions of all services match and are running the same version.
Once the link between the systems is active again, the Main System can be set back to In Service.
Click on next to Main System is out of service.
In the Service state window that opens, set anynode back to In Service and confirm by clicking .
A manual Recover can now be performed at any time. However, it is important to remember that this should only be done when there are no active calls.
In general, performing a Recover is not necessary since the Main System and the Standby System are equivalent. Therefore, the Standby System may just remain active without any issues.
