Raid 50
- Ersteller DarkMaTTi
- Erstellt am
3V!L
Enthusiast
nein
PowerToTheUsers
Enthusiast
ja
ja
ja
- Mitglied seit
- 29.06.2006
- Beiträge
- 637
Muss man nicht unbedingt - da dort keine Paritätsdaten berechnet werden, bringt ein leistungsfähiger Controller in dieser Hinsicht keine Vorteile, es genügt im Grunde auch ein Software-Raid.
Controller-Cache, Battery-Backup-Unit, Flexibilität/Unabhängigkeit von Mainboard und Betriebssystem, usw. sind natürlich trotzdem Vorteile eines Controllers egal welches Raid-Level genutzt wird.
HisN
Legende
- Mitglied seit
- 09.06.2006
- Beiträge
- 31.948
Hängt wohl direkt von der Anzahl der Platten ab die Du betreiben willst. Ein 24-Kanal-Controller mit nur 4 Platten drann ist genau so beknackt wie ein 8-Kanal-Controller an den Du 16 Platten hängen möchtest.
Zuletzt bearbeitet:
underclocker2k4
Mr. Alzheimer
Kann man auch bei SATA, bei beiden Varianten wird aber ein port multiplier benötigt.
Daher HDD-Anzahl = Port-Anzahl!
Daher HDD-Anzahl = Port-Anzahl!
HisN
Legende
- Mitglied seit
- 09.06.2006
- Beiträge
- 31.948
für ein SATA II RAID 50 empfiehlt sich laut Test:
- AMCC/3WARE9650SE-8LPML
für ein SAS RAID 50 empfiehlt sich laut Test:
- Adaptec RAID 5805
- Adaptec RAID 3805
welchen Controller könnt ihr für ein SATA RAID 10 und für ein SAS RAID 10 (7200er Platten) empfehlen???
danke
mfg DarkMaTTi
- AMCC/3WARE9650SE-8LPML
für ein SAS RAID 50 empfiehlt sich laut Test:
- Adaptec RAID 5805
- Adaptec RAID 3805
welchen Controller könnt ihr für ein SATA RAID 10 und für ein SAS RAID 10 (7200er Platten) empfehlen???
danke
mfg DarkMaTTi
also es geht hauptsächlich um Datenbank & Files. Die Frage ist noch ungeklärt ob es sinn macht SWAP und Tempfiles auf schnellen Seagate Cheetah Platten auszulagern, ansonsten soll es so ausschaunen:
6-8 Seagate Barracuda ES.2 1 TB Platten die entweder im RAID 10 oder RAID 50 laufen sollen. Ob SAS oder SATA Version ist noch unklar da SAS-Version der Platten ja nicht soviel mehr Vorteile haben. Slot mäßig ist noch nicht sicher ob PCI-X zur verfügung stehn wird, eher PCIe da ja die PCIe x16 Slots abwärtskompatibel sind.
P.S.: was ist bei Asus Boards von diesem Asus Pike zu halten?
6-8 Seagate Barracuda ES.2 1 TB Platten die entweder im RAID 10 oder RAID 50 laufen sollen. Ob SAS oder SATA Version ist noch unklar da SAS-Version der Platten ja nicht soviel mehr Vorteile haben. Slot mäßig ist noch nicht sicher ob PCI-X zur verfügung stehn wird, eher PCIe da ja die PCIe x16 Slots abwärtskompatibel sind.
P.S.: was ist bei Asus Boards von diesem Asus Pike zu halten?
Zuletzt bearbeitet:
Elrond der 2te
Neuling
Bei RAID 10 hast du den nachteil, das du Mindestens 4 Platten brauchst, aber die hälfte der Kapazität verliertst.. RAID 50 halte ich für unnötig, ein normales RAID5 oder 6 tuts auch.. Du solltest aber auch eine extra Platte fürs OS nehmen (z.B eine Cheetah/Savvio, Velociraptor oder SSD ->Das ganze soll nehme ich jetzt mal an für eine Workstation sein??) Soll das System Produktiv eingesetzt werden oder ist es eher ein Hobby Rechner??
Anus (Asus) Consumer Boards sind meiner Meinung nach der letzte Müll (genügend schlechte Erfahrungen gemacht..), lieber was von MSI oder DFI (meintetwegen auch von Gagabyte)
Anus (Asus) Consumer Boards sind meiner Meinung nach der letzte Müll (genügend schlechte Erfahrungen gemacht..), lieber was von MSI oder DFI (meintetwegen auch von Gagabyte)
Naja wenn er von ASUS Pike spricht, meint er wohl eher die ASUS Serverboards und die werden ja von vielen hier im Forum verwendet, daher scheinen die nicht so schlecht zu sein.
Raid 10 kannst bei dem Vorhaben wohl eher vergessen, du verlierst genau die Hälfte der angesteckten Kapazität, was in deinem Fall nicht wirklich im Sinne des Erfinders sein dürfte...
Ein Raid 5 hat im Gegensatz zu nem Raid 50 eigentlich nur den Nachteil, das die Transferrate etwas niedriger ist, aber das sollte sich bei der Anzahl der HDDs nicht sonderlich viel nehmen, zumahl du bei nem Radi 50 die doppelten Paritätsdaten berechnen musst...
Vorteile bringt dir diese gesteigerte Transferrate aber eher nix, vor allem im Datenbankeinsatz nicht.
Für die Files vllt schon, aber hier sollte in jedemfall eigentlich auch die NIC limitieren...
Weiterer Nachteil, du verlierst beim Raid 50 die Kapazität zweier HDDs, bei nem Raid 5 nur eine, steigerst aber die Ausfallwarscheinlichkeit mit dem Raid 50.
Ein Raid 5 hat im Gegensatz zu nem Raid 50 eigentlich nur den Nachteil, das die Transferrate etwas niedriger ist, aber das sollte sich bei der Anzahl der HDDs nicht sonderlich viel nehmen, zumahl du bei nem Radi 50 die doppelten Paritätsdaten berechnen musst...
Vorteile bringt dir diese gesteigerte Transferrate aber eher nix, vor allem im Datenbankeinsatz nicht.
Für die Files vllt schon, aber hier sollte in jedemfall eigentlich auch die NIC limitieren...
Weiterer Nachteil, du verlierst beim Raid 50 die Kapazität zweier HDDs, bei nem Raid 5 nur eine, steigerst aber die Ausfallwarscheinlichkeit mit dem Raid 50.
hm, naja ich hab mich an dem Whitepaper "Welcher RAID Level ist der richtige für mich" orientiert und da wird RAID 50 für große Datenbanken empfohlen.
mal abgesehn davon, was für ein Controller wäre den nun Sinnvoll bei RAID 10, 5 oder 50??? Macht bei den 7200er Platten trotzdem ein SAS Controller Sinn oder SATA (bei dem SAS kann man ja auch SATA Platten dranhängen)?
danke
mfg DarkMaTTi
mal abgesehn davon, was für ein Controller wäre den nun Sinnvoll bei RAID 10, 5 oder 50??? Macht bei den 7200er Platten trotzdem ein SAS Controller Sinn oder SATA (bei dem SAS kann man ja auch SATA Platten dranhängen)?
danke
mfg DarkMaTTi
Für komplexe Datenbanken zählt die Zugriffszeit und noch der Cache des Controllers...
Die Zugriffszeit bekommst du nur durch schnellere HDDs kleiner, oder durch SSDs, ansonsten bringt dir das Raidlevel bzw. die Anzahl der HDDs da gar nix.
Weiterer Nachteil, wenn die Daten der Fileablage auf dem gleichen Raidarray liegen, wird immer das komplette Raidarray belastet, was die Datenbankperformance ebenso sinken lässt.
Wenn die Datenbank hochkomplex ist und extrem an der HDD Performance hängt, dann macht es vllt sogar Sinn ein einzellnes Raid 5 aus 3 sehr schnellen SAS HDDs allein für die Datenbank zu bauen und 4-5 1TB HDDs für die Datenablage zusätzlich mit nem weiteren Raid 5 zu erstellen.
Ja SATA HDDs gehen auch an SAS Controllern, aber anders rum gehts net...
Kommt halt immer drauf an, oft sind SAS Controller günstiger als von den Daten her gleichwertige SATA Controller...
Die Zugriffszeit bekommst du nur durch schnellere HDDs kleiner, oder durch SSDs, ansonsten bringt dir das Raidlevel bzw. die Anzahl der HDDs da gar nix.
Weiterer Nachteil, wenn die Daten der Fileablage auf dem gleichen Raidarray liegen, wird immer das komplette Raidarray belastet, was die Datenbankperformance ebenso sinken lässt.
Wenn die Datenbank hochkomplex ist und extrem an der HDD Performance hängt, dann macht es vllt sogar Sinn ein einzellnes Raid 5 aus 3 sehr schnellen SAS HDDs allein für die Datenbank zu bauen und 4-5 1TB HDDs für die Datenablage zusätzlich mit nem weiteren Raid 5 zu erstellen.
Ja SATA HDDs gehen auch an SAS Controllern, aber anders rum gehts net...
Kommt halt immer drauf an, oft sind SAS Controller günstiger als von den Daten her gleichwertige SATA Controller...
Elrond der 2te
Neuling
Dachte die Pike Serie ist schon wieder irgendeine neue Consumer Serie von Assus, hab dann nicht mehr nachgeschaut, war ja auch schon spät.. Die Serverboards von Assus sind idr. nicht schlecht, nur was ich nicht ganz verstehe ist, warum so ziemlich jeder bei Produktivsystemen anfängt zu basteln... Lieber was von HP, DELL, IBM nehmen und sich die Rennerei ersparen wenn was eingeht......
Ansonsten sagt der fdsonne eigentlich eh schon alles was wichtig ist
Ansonsten sagt der fdsonne eigentlich eh schon alles was wichtig ist
bei anstaendigen controllern kann raid1 unter last (im read) 2,5x so schnell sein dank raid1 read balancing.
ansonsten - raid5 nimmt und empfiehlt niemand fuer datenbanken. ibm nicht und oracle schon garnicht. wenn redundantes raid fuer DBs dann raid1 oder raid10.
zumindest nicht wenn die performance wichtig ist.
desweiteren, wenn man mehrere DBs parallel benutzen will/muss kann man auch mehrere raid arrays anlegen und die DBs ein bisl aufteilen. auch das journal bei journaling filesystemen kann man auf eine eigene platte legen. (zumindest bei unix/linux) - sofern man nicht gleich raw devices benutzen will
Zuletzt bearbeitet:
Das stimmt zwar, nur bringt ihm das in seinem Fall recht wenig, weil eben nur die Datenrate steigt, aber die viel wichtigere Zugriffszeit nicht ansteigt...
Das ein Raid 5 ungünstig für DBs ist, stimmt natürlich ebenso
falsch
bei raid1 read balancing sinkt (nicht steigt
) die zugriffszeit gewaltigwenn unter last z.b. 128 datensaetze random gelesen werden teilt der controller sie intelligent auf - per NCQ werden sie geordnet und dann liest jeweils eine platte/lesekopf 64 optimal verteilte datensaetze - z.b. liest platte 1 dann im die 64 datensaetze im anfangsbereich der hdd, die zweite im endbereich.
deshalb kannst du viel mehr random read (also dort wo die zugriffszeit wichtig ist) aus einem raid1 holen als z.b. aus einem raid0, wo alle lesekoepfe alle 128 datensaetze ansteuern muessen (sofern die request size hoch genug ist und die datensaetze auf allen platten verteilt liegen)
wenn in der DB aber viel mehr geschrieben wird als gelesen wird (z.b. bei ueberwachungssoftware) - dann hilfts dir null
edit: siehe z.b.
http://forums.storagereview.net/index.php?showtopic=24561&hl=raid1
Zuletzt bearbeitet:
das würde bedeuten, das im Optimalfall bei gleicher Zugriffszeit und gleicher Datenrate die doppelte Menge an Datensätzen gelesen werden kann, richtig?
Stimmt eigentlich, und ist ja auch logisch, wenn die beiden HDDs im Raid 1 durch den Controller unterschiedliche Bereiche lesen könne und somit fast unabhängig von der anderen HDD agieren bei lesen...
Stimmt eigentlich, und ist ja auch logisch, wenn die beiden HDDs im Raid 1 durch den Controller unterschiedliche Bereiche lesen könne und somit fast unabhängig von der anderen HDD agieren bei lesen...
Ist doch aber eigentlich egal, wie stark der Lesekopf sich bewegen muss, da wir doch über Random Zugriff reden, und hier gibt doch die Zugriffszeit an, wie lange der Lesekopf brauch um die Stelle auf der HDD zu finden, wo die Daten abgegriffen werden?
Oder steh ich aufm Schlauch?
Oder steh ich aufm Schlauch?
jein, wenn der lesekopf immer zwischen der innersten und auessersten spur hin und her positionieren muss dauerts immer einen "full stroke" - das sind ~18ms bei 7200rpm satas
von spur zu spur positionieren dauert 0.xx ms
wennst sich der lesekopf dann nur in einem kleineren bereich positionieren muss dauerts nicht so lange.
hier die daten einer 7200rpm wdc platte
Seek Times - 8.7 ms (Read); 0.6 ms (Track-to Track); 21.0 ms (Full Stroke)
die 8,7 ist eben nur der "average" wert.
von spur zu spur positionieren dauert 0.xx ms
wennst sich der lesekopf dann nur in einem kleineren bereich positionieren muss dauerts nicht so lange.
hier die daten einer 7200rpm wdc platte
Seek Times - 8.7 ms (Read); 0.6 ms (Track-to Track); 21.0 ms (Full Stroke)
die 8,7 ist eben nur der "average" wert.
Zuletzt bearbeitet:
underclocker2k4
Mr. Alzheimer
Das ist auch der Grund, warum neuere Platten immer schneller im Zugriff werden.
Auf Grund der höheren Datendichte müssen sie im selben Kapazitätsbereich immer weniger die Köpfe bewegen.
Vergleich 40MB HDD von anno dazumal vs aktuelle HDD, die aktuellen wird den Kopf so gut wir garnet bewegen müssen = kaum accesstime, die alte muß nen full stroke machen um das 1. MB und das letzte MB zu erfassen.
Auf Grund der höheren Datendichte müssen sie im selben Kapazitätsbereich immer weniger die Köpfe bewegen.
Vergleich 40MB HDD von anno dazumal vs aktuelle HDD, die aktuellen wird den Kopf so gut wir garnet bewegen müssen = kaum accesstime, die alte muß nen full stroke machen um das 1. MB und das letzte MB zu erfassen.
Ähnliche Themen
