|
we win--------
We dont know how to thank Horms for ldirectord.
Actually we were facing problem for squid with
ldirectord on LVS s discussed in previous mail. We had
solved the problem by adding only two lines at the end
of file /etc/ha.d/ldirectord as follows :-
checkport=3128
checktype=connect
now ldirectord is able to detect failures of
realservers automatically.great---thank u mr horms &
wensong for concept of LVS & ldirectord. One kind
member has suggested one more method to solve this
problem as under :-
"You need to tell ldirectord a suitable URL to use for
testing the Squid servers. You can either use a
proxied URL or request an internal URL such as one of
the icons
http://squid.server/squid-internal-static/icons/anthony-unknown.gif
HTTP Proxies is not that different from a normal HTTP
web service. Both
speaks HTTP."
Please suggest this method also if any one want.
thank u again to all the members of forum for helping
us a lot.
--- lvs-users-request@xxxxxxxxxxxxxxxxxxxxxx wrote:
> Send lvs-users mailing list submissions to
> lvs-users@xxxxxxxxxxxxxxxxxxxxxx
>
> To subscribe or unsubscribe via the World Wide Web,
> visit
> http://www.in-addr.de/mailman/listinfo/lvs-users
> or, via email, send a message with subject or body
> 'help' to
> lvs-users-request@xxxxxxxxxxxxxxxxxxxxxx
>
> You can reach the person managing the list at
> lvs-users-owner@xxxxxxxxxxxxxxxxxxxxxx
>
> When replying, please edit your Subject line so it
> is more specific
> than "Re: Contents of lvs-users digest..."
> > Today's Topics:
>
> 1. squid with ldirectord----------------
> (SUKHWINDER PAL)
> 2. ldirectord and HTTP GET/HEAD [patch] (Volker
> Dormeyer)
> 3. Re: ldirectord and HTTP GET/HEAD [patch]
> (Volker Dormeyer)
> 4. Re: ldirectord and HTTP GET/HEAD [patch]
> (Volker Dormeyer)
> 5. Slow SSL (Jeff Royal)
> 6. Some issues on LVS-DR with Squid (Janno de
> Wit)
>
> ATTACHMENT part 3.1 message/rfc822
> From: SUKHWINDER PAL <rec_engrec@xxxxxxxxxxx>
> Subject: squid with ldirectord----------------
> Date: Mon, 21 Feb 2005 16:27:18 +0000 (GMT)
> To: lvs-users@xxxxxxxxxxxxxxxxxxxxxx
>
> Finally we are able to implement two squid servers
> with LVS-DR method .Now we are trying to implement
> ldirectord to detect fail over of squids.If We use
> two
> realserver as following :-
>
> On director--------
> VIP------10.11.151.24
> DIP-------10.11.150.98
>
> On Realserver1(Squid)-----------
> RIP----------10.11.150.82
> VIP----------10.11.151.24
>
> On realserver2------------
> RIP----------10.11.150.96
> VIP----------10.11.151.24
>
> Now as in LVS-DR the realserver is serving directly
> to
> client and not through director.Then how can we
> implement ldirectord on director to check health of
> realservers.
> We downloaded the "forward_shared---" patch &
> applied
> it on director.Then we changed the default gateway
> of
> realservers as DIP.And then we issued following
> commands:-
> echo 1 > /proc/sys/net/ipv4/conf/all/forward_shared
> echo 1 > /proc/sys/net/ipv4/conf/DIP/forward_shared
> Then we modified /etc/ha.d/ldirectord on the
> director
> as follows:-
> virtual=10.11.151.24:3128
> real=10.11.150.82:3128 gate
> real=10.11.150.96:3128 gate
> fallback=127.0.0.1:3128
> quiescent=no
> scheduler=wrr
> protocol=tcp
> As on the man page of ldirectord service "squid" was
> not there ,we have not defined service field.
> After this we started all the services like
> ipvsadm,ldirectord,squid on director & realserver
> respectively.But whenever any of the squid server
> goes down its entry is not removed from the ipvsadm
> table.And client connected to the failed server does
> not get connected to the working squid
> automatically.
> What could be the problem sir.
>
>
>
>
>
> __________________________________
> Do you Yahoo!?
> Yahoo! Mail - You care about security. So do we.
> http://promotions.yahoo.com/new_mail
>
> ATTACHMENT part 3.2 message/rfc822
> From: Volker Dormeyer <volker@xxxxxxxxxxxx>
> Subject: ldirectord and HTTP GET/HEAD [patch]
> Date: Mon, 21 Feb 2005 21:29:54 +0100
> To: lvs-users@xxxxxxxxxxxxxxxxxxxxxx
>
> Hello,
>
> ldirectord does HTTP/HTTPS health checking by the
> HTTP GET method. I
> know of some people and one of our customers who
> would like to use the
> HTTP HEAD method for health checking to avoid the
> retrieval of an entire
> web page. Which in turn results in a log entry of
> the web server and
> after all in a web page hit.
>
> Thus, I wrote a small patch to make ldirectord able
> to issue HTTP HEAD
> requests for HTTP/HTTPS health checking. The
> attached patch adds an
> additional config file parameter "httpmethod" which
> can be either "GET"
> or "HEAD". It defaults to "GET", if it is not set in
> order to not break
> any existing setups.
>
> What do you think about it? Contructive ideas or
> criticism are welcome!
> Maybe this was discussed some time ago.
>
> Regards
> Volker
>
> -------------- next part --------------
> --
> Volker Dormeyer <volker@xxxxxxxxxxxx>
>
>
>
> ATTACHMENT part 3.3 message/rfc822
> From: Volker Dormeyer <volker@xxxxxxxxxxxx>
> Subject: Re: ldirectord and HTTP GET/HEAD [patch]
> Date: Mon, 21 Feb 2005 21:34:19 +0100
> To: lvs-users@xxxxxxxxxxxxxxxxxxxxxx
>
> I'm sorry, the patch file was created in the wrong
> order. Here is a new
> one.
>
> Regards
> Volker
>
> -------------- next part --------------
>
>
>
>
> //> On Mon, 21 Feb 2005 21:29:54 +0100,
> //> Volker Dormeyer <volker@xxxxxxxxxxxx> wrote:
>
> > Hello,
>
> > ldirectord does HTTP/HTTPS health checking by
> the HTTP GET method. I
> > know of some people and one of our customers who
> would like to use the
> > HTTP HEAD method for health checking to avoid
> the retrieval of an entire
> > web page. Which in turn results in a log entry
> of the web server and
> > after all in a web page hit.
>
> > Thus, I wrote a small patch to make ldirectord
> able to issue HTTP HEAD
> > requests for HTTP/HTTPS health checking. The
> attached patch adds an
> > additional config file parameter "httpmethod"
> which can be either "GET"
> > or "HEAD". It defaults to "GET", if it is not
> set in order to not break
> > any existing setups.
>
> > What do you think about it? Contructive ideas or
> criticism are welcome!
> > Maybe this was discussed some time ago.
>
> > Regards
> > Volker
>
> > --
> > Volker Dormeyer <volker@xxxxxxxxxxxx>
>
>
> ATTACHMENT part 3.4 message/rfc822
> From: Volker Dormeyer <volker@xxxxxxxxxxxx>
> Subject: Re: ldirectord and HTTP GET/HEAD [patch]
> Date: Mon, 21 Feb 2005 21:40:46 +0100
> To: Volker Dormeyer <volker@xxxxxxxxxxxxxxxxx>,
> lvs-users@xxxxxxxxxxxxxxxxxxxxxx
>
> Sorry again, the patch (MIME attachement) seemed to
> be cut by the
> mailing list software. Here it is again as text:
>
> --- ldirectord.orig 2005-02-09 09:19:51.000000000
> +0100
> +++ ldirectord 2005-02-21 21:07:28.000000000 +0100
> @@ -265,6 +265,12 @@
>
> For a MySQL check, the receive setting is not used.
>
> +B<httpmethod = GET>|B<HEAD>
> +
> +Sets the HTTP method which should be used to fetch
> the URI specified in
> +the request-string. GET is the method used by
> default if the parameter is
> +not set. If HEAD is used, the receive-string should
> be unset.
> +
> B<virtualhost = ">I<hostname>B<">
>
> Used when using a negotiate check with HTTP or
> HTTPS. Sets the host header
> @@ -712,6 +718,7 @@
> $vsrv{connecttimeout} = 0;
> $vsrv{negotiatetimeout} = 0;
> $vsrv{num_connects} = 0;
> + $vsrv{httpmethod} = "GET";
> push(@VIRTUAL, \%vsrv);
> while(<CFGFILE>) {
> $line++;
> @@ -826,6 +833,10 @@
> $vsrv{login} eq "") {
> $vsrv{login} = "anonymous";
> }
> + } elsif ($rcmd =~ /^httpmethod\s*=\s*(.*)/) {
> + $1 =~ /(\w+)/ && (uc($1) eq "GET" ||
> uc($1) eq
> "HEAD")
> + or &config_error($line, "httpmethod
> must
> be GET or HEAD");
> + $vsrv{httpmethod} = uc($1);
> } elsif ($rcmd =~ /^virtualhost\s*=\s*(.*)/) {
> $1 =~ /\"?([^"]*)\"?/ or
> &config_error($line, "invalid
> virtualhost");
> @@ -1675,7 +1686,7 @@
> my $ua = new LWP::UserAgent();
> $ua->timeout($$v{negotiatetimeout});
> my $h = new HTTP::Headers("Host" =>
> $virtualhost);
> - my $req = new HTTP::Request("GET", "$$r{url}",
> $h);
> + my $req = new HTTP::Request("$$v{httpmethod}",
> "$$r{url}", $h);
> my $res;
> {
> # LWP makes ungaurded calls to eval
> @@ -1848,7 +1859,7 @@
> }
> my $virtualhost = (defined $$v{virtualhost} ?
> $$v{virtualhost} : $host);
> my ($page, $errors, $cert, $head, $body,
> $response, $result);
> - my $msg = "GET $uri HTTP/1.0" . $CRLF
> + my $msg = "$$v{httpmethod}" . " $uri HTTP/1.0" .
> $CRLF
> . "Host: " . $virtualhost . $CRLF
> . "Accept: */*" . $CRLF . $CRLF;
>
> -------------- next part --------------
>
> //> On Mon, 21 Feb 2005 21:34:19 +0100,
> //> Volker Dormeyer <volker@xxxxxxxxxxxx> wrote:
>
> > I'm sorry, the patch file was created in the
> wrong order. Here is a new
> > one.
>
> > Regards
> > Volker
>
>
> //> On Mon, 21 Feb 2005 21:29:54 +0100,
> //> Volker Dormeyer <volker@xxxxxxxxxxxx> wrote:
>
> >> Hello,
>
> >> ldirectord does HTTP/HTTPS health checking by
> the HTTP GET method. I
> >> know of some people and one of our customers who
> would like to use the
> >> HTTP HEAD method for health checking to avoid
> the retrieval of an entire
> >> web page. Which in turn results in a log entry
> of the web server and
> >> after all in a web page hit.
>
> >> Thus, I wrote a small patch to make ldirectord
> able to issue HTTP HEAD
> >> requests for HTTP/HTTPS health checking. The
> attached patch adds an
> >> additional config file parameter "httpmethod"
> which can be either "GET"
> >> or "HEAD". It defaults to "GET", if it is not
> set in order to not break
> >> any existing setups.
>
> >> What do you think about it? Contructive ideas or
> criticism are welcome!
> >> Maybe this was discussed some time ago.
>
> ATTACHMENT part 3.5 message/rfc822
> From: Jeff Royal <LVS@xxxxxxxxx>
> Subject: Slow SSL
> Date: Mon, 21 Feb 2005 21:46:47 -0600
> To: lvs-users@xxxxxxxxxxxxxxxxxxxxxx
>
> I've added an SSL server to my realserver list.
> Here is an example of my ldirectord.cf
>
> # Global Directives
> checktimeout=20
> checkinterval=10
> logfile="/var/log/ldirectord.log"
> quiescent=no
>
> # Virtual Server for HTTP
> virtual=192.168.22.41:80
> real=lweb1:80 masq
> real=lweb2:80 masq
> fallback=192.168.22.70:80
> service=http
> request="/us/index.jsp"
> receive="working"
> scheduler=wlc
> persistent=1800
> netmask=255.255.255.0
> protocol=tcp
> checktype=negotiate
>
> # Virtual Server for HTTPS
> virtual=192.168.22.41:443
> real=lweb3:443 masq
> service=https
> request="/test.ipage"
> receive="working"
> scheduler=wlc
> persistent=1800
> protocol=tcp
> checktype=negotiate
>
> I can get to the server through https:// but the
> pages load very slowly
> (~2 minutes compared to 4 seconds if I go directly
> to the realserver
> address)
>
> I'm not sure where to start, as it works.
>
> ATTACHMENT part 3.6 message/rfc822
> From: Janno de Wit <jdewit@xxxxxxxxxxxxxx>
> Subject: Some issues on LVS-DR with Squid
> Date: Tue, 22 Feb 2005 10:16:10 +0100
> To: lvs-users@xxxxxxxxxxxxxxxxxxxxxx
>
> Hi Folks (just not signing this with gpg,
> lvs-users-owner reject
> message type ;-)),
>
> I'm having some struggles with LVS here.
> Running Director with:
> * Linux 2.6.9 on HT Xeon 3.00G
> * Debian ipvsadm v1.24 2003/06/07 (compiled with
> popt and IPVS v1.2.0)
> * 2x BroadCom BCM5703X Gigabit Ethernet (lan-wan)
> (tigon3 driver at
> 100Mbit Full duplex)
> * Load Balancing Squid via LVS-DR over internal LAN
> to 10.0.0.x. With
> 2 machines.
>
> Case 1:
> - Each night the realservers are updated in this
> way:
> * LVS remove realserver-1, run updatescript for
> realserver 1, LVS add realserver 1
> * Next realserver
> So each realserver will be updated each day.
>
> The realserver is taken offline by executing:
> # /sbin/ipvsadm --delete-server -t $VIRTUAL_IP:$port
> -r $realserver
>
> and the server is set back online by using:
> # /sbin/ipvsadm -a -t $VIRTUAL_IP:$port -g -r
> $realserver -w $weight
>
> When LVS removed the server, all connections will be
> forwarded to the
> other realservers. But when the updated realserver
> comes back it LVS
> restores the connection counters too... This is not
> the problem, but
> it *seems* this connections never loop out the
> hashtable.
>
> Our site here is update at 3:00am and there are 'no'
> clients online,
> so i should not have many open connections.
>
> Here's a table of my experience with a cron-jobbed
> 'ipvsadm --list'
>
> 6 day uptime weight active
> inactive
> -> realserver-2:webcach Route 50 790
> 2825
> -> realserver-1:webcach Route 50 607
> 2959
> 7 days uptime
> -> realserver-2:webcach Route 50 969
> 3485
> -> realserver-1:webcach Route 50 648
> 3212
> 8 days uptime
> -> realserver-2:webcach Route 50 1054
> 3932
> -> realserver-1:webcach Route 50 653
> 3546
> 9 days uptime
> -> realserver-2:webcach Route 50 1069
> 4492
> -> realserver-1:webcach Route 50 682
> 4050
> 10 days uptime
> -> realserver-2:webcach Route 50 1054
> 4507
> -> realserver-1:webcach Route 50 655
> 4071
> 11 days uptime
> -> realserver-2:webcach Route 50 1044
> 5193
> -> realserver-1:webcach Route 50 709
> 4616
> 12 days uptime
> -> realserver-2:webcach Route 50 1109
> 5791
> -> realserver-1:webcach Route 50 695
> 4957
> 13 days uptime
> -> realserver-1:webcach Route 50 790
> 5301
> -> realserver-2:webcach Route 50 1253
> 6572
> 14 days uptime
> -> realserver-2:webcach Route 50 1285
> 7017
> -> realserver-1:webcach Route 50 824
> 5853
> 15 days uptime
> -> realserver-2:webcach Route 50 1678
> 7946
> -> realserver-1:webcach Route 50 1031
> 6541
> 16 days uptime
> -> realserver-2:webcach Route 50 1705
> 9036
> -> realserver-1:webcach Route 50 1115
> 7240
> 17 days uptime
> -> realserver-2:webcach Route 50 1656
> 9103
> -> realserver-1:webcach Route 50 1054
> 7295
> 18 days uptime
> -> realserver-2:webcach Route 50 1699
> 10154
> -> realserver-1:webcach Route 50 1085
> 8053
> 19 days uptime
> -> realserver-1:webcach Route 50 1155
> 8681
> -> realserver-2:webcach Route 50 1757
> 11265
> 20 days uptime
> -> realserver-2:webcach Route 50 1735
> 12062
> -> realserver-1:webcach Route 50 1150
> 9261
> 21 days uptime
> -> realserver-1:webcach Route 50 1226
> 9879
> -> realserver-2:webcach Route 50 1797
> 12827
> 22 days uptime
> -> realserver-2:webcach Route 50 2044
> 13726
> -> realserver-1:webcach Route 50 1311
> 10500
> 23 days uptime
> -> realserver-2:webcach Route 50 1978
> 14981
> -> realserver-1:webcach Route 50 1312
> 11211
> 24 days uptime
> -> realserver-2:webcach Route 50 1988
> 15003
> -> realserver-1:webcach Route 50 1310
> 11248
> 25 days uptime
> -> realserver-2:webcach Route 50 1838
> 15823
> -> realserver-1:webcach Route 50 1258
> 11777
>
> You see... how more often I took the servers offline
> en set them back online,
> the more inactive connections LVS creates... And I'm
> very sure this
> is is not because my site is growing ;-)
>
> The ActiveConn field is too large at midnight. My
> Squids says they
> transfer less than 1 request per second at 03:00am.
>
> Case 2:
> - I get clients complaining that their SSL
> connections gets broken
> when tunneling through our proxy. I don't have any
> idea where to
> search this. Sometimes the solution is to point
> the proxy directly
> to a realserver, otherwise this is not a solution
> for everybody (got
> someone who is using Citrix NFuse through our
> LVS-Squid setup and the
> connection suddenly breaks after some minutes .
> Maybe this is a
> squid issue? Is there a squid setting to keep
> CONNECT sessions open,
> not breaking after some minutes (disconnecting
> after 2 minutes).
>
>
> Someone having this problem too?
> Thank you very much.
>
> Regards, Janno.
>
> --
> Janno de Wit
> DNA Services B.V.
> > _______________________________________________
> lvs-users mailing list
> lvs-users@xxxxxxxxxxxxxxxxxxxxxx
> http://www.in-addr.de/mailman/listinfo/lvs-users
>
__________________________________
Do you Yahoo!?
Meet the all-new My Yahoo! - Try it today!
http://my.yahoo.com
|
