Use Case

You have a UMS High Availability (HA) installation and need to update it. 

General Overview

There are two possible HA update procedures:

With Short Downtime

In this case, the update procedure generally looks as follows:

  1. Stop all UMS Servers except one (verify this in the server list of the UMS Console connected to the last running server).
  2. Update this UMS Server.
    As soon as the update is complete, the productive database will be updated upon server startup.  
  3. Update the remaining UMS Servers (simultaneously or one after another).
    When the update is complete, they will automatically connect to the productive database. 
  4. Update other components like separate UMS Load Balancers and/or UMS Consoles.

For detailed instructions, see Updating HA Installation: With Downtime of the Servers.

IGEL recommends using this HA update method due to a number of advantages:

  • The update procedure is much faster. 
  • No database inconsistencies since no other servers and processes use the database during the update.
  • Only short downtime. Note: Since there is no communication between the servers and devices (during the update of the first UMS Server), user-specific profiles cannot be supplied (IGEL Shared Workplace).

Without Downtime

In this case, the update procedure generally looks as follows:

  1. Update all UMS Servers to a new version, one server after another.
    While being updated, a UMS Server disconnects itself from the productive database and stores a copy of it locally in an embedded Derby database. The copy is created for each server except the last. The last UMS Server also updates the schema of the productive database. After this, all other UMS Servers connect themselves again to the original productive database.
  2. Update other components like separate UMS Load Balancers and/or UMS Consoles.

For detailed instructions, see Updating HA Installation: Without Downtime of the Servers.

By this update method, all UMS Servers can be addressed by the endpoint devices at any time during the update process, e.g. to supply user-specific profiles (IGEL Shared Workplace). However, note the following:

  • The copying of the data from the productive database to the temporary database can take a lot of time. 
  • Requests from devices can interfere with the copying process.
  • Changes in the temporary database are lost as soon as the servers switch back to the productive database when the update is complete.