How to get which broker is in control in HA pair (primary or backup) programmatically

How to get which broker is in control in HA pair (primary or backup) programmatically using SEMP API's or any other means but not using soladmin.

Comments

  • Aaron
    Aaron Member, Administrator, Moderator, Employee Posts: 508 admin

    Hi @tejchowsalkar, welcome to the community!

    For broker-level / system-level commands, you'll find SEMPv1 to be your friend. Something like this will work:

    curl -u admin:admin http://localhost:8080/SEMP -d '<rpc><show><redundancy/></show></rpc>' | grep activity
    


  • uherbst
    uherbst Member, Employee Posts: 121 Solace Employee

    You could also ask the health-check port:

    curl http://localhost:5550/health-check/guaranteed-active

  • tejchowsalkar
    tejchowsalkar Member Posts: 5

    Thanks @Aaron & @uherbst for the reply.


    I'm getting below error while hitting the curl command as provided by you @Aaron , I'm not sure if I'm missing anything here

    <rpc-reply semp-version="soltr/10_0_1VMR">

    <parse-error>invalid message: schema validation error</parse-error>

    </rpc-reply>


    Whereas im not getting any response while hitting the curl command provided by you @uherbst .

    I'm using pubsub+ manager host & port with https, please correct me if i'm wrong here.

  • uherbst
    uherbst Member, Employee Posts: 121 Solace Employee

    Hi @tejchowsalkar,

    sorry to give you incomplete examples.


    For the health-check: Don't use the SEMP port, use the health-check port. In most cases, this is 5550.


    And the difference response between active and inactive broker is the HTTP-return-code.


    Inactive broker:

    [appuser@kilo-production-3680sypaq80-solace-backup-0 sw]$ curl -vvv http://localhost:5550/health-check/guaranteed-active
    *  Trying 127.0.0.1...
    * TCP_NODELAY set
    * Connected to localhost (127.0.0.1) port 5550 (#0)
    > GET /health-check/guaranteed-active HTTP/1.1
    > Host: localhost:5550
    > User-Agent: curl/7.61.1
    > Accept: */*
    >
    < HTTP/1.1 503 Service Unavailable - Message Spool Down
    < Cache-Control: no-cache
    < Content-Length: 0
    <
    * Connection #0 to host localhost left intact
    

    You see HTTP/503....


    Active Broker:

    [appuser@kilo-production-3680sypaq80-solace-primary-0 sw]$ curl -vvv http://localhost:5550/health-check/guaranteed-active
    *  Trying 127.0.0.1...
    * TCP_NODELAY set
    * Connected to localhost (127.0.0.1) port 5550 (#0)
    > GET /health-check/guaranteed-active HTTP/1.1
    > Host: localhost:5550
    > User-Agent: curl/7.61.1
    > Accept: */*
    >
    < HTTP/1.1 200 OK
    < Cache-Control: no-cache
    < Content-Length: 0
    <
    * Connection #0 to host localhost left intact
    

    => The active broker returns a HTTP/200.


    Uli

  • Aaron
    Aaron Member, Administrator, Moderator, Employee Posts: 508 admin

    The health check just returns 200 OK if the broker active, otherwise something else. https://docs.solace.com/Admin/Load-Balancer-Health-Check.htm

    Uli's way is probably the better / less complicated option.

    I'm not sure why you're getting a schema validation error, works for me??

    $ curl -u admin:admin http://localhost:8080/SEMP -d '<rpc><show><redundancy/></show></rpc>'
    
    <rpc-reply semp-version="soltr/10_3_1VMR">
      <rpc>
        <show>
          <redundancy>
            <config-status>Shutdown</config-status>
            <redundancy-status>Down</redundancy-status>
            <operating-mode>Message Routing Node</operating-mode>
            <switchover-mechanism>Hostlist</switchover-mechanism>
            <auto-revert>false</auto-revert>
            <redundancy-mode>N/A</redundancy-mode>
            <active-standby-role>Primary</active-standby-role>
            <mate-router-name></mate-router-name>
            <oper-status>
              <adb-link-up>false</adb-link-up>
              <adb-hello-up>false</adb-hello-up>
            </oper-status>
    ...
    

    That command has been around forever.

  • tejchowsalkar
    tejchowsalkar Member Posts: 5

    Thanks @Aaron & @uherbst - Im using Pubsub+ manager host & post is that correct? This is a SAAS broker managed by solace.

  • Aaron
    Aaron Member, Administrator, Moderator, Employee Posts: 508 admin

    AH! You're using Solace Cloud. Ok, the default admin username/password won't work b/c it's scoped to just your VPN, you cannot interrogate the broker for system-level commands.

    In the Cloud Console (not the PubSub+ Manager), within your specific broker if you click on "Manage", you should see something that looks like this:

    The "viewers" credentials are system-level, but read-only. That username + password should work.

  • uherbst
    uherbst Member, Employee Posts: 121 Solace Employee

    For Aarons way, PS+ Manager host + port are correct.

    For my suggestion (health-check), use PS+-Manager host and port 5550.


    BUT: If you use Solace Cloud brokers (our SAAS solution), you will always see the active broker, because the loadbalancer in front of the HA group handle that the right way.

  • Aaron
    Aaron Member, Administrator, Moderator, Employee Posts: 508 admin

    @uherbst it doesn't appear that 5550 is exposed for Solace Cloud? I'm trying for my test broker and it's not working, the connection just hangs. I've tried a bunch of different combinations, ports, etc. I've asked internally and will report back here. They may just not expose it since the SaaS handles everything for you via the load balancer..?

    @tejchowsalkar Uli is right, the SaaS takes care of which broker to point at for you. What is the reason / use-case for trying to figure this out? There are some other options too. You can query the broker for its hostname, and (due to the load balancer) the active one will respond, so you'll know which is currently active. Something like:

    curl -u my-broker-admin:password https://abc.messaging.solace.cloud:943/SEMP -d '<rpc><show><ho
    stname/></show></rpc>'
    

    "show hostname" will work with the regular admin credentials.

  • tejchowsalkar
    tejchowsalkar Member Posts: 5

    Hi @Aaron ,

    The use case here is we are using SEMP over message bus to get the queue statistics, for that we need the router name which is in control so we want to query and get the broker name first & then query SEMP over message bus. Do we have a way to get the router name for software brokers & on premise brokers on K8's using SEMP over message bus.

  • Aaron
    Aaron Member, Administrator, Moderator, Employee Posts: 508 admin
    edited April 2023 #12

    Ok. Thanks for the additional details. SEMP over the message bus is a whole different kettle of fish. First off: why are you looking to used SEMP-over-MB? It was an old feature that we added for particular use cases a long time ago... and it not typically considered a best practice. However, in some instances, it can be very useful.

    One of the main issues with its use is that if one deployed app needs it, then often many applications that connect into Solace use the same code, and you now have dozens or hundreds of app querying for SEMP statistics... and this puts significant load on the broker's control plane. It's better to query the broker once (with a broker monitoring app), and store or distribute that data to other apps that require it.

    Further: you cannot query any system-level or broker-level commands using SEMP-over-MB. Only objects available inside your VPN. See docs here: https://docs.solace.com/Admin/SEMP/Using-Legacy-SEMP.htm Specifically:

    The event broker will reject any requests for information about any managed object not contained in that Message VPN.

    To find out the broker's router name (which can be different than the hostname), you can ask the API once you've connected to Solace. Something like:

    // Extract the router name.
    String routerName = (String) session.getCapability(CapabilityType.PEER_ROUTER_NAME);
    
    final String SEMP_TOPIC_STRING = String.format("#SEMP/%s/SHOW", routerName);
    final Topic SEMP_TOPIC = JCSMPFactory.onlyInstance().createTopic(SEMP_TOPIC_STRING);
    

    Note that for SEMP-over-MB to work, you have to enable it inside your VPN's configuration. And only SEMPv1 is supported.

    But again, I'd ask what your use case is? Messaging apps themselves don't usually need to poll for this info, it should be done by a management app using the HTTP SEMP interface.