RHQ Agent's communicate only with RHQ Servers. The data the agents
collect is reported to a server, potentially processed in various ways,
like for alerting, and then stored. Today, availability data, events
and more are stored into the [oracle] RDB. Metric data is stored into
the storage cluster you've created. Agents never communicate directly
to the storage cluster. The storage cluster knows only about storing
and fetching data. It has no concept of agents and all the associated
things that go with that, like authorization, communication, etc.
So, RHQ Servers are one thing and they connect to the RDB and the RHQ
Storage Node cluster. They also service agents. Agents only
communicate with an RHQ Server, and not necessarily the server that
initially contacted, but rather the server they are told to contact in
order to distribute agent load.
I'm sorry, I don't know about F5, but basically the agents are not
dealing with F5 after perhaps the initial server contact. They are
connecting to a server via the RHQ comm layer, directly.
On 8/11/2014 2:17 PM, barry.barnett(a)wellsfargo.com wrote:
Why wouldn’t the agent that points to the F5 GTM URL point to wherever
the F5 wants to have it communicate with? So you’re saying the BCP
RHQ server storage node has to join the Prod storage node cluster for
this failover to BCP to work, even with the F5 GTM URL being used?
Regards,
Barry
*From:*rhq-users-bounces@lists.fedorahosted.org
[mailto:rhq-users-bounces@lists.fedorahosted.org] *On Behalf Of *Jay
Shaughnessy
*Sent:* Monday, August 11, 2014 2:07 PM
*To:* rhq-users(a)lists.fedorahosted.org
*Subject:* Re: F5 GTM - RHQ Agent configuration issue
If I understand this correctly, the reason is this. The agent
initially contacts *any server* but is not immediately serviced by
that server. It is only provided with a "failover list" of servers
it should use. It then tries to connect with the first server in that
list (the "primary"). Failing contact it will then proceed to
"failover" to the next HA server in the ordered list of HA servers.
Eventually it will always try to return to its primary server, if
possible.
The failover list will contain entries for only the registered HA
servers, in the case A and B.
On 8/11/2014 1:40 PM, barry.barnett(a)wellsfargo.com
<mailto:barry.barnett@wellsfargo.com> wrote:
We currently have the following configuration for our RHQ server:
Production RHQ Server 1 (Node A)
Production RHQ Server 2 (Node B)
·Both nodes connected to the Oracle backend database)
·Storage nodes on each instance, clustered
BCP RHQ Server (Node C – different location)
·Storage node not in cluster
We have an F5 URL that sits infront of all the nodes, and can
point to any of them in the following scenario:
·Prod Node A fails, traffic directed to Prod Node B
·Prod Node A and B fails, traffic directed to BCP Node C
When an RHQ agent on a client windows box is configured, and the
F5 GTM URL is used as the RHQ Server, the agent connects to Prod
Node A (as that node is the primary active node for the F5 to
point to). If I bring down both Prod Nodes, I would think the F5
URL would connect the agent to the BCP Node C RHQ server. But, it
never connects to BCP, but rather in its logs shows it trying to
connect to both Prod nodes and failing. Is this due to the
storage nodes in Prod being clustered (assumption)? Why wouldn’t
the F5 URL direct the agent to connect to BCP?
_______________________________________________
rhq-users mailing list
rhq-users(a)lists.fedorahosted.org <mailto:rhq-users@lists.fedorahosted.org>
https://lists.fedorahosted.org/mailman/listinfo/rhq-users
_______________________________________________
rhq-users mailing list
rhq-users(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/rhq-users