Grouper Users - Open Discussion List

[Chris Hyzer <>]

Try putting this in the grouper-ws.properties:

 

ws.diagnostic.ignore.loader_MAINTENANCE__grouperReport = true

 

 

I added that line to the diagnostics doc:

 

https://spaces.internet2.edu/display/Grouper/Grouper+diagnostics

 

You should be able to ignore any part of the diagnostics for just this reason…

 

Thanks,

Chris

 

From: Gagné Sébastien [mailto:]
Sent: Wednesday, February 15, 2012 2:15 PM
To: Chris Hyzer
Cc:
Subject: RE: High availability of Grouper's processes

 

Hi Chris,

I tested the status service and found something : it will always return an error if you didn’t activate the daily reports, even though you can disable them with an empty cron string.

 

I was wondering why the status with type=all still gave me an exception even after I started the the loader. I had left the “grouper-loader.properties” file pretty much untouched but I soon realised that I had to enable the daily reports. All the other status Type returned Ok with some SUCCESS items.

 

Is it normal behaviour ? Should I open a JIRA about it ? Shouldn’t the status service check if the daily reports are enabled or not before throwing an exception (I don’t know how you could do it though, maybe a property in the web service)?

 

Would there be a way to use the status service without the daily reports ? I guess I would have to edit the source files and recompile them.

 

Thank you

 

 

De : Chris Hyzer [mailto:]
Envoyé : 14 février 2012 13:31
À : Gagné Sébastien
Cc :
Objet : RE: High availability of Grouper's processes

 

Yes, the status servlet checks the logs in the DB.  If you were using monitoring software, you can check that the process is running (SNMP or something?) and if it is not running or the server is not available then kick it off somewhere else. 

 

Ø  So, if the loader is running on any one server, the diagnostic Web Service application from ALL the servers will return that it is properly working, right ?

 

Yes

 

Ø  So there would be no problem using the monitoring app (like Nagios) with the load balancer in front of the webservers

 

Well, that servlet will return failure if any one job fails.  And a job could fail if the backend datasource wasn’t available or if it tried to feed in unresolvable subjects.  So if the servlet gives an error, it doesn’t mean that you could start the daemons somewhere else.  You need to check if the daemon process is running…

 

Thanks,

Chris

 

From: Gagné Sébastien [mailto:]
Sent: Tuesday, February 14, 2012 1:24 PM
To: Chris Hyzer
Subject: RE: High availability of Grouper's processes

 

Hi Chris

So I understand the web service properly : what does it check ? I thought it was checking the physical machine and seeing if the loader was running. But according to what Shilen told me, it checks the database for the traces left by the proper execution of the daemon/loader/provisioning, am I right ?

 

So, if the loader is running on any one server, the diagnostic Web Service application from ALL the servers will return that it is properly working, right ?

 

Based on this deployment :

·         Server1 is running UI, WS, loader

·         Server2 is running UI, WS

 

My initial thought was that a call to the diagnostic WS on server1 would return “Ok”, while the diagnostic call on server2 would return “Failure”. According to what Shilen said, a call to server1 or server2 will return “Ok” since it’s checking the database and both will return “Failure” if the loader fails on server1. So there would be no problem using the monitoring app (like Nagios) with the load balancer in front of the webservers

 

Thanks

 

 

De : Chris Hyzer [mailto:]
Envoyé : 10 février 2012 23:56
À : Gagné Sébastien;
Objet : RE: High availability of Grouper's processes

 

Our current solution is to monitor the processes with this WS servlet:

 

https://spaces.internet2.edu/display/Grouper/Grouper+diagnostics

 

At Penn we do this with nagios.  It will send an email if there is a job which doesn’t run within in allotted amount of time.  We have never had to run the daemons on another server, not sometimes if the loader job has unresolvable subjects we get an email and need to adjust the query and rerun the job manually.

 

It would be bad if the daemon was running on more than one server at one time, so the manual failover seems like the right thing to do (reduces chance of false positives).  But if you wanted it automatic I could picture checking the daemon loader process to see if it is running and if not kick it off somewhere else…  at some point we would like to run the loader in a webapp (WS?) fyi…

 

Thanks,

Chris

 

From: [mailto:] On Behalf Of Gagné Sébastien
Sent: Friday, February 10, 2012 4:06 PM
To:
Subject: [grouper-users] High availability of Grouper's processes

 

Hi,

We want to deploy Grouper in a High Availability environment and I have a few last questions regarding Grouper’s processes. Here I’m talking about provisioning (LDAPPCNG), the Grouper Deamon (Grouper Loader) and the Group Loader. Is there a way to have those in High Availability ?

 

What I found in previous discussion is people have the Ui/Tomcat on 2 load balanced Hosts, but only have one server running the Grouper Processes and, should a failure happen, they would start them on the second server. My guess is that it’s still the case, but maybe I’m wrong. Is there any new development or solution for this problem ? Any synchronisation available ?

 

Maybe one idea would be to have a scheduler/watcher check the first server’s health and if it fails it would automatically start the processes on the second one.

 

Thanks

 

PS. Will all this change with real-time provisioning ? From the quick glance I had from TomZ’s manual it seems the real-time provisioning is in the Grouper Loader so I think my question still stands for this.

 

 

Sébastien Gagné,     | Analyste en informatique

514-343-6111 x33844  | Université de Montréal,

                     | Pavillon Roger-Gaudry, local X-100-11