|
Hi John
On Mon, 2010-08-09 at 12:29 -0500, John Lash wrote:
> My problem is that since the real-servers only listen on the VIP attached to
> the loopback device, I have no way to address them to make sure that the
> service is usable from any location off of the real-servers themselves.
Well, the short answer there is that without doing something a little
more clever than direct connections, you're scuppered...
> Is there a way to health-check this service within the LVS framework? I
> haven't been able to find any information about it out on the web. The best
> solution that I've thought of to this point is to use ssh (or similar) to run
> a command locally on each server to do a health-check.
Notably the LVS framework itself doesn't do health checks - it's just a
router, albeit a very clever one. You already mentioned you're using
keepalived, which is analogous to ldirectord+heartbeat, or Piranha's
nanny+pulse, or several other setups.
In your case you have a multiplicity of options:
1. run all checks over an SSH connection
2. run all checks locally on the realservers, output to a file, fetch
that from the realservers periodically, have a script enumerate it,
check the output from a misc_check script
3. bring up another interface alias on the real NIC rather than lo, but
keep it on a private range, and bind services to that
4. run some sort of VPN between the realservers and the directors (which
is analogous to a a combination of (1) and (3)
5. ...you decide :)
What you're after, really, is exposing close-to-realtime service state
data from your realservers to some process running on the director. The
easiest way is to have that service bound to an address the director can
see but nothing else can, therefore exposing the service state. As I
said above, you could tighten things up by having the state collected
locally and then pulled by the director from the realservers.
Personally I'd go for a private range, but if that's not an option then
push state from the realservers to the director (rather than pulling the
other way), because that's more scalable.
Graeme
_______________________________________________
Please read the documentation before posting - it's available at:
http://www.linuxvirtualserver.org/
LinuxVirtualServer.org mailing list - lvs-users@xxxxxxxxxxxxxxxxxxxxxx
Send requests to lvs-users-request@xxxxxxxxxxxxxxxxxxxxxx
or go to http://lists.graemef.net/mailman/listinfo/lvs-users
|
