Proposition of changes in cluster definition

Development
,
1

Hi everyone

I’m a Vyatta user for ages.
I’m using almost everything in Vyatta and it’s about time to do something for whole community.

I found, that there is no option to create secondary cluster group. This could be used to manually balance incoming connections in Vyatta cluster e.g.:
We have two hosts in cluster: gate01 and gate02. This cluster have multiple ip service configured, so if one host goes away, the other one takes all ip addresses. Some of them are used for Vyatta services (ipsec, pptp, outgoing ip from lan) but rest is used for 1 to 1 mapping to our servers.

In that situation all traffic to cluster always comes to master Vyatta and the other one is waiting on standby.

Hearbeat has required options by default. You can define which host is a master for certain service but vyatta not support it.

The only thing I need is to declare a master host for a service and here comes a problem with backwards compatibility.

I have two propositions. The is current format:

cluster {
  group ... {
    service 192.168.100.1/24
  }
}
  1. Change it to this one (backwards compatibility problem, word ‘service’ used twice)
cluster {
  group ... {
    service NUMBER {
      service 192.168.100.1/24
      primary HOST
    }
  }
}
  1. Additional ‘service-advanced’ section
cluster {
  group ... {
    service-advanced NUMBER {
      service 192.168.100.1/24
      primary HOST
    }
  }
}

Argument ‘primary’ in service definition can be optional. If missing, definition comes from group > primary.

It will be nice to hear your opinion.
When I’ll finished I want to make a pull request for it.

Mariusz

2

Hi,
great idea. Why not just add “primary” config node to service?
Like:

cluster {
  group ... {
    service 192.168.100.1/24 {
      primary HOST
    }
  }
}

Anyway I was looking in this bit and this feature should be pretty easy to implement. Just change the way how ip adresses are generated in /etc/heartbeat/haresources .

3

Because this will break backwards compatibility.
All configs before changes will be not compatible with new syntax.

I already made it in production environment.
The last thing is syntax of config if someone want to accept pull request with my changes.

Mariusz

4

I don’t really see how
“set cluster group 1 service 192.168.1.1/25/eth0 primary vyos-1” is not compatible with “set cluster group 1 service 192.168.1.1/25/eth0”, but I haven’t look how it is treated internally (when node has subnodes, and when not, espceially if eg. “protocols bgp 1234 network 1.2.3.4” is compatible with “protocols bgp 1234 network 1.2.3.4 { }” in config file…)

Anyway another idea, why not add optional /primary-node to service ? like:

set cluster group 1 service 192.168.1.1/25/eth0/vyos-1

I hope your pull request will be accepted as well.

5

wow. great.
I didn’t know that you cen defice bgp network withyout defailts …
It could be a solution

I think about it and even try to do it.
Then I found that there is a hidden param after /interface called boradcast (vyatta-cluster/lib/Vyatta/Cluster/Config.pm at helium · vyos/vyatta-cluster · GitHub)
This ruined everything.

I will stay with bgp like solution and try to do it.