Date: Mon, 11 Dec 2000 14:42:08 +1100 (EST) From: Stanley Hopcroft <Stanley.Hopcroft@IPAustralia.Gov.AU> To: freebsd-isp@FreeBSD.ORG Cc: Netsaint@Netsaint.ORG Subject: Re: Load-Balancing - any solutions? Message-ID: <Pine.BSF.4.21.0012111428240.3731-100000@stan.aipo.gov.au> In-Reply-To: <3A337A25.E2074762@free.fr>
next in thread | previous in thread | raw e-mail | index | archive | help
Dear Ladies and Gentlemen, I am writing with some extra stuff about ways of server load balancing that haven't been mentioned in other correspondence about this matter. The Foundy ServerIron (SI) is a well regarded means of doing Server Load Balancing (SLB) and a few other clever things also. The SLB operates using a battery of health checks on the servers it is load balancing. The most important of these are layer 7 or content based checks. The SI can send a GET request to the servers and respond to . content from the real servers using regular expression pattern matching for a good|bad pattern in the HTML returned by the server . 4xx or 5xx return codes . a combination of the above There is no necessity to do this in the SI hardware; the general method of - of a third part checking the health of servers and - reacting to change the selected server according to the results of the health checks can be implemented in other ways. The Netsaint network monitor (http://www.netsaint.org) for example, has had for some time the ability to execute "service handlers" if its content sensitive health checks reveal faults (it too can use regexps to check the returned HTML for pattersn of interest) A service handler is arbitrary code that could for example via a secure channel (ssh) reconfigure the rewriting configuation of an Apache load balancing rewrite box to rewrite requests elsewhere. The service handler could achieve the same result by other mechanisms (as is done by the Foundry Global Server Load Balancing method) such as using the Dynamic DNS capability to select another (by changing the address corresponding to the failed name so that all requests for the failed server will end up at another) server. Eliminating manual intervention in bringing on-line a warm duplicate server may be feasable by a health check triggered change of interface address or state in the standby duplicate. Likewise, routing decisions (in situations where it's undesirable to do so with a routing protocol, perhaps in a firewall situation) may be done by a health check leading to a secure channel update of a static routing table. Perhaps a more extreme case is where a network Intrusion Detection System (IDS)is used to measure health and react with SNMP writes or traps to reconfigure other infrastructure (IDSs such as the ISS Real Secure and the Cisco IDS have this capacity already but it is not difficult to fit to any IDS that has the capacity of running code when it recognises an attack signature). A host-based IDS need not behave so radically; it could react to suspicious log messages by calling someone. That said, there are cases where the SIs capacity to collect comprehensive health indications such as - layer 1 (switch or NIC link signal, when the servers are plugged into the SI) - layer 3 (network reachability) - layer 4 (accepting server port connections) - layer 7 (reacting to a request) and react to them blazingly quickly can't be substituted for. There are other software methods of doing SLB for specific servers. The Eddie Mission (?) does so for DNS servers. Thank you. Yours sincerely, S Hopcroft Network Specialist IP Australia +61 2 6283 3189 +61 2 6281 1353 FAX To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isp" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0012111428240.3731-100000>