Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
NewsIm Test vor 15 Jahren: Fünf RAID-Controller für günstigere SATA-HDDs
Vergiss nicht das Alter der X25, die waren die ersten modernen SATA SSDs, deren Controller war damals revolutionär und was es davor gab waren eher aufgebohrte USB Stick Controller als heutige SSD Controller.
Eben, aber es hatte eben auch einen Grund warum man TRIM eingeführt hat, denn die GC alleine kann nicht alles richten, zumal wenn es nicht viel OP gibt.
Das stimmt ja nun nicht, es ist auch dazu da ein größeres Volumen zu erreichen als mit einzelnen Laufwerken möglich ist und mehr Performance spielt auch oft eine Rolle, gerade auch die seq. Transferraten.
Du vergisst das ein Cache auch verwaltet werden muss und je größer der Cache ist, umso aufwendiger wird diese Verwaltung, so dass die Performance dann wieder fällt, wenn die Hitrate nicht entsprechend steigen kann. Intel sagt sogar, dass 32 bis 64GB Cache das Optimum sind. Es gilt eben nicht: Viel hilft viel. Außerdem wird ein sehr großer Cache irgendwann auch unwirtschaftlich, da das Cachemedium ja pro GB deutlich teurer ist als das welches gecacht wird.
Crass Spektakel schrieb:
RAID5 ist manchmal quälend langsam mit 40MB/s während das gleiche RAID unter Linux mittels dmraid mit 800MB/s läuft....
Die Intel Chipsatz-RAIDs sind extrem performant, wenn Du da solche Unterschiede hattest, dann dürfte die Ursache woanders (Cacheeinstellungen, Virenfinder und andere Dienste die im Hintergrund zugreifen, Filesystem, etc.) gelegen haben, aber mit Sicherheit nicht bei der RAID Lösung selbst.
Ergänzung ()
Cool Master schrieb:
Bei einem (R)AID 0 geht es um wenig Latenz und Speed.
Speed ja, Latenz nein, denn die Latenz kann bei einem RAID niemals geringer sein als bei dem einzelnen Laufwerken, denn es gibt durch die RAID Verwaltung immer einen Overhead, wie insignifikant der auch immer sein mag. Dies sieht in Benchmarks oft anderes aus, weil bei RAIDs meist mehr Cache vorhanden ist, so nutzt auch der RST für RAIDs mehr Cache als für Einzellaufwerke, was ja auch nötig ist, da die Daten ja entsprechend aufgeteilt (beim Schreiben) bzw. beim Lesen zusammengeführt werden müssen und schon von daher mehr Puffer nötig ist. Die meisten Benchmarks laufen nur über einen recht kleinen Adressraum und profitieren entsprechend von dem Cache.
Die Latenz eines jeden RAIDs ist immer schlechter als die der Laufwerke aus denen es besteht, je nachdem wie wie groß diese ist und welche Cachelösung verwendet wird, ist dies aber mehr oder weniger signifikant. Man sieht aber z.B. in den Reviews von Optanes, die ja eine extrem geringe Latenz haben, dann schon deutliche Unterschiede bei den 4k QD1, die zur Anzeige der Latenz von SSDs am Besten geeignet sind.
Kaventsmänner: https://www.google.com/search?q=micropolis+1355 - waren ein Geschenk und für Basteln und Experimente absolut ok. Die Dinger haben beim Anlaufen so viel Strom gezogen dass die Sicherung vom Netzteil geflogen ist. Erst mit Startverzögerung von 20 Sekunden pro Laufwerk kamen sie dann hoch.
Ich hätte auf den ersten Blick damit gerechnet, dass es sich bei den Teilen noch um Laufwerke mit nem MFM-Interface handelt Die hatte mein damals (1993) erster PC (386DX40, 4MB Ram) nämlich noch verbaut und sahen denen verdammt ähnlich. Könnte sogar sein, dass es sich dabei auch um Micropolis Platten handelte... Achja, lang ists her ^^
ich benutze zfs raid z2 mit 3x8 tb in nem proxmox(debian) host
das ist einfach viel besser als das hardware geraffel
und läuft in jedem rechner
snapshots und sharing sind einfach super damit
auch volumes an die container abzugeben ist ne schicke sache
im pc hab ich ne samsung 970 pro ... da braucht es kein raid :-P
Naja, es geht auch um die Kosten. Und da SSDs nicht wirklich billiger werden und Spiele immer größer ist aktuell ein RAID, bei dem eine SSD eine HDD cached, wieder sinnvoller geworden. Zumindest sehe ich das so, denke ich an Intel RST oder AMD StoreMI und FuzeDrive .
Ein Glück, gab es neben diesen ganzen Hilfslösungen doch auch echtes RAID per Steckkarte mit SCSI-HDDs und das schon bis zu 10 Jahre früher. Hab selber noch nen Mylex i960 RAID5 Controller daheim für bis zu 45 HDDs. Mit damals schon fast unerschwinglichen 18.2GB HDDs mit effektiv etwa 16,95GB schaffte man so schon beachtliche Massenspeicher. Nur die Netzteilsuche bei Alternate und Verwandten war zuweilen etwas schwierig. ^^
Bei einer guten JBOD-Implementierung bremsen sich konkurrierende Operationen auf verschiedenen Platten nicht aus. Unter Linux kann man z.B. eine Datei gezielt auf einem Teil-Laufwerk eines JBOD ablegen. Für Datenbanken ist das durchaus nützlich.
Ergänzung ()
Holt schrieb:
Die Intel Chipsatz-RAIDs sind extrem performant, wenn Du da solche Unterschiede hattest, dann dürfte die Ursache woanders (Cacheeinstellungen, Virenfinder und andere Dienste die im Hintergrund zugreifen, Filesystem, etc.) gelegen haben, aber mit Sicherheit nicht bei der RAID Lösung selbst.
Es gibt kein "Chipsatz-RAID" bei Intel, das ist zu 100% ein Software-RAID und vermutlich war es deswegen auch immer so flott. Ganz im Gegensatz zu einigen Silicon-Image und Marvell-Implementierungen, die hatten in der Tat eine kleine Bitshift-Engine für die RAID5-Hammingcodes. Leider war die so lahm dass das gleiche Ding in Software mehrfach schneller war. Gegen die moderne Leistung eines 4Ghz Achtkerners mit MMX, AVX und Co kann diese primitive 33Mhz-Bitshift-Logik mit einem Achtbit-Controller nicht anstinken. Und ob mein Software-RAID jetzt 0,5% oder 0,05% Rechenleistung braucht... who cares? Mir ist es lieber das Ding liefert 4GB/s statt 40MB/s.
Was im Moment bei Intel im Eimer ist ist einfach die komplette Implementierung der Rapid Storage Software. Bei Socket 2011 und 2066 Boards kann man z.B. nicht jeden Port mit jedem anderen Port zu einem RAID zusammenfassen, warum? Kein Ahnung, es macht absolut keinen Sinn. Das Thema wurde sogar mal auf der Linux-dmraid-Liste angesprochen, Kommentar eines Entwicklers: Die Chipsets für Socket 2011 und 2066 verwenden exakt die gleichen SATA-Implementierungen wie Socket 115x. Es gibt lediglich ein paar Register mehr für die zusätzlichen Ports. Dass die Ports sich nicht kombinieren lassen hat keinen technischen Grund, das ist schlicht Pfusch und Desinteresse.
Man kann exakt das gleiche unter Linux mittels md und dmraid machen, es rennt wunderbar, alles runter bis zur Hardware ist perfekt. Der Fehler tritt sogar auf einer frischen Windows-Installation nur mit RAID-Treiber auf die komplett idle ist. Tausende haben den Fehler, Intel ignoriert ihn einfach. Ich gehe davon aus dass mindestens 50% aller Käufer davon betroffen sind.
Besonders gemein, erstelle ich mit Rapid Storage unter Windows ein RAID5-Volume dann ist es unter Windows langsam, mounte ich exakt das gleiche Volume unter Linux dann rennt es sauschnell.
Deshalb nimmt man bei Workstations und Servern echte RAID-Controller und kein GamerBoard mit KillerNIC. Wenn, Dann! Je nach Einsatz muß man sich den passenden Unterbau besorgen. Leider gibt es auch im PC-Bereich keine Eier legende Wollmilchsau.
Bei einer guten JBOD-Implementierung bremsen sich konkurrierende Operationen auf verschiedenen Platten nicht aus. Unter Linux kann man z.B. eine Datei gezielt auf einem Teil-Laufwerk eines JBOD ablegen. Für Datenbanken ist das durchaus nützlich.
Bei Jbod werden die Platten einfach "nacheinander" genutzt. Kommt man über die Speichergrenze der ersten Platte, wird auf die Zweite geschrieben (zumindest unter Windows Software-JBOD). Wenn ich nun RAID0 mache, werden alle Daten zu 50% auf beide Laufwerke aufgeteilt (eben das striping). Wenn ich schon auf Redundanz verzichte, dann aber richtig .
Ps. Mit Chipsatz-RAID ist wohl eber "FakeRaid" gemeint denn Windows braucht halt den vorgegaukelten Controller um davon booten zukönnen. Die Operationen selbst gehen natürlich vom Rapidstoragetreiber im Windows aus.
Ergänzung ()
Mega-Bryte schrieb:
absolutes +1
Ich rede mir auch seit Ewigkeiten den Mund fusselig. Aber die Mehrheit labert irgendwas nach, das gar nicht stimmen kann.
Deshalb nimmt man bei Workstations und Servern echte RAID-Controller und kein GamerBoard mit KillerNIC. Wenn, Dann! Je nach Einsatz muß man sich den passenden Unterbau besorgen. Leider gibt es auch im PC-Bereich keine Eier legende Wollmilchsau.
RAID0 ist halt ein RAID weil es eben striping macht, wie eben RAID5 nur ohne Parität. Das Fehlen der Redundanz soll eigentlich das "0" bei RAID0 zeigen .
Ja, FakeRAID ist einfach grauslig. Selbst Intels RapidStorage"Enterprise" ist echt Müll. Sogar Bluescreens gab es da schon bei uns. Bei kleinem Setup ist man da mit einer Softwarespiegelung im Windows deutlich besser bedient. Vorallem geht dann auch TRIM, SSD-Firmwareupdate und generell die SMART-Werte.
Btw. EMC und andere Dickschiffe haben alle Softwreraid. Hardwareraid wird immer mehr zur Nische. Ich setze es nur ein wenn ich halt größere Arrays brauche die man mit einer SSD nicht mehr abdecken kann, sonst auch mehrere Softwareraid1.
Nein ist es nicht, es ist ein Fake-RAID in dem Sinne das die CPU wie bei einem SW RAID die Arbeit übernimmt, aber es ist nicht unabhängig von der HW wie bei einem SW RAID, weshalb es eben kein 100% SW RAID ist, wie Du ihm fälschlich unterstellst. Man sieht dies auch daran welchen Trick Intel verwendet hat mit dem Intel RST Treiber RAIDs von NVMe SSDs zu realisieren:
Bei Socket 2011 und 2066 Boards kann man z.B. nicht jeden Port mit jedem anderen Port zu einem RAID zusammenfassen, warum? Kein Ahnung, es macht absolut keinen Sinn.
Wenn man nicht verstanden ist das es eben kein reines SW RAID ist, dann macht es keinen Sinn, aber es ist eben kein reines SW RAID und daraus ergeben sich eben technische Limitierungen.
Crass Spektakel schrieb:
Dass die Ports sich nicht kombinieren lassen hat keinen technischen Grund, das ist schlicht Pfusch und Desinteresse.
Keine Ahnung welches Problem Du mit welchemn X299er Board hast, aber der X299 gat ja nur 8 Ports und meines Wissens kann man an allen 8 ein RAID machen. Beim X99 ist es anderes, der hat nämlich intern 2 und nicht nur einen SATA Host Controller enthält, nur an einem kann man ein RAID machen.
Crass Spektakel schrieb:
Man kann exakt das gleiche unter Linux mittels md und dmraid machen, es rennt wunderbar, alles runter bis zur Hardware ist perfekt.
Ja aber eben nur unter Linux, die Windows SW RAID sind bzgl. der Performance eher bescheiden und haben Limitierungen bzgl. der Bootfähigkeiten. Die Linux User verwenden auch heutzutage praktisch nie HW RAIDs, die Windows User aber eben schon und für die ist das Chipsatz RAID auch gedacht. Es gibt ja keine Linux Version des RST, sondern da setzt Intel dann auch auf das md SW RAID und hat dem auch die Kompatibilität zu den Metadaten seiner Chipsatz RAID implementiert, man kann also ein Intel Chipsatz RAID problemlos unter Linux als md RAID verwenden.
echt_jetzt? schrieb:
Bei Jbod werden die Platten einfach "nacheinander" genutzt. Kommt man über die Speichergrenze der ersten Platte, wird auf die Zweite geschrieben
Was eben den Vorteil hat, dass man bei unterschiedlich großen Platten trotzdem deren volle Kapazität nutzen kann, nur dazu macht JBOD (BIG) Sinn, sonst würde ich auch immer ein RAID 0 nehmen, denn bzgl., des Datenverlust bei Ausfall eines Laufwerks sind bei gleich mies, bei JBOD hat man allenfalls etwas bessere Chancen doch noch was zu retten, aber von wichtigen Daten hat man eben immer ein Backup zu haben, nicht nur aber vor allem wenn sie auf einem JBOD oder RAID 0 stehen.
von den dort erwähnten 528MB/s max hab ich nie was gesehen. Bei mir lief der Stapel immer als Raid5 mit HotSpare. Damals mit 1TB der Bringer. 6x250GB. mit Dual Sockel 604 mit zwei XEON 3,2GHz HT
Heute haben wir den abgwrackt und dafür ein Asus ESC700 mit Z9PE-D16 mit zwei E5-2695v2 und 128GB ECCreg RAM aufgestellt. Raid5 jeweils über 3x6TB und 3x1TB plus System und ODD. Rechnet schnell genug!
ich benutze zfs raid z2 mit 3x8 tb in nem proxmox(debian) host
das ist einfach viel besser als das hardware geraffel
und läuft in jedem rechner
snapshots und sharing sind einfach super damit
Ich bin auch kein Freund von "Hardware"-Raids. Zu teuer, zu speziell. Die hier im Test behandelten Controller sind aber Chimären. Die Software ist auf dem Controller verankert, aber ausgeführt wird das von der CPU. Geht der Controller kaputt, muß man einen neuen suchen und hoffen, daß der kompatibel ist.
ZFS ist für einen Fileserver eine prima Sache, auch wegen der Prüfsummen. Bei uns in der Firma verstehen die Admins leider nicht den Unterschied zwischen Fileserver und Datenbank und zwingen jeden dazu ZFS zu benutzen. Der Feind vom ZFS ist paralles Schreiben und Veränderungen bestehender Daten. Es kommt auf Festplatten zu furchtbarer Fragmentierung mit niedrigen Durchsatz und hohen Latenzen.
Da die den ARC-Cache nicht begrenzen, Starten Anwendungen erst beim 3. Versuch, bis das OS genügend RAM freigeräumt hat. Bei I/O-intensiven Aktionen sehe ich 15% User-Last, aber 80% Kernel-Last.
Ergänzung ()
Crass Spektakel schrieb:
Unter Linux kann man z.B. eine Datei gezielt auf einem Teil-Laufwerk eines JBOD ablegen. Für Datenbanken ist das durchaus nützlich.
Das ist für Datenbanken nicht nützlich. In Datenbanken bindet man die einzelnen unabhängigen Laufwerke ein wie sie sind. Innerhalb der Datenbanken gibt es Mechanismen, diese zu großen Volumes/Segmenten zu verbinden.
Bei einem Zugriffen oder Backup kann die Datenbank diese Laufwerke parallel ansprechen. Gaukle ich der Datenbank nur ein großes Laufwerk vor, verzichte ich auf Performance.
Generell geht es bei Datenbanken um jede µs. So soll man sogar den I/O-Scheduler von Linux für das jeweilige Laufwerk auf "noop" setzen, damit nicht Linux noch Rechenzeit einfügt um die Zugriffszeit zu optimieren. Man verzichtet auf jede Art Puffer, Mapping, oder gar Filesystem. Man nutzt direct-i/o und raw-devices.
Einzig Stripesets oder (bei sehr wenigen Schreibzugriffen Raid-5) können bei bestimmten Szenarien sinnvoll sein.
Mega-Bryte schrieb:
Ich rede mir auch seit Ewigkeiten den Mund fusselig. Aber die Mehrheit labert irgendwas nach, das gar nicht stimmen kann.
Diese Raids, die ohne OS funktionieren (einschließlich FakeRaids) haben in meinen Augen den Sinn, das I/O-System unkompliziert einzurichten und mit den Internas vom OS keine Zeit zu verschwenden.
Ich würde das z.B. verwenden, um das OS auf einem Mirror zu installieren. Wie man das Betriebssystem bei z.B. Windows ansonsten mit Bordmitteln machen würde habe ich nie ausprobiert. Funktioniert sicherlich auch, kostet aber wieder Zeit.
Die Controller in Workstations haben gerne größere Latenzen als die Anschlüsse auf den Boards, weil die per PCIe angeschlossen sind. Auf den Boards kommt eine geringe Zahl meist direkt aus der CPU. Wenn ich aber >8 Platten anschließen will oder SAS oder FC nutzen muß, komme ich nicht um solche Erweiterungen herum.
Verfügen diese auch noch über einen batteriegepufferten Schreibcache (und die Platten auch batteriegepuffert) kann das auch besondere Einsatzzwecke haben.
Ich würde das z.B. verwenden, um das OS auf einem Mirror zu installieren. Wie man das Betriebssystem bei z.B. Windows ansonsten mit Bordmitteln machen würde habe ich nie ausprobiert. Funktioniert sicherlich auch, kostet aber wieder Zeit.
Meines Wissens ist es bei Windows nicht möglich das OS komplett redundant auf einem SW RAID einzurichten, was auch logisch ist, denn zumindest der ein Teil der SW (wohl der Bootloader) sowie die Konfigurationsinformationen müssen ja erst geladen werden um das SW RAID einzurichten, erst dann kann auf das SW RAID zugegriffen werden. Bei Chipsatz und anderen Fake-RAIDs umgeht man dies eben.
HP schreibt dazu in den Specs des HP Z Turbo Quad Pro, welches ja auch mit einem SW RAID benutzt werden musst, zumindest bevor VROC eingeführt wurde, was ja erst lange nach dem Erscheinen des HP Z Turbo Quad Pro passiert ist:
@Kowa
ja die mariadb und den mssql ubuntu container habe ich auf ner spare ssd
lxd kann mann ja da auch super snapshotten und ist genauso netzwerk transportabel
die ssd hab ich ultra konservativ auf ext4
leider unterstützen bis jetzt nur die bsds sauber ssd in zfs
Um mal auf ein etwas älteres Thema zurück zu kommen. Bekannter von mir hat einen Server bekommen. Ist keine Neuware, sondern wurde bei ihm im Büro ausrangiert weil es da neue Kraftprotze gab. Nun wollte er (vermutlich darf ich das sogar zu 100% machen) das Teil im Home Office verwenden.
Er hat schon seit Tagen hier und da Ideen und Visionen, was er machen oder einbauen könnte. Seine neuste Idee ist, den Server mit einem separaten RAID Controller auszustatten. Dabei ist mir dann eingefallen, dass hier im Topic schon mal erwähnt wurde das es ja auch gut gebrauchte in der Bucht gibt. Weiß jemand wie es mit diesem 9260CV-8i aussieht, kann man das Teil bedenkenlos bestellen, dort zwei SSDs (irgend eine Samsung Pro) dran hängen und die im RAID 1 laufen lassen?
An den Onboard Controller des HP Servers würde er dann nur HDDs klemmen, oder (weil der zusätzliche RAID Controller genug Anschlüsse hat) die HDDs sogar direkt an den Controller zu klemmen. Uns geht es nur darum, dass es keine Probleme mit dem RAID Controller in Verbindung mit RAID 1 und SSDs gibt
.
.
