Hello @Hamza - if you are doing Asynchronous upgrades, the backup Appliance is updated first and then assumes the role of primary. The process of Failover copies everything from Appliance A to Appliance B. The moment you break failover, you essentually have 2 copies the Appliance A with all the session and configuration data on it. So there should be no risk in losing any session data or recordings.
As for all upgrades, we also strongly recommend taking a /login backup so you could restore an appliance should anything go wrong during the update process.
Hi @PhillC
in our case we have advised to wait 24 hours before going for second upgrade. below is the upgrade sequence.
- Upgrade Base to 7.1.0
- Upgrade PRA Site to 24.1.1
----minimum 24 hours wait-----
- Upgrade Base to 7.3.0
- Upgrade PRA Site to 24.3.1
can you suggest how we can avoid losing any session data in this all activity.
because as soon as we perform DNS swing, IC will check with Appliance B for any downloads and Appliance A not being in failover/Atlas cluster will not be ablet to offload the data via IC.
Hello @Hamza - I am not sure I fully follow where you believe the session data is going to be lost? In both upgrade events, you have 2 appliances with a copy of your session data on both. Which ever appliance is Primary will be copying it’s data to the Backup.
Can you expand on your concens or queries here? Maybe add some addtional details please?
Hi @PhillC ,
so we will start the upgrade process by breaking Failover and then updating Appliance B. Users will be connecting via Appliance A here.
perform DNS swing to make Appliance B primary. before this step Appliance A will be having session data that is not synced to Appliance B (as it was not part of failover sync). after upgrading all appliance in cluster we will initiate failover from Appliance B and Appliance B will sync it’s data to Appliance A.
what will happen to the data which Appliance A have during the Appliance B upgrade ?
Hello @Hamza - The upgrade process should be done with some downtime planned, so no new sessions or rep log in’s are taking place during this process, ideally.
Right before you break Failover, you perform a Failove Sync, so both appliance are as up to date as possible. Once broken, nothing happens to the session data, it now exsits on both appliances - one appliance gets updated, so it now has the new software and still has the session data. Then the other appliance is updated, same situation. Also note: Breaking Failover does not remove or wipe any data from either appliance.
Once failover is re-established, both appliances will sync again but really, there is nothing new to sync, but it is part of the process.
I hope this helps with your query!
Hi @PhillC ,
in this case the downtime will be similar to ‘Synchronous updates’, while Asynchronous approach is used to minimize the downtime by failing over .
Hello @Hamza - it is minimsing downtime by allowing the backup appliance to run while you upgrade the primary. But, when you re-establish Failover at the end of the upgrade sequence, the backup (current primary) will sync whatever new data it has with the primary (current backup).
I see you mention the integration Client not downloading the data from Appliance B, but any new session data will sync’d to Appliance A once the upgrade process is completed, at which point the IC will be able to see it. So long as the Failover is created from Appliance B, it will remain primary and sync to backup Appliance A. You can then switch from there, back to normal.
Just to confirm, everything I have stated so far can be found in our upgrade guide here: https://docs.beyondtrust.com/pra/docs/on-prem-upgrade-multiple#asynchronous-updates
