Hello all,
Firstly thanks for such an overwhelming response for yesterday's talk +
demo.
It is hard to point the finger and say why so many turned up.
Anyway thanks.
This is a short mail to tie up some loose ends.
First I shall answer some of the questions raised yesterday. I had not
come prepared to answer that, so I kinda screwed up yesterday.
a) Can TCP sessions be carried over in a CARP failover?
It is quite obvious that if the machine that just died was the TCP
server (ssh or HTTP), then of course the session will die. ;)
However if the failover happens on a firewall/router or some
intermediate machine then of course the TCP sessions will get retained.
b) Shuveb asked something about the Master status being assigned to the
better configured machines.
I demonstrated it yesterday but then it was too hard with just one
display. It is definitely possible and trivial to designate a particular
machine as MASTER all the time.
c) Does CARP work in layer III?
CARP works in both layer II and III. It has a virtual MAC and a virtual
IP address. It is a protocol with IP number 112.
It is only because it is so low level that it works so well.
And of course it is trivial to get it working on OpenBSD. It is also
available on all BSDs. I showed how to get it working yesterday.
And oh by the way, the demo was meant only for technical people and I
wanted to show the technicalities. It was not meant to be smooth; I
guess many people expected the demo to be without hiccups and work at
the first try.
How can we learn if everything works? ;)
Anyway it is just three commands to setup CARP.
# ifconfig rl0 192.168.1.3 netmask 255.255.255.0
(assign IP to physical interface)
# ifconfig carp0 create
# ifconfig carp0 vhid 1 192.168.1.10 carpdev rl0
(for MASTER)
and
# ifconfig carp0 vhid 1 192.168.1.10 carpdev rl0 advskew 100
(for BACKUP)
And of course as I mentioned yesterday CARP will work only when there
are no routers in between. This used to be the case until things changed
recently but that must be tricky to get it working across routers.
Nowadays of course it is possible to make CARP work across routers using
a different technique and CARP also allows load balancing. I have not
tried those things and I would imagine yesterday's setup to be most
common.
I shall take a stab at the routing tutorial I missed yesterday.
And before that one more thing. In OpenBSD and other BSDs, CARP is one
way to achieve failver. The best possible way in fact.
There is another program by name relayd(8) in OpenBSD (not other BSDs)
that can poll for a particular service and failover servers.
I wanted to show this yesterday but it is way too complex and we did not
have enough machines. It works at the application layer and hence there
are pros and cons to it.
Now for the routing tutorial.
relayd(8) or any other load balancing algorithm will work by IP
redirection. IP redirection can be thought of as the cousin of NAT.
NAT rewrites the source of packets going out and by maintaining a table,
rewrites the destination IP whenever packets come in from the same
connection or UDP session.
Whereas IP redirection (known as DNAT in the linux world) works by
rewriting the destination IP address of packets coming in.
So we reflect packets arriving at our network where we are running
relayd(8) load balancer to the real web server hiding behind us by
rewriting the destination IP address.
Now this will work only when symmetric routing is implemented. Which
means that the replies coming from the server has to also go thro' the
machine running relayd(8). It is only then that the source address is
of the replies is rewritten.
Otherwise the client will simply drop packets as it will get confused
why the reply is coming from a different IP address.
I had a lot of trouble with this as I had to get this working with NAT
in my present customer environment.
It can be a pain alright but great fun too since you learn a lot about
routing in the process.
And the networks have to be different.
Remember, all machines in the same network are directly accessible. It
is stupid to assign a machine in one network as the gateway to reach
another machine in the same network. It is so obvious but most people do
not seem to know that physical interconnectivity has nothing much to do
with IP topology and routing tables.
At home I only have all my computers connected in one physical ethernet
segment.
So they are all directly connected.
But I segregated them into multiple networks with the appropriate
netmasks and IP addresses.
Please do not forget this!
" It is the logical network assignments that determine packet
routing and NOT physical interconnectivity."
It is only because I got this wrong that my relayd(8) deployment at home
was going wrong.
I later got it all working beautifully by building three networks with
two computers in one network using three computers. ;)
You can do a lot more tricks with interface aliasing.
I know I am being a bit vague but it is a deep topic and most people I
meet in the industry know precious little that I wonder where to begin.
A demo is the best way to teach but then we don't have the time.
At this this mail should get you started to think in the right
direction.
Basic idea is that you can play around with just 3 or 4 computers and
one single ethernet switch and create any number of networks and routing
topologies with interface aliasing.
Thanks. ;)
-Girish
