Failover : Balancing a one-ip pool (!)

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Failover : Balancing a one-ip pool (!)

Nicolas Ecarnot
Hello,

This message is less a question than a discussion, because we're happy
with our setup for years and maybe won't change soon, unless you answer
with a nice new idea.

We have 7 DHCP servers in a star pattern : one central and 6 around.
The center is the primary peer for the others, for around 400 pools and
lots of subnets.

Around 30 pools are classical ones, and balancing fine.
The numerous other ones are one-ip pools.

These one-ip pools are made this way in order to :
- benefit from failover setup. There seems to be no other way, failover
can only be setup on pools
- apply classID rules by pool, working only on one machine by subnet. We
don't want to use static reservations for that.

All this is working like a charm, but a small concern of mine is the
periodic balancing (60 seconds by default, we raised it to 120) where I
see that the servers are trying and obviously failing to balance the
only one ip between peers.
This is not very bad, except it is eating CPU and flooding the logs.

But I post here this message in hope someone could advice a better way
to do. Because I read lots of doc about balancing and the way ISC DHCPD
is managing this sounds clever and I'd be happy to use it in a proper way.

Of course, external constraints exist forcing me to use this weird
one-ip pools setup. But I'll fight to change them if someone replies
with nice hints I may have missed.

Regards,

--
Nicolas ECARNOT
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
Reply | Threaded
Open this post in threaded view
|

Re: Failover : Balancing a one-ip pool (!)

Chris Buxton
Nicolas,

I have a couple of thoughts about this.

1. When using a hub-and-spoke architecture, I find its better to let the spokes be primary and the hub be secondary for all its peers.

2. Singleton pools like you're describing don't really work for the failover protocol. Only the primary server will ever be able to answer. You won't see any benefit in terms of load balancing or even fault tolerance. You're better off configuring these without failover; if you really can't use reservations (host declarations with fixed addresses), then just define each singleton pool identically on each server, without failover (as long as you're certain there will never be two clients asking for that one address).

Regards,
Chris

> On Feb 16, 2016, at 12:05 AM, Nicolas Ecarnot <[hidden email]> wrote:
>
> Hello,
>
> This message is less a question than a discussion, because we're happy with our setup for years and maybe won't change soon, unless you answer with a nice new idea.
>
> We have 7 DHCP servers in a star pattern : one central and 6 around.
> The center is the primary peer for the others, for around 400 pools and lots of subnets.
>
> Around 30 pools are classical ones, and balancing fine.
> The numerous other ones are one-ip pools.
>
> These one-ip pools are made this way in order to :
> - benefit from failover setup. There seems to be no other way, failover can only be setup on pools
> - apply classID rules by pool, working only on one machine by subnet. We don't want to use static reservations for that.
>
> All this is working like a charm, but a small concern of mine is the periodic balancing (60 seconds by default, we raised it to 120) where I see that the servers are trying and obviously failing to balance the only one ip between peers.
> This is not very bad, except it is eating CPU and flooding the logs.
>
> But I post here this message in hope someone could advice a better way to do. Because I read lots of doc about balancing and the way ISC DHCPD is managing this sounds clever and I'd be happy to use it in a proper way.
>
> Of course, external constraints exist forcing me to use this weird one-ip pools setup. But I'll fight to change them if someone replies with nice hints I may have missed.
>
> Regards,
>
> --
> Nicolas ECARNOT
> _______________________________________________
> dhcp-users mailing list
> [hidden email]
> https://lists.isc.org/mailman/listinfo/dhcp-users
>
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
Reply | Threaded
Open this post in threaded view
|

Re: Failover : Balancing a one-ip pool (!)

Nicolas Ecarnot
Thank you Chris for your answers.

See below some comments.

Le 16/02/2016 15:28, Chris Buxton a écrit :
> Nicolas,
>
> I have a couple of thoughts about this.
>
> 1. When using a hub-and-spoke architecture, I find its better to let
> the spokes be primary and the hub be secondary for all its peers.

We lived this way (spokes primary and hub secondary) for 6 years.
Actually, we saw no real difference, neither in term of reliability not
performance.

> 2. Singleton pools like you're describing don't really work for the
> failover protocol. Only the primary server will ever be able to
> answer. You won't see any benefit in terms of load balancing or even
> fault tolerance.

Though I understand your answer about load balancing, I counldn't agree
about fault tolerance benefit:
On every remote site, we configure its router to relay the queries
towards 2 servers. When one of the server is down, the other correctly
replies, even to one-ip pools queries.

> You're better off configuring these without
> failover; if you really can't use reservations (host declarations
> with fixed addresses), then just define each singleton pool
> identically on each server, without failover (as long as you're
> certain there will never be two clients asking for that one
> address).

I agree, that could make complete sense, and would be cleaner.

>
> Regards, Chris
>
>> On Feb 16, 2016, at 12:05 AM, Nicolas Ecarnot <[hidden email]>
>> wrote:
>>
>> Hello,
>>
>> This message is less a question than a discussion, because we're
>> happy with our setup for years and maybe won't change soon, unless
>> you answer with a nice new idea.
>>
>> We have 7 DHCP servers in a star pattern : one central and 6
>> around. The center is the primary peer for the others, for around
>> 400 pools and lots of subnets.
>>
>> Around 30 pools are classical ones, and balancing fine. The
>> numerous other ones are one-ip pools.
>>
>> These one-ip pools are made this way in order to : - benefit from
>> failover setup. There seems to be no other way, failover can only
>> be setup on pools - apply classID rules by pool, working only on
>> one machine by subnet. We don't want to use static reservations for
>> that.
>>
>> All this is working like a charm, but a small concern of mine is
>> the periodic balancing (60 seconds by default, we raised it to 120)
>> where I see that the servers are trying and obviously failing to
>> balance the only one ip between peers. This is not very bad, except
>> it is eating CPU and flooding the logs.
>>
>> But I post here this message in hope someone could advice a better
>> way to do. Because I read lots of doc about balancing and the way
>> ISC DHCPD is managing this sounds clever and I'd be happy to use it
>> in a proper way.
>>
>> Of course, external constraints exist forcing me to use this weird
>> one-ip pools setup. But I'll fight to change them if someone
>> replies with nice hints I may have missed.
>>
>> Regards,
>>
>> -- Nicolas ECARNOT _______________________________________________
>> dhcp-users mailing list [hidden email]
>> https://lists.isc.org/mailman/listinfo/dhcp-users
>>
> _______________________________________________ dhcp-users mailing
> list [hidden email]
> https://lists.isc.org/mailman/listinfo/dhcp-users
>


--
Nicolas ECARNOT
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users