QRadar upgrade – Parallel upgrade vs. Patch all

There are two methods commonly used for the QRadar upgrade. These methods apply to the distributed deployment only but not to the All-in-One installation.

By default, the QRadar console has all the capabilities and features. However, when there is a need to improve functionality and there are not enough resources in a single hardware server, we can add a number of additional servers for specific purposes. For example, we can add more collectors or processors or the AppHost. This is what we call a distributed deployment. You can read more about these types by following the link.

Whenever you have more than one appliance but a few only, like two or three both methods are equally acceptable. Nevertheless, if you have more than three appliances to patch, I am pretty sure that only the parallel upgrade should be used. This method saves a significant amount of time which has to be used for the upgrade of QRadar software, so do not hesitate to use this method when you would need to upgrade or patch your system.

Differences in QRadar upgrade methods

Let’s discuss the differences between both methods if you are still not aware of them.

In both methods, there is the console upgraded as the first element, and this is necessary. In the patch-all method after that, the installer is upgrading the second appliance in the queue and when will finish the second and then is dealing with the third. Everything goes one by one until the end using only one screen session. Unfortunately, this costs you a lot of time.

As mentioned before, I suggest using the parallel method and when during the process, you will be asked by the installer, if you are going to upgrade the console only or the whole deployment, chose wisely. Most of the users choose at this stage patch-all and in this way they are wasting their time.

If you would choose to patch the console only and you successfully patch the console first then you can continue with patching at the next step. The distributed deployment can survive whenever you have the console in a different version than the other components. Obviously, you cannot deploy changes at this stage or take backups, so it is suggested to follow the rest of the procedure as soon as possible. You can read more about Parallel upgrades in this document by following the link below. (https://www.ibm.com/support/pages/qradar-how-update-appliances-parallel).

With the latest upgrade of supportability tools, there is a new feature of the all_servers.sh script added which helps you with the monitoring of the parallel upgrade so you will not be expected to run individual ssh windows for each host anymore but you can simply use the command /opt/qradar/support/all_servers.sh -R which will generate only one window for this purpose as seen below.

The other useful switches are below, so as you can see now Parallel updating is much simpler than it was.

        -s PATCH        :: Patch Staging Mode.  This PATCH should include the full path. This option will push the patch to the hosts and mount it.
        -P PATCH        :: Patch mode. This option will install the patch on all the hosts in parallel. Include the name of the patch file.  Console should be patched prior to running this command.
        -R              :: Patch Report and Monitoring mode. This option will display the patch status of all hosts.  The report refreshes every minute, Control-C quits.

Hopefully, with the above hints, your next QRadar upgrade will be much faster and it will run smoothly. Nevertheless do not forget about other features available during this process like running pretests only (/media/upgrades/installer -t) or following (tail -f) the file patches.log