Perfomance iSCSI vs. Samba

JüMü Gast #2690805
Lesenswert?
• ▲
▼ 
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
Antwort Zitieren Bearbeiten Thread verschieben Thread sperren Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Beitrag melden
(prx) A. K. #2690809
Lesenswert?
• ▲
▼ 
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.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
JüMü Gast #2690812
Lesenswert?
• ▲
▼ 
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.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
(prx) A. K. #2690820
Lesenswert?
• ▲
▼ 
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.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
(prx) A. K. #2690835
Lesenswert?
• ▲
▼ 
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.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
JüMü Gast #2690852
Lesenswert?
• ▲
▼ 
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.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Thread beobachten

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

Bestehender Account

oder

Mit Google-Account einloggen

Noch kein Account?

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren