Skip to main content
Announcements
Qlik Connect 2024! Seize endless possibilities! LEARN MORE
cancel
Showing results for 
Search instead for 
Did you mean: 
lobmeister165
Contributor III
Contributor III

Migrating/Upgrading Qlik Sense Feb 2022 2-Node Site to an Aug 2023 4-Node Site

I currently have the following live setup:

  • 2 node site (one central node and one RIM node)
  • Feb 2022 version with Postgres 9.6 repository
  • All apps / static content / logs stored on central node
  • Scheduling, Consumer access to apps and Development all shared between BOTH nodes
  • All script files separately stored on file server and run via include script from app)

I now have access to 2 more servers and would like to deploy the following whilst maintaining the existing  apps, security rules, users, licences and basically everything which is contained within the repository database

  • 4 node site (one central node and 3 RIM nodes)
  • Aug 2023 version with Postgres 14.8 repository (standalone location)
  • 2 RIM nodes to be used as load-balanced consumer nodes
  • 3rd RIM node to be used as a development node
  • Central node to be used as primary reload node but with possibility to share reload tasks with development node

Ideally, in order to perform the cleanest install and to keep the lights on for users for the maximum time I would like

  • The two new servers to be set up first as the Central and Development nodes (Aug 2023 version)
  • Existing Apps/content/logs content to be migrated to the new central node
  • Latterly, the two existing servers to be repurposed as consumer nodes, once the new cluster is operating with existing apps/content

Could anyone please advise the best approach/path/method to this migration/upgrade ?

Labels (1)
1 Solution

Accepted Solutions
kallay
Contributor II
Contributor II

Hello!

The operation you want to do and the way you want to do it will require a lot of downtime and involve changes through postgre sql and many other changes in the settings xmls, probably also the certificates, especially since you want to change who will be the new central node.

I suggest an alternative that involves less downtime and fewer operations to perform, that you add the new node that you want to be central as a failover and then set it as a central node. in this way, you will have covered the situation in which the central node may have problems and drops, and you can also use it for activities such as reloads or consumption for the end-user.

my plan would be:
1. August 2023 installation on new nodes:
a. I add the node that I want to be central to the architecture as failover
b. I add the node that I want to be dev to the architecture as a normal node
2. proxies configuration, load balancing and what other configurations you have set in your architecture for the newly added nodes.
3. upgrade version August 2023 on old nodes.
4. stop services on the current central node so that the new failover node becomes central
5. start services on the old central node that has now become failover.

From point 2 on down, it will involve downtime for end-users.

Obviously, I expect that along the way you will encounter other atypical situations depending on the configurations you have in your architecture: load balancing, custom properties... etc.

The approximate duration of the operation is 8 hours, depending on the specifications of the new servers.

Have fun!

View solution in original post

4 Replies
kallay
Contributor II
Contributor II

Hello!

The operation you want to do and the way you want to do it will require a lot of downtime and involve changes through postgre sql and many other changes in the settings xmls, probably also the certificates, especially since you want to change who will be the new central node.

I suggest an alternative that involves less downtime and fewer operations to perform, that you add the new node that you want to be central as a failover and then set it as a central node. in this way, you will have covered the situation in which the central node may have problems and drops, and you can also use it for activities such as reloads or consumption for the end-user.

my plan would be:
1. August 2023 installation on new nodes:
a. I add the node that I want to be central to the architecture as failover
b. I add the node that I want to be dev to the architecture as a normal node
2. proxies configuration, load balancing and what other configurations you have set in your architecture for the newly added nodes.
3. upgrade version August 2023 on old nodes.
4. stop services on the current central node so that the new failover node becomes central
5. start services on the old central node that has now become failover.

From point 2 on down, it will involve downtime for end-users.

Obviously, I expect that along the way you will encounter other atypical situations depending on the configurations you have in your architecture: load balancing, custom properties... etc.

The approximate duration of the operation is 8 hours, depending on the specifications of the new servers.

Have fun!

lobmeister165
Contributor III
Contributor III
Author

thx @kallay  - how do I manage the upgrade of Postgres to 14.8 ( I understand there is a QPI installer tool from Qlik)- and then to make sure that on completion of the migration, that the repository and app/content file data all reside on the new central node ?

kallay
Contributor II
Contributor II

If I understood correctly from the first post, the postgre server is standalone in another location and I don't see a problem in upgrading it as long as you stop the services on all nodes during the upgrade.
The location of the QVF files is where it was initially set at the time of the architecture installation, and the method proposed above does not change their location.
The connection to the repository is made individually by each node through the "QlikSense Repository service" service and you don't have to do anything about it.

If you want to change their location, you must use the suite of tools that comes with QlikSense. https://community.qlik.com/t5/Official-Support-Articles/How-to-change-the-share-path-in-Qlik-Sense-S...

lobmeister165
Contributor III
Contributor III
Author

@kallay  ..the current repository is 9.6 and not standalone - stored within  the current Feb 2022 QS install folder

However, as part of the migration, I would like to upgrade to 14.8 (as reqd by newer versions) but also to install it to a separate folder (I know this is possible using the QPI util)

Finally I wold want to move the shared location of apps to the new central node so would need to repoint the repo service to this location - think this bit is answered by the article in the URL you posted, thx