Hubs and Bridging

  • I've configured 2 brokers according to the documentation on Bridging and observed that:

    • events are bi-directional between the brokers (e.g. you'll see events regardless of which broker you send them to or which broker you subscribe to an event)
    • a service registered on broker1 can be accessed from a client on broker2 and vice versa
    • a service can be registered to broker1 and broker2 and clients connected to broker1 and broker2 will have their requests handled by the closest service
    • if one of the services fails, clients can still access the service on the other broker, regardless of which broker they are connected to

    This appears to be a good design for an Active-Active configuration for high availability.


    Hubs are only referenced in the doc for the brokerstate.policy and it's not clear what benefits they provide and they do not appear to be endpoints for clients. The doc on Bridging does not use them and the fields for "primaryBroker" and "secondaryBroker" are not documented.


    Can you explain how they could or should be used and their impact on an Active-Active configuration?


    Based strictly on Bridging, it would seem a simple setup with 2 servers, each one having a broker instance and possibly multiple service instances connected to each broker, would provide fail-over and load-balancing across the services.

  • Hi Brian-


    That is a great question.


    Typically fabrics are scaled out in a hub-and-spoke pattern. To add further scalability (support additional client connections, etc.) you can add more spokes (brokers) to a hub.



    The image above is an example of a hub-and-spoke deployment of a DXL fabric. Each of the hubs might reside in a different geographic location. The top hub might be the "global" hub that connects the various regions.


    Hubs are critical pieces of the fabric due to the fact that if they fail, the fabric will split. This isn't the case with the lower level brokers as they are there to provide scalability. If any particular broker fails, the fabric as a whole is still connected.


    So, to reduce the possibility of a fabric split, DXL introduced the concept of a hub that can contain two brokers. A hub is not something that is physically deployed, it is just a set of rules that the brokers comprising the hub follow. If one of the brokers goes down, the other will bridge to the parent hub or broker, retaining the connected state of the overall fabric. It is also important to note that both of the brokers are active. They connect to each other, and only one of them is connected to their parent at any given time. The children of the hub will select one of the two brokers to connect to.


    Hopefully that helps. Please let me know if you have any additional questions.


    Thanks a lot,

    Chris

  • Thanks, that's very helpful. If I understood correctly, it sounds like a hub consisting of 2 brokers would act very similar to just bridging 2 brokers with a parentId.


    For a simple deployment of just 2 or 3 brokers, would there be any reason to introduce a hub? Is that more of an advanced configuration, once you start to scale out to many brokers across different sites and you want the resilience between hubs?

  • Thanks, that's very helpful. If I understood correctly, it sounds like a hub consisting of 2 brokers would act very similar to just bridging 2 brokers with a parentId.

    Unfortunately, you can't bridge two brokers and have them bridge to the same parent identifier. A broker can only have one outgoing bridge (it can have an unlimited number of incoming, aka brokers bridging to it). That is the reason the hub exists, the brokers are able to dynamically change who they bridge to based on the presence (or absence) of the other broker in the hub.


    For a simple deployment of just 2 or 3 brokers, would there be any reason to introduce a hub? Is that more of an advanced configuration, once you start to scale out to many brokers across different sites and you want the resilience between hubs?

    For two brokers, no.


    For three brokers, yes.


    By having a hub comprised of two brokers and a single spoke, if a single broker goes down, you are still guaranteed to have the remaining two brokers connected. If you had three brokers connected to each other without a hub, if the middle broker went down, the remaining two would be unable to communicate with each other.


    Hope this helps,

    Chris