What is the difference between queues and tunnels,Whether both are doing same work ?
So Queues and tunnels do not do the same job. they very often work together but have different functions.
A queue is a place on hub that stores and passes messages.
There are three types of Queues
Post queue - takes incoming messages and moves them to another location.
Attach Queue - Storage location for local messages. Must be used with a Get Queue or probe to have messages removed.
Get Queue - This is a queue that goes to another hub and retrieves messages from an attach queue.
A tunnel allows encrypted communication between two hubs on different networks.
Data Center A has a the primary hub.
Data Center B as a secondary client hub
Both location have internet access but no direct connection to each other networks.
This is where you would setup a tunnel between these two locations to allow for communication to happen.
Infrastructure manager and admin console direct traffic over tunnels to allow for remove configuration.
Hubs move messages over the tunnels as well.
Queues are used to pass messages from robot to hub and hub to hub
Tunnels are used when there is a firewall between two hubs. The Queues will pass the messages through the tunnel.
CA Nimsoft Admin Console Probes: hub v7.1
Nimsoft components use queues to pass messages. Messages are placed into queues based on their Subject ID, which classifies every Nimsoft message. Most queues are created automatically during installation (when hub-to-robot communication is set up) or deployment (during which some probes create the queues they require).
Hub-to-hub queues must be created manually. If you have any secondary hubs in your deployment, you must create queues so that those hubs can communicate with the primary hub.
Most companies today have one or more firewalls in their network, both internally between different networks and externally against a DMZ or Internet. Network administrators are often reluctant to open a firewall for a lot of IP addresses and ports in order to make it possible for Management applications to work. This makes it difficult to administrate and monitor the whole network from a central location.
The solution is to set up a tunnel between two Hubs that is separated by a Firewall. The Tunnel sets up a VPN-like (Virtual Private Network) connection between the two Hubs and enables all Nimsoft requests and messages to be routed over the Tunnel and dispatched on the other side. This routing will be transparent to all the users within Nimsoft. The only requirement for setting up a Tunnel is that one of the Firewalls opens for connection to the target Hub on one port.
Thanks Gene and Silvio!!
"Queues are used to pass messages from robot to hub and hub to hub."
Messages must push automatically from robot to hub.it requires any queues?..Hub to Hub we need queues.
Performance data will be handled by tunnel or queues to primary UIM. kindly confirm!
To provide answers, here's some of your text with my comment:
Queues are used between hubs. The robot to hub communication happens automatically and "queuing" is handled by the spooler probe on the robot.
Messages must push automatically from robot to hub.
Yes this is automatic.
it requires any queues?..
Hub to Hub we need queues.
Yes, you need an attach queue where the data originates and you need a get queue on the hub that the data is destined for. You can also use post queues but they don't have guaranteed delivery.
Performance data will be handled by tunnel or queues to primary UIM.
Both. When you create an attach queue, you specify the "subjects" that it will hold on to. So, it's possible to create a queue that will allow everything to be forwareded by specifying a subject of "*". You can forward only QOS by specifying the subjects "QOS_MESSAGE,QOS_DEFINITION", or alarms by specifying a subject of "alarm".
kindly confirm!Hopefully. -Garin
Thanks, Garin for very detailed explanation.
I would like to add some on it.
robot has concept which HUB it belongs to. In other words, a robot belongs to a HUB. (can belong to multiple HUBs with redundancy setup enabled)
UIM data (e.g alarms, Performance Data) produced by a monitoring probe is sent to SPOOLER service which is part of robot.
SPOOLER service dispatches it to HUB that the robot belongs to.
In any case, final destination of UIM data is the UIM Primary HUB Server.
There is common confusing point is - you need to create "ATTACH" type queue with appropriate types of subjects selected on the HUB that the robot belongs to.
If you don't have "ATTACH" queue on the HUB, the data is dropped, because HUB determines there is NO queue to attach the data.
As others mention, Tunnel is advanced (secured) way of taking in between HUB to HUB. It helps when people needs tighten control on talking port.
With regards to the "final destination", that applies to the generic configuration. There are reasons though to bypass this. You could install the nas probe on any hub you wanted and so you could have a remote hub that receives alarms and a nas probe on that hub that sends an email when a particular alarm arrives and you could throw away all the rest of the messaging. Or if you have a large volume of alerting and use preprocessing, you can put that preprocessing functionality on your tunnel proxies and then use nas replication to move the processed alarms from there forwards.
So I would amend that to be that the final destination of QoS messaging is your data_engine probe. The final destination of your alert data is the responsible nas probe. The final destination of discovery data is your disovery_server probe, and the final destination of your audit data is your audit probe and the final destination of your email data is your email gateway probe. In the ideal world these are all on the same hub (generic solution) but they don't all have to be.
Regarding the "confusion" comment, I couldn't agree more. Note that you also need a corresponding GET queue to read the data out of he ATTACH queue.
One of the hub 7.7x releases has an alarm now for the situation of data being dropped if there is no matching queue subject. I've not used that so I can't tell you if it works.
And the probe to hub communications can also take advantage of SSL encryption too. The big advantage of the tunnel function is that it allows you to push traffic through a NAT.
Retrieving data ...