Hallo Leute.
Ich habe hier einen Backup-Server W2K3 R2 mit folgender Hardware:
- Supermicro X8SIL-F mit Intel Xeon X3440 CPU
- 4GB ECC reg. RAM
- 1x 80GB WD SATA Systemplatte (WD)
- 1x 320GB Maxtor SATA HD für temp. Zeugs
- 3x 1,5TB WD15EADS SATA HD intern für's Backup
- 1x 1,5TB WD15EADS SATA HD zum täglichen Wechsel in Wechselrahmen
- alle Platten hängen am internen Intel-Controller (ESB2) im AHCI-Modus
Über Nacht sichern unsere Server ihre Daten auf eine der drei 1,5TB Platten (je nach Woche). Sobald sie damit fertig sind, wird diese Platte am Tag komplett auf die vierte 1,5TB Platte kopiert (nennen wir es "Wechselbackup") und diese wird dann täglich gewechselt. Soweit die Theorie.
Praktisch habe ich ein Performance Problem und suche derzeit verzweifelt nach der Ursache .
Das Problem:
- wenn ich während des Wechselbackup, was ja "nur" ein schnöder Kopiervorgang ist, von einem anderen Rechner im Netz Daten auf eine andere (unbelastete) Platte auf dem Backup-Server kopiere, dann kommt das Wechselbackup fast vollkommen zum Stillstand (0-3 MB/s) und erst wenn der Kopiervorgang über's Netz abgeschlossen ist geht es mit dem lokalen kopieren weiter (ca. 50-70 MB/s).
Netzwerk-Traffic und lokale Festplattenzugriffe scheinen sich gegenseitig nicht besonders zu mögen. Ich habe auch verschiedene Intel Matrix Storage Treiber versucht, da ich mit der mitgelieferten Version 8.9.1023 so meine liebe Not mit angeblich und sporadisch fehlerhaften Platten hatte. Ich bin jetzt wieder auf V8.8.1009 und bin wenigstens diese Probleme wieder los. Ich habe außerdem neue Intel-Chipsatz-Treiber (V9.1.1.1013) und Netzwerktreiber (V11.1.6.0) direkt von der Intel-Seite geladen, aber auch diese brachten keine Verbesserung . Den Modi des OnBoard SATA Controllers habe ich bereits mit Modus IDE, Intel AHCI und Intel RAID ausprobiert, jeweils auch ohne signifikante Veränderung - wobei der Datendurchsatz im einfachen IDE-Modus generell stabiler, aber dafür deutlich langsamer ist.
Ich habe nun testweise einen Promise Fasttrak TX4 SATA Controller eingebaut und die eine 1,5TB Wechselplatte dort angeschlossen. Ändern tut's leider nix
- gleiches Problem weiterhin.
Außerdem habe ich einen weiteren Test gemacht, wonach ich auch nicht mehr dran glaube dass der onBoard Controller so "schlecht" ist. Ich habe das System mit einer Ubuntu 9.10 Live-CD gestartet und dann die Kopiervorgänge zum Laufen gebracht. Per SMB habe ich von 2 verschiedenen Servern gleichzeitig auf je eine der 1,5TB Platten kopiert und gleichzeitig die 3. 1,5TB HD lokal auf die 4. 1,5TB kopiert. Ergebniss: Gigabit LAN war voll ausgelastet (2x ca. 45 MB/s) und lokal lief der Kopiervorgang zur gleichen Zeit ebenfalls mit ca. 60 MB/s. Genauso soll es sein - aber eben nicht nur unter Linux, sondern unter Windows . Einziger gravierender Unterschied: Unter Linux ist die CPU seeehr beschäftig (60-70%), unter Windows fast gar nicht. Ich denke unter Linux wird der Controller mit einer Art generischem Treiber angesteuert wobei der unter Windows Intel-spezifisch ist. Übernimmt hier unter Linux die CPU die Arbeit die unter Windows der "Raid-Controller" macht? Keine Ahnung, aber es funktioniert auf jeden Fall.
Als dritten Versuch habe ich kurzerhand einen W2k8 R2 Server aufgesetzt. Dort wird der Intel Controller im AHCI Modus nativ erkannt - ich brauche also erstmal keine Intel-Treiber von irgendeiner Treiber-CD. Problem besteht aber wieder genauso wie unter W2k3 R2 Server
Wenn es Sinn macht (d.h. es dann sicher funktioniert) würde ich auch einen echten Raid-Controller einbauen (z.B. Adaptec Raid 3405), aber ich bin mir nicht sicher ob es überhaupt etwas bewirken wird. Ich möchte ja auch gar kein Raid, sondern nur lokal kopieren und Netzwerkverkehr auf eine andere Platte gleichzeitig abwickeln können
.
OK, ich glaube jetzt reicht's erstmal mit Infos. Wenn ich das jetzt nochmal so lese klingt es eher so als hätte ich mich mal richtig "ausgek*tzt"
. Also falls noch wichtige Infos fehlen, fragt einfach 
.
PS: Wenn jemand noch eine anderen Link für Supermicro Treiber kennt, als die ständig überlastete Supermicro FTP-Seite, dann wäre ich dafür auch sehr dankbar.
Ich hänge mal noch das Block-Diagramm vom Mainboard an. Evtl. kann damit ja jemand was anfangen.
Ich habe hier einen Backup-Server W2K3 R2 mit folgender Hardware:
- Supermicro X8SIL-F mit Intel Xeon X3440 CPU
- 4GB ECC reg. RAM
- 1x 80GB WD SATA Systemplatte (WD)
- 1x 320GB Maxtor SATA HD für temp. Zeugs
- 3x 1,5TB WD15EADS SATA HD intern für's Backup
- 1x 1,5TB WD15EADS SATA HD zum täglichen Wechsel in Wechselrahmen
- alle Platten hängen am internen Intel-Controller (ESB2) im AHCI-Modus
Über Nacht sichern unsere Server ihre Daten auf eine der drei 1,5TB Platten (je nach Woche). Sobald sie damit fertig sind, wird diese Platte am Tag komplett auf die vierte 1,5TB Platte kopiert (nennen wir es "Wechselbackup") und diese wird dann täglich gewechselt. Soweit die Theorie.
Praktisch habe ich ein Performance Problem und suche derzeit verzweifelt nach der Ursache .
Das Problem:
- wenn ich während des Wechselbackup, was ja "nur" ein schnöder Kopiervorgang ist, von einem anderen Rechner im Netz Daten auf eine andere (unbelastete) Platte auf dem Backup-Server kopiere, dann kommt das Wechselbackup fast vollkommen zum Stillstand (0-3 MB/s) und erst wenn der Kopiervorgang über's Netz abgeschlossen ist geht es mit dem lokalen kopieren weiter (ca. 50-70 MB/s).
Netzwerk-Traffic und lokale Festplattenzugriffe scheinen sich gegenseitig nicht besonders zu mögen. Ich habe auch verschiedene Intel Matrix Storage Treiber versucht, da ich mit der mitgelieferten Version 8.9.1023 so meine liebe Not mit angeblich und sporadisch fehlerhaften Platten hatte. Ich bin jetzt wieder auf V8.8.1009 und bin wenigstens diese Probleme wieder los. Ich habe außerdem neue Intel-Chipsatz-Treiber (V9.1.1.1013) und Netzwerktreiber (V11.1.6.0) direkt von der Intel-Seite geladen, aber auch diese brachten keine Verbesserung . Den Modi des OnBoard SATA Controllers habe ich bereits mit Modus IDE, Intel AHCI und Intel RAID ausprobiert, jeweils auch ohne signifikante Veränderung - wobei der Datendurchsatz im einfachen IDE-Modus generell stabiler, aber dafür deutlich langsamer ist.
Ich habe nun testweise einen Promise Fasttrak TX4 SATA Controller eingebaut und die eine 1,5TB Wechselplatte dort angeschlossen. Ändern tut's leider nix
- gleiches Problem weiterhin.Außerdem habe ich einen weiteren Test gemacht, wonach ich auch nicht mehr dran glaube dass der onBoard Controller so "schlecht" ist. Ich habe das System mit einer Ubuntu 9.10 Live-CD gestartet und dann die Kopiervorgänge zum Laufen gebracht. Per SMB habe ich von 2 verschiedenen Servern gleichzeitig auf je eine der 1,5TB Platten kopiert und gleichzeitig die 3. 1,5TB HD lokal auf die 4. 1,5TB kopiert. Ergebniss: Gigabit LAN war voll ausgelastet (2x ca. 45 MB/s) und lokal lief der Kopiervorgang zur gleichen Zeit ebenfalls mit ca. 60 MB/s. Genauso soll es sein - aber eben nicht nur unter Linux, sondern unter Windows . Einziger gravierender Unterschied: Unter Linux ist die CPU seeehr beschäftig (60-70%), unter Windows fast gar nicht. Ich denke unter Linux wird der Controller mit einer Art generischem Treiber angesteuert wobei der unter Windows Intel-spezifisch ist. Übernimmt hier unter Linux die CPU die Arbeit die unter Windows der "Raid-Controller" macht? Keine Ahnung, aber es funktioniert auf jeden Fall.
Als dritten Versuch habe ich kurzerhand einen W2k8 R2 Server aufgesetzt. Dort wird der Intel Controller im AHCI Modus nativ erkannt - ich brauche also erstmal keine Intel-Treiber von irgendeiner Treiber-CD. Problem besteht aber wieder genauso wie unter W2k3 R2 Server
Wenn es Sinn macht (d.h. es dann sicher funktioniert) würde ich auch einen echten Raid-Controller einbauen (z.B. Adaptec Raid 3405), aber ich bin mir nicht sicher ob es überhaupt etwas bewirken wird. Ich möchte ja auch gar kein Raid, sondern nur lokal kopieren und Netzwerkverkehr auf eine andere Platte gleichzeitig abwickeln können
.OK, ich glaube jetzt reicht's erstmal mit Infos. Wenn ich das jetzt nochmal so lese klingt es eher so als hätte ich mich mal richtig "ausgek*tzt"
. Also falls noch wichtige Infos fehlen, fragt einfach .PS: Wenn jemand noch eine anderen Link für Supermicro Treiber kennt, als die ständig überlastete Supermicro FTP-Seite, dann wäre ich dafür auch sehr dankbar.
Ergänzung ()
Ich hänge mal noch das Block-Diagramm vom Mainboard an. Evtl. kann damit ja jemand was anfangen.
