|
> problems with the HTTPS check leaking memory in the past, so I
> would start by seeing if that is the culprit.
For anyone who is interested, my ldirectord.cf looks like this:
checktimeout=10
checkinterval=2
autoreload=yes
logfile="/var/log/ldirectord.log"
logfile="local0"
quiescent=yes
#supervised
#
# -- Terminal Servers
#
# Virtual Server for RDP, Outside to DMZ
virtual=192.168.5.100:3389
real=192.168.15.83:3389 masq
real=192.168.15.84:3389 masq
scheduler=wlc
protocol=tcp
checktype=connect
#
# -- FTP Servers
#
# Virtual Service for FTP, Outside to Inside
virtual=192.168.5.100:21
real=192.168.10.61:21 masq
real=192.168.10.62:21 masq
service=ftp
request="checkup.txt"
receive="ftp_is_up"
login="load-balancer"
passwd="checkUp@now <mailto:checkUp@now> "
scheduler=wlc
protocol=tcp
checktype=negotiate
persistent=360
#
# -- SMB Servers
#
# Virtual Server for SMB, Outside to DMZ
virtual=192.168.5.100:445
real=192.168.15.83:445 masq
#real=192.168.15.82:445 masq
scheduler=wlc
#persistent=600
protocol=tcp
checktype=connect
#
# -- Tomcat Servers
#
# Virtual Server for tomcat(site001), Outside to Inside
virtual=192.168.5.100:3001
real=192.168.10.61:3001 masq
real=192.168.10.62:3001 masq
service=http
request="/checkup.html"
receive="site001_tomcat_is_up"
scheduler=lblc
protocol=tcp
checktype=3
persistent=360
(plus 60 more entries like the one above)
#
# -- Lab Results
#
# Virtual Server for LabCorp Results(site005), Outside to Inside
virtual=192.168.5.100:11005
real=192.168.10.61:11005 masq
scheduler=wlc
protocol=tcp
checktype=off
# Virtual Server for LabCorp Results(site003), Outside to Inside
virtual=192.168.5.100:11003
real=192.168.10.73:11003 masq
scheduler=wlc
protocol=tcp
checktype=off
#
# -- MySQL Servers
#
# Virtual Server for mysql(site002), Outside to Inside
virtual = 192.168.5.100:5002
real=192.168.10.200:5002 masq
scheduler=wlc
protocol=tcp
checktype=connect
(plus 60 more entries like the one above)
# --end
> In answer to the multi-threading question - no ldirectord is not
> multi-threaded, though you can split your configuration up into
> multiple configuration files and run multiple instances of ldirectord.
> I can handle the forking for you, or you can do it manually.
> Somewhere in the thread it was suggested that you could split your
> configuration up so that you have one ldirectord process per virtual
> service as a means of attempting to narrow down the problem. I think that
> this is a good idea.
I'm willing to try that. I'll have to create two ldirectord init scripts using
separate config files and two heartbeat resources. Is that correct?
> The primary motivation for parallelising ldirectord either within
> a single process or with multiple processes is usually to minimise
> the delays inherent in running checks serially. This would actually
> result in increased CPU usage - as it would be doing more work in
> a given space of time.
Wouldn't splitting it into different instances have the same effect then?
> With regards to LVS, it is almost certainly not the cause of ldirectord
> taking up 50% of CPU. ldirectord only configures LVS.
It also does the health checking, right? I think the earlier suggestion about
overlapping requests may have merit.
--Eric
Disclaimer - October 31, 2008
This email and any files transmitted with it are confidential and intended
solely for LinuxVirtualServer.org users mailing list.,LinuxVirtualServer.org
users mailing list.. If you are not the named addressee you should not
disseminate, distribute, copy or alter this email. Any views or opinions
presented in this email are solely those of the author and might not represent
those of . Warning: Although has taken reasonable precautions to ensure no
viruses are present in this email, the company cannot accept responsibility for
any loss or damage arising from the use of this email or attachments.
This disclaimer was added by Policy Patrol: http://www.policypatrol.com/
|
