|
Hi!
I have written a little patch for the VS 0.8. I am calling it a
Persistent Client Connection patch and it changes the scheculing policy
of the virtual server. The patch is included in this mail as an
attachment and it includes a full VS patch for a clean 2.0.36 kernel.
What does it do: each time a new client connects to a server, it
remembres the real server the client was redirected to and forwards all
other client requests that follow to the same real server.
This solved some problems with the VS. Ftp and similar protocols now
work even without masq_apps being installed. Also there are no more
problems with the HTTP cookies issued by particular real servers to
particular clients (otherwise, further client connections could be
redirected to distinctive real servers without the cookies).
The other nice thing of the patch is that it improves performance
(maximum throughput) of the virtual server for about 5 times (by my
estimation and also test results on tunneled configuration)... Let me
explain this in details. When the client connects to the server for the
first time, the router remembers the real server assigned to the client
by adding a template to the masquerading table. The template is a simple
masquerading entry with all ports and protocol set to 0. The template
has a reference count and is cleared from the table 30 minutes after the
last connection from that client had expired. If the client establishes
a new connection within those 30 minutes, the template clock is
refreshed and the client's packets will be redirected to the same real
server. This means it is safe to delete masq entries in the hash table
even if the connection hasn't expired, because if there is some more
activity on that connection, the masq entry can be restored from the
template. Therefore expiration timeouts can be reduced which means less
masquerading entries in the hash table, which leads to less work for the
kernel and better performance.
The scheduling algorithm is now limited to creating new templates. Since
we do not know how many connections will be created by the client, the
round robin scheuling algorithms seem somewhat obsolete. The LC and WLC
algorithms are more appropriate. Note that since there are shorter
timeouts for the masq entries, the number of active connections reflect
the load on the real server much better and the LC/WLC algorithms should
therefore perform better.
On the other hand, the patch has a serious limitation of forwarding all
connections of the same client to the same server, which means all
servers have to be configured equally. For example, you can't have
servers A, B and C handling HTTP requests and servers C and D handling
FTP requests.
All servers A, B, C, D and E now have to have both HTTP and FTP servers
installed.
This problem can be solved in the future by implementing port groups for
certain services. For example client connections to port 80 could have a
different template than those for ports 21 and 22. Otherwise the ip_fw.c
should check when ippfvsadm adds a new server, the new server should be
configured with all existing ports, or when a new port is added, the
port should be assigned to all other servers to. Right now, it is the
users responsibility to confugure the VS properly.
Also for the future to work on work is to detect which masq entries were
created by the VS and which by normal masquerading and set the timeouts
properly (shorter timeouts for VS, longer for masquerading). Right now,
all timeouts get shorter, since in most cases, the VS enabled computers
will only do VS anyway.
Have a nice time,
Peter
|
