Clustering Issues

[#1]

Hi,

We recently got a cluster license and after trying to cluster the 2 server we are experiencing inconsistency.

The setup:

- 2 Servers (for the sake of server names lets call server 1 as server A and server 2 as server B)

- Each server running all the default QV services

- We have put a VIP (Vitual IP with Stickeness) on top of the 2 server in round robin mode so that the load on the web app is distributed equally

- The QVD files are located on server A and are shared with a UNC path (\\ servername\C$\path....). Both servers are pointing to a shared drive

- 64bit server on windows 2008

Issues we are facing:

- Server A where we have put in the cluster license first sees both servers and it appears that the cluster is setup correectly

- Server B does not see server A. It appears that its pointing to local host even though the cluster license has been put in and all the clustering steps are followed

- Server A shows the cluster name and Server B shows local host under cluster section as well as access point server connections

- I have tried to use the QvsStatus tool from server A and see clustering for both server up and running however when going fro B server, I only see localhost

[#2]

Gary,

In a QlikView Server cluster, the single point of failure are the PGO files which are located on a network share. 
Since QlikTech does not currently support storing PGO files on a SAN or NAS, you are stuck with local drive shares. 
If the drive fails (hopefully you have RAID), or the server dies or crashes, your cluster is dead.  I am not aware of a workaround or alternative.

Could you explain this further? We are running QVS in a HOT HOT configuration with a pair of servers. Don't the pgo files have to be in a shared location accessible by both QVS.exe processes ?

[stevedark]

Hi,

We have clustering set up and working successfully (QV11 SR1 Cluster Licence).  We currently have two servers clustered and distribution services installed on both servers but the services are stopped on one server (Hot/Cold).  In the event of the server with distribution services failing we can start distribution services on the other server and hook that into QMC and things carry on as before.

Where we currently have an issue though is if we can not get to QMC because this is on the machine that has failed. In this case we could not bring the distribution services up properly on the other server.

Our first thought was to install Management Services on the second server so that it can be accessed from either server.  However, the server install documentation (and indeed this thread) warns against doing this.

Given that, what would the best way forward be?  We are considering a similar approach for QMC as distribution services - where the server is installed on both machines but only running on one at any given time.  Another consideration is not running the management services on either QlikView server - but rather having it on a separate VM that can be imaged and be protected with VM fail over.  This way whatever affects either of the QlikView servers would not also affect the management console.

Any thoughts anyone has on any of this would be greatly appreciated.

Steve

[dde]

In that scenario I would install the QMS on two servers but set one to disabled.   Move your QMS application config and QVPR to the share.  You would the need a process in place to ensure only one QMS can be up at any one time.

Looking at other comments in this thread:

DSC - I always cluster this, there are no cost implications so why not?

File Share - yes a single point of failure but could be on a Microsoft cluster so will still be a "true" Windows share.  Note it can be a NAS/SAN providing a true Windows share is in front of it (e.g. a VM).

Web Server - for resilience your should have 2+ of these also with a network load balancer in front to handle incoming traffic.  All web servers would talk to all QVSes.

Thanks

Dave

[stevedark]

Hi Dave,

Many thanks for your input here.  The QMS on both servers - but only ever one at a time sounds like a sound approach.  Can you please advise how we can move the QMS application config to our file share?  We already have the root folder (all pgo files), logs, extensions and temporary files on the share - but I believe all the xml config files are still sitting on the master server.

Thanks in advance.

Steve

[dde]

In C:\Program Files\QlikView\ManagementService (exact path may differ) there is a file named QVManagementService.exe.config.  Within there is an application base path.  Two caveats though:

1.) Because the above path is in Program Files it may be overwritten during upgrades

2.) Some of these .config files have some settings you should *never* change.

[stevedark]

Just to make absolutely sure I have this correct, we should:

1. Stop QV services

2. Find the current folder loction in QVManagementService.exe.config

3. Copy all files from that location to a location on the shared drive

4. Modify QVManagementService.exe.config to point to new location

5. Start up services and test single QMS

6. Stop QMS services on first server

7. Install QMS on second server

8. Modify QVManagementService.exe.config on the second server to point to shared location

9. Start QMS services on second machine and test

10. Test stopping and starting QMS on each each server to ensure switch over solid

Many thanks for your help.

[rwunderlich]

Steve, another option is to host your QVPR on SQL Server instead of XML. This makes the config of mutiple QMS' easier.

While a hot/cold QMS is possible, I actually prefer your solution of a seperate QMS image.

-Rob

[stevedark]

Hi Rob - thanks for your input.  The separate QMS image certainly feels simpler to me.  It will be up to the client what they go with though.

Cheers,

Steve

[danielrozental]

Steve, instead of changing config files (that get overwriten by upgrades) you can create a soft link to the correct folder.

Something like this. http://qliktips.blogspot.com.ar/2012/02/move-your-qliktech-programdata-folder.html

[dde]

That's the gist of it yes Steve.  You would need to ensure you were able to be 100% certain that only one QMS can be active at any one time, whether this is done by technology (e.g. MSCS) or having robust manual procedures is up to you.

The single image solution containing the QMS and maybe even the QDS is more common and I deploy that sometimes too.