Diskussionsthread zu "Raid-Controller und Festplatten" :)

Ein Hardware-Raid kannst du problemlos auf ein anderes Board portieren.
Bei einem Softwareraid geht das nicht so einfach.
Da startet das OS auf dem neuen Board u.U. erst gar nicht...

Die richtig paranoiden legen sich nen zweiten identischen Controller auf Halde falls der in 5 Jahren abraucht und nicht mehr zu bekommen ist.

Nunja, "unseren" Controller können wir ja in 3 Jahren günstig bei ebay schießen und auf Halde legen, für den Fall der Fälle.
 
Ein Hardware-Raid kannst du problemlos auf ein anderes Board portieren.
Bei einem Softwareraid geht das nicht so einfach.
Da startet das OS auf dem neuen Board u.U. erst gar nicht...

Also das Problem sehe ich bei Linux zu allerletzt. Das Board, auf dem eine LiveCD nicht bootet, musst du mir erstmal zeigen. Und wenn du irgendwann mal eins gefunden hast, weise ich dich lediglich dezent darauf hin, dass es noch Unmengen anderer Boards gibt, die garantiert laufen. ;D
 
Was hat denn das mit einer LiveCD zu tun?
Bei uns liegen OS und Datenbank auf einem Raid.

Muss das irgendwann mal auf ein anderes Board umziehen (was dann wohl nen anderen Chipsatz hat) will ich kein Treibergesteuertes Softwareraid haben.

Ne, wirklich nicht.
 
Du komms immer wieder an die Daten ran, wenns sein muss, halt mit ner LiveCD. Ich habe Linux-Installationen schon über mehr als ein Board hinweg umziehen lassen, ist nicht wirklich ein Problem. Auch ein Software-RAID stört da nicht wirklich. Mag ja sein, dass andere Betriebssysteme bei sowas rumzicken. Mit Linux tut sowas nicht weh. ;D
Da ist ein Hardware-RAID mit speziellem Controller viel schlimmer, falls der mal kaputt gehen sollte. Dann kommst du nämlich erstmal nicht mehr an deine Daten ran.
 
Falls nicht ein Treiberupdate das Raid killt, oder falls der Controller plötzlich nicht mehr mit dem neuen Kernel/Treiber läuft...
Oder irgendwas greift auf einen vom Controllertreiber belegten Speicherbereich zu. -> Bumm.

Kommt ja bei Linux schon mal vor das mit neuem Kernel Sachen nicht mehr gehen die vorher gingen...
Da gabs doch mal vor 2-3 Jahren was mit AudioCDs, DMA und Brennern wenn ich mich nicht irre...
;)

Ausserdem:
Im Falle dass das Board stirbt, sollte es schnell gehen. Anderes Board rein, Controller reinstecken wäre das beste. Erst noch mit ner LiveCD die Daten irgendwie vom Raid kratzen nachdem man erst nen funktionierenden Treiber auftreiben muss usw, ist ein viel höherer Aufwand.

Es hat schon seine Gründe warum professionelle Controller ne eigene CPU und RAM haben und warum die SoHo-Teile das nicht haben (müssen).
 
meint ihr jetzt Raid0 und 5 oder?

bei Raid1 wird doch eigentlich 1:1 gespiegelt auch bei Software, was ist da so gefährlich?
 
meint ihr jetzt Raid0 und 5 oder?

bei Raid1 wird doch eigentlich 1:1 gespiegelt auch bei Software, was ist da so gefährlich?
Es geht nicht um verschiedene Raidlevel.

Raids haben allerdings generell das Sicherheitsproblem das sie nicht sicher sind wie viele Denken.
Ein Fehler der sich einschleicht (wegen defektem Ram, Virus usw.) schlägt direkt auf alle Platten durch, also auf das gesamte Raid.

Backup gehört also immer dazu.
 
Falls nicht ein Treiberupdate das Raid killt, oder falls der Controller plötzlich nicht mehr mit dem neuen Kernel/Treiber läuft...
Oder irgendwas greift auf einen vom Controllertreiber belegten Speicherbereich zu. -> Bumm.

Kommt ja bei Linux schon mal vor das mit neuem Kernel Sachen nicht mehr gehen die vorher gingen...
Da gabs doch mal vor 2-3 Jahren was mit AudioCDs, DMA und Brennern wenn ich mich nicht irre...
;)

Also die Argumente sind an den Haaren herbei gezogen. Ein Software-RAID ist unter Linux in Sachen Ausfallsicherheit (Controller, Board) deutlich sicherer als eine Hardware-Lösung, weil man bei einem Software-RAID mit größerer Wahrscheinlichkeit wieder an die Daten kommt.

Was du da mit DMA und CDDA anführst war das Problem von Linux, früher nur bei bestimmten Blockgrößen DMA zu unterstützen. Bei Daten-CDs hat das hingehauen, bei Audio-CDs nicht. Hat nix mit "plötzlich geht nix mehr" zu tun.

Ausserdem:
Im Falle dass das Board stirbt, sollte es schnell gehen. Anderes Board rein, Controller reinstecken wäre das beste. Erst noch mit ner LiveCD die Daten irgendwie vom Raid kratzen nachdem man erst nen funktionierenden Treiber auftreiben muss usw, ist ein viel höherer Aufwand.

Das funktioniert doch aber auch nur, wenn man einen Ersatz-Controller schon liegen hat. Muss man erstmal einen besorgen, steht die Kiste auch erstmal ne Weile. In der Zeit, in der du einen neuen Controller besorgst, bring ich die Installation auf dem Ersatzboard dreimal wieder zum laufen.
(Ja ich weiß, auch das Board will erstmal besorgt sein.)

Es hat schon seine Gründe warum professionelle Controller ne eigene CPU und RAM haben und warum die SoHo-Teile das nicht haben (müssen).

Das hat eher was mit Kostengründen zu tun, und teilweise mit dem Administrationsaufwand. Ausserdem stammt der zusätzliche Prozessor auf der Controller-Karte noch aus der Zeit, in der das zwingend notwendig war, weil die CPU für sowas zu schwach auf der Brust war.
 
Es geht nicht um verschiedene Raidlevel.

Raids haben allerdings generell das Sicherheitsproblem das sie nicht sicher sind wie viele Denken.
Ein Fehler der sich einschleicht (wegen defektem Ram, Virus usw.) schlägt direkt auf alle Platten durch, also auf das gesamte Raid.

Backup gehört also immer dazu.

Das ist doch schon wieder eine ganz andere Baustelle. RAID ist einerseits für einen Geschwindigkeitszuwachs zuständig, und schützt andererseites bedingt vor Datenverlust und Rechnerausfall bei Festplattenausfällen. Alles andere ist nicht Aufgabe eines RAIDs.
 
Das ist doch schon wieder eine ganz andere Baustelle. RAID ist einerseits für einen Geschwindigkeitszuwachs zuständig, und schützt andererseites bedingt vor Datenverlust und Rechnerausfall bei Festplattenausfällen. Alles andere ist nicht Aufgabe eines RAIDs.

Natürlich ist das eine andere Baustelle ich habe Ghostadmin geantwortet.

PuckPoltergeist schrieb:
Also die Argumente sind an den Haaren herbei gezogen. Ein Software-RAID ist unter Linux in Sachen Ausfallsicherheit (Controller, Board) deutlich sicherer als eine Hardware-Lösung, weil man bei einem Software-RAID mit größerer Wahrscheinlichkeit wieder an die Daten kommt.

Was du da mit DMA und CDDA anführst war das Problem von Linux, früher nur bei bestimmten Blockgrößen DMA zu unterstützen. Bei Daten-CDs hat das hingehauen, bei Audio-CDs nicht. Hat nix mit "plötzlich geht nix mehr" zu tun.



Das funktioniert doch aber auch nur, wenn man einen Ersatz-Controller schon liegen hat. Muss man erstmal einen besorgen, steht die Kiste auch erstmal ne Weile. In der Zeit, in der du einen neuen Controller besorgst, bring ich die Installation auf dem Ersatzboard dreimal wieder zum laufen.
(Ja ich weiß, auch das Board will erstmal besorgt sein.)



Das hat eher was mit Kostengründen zu tun, und teilweise mit dem Administrationsaufwand. Ausserdem stammt der zusätzliche Prozessor auf der Controller-Karte noch aus der Zeit, in der das zwingend notwendig war, weil die CPU für sowas zu schwach auf der Brust war.

An den Haaren herbeigezogen ist es mitnichten.
Was ist wahrscheinlicher? Ein Ausfall von Board oder von Controller?
Ich schrieb oben schon das es optimal wäre einen identischen Controller vorzuhalten. Sollten wir vielleicht auch überlegen, aber da kann man schon das kalkulierte Risiko eingehen den vielleicht in 2-3 Jahren günstig irgendwo abzustauben.

Im Dauerbetrieb sind Controller nun mal haltbarer als Boards.


War es nicht so, dass das Brennen von AudioCDs erst eine Zeit lang funktioniert hat und dann mit einer neuen Kernelversion nicht mehr mit DMA, was dann längere Zeit so blieb bis es einige Versionen später endlich gefixt wurde?
Habe mich da nicht so drum gekümmert, nur ein wenig über die Komanndozeilenjunkies gegrinst die mir immer cdrecord als das Nonplusultra anpriesen, aber bei Audiocds immer lecker Bufferunderruns bekamen...
War schon lustig, damals..s
;)
Wird aber langsam OT, glaube ich. ;)
 
An den Haaren herbeigezogen ist es mitnichten.
Was ist wahrscheinlicher? Ein Ausfall von Board oder von Controller?
Ich schrieb oben schon das es optimal wäre einen identischen Controller vorzuhalten. Sollten wir vielleicht auch überlegen, aber da kann man schon das kalkulierte Risiko eingehen den vielleicht in 2-3 Jahren günstig irgendwo abzustauben.

Im Dauerbetrieb sind Controller nun mal haltbarer als Boards.

Ich will mich jetzt nicht mit dir darüber streiten, was länger hält, Board oder Controller. Ich habe keine Daten diesbezüglich, und ohne macht es wenig Sinn zu spekulieren.
Ist aber auch ganz egal, denn es ging ja eigentlich ursprünglich auch darum, dass du einem Software-RAID deine Daten nicht anvertrauen würdest, wegen Datensicherheit, sprich hinterher wieder ran zu kommen. Und da ist halt eine Softwarelösung deutlich besser als ein Hardware-RAID.

War es nicht so, dass das Brennen von AudioCDs erst eine Zeit lang funktioniert hat und dann mit einer neuen Kernelversion nicht mehr mit DMA, was dann längere Zeit so blieb bis es einige Versionen später endlich gefixt wurde?
Habe mich da nicht so drum gekümmert, nur ein wenig über die Komanndozeilenjunkies gegrinst die mir immer cdrecord als das Nonplusultra anpriesen, aber bei Audiocds immer lecker Bufferunderruns bekamen...
War schon lustig, damals..s
;)
Wird aber langsam OT, glaube ich. ;)

Nope, was du meinst ist die leidige Geschichte mit dem ide-scsi Treiber. Damals ging brennen mit ATAPI-Geräten nicht, die wurden über den ide-scsi Treiber angesprochen. Und genau dieses ide-scsi Teil war ein riesiger Würg-Around im Kernel, der eben auch DMA nur mit bestimmten Blockgrößen konnte. Das wurde dann recht großflächig umgekrempelt, und jetzt werden ATAPI Geräte direkt angesprochen, auch beim Brennen.
 
Hm, also ich hab gestern den ICP Vortex Controller installiert und über Nacht erst einmal nochmal mit meinen Windows-Stabilitätstests laufen lassen, um sicher zu gehen, dass der Controller in Ordnung ist.

Allerdings muss ich ganz ehrlich sagen, dass ich von der Performance des Controllers doch ziemlich enttäuscht bin. Hier mal ein Vergleich (beide im Raid-1 unter Windows x64):

Adaptec 29320ALP-R (kein eigener Prozessor, kein eigenes RAM)
HD Tach Burst: 240 MB/s
HD Tach Average: 59 MB/s
HD Tach CPU-Last: 0%
Sandra HDD Index: 65 MB/s

ICP Vortex GDT8514RZ (eigener Prozessor, 128 MB ECC SDRAM)
HD Tach Burst: 125 MB/s
HD Tach Average: 51 MB/s
HD Tach CPU-Last: 3%
Sandra HDD Index: 51 MB/s

Von einem Controller mit eigenem Prozessor und eigenem RAM (und dreifachem Preis) hätte ich doch erwartet, dass er dem Low-Cost Adaptec zumindest ebenbürtig ist :( Ok, sind synthetische Tests, aber trotzdem...

Naja, egal. Zumindest erkennt Linux den ICP Vortex auf Anhieb ;D Jetzt geht's anschließend ans Eingemachte :)
 
Man könnte ja jetzt böse schreiben: "Was erwartest du auch von einem Intel Chip?" ;D

Aber das will ich mal lassen. So wie ich das sehe wirken sich bei den sythetischen Tests einfach zusätzliche Caches eher negativ auf die Performance aus, weil sie entweder a) langsamer als die ohnehin in den Platten integrierte Caches sind oder b) für die Datenmengen der Tests noch zu klein sind. Das lässt mich nur hoffen, dass die P3D Datenbank etwas besser vom zusätzlichen Speicher profitiert.

Ganz und gar nicht erklärlich ist für mich die zusätzliche CPU Last *noahnung*
 
Miss das mal mit IOMeter, der sollte auch realistisch simulieren was auf den Server zukommt.
 
Hm, also ich hab gestern den ICP Vortex Controller installiert und über Nacht erst einmal nochmal mit meinen Windows-Stabilitätstests laufen lassen, um sicher zu gehen, dass der Controller in Ordnung ist.

Allerdings muss ich ganz ehrlich sagen, dass ich von der Performance des Controllers doch ziemlich enttäuscht bin. Hier mal ein Vergleich (beide im Raid-1 unter Windows x64):

Adaptec 29320ALP-R (kein eigener Prozessor, kein eigenes RAM)
HD Tach Burst: 240 MB/s
HD Tach Average: 59 MB/s
HD Tach CPU-Last: 0%
Sandra HDD Index: 65 MB/s

ICP Vortex GDT8514RZ (eigener Prozessor, 128 MB ECC SDRAM)
HD Tach Burst: 125 MB/s
HD Tach Average: 51 MB/s
HD Tach CPU-Last: 3%
Sandra HDD Index: 51 MB/s

Von einem Controller mit eigenem Prozessor und eigenem RAM (und dreifachem Preis) hätte ich doch erwartet, dass er dem Low-Cost Adaptec zumindest ebenbürtig ist :( Ok, sind synthetische Tests, aber trotzdem...

Naja, egal. Zumindest erkennt Linux den ICP Vortex auf Anhieb ;D Jetzt geht's anschließend ans Eingemachte :)

Wie hast du den ICP denn konfiguriert (Cluster-Größe, Cache etc.)? Da kannst du sehr viel verhunzen bzw. rausholen.
 
Hi,

der Write-Cache ist auf Enabled, die Clustergröße ist genau wie beim Adaptec auf 64K
 
Dann sind die Daten in der Tat merkwürdig. Habt ihr auch mal unter Linux gemessen (hdparm, dd, bonnie++, iozone...)?
 
hdparm zeigt 63 MB/s an. Alles andere hab ich unter Linux noch nicht probiert, da mir hier auch die Vergleichswerte fehlen.

Aber momentan ist es auch noch ziemlich egal, da die 4 GB groß genug sind, um die ständig benutzten Files im Cache halten zu können. :) Wenn das irgendwann nicht mehr reicht, kann man immer noch überlegen, ob man aus dem Raid-1 ein Raid-10 macht oder ob es nicht besser wäre, auf 8 GB RAM aufzurüsten.
 
Aber momentan ist es auch noch ziemlich egal, da die 4 GB groß genug sind, um die ständig benutzten Files im Cache halten zu können. :) Wenn das irgendwann nicht mehr reicht, kann man immer noch überlegen, ob man aus dem Raid-1 ein Raid-10 macht oder ob es nicht besser wäre, auf 8 GB RAM aufzurüsten.
MySQL behaelt kaum Daten im Cache und verlaesst sich da auf die FS Puffer. Welche wiederum besorgt sind das alles auf die Platten zu bekommen. Anschliessend werden bei jedem Commit die Buffer geflushed, Ergebnis: Festplattenzugriffe und die relevanten Daten sind nicht im Ram. Nachgeladen wird vor der naechsten Anfrage nichts.

So oder so wirst du um die I/O nicht herumkommen, egal wieviel Ram zur Verfuegung steht.
 
Bist Du Dir da sicher? Nach einem kompletten DB-Search ist der Plattencache satte 3,3 GB groß und wird auch nicht mehr kleiner.
 
Bist Du Dir da sicher? Nach einem kompletten DB-Search ist der Plattencache satte 3,3 GB groß und wird auch nicht mehr kleiner.
...weil keine Commits stattfinden, kann er den ganzen Kram im Ram behalten. Aendert sich etwas, werden die ganzen Daten im Cache nutzlos und fliegen anschliessend raus.
 
Genau das sind auch meine laienhaften Bedenken gegenüber viel Datenmüll im Cach....
Mailwurm meinte hier zwar, daß macht die Datenbanksoftware alles automatisch - aber ich glaube das auch nicht, ich sehe das wie Tom24.

Ramdisk?
Wie oft wird die dann mit der Harddisk abgeglichen? Sagen wir mal alle 5 Minuten, dann müssten alle 5 Minuten 4GB geschrieben werden. Da freuen sich die Platten.
Gleicht man permanent ab, kann man sich das wohl auch aus Performancegründen sparen.
Und wenn doch mal die Kiste abschmiert, warum auch immer, sind alle Daten die in den Zeitraum entstanden sind weg und die Datenbank wahrscheinlich korrupt.
Neeee, das lassen wir mal besser.
Mmmm noch mal ich kleines Licht...

Die Einwände gegen eine RAMDISK sind alle sehr richtig. Folgende Frage/Idee/Einschränkung dennoch: Wenn es sich bei 5GB um eine Datenbank seit Anbeginn von P3D handelt - so ist doch nur ein Bruchteil jünger als 1 Jahr - sagen wir mal ab 31.12.2004. Von diesem Teil würde ich eine Kopie im RAM (RAMDISK) halten. Alle Lesezugriffe (ich schätze mal es sind 75% der Seitenaufrufe + Newsseite) werden von hier aus bedient. Erst wenn ein Post geschrieben wird, wird dieser zunächst schreibend auf dem Raid-Array und anschließend schreibend auf der RAMDISK nötig. Also schreibend ein RAID 1 zwischen HDDs (wie diese auch immer in sich organisiert sein sollten) und der RAMDISK. So kann keine Inkonsistenz aufkommen und selbst bei Stromausfall ist ja alles auf den HDDs. Gibts sowas nicht?

Wenn ich Müll schreibe - einfach ignorieren ;D
 
MySQL behaelt kaum Daten im Cache und verlaesst sich da auf die FS Puffer. Welche wiederum besorgt sind das alles auf die Platten zu bekommen. Anschliessend werden bei jedem Commit die Buffer geflushed, Ergebnis: Festplattenzugriffe und die relevanten Daten sind nicht im Ram. Nachgeladen wird vor der naechsten Anfrage nichts.

So oder so wirst du um die I/O nicht herumkommen, egal wieviel Ram zur Verfuegung steht.

Das ist so nicht ganz korrekt. Erstmal ist es vollkommen ok, wenn sich das DBMS auf den Buffer-/PageCache verlässt, sofern es nicht gerade RawDevices verwendet, was MySQL meines Wissens nach eh nicht kann.
Als nächstes ist der PageCache auch nicht besorgt, alle Daten auf die Platte zu bekommen, um sie dann aus dem RAM zu löschen. Die Daten werden zwar möglichst zeitnah auf die Platte geschrieben, aber deswegen nicht unbedingt aus dem RAM gelöscht. Im Gegenteil der Cache versucht so viele Daten wie möglich im RAM zu behalten, um eben bei Bedarf einen schnellen Zugriff zu ermöglichen.
Schlussendlich hat auch das verwendete Dateisystem ein gewichtiges Wörtchen mitzureden. XFS zum Beispiel cached selber nochmal sehr aggressiv, um kurzlebige Daten erst garnicht auf Platte zu speichern.
Grundsätzlich befinden sich also die Daten, die am häufigsten verwendet werden auch konsequent die meiste Zeit im RAM. In wie weit das nun bei einem DBMS von Vorteil ist, steht auf einem anderen Blatt. Will man da das letzte Ende an Leistung noch rausquetschen, muss man eh zu einem DBMS greifen, welches die Datenverwaltung auf der Platte selber übernimmt, via RawDevices. Das können aber nur die ganz großen Systeme wie Oracle oder DB2, und ist für so was kleines wie so ein WebForum eh nicht notwendig.
 
Genau das sind auch meine laienhaften Bedenken gegenüber viel Datenmüll im Cach....
Mailwurm meinte hier zwar, daß macht die Datenbanksoftware alles automatisch - aber ich glaube das auch nicht, ich sehe das wie Tom24.

Mmmm noch mal ich kleines Licht...

Die Einwände gegen eine RAMDISK sind alle sehr richtig. Folgende Frage/Idee/Einschränkung dennoch: Wenn es sich bei 5GB um eine Datenbank seit Anbeginn von P3D handelt - so ist doch nur ein Bruchteil jünger als 1 Jahr - sagen wir mal ab 31.12.2004. Von diesem Teil würde ich eine Kopie im RAM (RAMDISK) halten. Alle Lesezugriffe (ich schätze mal es sind 75% der Seitenaufrufe + Newsseite) werden von hier aus bedient. Erst wenn ein Post geschrieben wird, wird dieser zunächst schreibend auf dem Raid-Array und anschließend schreibend auf der RAMDISK nötig. Also schreibend ein RAID 1 zwischen HDDs (wie diese auch immer in sich organisiert sein sollten) und der RAMDISK. So kann keine Inkonsistenz aufkommen und selbst bei Stromausfall ist ja alles auf den HDDs. Gibts sowas nicht?

Wenn ich Müll schreibe - einfach ignorieren ;D

Vergiss es. Das ist viel zu aufwändig, weil es erstmal alles per Hand implementiert werden müsste. Ausserdem ist es unnötig, weil siehe mein vorheriger Beitrag. ;D
 
Naja, ich hatte mal mit Banken zu tun, wo über eine von mir projektierte und gewartete Datenbank mit online-banking mehere Mio. Transaktionen pro Tag liefen. In Spitzenzeiten ca. 1000 Transaktionen/sek!
Wir hatten damals dort 40 RAID1 Set's in Betrieb, damit die Performance erreichbar war.
MitRAID 5 war das absolut nicht machbar.

Naja, das kann ich nicht ganz nachvollziehen. Bei uns sind 3 Datenbankserver (HP Proliant DL380) mit je einem RAID5 bestehend aus 3 15000 rpm SCSI-U320 72GB Platten im Einsatz und wir schaffen locker 2000 Queries/Sekunde. Wenn Du natürlich nen billigen RAID-Controller oder was anderes als SCSI nimmst bist Du natürlich selbst schuld.

Glaube mir bitte: Finger weg von RAID 5, ausgenommen als Datenfriedhof im Nurlese-Betrieb oder als Backupdevice.

Unsinn.

thermoman
 
Zurück
Oben Unten