|
Hello,
On Sun, 24 Dec 2000, Lorn Kay wrote:
> >5. NAT is not the only used method. The DR and TUN methods don't allow
>
> >the director's checks properly to check the real services: the real
>
> >service listens to the same VIP and it is hard to generate packets
> >in the director with daddr=VIP that will avoid the routing and will
> >reach the real server. They don't leave the director. What means this:
> >we can't check exactly the VIP:VPORT in the real service, may be only
> >RIP:VPORT ? This problem does not exist when the checks are performed
> >from the real service, for example the L4 check can be simple bind()
> >to VIP:VPORT. Port busy means L4 succeeds. No problems to perform
> >L7 checks. Sometimes httpd can listen to many virtual domains with
> >bind to 0.0.0.0. Why we need to perform checks for all these VIPs
> >when we can simply check on of them. Many, many optimizations, User
> >defined.
> >
>
> But it is nice to be able to have the ability to configure this (the
> VIP/RIP and PORT combination) since we don't want to assume the only
> configuration is multiple HTTP daemons (for example) bound to 0.0.0.0.
> (Even if we are local on DR or TUN server).
Agreed.
> In Apache http.conf we can specify a LISTEN port and run a separate
> daemon for HTTPS on port 443 for example. If this https daemon or daemons
> dies, or fails to start (because we have it configured to prompt for our
> security certificate password at startup) we wouldn't want to make
> assumptions about the health of the daemons listening on port 80 right?
Yes, even when we have one httpd for two domains may be we want to
check different cgi or database calls with L7 HTTP checks. But the L4
check can be one, of course, configured from the user: bind to 0.0.0.0:80.
> Also, Julian does your comment about FWMARK mean you think keepalived
> will not work with FWMARKing Directors?
It will. I think, all we want to see it implemented. But such
virtual services are not setup only with LVS setsockopts, we need to define
some ipchains rules, etc. These settings can be added to the configuration
file(s): chain name (input, vip), many vproto:vip:vport, fwmark value, etc.
> Many thanks to Alexandre Cassen for the great contribution... I plan to
> test it further in the lab ASAP.
>
> --K
Regards
--
Julian Anastasov <ja@xxxxxx>
|
