Re: [SCSI] Battery Backup Unit
- From: Thomas Wildgruber <ng@xxxxxxxxxx>
- Date: Tue, 6 Dec 2005 20:06:38 +0100
Hallo Ingo,
On Tue, 6 Dec 2005 18:24:16 +0100, Ingo Böttcher wrote:
>> antworten. Aber gerne gebe ich dir Auskunft über die Gedanken bezgl. des
>> Sizings, welche wir uns gemacht haben -> speziell Exchange in diesem Fall,
>> ist aber so ziemlich auf alle DB's übertragbar. Gehts um
>> Performanceprobleme in Verbindung mit einem Exchange? In welcher Form
>> sollen die Benchmarks sein?
>
> Folgendes: ich habe hier einen Server mit dem LSI Controller in der Intel
> OEM Version als Zweikanal Variante. Daran hängen sechs 146er Seagate als
> ein RAID5 mit einer Hotspare Platte.
>
> Wenn ich mit HD-Tune (http://www.hdtune.com/) einen reinen Lese-Benchmark
> mache, komme ich auf maximale Werte von etwa 45 MB/s. Das ist etwas mehr
> als die Hälfte von dem, was andere Maschinen hier machen, die allesamt mit
> ICP Vortex Controllern ausgerüstet sind.
Okay, das erste was mir bei Raidcontrollern mit Raid 5 einfällt ist XOR in
Hardware -> Ja oder Nein. Wenn er das nicht kann, kannst du ihn - oder dein
Raid 5 - gleich abschreiben. Das betrifft jetzt aber das Schreiben auf das
Raid, Lesezugriffe sind davon erstmal nicht betroffen.
Der Standard deiner SCSI Geräte ist U320? Einen Benchmark kann ich dir nur
in einem Raid 10 Setup mit vier HD's liefern. Der verwendete Controller ist
ein LSI U320-1 (die Einkanal Variante), die HD's sind ebenfalls 146er
(Marke weis ich jetzt nicht, muss ich morgen schauen)
Was mir bei den LSI Controllern aufgefallen ist, die haben ab einem
Firmwarerelease (ich glaube ab dem vorletzten) die Default Stripesize auf
2KB gesetzt, wir haben aber alles auf 64KB konfiguriert. Ob das jetzt aber
Einfluss auch in der Leseperformance hat entzieht sich meiner Kenntniss,
sollte man aber mal berücksichtigen. Hast du das LSI-Tool installiert? Das
gibt dir Auskunft über die Konfiguration -> auch der eingestellten
Stripesize. Ich weis jetzt wirklich nicht was die mit 2KB wollen, wenn die
Clustergrösse von Windows per Default schon 4KB ist, weis wie gesagt aber
auch nicht ob das einen Einfluss auf die Gesamtperformance hat -> Ich
vermute, wenn überhaupt, auch nur beim Schreiben.
Die Cacheoptionen des Controllers haben wir hier auf dem Exchange explizit
nur auf dem Raidset (ein seperates Raid 1), auf welchem die Partition
liegt, auf welcher die Transactionlogs geschrieben werden aktiviert. D.h.
'Cached I/O' und 'Whrite back'. Auf dem Raid 10, auf welchem die EDB's
(ExchangeDatenBanken) liegen ist nur 'Write Through' und eben kein 'Cached
I/O' (ich weis jetzt nicht, wie sich die Option jetzt in der Terminologie
von LSI nennt) Anyway, ich vermute aber auch hier mehr einen Einfluss auf
die Schreibgeschwindigkeit, weniger auf das Lesen.
Ich überprüfe das mal mit dem von dir angegebenen Benchmarktool jeweils auf
dem Raid 10 und auf dem Raid 1.
> Noch eklatanter wird die ganze Geschichte, wenn ich ihn etwas quäle und
> eine 3,3 GB grosse Datei innerhalb einer Partition von einem Verzeichnis
> ins nächste kopiere. Ich erreiche dabei durchschnittlich Durchsätze von
> etwa 7,5 MB/s.
Da schreiben wir aber auch auf die Zielpartition, hier könnten o.g.
Bemerkungen durchaus zutreffen, vor allem das Schreiben der Parität bei
Raid 5 und vor allem dann, wenn der Kontroller kein XOR in Hardware macht.
Auch zu bedenken ist hierbei, dass die Schreib/Leseköpfe der involvierten
HD's gleichzeitig beides tun müss(t)en -> Lesen und Schreiben. Diesen Test
sehe ich nicht als sehr aussagekräftig an.
Ich würde vor allem auch auf ein defragmentiertes Dateisystem achten, um
sicherzustellen, dass ich meine Datei nicht kreuz und quer auf die ganze HD
verstreue. Nutzt du NTFS, mit welcher Clustergrösse? Ich habe z.B. auf
unserem BackUpServer eine Clustergrösse von AFAIK 32MB eingestellt, da nur
Dateien >500MB drauf landen. Bei kleineren Dateien, die seltener dieses
Raid (auch ein Raid 5, aber mit 15 HD's) benutzen ist dann der Verschnitt
eben dementsprechend hoch aber das ist angesichts einer Grösse von fast 2TB
eher wurscht ;-)
> Nun heisst es: ja, das wäre so langsam, weil halt die Caches der einzelnen
> Platten deaktiviert würden, weil die ja nicht von der BBU mit gepuffert
> werden würden. So weit, so schlecht.
> Ein zum Testen organisierter ICP 8524RZ+BBU zeigt aber diese Einbrüche
> nicht, auch wenn man dort den Write-Cache der Platten deaktiviert (dort
> kann man das zum Glück selber beeinflussen) und sogar weitaus langsamere
> Platten verwendet.
Was aber IMHO das Problem nach sich zieht, das ein Crash des Servers
(stromlos) unweigerlich auch Datenverlusst zur Folge hat. Die HD Caches
sind AFAIK auch schon 8MB gross und das reicht locker um eine Datenbank in
den Ruin zu treiben. Ich würde diese Option bei einem Produktivsystem
*niemals* nutzen wollen, das wollte ich hier auch nochmal abgeklärt haben.
> Die spannende Frage wäre jetzt also, ob solche miserablen Geschwindigkeiten
> in anderen Umgebungen auch auftauchen, obs ein Problem mit der Intel OEM
> Version ist oder was da auch immer schief läuft.
Ich kann dir die Tests unter o.g. Konfiguration durchführen und gebe dir
auch den genauen Typ mit Firwarerelease des LSI Kontrollers durch, weis nur
nicht ob ich es morgen schon schaffe ;-)
> Bevor ihr also auf einen Server mit dem schg§"&%§&%§" Controller migriert,
> wäre es vielleicht nicht schlecht, ihn mal mit den o.g. Tests zu quälen.
Ja jeder hat so seine Lieblinge, ich habe Adaptec komplett aus dem Haus
gebannt -> Der Support war miserabel ;-) Ich hatte o.g. BackUpRaid
hostseitig an einem Adaptec schiessmichtod U320 blafasel betrieben und
hatte miserable Werte und kam fehlerfrei nicht über U160 hinaus, sobald ich
den Controller auf 320 schaltetet brach der Server mit samt seinem Raid
ein. Adaptec verweigerte, weil die billigere Retail Variante, *jeden*
Support. Die Fehler bekam ich allerdings nur mit, weil das damals
installierte Linux auf dem Server einen äusserst geschwätzigen Bootvorgang
mit sich brachte. Ich habe *Wochen* damit zugebracht, Linux in allen
verschiedenen Distrubutionen zu installieren und immer das selbe. Windows
war dann nicht ganz so gesprächig, hatte aber zumindest *einen* Fehler im
Ereignissprotokoll. Das ganze habe ich mit samt der boot.msg an den
ThirdLevel Support des Herstellers des RaidSubSystems nach Korea (mich
schauderts jetzt noch;) eskaliert und siehe da -> Der Chipsatz des
Controllers ist mit dem Chipsatz des RaidSubSystems nicht kompatibel und
sie empfehlen daher entweder einen Downgrade des Controllers auf ein
Release zuvor oder ein Upgrade des Controllers des RaidSubSystems oder aber
die pragmatischer Lösung wäre ein Controller eines anderen Herstellers ->
Mit dem LSI Kontroller waren die Problem quasi über Nacht wie weggeblasen
und habe seitem bereits vier LSI verbaut.
> Kopiert wurde mit Total-Commander, der Lesebenchmark lief halt mit HD-Tune.
Ich teste es und hoffe nicht auch noch eine böse Überraschung zu erleben
aber ich komme beim Backup immerhin schon mal auf über 20MB Leseperformance
;-) Da spielen aber auch noch etliche andere Faktoren eine Rolle ->
Auslastung des Zielsystems, Netzwerktraffic, Grösse der zu sichernden
Dateien, schlägt der OpenFileAgent zu oder nicht usw. usf. Gebe aber zu ich
hätte mir vor allem auch von einem Raid 10 deutlich mehr erwartet, da ich
aber mit dieser Leistung und inkrementeller BackUpStrategie weit von einem
Problem mit dem Zeitfenster weg bin, juckt mich das erstmal nicht und
Datenbankserver tuned man mit anderen Methoden, da ist ein durchdachtes
Sizing mehr wert als die schnellste Hardware oder anders rum, mit einer
dämlichen Aufteilung deiner Platten machst du die schnellste Hardware zur
Schnecke ;-)
Bye Tom
--
"Ich hatte vom Feeling her ein gutes Gefühl." (Andy Möller)
.
- References:
- [SCSI] Battery Backup Unit
- From: Thomas Wildgruber
- Re: [SCSI] Battery Backup Unit
- From: Ingo Böttcher
- Re: [SCSI] Battery Backup Unit
- From: Thomas Wildgruber
- Re: [SCSI] Battery Backup Unit
- From: Ingo Böttcher
- [SCSI] Battery Backup Unit
- Prev by Date: SCSI Probleme
- Next by Date: Re: SCSI Probleme
- Previous by thread: Re: [SCSI] Battery Backup Unit
- Next by thread: Re: [SCSI] Battery Backup Unit
- Index(es):
Relevant Pages
|
