Solved: Re: Going for shared persistence? - Qlik Community

jaisoni_trp · ‎2017-01-05

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.

simondachstr · ‎2017-01-18

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

simondachstr · ‎2017-01-18

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 · ‎2017-02-23

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

jaisoni_trp · ‎2017-02-23

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 · ‎2017-03-03

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 · ‎2017-03-03

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 · ‎2017-03-04

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 · ‎2017-03-20

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

simondachstr · ‎2017-03-20

Which statement of all?

simondachstr · ‎2017-03-20

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.