Hallo, Ich probiere aktuell grad mit iSCSI rum. Laut Literatur sollte iSCSI schneller sein, als z.b. Samba, weil - angeblich - der Overhead deutlich geringer ist. Habe auf einem kleinen Rechner eine Platte drin - die ich via iSCSI als Target zur Verfügung stelle. An einem Windows 7 Rechner kann ich diese Platte auch über iSCSI benutzen ... Beim Zugriff auf die Platte komme ich aber nur auf Transferraten von ca. 50 MB/s (lesend/schreibend). Gebe ich auf dem selben Rechner die selbe Platte aber als Samba-Freigabe frei, dann kann ich darauf mit ca. 90 MB/s zugreifen. Also fast doppelt so schnell - trotz dem langsamen Samba!? (Viel mehr als 90 MB würde fast nicht gehen, weil die Platte nicht viel mehr bringt). Ist das "normal"? Oder übersehe ich da was? Braucht man da irgendwelchen speziellen Einstellungen am Initiator? Auf dem Rechner läuft ein Ubuntu Server 12.04, mit Kernel 3.2. Prozessor ist ein G630T. Als iSCSI Target Daemon habe ich schon tgt, targetcli und LIO probiert ... aber die sind sich von Ergebnis her ziemlich einig. Oder ist iSCSI so "prozessorlastig", dass der G630T das nicht bringt? (Die Load ist sowohl beim Zugriff mit Samba als auch iSCSI "nur" im Bereich von 0.80). danke! Jürgen
Samba ist vergleichsweise langsam, wenn man es alten Version 1 verwendet, also auf Stand XP und Server 2003 und in der Standardeinstellung von Samba. Nicht jedoch die Version 2 mit Win 7 und Server 2008 oder Samba 3.6 mit explizit eingeschaltetem SMBv2. Der CPU-Overhead von iSCSI dürfte schon geringer sein, jedenfalls wenn das Target eine Disk ist und kein Container auf einem Filesystem. In einem isolierten Test, in dem nur ein Client darauf zugreift, wird man den grösseren Anspruch an die CPU aber kaum bemerken. Da müsste man schon mit mehr Masse ran. Andererseits würde mich es nicht wundern, wenn ein direkt auf ein Disk-Volume aufsetzendes iSCSI-Target am RAM-Cache vorbei operiert während ein SMB-Test den Cache nutzt. Womit sich das Ergebnis eines Tests wie hier gezeigt auch umkehren könnte. Was die CPU-Last angeht: Mein Serverlein enthält einen 1,3GHz AMD Dualcore und der kommt auch bei voller Netzlast nicht übermässig ins schwitzen.
Yep, Samba habe ich explizit auf SMBv2 gestellt ... :) Das iSCSI Target hängt direkt an einer Platte - und IMHO ohne RAM Cache (nicht 100% sicher). Auf der anderen Seite habe ich zum Testen extra große Dateien genommen, die nicht (komplett) in den Speicher passen - und die auch noch nie vorher gelesen wurden ... von daher dürfte Samba (beim Lesen) auch kaum vom Cache profitieren können.
Zur CPU-Last: Linux-Linux mit NFS bei 113MB/s (mehr geht in Gigabit nicht) von mdraid-Disk lesend ergibt eine Last von ca. 60% bei angezeigten 800MHz - der Server sieht offenbar keinen Grund, auf 1300MHz hochzutakten.
Es kann auch Unterschiede bzgl. Prefetching geben. Filesysteme entwickeln heute u.U. eine gewisse Eigenintelligenz, was Zugriffsmuster angeht, und sind eher in der Lage, schon vor konkretem Bedarf vorweg zu lesen, als ein einfach gebautes iSCSI-Target das tun wird. Ähnlich kann das bei den Disk-Controllern sein. Echte RAID-Controller mit erheblich Puffer drauf sind ebenfalls auf Zugriffsmuster trainiert, wogegen simple SATA-Controller mit oder ohne RAID-Aufkleber in dieser Hinsicht weniger weit entwickelt sind. Ein iSCSI-Target darf den Schreibzugriff erst dann quittieren, wenn die Daten nicht mehr verloren gehen können, was bei SATA meist bedeutet, dass die sich auf der Platte befinden. Ein Filesystem darf sich anders verhalten und wird die Daten bereits quittieren, wenn sie erst im RAM geparkt sind. Dieser Unterschied ist besonders markant, wenn kein Hardware-RAID mit durch Batterie/Flash abgesichertem Write-Cache verwendet wird.
Generell zu iSCSI vs Samba, insbesondere bei SMBv2: Wenn der Client ein normaler Windows-Rechner ist und die doch ziemlich dürftige Abbildung von Windows-Zugriffsrechen in Samba nicht von Bedeutung ist, dann spricht m.E. nichts für iSCSI. iSCSI kann von Bedeutung sein, wenn SMB keine Alternative ist. Wie beispielsweise als Datastore für VMware ESXi, oder wenn der Store aus Sicht des Clients eine lokale Disk oder eine SAN-Disk sein muss (bei HA-Clustern). Wobei man bei ESXi allerdings auch NFS betrachten sollte.
A. K. schrieb: > Wenn der Client ein normaler Windows-Rechner ist und die doch ziemlich > dürftige Abbildung von Windows-Zugriffsrechen in Samba nicht von > Bedeutung ist, dann spricht m.E. nichts für iSCSI. naja - nen Grund habe ich schon. Ich hätte die Daten auf der Platte gerne verschlüsselt - aber nicht auf Filebasis (über z.b. encfs), sondern wirklich die komplette Platte (ala truecrypt). Zusätzlich - und bitte steinigt mich nicht - hätte ich die Platten gerne in NTFS formatiert (damit man sie notfalls, ohne große Probleme auch an nem normalen Windows PC anstecken kann). Truecrypt und NTFS unter Linux geht natürlich - grad auf nem G630T erwarte ich da aber halt keine Wunder (wobei, ca. 40 MB/s bringt die Kiste mit der Konstelation dann doch auch). Darum war eigentlich dich Idee, die rohen Platten via iSCSI zur Verfügung zu stellen - und dann den Windows Client den harten Rest machen zu lassen (der ist schnell genug). Und ja: Es kommt weder ein (Software) Raid noch ein Hardware-Raid zum Einsatz. Ist ein normaler Low-End Rechner - der als NAS/SAN fungieren soll.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.