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.
Eine eigene Frage?
Dieser Thread ist über 14 Jahre alt.
Stell sie in einem eigenen Thread – dort lesen mehr Leute mit, und sie wird öfter und schneller beantwortet.
