allgemeine RAID Fragen

  • JanR : Danke, dann sind 10 Jahre Berufserfahrung doch nicht ganz umsonst :-)


    pbriesch : iSCSI ist IMHO keine besonders gute idee, aus folgenden Gruenden:
    1. schwierig im Betrieb zu erweitern (aehnlich wie ein physikalisches Laufwerk)
    2. nur an einen Client zu exportieren
    3. Datenkonsistenz beim Backup nur gewaehrleistet, wenn der Client das Laufwerk nicht gemountet hat! (der Filesystem-Cache des Client ist dem Server unbekannt, daher ist ein Backup des iSCSI-Files am Server inkonsistent, wenn der Client das Laufwerk offen hat)
    4. keine Nutzung des OS-Caches des Servers fuer Files im iSCSI-Volume.
    5. schlechtes Verhalten, wenn die Netzverbindung unterbrochen wird (kein Problem bei NFS)


    Generell ist iSCSI eher eine Alternative zu FiberChannel, weniger fuer NFS. Wir setzen im Job iSCSI nur ein, wenn die Applikation auf physikalischen Platten vesteht (beispielsweise Cluster Quorum, oder manche SAP Anwendungen).

    VDR: ASUS AT3ION-T, 2GB, Satix S2 Dual, 1TB 2.5", yavdr 0.4
    Server: Intel DH67CF, Pentium G620, 8GB, 2x1000GB 2.5" Raid1, WLAN, Ubuntu 12.04 @22W
    TV: Panasonic P50G30

    The post was edited 1 time, last by andreash ().

  • Hallo,


    da sich hier ja einige gut mit den RAIDs auskennen hier noch eine Grundsatzfrage:


    Wie groß sollte die chunk-size sein (für große Video-Dateien)?


    Hardy

    Suche: 6 Richtige für die nächste Lottoziehung
    PS: Wer Rechtschreibfehler findet, darf sie behalten!

  • Quote

    Originally posted by HFlor
    Wie groß sollte die chunk-size sein (für große Video-Dateien)?


    Das kann man leider nicht genau sagen. Deshalb ein paar Ideen dazu:


    Ist die chunk Size zu klein, muessen fuer einen gelesenen Datenblock der Anwendung mehrere Platten bemueht werden.
    Ist sie zu gross, werden deutlich mehr Daten gelesen, also unnoetig viele Daten uebertragen.


    Beides ist langsamer als noetig. Als allgemeine Empfehlung ist es durchaus anzuraten, dass die Chunk Size so gewaehlt wird, wie als Default vorgesehen. Ich meine, dass sind 8K. Das ist insbesondere dann gut, wenn man unterschiedliche Anforderungsprofile hat- was ja bei uns ueblicherweise der Fall ist. Die index.vdr ist ja recht klein, wird aber wohl intensiv gelesen. Und meist hat man ja auch noch andere Dateien drauf. Auf keinen Fall sollte IMHO die Chunk Size groesser als rsize/wsize bei NFS mounts sein.


    Ich hatte mal mit 64k Chunk Size gespielt, das war bei mir aber deutlich langsamer.


    Wichtig ist aber, dass beim Formatieren mit ext3 der Stride Parameter entsprechend passt. Weitere moegliche Optimierungen gibt es hier.

    Glotze: yaVDR (ASRock Q1900M, 4GB RAM, DD Cine S2 V6.5, ZOTAC GT630 (Rev. 2)
    Server: HP ProLiant MicroServer G8, VMware ESXi 5.5 :P

  • andreash :


    Danke für Deinen Kommentar bezüglich iSCSI. Für mich bedeutet dies, dass NFS für Linuxsysteme die erste Wahl ist, iSCSI jedoch notwendig ist, wenn ich Windows von einem Server booten möchte (ohne MS spezifische Software $$$ einsetzen zu müssen).

    Server: Raspberry Pi, Acer Aspire easyStore H340, DIGIBIT R1 SAT>IP

    Clients: Hauppauge MediaMVP, Raspberry Pi mit Vomp-Client und SAT>IP, BananaPi Pro, Mele M5


  • Hi Knebb


    Quote

    Original von knebb
    Wichtig ist aber, dass beim Formatieren mit ext3 der Stride Parameter entsprechend passt. Weitere moegliche Optimierungen gibt es hier.

    ´


    Gibt's da irgendwas Analoges auch für das XFS Filesystem ?


    Viele Grüße


    gehlhajo

    VDR-1: streamdev-server | Hummingboard2| TT 3600 USB | Siemens S500 Gehäuse | Archlinux mit eigen Skripten
    VDR-2: streamdev-client | rpihddevice | Raspberry 2b | Siemens S450 Gehäuse| Remote: URC6410 | LG 42LV4500 |
    Archlinux mit eigenen Skripten


  • Quote

    Originally posted by pbriesch
    andreash :


    Danke für Deinen Kommentar bezüglich iSCSI. Für mich bedeutet dies, dass NFS für Linuxsysteme die erste Wahl ist, iSCSI jedoch notwendig ist, wenn ich Windows von einem Server booten möchte (ohne MS spezifische Software $$$ einsetzen zu müssen).


    Naja, ich wuerde die iSCSI Kritik etwas einschraenken wollen. iSCSI hat durchaus Vorteile. Nicht als Ersatz fuer FC, sondern wenn mann es als zentralen Lagerort fuer lokale Festplatten betrachtet (so aehnlich jedenfalls :D).


    iSCSI ist eine Festplatten, die ueber ein anderes Protokoll angesprochen wird (nicht SATA oder IDE, sondern iSCSI). Fertig. In der Tat ist es die falsche Herangehensweise, wenn iSCSI als Netzwerklaufwerk betrachtet wird. Ein Ersatz fuer NFS ist und kann es nicht sein. Gibt man ein iSCSI Volume ueber mehrere Rechner frei, muss man selbst (z.B. durch ein geeignetes Dateisystem) sicherstellen, dass es keine Zugriffsprobleme gibt.


    @gelhajo:
    Soweit ich weiss, ist das eine Besonderheit von EXT2/3. Kenne kein anderes Dateisystem, dass einen solchen Parameter benoetigt.

    Glotze: yaVDR (ASRock Q1900M, 4GB RAM, DD Cine S2 V6.5, ZOTAC GT630 (Rev. 2)
    Server: HP ProLiant MicroServer G8, VMware ESXi 5.5 :P

    The post was edited 1 time, last by knebb ().

  • Quote

    Original von gehlhajo
    Hi Knebb


    ´


    Gibt's da irgendwas Analoges auch für das XFS Filesystem ?


    XFS macht das automatisch, falls es die Parameter vom Device erfragen kann. Das klappt bei LVM leider nicht.


    man mkfs.xfs:
    "When a filesystem is created on a logical volume device, mkfs.xfs will automatically query the logical volume for appropriate sunit and swidth values."


    Ansonsten gibts einige Anleitungen im Netz, wie man das manuell setzen kann (ich habs bleiben lassen)


    [edit] Der Wert ist sowieso irrelevant, wenn man die Anzahl der Raid-Devices spaeter mal erhoeht. Da wirds mit der Planung schon interessant...

    VDR: ASUS AT3ION-T, 2GB, Satix S2 Dual, 1TB 2.5", yavdr 0.4
    Server: Intel DH67CF, Pentium G620, 8GB, 2x1000GB 2.5" Raid1, WLAN, Ubuntu 12.04 @22W
    TV: Panasonic P50G30

    The post was edited 1 time, last by andreash ().

  • Quote

    Original von JanR
    Und wenn wir gerade dabei sind... habt ihr fuer eure Monster-RAIDs auch an Disc-Scrubbing gedacht (Folie 29)? Das ist gerade bei Videos, die man vielleicht nur selten schaut, sehr wichtig, da viele Plattenfehler erst beim ZUGRIFF festgestellt werden koennen und somit jahrelang unbemerkt bleiben und erst beim Syncen nach dem Ausfall einer ANDEREN Platte auftauchen. Ohne Scrubbing ist die Wahrscheinlichkeit eines Doppelfehlers sehr viel hoeher, als man das allgemein so glaubt.


    "Monster-RAIDs" :-)


    Fuers Protokol: Debian installiert mit dem mdadm-Package ein Script /etc/cron.d/mdadm, das einmal monatlich ein Srubbing auf allen md-Arrays durchfuehrt.

    VDR: ASUS AT3ION-T, 2GB, Satix S2 Dual, 1TB 2.5", yavdr 0.4
    Server: Intel DH67CF, Pentium G620, 8GB, 2x1000GB 2.5" Raid1, WLAN, Ubuntu 12.04 @22W
    TV: Panasonic P50G30

  • Hallo Jan,


    Quote

    Original von JanR
    Und wenn wir gerade dabei sind... habt ihr fuer eure Monster-RAIDs auch an Disc-Scrubbing gedacht (Folie 29)? Das ist gerade bei Videos, die man vielleicht nur selten schaut, sehr wichtig, da viele Plattenfehler erst beim ZUGRIFF festgestellt werden koennen und somit jahrelang unbemerkt bleiben und erst beim Syncen nach dem Ausfall einer ANDEREN Platte auftauchen. Ohne Scrubbing ist die Wahrscheinlichkeit eines Doppelfehlers sehr viel hoeher, als man das allgemein so glaubt.


    Ich habe auf meinem Test-RAID6 mal auf eine Platte mit dd einen Bereich mit Nullen überschrieben, und die o.g. Kontrolle gestartet.
    Nach dieser Kontrolle ist folgendes im log zu finden:


    Code
    1. md: data-check of RAID array md6
    2. md: minimum _guaranteed_ speed: 1000 KB/sec/disk.
    3. md: using maximum available idle IO bandwidth (but not more than 200000 KB/sec) for data-check.
    4. md: using 128k window, over a total of 41942976 blocks.
    5. md: md6: data-check done.

    Die Platte enthielt danach immer noch die Nullen in dem überschriebenen Bereich.
    Nach einem Entfernen und Hinzufügen (resync dieser Platte) waren die Nullen dann weg.



    Also wozu einen check, wenn der keine Fehler findet? Einen reinen Plattentest kann ich mit smartctl anstossen.


    Hardy

    Suche: 6 Richtige für die nächste Lottoziehung
    PS: Wer Rechtschreibfehler findet, darf sie behalten!

  • Quote

    Original von andreash


    XFS macht das automatisch, falls es die Parameter vom Device erfragen kann. Das klappt bei LVM leider nicht.


    Alles kla,r vielen Dank an Dich und knebb...

    VDR-1: streamdev-server | Hummingboard2| TT 3600 USB | Siemens S500 Gehäuse | Archlinux mit eigen Skripten
    VDR-2: streamdev-client | rpihddevice | Raspberry 2b | Siemens S450 Gehäuse| Remote: URC6410 | LG 42LV4500 |
    Archlinux mit eigenen Skripten


  • Hi,


    Quote


    Die Platte enthielt danach immer noch die Nullen in dem überschriebenen Bereich.
    Nach einem Entfernen und Hinzufügen (resync dieser Platte) waren die Nullen dann weg.



    Also wozu einen check, wenn der keine Fehler findet? Einen reinen Plattentest kann ich mit smartctl anstossen.


    Ueberaus seltsam... das DARF eigentlich nicht sein, auch sowas MUSS erkannt werden. Wenn ich demnaechst mal wieder Zeit habe, baue ich das mal in einer VMWare nach und teste das (fuer RAID1 und RAID5... RAID6 hast du ja schon getestet)... mein grosses RAID5 will ich da lieber nicht als Versuchskandidat nehmen, da es dann zumindest zeitweise seine Redundanz loswird).


    Viele Gruesse,


    Jan

    Hardware: ASRock AM2NF3-VSTA + AMD Sempron 3200+ (1,8 GHz, meist 1,0 GHz) mit Fujitsu Siemens DVB-C FF (ohne Kabelsignal), 2 x TechniSat AirStar 2 DVB-T PCI und Terratec Cinergy T2 DVB-T USB 2.0 (als IR-Empfaenger ohne Antenne), Pollin 27x4 LCD, 1 GB DDR2, diskless, /video ueber NFS
    Software: Gentoo Linux 64 Bit (Kernel 2.6.24) mit VDR 1.4.7 aus den ebuilds mit einigen manuellen Anpassungen und wenigen Plugins (femon, dvd, remote, lcdproc)

  • Hi,


    hab gerade noch ein wenig mit HFlor hin-und hergePNt, wobei mir was auf- bzw. eingefallen ist: Solche Fehler KANN das RAID prinzipbedingt nicht abfangen bzw. korrigieren. Anzeigen sollte es sie (es zaehlt wohl auch einen Missmatch-Count hoch), aber mehr kann nicht passieren.


    Der Punkt bei einem RAID ist naemlich, dass die Funktion darauf basiert, dass durch das Verhalten der Platten absolut klar ist, WELCHE Platte kaputt ist. Das wird erkannt, indem eine Lese- oder Schreiboperation schiefgegangen ist. DAS ist der Trigger, nichts anderes. Andere Fehler sind durch ein paritaetsbasiertes Verfahren nicht behebbar, weil der Fehler nicht lokalisiert werden kann.


    Nehmen wir einfach mal an, wir haben ein RAID1 (da wird es auch passieren... HFlor hat es zumindest bei RAID5 auch gesehen. RAID1 ist ein Spiegel, wir haben also zweimal das gleiche auf den Platten. Jetzt ueberschreiben wir eine per DD und aendern ein bisschen was. Jetzt sind sie nicht mehr gleich und ein Check wird das auch sehen - fragt sich nur, wie er es genau protokolliert (in jenem Counter, vielleicht kommt auch mehr ins Log... werde ich mal versuchen). Problem fuer den Check ist nur, dass es ZWEI Datensaetze gibt, die unterschiedlich sind... welcher ist korrekt? Es koennen beide sein!


    Hat jedoch eine Platte kaputte Sektoren oder so, dann gibt es bei Scrubbing an der Stelle einen Lesefehler -> voila. Nur DAS wird vom RAID abgefangen, keine Datenaenderungen auf den Platten OHNE gleichzeitigen Lese- oder Schreibfehler. Eine Datenverfaelschung auf dem Medium hingegen fuehrt beim Lesen zum CRC-Fehler und der zum Lesefehler, nur kann man das nicht simulieren, denn alles, was man schreibt, wird ja auch geCRCt. Von daher ist das quasi ein Test, der etwas testet, was normal nicht passieren kann durch sterbende Platten.


    Beim Scrubbing geht es aber eben um schleichende Lesefehler auf Platten, die man sonst nicht bemerkt. Stellen wir uns vor, wie klatschen einen grossen Film auf unser RAID und schauen den erstmal nicht mehr an. Monate spaeter setzt genau an einer der Stellen, die dazugehoeren, beim Positionieren einer der Koepfe mal kurz auf und schaedigt die Oberflaeche EINER Platte. Da das keine Lese/Schreiboperation war, gibt es keinen Fehler. Da wir den Film NIE lesen, merkt auch keiner den Fehler und das RAID bleibt intakt. Jahre spaeter stirbt eine zweite Platte, das RAID trennt die Platte ab und will eine neue. Wir bauen die ein, resync... BUMM. Genau dafuer ist Scrubbing da... eine kaputte Platte durch komplettes Lesen zu erkennen.


    Quote


    Einen reinen Plattentest kann ich mit smartctl anstossen.


    Das geht auch, man kann auch einfach ein dd if=/dev/mdX of=/dev/null ueber das RAID laufen lassen. Egal wie... Fakt ist, dass man alles lesen muss, um sowas auszuschliessen.


    Hoffe, obige Ueberlegungen sind verstaendlich geschrieben und klaeren, warum ein RAID das Ueberschreiben von Plattenbereichen nicht sinnvoll beheben kann und auch nur seltsam erkennt (eben weil es im Fehlermodell nicht vorkommt).


    Viele Gruesse,


    Jan

    Hardware: ASRock AM2NF3-VSTA + AMD Sempron 3200+ (1,8 GHz, meist 1,0 GHz) mit Fujitsu Siemens DVB-C FF (ohne Kabelsignal), 2 x TechniSat AirStar 2 DVB-T PCI und Terratec Cinergy T2 DVB-T USB 2.0 (als IR-Empfaenger ohne Antenne), Pollin 27x4 LCD, 1 GB DDR2, diskless, /video ueber NFS
    Software: Gentoo Linux 64 Bit (Kernel 2.6.24) mit VDR 1.4.7 aus den ebuilds mit einigen manuellen Anpassungen und wenigen Plugins (femon, dvd, remote, lcdproc)

  • Quote

    Original von Dirk


    Deshalb richtet man es auch so ein, das dem Admin beim (evtl. auch drohenden) Ausfall eine eMail geschickt wird. (stichwort -> smartmontools)


    Mdadm kann auch programme ausführen wenn ein fehler auftritt.
    Das schickt mir den fehler dann per SVDRP MSG direkt auf den bildschirm.
    Da schau ich häufiger drauf als in meine e-mails ...
    :unsch


    Wegen der syncronisation hab ich bei mir nur je 20GB pro platte als RAID5.
    Da dauert der sync schon lang genug.
    Videos eben ungesichert aber manuell jeweils auf einer platte zusammengepackt. Was weg ist ist dann eben weg und kein gejammer mehr über teilweise reste wegen VDR plattenverteilung. :lol2


    Peter

    Mein anderer VDR ist (auch) ein EPIA
    1)VIA M10000-Nehemiah, 160+120G Samsung; NEC 1300A; YY A106; LCD20x4 ...
    2) ctvdr+e-tobi ; C3M266+1,2GHz-Nehmiah; 160G Samsung + 4x500G Seagate SATA; NEC3500; TT-Case; DVB-S 1.3+4MB + Nova ; gLCD 240x128 ...
    . . .TB rulez. . .

    The post was edited 1 time, last by PeterD ().

  • Hi,


    Quote


    Da dauert der sync schon lang genug.


    An der Stelle unterscheiden sich zumindest in der Haeufigkeit die Kernelversionen (nach deiner Sig hast du noch 2.4.x im Einsatz). Bei 2.4.x hat es gereicht, den Rechner hart auszuschalten bzw. dass dies im Rahmen eines Absturzes oder Stromausfalls passiert, damit hinterher ein Raid-Resync stattfindet. Das ist bei 2.6.x nicht mehr so. Ausschalten oder Komplettabsturz des Systems fuehrt im Normalfall nicht zum Resync.


    Von daher sind die Resync-Zeiten bei 2.6 deutlich unwichtiger, weil sie wesentlich seltener auftreten.


    Mein grosses 1,7 TB-Raid5 (3 Partitionen von etwa 900GB) braucht ungefaehr 2...2,5 Stunden zum kompletten Synchronisieren mit knapp ueber 100 MB/s (ohne parallele Zugriffe, sonst laenger). Finde ich fuer die Groesse eigentlich okay... aber das geht natuerlich nur bei neueren SATA-Platten und einem entsprechend schnellen Board.


    Viele Gruesse,


    Jan

    Hardware: ASRock AM2NF3-VSTA + AMD Sempron 3200+ (1,8 GHz, meist 1,0 GHz) mit Fujitsu Siemens DVB-C FF (ohne Kabelsignal), 2 x TechniSat AirStar 2 DVB-T PCI und Terratec Cinergy T2 DVB-T USB 2.0 (als IR-Empfaenger ohne Antenne), Pollin 27x4 LCD, 1 GB DDR2, diskless, /video ueber NFS
    Software: Gentoo Linux 64 Bit (Kernel 2.6.24) mit VDR 1.4.7 aus den ebuilds mit einigen manuellen Anpassungen und wenigen Plugins (femon, dvd, remote, lcdproc)