-3

In The Linux Programming Interface Sec 60.4, it talks about design a server that handles multiple requests using multiple processes or threads, or pools of processes or threads. Then it discusses another approach "server farm":

Other approaches to handling high client loads involve the use of multiple server systems—a server farm.

One of the simplest approaches to building a server farm (employed by some web servers) is DNS round-robin load sharing (or load distribution), where the authori- tative name server for a zone maps the same domain name to several IP addresses (i.e., several servers share the same domain name). Successive requests to the DNS server to resolve the domain name return these IP addresses in a different order, in a round-robin fashion. Further information about DNS round-robin load sharing can be found in [Albitz & Liu, 2006].

Round-robin DNS has the advantage of being inexpensive and easy to set up. However, it does present some problems. One of these is the caching performed by remote DNS servers, which means that future requests from clients on a particular host (or set of hosts) bypass the round-robin DNS server and are always handled by the same server. Also, round-robin DNS doesn’t have any built-in mechanisms for ensuring good load balancing (different clients may place different loads on a server) or ensuring high availability (what if one of the servers dies or the server application that it is running crashes?). Another issue that we may need to consider— one that is faced by many designs that employ multiple server machines—is ensuring server affinity; that is, ensuring that a sequence of requests from the same client are all directed to the same server, so that any state information maintained by the server about the client remains accurate.

A more flexible, but also more complex, solution is server load balancing. In this scenario, a single load-balancing server routes incoming client requests to one of the members of the server farm. (To ensure high availability, there may be a backup server that takes over if the primary load-balancing server crashes.) This eliminates the problems associated with remote DNS caching, since the server farm presents a single IP address (that of the load-balancing server) to the outside world. The load-balancing server incorporates algorithms to measure or estimate server load (perhaps based on metrics supplied by the members of the server farm) and intelligently distribute the load across the members of the server farm. The load-bal- ancing server also automatically detects failures in members of the server farm (and the addition of new servers, if demand requires it). Finally, a load-balancing server may also provide support for server affinity. Further information about server load balancing can be found in [Kopparapu, 2002].

When using a server farm (built on either DNS round-robin load sharing or server load-balancing),

  • is it correct that all machines in the farm run the same server program?

  • is the server program still designed in the same way as a standalone server program: handle multiple requests concurrently (using methods such as multiple processes/threads or pools of processes/threads)?

  • or does server farm change the design of the server program in some way, e.g. only handle just one request?

Thanks.

4
  • 2
    You need to consider how you will manage state in a farm. In a single server application you can get away with having state accessible to the one server application. But in a farm, and since each request may be handled by a different server in the farm, the server program needs to ensure its strategy for maintaining state across requests accounts for this. – quaabaam Nov 25 '20 at 1:34
  • @quaabaam Thanks. Can you elaborate how farm change server program design? What books on this? – Tim Nov 25 '20 at 1:44
  • 1
    In a farm the servers need a common place to read/write state (e.g. session state). A user's first request may go to server 1 and their next may go to server 2. These servers need a shared state strategy in order for state to be maintained across requests and servers. Look into 'server farm session state'. This is an older link but the ideas are still relevant. State Management. – quaabaam Nov 25 '20 at 1:55
  • Technically, you can design your own system however you want. They don't all need to run the same program. In fact it's common to have more than one different group of servers with a different program on each group. – user253751 Nov 25 '20 at 17:12
2
  • is it correct that all machines in the farm run the same server program?

Yes, that is correct

  • is the server program still designed in the same way as a standalone server program: handle multiple requests concurrently (using methods such as multiple processes/threads or pools of processes/threads)?
  • or does server farm change the design of the server program in some way, e.g. only handle just one request?

The application should still be designed to handle multiple concurrent requests, but there are some other considerations to take into account.

The most important consideration is that you cannot use memory to share information between the processes that handle requests, because some of those processes run on a different machine.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.