Context
With the release of ServiceNav version 4.17, ServiceNav Boxes will now be able to migrate their OS version to Ubuntu 20.04 LTS, without the need to deploy a new Box.
Listening to your feedback following the previous OS upgrade (12.04 → 16.04), we were keen to work on a much more packaged feature, allowing for effortless and mass operations.
Where it used to be necessary to instantiate a second box in order to migrate the configuration from the current ServiceNav Box, it is now sufficient to launch the upgrade from the ServiceNav interface for eligible ServiceNav boxes.
What are the prerequisites?
These requirements are checked by the migration script, which will prevent the ServiceNav Box from upgrading if they are not met.
Controls can be put in place to assist you in checking the prerequisites, so that you can migrate your ServiceNav Box smoothly as soon as version 4.17 is available. These controls have been put in place for users of our SaaS platforms.
- ServiceNav Box version: 4.17.0
- Available disk space: 5 GB
- Accessible URL : en.archive.ubuntu.com - This service is provided as an indication (see below)
Due to the public nature of the repositories used, it is preferable to open them for the time of the migration, full internet access from the ServiceNav Box.
At a minimum, the following protocols must be authorized to the outside world (list may evolve according to the update of the repositories called during installation):
| Protocol | Port |
|---|---|
| ping | echo (7) |
| http | 80 |
| https | 443 |
| ftp | 21 |
What are the impacts?
The ServiceNav Box upgrade to Ubuntu 20 causes 2 à 4 h of total unavailability, which implies :
- No notification
- No collection (no raw data)
We are aware that, even when planned, such unavailability is not feasible in some contexts.
For this reason, with the release of version 4.17, we are providing a new Master ServiceNav Box Ubuntu 20.04, associated with a configuration migration scriptThis will allow the OS migration to be carried out in two steps (instantiation of the VM, then migration of the conf), without downtime or lack of raw data.
What precautions should be taken?
Despite all the care taken in developing and testing this feature, there is still a risk that a specific configuration or context within the ServiceNav Box could generate an error and block the upgrade.
It is advisable to schedule these operations during business hours, in order to benefit from Coservit support in case of problems. We also recommend to perform the migration graduallyon small batches of ServiceNav Box, and to perform backups/snapshots on the most critical ServiceNav Boxes, in order to facilitate the rollback in case of problem. In the case of an incorrect state during OS migration, Coservit support will be able to direct you to restore the snapshot and then instantiate a new VM based on the new Master ServiceNav Box and apply the configuration migration script.
Finally, in order to avoid time-consuming alerts/false positives, it is necessary to report maintenance on ServiceNav Boxes, for the duration of the update (recommended value: 4h).
Carrying out the migration
How to proceed
The migration is launched from ServiceNav, in the list of devices (Configuration > General > Box).
It is possible to display all the boxes of your sites or customers, by checking "Account and subordinates" in the company tree.
It is also possible to filter the list to only those boxes that are not up to date.
Identify and select the boxes to be updated
These are the boxes in the status "Upgrade possible" or "Requirements not compliant".
Start the update
Selected and eligible ServiceNav Boxes will start their upgrade.
Possible statuses and actions to be taken
| Status | Type | Comment | Status of the ServiceNav Box | Possible actions |
|---|---|---|---|---|
| Possible update | Initial | This is the initial status a ServiceNav Box must be in to be eligible for migration. | Functional | Start the update |
| Update sent | Transient | The update request has been sent to the ServiceNav Box. | Functional | No |
| Update in progress | Transient | The ServiceNav Box is being updated. This status can last from 2 to 4 hours. | Not functional | No |
| Updated version | Final | Final status, the update is completed and the ServiceNav Box is in version 4.17.0.1, based on Ubuntu 20.04 LTS | Functional | No |
| Update failed | Error | Blocking error that can have many causes. | Not functional | Contact support or restore a snapshot. This error must be dealt with immediately as the ServiceNav Box may be in an unstable and non-functional state. |
| Non-compliant requirements | Error | Blocking error reported following an attempt to migrate a ServiceNav Box that does not meet the prerequisites (disk/access to Ubuntu repository). | Functional | Correct the requirements on the ServiceNav Box (see below), and restart the update |
Important note Restarting RemoteOperationBox (scheduled daily overnight) resets the error status and makes the ServiceNav Boxes eligible for migration again. It is not relevant to run the migration of these ServiceNav Boxes again, unless the root cause of the error has been addressed.
Correcting non-compliant prerequisites
Disc
The free disk space required, before launching the migration, is 5 GB.
If this disk space is not available, it is necessary to add some on the VM and to extend the partition.
URL
The ServiceNav Box must be able to access the internet, and in particular the Ubuntu repository, in order to retrieve the installation sources: en.archive.ubuntu.com.
In case you need to configure a proxy on the ServiceNav Box, please follow the dedicated documentation.
Using Traps
If you use your ServiceNav Box for SNMP Traps collection, it is necessary to reconfigure it, following the documentation.
