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 difference is using group guarantees that all instances in the
group always have the same state.
There are cases where only one instance doing fail over among
multiple instances doesn't work for the whole network setup.
There might be needs that all instances whether do fail over as a
whole, or rather stay unchanged.
For example, consider a pair of NAT mode load balancers where
both outside IP (the VIP) and the inside IP (the default route of
back end servers) need to be protected by VRRP. If separate
VRRP instances are applied on inside and outside interface
respectively, when the inside link somehow fails, the inside IP
will fail over to the backup, while the outside IP will stay on
the original master. That doesn't work for the network setup. Unless
we use another linkage to serialize the two hosts in this case,
which is chosen as a solution by the Nortel load balancer who
doesn't introduce extensions like we do for VRRP group.
By grouping the inside and outside instances, the uneven fail over
case can be avoided, but it still doesn't solve the problem. A decision
that needs to be made is when one or some of the instances fail, how
should the group act?
1) don't do fail over until all instances fail
2) do mandatory fail over for all instances
It is a trade-off choosing either one. The second solution can work
for cases that part of links on master fail, as described in the example.
But there is possibility that it is the backup's inside link who fails and
hence can't hear advertisement from the master. The advantage of the
first solution is it can avoid such a false-positive.
Another issue of the second solution is lack of support from the
VRRP protocol. It is the backup who detects absence of advertisement
and performs fail over. But the backup has lower priority than the master.
So in the above example, if the backup wants to do mandatory fail over
for both instances, it needs a way to preempt the power from the master
on the outside instance, such as changing its own priority to a higher one
than that of the master. However the protocol doesn't provide such a
scheme.
Providing both solutions as options would be great for VRRP group. But
considering the issues of the second solution, we only provide the first
solution in this implementation.
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.
I agree some examples would help a lot.
For example, suppose I have a single group (let's call it "mygroup")
which comprises two instances (we can call these "A" and "B"). The
instances each have a virtual IP address (IP-A and IP-B) and an
interface -- let's just have them on the same interface to start.
Suppose I'm the backup, and I stop hearing announcements for IP-B, but
I'm still hearing them for IP-A. Does this mean that I assume that
the sender is still master for both IP-A and IP-B, even though I can't
hear IP-B, and even though the protocol document says that I should
now be master for IP-B?
Yes.
What if it's only IP-B that's broken on the
peer?
The group setting can't solve this single link failure. In current design we
just try to avoid doing improper fail over based on false positive.
Now suppose that I make a mistake. I've configured one side with a
group and the other with independent instances. What happens? Are
there any cases where the peers can get confused about who owns which
address? If so, how can the user detect that such a mistake has been
made?
I think these kind of inconsistent configurations across multiple hosts
are hard to detect.
In the particular case you describe above, if a group is configured on
the backup and independent instances are configured on the master,
then it will work just as configuring two groups on both hosts. That's
because in practice it is the backup who perform fail over. Conversely,
having the group on the master while independent instances on the
backup won't work.
Are there any cases where one instance in a group could attain
"master" status while another has "backup," or are all of them tied in
lock-step to the group's status?
They shares the same state, and also other VRRP attributes.
It almost sounds like you want a protocol extension here (one that
allows multiple addresses to be transferred at one time), but are
declining to do that. If you're changing the protocol anyway --
changing how "master" and "backup" roles are detected is a protocol
change -- then why not just add an extension to handle this case,
rather than running parallel instances?
To be more precise, the desired extension is to allow addresses on multiple
interfaces to be transferred at one time. The implementation of group
actually
doesn't work like running parallel instances, but like an extended instance
instead.
Yifan
_______________________________________________
networking-discuss mailing list
[email protected]
