design DNS resolver

[Martin Hotze]

Hallo,

gegeben seien 3-4 handvoll Server und ein paar Hundert Accesskunden,
geographisch an einem Standort zusammengeführt.

gesucht:
neues und passend(!) performantes Setup für DNS resolver.

geplant:
2 (physikalisch) getrennte Maschinen mit pdns_recurser

Überlegungen mit der Bitte um Input/Feedback:
- 2x direkt auf Blech oder würdet ihr virtualisieren (warum?)
- lieber zuviel RAM oder habt ihr eine Faustformel?

So wie das Google mit deren public DNS Infrastruktur macht wird von
denen ja (leider) nicht veröffentlicht, auch finden sich sonst auch kaum
verwertbare Informationen bzgl. sinnvollem DNS Design.

any Input appreciated.

#m
--
"What would I do with 72 virgins? That's not a reward,
that's a punishment. Give me two seasoned whores any day."
(Billy Connolly)

[Florian Weimer]

* Martin Hotze:

> gegeben seien 3-4 handvoll Server und ein paar Hundert Accesskunden,
> geographisch an einem Standort zusammengeführt.

Wieviel Spammer sind darunter? Manche machen außergewöhnlich viel
DNS-Verkehr.

> 2 (physikalisch) getrennte Maschinen mit pdns_recurser

Wenn Du viele UNIX-artige Clients hast, mußt Du eventuell Failover auf
Netzebene machen, weil die Clients das nicht selbst hinbekommen.

> - 2x direkt auf Blech oder würdet ihr virtualisieren (warum?)

Wenn es ohne Virtualisierung geht, würde ich darauf verzichten. DNS
hat dank Source Port Randomization viele kurzlebige Flows und basiert
auf UDP. Das ist eher untypisch und die Virtualisierungs-Container
kommen vielleicht nicht damit klar. Ebenso viele Firewalls.

> - lieber zuviel RAM oder habt ihr eine Faustformel?

1 GB sollte locker reichen, wenn die Kundschaft halbwegs homogen ist.

> So wie das Google mit deren public DNS Infrastruktur macht wird von
> denen ja (leider) nicht veröffentlicht, auch finden sich sonst auch
> kaum verwertbare Informationen bzgl. sinnvollem DNS Design.

ISC veranstalt Kurse (zu deren Inhalt ich nichts sagen kann).

Vom Failover-Problem abgesehen sollte die genannten Client-Zahlen auf
halbwegs aktueller Hardware keine wesentliche Schwierigkeit
darstellen.

[Georg Schwarz]

Florian Weimer <f...@deneb.enyo.de> wrote:

> Wenn Du viele UNIX-artige Clients hast, mußt Du eventuell Failover auf
> Netzebene machen, weil die Clients das nicht selbst hinbekommen.

-v, please

--
Georg Schwarz http://home.pages.de/~schwarz/
georg....@freenet.de +49 170 8768585

[Andreas Schwarz]

On Wed, 8 Feb 2012 22:25:23 +0100, georg....@freenet.de (Georg Schwarz) wrote:

> Florian Weimer <f...@deneb.enyo.de> wrote:
>
> > Wenn Du viele UNIX-artige Clients hast, mußt Du eventuell Failover auf
> > Netzebene machen, weil die Clients das nicht selbst hinbekommen.
>
> -v, please

Er meint wahrscheinlich ein AnyCast Modell, DNS ist ja sozusagen die
"Referenz Implementierung".



--

PGP: 0x661AB571

[Juergen P. Meier]

Martin Hotze <local...@gmx.at>:

> gegeben seien 3-4 handvoll Server und ein paar Hundert Accesskunden,
> geographisch an einem Standort zusammengeführt.
>
> gesucht:
> neues und passend(!) performantes Setup für DNS resolver.

Was sind denn die genauen Anforderungen an Queries/sec, mittlere
Antwortzeit, Caching, offline-storage, DNSSEC Verifikation,
Filtermoeglichkeiten etc?

Um was fuer sorten Kunden handelt es sich, und was machen die
ueblicherweise per DNS? Nur Websurfende Haushalte?

Selbst ein 10 Jahre alter PC kann ueber tausend queries/sec.
Inkl. DNSSEC Validierung.

> geplant:
> 2 (physikalisch) getrennte Maschinen mit pdns_recurser

Fuer ein paar hundert Kunden ist praktisch alles oversized was du mit
moderner Hardware und Standardsoftware bauen kannst.
Zumindest bei Durschnitts Access-Kunden ohne besondere anforderungen.

Apropos: meinst du mit "pdns_recurser" PowerDNS[tm] Recursor oder pdnsd
recursor?

> Überlegungen mit der Bitte um Input/Feedback:
> - 2x direkt auf Blech oder würdet ihr virtualisieren (warum?)

Das ist in diesem Kontext eine reine Geschmacksfrage. Es gibt kaum
fuer die Funktion als Recursor technisch relevanten Argumente.

> - lieber zuviel RAM oder habt ihr eine Faustformel?

Fuer einen DNS Recursor fuer hunderte von Kunden: mindestens 0.5 GByte.

> So wie das Google mit deren public DNS Infrastruktur macht wird von
> denen ja (leider) nicht veröffentlicht, auch finden sich sonst auch kaum
> verwertbare Informationen bzgl. sinnvollem DNS Design.

Google will an die korrelierten Daten aller Nutzer herankommen, es
geht Google primaer nicht darum, performante Recursor anzubieten,
sondern Log-Korrelatoren die DNS Lookups von zig tausend Kunden
mit anderen Datensaetzen moeglichst zeitnah korrelieren koennen.
Erstens ist sowas in .DE generell illegal und zweitens wirst du damit
gegen jede uebliche Datenschutzvereinbarung mit deinen Kunden
verstossen.
Das ist also nicht vergleichbar.
Ausserdem koennen Google DNS resolver kein DNSSEC.

> any Input appreciated.

HTH,
Juergen
--
Juergen P. Meier - "This World is about to be Destroyed!"
end
If you think technology can solve your problems you don't understand
technology and you don't understand your problems. (Bruce Schneier)

[Martin Hotze]

Am 09.02.2012 05:40, schrieb Juergen P. Meier:
> Martin Hotze<local...@gmx.at>:
>> gegeben seien 3-4 handvoll Server und ein paar Hundert Accesskunden,
>> geographisch an einem Standort zusammengeführt.
>>
>> gesucht:
>> neues und passend(!) performantes Setup für DNS resolver.
>
> Was sind denn die genauen Anforderungen an Queries/sec, mittlere
> Antwortzeit, Caching, offline-storage, DNSSEC Verifikation,
> Filtermoeglichkeiten etc?

ui, Queries/sec müste ich mal aktuell rausloggen, DNSSEC wird kommen;

gefiltert wird nicht, da stelle ich mich mal auf den Standpunkt dass wir
das als Diensteanbieter nicht dürfen und ich das auch nicht will. Und so
lange es geht ist mir da der Gesetzgeber schnuppe.

> Um was fuer sorten Kunden handelt es sich, und was machen die
> ueblicherweise per DNS? Nur Websurfende Haushalte?

Quer durch den Gemüsegarten, große Businesskunden, 1-Mann Firma,
Private, alles dabei.

> Selbst ein 10 Jahre alter PC kann ueber tausend queries/sec.
> Inkl. DNSSEC Validierung.

_können_: ja. Mir geht es um *gute* Performance.

>> geplant:
>> 2 (physikalisch) getrennte Maschinen mit pdns_recurser
>
> Fuer ein paar hundert Kunden ist praktisch alles oversized was du mit
> moderner Hardware und Standardsoftware bauen kannst.
> Zumindest bei Durschnitts Access-Kunden ohne besondere anforderungen.

Die Anforderung: so schnell wie möglich mit sinnvollen Mitteln und ohne
zu übertreiben.

> Apropos: meinst du mit "pdns_recurser" PowerDNS[tm] Recursor oder pdnsd
> recursor?

ersteren.

>> Überlegungen mit der Bitte um Input/Feedback:
>> - 2x direkt auf Blech oder würdet ihr virtualisieren (warum?)
>
> Das ist in diesem Kontext eine reine Geschmacksfrage. Es gibt kaum
> fuer die Funktion als Recursor technisch relevanten Argumente.

DNS queries beantworten oder _schnell_ beantworten, das ist der Punkt.
Da kann also eine andere VM am selben Blech schnell mal in die Suppe
spucken.

>> - lieber zuviel RAM oder habt ihr eine Faustformel?
>
> Fuer einen DNS Recursor fuer hunderte von Kunden: mindestens 0.5 GByte.
>
>> So wie das Google mit deren public DNS Infrastruktur macht wird von
>> denen ja (leider) nicht veröffentlicht, auch finden sich sonst auch kaum
>> verwertbare Informationen bzgl. sinnvollem DNS Design.
>
> Google will an die korrelierten Daten aller Nutzer herankommen, es
> geht Google primaer nicht darum, performante Recursor anzubieten,

das "Problem": die _sind_ performant. Und mir geht es in diesem
Zusammenhang um Performance; mir ist bewusst dass Google Daten sammelt,
aber das war hier nicht der Punkt

> HTH,
> Juergen

tnx,

[Martin Hotze]

Am 08.02.2012 21:38, schrieb Florian Weimer:
> * Martin Hotze:
>
>> gegeben seien 3-4 handvoll Server und ein paar Hundert Accesskunden,
>> geographisch an einem Standort zusammengeführt.
>
> Wieviel Spammer sind darunter? Manche machen außergewöhnlich viel
> DNS-Verkehr.

oh, in aller Regel gut erzogen; es ist in erträglich geringem Ausmass
bzw wird schnell geerdet.

>> 2 (physikalisch) getrennte Maschinen mit pdns_recurser
>
> Wenn Du viele UNIX-artige Clients hast, mußt Du eventuell Failover auf
> Netzebene machen, weil die Clients das nicht selbst hinbekommen.

die Server sind 99% Linux, die Kunden sind idR Windows, bissi Apple,
noch weniger Linux.

>> - 2x direkt auf Blech oder würdet ihr virtualisieren (warum?)
>
> Wenn es ohne Virtualisierung geht, würde ich darauf verzichten. DNS
> hat dank Source Port Randomization viele kurzlebige Flows und basiert
> auf UDP. Das ist eher untypisch und die Virtualisierungs-Container
> kommen vielleicht nicht damit klar. Ebenso viele Firewalls.

OK.

>> - lieber zuviel RAM oder habt ihr eine Faustformel?
>
> 1 GB sollte locker reichen, wenn die Kundschaft halbwegs homogen ist.

naja, die sind zwar geografisch ziemlich geballt, aber von der Nutzung
her querbeet. Es sollte nicht nur locker reichen damit es eben
funktioniert sondern ich möchte quasi "most bang for the bucks" oder:
DNS resolving soll auch _schnell_ sein. So schnell wie mit sinnvollen
und einfachen Mitteln machbar ist.

> Vom Failover-Problem abgesehen sollte die genannten Client-Zahlen auf
> halbwegs aktueller Hardware keine wesentliche Schwierigkeit
> darstellen.

ich überspitze die Frage:
Lieber eine Standalone Atomkiste mit 4GB Ram dediziert und nur für DNS
hinstellen oder ein anderer Server mit 2x Xeon und 40GB RAM der schon
Web oder Mail macht da noch DNS mitmachen?

[Juergen Ilse]

Hallo,

Juergen P. Meier <nospa...@jors.net> wrote:
> Um was fuer sorten Kunden handelt es sich, und was machen die
> ueblicherweise per DNS? Nur Websurfende Haushalte?
> Selbst ein 10 Jahre alter PC kann ueber tausend queries/sec.
> Inkl. DNSSEC Validierung.

... aber nicht mir dem von ihm eingeplanten pdns-recursor, denn DNSSEC-
Validierung ist bei dem IIRC noch nicht eingebaut (soll aber bald kommen).
Wenn der Client aber validieren will: der pdns-recursor unterstuetzt alle
fuer DNSSEC benoetigten Record-Typen, nur ist eben noch nicht eingebaut,
dass er bereits selbst validiert. Wenn DNSSEC-Validierung auf dem DNS
benoetigt wird, wird man auf andere Software (bind oder unbound?) zurueck-
greifen muessen (aber auch da wird man fuer ein solches Szenario nicht
auf eine besonders dicke Machine zurueckgreifen muessen, das Szenario
ist im Vergleich dazu, was ueblicherweise an groessere DNS fuer Anfor-
derungen gestellt werden, eher lachhaft).

>> geplant:
>> 2 (physikalisch) getrennte Maschinen mit pdns_recurser
> Fuer ein paar hundert Kunden ist praktisch alles oversized was du mit
> moderner Hardware und Standardsoftware bauen kannst.

Korrekt.

> Zumindest bei Durschnitts Access-Kunden ohne besondere anforderungen.
> Apropos: meinst du mit "pdns_recurser" PowerDNS[tm] Recursor oder pdnsd
> recursor?

Mit an Sicherheit grenzender Wahrscheinlichkeit ersteren, denn nur der
heisst pdns-recursor, der andere hat mit pdnsd einen anderen Namen. Wenn
die beiden zur Wahl stuenden, hielte ich auch ersteren fuer die bessere
Wahl. Dies hier sind ueberigens die Statistik-Daten eines pdns-recursors
der hier im Produktivbetrieb bei meinem Arbeitgeber laeuft (und der wird
fuer mehr als nur ein paar hundert Rechner benutzt und laeuft praktisch
wartungsfrei):
------------------
[root@ns3a ~]# rec_control get-all
all-outqueries 57720067
dlg-only-drops 0
dont-outqueries 18305
outgoing-timeouts 1370054
tcp-outqueries 38502
throttled-out 536485
throttled-outqueries 536485
unreachables 115089
answers-slow 973896
answers0-1 10698106
answers1-10 6679704
answers10-100 23056519
answers100-1000 7301384
case-mismatches 0
chain-resends 954373
client-parse-errors 773
edns-ping-matches 0
edns-ping-mismatches 0
ipv6-outqueries 0
no-packet-error 42052808
noedns-outqueries 57758562
noerror-answers 104650628
noping-outqueries 0
nsset-invalidations 101399
nxdomain-answers 34689365
over-capacity-drops 0
qa-latency 12978
questions 141217089
resource-limits 0
server-parse-errors 1
servfail-answers 1877067
spoof-prevents 0
tcp-client-overflow 0
tcp-questions 1221
unauthorized-tcp 0
unauthorized-udp 0
unexpected-packets 500
cache-entries 4326010
cache-hits 7754691
cache-misses 40954922
concurrent-queries 0
negcache-entries 87637
nsspeeds-entries 8408
packetcache-entries 461456
packetcache-hits 92507593
packetcache-misses 48709165
sys-msec 9045267
tcp-clients 0
throttle-entries 165
uptime 1808024
user-msec 20013080
[root@ns3a ~]#
--------------------

Aktuell antwortet er also im Schnitt innerhalb von 12-13 ms auf eine Anfrage,
die Maschine ist aber eigentlich fuer den Zweck schon voellig ueberzogen
(2,4 Ghz Xeon CPU, 4 GB Ram), aber als reine Server-Hardware bekommt man ja
aktuell nur noch wenig schwaecheres ...

Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)
--
Ein Domainname ist nur ein Name, nicht mehr und nicht weniger.
Wer mehr hineininterpretiert, hat das Domain-Name-System nicht
verstanden.

[Lutz Donnerhacke]

* Juergen Ilse wrote:
> benoetigt wird, wird man auf andere Software (bind oder unbound?) zurueck-

Unbound. Praktische Erfahrung sagt, daß unbound immer und in jedem Fall
gegen bind gewinnt. Nur in komplexeren Setups ist Bind noch sinnvoll
(z.B. Mischbetrieb Resolver und Auth-Server, verschiedene Views, ACLs ...)

> greifen muessen (aber auch da wird man fuer ein solches Szenario nicht
> auf eine besonders dicke Machine zurueckgreifen muessen, das Szenario
> ist im Vergleich dazu, was ueblicherweise an groessere DNS fuer Anfor-
> derungen gestellt werden, eher lachhaft).

Brauchen tut man zwei Maschinen, die IPv6, IPv4 stabil beherreschen und
etwas RAM und CPU frei haben. Platten-IO ist unnötig.

> unreachables 115089
> answers-slow 973896
> answers0-1 10698106
> answers1-10 6679704
> answers10-100 23056519
> answers100-1000 7301384

Das sind die Wartezeiten. Die kannst Du wenig beeinflussen, weil sie von
externen Server abhängen. Ist halt so. DNSSEC macht es nur noch langsamer,
es sei denn Du hast einen Hack drin, der NSEC auch für andere Queries
auswertet, dann wird es rasend schnell.

Der Hack ist schon implementiert, er wird im Bereich der DLV benutzt. Man
muß ihn nur für die anderen Zonen auch aktivieren.

> Aktuell antwortet er also im Schnitt innerhalb von 12-13 ms auf eine Anfrage,
> die Maschine ist aber eigentlich fuer den Zweck schon voellig ueberzogen
> (2,4 Ghz Xeon CPU, 4 GB Ram), aber als reine Server-Hardware bekommt man ja
> aktuell nur noch wenig schwaecheres ...

Tja, das Problem moderner Zeiten. Da lob ich mir meine Altlasten.

[Juergen Ilse]

Hallo,

Lutz Donnerhacke <lu...@iks-jena.de> wrote:
> * Juergen Ilse wrote:
>> benoetigt wird, wird man auf andere Software (bind oder unbound?) zurueck-
> Unbound. Praktische Erfahrung sagt, daß unbound immer und in jedem Fall
> gegen bind gewinnt. Nur in komplexeren Setups ist Bind noch sinnvoll
> (z.B. Mischbetrieb Resolver und Auth-Server, verschiedene Views, ACLs ...)

Da ich mit unbound keine praktischen Erfahrungen habe, wollte ich dazu
keine Empfehlung abgeben sondern nur moegliche Alternativen erwaehnen ...

>> greifen muessen (aber auch da wird man fuer ein solches Szenario nicht
>> auf eine besonders dicke Machine zurueckgreifen muessen, das Szenario
>> ist im Vergleich dazu, was ueblicherweise an groessere DNS fuer Anfor-
>> derungen gestellt werden, eher lachhaft).
> Brauchen tut man zwei Maschinen, die IPv6, IPv4 stabil beherreschen und
> etwas RAM und CPU frei haben. Platten-IO ist unnötig.

Simmt.

>> unreachables 115089
>> answers-slow 973896
>> answers0-1 10698106
>> answers1-10 6679704
>> answers10-100 23056519
>> answers100-1000 7301384
> Das sind die Wartezeiten.

... bzw. die Anzahl an Anfragen nach aussen, die jeweils innerhalb der
angegebenen Zeit beantwortet wurden ... Mir ist klar, dass man die eher
nicht unbedingt beeinflussen kann. Ich habe nur der Einfachheit halber
den kompletten output von "rec_control get-all" in das Posting gepackt
(bevor ich mir Gedanken darueber mache, welche Werte evt. von Interesse
sein koennten ...).

> Die kannst Du wenig beeinflussen, weil sie von externen Server abhängen.

Das ist mir klar. die 12 - 13 ms bezogen sich auf "qa-latency", und da
geht auch die Geschwindigkeit mit ein, mit der der cache durchsucht wird.
Wie man an manchen anderen Werten sieht, wird ein durchaus erheblicher
Anteil aus dem Cache und aus dem "packet-cache" beantwortet:

qa-latency 20233
questions 141610343
cache-entries 4327019
cache-hits 7799380
cache-misses 41091757
concurrent-queries 1
negcache-entries 102771
nsspeeds-entries 6331
packetcache-entries 460950
packetcache-hits 92719322
packetcache-misses 48890684

> Ist halt so. DNSSEC macht es nur noch langsamer,
> es sei denn Du hast einen Hack drin, der NSEC auch für andere Queries
> auswertet, dann wird es rasend schnell.

Bei der aktuellen stable-Version des pdns-recursors macht DNSEC den resolver
nicht langsamer, weil der resolver keine DNSSEC-Validierung beherrscht (und
damit natuerlich auch nicht durchfuehrt).

>> Aktuell antwortet er also im Schnitt innerhalb von 12-13 ms auf eine Anfrage,

Der Wert schwannkt immer mal wieder leicht, aktuell liegt er mal wieder
bei ca. 20 ms (wie man dort oben sieht). Es haengt eben zu einem nicht
unerheblichen Teil auch von den Antworten ab, die nicht im Cache liegen
und daher erst durch Anfragen nach aussen ermittelt werden muessen ...

[Florian Weimer]

* Juergen Ilse:

> ... aber nicht mir dem von ihm eingeplanten pdns-recursor, denn DNSSEC-
> Validierung ist bei dem IIRC noch nicht eingebaut (soll aber bald kommen).
> Wenn der Client aber validieren will: der pdns-recursor unterstuetzt alle
> fuer DNSSEC benoetigten Record-Typen, nur ist eben noch nicht eingebaut,
> dass er bereits selbst validiert.

DNSSEC ist mehr als nur ein paar obskure RR-Typen. Meines Wissens kann
man hinter einem PowerDNS Recursor derzeit überhaupt nicht validieren.

[Florian Weimer]

* Martin Hotze:

>> Wenn Du viele UNIX-artige Clients hast, mußt Du eventuell Failover auf
>> Netzebene machen, weil die Clients das nicht selbst hinbekommen.
>
> die Server sind 99% Linux, die Kunden sind idR Windows, bissi Apple,
> noch weniger Linux.

Dann kommst Du vermutlich ohne Failover auf Netzebene aus.

>> 1 GB sollte locker reichen, wenn die Kundschaft halbwegs homogen ist.
>
> naja, die sind zwar geografisch ziemlich geballt, aber von der Nutzung
> her querbeet.

Solange es Leute aus dem deutschen Kulturkreis sind, ist es homogen.

> Es sollte nicht nur locker reichen damit es eben funktioniert
> sondern ich möchte quasi "most bang for the bucks" oder: DNS
> resolving soll auch _schnell_ sein. So schnell wie mit sinnvollen
> und einfachen Mitteln machbar ist.

Das ist in erster Linie eine Software-Frage. Unbound implementiert
z.B. Prefetching von Datensätzen, die bald ablaufen. Das hilft ein
bißchen.

> Lieber eine Standalone Atomkiste mit 4GB Ram dediziert und nur für DNS
> hinstellen oder ein anderer Server mit 2x Xeon und 40GB RAM der schon
> Web oder Mail macht da noch DNS mitmachen?

Zwei 64-Bit-Dual-Core-Atoms mit 4 GB sollten ausreichen. Ich würde
aber eher die günstigen Single-Socket-Xeon-Systeme mit ECC-RAM nehmen
(Xeon E3-1220 wäre ein Kandidat), oder etwas vergleichbares von AMD.

[Juergen Ilse]

Hallo,

Der pdns_recursor kann nicht selbst validieren, aber ich wuesste jetzt
keinen Grund, warum man hinter einem pdns_recursor (sprich mit einem
validierenden resolver mit einem pdns_recursor als forwarder) nicht
validieren koennen sollte. Kannst du das evt. mal erlaeutern?

[Florian Weimer]

* Juergen Ilse:

>> DNSSEC ist mehr als nur ein paar obskure RR-Typen. Meines Wissens kann
>> man hinter einem PowerDNS Recursor derzeit überhaupt nicht validieren.
>
> Der pdns_recursor kann nicht selbst validieren, aber ich wuesste jetzt
> keinen Grund, warum man hinter einem pdns_recursor (sprich mit einem
> validierenden resolver mit einem pdns_recursor als forwarder) nicht
> validieren koennen sollte. Kannst du das evt. mal erlaeutern?

pdns_recursor sendet selbst keine Anfragen mit DO=1, d.h. der Server
bekommt die DNSSEC-Metadaten gar nicht zu Gesicht und kann sie deshalb
auch nicht an Clients ausliefern. Die Sonderlocke für QTYPE=DS ist
auch nicht implementiert.

[Martin Hotze]

Am 09.02.2012 11:19, schrieb Florian Weimer:
> * Martin Hotze:

>> Lieber eine Standalone Atomkiste mit 4GB Ram dediziert und nur für DNS
>> hinstellen oder ein anderer Server mit 2x Xeon und 40GB RAM der schon
>> Web oder Mail macht da noch DNS mitmachen?
>
> Zwei 64-Bit-Dual-Core-Atoms mit 4 GB sollten ausreichen. Ich würde
> aber eher die günstigen Single-Socket-Xeon-Systeme mit ECC-RAM nehmen
> (Xeon E3-1220 wäre ein Kandidat), oder etwas vergleichbares von AMD.

und von den HDDs her gleich SSD? wobei das ja eigentlich nicht so
wichtig wäre, IMveryHO.

tnx, #m

[Carsten Krueger]

Am Thu, 09 Feb 2012 16:55:14 +0100 schrieb Martin Hotze:

> und von den HDDs her gleich SSD?

Willst du mit Gewalt Geld zum Fenster rausschmeißen?

> wobei das ja eigentlich nicht so wichtig wäre, IMveryHO.

Das ist wohl die Untertreibung des Jahres.

Gruß Carsten
--
ID = 0x2BFBF5D8 FP = 53CA 1609 B00A D2DB A066 314C 6493 69AB 2BFB F5D8
http://www.realname-diskussion.info - Realnames sind keine Pflicht
http://www.spamgourmet.com/ + http://mailcatch.com/ - Antispam
cakruege (at) gmail (dot) com

[Burkhard Ott]

On Thu, 09 Feb 2012 18:20:37 +0100, Carsten Krueger wrote:

> Am Thu, 09 Feb 2012 16:55:14 +0100 schrieb Martin Hotze:
>
>> und von den HDDs her gleich SSD?
>
> Willst du mit Gewalt Geld zum Fenster rausschmeißen?

Vielleicht hat er Aktien diverser Hersteller, dann wuerde ich das meinem
Chef auch einreden.

cheers

[Martin Hotze]

Am 09.02.2012 18:20, schrieb Carsten Krueger:
> Am Thu, 09 Feb 2012 16:55:14 +0100 schrieb Martin Hotze:
>
>> und von den HDDs her gleich SSD?
>
> Willst du mit Gewalt Geld zum Fenster rausschmeißen?

da im konreten Fall die Plattengröße keine Rolle spielt auf die Schnelle
ein Blick zu thomaskrenn:

1 x 80 GB SATA II Intel SSD MLC 2,5“ (320 Serie) .. 154,30 netto
1 x Stk. 250 GB SATA II WD Raid Edition IV 3,5" ... 105,30 netto

OK, die SSD ist 50% teurer und ein Drittel kleiner als die WD SATA HDD,
aber in Zahlen noch immer erträglich. Und _wenn_ es _ausreichend_ mehr
an Performance bringt, dann wäre es ja OK.

[Carsten Krueger]

Am Thu, 09 Feb 2012 18:42:34 +0100 schrieb Martin Hotze:

> Und _wenn_ es _ausreichend_ mehr
> an Performance bringt, dann wäre es ja OK.

Wofür außer zum Booten und zum Logfile Schreiben soll ein DNS-Server seine
Platte benutzen?

Selbst wenn du einen authoritative dns server aufsetzt sollte das Zonefile
immer in den RAM passen.

[Juergen Ilse]

Hallo,

Martin Hotze <local...@gmx.at> wrote:
> Am 09.02.2012 18:20, schrieb Carsten Krueger:
>> Am Thu, 09 Feb 2012 16:55:14 +0100 schrieb Martin Hotze:
>>> und von den HDDs her gleich SSD?
>> Willst du mit Gewalt Geld zum Fenster rausschmeißen?
> da im konreten Fall die Plattengröße keine Rolle spielt auf die Schnelle
> ein Blick zu thomaskrenn:
>

> 1 x 80 GB SATA II Intel SSD MLC 2,5??? (320 Serie) .. 154,30 netto

> 1 x Stk. 250 GB SATA II WD Raid Edition IV 3,5" ... 105,30 netto
>
> OK, die SSD ist 50% teurer und ein Drittel kleiner als die WD SATA HDD,
> aber in Zahlen noch immer erträglich. Und _wenn_ es _ausreichend_ mehr
> an Performance bringt, dann wäre es ja OK.

Woher soll denn das "ausreichend mehr an Performance" kommen, wenn
nach dem hochlaufen aller relevanten Prozesse ausser ggfs. Logfile-
Zugriffen (die ich evt. dann doch lieber auf einer Platte statt auf
einer SSD haette) kaum noch Plattenzugriffe stattfinden?

[Sven Hartge]

Carsten Krueger <cakr...@gmail.com> wrote:
> Am Thu, 09 Feb 2012 18:42:34 +0100 schrieb Martin Hotze:

>> Und _wenn_ es _ausreichend_ mehr
>> an Performance bringt, dann wäre es ja OK.

> Wofür außer zum Booten und zum Logfile Schreiben soll ein DNS-Server
> seine Platte benutzen?

> Selbst wenn du einen authoritative dns server aufsetzt sollte das
> Zonefile immer in den RAM passen.

Hier mal die Daten von einem BIND9 Resolver inkl. authorative Domains
meiner Hochschule, der ca. 4000 Clients im LAN bedient.

(Bevor jemand schreit: Die authorativen DNS für externe Anfragen sind
_keine_ rekursiven Resolver, nur bei den internen Resolvern haben wir
die Zonen auch mit drauf, dann müssen diese bei Anfragen nicht immer zu
den authorativen DNS für die Zonen laufen sondern haben die Daten direkt
da.)

19:47:43 up 8 days, 31 min, 1 user, load average: 0.00, 0.00, 0.00

total used free shared buffers cached
Mem: 1034348 957728 76620 0 163328 633100
-/+ buffers/cache: 161300 873048
Swap: 546200 716 545484

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1113 bind 20 0 138m 94m 2768 S 0 9.3 143:03.44 named

Wie man sieht: Die Kiste (eigentlich eine VM) langweilt sich total, die
143 Minuten CPU-Zeit über 8 Tage Uptime beim named kommen nur von der
derzeit suboptimalen Zonen-Update-Strategie.

Von wievielen Usern/PCs redest du denn Martin, die deinen Resolver
benutzen werden? Weil viel CPU und RAM braucht sowas nicht wirklich, I/O
auf Platte schon gar nicht. Da könnte man fast einen USB-Stick als
Medium im Server für benutzen.

S°

--
Sigmentation fault. Core dumped.

[Gert Doering]

Martin Hotze <local...@gmx.at> writes:

>OK, die SSD ist 50% teurer und ein Drittel kleiner als die WD SATA HDD,
>aber in Zahlen noch immer erträglich. Und _wenn_ es _ausreichend_ mehr
>an Performance bringt, dann wäre es ja OK.

Wenn Dein *caching Nameserver* im normalen Betrieb irgendwas von der
Platte braucht, braucht er mehr RAM - auf die Platte gehört maximal
das Logfile, und das geht auch mit 'ner lahmen Platte... :-)

gert
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany ge...@greenie.muc.de
fax: +49-89-35655025 ge...@net.informatik.tu-muenchen.de

[Florian Weimer]

* Carsten Krueger:

> Am Thu, 09 Feb 2012 16:55:14 +0100 schrieb Martin Hotze:
>
>> und von den HDDs her gleich SSD?
>
> Willst du mit Gewalt Geld zum Fenster rausschmeißen?

Kleine SSDs sind derzeit billiger als Festplatten. 70-mm-SATA-Platten
für den Einsatz rund um die Uhr gibt es meines Wissens überhaupt
nicht.

Wenn ich den Verkehr nicht aufzeichnen soll, würde ich infolgedessen
derzeit SSDs nehmen (mit RAID-1).

[Carsten Krueger]

Am Thu, 09 Feb 2012 22:47:28 +0100 schrieb Florian Weimer:

> Kleine SSDs sind derzeit billiger als Festplatten.

Meiner privaten Erfahrung sind sie leider deutlich unzuverlässiger als
Platten.

> 70-mm-SATA-Platten für den Einsatz rund um die Uhr gibt es meines Wissens überhaupt
> nicht.

Wozu sollte man 70-mm benötigen?

[Florian Weimer]

* Carsten Krueger:

> Am Thu, 09 Feb 2012 22:47:28 +0100 schrieb Florian Weimer:
>
>> Kleine SSDs sind derzeit billiger als Festplatten.
>
> Meiner privaten Erfahrung sind sie leider deutlich unzuverlässiger als
> Platten.

Intel 320 sah im Dauerschreibtest gar nicht so schlecht aus. Nicht daß
das hier die Anwendung wäre.

Zu SSD-Defektraten kann ich mangels Masse nichts sagen. Viel schlimmer
als bei Festplatten kann's aber eigentlich nicht sein.

>> 70-mm-SATA-Platten für den Einsatz rund um die Uhr gibt es meines
>> Wissens überhaupt nicht.
>
> Wozu sollte man 70-mm benötigen?

Es gibt bestimmte hochdichte Gehäuse, die solche Platten benötigen
(und kein SAS unterstützen).

[Carsten Krueger]

Am Fri, 10 Feb 2012 15:56:48 +0100 schrieb Florian Weimer:

> Intel 320 sah im Dauerschreibtest gar nicht so schlecht aus.

Das ist auch nicht das Problem.
Jeder Powercycle hat halt ne Gefahr, dass die SSD von jetzt auf gleich
nicht mehr erkannt wird.
Google mal nach: "<ssd name> not detected" oder "<ssd name> died" oder
"<ssd name> panic mode".
Oder speziell bei der Intel 320 nach: 8 MB Bug

Bei der Intel hast du reelle Chancen alle Daten zu verlieren wenn du ein
ATA-Passwort gesetzt hast. Das ist ein Knownbug bei der aktuellen Firmware
...

> Zu SSD-Defektraten kann ich mangels Masse nichts sagen. Viel schlimmer
> als bei Festplatten kann's aber eigentlich nicht sein.

Mein Haus und Hof Händler murmelte was von 5% innerhalb eines Jahres bei
einem bestimmten Hersteller.

> Es gibt bestimmte hochdichte Gehäuse, die solche Platten benötigen
> (und kein SAS unterstützen).

Ok, ich dachte wir waren bei DNS-Servern ;-)

[Marc Haber]

Martin Hotze <local...@gmx.at> wrote:
>gesucht:
>neues und passend(!) performantes Setup für DNS resolver.
>

>geplant:
>2 (physikalisch) getrennte Maschinen mit pdns_recurser
>

>Überlegungen mit der Bitte um Input/Feedback:

>- 2x direkt auf Blech oder würdet ihr virtualisieren (warum?)

>- lieber zuviel RAM oder habt ihr eine Faustformel?

Wenn Du vorher messen magst, binde mal zwei pdns_recursor-Instanzen
desselben Systems auf zwei IP-Adressen und schau nach, wie sich die
Performance von zwei parallelen Tests (einer auf eine, der andere auf
die andere IP-Adresse) gegenüber einem Test auf eine IP-Adresse
verhält.

Mit dem autoritativen pdns-Server erreicht man so eine sehr viel
höhere Skalierung; es gibt da wohl die eine oder andere
Herausforderung mit dem Threading unter Linux.

Grüße
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834