Jan-Piet Mens
2012-05-25 11:17:57 UTC
Starting just a few days before the day the machine running dnsmasq in
my SOHO died, I was giving some thought to how I'd go about ensuring
a backup copy of dnsmasq could take over if my only running instance
died. Needless to say, the death of the machine left my small network in
shambles, because I couldn't connect to anything to fix things without
first configuring temporary static addresses; sans DHCP, stuff fails... :)
I'm anything but a DHCP specialist, but I want to bounce this idea off
you anyway, even if you mind. ;-)
The trick, as I understand it, in setting up more than a single dnsmasq
instance in a network, is to ensure that it uses --dhcp-script to STORE
the leases and --leasefile-ro to force the script to produce a list of
current leases ("init") from which a launching dnsmasq obtains its data
before going on its usual business.
If we were able to ensure the "data store" (i.e. lease database) were
available on two machines A and B (and up to date on both of course) the
solution would be easy, except for the fact that dnsmasq does not LOOKUP
(i.e. query) for a lease in the data store except upon startup.
I'm thinking along the lines of having a function lease_query() in
lease.c which dnsmasq invokes to determine whether a lease exists before
issuing a new lease for a device.
Being very lightweight, dnsmasq must not be bloated by having a huge
MySQL or other database attached to it. I've been searching the
Internets and finally landed upon Tokyo Tryant [1] which I've discussed a
long time ago [2].
What I'm basically getting at is providing dnsmasq with an optional very
lightweight replicating server which it (optionally) uses to ensure the
lease database can be propagated to a second (or third or fourth)
dnsmasq instance. The reason I'm suggesting Tryant is that, it too, is
lightweight and offers multi-master setups.
+------------+ +-------------+
| dnsmasq | | dnsmasq |
| A | | B |
+-----+------+ +-------------+
| +
| |
| |
+-----v-------+ +------v-------+
| Tryant | | Tryant |
| A |+---------------------> B |
| |<---------------------+ |
+-------------+ +--------------+
+-------------+ +---------------+
| leases | | leases |
|-------------| |---------------|
+-------------+ +---------------+
In other words, dnsmasq (A) reads/writes leases from Tryant (A) and
dnsmasq (B) read/writes from/to Tryant (B). If Tryant (A) and (B) can
speak to eachother, the database is replicated, irrespective of which
dnsmasq (A) or (B) has last written a lease.
I'll stop here, before boring you even more, but I'll gladly send you
snippets of code and a short "howto" set up a multi-master system. Most
important IMO is to keep things very light-weight in the spirit of
dnsmasq.
Best regards,
-JP
[1] http://fallabs.com/tokyocabinet/tokyoproducts.pdf
[2] http://jpmens.net/2009/09/06/tokyocabinet-a-wow-replacement-for-dbm/
my SOHO died, I was giving some thought to how I'd go about ensuring
a backup copy of dnsmasq could take over if my only running instance
died. Needless to say, the death of the machine left my small network in
shambles, because I couldn't connect to anything to fix things without
first configuring temporary static addresses; sans DHCP, stuff fails... :)
I'm anything but a DHCP specialist, but I want to bounce this idea off
you anyway, even if you mind. ;-)
The trick, as I understand it, in setting up more than a single dnsmasq
instance in a network, is to ensure that it uses --dhcp-script to STORE
the leases and --leasefile-ro to force the script to produce a list of
current leases ("init") from which a launching dnsmasq obtains its data
before going on its usual business.
If we were able to ensure the "data store" (i.e. lease database) were
available on two machines A and B (and up to date on both of course) the
solution would be easy, except for the fact that dnsmasq does not LOOKUP
(i.e. query) for a lease in the data store except upon startup.
I'm thinking along the lines of having a function lease_query() in
lease.c which dnsmasq invokes to determine whether a lease exists before
issuing a new lease for a device.
Being very lightweight, dnsmasq must not be bloated by having a huge
MySQL or other database attached to it. I've been searching the
Internets and finally landed upon Tokyo Tryant [1] which I've discussed a
long time ago [2].
What I'm basically getting at is providing dnsmasq with an optional very
lightweight replicating server which it (optionally) uses to ensure the
lease database can be propagated to a second (or third or fourth)
dnsmasq instance. The reason I'm suggesting Tryant is that, it too, is
lightweight and offers multi-master setups.
+------------+ +-------------+
| dnsmasq | | dnsmasq |
| A | | B |
+-----+------+ +-------------+
| +
| |
| |
+-----v-------+ +------v-------+
| Tryant | | Tryant |
| A |+---------------------> B |
| |<---------------------+ |
+-------------+ +--------------+
+-------------+ +---------------+
| leases | | leases |
|-------------| |---------------|
+-------------+ +---------------+
In other words, dnsmasq (A) reads/writes leases from Tryant (A) and
dnsmasq (B) read/writes from/to Tryant (B). If Tryant (A) and (B) can
speak to eachother, the database is replicated, irrespective of which
dnsmasq (A) or (B) has last written a lease.
I'll stop here, before boring you even more, but I'll gladly send you
snippets of code and a short "howto" set up a multi-master system. Most
important IMO is to keep things very light-weight in the spirit of
dnsmasq.
Best regards,
-JP
[1] http://fallabs.com/tokyocabinet/tokyoproducts.pdf
[2] http://jpmens.net/2009/09/06/tokyocabinet-a-wow-replacement-for-dbm/