7 Replies Latest reply on Oct 10, 2018 12:47 AM by stevewalker74

    Should the /psc URL work on both HA load balanced PSC nodes?

    stevewalker74 Novice

      I have run into a strange issue which occurs following the enablement of two PSC 6.5 nodes in an HA configuration as part of a rolling upgrade from 5.5.

       

      The first PSC node in a new site was migrated from an original Window vCenter 5.5 SSO to PSC 6.5, and subsequently a second new node was joined to the first site in order for replication to be established. I'm using a Citrix NetScaler to load balance the configuration and I noticed at some point after the successful HA repointing was done that I am unable to access the https://hosso01.sbcpureconsult.internal/psc URL. The second node, https://hosso2.sbcpureconsult.internal/psc works correctly and redirects to the load balanced address psc-ha-vip.sbcpureconsult.internal for authentication before displaying the PSC client UI. Irrespective of whichever node is selected I am able to log in to vCenter, then choose Administration, System Configuration, select a node then Manage, Settings or CA without receiving any errors.

       

      If I deliberately drop the first node out of the load balancing config on the NetScaler I don't have any issues when accessing the /psc URL by either host name or load balancer name, but if I try to connect to the first node by its own DNS name or IP I get an HTTP 400 error and the following entry in:

       

      /storage/log/vmware/psc-client/psc-client.log

       

      [2018-10-08 12:05:20.347] [ERROR] tomcat-http--3 com.vmware.vsphere.client.security.websso.MetadataGeneratorImpl - Error when creating idp metadata.

      java.lang.RuntimeException: java.io.IOException: HTTPS hostname wrong:  should be <psc-ha-vip.sbcpureconsult.internal>

       

      It appears that the HTTP 400 error is because the psc-client Tomcat application doesn't start up correctly on the first node anymore, along with an error in..

       

      /storage/log/vmware/rhttpproxy/rhttpproxy.log

       

      2018-10-08T13:27:10.691Z warning rhttpproxy[7FEA4B941700] [Originator@6876 sub=Default] SSL Handshake failed for stream <SSL(<io_obj p:0x00007fea2c098010, h:27, <TCP '192.168.0.117:443'>, <TCP '192.168.0.121:26417'>>)>: N7Vmacore3Ssl12SSLExceptionE(SSL Exception: error:140000DB:SSL routines:SSL routines:short read)

       

      I've repeated the same steps in my lab environment that I experienced in the customer site and can confirm the same behaviour. Let me explain however that all other vCenter functionality is correct and this issue only affects the /psc URL.

       

      Could this be deemed 'correct' behaviour? If I choose https://psc-ha-vip.sbcpureconsult.internal/psc (which is the load balancer address) I am initially only able to connect if the second node is online and happens to be selected.

       

      I am happy to provide detailed steps of the upgrade process, but in the first case I would like to confirm that it should be possible to access the /psc URL on each node deliberately?