Raid 50 schneller als Raid 5?
Neuer Server - Raid 50 oder Raid 5
Hallo!
Meine Firma kauf für unsere ERP Software einen neuen Server (Windows Server 2008 R2). Anscheinend sollen mit Raid 50 die Zugriffe um einiges schneller verarbeitet werden als mit Raid 5. Stimmt das? Hat jemand schon Erfahrungen damit?
Danke für eure Hilfe!
Hallo!
Meine Firma kauf für unsere ERP Software einen neuen Server (Windows Server 2008 R2). Anscheinend sollen mit Raid 50 die Zugriffe um einiges schneller verarbeitet werden als mit Raid 5. Stimmt das? Hat jemand schon Erfahrungen damit?
Danke für eure Hilfe!
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 179072
Url: https://administrator.de/contentid/179072
Ausgedruckt am: 22.11.2024 um 09:11 Uhr
9 Kommentare
Neuester Kommentar
Moin,
hat die Suchmaschine Deiner Wahl grad Urlaub? http://en.wikipedia.org/wiki/Nested_RAID_levels
Gruß
24
hat die Suchmaschine Deiner Wahl grad Urlaub? http://en.wikipedia.org/wiki/Nested_RAID_levels
Gruß
24
Hallo
Die Zugriffe sind gleich schnell, da es hierbei Festplattenabhängig ist.
Man erhöht unter umständen den Datendurchsatz beim Schreiben und Lesen, da es dann 2 Raid 5 Arrays gibt, die dann zusammen als Raid 0 laufen.
Ein Raid 50 bietet auch gegenüber eines Raid 5 den vorteil der "etwas" besseren Redudanz und beim Festplattenausfall wird halt nur in einem Raid 5 Unterarray die Daten wiederhergestellt, was bei vielen Festplatten den Controller auch entlasten kann.
Kannst aber auch Raid 5 mit schnellen SAS(z.b. 300GB 15k in 3,5" etwa 3,4ms und bei 2,5" ca 2,7ms[Handelsübliche Sata haben zwischen 8 und 12ms]) nehmen da erreichst schon ohne probleme die 120MB/s Pro Festplatte.
mfg
derklient
Die Zugriffe sind gleich schnell, da es hierbei Festplattenabhängig ist.
Man erhöht unter umständen den Datendurchsatz beim Schreiben und Lesen, da es dann 2 Raid 5 Arrays gibt, die dann zusammen als Raid 0 laufen.
Ein Raid 50 bietet auch gegenüber eines Raid 5 den vorteil der "etwas" besseren Redudanz und beim Festplattenausfall wird halt nur in einem Raid 5 Unterarray die Daten wiederhergestellt, was bei vielen Festplatten den Controller auch entlasten kann.
Kannst aber auch Raid 5 mit schnellen SAS(z.b. 300GB 15k in 3,5" etwa 3,4ms und bei 2,5" ca 2,7ms[Handelsübliche Sata haben zwischen 8 und 12ms]) nehmen da erreichst schon ohne probleme die 120MB/s Pro Festplatte.
mfg
derklient
Hallo,
ERP bedeutet für mich Datenbank mit relativ "geringer" Größe .
Ein Raid 5 ist da genau das was man nicht braucht. Ein Raid 50 macht es sicher besser aber halte ich trotzdem für sinnlos.
Je nach Firmengröße und System eher ein oder mehrere Raid 10 (DB und Transaktionslog) auf jeweils einem eigenständigen Raid.
Oder schöne Enterprice SSD's verwenden.
ERP bedeutet für mich Datenbank mit relativ "geringer" Größe .
Ein Raid 5 ist da genau das was man nicht braucht. Ein Raid 50 macht es sicher besser aber halte ich trotzdem für sinnlos.
Je nach Firmengröße und System eher ein oder mehrere Raid 10 (DB und Transaktionslog) auf jeweils einem eigenständigen Raid.
Oder schöne Enterprice SSD's verwenden.
öhm - nein, ERP Datenbanken benötigen in den meisten Fällen sehr viele IOs und im Regelfall sollte man da immer Raid 10 wählen. Unsere NAV DB geht momentan total in die Knie bei 12 x SAS 15k rpm als Raid 10 (90 User) und das an sich nur weil die IOs nicht reichen. (das wurde durch eine Langzeitmessung ermittelt)
Ich würde bei einer ERP immer Raid 10 nehmen nichts anderes (und nein Lexware ist keine ERP ... )
Zitat von @clSchak:
öhm - nein, ERP Datenbanken benötigen in den meisten Fällen sehr viele IOs und im Regelfall sollte man da immer
Raid 10 wählen. Unsere NAV DB geht momentan total in die Knie bei 12 x SAS 15k rpm als Raid 10 (90 User) und das an sich nur
weil die IOs nicht reichen. (das wurde durch eine Langzeitmessung ermittelt)
öhm - nein, ERP Datenbanken benötigen in den meisten Fällen sehr viele IOs und im Regelfall sollte man da immer
Raid 10 wählen. Unsere NAV DB geht momentan total in die Knie bei 12 x SAS 15k rpm als Raid 10 (90 User) und das an sich nur
weil die IOs nicht reichen. (das wurde durch eine Langzeitmessung ermittelt)
Nur so nebenbei. Hab auch NAV im Einsatz mit 30 Usern. Da alleine war vom Systemhaus min 16 SAS 15k Platten als Grundvoraussetzung.
Zitat von @XenonAUT:
Danke für die vielen Antworten! Die ERP-Software hat eine sehr große Datenbank (etwa 200 GB). In den Server werden 300
GB 15K SAS 2.5" Platten verbaut.
Aktuell verwenden wir Raid 5. Nun hat unser Lieferant jedoch gesagt, dass Raid 50 anscheinend schneller sein soll. Mir geht es
hier weniger um die Sicherheit, da Raid 5 imho ausreichend ist.
Danke für die Anregungen!
Danke für die vielen Antworten! Die ERP-Software hat eine sehr große Datenbank (etwa 200 GB). In den Server werden 300
GB 15K SAS 2.5" Platten verbaut.
Aktuell verwenden wir Raid 5. Nun hat unser Lieferant jedoch gesagt, dass Raid 50 anscheinend schneller sein soll. Mir geht es
hier weniger um die Sicherheit, da Raid 5 imho ausreichend ist.
Danke für die Anregungen!
Selbst 200GB sind für Festplatten relativ wenig. Vom Volumen her kriegt man das schon auf eine drauf. Wenn da nicht's anderes drauf ist dann ist meiner Meinung nach RAID 5 ein absoluter Fehler da es drauf ausgelegt ist möglichst viel Speicherplatz zu bieten und immer noch für Redundanz zu sorgen.
Ein Raid 50 braucht min 6 Platten, rechnen wir mal mit a 146 GB (kleine Platten): macht 876 GB, sind also über 4 mal so viel Platz als du brauchst.
Ein Raid 10 mit 6 Platten macht 438, immer noch das Doppelte an benötigten Platz aber doch etwas schneller. Und
Und fallst du etwas neu kaufen musst SSD's. Da macht's doch gleich richtig Spaß
Edit: und in nem vernünftigen DB Server sind selten so weinig Platten drinn. Rechne es doch mal hoch bei den 18 Platten von mir. Da hast du relativ viel überflüssigen Platz wenn nicht's anderes drauf laufen soll.
Das sollte mit Raid 10 mit mehreren Festplatten kein Problem sein, wenn man viele Platten im Einsatz hat, da dort die Geschwindigkeit zählt und der gesamte Speicherplatz aller Platten einfach durch 2 genommen wird.
Und das Wachstum der Datenbank muss man ja eh Einkalkulieren, da ein DB Server unter umständen nicht jedes Jahr gewechselt wird wegen den Anschaffungskosten.
Und das Wachstum der Datenbank muss man ja eh Einkalkulieren, da ein DB Server unter umständen nicht jedes Jahr gewechselt wird wegen den Anschaffungskosten.