12
HP Proliant G9 Raidkonfiguration - Ein Raid5 oder gesplittet?
Hallo zusammen,
ich habe eine allgemeine Frage zu einer Raidkonfiguration und wie ich die am besten konfiguriere auf einem HP Proliant G9 Server.
Der Server ist im Werkszustand und folgende Platten sind verbaut:
2x 300 GB SAS 15 K Platten im Slot 1 und 2 (sind gedacht für das Betriebssystem)
6x 600 GB SAS 15 Platten im Slot 3 bis 8 (Sind gedacht für Datenablage und SQL Datenbankablage)
Jetzt ist die Frage welches Raid am sinnvollsten wäre.
Die Entscheidung steht eigentlich schon für ein Raid 5. Nur ist die Frage ob die ersten zwei Systemplatten besser in ein eigenes Raid sollten zB. Raid 1 und die anderen 6 Platten in ein Raid 5. Bei den 600er Platten soll zusätzlich noch eine als Hotspare fungieren.
Wie würdet ihr die Raid Konfiguration durchführen?
Danke und Gruss
staybb
ich habe eine allgemeine Frage zu einer Raidkonfiguration und wie ich die am besten konfiguriere auf einem HP Proliant G9 Server.
Der Server ist im Werkszustand und folgende Platten sind verbaut:
2x 300 GB SAS 15 K Platten im Slot 1 und 2 (sind gedacht für das Betriebssystem)
6x 600 GB SAS 15 Platten im Slot 3 bis 8 (Sind gedacht für Datenablage und SQL Datenbankablage)
Jetzt ist die Frage welches Raid am sinnvollsten wäre.
Die Entscheidung steht eigentlich schon für ein Raid 5. Nur ist die Frage ob die ersten zwei Systemplatten besser in ein eigenes Raid sollten zB. Raid 1 und die anderen 6 Platten in ein Raid 5. Bei den 600er Platten soll zusätzlich noch eine als Hotspare fungieren.
Wie würdet ihr die Raid Konfiguration durchführen?
Danke und Gruss
staybb
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 622963
Url: https://administrator.de/contentid/622963
Printed on: May 4, 2024 at 22:05 o'clock
12 Comments
Latest comment
Moin ,
die beiden 300er Raid 1
die 6 600er Raid 10 wegen dem SQL Server.
Gruss
die beiden 300er Raid 1
die 6 600er Raid 10 wegen dem SQL Server.
Gruss
Moin
Danke für den Tipp.
Warum genau sollte man Raid 10 vor Raid 5 vorziehen?
Schauste hier mal vorbei, dann sollte sich die Frage schon erledigen. Bei Raid 10 sind die IOPS viel höher als bei Raid 5.
http://www.raid-calculator.com/
Naja - das Problem is das mal wieder NICHTS über die Umgebung gesagt wird - da kann man nur generelle Schätzungen abgeben... Es ist ja nicht gesagt wofür die DB sein soll und wieviele Zugriffe erwartet werden. Da kann es jetzt unterschiedliche Dinge geben - z.B. nen Dokumenten-Managementsystem was eher viele grosse Daten hat (da wäre dann der Platz schon interessant, die Zugriffsgeschwindigkeit eher nicht so). Oder es is eben der Web-Shop mit 500.000 Besuchern gleichzeitig die aber nur vergleichsweise kleine Datenmengen haben - da wäre dann die Grösse eher sekundär, da kommt es dann eben auf die Suchgeschwindigkeit an...
Ich würde aber auch in jedem Fall System und DB voneinander trennen - allein schon damit ein Fehler nich gleich die Platten vollschreibt...
Ich würde aber auch in jedem Fall System und DB voneinander trennen - allein schon damit ein Fehler nich gleich die Platten vollschreibt...
Zitat von @maretz:
Ich würde aber auch in jedem Fall System und DB voneinander trennen - allein schon damit ein Fehler nich gleich die Platten vollschreibt...
Ich würde aber auch in jedem Fall System und DB voneinander trennen - allein schon damit ein Fehler nich gleich die Platten vollschreibt...
Ich würde das schon allein aus dem Grund der unterschiedlichen Plattengröße trennen. Wenn du ein Raid (egal was für eins) über alle 8 Platten machst, dann werden bei den 6 600er Platten ja nur 300 GB berücksichtigt, weil es sonst ja nicht passt. Von daher zeigt allein die Ausgangsfrage "Ein Raid 5 oder gesplittet" schon von Kenntnisstand, wie Raids arbeiten.
Mein Tipp: Informiere wie Raids arbeiten, was Sie machen und was Sinnvoll ist und dann ziehe ALLE relevanten Faktoren mit in deine Überlegung ein.
Zitat von @maretz:
Naja - das Problem is das mal wieder NICHTS über die Umgebung gesagt wird - da kann man nur generelle Schätzungen abgeben... Es ist ja nicht gesagt wofür die DB sein soll und wieviele Zugriffe erwartet werden. Da kann es jetzt unterschiedliche Dinge geben - z.B. nen Dokumenten-Managementsystem was eher viele grosse Daten hat (da wäre dann der Platz schon interessant, die Zugriffsgeschwindigkeit eher nicht so). Oder es is eben der Web-Shop mit 500.000 Besuchern gleichzeitig die aber nur vergleichsweise kleine Datenmengen haben - da wäre dann die Grösse eher sekundär, da kommt es dann eben auf die Suchgeschwindigkeit an...
Ich würde aber auch in jedem Fall System und DB voneinander trennen - allein schon damit ein Fehler nich gleich die Platten vollschreibt...
Naja - das Problem is das mal wieder NICHTS über die Umgebung gesagt wird - da kann man nur generelle Schätzungen abgeben... Es ist ja nicht gesagt wofür die DB sein soll und wieviele Zugriffe erwartet werden. Da kann es jetzt unterschiedliche Dinge geben - z.B. nen Dokumenten-Managementsystem was eher viele grosse Daten hat (da wäre dann der Platz schon interessant, die Zugriffsgeschwindigkeit eher nicht so). Oder es is eben der Web-Shop mit 500.000 Besuchern gleichzeitig die aber nur vergleichsweise kleine Datenmengen haben - da wäre dann die Grösse eher sekundär, da kommt es dann eben auf die Suchgeschwindigkeit an...
Ich würde aber auch in jedem Fall System und DB voneinander trennen - allein schon damit ein Fehler nich gleich die Platten vollschreibt...
Hi,
ja sorry das war jetzt recht vereinfacht und allgemein gehalten im ersten Post.
Generell habe ich nicht viel dazu geschrieben, da es sich nur um eine kleine Umgebung halten wo später 5-10 User auf die Datenbank zugreifen.
Also würde aus performance Sicht ein Raid 5 allemal ausreichen.
Aber es macht natürlich schon Sinn bei grösseren Umgebungen zB. ein Raid10 in Betracht zu ziehen wenn die Zugriffszeiten dort dem Raid 5 überlegen.
Bei der Konstellation hier handelt es sich um eine kleinere Umgebung, besser gesagt einen Aussenstandort mit 10 Mitarbeitern.
Bei uns in der Zentrale ist zB. eine HCI Umgebung von Nutanix im Einsatz, mit entsprechender Anbindung und keinem traditionellen Raid sondern einem "Replication Factor", welcher auf block Ebene Daten ablegt und redundant mit fashion across mehrere nodes in einem cluster (i.e RF2 two copies or RF3, three copies) managed.
Zitat von @staybb:
Hi,
ja sorry das war jetzt recht vereinfacht und allgemein gehalten im ersten Post.
Generell habe ich nicht viel dazu geschrieben, da es sich nur um eine kleine Umgebung halten wo später 5-10 User auf die Datenbank zugreifen.
Also würde aus performance Sicht ein Raid 5 allemal ausreichen.
Zitat von @maretz:
Naja - das Problem is das mal wieder NICHTS über die Umgebung gesagt wird - da kann man nur generelle Schätzungen abgeben... Es ist ja nicht gesagt wofür die DB sein soll und wieviele Zugriffe erwartet werden. Da kann es jetzt unterschiedliche Dinge geben - z.B. nen Dokumenten-Managementsystem was eher viele grosse Daten hat (da wäre dann der Platz schon interessant, die Zugriffsgeschwindigkeit eher nicht so). Oder es is eben der Web-Shop mit 500.000 Besuchern gleichzeitig die aber nur vergleichsweise kleine Datenmengen haben - da wäre dann die Grösse eher sekundär, da kommt es dann eben auf die Suchgeschwindigkeit an...
Ich würde aber auch in jedem Fall System und DB voneinander trennen - allein schon damit ein Fehler nich gleich die Platten vollschreibt...
Naja - das Problem is das mal wieder NICHTS über die Umgebung gesagt wird - da kann man nur generelle Schätzungen abgeben... Es ist ja nicht gesagt wofür die DB sein soll und wieviele Zugriffe erwartet werden. Da kann es jetzt unterschiedliche Dinge geben - z.B. nen Dokumenten-Managementsystem was eher viele grosse Daten hat (da wäre dann der Platz schon interessant, die Zugriffsgeschwindigkeit eher nicht so). Oder es is eben der Web-Shop mit 500.000 Besuchern gleichzeitig die aber nur vergleichsweise kleine Datenmengen haben - da wäre dann die Grösse eher sekundär, da kommt es dann eben auf die Suchgeschwindigkeit an...
Ich würde aber auch in jedem Fall System und DB voneinander trennen - allein schon damit ein Fehler nich gleich die Platten vollschreibt...
Hi,
ja sorry das war jetzt recht vereinfacht und allgemein gehalten im ersten Post.
Generell habe ich nicht viel dazu geschrieben, da es sich nur um eine kleine Umgebung halten wo später 5-10 User auf die Datenbank zugreifen.
Also würde aus performance Sicht ein Raid 5 allemal ausreichen.
Selbst bei 5-10 Benutzern ist halt die Frage was die mit der DB machen sollen - da die ja idR. nich direkt auf die DB gehen sondern nur ne Applikation nutzen die auf der DB arbeitet... Aber generell würde ich da auch eher vermuten das es weniger um die Leistung geht.
Aber es macht natürlich schon Sinn bei grösseren Umgebungen zB. ein Raid10 in Betracht zu ziehen wenn die Zugriffszeiten dort dem Raid 5 überlegen.
Bei der Konstellation hier handelt es sich um eine kleinere Umgebung, besser gesagt einen Aussenstandort mit 10 Mitarbeitern.
Bei uns in der Zentrale ist zB. eine HCI Umgebung von Nutanix im Einsatz, mit entsprechender Anbindung und keinem traditionellen Raid sondern einem "Replication Factor", welcher auf block Ebene Daten ablegt und redundant mit fashion across mehrere nodes in einem cluster (i.e RF2 two copies or RF3, three copies) managed.
Sorry, das hört sich an wie ausm besten Marketing-Handbuch abgetippt - schön mit nen paar Englischen Fachworten reingemixt.. Aber gut, jedem das seine...
Irgendwie ist noch die Reihenfolge verdreht. Man überlegt sich zuerst das einzusetzende Raid, dann erst wie viel Platten man dafür einsetzt. Weil, bei Raid-10 hat man weniger Plattenplatz übrig als bei Raid-5.
Könnte aber auch ne IHK Prüfungsfrage sein, nach dem Motto: Sie haben folgenden Server, blabla. welche Raid-Konfiguration würden Sie empfehlen :D
ich möchte an der Stelle noch einmal kurz einwerfen, dass der Cache des Controllers bei der Konfiguration auch nicht völlig außer acht gelassen werden darf/sollte. Ich habe schon erlebt, dass Raid-5 mit dem entsprechenden Cache einem Raid-10 ohne Cache kaum noch nachstand. Ja, rein rechnerisch war 10 noch schneller, spürbar war es aber für die Anwender und Applikationen nicht mehr.
ich möchte an der Stelle noch einmal kurz einwerfen, dass der Cache des Controllers bei der Konfiguration auch nicht völlig außer acht gelassen werden darf/sollte. Ich habe schon erlebt, dass Raid-5 mit dem entsprechenden Cache einem Raid-10 ohne Cache kaum noch nachstand. Ja, rein rechnerisch war 10 noch schneller, spürbar war es aber für die Anwender und Applikationen nicht mehr.
Ebenso muß bzw. sollte immer noch eine Hotspare Platte mit eingerechnet werden und mögliche Rebuildzeiten bedacht werden.
Dabei kann es manchmal Sinn machen auf unterschiedliche Plattengrößen zu verzichten um 1 Hotspare für alle Raids im System verwenden zu können.
CH
Dabei kann es manchmal Sinn machen auf unterschiedliche Plattengrößen zu verzichten um 1 Hotspare für alle Raids im System verwenden zu können.
CH
Moin
Ja... Wodurch sich die Frage stellt, weshalb nicht gleich ein Raid 6 !?
Gruß
Zitat von @ChriBo:
Ebenso muß bzw. sollte immer noch eine Hotspare Platte mit eingerechnet werden und mögliche Rebuildzeiten bedacht werden.
Ebenso muß bzw. sollte immer noch eine Hotspare Platte mit eingerechnet werden und mögliche Rebuildzeiten bedacht werden.
Ja... Wodurch sich die Frage stellt, weshalb nicht gleich ein Raid 6 !?
Gruß
1
Zitat von @Hubert.N:
Moin
Ja... Wodurch sich die Frage stellt, weshalb nicht gleich ein Raid 6 !?
Gruß
Moin
Zitat von @ChriBo:
Ebenso muß bzw. sollte immer noch eine Hotspare Platte mit eingerechnet werden und mögliche Rebuildzeiten bedacht werden.
Ebenso muß bzw. sollte immer noch eine Hotspare Platte mit eingerechnet werden und mögliche Rebuildzeiten bedacht werden.
Ja... Wodurch sich die Frage stellt, weshalb nicht gleich ein Raid 6 !?
Gruß
Ahoi zusammen
Da kann ich mich Hubert anschliessen. Wir fahren seit einiger Zeit sehr gut mit RAID6 für Daten- und DB-Volumes. Zusätzlich war für uns der Aspekt einer zweiten Ausfall-Disk relevant aufgrund der örtlich verteilten Rechenzentren.
Grüsse
Damoclash
