TABLE OF CONTENTS
Requirements
Prior to scheduling the SERVERware upgrade procedure, it is crucial to review the following items and ensure their readiness for the support team:
1. KVM access to each host
You are required to provide KVM access to each host as direct server access is mandatory. If public access to iDRAC, iLO, or similar interfaces is unavailable, please include detailed instructions within the ticket regarding the method of access to be utilized (such as RDP, VPN, or similar).
2. Servers firmware update
The firmware of each server should be updated to the latest version to mitigate any potential unexpected issues during the upgrade process
3. Firewall check
If a firewall is in place, it is imperative to ensure that full access is granted to our licensing servers, bicomsystems.com (185.59.92.181) and downloads.bicomsystems.com (157.90.90.217).
4. Preferred date & time
Please note that upgrade procedures are conducted from Monday to Thursday, aligning with the availability of the SERVERware team, and upgrades can be scheduled until 10 PM in your time zone. It is recommended that upgrades be scheduled at least 7 days in advance.
After addressing all four items mentioned above and confirming readiness, it is crucial to understand the process of the SERVERware procedure and its associated downtime which will be explained in the text below.
NOTE: As a recommendation, we advise stopping all VPSs prior to starting the SERVERware upgrade procedure. However, it is important to note that this step is not mandatory, and the upgrade can proceed without interruption even if the VPSs remain active.
SERVERware v3.2.x and lower versions (SERVERware Mirror + backup)
If your SERVERware is currently running on version v3.2.x or lower, we will need to perform a two-step upgrade process. Firstly, the system will be upgraded to version v3.3.x, followed by the upgrade to the latest version, as further explained below:
1. On the scheduled date & time, we will start firstly with the upgrade of the Backup host to 3.3.x, and there will be no downtime as it is the Backup host in question.
2. Secondly, we will proceed with the same on the Secondary Storage Host and there will be no downtime as well.
After upgrading the Secondary host, we would need to initiate a failover so that Secondary and Primary switch places, and that one should not take more than 15 minutes. There will be downtime during the failover, so around 15 minutes in total. During failover, all VPSs will be non-operational.
3. Lastly, we would upgrade the Secondary Host (former Primary) to 3.3.x as well.
The reason why we initiate a failover is that any kind of maintenance should always be done only on the Secondary Host and the Primary should always be up and running.
At that moment all 3 Hosts should be on 3.3.x now and we can proceed with the upgrade to the latest version. The reason why we do not go directly to latest is that there were many core changes in the SERVERware after 3.2.x and we can not risk any kind of data loss.
4. We would repeat the described process above to get all 3 hosts on v4.x and the downtime again would be around 15 minutes again(in case everything goes smoothly without any unexpected issues arising). During failover, all VPSs will be non-operational.
Once all 3 Hosts are on the latest version we would quickly do the GUI update if needed and there will be no downtime during the GUI update. After that, your SERVERware will be running the latest version.
SERVERware v3.3.x and higher versions (SERVERware Mirror + backup)
If your SERVERware is currently running on version v3.3.x or higher, there will be a direct upgrade to the latest version, as further explained below:
1. On the scheduled date & time, we will start firstly with the upgrade of the Backup host to 4.x, and there will be no downtime as it is the Backup host in question.
2. Secondly, we will proceed with the same on the Secondary Storage Host and there will be no downtime as well.
After upgrading the Secondary host, we would need to initiate a failover so that Secondary and Primary switch places, and that one should not take more than 15 minutes. There will be downtime during the failover, so around 15 minutes in total. During failover, all VPSs will be non-operational.
3. Lastly, we would upgrade the Secondary Host (former Primary) to 4.x as well.
The reason why we initiate a failover is that any kind of maintenance should always be done only on the Secondary Host and the Primary should always be up and running.
When the Secondary Storage Host(former Primary) is updated we will ensure all services are up and the pool is ONLINE with no errors. We will issue the failover command again and to revert servers to the original state. There will be downtime during the failover, so around 15 minutes in total. During failover, all VPSs will be non-operational.
At that moment all 3 Hosts should be on 4.x now and we would quickly do the GUI update if needed and there will be no downtime during the GUI update. After that, your SERVERware will be running the latest version.
SERVERware v3.2.x and lower versions (SERVERware Cluster + backup)
If your SERVERware is currently running on version v3.2.x or lower, we will need to perform a two-step upgrade process. Firstly, the system will be upgraded to version v3.3.x, followed by the upgrade to the latest version, as further explained below:
1. On the scheduled date & time, we will start firstly with the upgrade of the Backup host to 3.3.x, and there will be no downtime as it is the Backup host in question.
2. Secondly, we will update PROCESSING HOSTS. While the host is restarting all the VPSs left on host in question will have some downtime (downtime depends on the hardware performance).
We will repeat the same procedure for other hosts in the Cluster until all PROCESSING HOSTS are updated.
3. In third place, we will proceed with the same on the Secondary Storage Host and there will be no downtime.
After upgrading the Secondary host, we would need to initiate a failover so that Secondary and Primary switch places, and that one should not take more than 15 minutes. There will be downtime during the failover, around 15 minutes in total. During failover, any VPSs running on the Primary host will become non-operational(VPSs on Processing Hosts should not be affected).
4. Lastly, we would upgrade the Secondary Host (former Primary) to 3.3.x as well.
At that moment all Hosts should be on 3.3.x now and we can proceed with the upgrade to the latest version. The reason why we do not go directly to latest is that there were many core changes in the SERVERware after 3.2.x and we can not risk any kind of data loss.
5. We would repeat the described process above to get all hosts on v4.x and there will downtime again for each Processing host as well as during failover procedure.
Once all Hosts are on the latest version we would quickly do the GUI update if needed and there will be no downtime during the GUI update. After that, your SERVERware will be running the latest version.
SERVERware v3.3.x and higher versions (SERVERware Cluster + backup)
If your SERVERware is currently running on version v3.3.x or higher, there will be a direct upgrade to the latest version, as further explained below:
1. On the scheduled date & time, we will start firstly with the upgrade of the Backup host to 4.x, and there will be no downtime as it is the Backup host in question.
2. Secondly, we will update PROCESSING HOSTS. While the host is restarting all the VPSs left on host in question will have some downtime (downtime depends on the hardware performance).
We will repeat the same procedure for other hosts in the Cluster until all PROCESSING HOSTS are updated.
3. In third place, we will proceed with the same on the Secondary Storage Host and there will be no downtime.
After upgrading the Secondary host, we would need to initiate a failover so that Secondary and Primary switch places, and that one should not take more than 15 minutes. There will be downtime during the failover, around 15 minutes in total. During failover, any VPSs running on the Primary host will become non-operational(VPSs on Processing Hosts should not be affected).
4. Lastly, we would upgrade the Secondary Host (former Primary) to 4.x as well.
The reason why we initiate a failover is that any kind of maintenance should always be done only on the Secondary Host and the Primary should always be up and running.
When the Secondary Storage Host(former Primary) is updated we will ensure all services are up and the pool is ONLINE with no errors. We will issue the failover command again and to revert servers to the original state.
There will be downtime during the failover, around 15 minutes in total. During failover, any VPSs running on the Primary host will become non-operational(VPSs on Processing host should not be affected).
At that moment all 3 Hosts should be on 4.x now and we would quickly do the GUI update if needed and there will be no downtime during the GUI update. After that, your SERVERware will be running the latest version.
SERVERware v4.3.x and higher versions
If your SERVERware is currently running on version v4.3.x or higher, a GUI update can be performed and there will be no downtime during this process. Subsequently, your SERVERware will be running on the latest version.
However, with the latest updates to version 4.7, we can do a core update, which will result in some downtime. This update should be performed by a Bicom engineer and scheduled with you accordingly.
