Re: [SSI-devel] Re: amd

[Roger T. <rog...@gm...>]

Hi,

I just checked again.  This time the IPVS daemon did failback to the
preferred initnode.  Services on the CVIP are still available, but you
might want to seriously consider the consequences of routing locally
generated packets directly to the director node rather than to the
CVIP.  ;-)

[root@node1 root]# cat /proc/1/where
2
[root@node1 root]# ipvsadm -ln --daemon
running as master (mcast=3Dbond0eth1)
[root@node1 root]# service ha-lvs status
(node 1)
ha-lvs (pid 125508) is running...
(node 2)
ha-lvs (pid 178914) is running...

-Roger


On 4/15/05, Roger Tsang <rog...@gm...> wrote:
> I just went on my cluster to verify whether this is true.  Apparently
> not, at least not this time.  Perhaps that was just a fluke - I hope.
>=20
> -Roger
>=20
> On 4/14/05, Brian J. Watson <Bri...@hp...> wrote:
> > Yes, that's what I was referring to. ;)
> >
> > Brian
> >
> >
> > Roger Tsang wrote:
> > > Hey Aneesh,
> > >
> > > I think Brian meant the LVS director failback to the preferred
> > > initnode that I was talking about.  I saw this behavior once.  I
> > > wonder if it was intentional too.
> > >
> > > -Roger
> > >
> > > On 4/14/05, Brian J. Watson <Bri...@hp...> wrote:
> > >
> > >>Aneesh-
> > >>
> > >>Is this LVS failback an intentional feature?
> > >>
> > >>Brian
> > >>
> > >>
> > >>Roger Tsang wrote:
> > >>
> > >>>Oh I see.  Now that you mention, I ran into this too.  This is how I=
 solved it.
> > >>>
> > >>>iptables -t nat -A OUTPUT -j DNAT -d CVIP --to
> > >>>current_LVS_director_node_ICS_address
> > >>>
> > >>>There is a caveat.  The problem with the current HA-LVS code in
> > >>>SSI-1.2.x is VIP (director node) always runs on the preferred initno=
de
> > >>>regardless where proc 1 resides in the cluster.  The director
> > >>>failsover accordingly, but not always in sync with initnode failover=
 -
> > >>>eg. behavior exhibited when preferred initnode re-joins cluster.
> > >>>While init does not transparently failback to the preferred node, LV=
S
> > >>>director does.  This is what I saw one time, so it did happen.  Afte=
r
> > >>>you verify this behavior and you will have to update iptables
> > >>>accordingly.
> > >>>
> > >>>-Roger
> > >>
> > >
> > >
> >
> >
>