1 Reply Latest reply on Jul 30, 2014 2:48 PM by richard mcleod

    Monitor Job-Server with F5-Health Monitor

    Steffen Kreis



      we use an F5 LB to manage the traffic to out AppServer farm.

      At the moment we just monitor the "Authentication Service" (PORT 9840) on the CONSOLE instance on each App-Server in order to make sure a server is online.

      We managed that the TCP Handshake on those don't cause any logging alert, by adding this to the log4j.properties


      #Additional entries to reduce logging of F5 Load-Balancer Healthchecks




      In addition to this CONSOLE instance, we run two JOB instances on each box and we would like to monitor the availability for JOB_SERVER-1 as well.


      The reason for this is, that the BMI call-back in the WinPE-Provisioning phase goes against:


      Host: OUR-LB-ADDRESS

      Port: 9831


      So for instance, when JOB_1 crashes (or we shut it down for whatever reason) the OUR-LB-ADDRESS still considers this AppServer as active, as Port 9840 from the CONSOLES_AUTH-Service is still online, but the Provisioning will then fail.


      So in order to get around this we added the JOB_SEVERS SSL-PORT 9831 to the F5 Healthmonitor, so that it does TCP-Handshakes against that port.

      Unfortunately this produces ugly entries in the JOB_Server-LOG which we can't prevent at the moment:


      [23 Apr 2014 10:53:45,021] [SSL-Connections-Thread-4] [WARN] [Anonymous:Anonymous:] [Client] Error authorizing the connect

      1. com.bladelogic.om.infra.mfw.util.BlException: javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake

      at com.bladelogic.om.infra.mfw.net.SSLServerConnection.doHandshake(SSLServerConnection.java:36)

      at com.bladelogic.om.infra.mfw.net.ClientWorkerThread.handleNewConnection(ClientWorkerThread.java:144)

      at com.bladelogic.om.infra.mfw.net.ClientWorkerThread.execute(ClientWorkerThread.java:97)

      at com.bladelogic.om.infra.mfw.net.ClientWorkerThread.execute(ClientWorkerThread.java:27)

      at com.bladelogic.om.infra.app.service.thread.BlBlockingThread.run(BlBlockingThread.java:95)

      Caused by: javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake

      at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(Unknown Source)

      at com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(Unknown Source)

      at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(Unknown Source)

      at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(Unknown Source)

      at com.bladelogic.om.infra.mfw.net.SSLServerConnection.doHandshake(SSLServerConnection.java:32)

      ... 4 more

      Caused by: java.io.EOFException: SSL peer shut down incorrectly

      at com.sun.net.ssl.internal.ssl.InputRecord.read(Unknown Source)

      ... 9 more



      We are not even too sure if "hammering" the SSL-Port is a good idea.

      Has somebody done something similiar and found a way how to monitor such an instance ?

      Maybe use a different Port ?