CI/SSI and LVS integration (was: [CI] Re: keepalive with Cluster infrastructure health check.)

[Alexandre CASSEN]

Hi Aneesh,

SSI is also a kernel patch. libcluster is the interface for the user
application in accessing many of the cluster information.

Ok.

You mean what happens when the application migrates to other node ?

Yes exactly. According to your CI terminology what is the "application" ?
LVS code, WEB application, fs or all together ?

IMHO, if all together, this can result of some kind framework code
repetition. What I mean :

Introducing network loadbalancing in a logic network topology must
introduce some network level abstraction. This mean that we clearly locate
the virtualservers (VIP) & realservers. Loadbalancing framework will
schedule inbound connections on VIP to the elected realserver.

This loadbalancing framework can be incorporated into a global cluster
infrastructure product (like CI/SSI) only if it respect the LVS inside
framework design. Otherwise some big part of the code from LVS (for
instance scheduling decisions) will be backported to the global cluster
infrastructure framework (to deal with the CI/SSI CVIP). This backporting
process can be very time consuming.

If LVS is a part of a CI/SSI cluster, more than one node will have the LVS
code. Since CI/SSI design use the "CVIP" that is a roaming VIP on all LVS
node, the LVS connection table will be altered. A solution can be to
introduce somme kind of CI/SSI CVIP stickyness on a specific LVS node. This
mean that all traffic will be directed to a specific LVS director. That way
we can solve this problem since using this stickyness all connection will
be accepted by the same LVS node so scheduling decisions will be consistent
en LVS inside design will be respected.

This is a requierment since LVS is able to deal with LVS-NAT|TUN|DR, even
more we can use fwmark to mark inbound traffic before processing the
scheduling decision (I don t really know the impact of using fwmark in the
CI code).

Another point, if for CI/SSI you want a failover protection for the CVIP,
the CVIP takeover must (IMHO) be handled by a specific routing hot standby
protocol (VRRP), this really introduce the question : What is the meaning
of CVIP for use with LVS since CVIP must sticked to a specific LVS node ?

If i understand your point here. I have the server/daemon running at
node1 and when it migrates to node2( as per the decision taken by load
leveler ) and if the server requires persistents connection what will
happen ?

Yes exactly, what is the CI/SSI meaning of the "node migration process" ?
This sound like a node election/scheduling process isn t it ? if yes, is it
possible to stick the CVIP to a specific LVS node ?

LVS cluster topology, which mean in short of "LVS loadbalancing" is a
multiple active/active LVS topology. This active/active functionnality must
be (IMHO) by a specific dedicated hotstandby protocol. This is why, we (LVS
team) have started develop a robust VRRP framework embended into
keepalived.

[Brian J. Watson]

example specs: Two VIPs exposed to the world, loadbalancing using LVS on a
realserver pool.
+------------------+
| WAN area |
+------------------+
.............................................[CI/SSI cluster].....
. .
. .
. +----[VIP1]---+ +----[VIP2]---+ .
. | | | | .
. | LVS node1 | | LVS node2 | .
. +-------------+ +-------------+ .
. .
. +----[RIP1]---+ +----[RIP2]---+ +----[RIP3]---+ .
. | | | | | | .
. | app node1 | | app node2 | | app node3 | .
. +-------------+ +-------------+ +-------------+ .
..................................................................

There's not much point in running two LVS director nodes on the same
network. Barring any failures, the CVIP and LVS director would be
"stuck" to node1 and only node1. If node1 fails, then the CVIP would
failover to node2. As Bruce described, node2 would poll the other
servers to find out their connection states, it would build its own
director table with this information, and then it would begin acting as
the one and only CVIP/director node. Until this happens node2 cannot be
considered a CVIP/director node any more than node3.