Skip to main content
Announcements
Join us at Qlik Connect for 3 magical days of learning, networking,and inspiration! REGISTER TODAY and save!
cancel
Showing results for 
Search instead for 
Did you mean: 
jaisoni_trp
Creator II
Creator II

Going for shared persistence?

For various reasons/bugs Qlik is recommending to upgrade Sense environment to Shared Persistence. There are significant architecture changes which comes with 3.1 and wanted to have customers opinion if you are ok upgrading the environment to 3.1 from 3.0. What are the challenges you have come across, any insight you could share.

1 Solution

Accepted Solutions
simondachstr
Luminary Alumni
Luminary Alumni

Qlik recommends shared persistence because their initial approach to a synchronized multi-node environment, called replication synchronization, simply does not work. It works, until it fails, and then it's almost impossible to bring up the services without calling in Qlik's support engineers (fyi, Andrew Delaney from Qlik is your repository ninja if you have issues).

Hence, shared persistence was developed last year, which synchronizes the multi-node environment differently. Instead of replicating all apps and repository content across all nodes (rep sync) it hosts everything on a central node and distributes the apps into the memory of each slave node. This way, still the whole infrastructure is still in sync in the eyes of the user. But on the back-end, if everything is only kept in RAM on the rim nodes, it implies a HOT-DR setup is not feasible (Unless you have a smart DFS replication setup for your database server). If the main server (where all the apps are stored) fails over, no reloads are possible and the apps are only available in RAM on the rest of the infrastructure (e.g. a server restart would wipe the in-memory loaded app out).

Replication synchronization on the other hand ensures all nodes (rim & central nodes) have the apps and repository replicated locally (can be customized using sync rules), meaning that while in sync, each node can also fully operate on its own, effectively making it an ideal hot DR solution.

My personal recommendation is the following:

- Shared persistence (Shared synchronization) is not mature enough as it has only been released in a hasty approach to remedy existing rep sync issues and has, in my eyes, not been proven to work reliably yet (it has not been unreliable either).

- Replication synchronization is very powerful in concept, but unfortunately not bulletproof in QS.

-> If you plan to have a small environment with not too many apps (<50) and 2-3 nodes, go with rep-sync. If on the other hand you want to be able to scale horizontally (3+ servers) with multiple apps and/or the use of frequent on-demand app generation, please look to go with shared persistence. You will need to setup a separate DR environment though, making it a bit more costly.

View solution in original post

16 Replies
simondachstr
Luminary Alumni
Luminary Alumni

Qlik recommends shared persistence because their initial approach to a synchronized multi-node environment, called replication synchronization, simply does not work. It works, until it fails, and then it's almost impossible to bring up the services without calling in Qlik's support engineers (fyi, Andrew Delaney from Qlik is your repository ninja if you have issues).

Hence, shared persistence was developed last year, which synchronizes the multi-node environment differently. Instead of replicating all apps and repository content across all nodes (rep sync) it hosts everything on a central node and distributes the apps into the memory of each slave node. This way, still the whole infrastructure is still in sync in the eyes of the user. But on the back-end, if everything is only kept in RAM on the rim nodes, it implies a HOT-DR setup is not feasible (Unless you have a smart DFS replication setup for your database server). If the main server (where all the apps are stored) fails over, no reloads are possible and the apps are only available in RAM on the rest of the infrastructure (e.g. a server restart would wipe the in-memory loaded app out).

Replication synchronization on the other hand ensures all nodes (rim & central nodes) have the apps and repository replicated locally (can be customized using sync rules), meaning that while in sync, each node can also fully operate on its own, effectively making it an ideal hot DR solution.

My personal recommendation is the following:

- Shared persistence (Shared synchronization) is not mature enough as it has only been released in a hasty approach to remedy existing rep sync issues and has, in my eyes, not been proven to work reliably yet (it has not been unreliable either).

- Replication synchronization is very powerful in concept, but unfortunately not bulletproof in QS.

-> If you plan to have a small environment with not too many apps (<50) and 2-3 nodes, go with rep-sync. If on the other hand you want to be able to scale horizontally (3+ servers) with multiple apps and/or the use of frequent on-demand app generation, please look to go with shared persistence. You will need to setup a separate DR environment though, making it a bit more costly.

simondachstr
Luminary Alumni
Luminary Alumni

So, apparently with 4.0 Qlik Sense will deprecate replication synchronization.

jaisoni_trp
Creator II
Creator II
Author

We have a large deployment with multi nodes. Migrated to Shared persistence on 3.1.4. Unfortunately started seeing lock erros in apps resulting in publishing failures.

korsikov
Partner - Specialist III
Partner - Specialist III

thanks for your explanation.

have information whether in version 4.0 synchronized? my guess is that standalone version, in fact synchronized and shared persistense with native migration.

Anonymous
Not applicable

We have been trying to make QS work for us since Version 1.1. Stability due to synchronization related issues have been biggest challenge. If your deployment is small, best to go for single node installation. If it is VM which is replicated to DR site, you are all covered.

If deployment is large, then moving to shared persistence is definitely recommended. New version 3.2 is looking comparatively better. 3.1 has serious repository query issues which cause extremely poor performance and unexpected behavior.  

mountaindude
Partner Ambassador
Partner Ambassador

I very much agree with the recommendation to go with shared persistence (SP) for anything larger than 2-3 nodes and/or 100+ apps.

We have been running SP for quite a few months now (with significant numbers of apps users and apps), and while not 100% perfect, I would say it's 90% there. Performance can always be improved, there are features in the QMC you wish were there etc - but all in all SP is solid.  Performance improvements in 3.2 will only make it better.

Please mark the post as a solution if it provided you with a solution to the topic at hand. Thanks!
alexbjorlig
Creator
Creator

Do you have a link to a Qlik article supporting this statement?

simondachstr
Luminary Alumni
Luminary Alumni

Which statement of all?

simondachstr
Luminary Alumni
Luminary Alumni

All multi-node environments are synchronized - they just use a different approach.

With 4.0, shared persistence will be the only way to deploy a multi-node QS architecture going forward.