On 10/27/08 12:27, James Carlson wrote:
Sangeeta Misra writes:
On 10/27/08 10:10, James Carlson wrote:
I don't think I understand VRRP groups. The design describes in some
detail how to configure them and some of how they operate, but it
leaves out three crucial bits of information:
a. Why do we need them? What problem do they solve or what
necessary feature do they allow us to have?
[...]
The VRRP group concept was devised to handle the failover of primary
loadbalancer that handles multiple virtual services. Rather than
designate master and backup per virtual service, the idea was to have
one master for all the virtual services. So one would invoke a VRRP
instance per virtual service and bind all the the instances to 1 group
and perform failover as a whole.
The question I still have is "why?" What benefit do we get by doing
them as a group?
Is it expected to be simpler to configure this way? Is the behavior
more predictable for some applications?
What's the advantage of grouping them versus simply specifying the
same master and backup for a list of independent addresses?
The failover from primary to standby
will only occur when the standby fails to hear VRRP advertisements of
*all* instances in that group.
That makes it sound like a much bigger protocol change than the design
document indicates. I'd like to see some worked-through examples in
order to understand how it reacts.
Further, given this is an IETF standards track protocol, if we're going
to start adding our own bits and pieces to it, then we should be working
with the appropriate IETF WG - the right course of action here would be
to end up with a new RFC.
Darren
_______________________________________________
networking-discuss mailing list
[email protected]
