23 Čec
2017
23 Čec
'17
18:43
Hello Knot developers,
Suppose I am running two Knot DNS instances. They're listening on
different interfaces, and slaving different sets of zones. If the
"storage" variable is the same for these two, then the two instances of
knotd will both try to write into storage/journal and storage/timers.
Is this safe to do? My understanding of LMDB is that a database can be
shared between different threads and processes because they using locking.
Regards,
Anand
24 Čec
24 Čec
10:43
Hello Anand,
Yes, LMDB itself is designed to be shareable between different threads or processes,
but it has some performance penalty (serialized write operation). Knot DNS doesn't
expect there can be other unknown zones in the timer database. Such records are
purged during server reload. But I will remove this code as it is not consistent with
other databases and it will be possible to purge zone orphans via knotc zone-purge.
But what is your motivation for two Knots on one physical server? And why
to share storages if the zone lists are different?
Regards,
Daniel
On 07/23/2017 06:43 PM, Anand Buddhdev wrote:
Hello Knot developers,
Suppose I am running two Knot DNS instances. They're listening on
different interfaces, and slaving different sets of zones. If the
"storage" variable is the same for these two, then the two instances of
knotd will both try to write into storage/journal and storage/timers.
Is this safe to do? My understanding of LMDB is that a database can be
shared between different threads and processes because they using locking.
Regards,
Anand
_______________________________________________
knot-dns-users mailing list
knot-dns-users(a)lists.nic.cz
https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-dns-users
25 Čec
25 Čec
0:17
On 24/07/2017 10:43, Daniel Salzman wrote:
Hi Daniel,
Yes, LMDB itself is designed to be shareable between
different threads or processes,
but it has some performance penalty (serialized write operation). Knot DNS doesn't
expect there can be other unknown zones in the timer database. Such records are
purged during server reload. But I will remove this code as it is not consistent with
other databases and it will be possible to purge zone orphans via knotc zone-purge.
Okay got it.
But what is your motivation for two Knots on one
physical server? And why
to share storages if the zone lists are different?
We have Knot servers providing service for in-addr.arpa. The same
servers also service child zones such as 193.in-addr.arpa,
197.193.in-addr.arpa and 0.0.193.in-addr.arpa.
If this server receives a query for 1.0.0.193.in-addr.arpa/PTR, it will
reply with an answer from the 0.0.193.in-addr.arpa zone (closest match).
Protcol-wise, this is perfectly fine. A cache will be happy with this
response. However, casual observers querying the address of
in-addr-servers.arpa might be expecting a referral. Therefore we agreed
(together with the other operators of in-addr.arpa) that we would serve
it from a different view (BIND) or instance (Knot, NSD). So this is why
we run 2 instances of Knot on the same server.
Now, under Knot 2.3, it's fine for these 2 instances to share the
storage directory, because zones and journal files are written to
separate files. However, Knot 2.4 and above wants to keep data in a
database, and so I was wondering if it might be possible to share the
journal. This is especially important when upgrading from 2.3 to 2.4 and
above.
Your answer is clear. I will just go back and set a different storage
otion, pointing to different directories.
Regards,
Anand
8:45
Hi Anand,
On 07/25/2017 12:17 AM, Anand Buddhdev wrote:
On 24/07/2017 10:43, Daniel Salzman wrote:
Hi Daniel,
Thank you for the description. That makes sense.
By the way, we plan to implement some sort of views but still we have
to solve some implementation details and also it will take some time.
Also it would be possible to create a simple query module which could
solve your situation just with one server instance.
Regards,
Daniel
Yes, LMDB itself is designed to be shareable
between different threads or processes,
but it has some performance penalty (serialized write operation). Knot DNS doesn't
expect there can be other unknown zones in the timer database. Such records are
purged during server reload. But I will remove this code as it is not consistent with
other databases and it will be possible to purge zone orphans via knotc zone-purge.
Okay got it.
But what is your motivation for two Knots on one
physical server? And why
to share storages if the zone lists are different?
We have Knot servers providing
service for in-addr.arpa. The same
servers also service child zones such as 193.in-addr.arpa,
197.193.in-addr.arpa and 0.0.193.in-addr.arpa.
If this server receives a query for 1.0.0.193.in-addr.arpa/PTR, it will
reply with an answer from the 0.0.193.in-addr.arpa zone (closest match).
Protcol-wise, this is perfectly fine. A cache will be happy with this
response. However, casual observers querying the address of
in-addr-servers.arpa might be expecting a referral. Therefore we agreed
(together with the other operators of in-addr.arpa) that we would serve
it from a different view (BIND) or instance (Knot, NSD). So this is why
we run 2 instances of Knot on the same server.
Now, under Knot 2.3, it's fine for these 2 instances to share the
storage directory, because zones and journal files are written to
separate files. However, Knot 2.4 and above wants to keep data in a
database, and so I was wondering if it might be possible to share the
journal. This is especially important when upgrading from 2.3 to 2.4 and
above. Your answer is clear. I will just go back and set a
different storage
otion, pointing to different directories.
Regards,
Anand
_______________________________________________
knot-dns-users mailing list
knot-dns-users(a)lists.nic.cz
https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-dns-users
2477
days inactive
2479
days old
3 comments
2 participants
participants (2)
-
Anand Buddhdev -
Daniel Salzman