User story #5256: Accepted nodes and techniques shared among relays - Rudder - Issue Tracker

Actions

Copy link

User story #5256

open

Accepted nodes and techniques shared among relays

Added by Lionel Le Folgoc almost 10 years ago. Updated about 6 years ago.

Status:

New

Priority:

N/A

Assignee:

Category:

Server components

Target version:

Ideas (not version specific)

Pull Request:

UX impact:

Suggestion strength:

User visibility:

Effort required:

Name check:

Fix check:

Regression:

Description

Hi,

In the distributed setup, it appears that each relay receives the techniques and allows connections only from the subset of nodes that sent their initial inventory to this relay.

I set up a very basic round-robin dns, with 2 relays behind front.rudder.fqdn, and cf-agent runs fail about half of the time. Now when I have 5000 nodes, I'll need more relays, and the chance of a successful cf-agent run will decrease even more.
(same with different use cases such as a geo dns, as discussed on IRC)

So in a nutshell, the distributed setup is not usable for load balancing purposes...

As a local workaround, any way I can force the list of allowed nodes and techniques to be sent to all relays?

Thanks.

This can be called relay groups or relay clusters.

Actions

Copy link

Updated by Nicolas CHARLES over 9 years ago

Category set to Server components
Target version set to 2.11.2

Hi Lionel,

I suggest a solution with a "master" relay, and "slaves" relays, that would copy the master config

The best solution for this, would be to:

install rudder-agent on a node that would be the "slave" of the relay, but don't accept it on the server
follow the procedure for relay configuration (except the LDAP modification)
set up a rsync of the folder /opt/rudder between master and slave
set up a rsync of the folder /var/rudder -except for the file /var/rudder/cfengine-community/inputs/inventory/1.0/fusionAgent.cf
create a dummy /var/rudder/cfengine-community/inputs/inventory/1.0/fusionAgent.cf on the slave that would contain:
```
bundle agent doInventory
{
  reports:
    cfengine::
      "We don't do any inventory on slave relays";
}
```

What do yuo think of this solution ?

Actions

Copy link

Updated by Lionel Le Folgoc over 9 years ago

Hi Nicolas,

I think it works (although: what would happen with a rsync during a cfagent run?), but I'm not a fan of the introduced hierarchy between relays: the "master" relay becomes a SPOF.
AIUI, if the master dies, the whole infra is stuck (because the slaves are unknown to the policy server, I've no quick way to resume normal conditions, except a backup of the master ; but I don't want to backup relays, they are dispensable, they basically duplicate content from the policy server to share the load).

I'd like to simply put them behind a load balancer: when one relay goes down, I don't even care to restore it, only instanciate a new one from a template, accept it on the policy server & declare it as relay. After the next cf-agent run, it's ready to go. And this is invisible for all my nodes.

Thanks.

Actions

Copy link

Updated by Nicolas CHARLES over 9 years ago

Thank you for your answer.
We'll check how to implement this approach, has you have NATed systems, and identify Relay by their Hostname

Actions

Copy link

Updated by Nicolas CHARLES over 9 years ago

Hi Lionel,

We gave it some thought, and devised a more robust solution, by introducing "groups" of relays

each relay will belong to a group with a specific uuid (group is generated by the relay configuration script)
the relays will expose their group id rather than their own uuid to nodes connecting through them
the promises generated for relays will be in
/var/rudder/share/groupid/nodeid
relays will fetch their promise sbased on the gorup id rather than their own uuid
ACLs will be computed based on the group id rather than nodeid

For the migration, we'll automatically create the group at migration, and the techniques will contain new promises to

write the group id to a specific file
update the apache config to expose the group id rather that the node id

What do you think of it?

Actions

Copy link

Updated by Lionel Le Folgoc over 9 years ago

As discussed on IRC yesterday, that looks fine, thanks (why not a checkbox "promises are global to all relays" though?).

Actions

Copy link

Updated by Nicolas PERRON over 9 years ago

Target version changed from 2.11.2 to 2.11.3

Actions

Copy link

Updated by Matthieu CERDA over 9 years ago

Target version changed from 2.11.3 to 2.11.4

Actions

Copy link

Updated by Jonathan CLARKE over 9 years ago

Tracker changed from Bug to User story
Subject changed from Accepted nodes and techniques are not shared among relays to Accepted nodes and techniques shared among relays
Target version changed from 2.11.4 to 140

This can not be considered a bug, since this behaviour was never intended. In fact, quite the opposite: one of the roles of relay servers is to provide strict isolation between managed nodes in different network zones.

I'm requalifying this as a user story / feature request.

Actions

Copy link