Continuing the theme of discovering and tinkering with HP OneView and it’s API’s ..
The recent announcement of interoperability between HPE and Arista led me to investigate one of the more hidden aspects of HP OneView, albeit the most critical component as without the MessageBus then OneView simply wouldn’t work. The MessageBus handles two different types (or under the covers queues) which handle different types of information:
This message queue handles information such as configuration changes (new hardware plugged in), network configuration changes and failures etc.
This message queue contains information around things such as power draw or thermal/CPU metrics and details.
In this post i’ll be focussing on the state-change message bus and how Aristas EOS operating system on switches deals with changes within HP OneView. Also for most end-users it is this MessageBus that is going to be the most heavily used component and has the most interaction from end-users (either GUI of API) and also from the hardware changing (new/replacing etc.).
So why a MessageBus in the first place?
The majority of monitoring and state-based systems currently make use of polling various parts that make up the system. Essentially a digital “hourglass” asking the system to examine everything once the time is exhausted, and this carries two risks:
- Poll too infrequently and a component can be broken without being noticed.
- Poll too frequently and excessive load is introduced within both the monitoring subsystems and the systems being examined.
I’ve also come across frequent issues with some server infrastructure tools based on large java applications that poll the systems losing their synchronisation, which has effectively broken the management system requiring a restart.
The MessageBus will only send information in the event of a change of state, meaning that in the event of a state-changing e.g. New blade inserted then anything connected to the MessageBus will be notified of this change. For most end-users the functionality of the MessageBus is reflected in the “live” behaviour of the web-based UI, as multiple users make changes or hardware states change the MessageBus informs the UI and the effect/changes are displayed immediately.
How else can you make use of the MessageBus (i.e. What are Arista doing?)
The MessageBus is available for use for anyone with a OneView account and consists of a few steps:
- Log into HP OneView and generate the certificates
- Download the certificates
- Spend 48-72 hours banging your head against a poorly documented C RabbitMQ library (working now though)
- Use the certificates to authenticate to the RabbitMQ (underlying technology for MessageBus)
- Read Messages (JSON) on the queues
Originally, HP OneView would allow networking configuration down to the servers(downlinks) or on the interconnects (uplinks) to the outside world meaning that there would still be some networking configuration to be taken care of in the access/core areas of the datacenter (trunking new VLANs for example).
Arista have made use of the MessageBus in HP OneView in order to simplify and automate networking tasks in the data centre by having the MessageBus notify them of changes that have been made to networking configuration inside HP OneView, the Arista switches can then update their configuration and ensure that the configuration is correct end-to-end. This open design means that any vendor can make use of APIs and the MessageBus in order to extend the functionality and area of automation present in the datacenter, either by being notified of changes (MessageBus) or pushing configuration down to OneView Infrastructure (APIs).
Arista are tapping into the MessageBus and are specifically watching for changes to the logical-interconnects (vlan changes) and using this information to update the switch ports to ensure that this vlan configuration is automated end-to-end. As the logical-interconnects are changed the tasks to make the modifications are added to the MessageBus along with messages stating that the task has started and has completed. The ROUTING_KEY that is used will also determine which messages are received by the end client simplifying and reducing the amount of messages to handle and process. The ROUTING_KEY “scmb.#” will result in ANY message that is on the scmb (State-Change Message Bus) being delivered, however Arista is more than likely only looking at the changes that will effect the logical interconnects so they would use the ROUTING_KEY “scmb.logical-interconnect-groups.#” which will only deliver messages about the logical interconnects.
So using OVCLI (http://github.com/thebsdbox/OVCLI), I can attach to the MessageBus and watch the JSON fly around as changes are made in the exact same way that Arista are:
Using the line:
OVCLI 192.168.0.91 MESSAGEBUS LISTEN scmb.logical-interconnect-groups.#
We are on the MessageBus being informed about changes to the logical interconnects, and if you look at the GUI i’ve just added a new network to the group bringing the total network up to 7 (hence this JSON message being created). If we parse through the JSON as Arista would, we will find a networkURIs array that will list all of the networks attached to logical interfaces:
Arista finally will need to speak to the API to get a list of URI to vlan mappings so that it can apply these vlans to the switch ports.
Note: All vlans attached to the interconnects will be listed, not just additions/deletions so the switch will either need to determine what’s has changed or just re-apply the entire list of vlans.