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. Server's 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 Earlier Versions (Mirror + Backup)
If your SERVERware is currently running on version v3.2.x or lower, we will need to perform a three-step upgrade process. Firstly, the system will be upgraded to version v3.3.1. Once all hosts are on v3.3.1 version, the system will be upgraded to v4.8.2, followed by the upgrade to the latest version v5.x, as further explained below:
1. On the scheduled date & time, we will start firstly with the upgrade of the Backup host to v3.3.1, 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 with upgrading it to v3.3.1 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 v3.3.1 as well.
NOTE: 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.1 now and we can proceed with the upgrade to the v4.8.2 version. The reason why we do not go directly to v4.8.2 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(1.-3.) to get all 3 hosts on v4.8.2, and the downtime again would be around 15 minutes (in case everything goes smoothly without any unexpected issues arising). During failover, all VPSs will be non-operational.
Once all Hosts are on 4.8.2. version, we would do the core upgrade to final version, v5.x.
5. We would repeat the described process above (1.-3.) to get all 3 hosts on v5.x, and there will be downtime again during the failover procedure.
After that, your SERVERware will be running the latest version.
NOTE: Please be advised that three failovers will be performed. Each failover is expected to result in approximately 15 minutes of downtime. Therefore, you may experience three separate downtime intervals of around 15 minutes each, assuming the process proceeds smoothly. Please note that the exact duration may vary depending on the server hardware.
SERVERware v3.2.x and Earlier Versions (Cluster + Backup)
If your SERVERware is currently running on version v3.2.x or lower, we will need to perform a three-step upgrade process. Firstly, the system will be upgraded to version v3.3.1. Once all hosts are on v3.3.1 version, the system will be upgraded to v4.8.2, followed by the upgrade to the latest version v5.x, as further explained below:
1. On the scheduled date & time, we will start firstly with the upgrade of the Backup host to 3.3.1, 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 those VPSs left on the Processing 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 v3.3.1 as well.
At that moment all Hosts should be on v3.3.1 now and we can proceed with the upgrade to the v4.8.2 version.
5. We would repeat the described process above(1.-4.) to get all hosts on v4.8.2, and there will be downtime again for each Processing host as well as during the failover procedure.
Once all Hosts are on v4.8.2. version, we would do the core upgrade to the final version, v5.x.
6. We would repeat the described process above(1.-4.) to get all hosts on v5.x, and there will be downtime again for each Processing host as well as during the failover procedure.
After that, your SERVERware will be running the latest version.
NOTE: Please be advised that three failovers will be performed. Each failover is expected to result in approximately 15 minutes of downtime. Therefore, you may experience separate downtime intervals of around 15 minutes each, assuming the process proceeds smoothly. Please note that failover downtime will affect only the VPSs running on the Primary host during each failover. Additionally, during the reboot of Processing hosts, downtime will occur only for the VPSs running on the affected host. The exact duration may vary depending on the server hardware.
SERVERware v3.3.x - v4.2.x (Mirror + Backup)
If your SERVERware is currently running on a version from v3.3.x to v4.2.x , there will be a two-step upgrade process. Firstly, the system will be upgraded to version v4.8.2. Once all hosts are on v4.8.2 version, the system will be upgraded to v5.x, as further explained below:
1. On the scheduled date & time, we will start firstly with the upgrade of the Backup host to 4.8.2, 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.8.2 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 v4.8.2 now and we can proceed with the upgrade to the final v5.x version.
4. We would repeat the described process above(1.-3.) to get all 3 hosts on v5.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.
After that, your SERVERware will be running the latest version.
NOTE: Please be advised that two failovers will be performed. Each failover is expected to result in approximately 15 minutes of downtime. Therefore, you may experience two separate downtime intervals of around 15 minutes each, assuming the process proceeds smoothly. Please note that the exact duration may vary depending on the server hardware.
SERVERware v3.3.x - v4.2.x (Cluster + Backup)
If your SERVERware is currently running on a version from v3.3.x to v4.2.x , there will be a two-step upgrade process. Firstly, the system will be upgraded to version v4.8.2. Once all hosts are on v4.8.2 version, the system will be upgraded to v5.x, as further explained below:
1. On the scheduled date & time, we will start firstly with the upgrade of the Backup host to 4.8.2, 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.8.2 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.
At that moment all Hosts should be on v4.8.2 now and we can proceed with the upgrade to the v5.x version.
5. We would repeat the described process above(1.-4.) to get all hosts on v5.x, and there will be downtime again for each Processing host as well as during the failover procedure.
After that, your SERVERware will be running the latest version.
NOTE: Please be advised that three failovers will be performed. Each failover is expected to result in approximately 15 minutes of downtime. Therefore, you may experience separate downtime intervals of around 15 minutes each, assuming the process proceeds smoothly. Please note that failover downtime will affect only the VPSs running on the Primary host during each failover. Additionally, during the reboot of Processing hosts, downtime will occur only for the VPSs running on the affected host. The exact duration may vary depending on the server hardware.
SERVERware v4.3.x - v4.8.x (Mirror + Backup)
If your SERVERware is currently running on version v4.3.x or higher, there will be a one-step core upgrade to v5.x.
1. On the scheduled date & time, we will start firstly with the upgrade of the Backup host to v5.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 v5.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 v5.x now.
We will perform one final failover to return the host to its original location. This process will cause downtime of approximately 15 minutes. During the failover, all VPSs will be non-operational.
NOTE: Please be advised that two failovers will be performed. Each failover is expected to result in approximately 15 minutes of downtime. Therefore, you may experience two separate downtime intervals of around 15 minutes each, assuming the process proceeds smoothly. Please note that the exact duration may vary depending on the server hardware.
SERVERware v4.3.x and 4.8.x (Cluster + Backup)
If your SERVERware is currently running on version v4.3.x or higher, there will be a one-step core upgrade to v5.x
1. On the scheduled date & time, we will start firstly with the upgrade of the Backup host to v5.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 v5.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.
At that moment, all 3 Hosts should be on v5.x. now.
We will perform one final failover to return the host to its original location.
NOTE: Please be advised that two failovers will be performed. Each failover is expected to result in approximately 15 minutes of downtime. Therefore, you may experience separate downtime intervals of around 15 minutes each, assuming the process proceeds smoothly. Also, downtime is expected for VPSs while rebooting Processing hosts. Please note that the exact duration may vary depending on the server hardware.
SERVERware v5.x
If your SERVERware is running on v5.x, it is only necessary to perform a GUI update, which will not cause any downtime.
The GUI update can be performed on your side, or a member of the Support Team can assist you.
