16 Replies Latest reply: Jan 16, 2018 1:12 PM by test test RSS

    Going for shared persistence?

    Jai Soni

      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.

        • Re: Going for shared persistence?
          Martin Mahler

          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.

          • Re: Going for shared persistence?
            Rakesh Ranjan

            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.  

            • Re: Going for shared persistence?
              Göran Sander

              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.