Univention Bugzilla – Bug 26312
Performance Bind mit Samba4-Backend verbessern
Last modified: 2012-12-12 21:09:31 CET
Der Betrieb von BIND mit Samba4-Backend generiert bei frequentierten DNS-Servern eine relativ hohe CPU und IO-Last. Beispiel: Ein Web-Proxy mit ca. 200-300 aktiven Usern führt zu einer Load von ca. 0.8 auf einer ESX-VM mit zwei CPU-Kernen und 2 GB RAM (Serverhardware aus 2011), die CPU-Auslastung von Samba liegt bei 30-60%, die von BIND bei 10-20%. Das Backend kann in solchen Szenarien auf das LDAP-Backend geändert werden (unter Verlust der DDNS-Funktionalität), eine Performance-Optimierung ist aber wünschenswert.
Das sollten wir zur 3.0-2 nochmal prüfen, ggf. wird es eine Anpassung aber erst zu UCS 3.1 geben können.
Wir warten hier das nächste Samba Update ab. Falls das ein echtes Problem ist, kann das LDAP Backend für DNS verwendet werden. Die DDNS Funktionalität müsste dann anderes implementiert werden, beispielsweise kann direkt der DHCP Server die Änderungen ins LDAP schreiben. Weitere Tests mit 3.1, nach dem S4 Update.
Es ist im Samba 4 DNS Backend by design so, dass jede DNS Anfrage direkt im LDAP gesucht wird. Grundsätzlich ist die Performance mit der RC2 Version besser, aber für eine größere Umgebung noch nicht ausreichend. Für eine größere Umgebung sollte das OpenLDAP Backend verwendet werden, da dort per DNS Zonentransfer die Daten nur bei Änderungen im LDAP abgefragt werden. Da die Daten zwischen OpenLDAP und Samba 4 synchronisiert werden, ist dies auch transparent. Alternativ kann auch ein manueller DNS Proxy eingerichtet werden. Einzig die Aktualisierung der Windows Client IP Adressen per Kerberos signiertem DNS Update funktioniert dann nicht. Dafür gibt es Bug #301.
Ok, viel anderes kann man da denke ich auch nicht machen. Ich hatte beim Patch des dns_bind9 samba4-Moduls auch ein bissschen auf Performace geschaut und da nur kleinere Punkte gefunden/mit behoben, wo ich gerade sowieso dran musste.
UCS 3.1-0 has been released: http://forum.univention.de/viewtopic.php?f=54&t=2125 If this error occurs again, please use "Clone This Bug".