Raid 1 oder 5

V

Voltron

Stinker
Hoi Leute,

ich bin gerade am überlegen ob ich mein Raid 1 durch ein Raid 5 ersetzen sollte.

Das Problem ist folgendes:

Ich betreibe auf dem Server 3 Jails, wobei alle 3 koninuierlich auf die Platte schreiben.
Die Jails befinden sich auf eine gbde partition.

Dazu kommt noch ein Qemu, nicht im gbde, mit Linux welches auch permanent läuft und schreibt.


Wenn ich nun etwas kopieren möchte via samba (gbde partition), bekomm ich gerade mal so 4 mb/s

Das System is n aktuelles 7er mit ZFS.



Die Frage ist nun, verbessere ich meine Performance durch ein raid 5 oder ist das vernachlässigbar?

Bin gespannt auf eure Beiträge.

Gruß

Oli
 
Das ganze schreit geradezu nach einen RaidZ1 über mindestens drei Platten. Da du deine Daten dann vom Dateisystem über die drei Platten verteilt bekommst, wird es beim Lesen merklich schneller werden. Schreiben kann ich leider nicht beurteilen, der Theorie nach müsste es aber auch merklich schneller werden.

Ansonsten würde ich statt gbde das teils merklich schnellere geli nehmen und dieses nicht auf die rohen Platten, sondern auch den Zpool anwenden. Ich werde das nächste Woche auch noch genaur in der dann hoffentlich finalen version von wiki.bsdforen.de/zfs beschreiben...

Ach ja, nur als Anmerkung: Wenn du noch nicht hast, würde ich auf RELENG_7 gehen. Da ist der Bug behoben, dass ZFS unter sehr hoher Last das System in eine Panic reißt :)
 
das gbde is in nem zpool drinne.
RELENG_7 hab ich schon drin, aber gepaniced is er trotzdem :(

Raidz1 ok, aber darin funzt doch noch kein gbde, bzw geli oder?
 
Wie hoch ist denn die tatsächliche Schreibgeschwinbdigkeit, die du erreichst?
Also mal singleuser, dann eine verschl. Part. einhängen und Schreibtests machen.

Was hast du für ein Raid? HW oder SW?
 
is n 3ware 9500, hatt ich vergessen zu sagen.

Ich könnte mir auch vorstellen das es an was anderem liegt, ich hatte ein ide platte drin und darauf via samba zugefriffen.
Das kopieren ging auch nicht schneller also von der gdbe partition.
Nächster Test war von USB Platte via USB 2 am server auf die gbde partition, speed war da grad mal 2 mb/s
 
Nene, nicht von ner pysischen Platte aus draufschreiben.
dd if=/dev/null bs=1024 count=1048576 of=/mountpoint_gdbe/test.txt

Mir geht es darum herrauszufinden, ob wirklich das Raid der Flaschenhals ist.
Hast du auf dem Escalade ein BBU und den writecache eingeschaltet?

CU

Martin
 
Also BBU hab ich keine und Writecache ist eingeschaltet.

Naja FTP is nich direkt toll um komfortabel Files aufzurufen, filme u mp3's zb!!
 
Mit Samba kommt man leider kaum auf wirklich hohe Performance. Mehr als kurzzeitige Spitzen von ~30 MB/s bekomme ich jedenfalls nicht hin, selbst mit extra dafür optimierten Einstellungen. Im Durchschnitt sind's sogar <20 MB/s. Und dabei langweilen sich alle beteiligten Komponenten.

Da du Samba einsetzt gehe ich mal von Windows-Clients aus, die du bedienen willst. Du könntest statt FreeBSD für Windows anzupassen auch den umgekehrten Weg gehen und die kostenlosen Services for Unix auf Windows installieren. Da ist ein NFS-Client dabei. Da kommt vielleicht mehr Performance bei 'raus als mit Samba.
 
NFS ist zwar im Allgemeinen schneller als SMB, hat aber den Nachteil, dass es im Prinzip keinerlei Sicherheitsfunktionalität besitzt. Zudem ist es recht unzuverlässig, wenn der Server verschwindet. In diesem Fall kann es auch schon mal zum Absturz kommen. Also keine wirkliche Alternative.

Allerdings geht der ganze Kram am Thema vorbei. Seine Schreibraten sind schlicht ungewöhnlich niedrig und das wird sicher nicht am Datenprotokoll liegen. Ich würde erst einmal weitere Analyse mit bonnie++ vorschlagen und nach den Ergebnissen weitere Entscheidungen treffen.
 
Ja, es ist OT hier, aber mich interessiert's trotzdem. :)
Yamagi schrieb:
NFS ist zwar im Allgemeinen schneller als SMB, hat aber den Nachteil, dass es im Prinzip keinerlei Sicherheitsfunktionalität besitzt.
Zum Vergrößern anklicken....
Ja, leider. Gibt's eigentlich einen Grund, warum es in FreeBSD noch keinen NFSv4-Support gibt?
Yamagi schrieb:
Zudem ist es recht unzuverlässig, wenn der Server verschwindet. In diesem Fall kann es auch schon mal zum Absturz kommen. Also keine wirkliche Alternative.
Zum Vergrößern anklicken....
Naja, man kann den NFS-Mounts ja auch als "tcp,intr" konfigurieren. Wenn dann noch Abstürze auftreten würde ich das nicht pauschal auf NFS schieben, sondern die Ursache eher in der Implementierung des NFS-Clients suchen. Dass der Client irgendwie ausm Tritt kommt, wenn der Fileserver verschwindet ist ja auch mit SMB genau so.
 
Weil der NFSv4-Server noch nicht fertig ist, wird man sich derzeit mit dem Client zufrieden geben müssen. Allerdings vehallt auch jeder Aufruf zum Testen oder nach Hilfe im Nirvana, sodass man sich gar nicht zu wundern braucht, dass es Jahre dauert -_-
Siehe auch: http://snowhite.cis.uoguelph.ca/nfsv4/

Allerdings ist es nicht so, als würde NFSv4 irgendwelche Probleme lösen. Auch ihm liegen längst überholte Designentscheidungen - die NFS schon zu Beginn der 90er den Ruf des "Nightmare Filesystems" eingebracht haben - und die ganzen Sicherheitsproblematiken zu Grunde. Viel sinnvollere wäre es, endlich mal eine wirklich brauchbare Altenative zu entwicklen.
 
Yamagi schrieb:
Weil der NFSv4-Server noch nicht fertig ist, wird man sich derzeit mit dem Client zufrieden geben müssen. Allerdings vehallt auch jeder Aufruf zum Testen oder nach Hilfe im Nirvana, sodass man sich gar nicht zu wundern braucht, dass es Jahre dauert -_-
Siehe auch: http://snowhite.cis.uoguelph.ca/nfsv4/
Zum Vergrößern anklicken....
Danke für die Info.
Yamagi schrieb:
Allerdings ist es nicht so, als würde NFSv4 irgendwelche Probleme lösen. Auch ihm liegen längst überholte Designentscheidungen - die NFS schon zu Beginn der 90er den Ruf des "Nightmare Filesystems" eingebracht haben - und die ganzen Sicherheitsproblematiken zu Grunde. Viel sinnvollere wäre es, endlich mal eine wirklich brauchbare Altenative zu entwicklen.
Zum Vergrößern anklicken....
Das sehe ich auch so. Nur: es gibt irgendwie keine verbreitete NFS-Alternative. SMB hat sich zwar durchgesetzt, aber ich sehe es nicht als NFS-Alternative. Und für AFS interessiert sich ja scheinbar niemand mehr. Also muss man wohl auf absehbare Zeit mit NFS leben und da würde ich es schon begrüßen, wenn NFSv4 in FreeBSD Einzug halten würde. Zumindest solange, bis jemand auf die Idee kommt, die Ansätze von GFS (sehr lesenswertes PDF: http://labs.google.com/papers/gfs.html ) mal in eine freie Implementierung zu stecken, die Chancen hat, in eine BSD oder Linux zu wandern.
 
Ja, leider hast du recht. SMB ist langsam, AFS selbst unter Linux instabil, CODA für große Dateien komplett unbrauchbar... Also auch noch 10 Jahre NFS :(
 
Mir war nicht bekannt das eine BBU zur Performance beiträgt, ist dem so?

hier die benchmark werte, aber schlau werd i da nit drauss
Code: 
%bonnie++ -d /data/daten/test -s 2048 -n 12 -x 2
format_version,bonnie_version,name,file_size,io_chunk_size,putc,putc_cpu,put_block,put_block_cpu,rewrite,rewrite_cpu,getc,getc_cpu,get_block,get_block_cpu,seeks,seeks_cpu,num_files,max_size,min_size,num_dirs,file_chunk_size,seq_create,seq_create_cpu,seq_stat,seq_stat_cpu,seq_del,seq_del_cpu,ran_create,ran_create_cpu,ran_stat,ran_stat_cpu,ran_del,ran_del_cpu,putc_latency,put_block_latency,rewrite_latency,getc_latency,get_block_latency,seeks_latency,seq_create_latency,seq_stat_latency,seq_del_latency,ran_create_latency,ran_stat_latency,ran_del_latency
Writing a byte at a time...done
Writing intelligently...done
Rewriting...done
Reading a byte at a time...done
Reading intelligently...done
start 'em...done...done...done...done...done...
Create files in sequential order...done.
Stat files in sequential order...done.
Delete files in sequential order...done.
Create files in random order...done.
Stat files in random order...done.
Delete files in random order...done.
1.93c,1.93c,bodo.namp.zi,1,1192472318,2G,,33,67,11553,13,4388,3,87,71,16975,5,75.4,7,12,,,,,6312,68,+++++,+++,4550,41,6028,63,+++++,+++,5121,49,2207ms,6639ms,5437ms,2997ms,240ms,881ms,34934us,14531us,691ms,26405us,6910us,342ms
Writing a byte at a time...done
Writing intelligently...done
Rewriting...done
Reading a byte at a time...done
Reading intelligently...done
start 'em...done...done...done...done...done...
Create files in sequential order...done.
Stat files in sequential order...done.
Delete files in sequential order...done.
Create files in random order...done.
Stat files in random order...done.
Delete files in random order...done.
1.93c,1.93c,bodo.namp.zi,1,1192472318,2G,,34,65,11908,12,4177,3,91,72,16430,6,72.7,7,12,,,,,6104,61,+++++,+++,4278,39,5838,61,+++++,+++,4905,47,2448ms,6943ms,10640ms,1546ms,172ms,938ms,31590us,3180us,629ms,30317us,6284us,579ms
%
 
Um auf die ursprüngliche Frage nach dem RAID-Modus zurück zu kommen: Kristian Koehntopp hat mal im Rootforum einen umfangreichen Artikel über Storage gepostet (http://www.rootforum.de/forum/viewtopic.php?t=39965). Der bezieht sich zwar hauptsächlich auf DB-Server, die allgemeinen Erkenntnisse dürften sich aber auch auf Fileserver und Workstations übertragen lassen (abhängig von der erwarteten Schreib-/Lese-Aktivität).
 
ich hab mal iozone laufen lassen

Code: 
bodo# iostat -x 1 5
                        extended device statistics
device     r/s   w/s    kr/s    kw/s wait svc_t  b
da0       93.7 123.7   593.7  1047.3   66  24.9  17
pass0      0.0   0.0     0.0     0.0    0   0.0   0
                        extended device statistics
device     r/s   w/s    kr/s    kw/s wait svc_t  b
da0      247.8 497.6   123.9  4172.8    0  25.1  24
pass0      0.0   0.0     0.0     0.0    0   0.0   0
                        extended device statistics
device     r/s   w/s    kr/s    kw/s wait svc_t  b
da0      461.9 899.8   230.9  7423.5   24   3.5  42
pass0      0.0   0.0     0.0     0.0    0   0.0   0
                        extended device statistics
device     r/s   w/s    kr/s    kw/s wait svc_t  b
da0      1070.6 2108.2   597.3 17370.8  320  46.5  87
pass0      0.0   0.0     0.0     0.0    0   0.0   0
                        extended device statistics
device     r/s   w/s    kr/s    kw/s wait svc_t  b
da0      905.6 1700.6   452.8 13609.0  270  53.5  93
pass0      0.0   0.0     0.0     0.0    0   0.0   0
 
Ich mach noch einen letzten Versuch:

Im Singleusermodus, damit man sehen kann wie schnell auf die verschlüsselten Partitionen geschrieben wird. Das Schreiben auf den verschlüsselten Partitionen ist langsamer als der Zugriff auf die Platte selbst. Daher dieser Test:

dd if=/dev/null bs=1024 count=1048576 of=/mountpoint_gdbe/test.txt


Voltron schrieb:
Mir war nicht bekannt das eine BBU zur Performance beiträgt, ist dem so?
Zum Vergrößern anklicken....

Nein. Das BBU ist für mich nur Grundvorraussetzung write_cache einzuschalten. Und der write_cache macht halt Dampf.
Nur nebenbei, auf ner verschlüsselten Partition auf der wie du sagst dauerhaft geschrieben wird ohne BBU write_cache eingeschaltet zu haben ist etwas leichtsinnig...

CU

Martin
 
@Troll: den Speed Test kann ich momentan nicht machen leider.

Ich vermute aber das es weniger mit dem gbde als mit dem smaba selbst zu tun hat.
Denn wenn ich via Samba von anderen datenträgern aus kopieren möchte, dann is der speed der selbe.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben