Project

General

Profile

Actions

User story #5256

open

Accepted nodes and techniques shared among relays

Added by Lionel Le Folgoc over 10 years ago. Updated almost 7 years ago.

Status:
New
Priority:
N/A
Assignee:
-
Category:
Server components
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 #1

Updated by Nicolas CHARLES over 10 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:
  1. install rudder-agent on a node that would be the "slave" of the relay, but don't accept it on the server
  2. follow the procedure for relay configuration (except the LDAP modification)
  3. set up a rsync of the folder /opt/rudder between master and slave
  4. set up a rsync of the folder /var/rudder -except for the file /var/rudder/cfengine-community/inputs/inventory/1.0/fusionAgent.cf
  5. 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 #2

Updated by Lionel Le Folgoc over 10 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 #3

Updated by Nicolas CHARLES over 10 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 #4

Updated by Nicolas CHARLES over 10 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
  1. write the group id to a specific file
  2. update the apache config to expose the group id rather that the node id

What do you think of it?

Actions #5

Updated by Lionel Le Folgoc over 10 years ago

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

Actions #6

Updated by Nicolas PERRON over 10 years ago

  • Target version changed from 2.11.2 to 2.11.3
Actions #7

Updated by Matthieu CERDA about 10 years ago

  • Target version changed from 2.11.3 to 2.11.4
Actions #8

Updated by Jonathan CLARKE about 10 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 #9

Updated by Matthieu CERDA about 10 years ago

  • Target version changed from 140 to 3.0.0~beta1
Actions #10

Updated by Jonathan CLARKE almost 10 years ago

  • Target version changed from 3.0.0~beta1 to 3.1.0~beta1
Actions #11

Updated by Vincent MEMBRÉ over 9 years ago

  • Target version changed from 3.1.0~beta1 to 3.1.0~rc1
Actions #12

Updated by Vincent MEMBRÉ over 9 years ago

  • Target version changed from 3.1.0~rc1 to 3.1.0
Actions #13

Updated by Vincent MEMBRÉ over 9 years ago

  • Target version changed from 3.1.0 to 3.1.1
Actions #14

Updated by Benoît PECCATTE over 9 years ago

  • Description updated (diff)
Actions #15

Updated by Vincent MEMBRÉ over 9 years ago

  • Target version changed from 3.1.1 to 3.1.2
Actions #16

Updated by Vincent MEMBRÉ about 9 years ago

  • Target version changed from 3.1.2 to 3.1.3
Actions #17

Updated by Vincent MEMBRÉ about 9 years ago

  • Target version changed from 3.1.3 to 3.1.4
Actions #18

Updated by Vincent MEMBRÉ about 9 years ago

  • Target version changed from 3.1.4 to 3.1.5
Actions #19

Updated by Vincent MEMBRÉ almost 9 years ago

  • Target version changed from 3.1.5 to 3.1.6
Actions #20

Updated by Vincent MEMBRÉ almost 9 years ago

  • Target version changed from 3.1.6 to 3.1.7
Actions #21

Updated by Vincent MEMBRÉ over 8 years ago

  • Target version changed from 3.1.7 to 3.1.8
Actions #22

Updated by Vincent MEMBRÉ over 8 years ago

  • Target version changed from 3.1.8 to 3.1.9
Actions #23

Updated by Vincent MEMBRÉ over 8 years ago

  • Target version changed from 3.1.9 to 3.1.10
Actions #24

Updated by Vincent MEMBRÉ over 8 years ago

  • Target version changed from 3.1.10 to 3.1.11
Actions #25

Updated by Vincent MEMBRÉ over 8 years ago

  • Target version changed from 3.1.11 to 3.1.12
Actions #26

Updated by Vincent MEMBRÉ over 8 years ago

  • Target version changed from 3.1.12 to 3.1.13
Actions #27

Updated by Vincent MEMBRÉ about 8 years ago

  • Target version changed from 3.1.13 to 3.1.14
Actions #28

Updated by Vincent MEMBRÉ about 8 years ago

  • Target version changed from 3.1.14 to 3.1.15
Actions #29

Updated by Vincent MEMBRÉ about 8 years ago

  • Target version changed from 3.1.15 to 3.1.16
Actions #30

Updated by Vincent MEMBRÉ about 8 years ago

  • Target version changed from 3.1.16 to 3.1.17
Actions #31

Updated by Vincent MEMBRÉ almost 8 years ago

  • Target version changed from 3.1.17 to 3.1.18
Actions #32

Updated by Vincent MEMBRÉ almost 8 years ago

  • Target version changed from 3.1.18 to 3.1.19
Actions #33

Updated by Vincent MEMBRÉ over 7 years ago

  • Target version changed from 3.1.19 to 3.1.20
Actions #34

Updated by Vincent MEMBRÉ over 7 years ago

  • Target version changed from 3.1.20 to 3.1.21
Actions #35

Updated by Vincent MEMBRÉ over 7 years ago

  • Target version changed from 3.1.21 to 3.1.22
Actions #36

Updated by Vincent MEMBRÉ over 7 years ago

  • Target version changed from 3.1.22 to 3.1.23
Actions #37

Updated by Vincent MEMBRÉ about 7 years ago

  • Target version changed from 3.1.23 to 3.1.24
Actions #38

Updated by Vincent MEMBRÉ about 7 years ago

  • Target version changed from 3.1.24 to 3.1.25
Actions #39

Updated by Benoît PECCATTE about 7 years ago

  • Target version changed from 3.1.25 to 4.1.9
Actions #40

Updated by Vincent MEMBRÉ almost 7 years ago

  • Target version changed from 4.1.9 to 4.1.10
Actions #41

Updated by Benoît PECCATTE almost 7 years ago

  • Target version changed from 4.1.10 to Ideas (not version specific)
Actions

Also available in: Atom PDF