Rolling Upgrade Scenario: Three OneSpan Authentication Server Instances Using Shared Database

About this scenario

This scenario describes an environment with the following setup:

• There are three OneSpan Authentication Server instances: server A, server B, and server C.
• All servers use the same, older version of OneSpan Authentication Server.
• All OneSpan Authentication Server instances are using the same database.
• User load is distributed evenly between all OneSpan Authentication Server instances using a third-party solution.

Figure: Rolling upgrade scenario: Three servers using one shared database

The servers will be upgraded in the following order:

1. Server A
2. Server B
3. Server C

Do not access the Administration Web Interface of any OneSpan Authentication Server instance during the rolling upgrade. Doing so might inadvertently apply database changes in the middle of a database schema update. This could corrupt the database and thus damaging its stored data.

Before you begin

• Verify that you have addressed the different usability and user load issues related to a rolling upgrade (see General considerations).

• In this scenario you will be requested to configure, break, and restore replication between different OneSpan Authentication Server instances. For more information about replication during rolling upgrades, see Replication.

Walkthrough: Performing a rolling upgrade on three servers using one shared database

Performing a rolling upgrade on servers with one shared database

1. The first step in a rolling upgrade is to configure replication in the following directions:

   • Server B to server A
   • Server C to server A

2. Create a duplicate of the database.

   

   Figure: Rolling upgrade scenario: Creating a duplicate of the database

3. Disable the user load to server A.

   

   Figure: Rolling upgrade scenario: Disabling user load to server A

4. Disable the OneSpan Authentication Server instance on server A and configure it to use the duplicate database.

   Keep in mind that this is a time-sensitive operation, as both server B and server C are replicating to server A.

5. Enable the OneSpan Authentication Server instance on server A.

   Once you do, server A will start receiving traffic on the replication queues from both server B and server C.

   

   Figure: Rolling upgrade scenario: Enabling OneSpan Authentication Server instance on server A

6. Wait until the replication queue from server B to server A is empty. Once empty, break replication from server B to server A.

7. Wait until the replication queue from server C to server A is empty. Once empty, break replication from server C to server A.

   At this point, there should be no replication occurring between OneSpan Authentication Server instances.

8. Stop the OneSpan Authentication Server service on server A.

   

   Figure: Rolling upgrade scenario: Stopping OneSpan Authentication Server service on server A

9. Upgrade OneSpan Authentication Server on server A. Upgrade the database schema of the duplicate server as required.

   

   Figure: Rolling upgrade scenario: Upgrading OneSpan Authentication Server on server A

10. Restore replication from server B to server A.

11. Restore replication from server C to server A.

    At this point:

    • The schema of the duplicate database is now updated.
    • Server A is now updated and using the database with the updated schema.
    • Both server B and server C are replicating to server A.
    • Server A is not receiving any user load.
    • 

      Figure: Rolling upgrade scenario: Restoring replication from server C to server A

    • 
      

12. Restore user load to server A while simultaneously removing user load from server B and server C.

    This must be simultaneous to maintain the security and availability of the service.

    

    Figure: Rolling upgrade scenario: Restoring user load to server A while removing load from other servers

13. Wait until the replication queue from server B to server A is empty. Once empty, break replication from server B to server A.

14. Wait until the replication queue from server C to server A is empty. Once empty, break replication from server C to server A.

    At this point, there should be no replication occurring between OneSpan Authentication Server instances.

15. Disable the OneSpan Authentication Server instances on both server B and server C.

    Server A is now the sole service provider.

    

    Figure: Rolling upgrade scenario: Disabling OneSpan Authentication Server instances on servers B and C

16. Configure server A and server B to use the database with the updated schema.

17. Upgrade both server B and server C.

    

    Figure: Rolling upgrade scenario: Upgrading servers B and C

18. Restore user loads to server B and server C.

    

    Figure: Rolling upgrade scenario: Restoring user load to servers B and C

    At this point:

    • All servers are running upgraded OneSpan Authentication Server instances.
    • All servers are using the database with the updated schema.
    • All OneSpan Authentication Server instances are replicating to each other.
    • User load is distributed to all three servers.

It is now safe to completely disable replication between OneSpan Authentication Server instances.

At this point, the old database (i.e. the version still using the older schema) should no longer be needed. You may want to keep it for error recovery purposes, at least until the entire authentication service has been verified as fully functional and secure.

For security purposes, though, we recommend that you destroy this old database as soon as possible. The sequence of load and replication break/restore steps should ensure that all database writes during the rolling upgrade are applied to the database with the updated schema.