SAMBA4 DNS Performance Probleme

UCS - Univention Corporate Server
#1

Hallo,

ich hatte euch schon desöfteren Berichtet, dass wir nach dem Updaten von bestimmten Kunden nicht mehr den bind9 in Kombination von Samba4 verwenden können, da wir ewig lange Antwortzeiten erhalten.

Ich habe das ganze nun auf einem Testsystem reproduzieren können.

1.) Man setzt ein Testsystem mit UCS3.0.2 und Samba4 auf.
2.) Man startet folgendes Skript:

[code]
eval ucr shell

function randpass() {
CHAR=“a-z”
cat /dev/urandom | tr -cd “$CHAR” | head -c ${1:-32}
}
function getReverseZoneName {

    ip="$1"

    subnet=""
    if [ "`echo $ip | cut -d "." -f 1`" != "" ]; then
            subnet="`echo $ip | cut -d "." -f 1`"
    fi
    if [ "`echo $ip | cut -d "." -f 2`" != "" ]; then
            subnet="`echo $ip | cut -d "." -f 2`.$subnet"
    fi
    if [ "`echo $ip | cut -d "." -f 3`" != "" ]; then
            subnet="`echo $ip | cut -d "." -f 3`.$subnet"
    fi
    if [ "`echo $ip | cut -d "." -f 4`" != "" ]; then
            subnet="`echo $ip | cut -d "." -f 4`.$subnet"
    fi

    echo -n "$subnet.in-addr.arpa"

}

function addUser {
username="$1"
lastname="$2"
password="$3"

    udm users/user create --position="cn=users,$ldap_base" --set username=$username --set lastname=$lastname --set password=$password

}

function removeUser {
username="$1"

    udm users/user remove --dn="uid=$username,cn=users,$ldap_base"

}

function addGroup {
name="$1"

    udm groups/group create --position="cn=groups,$ldap_base" --set name=$name

}

function removeGroup {
name="$1"

    udm groups/group remove --dn="cn=$name,cn=groups,$ldap_base"

}

function addForwardZone {
dnsName="$1"

    udm dns/forward_zone create --position="cn=dns,$ldap_base" --set zone=$dnsName --set nameserver="$hostname.$domainname."

}
function removeForwardZone {
dnsZone="$1"

    udm dns/forward_zone remove --dn="zoneName=$dnsZone,cn=dns,$ldap_base"

}

function addReverseZone {
ip="$1"

    udm dns/reverse_zone create --position="cn=dns,$ldap_base" --set subnet=$ip --set nameserver="$hostname.$domainname."

}

function removeReverseZone {
ip="$1"

    udm dns/reverse_zone remove --dn="zoneName=`getReverseZoneName $ip`,cn=dns,$ldap_base"

}

function addHostRecord {
dnsZone="$1"
host="$2"
ip="$3"

    udm dns/host_record create --superordinate="zoneName=$dnsZone,cn=dns,$ldap_base" --set name=$host --set a=$ip

}

function addPtrRecord {
zoneIp="$1"
ip="$2"
host="$3"

    udm dns/ptr_record create --superordinate="zoneName=`getReverseZoneName $zoneIp`,cn=dns,$ldap_base" --set address=$ip --set ptr_record=$host

}

function removeHostRecord {
dnsZone="$1"
host="$2"

    udm dns/host_record remove  --superordinate="zoneName=$dnsZone,cn=dns,$ldap_base" --dn="relativeDomainName=$host,zoneName=$dnsZone,cn=dns,$ldap_base"

}

function removePtrRecord {
zoneIp="$1"
ip="$2"

    udm dns/ptr_record remove --dn="relativeDomainName=$ip,zoneName=`getReverseZoneName $zoneIp`,cn=dns,$ldap_base" --superordinate="zoneName=`getReverseZoneName $zoneIp`,cn=dns,$ldap_base"

}

forward_zones=“firstzone.local,tom.local,office.local,vienna.local,secret.local,phone.local,switch.local,servers.local,calc.local,manyzones.local,krems.local,city.local,ucs.local,vm.local,link.local”
reverse_zones=“192.168.100,192.168.101,192.168.102,192.168.103,192.168.104,192.168.105,192.168.106,192.168.107,192.168.108,192.168.109,192.168.110,192.168.111,192.168.112,192.168.113,192.168.114”

for i in {1…15}
do
addForwardZone “echo $forward_zones | cut -d "," -f $i” “$hostame.$domainname”
done

for i in {1…15}
do
addReverseZone “echo $reverse_zones | cut -d "," -f $i” “$hostame.$domainname”
done

while [ true ]; do

    username="`randpass 15`"
    addUser "$username" "$username" "MeinPW12345"
    if [ "`echo $(($RANDOM%15))`" != "10" ]; then
            removeUser "$username"
    fi

    group="`randpass 15`"
    addGroup "$group"
    if [ "`echo $(($RANDOM%15))`" != "10" ]; then
            removeGroup "$group"
    fi

    a="`echo $(($RANDOM%14+1))`"
    b="`echo $(($RANDOM%14+1))`"
    forward="`echo $forward_zones | cut -d "," -f $a `"
    reverse="`echo $reverse_zones | cut -d "," -f $b `"

    hostc="`randpass 15`"
    ptr="`echo $(($RANDOM%253+1))`"

    addHostRecord "$forward" "$hostc" "$reverse.$ptr"
    addPtrRecord "$reverse" "$ptr" "$hostc.$forward."

    if [ "`echo $(($RANDOM%15))`" != "10" ]; then
            removeHostRecord "$forward" "$hostc"
    fi

    if [ "`echo $(($RANDOM%15))`" != "10" ]; then
            removePtrRecord "$reverse" "$ptr"
    fi

done[/code]
Dieses Skript erstellt in einer Schleife Benutzer / Gruppen / DNS Einträge, und löscht diese auch teilweiße wieder.
Man lässt dieses Skript so lange laufen, bis der uSNChanged / uSNCreated bei etwa ~80000 liegt (waren bei mir rund 4 Stunden, war aber ein langsames System ;)).
Dann bricht man das Skript ab, und wartet, bis der s4-connector alles ins AD gesynct hat.

DNS funktioniert nun noch korrekt. Jetzt startet man das Update auf 3.1. Nach dem Update Rechner neu starten, und nun funktioniert der DNS mit bind nur mehr sehr langsam!
Der startup vom bind dauert schon rund 25 Sekunden bei 20 Zonen!

DNS Abfrage (nach startup vom bind):

[code]root@dnstest:~# dig xcmcctbghqnksnw.krems.local @192.168.1.22

; <<>> DiG 9.8.0-P4 <<>> xcmcctbghqnksnw.krems.local @192.168.1.22
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36114
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1

;; QUESTION SECTION:
;xcmcctbghqnksnw.krems.local. IN A

;; ANSWER SECTION:
xcmcctbghqnksnw.krems.local. 900 IN A 192.168.101.45

;; AUTHORITY SECTION:
krems.local. 900 IN NS dnstest.dns.local.

;; ADDITIONAL SECTION:
dnstest.dns.local. 900 IN A 192.168.1.22

;; Query time: 1626 msec
;; SERVER: 192.168.1.22#53(192.168.1.22)
;; WHEN: Thu Jan 10 11:42:58 2013
;; MSG SIZE rcvd: 103[/code]
1600ms!

Stoppe ich nun den bind, und setze samba4 als dns server:

server services = +dns -smb +s3fs -nbtd

So erhalte ich Antwortzeiten von 0-1ms!

[code]root@dnstest:~# dig xcmcctbghqnksnw.krems.local @192.168.1.22

; <<>> DiG 9.8.0-P4 <<>> xcmcctbghqnksnw.krems.local @192.168.1.22
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33184
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;xcmcctbghqnksnw.krems.local. IN A

;; ANSWER SECTION:
xcmcctbghqnksnw.krems.local. 900 IN A 192.168.101.45

;; Query time: 0 msec
;; SERVER: 192.168.1.22#53(192.168.1.22)
;; WHEN: Thu Jan 10 11:24:33 2013
;; MSG SIZE rcvd: 61[/code]

Daher stellt sich nun die Frage, warum reagiert bind nun so langsam!!!

Ich lade gerade das qcow2 Image auf unserem FTP Server (sollte bis 13 Uhr fertig hochgeladen sein, ist 5,9GB groß):
ftp.siedl.net/dnstest-0.qcow2
root Passwort: 12345

#2

Hallo,

vielen Dank für den Report. Ich habe hierzu [bug]29985[/bug] angelegt und die Kollegen aus der Entwicklung werden sich das im Rahmen der UCS 3.1 errata Update noch einmal anschauen.

Mit freundlichen Grüßen
Janis Meybohm

#3

Das qcow2 image ist nun komplett hochgeladen.

#4

Nach einem weiteren reboot des Servers sind die Antwortzeiten noch langsamer, nun sind es fast 5000ms!

#5

Danke für die umfangreiche Beschreibung und Bereitstellung der Daten.

Wir konnten das Problem mit den Daten mittlerweile reproduzieren und arbeiten derzeit an einer Lösung.

Viele Grüße
Stefan Gohmann

#6

Hallo,

wir haben soeben ein Errata Update veröffentlicht dass die Performance bei DNS Abfragen verbessern sollte.

Mit freundlichen Grüßen
Janis Meybohm

#7

Guten Morgen,

habe eben 3 Samba4 Systeme bei einem Kunden geupdatet, DNS funktioniert nun wesentlich besser :slight_smile:

Danke!

Mastodon