7
3ware SATA-Raid - Protect, Balance, Performance - welches Profil
Hallo,
ich habe hier ein S-ATA-Raid10 mit 8 Platten an einem 3Ware 9550 mit Battery Backup.
Am Controller kann man für jede Unit eine sogenannte StorSave-Stufe wählen.
Welches der drei Profile würdet ihr mir empfehlen?
Protect und Balance scheinen fast gleiche Geschwindigkeit zu bringen. Performance ist deutlich schneller.
Hier wird jedoch garkein Write Journaling verwandt.
Außerdem ist FUA (Force Unit Access) deaktiviert.
Normalerweise sollten diese zwei Punkte ja nur wichtig werden, wenn der Strom wegbricht (was bei 3 USVs relativ unwahrscheinlich ist).
Wozu würdet ihr tendieren? Auf dem Server läuft eine Datenbankanwendung.
Vielen Dank für die Hilfe
Gruß
Phil
ich habe hier ein S-ATA-Raid10 mit 8 Platten an einem 3Ware 9550 mit Battery Backup.
Am Controller kann man für jede Unit eine sogenannte StorSave-Stufe wählen.
Welches der drei Profile würdet ihr mir empfehlen?
Protect und Balance scheinen fast gleiche Geschwindigkeit zu bringen. Performance ist deutlich schneller.
Hier wird jedoch garkein Write Journaling verwandt.
Außerdem ist FUA (Force Unit Access) deaktiviert.
Normalerweise sollten diese zwei Punkte ja nur wichtig werden, wenn der Strom wegbricht (was bei 3 USVs relativ unwahrscheinlich ist).
Wozu würdet ihr tendieren? Auf dem Server läuft eine Datenbankanwendung.
Vielen Dank für die Hilfe
Gruß
Phil
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 35630
Url: https://administrator.de/forum/3ware-sata-raid-protect-balance-performance-welches-profil-35630.html
Ausgedruckt am: 03.04.2025 um 09:04 Uhr
7 Kommentare
Neuester Kommentar
Hi,
es gibt nur drei Möglichkeiten, welche dahinterstehen, ohne den Kontroller zu kennen:
Protect = Schreibcache 0%, Lesecache 100%; die "sichere" und langsame Methode, Fertigmeldung ans OS erst, wenn die Daten auf die Platten geschrieben wurden
Balance = Schreib- und Lesecache je 50%
Performance = Schreibcache wird ausgereizt, Gefahr ist, daß bei Sofortabsturz Daten im Schreibcache verbleiben und unter Umständen auch trotz Batteriepufferung verloren gehen, da sie nicht mehr auf die Platten geschrieben werden können (es gibt Fälle, wo dies passieren kann)
Im SCSI- Umfeld hätte ich keine großen Bedenken, Performance auszuwählen, falls dies wirklich eine brauchbare Durchsatzsteigerung bringt, im SATA Bereich mag ich keine Aussagen treffen, da ich über die Zuverlässigkeit im Fehlerfall keine (bzw. bei Billig- Teilen nur schlechte) Erfahrungen habe.
Wichtig ist, dran zu denken, daß, wenn dieses Array in einem Cluster eingesetzt wird, der Schreibcache zwingend abzuschalten ist (falls diese SATA- Dinger clusterfähig sein sollten)
Gruß - Toni
es gibt nur drei Möglichkeiten, welche dahinterstehen, ohne den Kontroller zu kennen:
Protect = Schreibcache 0%, Lesecache 100%; die "sichere" und langsame Methode, Fertigmeldung ans OS erst, wenn die Daten auf die Platten geschrieben wurden
Balance = Schreib- und Lesecache je 50%
Performance = Schreibcache wird ausgereizt, Gefahr ist, daß bei Sofortabsturz Daten im Schreibcache verbleiben und unter Umständen auch trotz Batteriepufferung verloren gehen, da sie nicht mehr auf die Platten geschrieben werden können (es gibt Fälle, wo dies passieren kann)
Im SCSI- Umfeld hätte ich keine großen Bedenken, Performance auszuwählen, falls dies wirklich eine brauchbare Durchsatzsteigerung bringt, im SATA Bereich mag ich keine Aussagen treffen, da ich über die Zuverlässigkeit im Fehlerfall keine (bzw. bei Billig- Teilen nur schlechte) Erfahrungen habe.
Wichtig ist, dran zu denken, daß, wenn dieses Array in einem Cluster eingesetzt wird, der Schreibcache zwingend abzuschalten ist (falls diese SATA- Dinger clusterfähig sein sollten)
Gruß - Toni
Hi!
Vielen Dank für deine Antwort.
Leider haben diese drei Profile nichts mit der Verteilung Schreib/Lesecache zu tun.
Es geht dabei um das FUA und das Write Journaling.
FUA bezeichnet es, dass Programme den Schreibcache umgehen können.
Gruß
Phil
Vielen Dank für deine Antwort.
Leider haben diese drei Profile nichts mit der Verteilung Schreib/Lesecache zu tun.
Es geht dabei um das FUA und das Write Journaling.
FUA bezeichnet es, dass Programme den Schreibcache umgehen können.
Wichtig ist, dran zu denken, daß, wenn
dieses Array in einem Cluster eingesetzt
wird, der Schreibcache zwingend abzuschalten
ist (falls diese SATA- Dinger
clusterfähig sein sollten)
Ich verwende kein Cluster. Das Ganze ist nur ein einzelner Datenbankserver, der jedoch sehr stark ausgelastet wird...dieses Array in einem Cluster eingesetzt
wird, der Schreibcache zwingend abzuschalten
ist (falls diese SATA- Dinger
clusterfähig sein sollten)
Gruß
Phil
Da du ja offenbar genau über die Arbeitsweise von Raid- Kontrollern Bescheid weißt,
frage ich mich, wozu Du eigentlich die Frage gestellt hast?
frage ich mich, wozu Du eigentlich die Frage gestellt hast?
Hallo,
ich kann mich durch die Anleitung lesen und die Bedeutung der Profile herausfinden.
Warum ich dann jedoch nicht nach Hilfe fragen darf, was für mich in der Praxis nötig wird verstehe ich jedoch nicht.
Wo ich Dir jetzt auf den Schlips getreten sein soll, weiß ich jedoch nicht.
Ich bin für jede Hilfe dankbar, nur hier hats halt bisher nicht gegriffen.
Phil
ich kann mich durch die Anleitung lesen und die Bedeutung der Profile herausfinden.
Warum ich dann jedoch nicht nach Hilfe fragen darf, was für mich in der Praxis nötig wird verstehe ich jedoch nicht.
Wo ich Dir jetzt auf den Schlips getreten sein soll, weiß ich jedoch nicht.
Ich bin für jede Hilfe dankbar, nur hier hats halt bisher nicht gegriffen.
Phil
Die Arbeitsweise von Raidsystemen habe ich bereits oben beschrieben, andere Möglichkeiten, die Performance zu beeinflußen, gibt es nicht.
Bei besagtem "FUA" (FUA = ForceUnitAccess) wird durch setzen eines Flags der Kontroller veranlasst, diese Daten sofort auf die Platte zu schreiben. Nichts anderes passiert, wenn der Lesecache auf 100% gesetzt wird, bzw. der Schreibcache deaktiviert wird, allerdings mit dem Unterschied, daß mittels FUA in die Verwaltung des Kontrollers eingegriffen wird (Cache wird geleert, um den angeforderten Schreibvorgang unmittelbar ausführen zu können) und damit Performanceeinbußen erfolgen.
Auch bei dem "Write Journaling" handelt es sich um nichts anderes als Cache- Sicherung durch Batterie- Pufferung und Sicherstellung, daß die Daten aus dem Cache nach Wiederanlauf des Systems auf die Platten zurückgeschrieben werden. Im SCSI- Bereich ist diese Vorgehensweise Usus und wird deshalb nicht extra erwähnt, während es im SATA- Umfeld als bahnbrechende Neuerung gepriesen wird.
Falls Du immer noch der Meinung bist, daß dies alles nichts mit Cache- Strategie zu tun hat, gebe ich mich geschlagen.
Nun noch mal zu Deiner Frage:
Da es bei Datenbanken i.d.R. auf hohe Performance ankommt, sollte die gleichlautende Einstellung gewählt werden, besonders, wenn es sich um einen stark frequentierten Server handelt (vorausgesetzt, USV und Cache- Pufferung wie bei Dir der Fall, sind vorhanden). Der aktivierte Schreibcache bietet den Vorteil, daß Zugriffe auf Daten, die noch im Cache liegen, in diesem bearbeitet werden und der "Umweg" über die Platten vermieden wird.
Bei besagtem "FUA" (FUA = ForceUnitAccess) wird durch setzen eines Flags der Kontroller veranlasst, diese Daten sofort auf die Platte zu schreiben. Nichts anderes passiert, wenn der Lesecache auf 100% gesetzt wird, bzw. der Schreibcache deaktiviert wird, allerdings mit dem Unterschied, daß mittels FUA in die Verwaltung des Kontrollers eingegriffen wird (Cache wird geleert, um den angeforderten Schreibvorgang unmittelbar ausführen zu können) und damit Performanceeinbußen erfolgen.
Auch bei dem "Write Journaling" handelt es sich um nichts anderes als Cache- Sicherung durch Batterie- Pufferung und Sicherstellung, daß die Daten aus dem Cache nach Wiederanlauf des Systems auf die Platten zurückgeschrieben werden. Im SCSI- Bereich ist diese Vorgehensweise Usus und wird deshalb nicht extra erwähnt, während es im SATA- Umfeld als bahnbrechende Neuerung gepriesen wird.
Falls Du immer noch der Meinung bist, daß dies alles nichts mit Cache- Strategie zu tun hat, gebe ich mich geschlagen.
Nun noch mal zu Deiner Frage:
Da es bei Datenbanken i.d.R. auf hohe Performance ankommt, sollte die gleichlautende Einstellung gewählt werden, besonders, wenn es sich um einen stark frequentierten Server handelt (vorausgesetzt, USV und Cache- Pufferung wie bei Dir der Fall, sind vorhanden). Der aktivierte Schreibcache bietet den Vorteil, daß Zugriffe auf Daten, die noch im Cache liegen, in diesem bearbeitet werden und der "Umweg" über die Platten vermieden wird.
Hi!
Vielen Dank für die Antwort!
Ich bin einfach davon ausgegangen, dass FUA so funktioniert, dass lediglich einzelne Programme dieses "Cache leeren" anfordern können, - im Normalbetrieb jedoch der Schreibcache aktiviert ist.
Hat sich in der 3ware Manual irgendwie so gelesen...
Phil
Vielen Dank für die Antwort!
Ich bin einfach davon ausgegangen, dass FUA so funktioniert, dass lediglich einzelne Programme dieses "Cache leeren" anfordern können, - im Normalbetrieb jedoch der Schreibcache aktiviert ist.
Hat sich in der 3ware Manual irgendwie so gelesen...
Phil
Das ist korrekt und steht auch so in meiner Beschreibung
Gruß - Toni
Gruß - Toni
