[Opendnssec-user] ods-signerd and job scheduling
Berry A.W. van Halderen
berry at nlnetlabs.nl
Fri Oct 20 12:00:48 UTC 2017
On 10/19/2017 04:28 PM, Jake Zack wrote:
> Can ods-signerd sign more than a single zone concurrently, or does the
> job scheduler ensure that there is only one signing happening at a time?
The signer will sign as many zones as specified by WorkingThreads in the
conf.xml at the same time. These "threads" are distributing the work
of the actual signing over SignerThreads.
If you specify 1 signerthreads and 4 workerthreads (a stupid
configuration, but for clarification), 4 zones will be signed
simultaneously, but it it will generate a signature from each
of these zones alternating (roughly, it isn't absolutely fair).
> If it can only sign one at a time, what happens if it gets 20 AXFR’s in
> using the axfr adapter? Just queued?
AXFRs are done by another thread outside of this pool. Of course its
performance might get affected if the other threads very busy.
There is just one thread for transfers, it will use asynchronous I/O
to serve all requests.
However when a zone is getting signed, there is a period in which it
cannot simultanously serve the zone as well. This is being worked
on for the next release of OpenDNSSEC.
> If it can sign more than one at a time, is this based on number of
> cores/threads? Any special considerations anyone can think of assuming
> mysql backend?
The SQL backend is at the moment only used for the enforcer, so there
are no considerations for your signer here. The number of Worker/
Signer threads to use depends on how you do the actual signing.
The signing process is heavily dependent on the speed and concurrency
of creating the signatures. If you have an HSM, you should look
in the documentation there on the optimum number of concurrent
operations it can handle. Experimenting works quite well.
If you are using a software based solution, like SoftHSM that
uses the same processor as the signer daemon uses, in general
you get the best performance setting the number of SignerThreads
to the number of cores. In case of hyperthreading or likewise
technology the number of virtual cores. Setting it one above
the actual number of cores in fact makes the actual throughput
even better, but at the expense of a general less responsive
system, therefor I'd recommend the number of cores to use.
> -Jacob Zack
> DNS Architect – CIRA (.CA TLD)
> Opendnssec-user mailing list
> Opendnssec-user at lists.opendnssec.org
More information about the Opendnssec-user