The Poor Man's Load Balancing Mechanism for Client-Server Information Systems Technical Note Structural Informatics Systems Development Group Department of Biological Structure, University of Washington, Mailstop SM-20 by Kraig Eno, kraig@u.washington.edu January 28, 1993 This document describes a very simple mechanism for satisfying requests for server connections where a well-known group of servers exists, when not all the servers are guaranteed to be available at all times. Statement of the Problem ------------------------ Consider N client machines or processes, denoted C(1)..C(n), connecting via TCP/IP to M servers, denoted S(1)..S(m). Several types of servers may run on any given machine, and the same server software can be run on several kinds of hardware. At any given time, server S(i) may or not be available to service clients, either because some failure has occurred or because some performance or user limit has been exceeded. When a client process C(j) starts, it must make a connection to a server in order to present useful information; this connection is relatively long-lived, usually lasting for the duration of the session. In order to establish a connection, the client must: a) obtain the address of one or more servers S(i1), S(i2), ... b) determine which of these servers, if any, is available Instead of putting the burden on the client machine to store the list of server addresses and try each one at startup time, I propose a central intermediary, a "dispatch" mechanism, running on one or more of the servers which will store the addresses of all the servers and supply an address to each client as they are requested. Implementation -------------- In our case, all server processes run under Unix, using the inetd mechanism to handle incoming network connections (see "man inetd"). A client connects to the dispatcher on port 5010 and issues the request find-service S The dispatch program determines the IP address of the client automatically using getpeername(). It then uses the service name S to open a file which is specific to that service, scans that file to find what servers match the client, and determines on the fly which of those servers is actually available. It returns the first one it finds, and the client uses that for its connection. An example of such a file is "si3", which contains server information for the Structural Information server version 3. It looks like 128.95.10.* 128.95.10.108 sulcus.biostr.washington.edu 5004 1 SULCUS 128.95.10.* 128.95.10.169 tarsus.biostr.washington.edu 5004 1 TARSUS *.*.*.* 128.95.32.247 ghini.engr.washington.edu 5002 0 - The fields in this file are blank-separated, and are defined in this order: client, server-address, server-name, server-port, status-check, database "client" is an IP number designed to match the IP of an incoming client or group of potential clients; any or all of the numeric fields can be replaced with '*' to match anything in that field. The first match is used "server-address" is the IP address that the client should use for a connection if this server is available. "server-name" is currently used only for feedback to the user. "server-port" is necessary since the port number may vary on different machines (or even in the same machine). "status-check", if it is '1', indicates that the status of the server should be checked for availability; not all servers can be checked in this way. "database" is specific to the application at hand, but could be used as a generic string argument for different servers. In this case, it is the name of the database which should be checked. Advantages ---------- can modify the distribution of servers without reconfiguring clients security based on IP number of client system uses dynamic information instead of static settings to determine availability; smart failover can enforce software user limits easily Disadvantages ------------- dispatch server MUST be working or the entire system fails the server address list itself should be cached or stored in a database if it gets very large Discussion ---------- should look at performance metrics to allow system to choose the best server, not just take the first available one use rsh to go to a particular server and do various tests have a mechanism for returning at least an integer, which should be normalized to account for basic machine capabilities; a client should be able to choose the one with the highest metric, and be reasonably sure that it will provide the best response instead of returning a single server name & address, we could return a list and allow the client to choose; this would be advantageous if the connection drops and it becomes necessary for the user to choose an alternate (as might be the case if the dispatch server is further away and less reliable than the servers themselves) dbname is too specific; better to call it "arg" or something. We should use gethostbyname() to translate host names, instead of storing their IP addresses in a table which will go out of date.