Verplaatsen van data naar iSCSI target onstabiel

[Eagle Creek]

Hi!

Even een kleine situatieschets.

pc
Core i7, 12 GB RAM, Postville, 2x F3 RAID0.
Windows 7 Ultimate

Server
Core i7, 12 GB RAM, 3x F3 RAID10.
- Server draait Hyper-V (2008 R2)
-- Op de Hyper-V server draait Server-01 (2008 R2)
-- Server-01 is de iSCSI-initiator voor de NAS.
--- Server 01 heeft op dit moment 3 cores en 2 GB toegewezen.

NAS
TS-439 Pro II aangemaakt als iSCSI target
Intel Atom D410 1.66 GHz (Single-Core), 1GB DDRII, 128MB (DOM), 4x F3 RAID5.

Alle netwerkkaarten ondersteunen gigabitoverdracht, evenals de switches. Jumboframes (9k) staan op alle apparaten ingeschakeld.

Op het moment dat ik data overzet via de server naar het iSCSI-target, is de snelheid redelijk maar de stabiliteit lijkt te wensen over te laten. De snelheid zakt iets, en de continue transfer zakt.

Onderstaand een uitgebreid overzicht. Toch even een toelichting:

iSCSI benaderen via server
- Transfer vertoont hikken in Taakbeheer
- Snelheid +/- 50 MB/sec, maar de tijdsduur varieert door de drops
- 100% CPU gebruik op de NAS
- Nauwelijks geheugenverhoging op de pc, grote geheugenverhoging op de server (zo'n 800 MB).

Server benaderen, geen NAS involved
- Transfer is stabiel
- Snelheid +/- 75 MB/sec
- CPU-gebruik op alle vlakken normaal (wel gestegen op zowel server als pc)
- Lichte geheugenverhoging op de pc en server

iSCSI direct benaderen via pc
- Transfer is stabiel, maar minder stabiel dan pc - server. Echter stabieler dan pc -> Server -> NAS
- Snelheid is +/- 60 MB (screenshot toont hger, dat klopt niet)
- 100% CPU op de NAS
- Enorme geheugensteiging op de pc. (zo'n 800 - 1000 MB)

Heeft iemand adviezen voor mij om zowel de stabiliteit als de snelheid positief te beïnvloeden, of moet ik dit als normaal beschouwen en zit ik simpelweg met een capaciteitsprobleem?

Daar de server tijdens transfers zo'n 800 MB inneemt (veel trouwens voor mijn gevoel, maar heb ik wel eerder voor zien komen), en deze server zowel AD als DHCP als DNS als file als WSUS voor zijn rekening neemt, ben ik van plan 1 tot 2 GB extra toe te wijzen.

Graag uw advies!

De afbeelding:

[jvanhambelgium]

Kan je eens proberen met alle Jumbo-frames af te zetten ?
Raar maar waar heb ik hier thuis op m'n Ubuntu omgeving problemen gezien met m'n iSCSI van de moment dat m'n Ethernet frame-size afwijkt van de klassieke 1500bytes.

Enkel iSCSI had er last van, de SAMBA fileshare op m'n NAS was perfect benaderbaar.

[Eagle Creek]

Ga ik morgen eens proberen.

Uitsluitend Samba-testen heb ik aan gedacht, maar ben ik vergeten uit te voeren. Zal ik ook gaan doen.

De reden dat ik jumbo inschakelde, was eigenlijk omdat ik las dat het ook het resourcegebruik erg positief kan beïnvloeden (dus weer meer ruimte voor throughput).

[Snow_King]

Als ik zie dat de NAS 100% CPU doet, is dat niet gewoon het probleem? Een Atom 1.6Ghz is namelijk niet zó snel dat ie ook echt Gbit sustained kan verwerken.

[ItsValium]

I agree with Snow_King. De cpu van de NAS is ten allen tijde van de transfers 100% belast zeg je? Dan heb je daar meteen je oorzaak. Als ik een high performance storage omgeving moet bouwen dan komt er minstens een degelijke quadcore (xeon) cpu in de storage bakken. Met voldoende geheugen (eventueel uitbreidbaar wanneer de load groeit) Op die manier ben je verzekerd van een schaalbare oplossing die ten allen tijde gigabit vol kan steken.

Nog een kleine opmerking, als je via je pc over je server naar je NAS gaat, dan halveert je je beschikbare bandbreedte indien je server en NAS communiceren over hetzelfde netwerksegment. Een gouden tip is om je clients en server op een gescheiden segment te houden en je storage over een ander segment te duwen. Ik weet natuurlijk niet of het in jou situatie mogelijk is om dit te realiseren.

[ Voor 30% gewijzigd door ItsValium op 06-02-2010 10:14 ]

[Eagle Creek]

ItsValium schreef op zaterdag 06 februari 2010 @ 10:11:
I agree with Snow_King. De cpu van de NAS is ten allen tijde van de transfers 100% belast zeg je? Dan heb je daar meteen je oorzaak. Als ik een high performance storage omgeving moet bouwen dan komt er minstens een degelijke quadcore (xeon) cpu in de storage bakken. Met voldoende geheugen (eventueel uitbreidbaar wanneer de load groeit) Op die manier ben je verzekerd van een schaalbare oplossing die ten allen tijde gigabit vol kan steken.

Dat is waar mijn vraag "capaciteitsprobleem?" vandaan kwam. Echter: de 100% CPU usage heb ik zowel als ik direct bestanden overzet, als via de server. Direct overzetten is toch sneller, en een stuk minder "springerig".

ItsValium schreef op zaterdag 06 februari 2010 @ 10:11:
Nog een kleine opmerking, als je via je pc over je server naar je NAS gaat, dan halveert je je beschikbare bandbreedte indien je server en NAS communiceren over hetzelfde netwerksegment. Een gouden tip is om je clients en server op een gescheiden segment te houden en je storage over een ander segment te duwen. Ik weet natuurlijk niet of het in jou situatie mogelijk is om dit te realiseren.

Ik snap je niet volledig. De switch kan per poort 1 Gb hebben, maar is in zijn totaliteit ook gelimiteerd tot 1 Gb?
PC --> kabel --> switch --> kabel --> switch --> server
................................................................--> nas

Het is natuurlijk wel zo dat de data met de kabel eerst naar de server gaat, en dan met diezelfde kabel weer terug de NAS in. In het geval met een directe iSCSI aansluiting op de NAS heb ik dat probleem niet.

Zowel de switch als de server hebben een 2e netwerkaansluiting. De server zit echter al op twee netwerken aangesloten, en kan er dus geen kabel meer bij krijgen.
Hypotetisch: Als ik die direct met elkaar doorlink, lost dit dan direct het probleem op, of moet ik dan nog werken met routing-instelling zodat de server snapt dat 'ie poort 2 gebruikt voor communicatie met de NAS?

[ Voor 11% gewijzigd door Eagle Creek op 06-02-2010 12:55 ]

[ItsValium]

zowiezo als je cpu met momenten, of meestal de 100% aantikt dan zal je performance gelimiteerd worden. Die load die je ziet als je via de server naar de nas gaat springt meer omdat de server dan tweemaal een verwerking moet doen (éénmaal inkomend, tweede maal uitgaand) terwijl als je enkel naar de server schrijft hij het enkel éénmaal moet gaan verwerken en wegschrijven doet ie dan op interne storage.

IVM de switch aansluitingen, je hebt het inderdaad juist als je zegt dat de data diezelfde kabel twee maal passeert, net zoals bij je cpu load hij twee keer moet verwerken als je naar de nas schrijft. Vandaar dat het aan te raden is het storage netwerk volledig gescheiden te houden, of door een tweede netwerk kaart of door een aparte switch erbij (of vlan's). Het rechtstreeks linken van je server aan je nas zal werken, gewoon beiden een statisch ip geven. En je zal waarschijnlijk wel al beterschap zien in je performance, maar gezien de cpu een bottleneck is zal dat niet overdreven veel beter zijn dan nu denk ik.

[Eagle Creek]

Klinkt allemaal vrij logisch .

Ik zal wel even kijken wat ik ga doen. Een extra PCI-netwerkkaartje zou de stabiliteit wellicht iets ten goede kunnen komen, maar vooralsnog laat ik het even zo.

Bedankt allen .