Engine Service on Qlik Proxy node

[AnjaliRai]

Hi All,

Need a help. Engine service should run on Proxy Node at Qlik Sense Server?

We believe it should not , but every time we restart Proxy node, the engine service stops and when restarted it throws an error:

Error: 1067, Service cannot run over server, it fails.

But, when under nodes, if we activate engine and then again restart the service over server, it starts runningwithout throwing an error.

As of now, we are using Sept 2020 Sense version.

Just wandering about the issue. Kindly suggest!

--Anjali Rai

[AnjaliRai]

Not yet raised any Qlik ticket for it. Just wanted to understand if this is something can be solved here first. For sure, will raise one soon to find permanent solution.

[ArnadoSandoval]

Hi @AnjaliRai 

No, you should not change the timeout to start the Windows Server's services for two reasons: (a) Error 1067 does not relate to time-outs (b) Your Proxy Service starts when a local Qlik Engine Service is running.

The error started to happen after upgrading to QlikSense September 2020 version; you already discovered some "new features" handling locks, so the Sep-2020 version probably implemented some new controls/security validations elsewhere.

An important hint is: your QPS (Qlik Proxy Services) start when the local QES (Qlik Engine Services)  is running, it fails otherwise; now it is clear that the QPS does not start when the QES is on a node server!

The Qlik Sense Enterprise installation guide is not clear about the usage of local or domain account on multi-nodes installations, which I suspect could be your issue here.

This old Installation Guide barely cover how to use the System Account starting these services, the architecture of your site suggest that the QPS tries to speak with the QES located on another server, so it does not have enough security credentials to do that (If you read the IBM document about the error 1067, their proposed workaround involve reviewing login-credentials IBM Support )

Questions/Suggestions:

Are you using a unique domain account to start all the Qlik Services across all your nodes? It could be possible that the new Sep-2020 version is enforcing this validation.

 I will check the login credentials for all your Qlik Sense Services across all your nodes; my personal preference is to use the same domain account.

I strongly suspect you are experiencing a login credential issue, so I will open a ticket with Qlik Support highlighting:

• Detail your installation architecture: e.g. number of nodes, and the function of each one.
• You are getting error 1067 starting the QPS when a local QES is not active. It runs when a local QES is active.
• Ask your question regarding keeping the QES active on the same node QPS is hosted; ask them to elaborate their reply.
• Ask them the best practices about the System Account starting your QS services on a multi-node architecture, should they be Local System Accounts or Domain System Accounts?

I can't suggest to change those service accounts into a unique domain account (which I will prefer) as it is a risky procedure to follow/implement on a production environment.

Anjali, this is the best I could suggest, but once again keep me posted with the replies you receive from Qlik Support. 

hph

[AnjaliRai]

Hi @ArnadoSandoval ,

Yes, all our Qlik services runs over server using same account as 'Service Account' ( where password never expires and is common for all). Qlik Engine service over Proxy node also using the same account. (No recent change done)

I will open up a ticket to Qlik about it to understand Root cause for the issue happening.

I will keep you updated. Again, thanks much @ArnadoSandoval  🙂

--Anjali

[ArnadoSandoval]

Hi @AnjaliRai 

Good, I can't wait to hear back from Qlik Support/Engineers !!! We will learn something new very soon !!!!

Thanks for keeping me posted!

[AnjaliRai · Accepted solution]

Hi @ArnadoSandoval ,

Back with an update. Had a discussion with Qlik on the issue  I reported to get better understanding.

As per Qlik, we can go ahead and disable the Qlik Engine Service over Proxy node if that is creating an issue and not starting up on it's own.

If the service is disabled in the QMC, the Central Node Repository Service understands this service is not needed and will not be contacted. Otherwise we would see other issues in the QMC like the node still showing 5 of 5 services running when Engine or another service is disabled. That is not the case here.

There is no requirement for all services to run on a Rim node, if not all services are selected in QMC. Furthermore, in previous versions you would choose the type of Rim that you wish to install and some of the services would be left out and never installed to begin with. This installer model has changed, yet the requirement for services to run remains the same: only if enabled in the QMC, this governs all Central Node communication patters with the Rim nodes.

Nevertheless, since this change was not known nor documented in the Release Notes, Support Team has raised the issue with R&D under ID QB-2562 and they will get back to us once they have some feedback on this report.

But in the meantime, rest assured there is no impact to environment if this service is not running.

--Anjali

[ArnadoSandoval]

Hi @AnjaliRai congratulations, you discovered another hidden feature in Qlik, and I am 100% confident that Qlik will find a solution; it is not easy to keep track of all the improvements and enhancements introduced into a product, much more a product like Qlik.

Suggestion: This is the second time that something like this happens at your side this year, you should negotiate with your Qlik's account manager a procedure allowing you guys to test new version before installing it into production, kind of become a beta-site for Qlik but in a way your production environment is not affected (we could exchange some e-mails if you want me to explain my ideas in a less public media)

Please keep me posted !!!!

[AnjaliRai]

Thanks much @ArnadoSandoval  for helping me out again. Yes, will connect with you for sure. 🙂

[Chanty4u]

good to hear .