Hello everyone in the list,
thanks for all the comments on LVSing IPSec.
I see that we'll have a lot of fun with it, if we really choose the
cluster solution.
We did a little work since my first post and worked out a possible
solution, which I want to present:
(sorry for the long posting, but it becomes rather complex)
Target:
-------
Cluster of IPSec Nodes for Load balancing (redundancy will be added later).
Assumptions:
------------
- high traffic rates (200MBit+ in total)
- many tunnels (1000+)
- we somehow know* about all the existing tunnels and the subnets behind
them
- enough money to buy some (dual?) 2GHz-boxes with enough memory
* in fact we have this Information in our 'Network Management System'
BEFORE a tunnel is set up.
Overview:
---------
Our System may look like this:
'target' subnets
|
+------------------+
| Director A |
+------------------+
| |
+--------------+ +--------------+
| Real Server | | Real Server |
| IPsec term. | | IPsec term. |
+--------------+ +--------------+
| |
+------------------+
| Director B |
+------------------+
|
insecure connection e.g. Internet
|
+-----+------+
| |
+--------------+ +--------------+
| IPSec term. | | IPSec term. |
+--------------+ +--------------+
| |
+--------------+ +--------------+
| many Subnets | | many Subnets |
+--------------+ +--------------+
We want to make it possible to have a secure connection from the 'many
Subnets' to the 'target subnets'.
Main Problems:
--------------
- packets of the same IPSec tunnel MUST terminate in the same box
- packets from 'target subnets' destined for 'many Subnets' thgrough an
IPSec tunnel MUST go to the correct node (the one that terminates/begins
the tunnel).
Our Approach for the solution:
------------------------------
(at first I look at the problem from bottom to top of the drawing)
We want to distribute the IPSec tunnels to the nodes. Each 'IPSec term'
has:
- an IP-Address (=tunnel starting address)
- a subnet behind it (in the future there may be more of them, but for
now one will do the job)
Since the 'tunnel starting address' is unique, we can use it to assign
an 'IPSec term' to a node, e.g.
node1:
ipsec_term_003
ipsec_term_009
ipsec_term_002
node2:
ipsec_term_005
ipsec_term_001
ipsec_term_010
node3:
ipsec_term_008
ipsec_term_004
ipsec_term_007
to do this, we must 'inform' the Directors in the following way:
Director 1:
send packets for subnet of ipsec_term_003 to node_1
send packets for subnet of ipsec_term_009 to node_1
send packets for subnet of ipsec_term_002 to node_1
send packets for subnet of ipsec_term_005 to node_2
send packets for subnet of ipsec_term_001 to node_2
send packets for subnet of ipsec_term_010 to node_2
send packets for subnet of ipsec_term_008 to node_3
send packets for subnet of ipsec_term_004 to node_3
send packets for subnet of ipsec_term_007 to node_3
Director 2:
send packets for tunnel starting address of ipsec_term_003 to node_1
send packets for tunnel starting address of ipsec_term_009 to node_1
send packets for tunnel starting address of ipsec_term_002 to node_1
send packets for tunnel starting address of ipsec_term_005 to node_2
send packets for tunnel starting address of ipsec_term_001 to node_2
send packets for tunnel starting address of ipsec_term_010 to node_2
send packets for tunnel starting address of ipsec_term_008 to node_3
send packets for tunnel starting address of ipsec_term_004 to node_3
send packets for tunnel starting address of ipsec_term_007 to node_3
The next Idea is to store this Information in a hash in the directors.
Wheather the assignment of the 'ipsec terms' to the nodes is done in
Director 1, Director 2 or another machine isn't clear to me, but it has
to be done in one point (either DR1 or DR2 or somewhere else). Round
robin should work for the beginning, maybe we can do some tuning here,
when the system works.
Back to these mysterious hashes: if we make them static, we waste the
opportunity for the 'node sheduling' - so we must get to something
semi-dynamic :-)
We think of a big hash, that stores the IP Adresses and the node for
that IP-address. So if you have an IP, a quick search for the
corresponding node is possible.
A look at the sh and dh algorithms was quite helpful for me. But there
the hash is too small, and it's static.
In fact I have no clue if it's possible to have such a hash which will
probabaly be >50MB and I have no clue how to modify such a hash from
'outside', i.e. another server.
That's our 'concept' by now.
Does it sound stupid? or realistic?
Henrik.
|