Qlik Community

Qlik Sense Deployment & Management

Discussion board where members learn more about Qlik Sense Installation, Deployment and Management.

jaisoni_trp
Contributor 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
Valued Contributor III

Re: Going for shared persistence?

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.

16 Replies
simondachstr
Valued Contributor III

Re: Going for shared persistence?

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
Valued Contributor III

Re: Going for shared persistence?

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

jaisoni_trp
Contributor II

Re: Going for shared persistence?

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
Valued Contributor II

Re: Going for shared persistence?

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.

rakesh038
New Contributor

Re: Going for shared persistence?

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
Contributor III

Re: Going for shared persistence?

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.

alexbjorlig
Contributor

Re: Going for shared persistence?

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

simondachstr
Valued Contributor III

Re: Going for shared persistence?

Which statement of all?

simondachstr
Valued Contributor III

Re: Going for shared persistence?

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.

Community Browser