Skip to main content
Announcements
Have questions about Qlik Connect? Join us live on April 10th, at 11 AM ET: SIGN UP NOW
cancel
Showing results for 
Search instead for 
Did you mean: 
Not applicable

Server Architecture Question

‌We implemented a new structure that does not seem to follow any schema that we have seen via these forums.  However, we have also been experiencing multiple connection issues via our access point in both I.E. Plugin and Ajax.

the design is:

System Load Balancer - pointing to - Web App Servers (2) -both pointing back to - 1 server running QMC only -pointing back to - QVS Servers (6) - connected to NAS

from what we see the connection errors almost all are thrown as tunneler errors In I.E. Aand no connection errors in Ajax.

it also appears to be a timeout connection between web app servers back through QMC.

Does this infrastructure pose any issues that anyone sees In this design?

The the tunneler errors are getting progressively more frequent.  We have found that if we repetitively refresh the browser like 10 times we will finally get in, but for our large user group this is not ideal.

Any input will be appreciated.

thank you

1 Solution

Accepted Solutions
Not applicable
Author

Peter,

Sorry, you are correct, the QMC is not between them, rather off to the side, or overhead.  We install the QMC on an independent server managing the remainder of the environment.

We opted to do a complete re-install and upgrade of QV and it is working now.

Thank you

View solution in original post

5 Replies
Peter_Cammaert
Partner - Champion III
Partner - Champion III

FYI: the explanation is probably not describing your real architecture. It should look more like the second picture in Chapter 17 Clustering QlikView Servers of the QlikView Server Reference Manual. You see, the QMC is not a service, it's not even a program, it's just a web page independently delivered to your browser by the web server inside the QMS (QlikView Management Service). That QMS is a pseudo-external service in that it doesn't interfere in the communications between the browser client/IE plugin/QV Desktop on the one side and one of the multiple QVS services that create the document lyaout, fill it with data and react to selections on the other side. To prove my point, just shut down the QMS - you will not be able to access the QMC anymore. But the AccessPoint will keep working as before, not very well but it works (after refreshing at least ten times).

Back to picture two in chapter 17:  the actual chain is more like:

Load Balancer->Web Servers (2)->(firewall?)->Cluster of 6 QVS Servers->connected to NAS

                      ^                                      ^

                      |                                      |

                      ---------------> QMS / QMC <------------


Please correct me if a made an error in my assumptions.


Tunneling is used to channel native client traffic from the user through a firewall to the QVS that is servicing requests. As such, it isn't used by Ajax clients as they use port 80/443 http traffic anyway that doesn't need tunneling  But it is being used by the native clients whenever they fail to connect straight to the QVS using port 4747 (qvp) and they need to use another camouflaged protocol (qvpx) through the same ports 80/443. You can resolve tunneling problems by simply unblocking post 4747 to your QVS cluster. I'm assuming that you may not want to do that and that there is a firewall between the Web servers (in DMZ?) and the QVS cluster for good reasons.


An important question from my side is this: what kind of errors does the tunneler DLL throw? It seems that the timeout errors occur between the web servers and the QMS/QMC? Are the web server machines also used for other applications / traffic? Did you monitor the cpu/memory load on those machines?


Best,


Peter


Not applicable
Author

‌the architecture is as I described and a place that I think we are having some issues.

system load balancer is pointing to 2 QVWS web servers, those point to a single server running QMC only, then that points to 6 QVS servers.  firewall is disabled on all servers, we have tested to the web servers and everything is good.  My real question is, does the design we put in place work?  With a single server running a QMC behind the QVWS and ahead of the QVS cause problems. 

We have tried several of the tunneling solutions to no avail.  The error it throws is the tunnel.dll not found.  However we are not using IIS so not sure why we are getting pushed to that as well.  Anyway, as you can tell, I am not the IT but more the app and DB design person, just trying to figure out the issue.  I keep coming back to our design, and I cannot find anywhere in any Qlik community or other forums that even suggest our design, so trying to determine if that design could be a part of the issue?

thank you for your input

brian

Peter_Cammaert
Partner - Champion III
Partner - Champion III

Ok, then let's go back to square one. Two questions:

  • Why do you think that in your architecture, QMC ( ! ) is between the two QVWS servers and the QVS cluster? If you use tunneling, traffic always flows from the QVWS straight to a selected QVS server based on your load balancing strategy.
  • Tunneling is builtin into the QVWS service, so the errors must be listed in the QVWS logs. Can you post one here? There should be errors in the Events logs of some of the nodes. See below.

Peter

[Edit] Did some checking out opf possible causes for the intermittent errors. Apparently the most common cause for these problems is a corrupt TicketData.pgo file. This file exists in two places: in the Document Root on the NAS, and in C:\ProgramData\QlikTech\QlikViewServer\ on each node. The timestamp of these files should update with each user accessing a QlikView document. If not or if these files are larger than about 1K, stop all QVS on all nodes, delete all TicketData.pgo files (can't do any harm as they will be recreated) and start the QVS nodes.  See also here: Re: Error on using QvsTunnel IE Plug-in

Not applicable
Author

Peter,

Sorry, you are correct, the QMC is not between them, rather off to the side, or overhead.  We install the QMC on an independent server managing the remainder of the environment.

We opted to do a complete re-install and upgrade of QV and it is working now.

Thank you

Peter_Cammaert
Partner - Champion III
Partner - Champion III

Brian,

good to hear that you managed to resolve the connection problem.

Can you please close the discussion by marking your own answer as correct? The answer will appear in the same frame as the original question, making it easier for other Community members to find a solution to similar problems.

Thanks,

Peter