iSCSI thuis

[axis]

Verwijderd schreef op zondag 01 maart 2009 @ 13:52:
[...]

Is er inmiddels al een ruimere keuze aan (gratis/goedkope) iSCSI targets voor Windows? Ik zat gisteravond even dit topic door te lezen en zag er 1 die nog steeds RC1 is en een andere waarbij erg veel restricties gelden voor de gratis versie. Is er inmiddels ook een Windows target dat goedkoop is en zonder restricties?

Geen ervaring met windows targets.. je zou eens kunnen kijken naar http://www.rocketdivision.com/download_starwind.html, zo te zien hebben die ook een gratis versie.

[Verwijderd]

Ja, die bedoelde ik dus toen ik het had over het programma met veel restricties. De restrictie van 2 GB is natuurlijk redelijk beperkend...

Edit:

Dit ziet er ook wel goed uit:

http://www.kernsafe.com/Product.aspx?id=5

(een nog ander Windows target is iSCSI Cake (laatste versie (1.7) van eind 2008), maar die site lijkt het niet meer te doen)

===

En over het integreren van iSCSI win Windows Server (dit was nog een andere Windows target implementatie (WinTarget)):

http://www.microsoft.com/...wsreviews/stringbean.mspx

[ Voor 69% gewijzigd door Verwijderd op 01-03-2009 17:45 ]

[Verwijderd]

Nog 2 linkjes over Windows targets:

http://www.nullsession.co...s-microsoft-iscsi-target/

http://www.softpedia.com/...rver-Download-105604.html

De 1e noemt nog een paar alternatieven voor Windows en op de 2e is het MS target te vinden.

[DiedX]

Zeer interessant. Ik wil binnenkort eens kijken wat FreeBSD 7 doet met oude schijven en ZFS. Vervolgens dat maar eens ontsluiten via iSCSI

[daan08]

Ik gebruikte tot voor kort hier een XP server met Rocketdivision Starwind en Starport op de clients. Werkte prima zoveel beter dan standaard file sharing. Nu is het echter van de ene op de andere dag niet meer functioneel moet nog uitzoeken waarom. Op het werk FreeNAS icm GlobalSAN (beiden freeware) op iMacs, geen problemen.

[axis]

DiedX schreef op maandag 02 maart 2009 @ 23:13:
Zeer interessant. Ik wil binnenkort eens kijken wat FreeBSD 7 doet met oude schijven en ZFS. Vervolgens dat maar eens ontsluiten via iSCSI

Hetzelfde als met nieuwe schijven, alleen langzamer
ZFS wordt trouwens wel streng aangeraden op 64-bit ipv 32-bit, ivm geheugenallocatie en -fragmentatie (ook al heb je minder dan 4GB ram).

Ik heb trouwens ook 32-bit machines met ZFS in productie, maar als je het dan heeel gek maakt (meerdere streams compressen @100% cpu, flink rsyncen etc, wil er nog wel eens een kernel panic tussendoor komen.

Voor thuis, of voor iSCSI zal het niet zo'n vaart lopen. Elke iSCSI backend is toch maar een enkele file met een enkele client

[Verwijderd]

Wat helemaal leuk is aan iSCSI is dat je er ook van kan booten... En als je het geluk hebt om een Intel PCI-e server adapter (goedkoopste kost ca. 70 euro) in je compu te hebben zitten heb je er verder helemaal niets voor nodig. Erg elegant; een aantal diskless clients die allemaal van een eigen kleine iSCSI partitie booten.

Ik had nog wel even een vraag. Ik heb gisteren wat zitten spelen met Kernsafe iStorage en Starwind. Nu viel me daarbij op dat ik allerlei verschillende files/partities/devices kan kiezen waar het target naar wijst. Vanavond even naar het MS target (WinTarget, zie mijn eerdere link hierboven) gekeken, daar lijkt het erop dat je alleen maar een file (.vhd) kan kiezen.

Is dit echt een beperking van het MS target? Of zie ik iets over het hoofd?

[Verwijderd]

En hier nog een (naar het schijnt) goed artikel:

http://virtualgeek.typepa...stomers-using-vmware.html

[SeuTjai]

Laatst zijn we ook bezig met ISCSI, alleen lukt dit niet zo, ik heb hier heel lang aan gezeten, ik hoop dat iemand mij verder kan helpen.

Op school hebben wij een project opgezet, wij waren van plan om te clusteren (failover).
Om dit te kunnen doen, moeten we een storage aanmaken dat voor alle nodes bereikbaar zijn.
Wij willen dit doen met ISCSI. aangezien op onze school de computers beveiligt zijn, draaien we alles virtueel.
We maken gebruik van VMware Server (1.0.7), daarop hebben Windows server 2003 Enterprise geïnstalleerd, 2 nodes en als 1 Storage met ISCSI.

Op de Storage hebben we een ISCSI Target geïnstalleerd, en de schijven toegevoegd en (CHAP) rechten gegeven.

Op de Node heb ik de Initiator geïnstalleerd van MS, bij Target Portal proberen toe te voegen.
Alleen, moet ik geen CHAP authentication invullen, anders krijg ik een foutmelding en staat er bij Targets helemaal niks.
Als ik de CHAP niet invult, krijg ik bij Target wel de ISCSI schijven, als ik deze individueel aanmelden, dan zijn ze verbonden.

Hierna heb ik begrepen dat de ISCSI schijven nu toegevoegd moet zijn in Disk Management, alleen is dit niet gebeurt bij ons, wij hebben heel veel geprobeerd, maar het is niet gelukt.

Wij hebben dit van een boek en diverse sites gevolgd, maar niks schijnt te werken.

Hebben we iets over het hoofd gezien? of hebben we iets verkeerd gedaan?

alvast bedankt.

[Verwijderd]

SeuTjai,

Overlaatst heb ik met een gelijkaardig probleem te maken gekregen.
Het gaat over een two-node failover cluster (Microsoft Windows Server 2008) op een VMware ESXi omgeving.
Ik had mijn schijven op de lokale storage aangemaakt met de thick option, dit wil zeggen dat de schijven kunnen gedeeld worden tussen verschillende servers (virtuele weliswaar).
Als ik mijn disk management ging kijken, dan zag ik op beide servers -gelijktijdig- de gepresenteerde schijven. Toch kreeg ik een foutmelding bij de clustervalidatie waarbij hij me zei dat hij geen geschikte schijven kon vinden die konden gebruikt worden als quorum/witness. Na wat zoeken bleek dat windows server 2008 SCSI-3 moet hebben of hij wil niet verder gaan. Dit probleem kan omzeilt worden door te werken met scsi initiators.

Ik heb hier zonet wat zitten zoeken en heb toch een interessante link gevonden.. http://www.minasi.com/forum/topic.asp?TOPIC_ID=17981. Ik weet niet hoe het juist zit met VMware server, maar in ESX moet je je SCSI-device op shared zetten..

Het zou alleszins interessant zijn, moest je je oplossing posten voor andere mensen..

[Verwijderd]

Verwijderd schreef op maandag 02 maart 2009 @ 23:41:
Wat helemaal leuk is aan iSCSI is dat je er ook van kan booten... En als je het geluk hebt om een Intel PCI-e server adapter (goedkoopste kost ca. 70 euro) in je compu te hebben zitten heb je er verder helemaal niets voor nodig. Erg elegant; een aantal diskless clients die allemaal van een eigen kleine iSCSI partitie booten.

En wat nog mooier is: als die diskless clients allemaal hetzelfde OS draaien kan je het eerste image met ZFS clonen en neemt het bijna geen extra ruimte in. Zie:

http://blogs.sun.com/cons...try_out_virtualbox_on_zfs

[SeuTjai]

Verwijderd schreef op dinsdag 10 maart 2009 @ 23:36:
SeuTjai,

Overlaatst heb ik met een gelijkaardig probleem te maken gekregen.
Het gaat over een two-node failover cluster (Microsoft Windows Server 2008) op een VMware ESXi omgeving.
Ik had mijn schijven op de lokale storage aangemaakt met de thick option, dit wil zeggen dat de schijven kunnen gedeeld worden tussen verschillende servers (virtuele weliswaar).
Als ik mijn disk management ging kijken, dan zag ik op beide servers -gelijktijdig- de gepresenteerde schijven. Toch kreeg ik een foutmelding bij de clustervalidatie waarbij hij me zei dat hij geen geschikte schijven kon vinden die konden gebruikt worden als quorum/witness. Na wat zoeken bleek dat windows server 2008 SCSI-3 moet hebben of hij wil niet verder gaan. Dit probleem kan omzeilt worden door te werken met scsi initiators.

Ik heb hier zonet wat zitten zoeken en heb toch een interessante link gevonden.. http://www.minasi.com/forum/topic.asp?TOPIC_ID=17981. Ik weet niet hoe het juist zit met VMware server, maar in ESX moet je je SCSI-device op shared zetten..

Het zou alleszins interessant zijn, moest je je oplossing posten voor andere mensen..

Bedankt voor je bericht,

Maar ik denk dat onze probleem niet echt te maken hebt met de jouwe, want in de Disk Management krijg ik helemaal niks te zien, terwijl we elkaar kunnen pingen en dat de disk bij de Initiator als connected aangeven zijn. Heel raar.

Maar bedankt voor je informatie en website, miscchien moeten we ook de scsi op shared zetten.
Hoe dan ook, ik heb vrijdag weer school, dan pas even verder proberen.

thnx

[SeuTjai]

Nou het is helaas niet gelukt met VMware, wel was dit gelukt met Virtual PC, we kregen de schijven te zien bij disk management, maar het rare is, dat we op 2 verschillende clients de schijven wel zien, maar dat het niet automatisch synchroniseerd, als ik bij de 1e client een nieuw bestand aanmaakt, dan ziet ik bij de 2e client die nieuwe bestand niet.
Maar wel als ik het opnieuw aanmeld (met initiator).

Is het de bedoeling dat ze vanaf beide computers zien en tegelijketijd alle veranderingen zien?
Of is het de bedoeling dat je voor een fail over clustering gebruikt, wanneer de een uitvalt, dan dat de andere server geactiveerd word en bij de iscsi connect word?

[Liam]

DiedX schreef op maandag 02 maart 2009 @ 23:13:
Zeer interessant. Ik wil binnenkort eens kijken wat FreeBSD 7 doet met oude schijven en ZFS. Vervolgens dat maar eens ontsluiten via iSCSI

Nou, ik heb het nu werkend onder FreeBSD 7.1 op een sparc64, en ik moet zeggen, het werkt, maar af en toe komen er toch wazige errors voorbij, waarbij ik de oplossing zo 1-2-3 niet heb. Ik gebruik deze iscsi-target-20080207_2.

Ik moet zeggen, over de performance heb ik niets te klagen. Ik haal op mijn oude 9.1GB 10k schijf (doet even dienst om diskspace aan te bieden) ongeveer 27MB/s, en dat is denk ik wel zo'n beetje de max van de schijf. Ik heb de hele handel met gigabit aan elkaar geknoopt en in een apart StorageVLAN gezet, en dat loopt prima.



Ik zit alleen een beetje met de security, ik gebruik nu een ACL die de toegang tot het StorageVLAN fixed, maar in principe hebben geen van de clients er wat te zoeken (ik heb nu twee servers interconnected).

Nu wil ik echter ook eens spelen met diskless clients. Hoe gaan we dat nou voor elkaar krijgen met een fatsoenlijke security. Een beetje met CHAP inloggen op je target, maar dat is nou ook niet echt om over naar huis te schrijven, want je data zelf gaat gewoon unencrypted over de lijn. Iemand een idee?

[ Voor 2% gewijzigd door Liam op 23-03-2009 01:03 . Reden: Plaatje geadd met performance ]

[Verwijderd]

Liam schreef op maandag 23 maart 2009 @ 00:58:
Nu wil ik echter ook eens spelen met diskless clients. Hoe gaan we dat nou voor elkaar krijgen met een fatsoenlijke security. Een beetje met CHAP inloggen op je target, maar dat is nou ook niet echt om over naar huis te schrijven, want je data zelf gaat gewoon unencrypted over de lijn. Iemand een idee?

Eens voor booten, maar daarna kan je het toch via SSH laten lopen?

[spone]

iSCSI is niet opgezet voor echte security, net als dat je op je gewone SCSI kabels geen wachtwoord hebt zitten Normaal gesproken hang je niet direct via iSCSI je clients aan een server, maar zijn servers via een storage-netwerk (SAN) verbonden en serveren ze die data via een LAN naar de clients. Op dat laatste punt wordt security een aandachtspunt.

@grizzly: SSH voor ~50MB/sec aan gegevens? Ik weet niet of ik medelijden met de client of de server moet hebben wanneer er zoveel gegevens tegelijk encrypted over de lijn moeten . Zijn we bijna weer terug in het PIO-tijdperk, waar de processor zich bezig moest houden met alle disk-access.

[ Voor 29% gewijzigd door spone op 23-03-2009 01:12 ]

[Liam]

spone schreef op maandag 23 maart 2009 @ 01:09:
iSCSI is niet opgezet voor echte security, net als dat je op je gewone SCSI kabels geen wachtwoord hebt zitten Normaal gesproken hang je niet direct via iSCSI je clients aan een server, maar zijn servers via een storage-netwerk (SAN) verbonden en serveren ze die data via een LAN naar de clients. Op dat laatste punt wordt security een aandachtspunt.

@grizzly: SSH voor ~50MB/sec aan gegevens? Ik weet niet of ik medelijden met de client of de server moet hebben wanneer er zoveel gegevens tegelijk encrypted over de lijn moeten . Zijn we bijna weer terug in het PIO-tijdperk, waar de processor zich bezig moest houden met alle disk-access.

Jup, dat ben ik helemaal met je eens, voor de opstelling die ik nu heb maakt het ook niet uit, want in de huidige situatie zijn het gewoon twee servers die met z'n tweeën in een apart VLAN zitten. De ene is de initiator, de andere is het target.

Maar, als je natuurlijk via iSCSI kan booten, dan kan je een diskless client maken die zich gewoon aanmeld, inlogt en boot. Als je dat voor meerdere clients zou doen, gaat je performance er eerst flink onder lijden en daarna nog je security ook. Als ik nu al kijk naar de utilization (19%) dan gaat dat straks met SSH natuurlijk niet meer goedkomen...

[axis]

Als je een sparc doos hebt, waarom kies je dan niet voor solaris/opensolaris? Moet je volgens mij net iets meer performance eruit kunnen persen denk ik..

En qua security, sja, is hetzelfde met scsi en FC eigenlijk. Je kunt zorgen dat ze in een apart vlan staan, en eventueel op je iscsi target chap zetten en ip-restrictie. Maar nog steeds link als een machine helemaal compromized is door een hacker/cracker. Als je de impact daarvaan wil beperken moet je denk ik uiteindelijk aan de hba's, zodat je OS geen toegang meer heeft tot het san, maar slechts een enkele scsi controller ziet.

[Liam]

axis schreef op maandag 23 maart 2009 @ 09:16:
Als je een sparc doos hebt, waarom kies je dan niet voor solaris/opensolaris? Moet je volgens mij net iets meer performance eruit kunnen persen denk ik..

En qua security, sja, is hetzelfde met scsi en FC eigenlijk. Je kunt zorgen dat ze in een apart vlan staan, en eventueel op je iscsi target chap zetten en ip-restrictie. Maar nog steeds link als een machine helemaal compromized is door een hacker/cracker. Als je de impact daarvaan wil beperken moet je denk ik uiteindelijk aan de hba's, zodat je OS geen toegang meer heeft tot het san, maar slechts een enkele scsi controller ziet.

hehe, ja, maar Solaris opzetten gaat me weer net ff iets te veel tijd kosten. In FreeBSD ben ik in ieder geval een beetje thuis, dan kan ik het een beetje makkelijk opzetten. Solaris = documentatie lezen. Maar over de performance ben ik wel tevreden hoor, de disk die erin zit kan gewoon niet harder. Ik heb hier nog ergens een P4 2,53 Ghz liggen met een 36gb 10k schijf. Die zal ik eens ombouwen tot iSCSI target, en dan zal ik wel even wat benches runnen (windows, bsd, linux) en die hier neerzetten.

Het is in ieder geval leuk spul, en het werkt nog best aardig moet ik zeggen

[pinockio]

Even hierop voortbordurend:

In verband met back-ups leek het me handig om een schijf op mijn server (Linux, Debian Lenny, P4 1.6 GHz, 80 en 250 GB SATA schijven) een partitie via iscsi beschikbaar te maken voor twee Windows clients (initiatiors), één via LAN en één via WAN.

Dit is allemaal gelukt, heb op de Debian bak een target aangemaakt (partitie), de Windows client op het ene netwerk (LAN; GBit) logt erop in, kan formatteren, etc.

Via de WAN verbind ik de initiator met dezelfde target, kan (moet) vervolgens ook formatteren (ging wel vrij traag, een half uur voor het snelformatteren van 100 GB), bestanden erop zetten etc.

Wat is nu het leuke? Op beide staat een ander filesystem, en ze zijn beide gewoon tegelijkertijd werkzaam en benaderbaar. Het lijkt alsof ze elkaar dus niet in de weg zitten. Hoe Linux dit afhandelt weet ik niet, maar het werkt wel. (Maar dus niet zoals ik wil.)

Om te testen wat er gebeurt heb ik vanaf het LAN de schijf halfvol laten zetten, maar er gebeurt niets met de data die via het WAN te zien is. Blijft gewoon staan. En dat is natuurlijk vreemd, want hetzelfde volume is tweemaal geformatteerd.

Weet iemand of het op eenvoudige wijze mogelijk is hetzelfde target vanuit twee initiatiors te benaderen?

Eerder in dit topic werd dit ervan gezegd:

DeBolle in "iSCSI thuis"

"Ja - je kunt op de target meerdere initiators toegang geven tot dezelfde lun, dus clusters en meerdere (onafhankelijke) hosts naar dezelfde lun laten schrijven kunnen zonder meer. Hoe je dat laatste wilt regelen zonder een cluster-aware filesystem te gebruiken die door meerdere hosts onafhankelijk van elkaar kan worden beschreven lijkt me niet mogelijk. Een hosts die mag schrijven en een andere die dezelfde lun read-only kan benaderen moet mogelijk zijn.
Kortom, meerdere hosts write-access geven op dezelfde lun lijkt mij alleen mogelijk als het clusters zijn."

Maar dat is al een tijd geleden.
De bedoeling is overigens dat beide dezelfde "schijf" zien en de data kunnen benaderen. Dit dus i.v.m. back-up, snelheid, omdat het kan, etc. En nee, samba werkt niet fijn via WAN, ook niet via een OpenVPN tunnel.

Inmiddels heb ik dit gevonden: http://www.cyberciti.biz/...i-target-sanwith-tgt.html ... maar het pakket tgt is in Lenny niet beschikbaar.

[ Voor 3% gewijzigd door pinockio op 29-05-2009 14:41 . Reden: tgt ]

[axis]

Vreemd, lijkt toch echt alsof je nu 2 verschillende iSCSI volumes mount. Als het 1 volume zou zijn, en je zou op de ene host iets wijzigen, zou de andere file system corruptie moeten ervaren, aangezien NTFS niet cluster-aware is.

Maar 2 initiators samen op 1 filesystem is niet zo makkelijk. Dit heeft niets te maken met iSCSI (2 initiators op 1 volume/lun kan prima, net zoals je bij SCSI 1 disk aan 2 controllers kunt hangen), maar met het filesystem.

NTFS, FAT, ext2, ext3, ZFS, zijn allemaal niet cluster-aware. Dan zou je naar filesystems moeten als GFS ofzo (of VMFS in het geval van VMware). iSCSI is een block-level protocol, en is volgens mij niet een oplossing voor wat jij wilt.

Dus ik zou nog steeds ervoor kiezen om je linux doosje op te tuigen als NAS in plaats van block level storage. Welk protocol echter, is een beetje aan jou. Je geeft aan dat SMB niet lekker werkt over een VPN tunnel, helemaal mee eens (teveel overhead). Ik weet niet wat je precies allemaal wilt, maar misschien kun je toch met FTP/WinSCP aan de slag om die storage te delen?


edit: op dezelfde site een pagina daarover:

Q. I'd like to share iSCSI storage with our 3 node web server cluster. How can multiple systems access a single iSCSI LUN under Linux operating system? Can I connect multiple servers to a single iSCSI LUN?

A. Short answer - no it is not possible.

Long answer - It is possible to access a single iSCSI LUN using cluster aware file system such as GFS or OCFS2. You can also use NFS or Samba for sharing file system. iSCSI provides no file locking. This may result into serious data corruption. To share LUN simply use cluster aware file system.

[ Voor 24% gewijzigd door axis op 29-05-2009 16:54 ]

[pinockio]

axis schreef op vrijdag 29 mei 2009 @ 16:51:
Vreemd, lijkt toch echt alsof je nu 2 verschillende iSCSI volumes mount. Als het 1 volume zou zijn, en je zou op de ene host iets wijzigen, zou de andere file system corruptie moeten ervaren, aangezien NTFS niet cluster-aware is.

(...)

Dus ik zou nog steeds ervoor kiezen om je linux doosje op te tuigen als NAS in plaats van block level storage. Welk protocol echter, is een beetje aan jou. Je geeft aan dat SMB niet lekker werkt over een VPN tunnel, helemaal mee eens (teveel overhead). Ik weet niet wat je precies allemaal wilt, maar misschien kun je toch met FTP/WinSCP aan de slag om die storage te delen?


edit: op dezelfde site een pagina daarover:

[...]

Dat verbaasde me dus ook al. Ik heb nog een test gedaan op locatie; straks ga ik naar huis, en dan kijk ik of die initiator nog normaal kan verbinden zonder datacorruptie.

Heb nu trouwens in plaats van een tijdelijk 10/100 Mbit kaartje dat er even inzat een Gbit kaartje erin gezet. Jumbo frames lukt nog niet (misschien ondersteunt de switch dat niet goed, of de kabels), want dan valt de verbinding soms weg of valt terug naar 100 Mbit. Maar de snelheid is nog relatief goed: 22 MByte/seconde constant. Ook is het browsen op de iscsi-schijf erg snappy, sneller nog lijkt het wel dan de plaatselijke schijf.

Nog een voordeel: er zit gewoon een prullenbak op (niet dat ik dat vaak gebruik, maar sommige gebruikers verwijderen wel eens wat en denken dan dat het in de prullebak zit - op de netwerkschijf). Volgens mij is dat met samba niet zo 1-2-3 in te richten (wel met Windows 2003 server natuurlijk en volume snapshots).

FTP? Nee, ik wil gewoon bestanden kunnen openen via de verkenner of via een programma (Word/Excel).

Wat ik nu doe is dat ik werk via remote desktop, maar ik heb dus ook een VPN, en directe toegang tot de shares. Ik vind het belachelijk dat dat zo langzaam werkt, vooral het browsen van mappen. Of zou dat aan samba liggen? In ieder geval is het niet echt lekker werken, zelfs niet met Word-bestandjes van 50 kB. Dat zou over een 100 kB/s uplink best moeten werken, in de praktijk werkt het vervelend.

Maar... NOGMAALS (ook anderen hebben dat al genoemd) ----- er zijn nog meer redenen om een netwerkschijf als fysieke schijf te kunnen benaderen, zoals:

- Bepaalde programma's kunnen niet via een netwerkschijf werken
- Bepaalde back-upprogramma's backuppen geen netwerkschijven
- Dat het nu eenmaal leuk is

[Verwijderd]

Wel cool, ik lees net dat Synology ook iSCSI support:

http://www.synology.com/e.../Synology_DSM2.2_2009.php

[pinockio]

Ja, dat doet (zelfs) de stokoude Freecom SL Network Drive. Daar kwam ik laatst achter. De beperking is ook daar dat slechts één PC tegelijk de schijf via iscsi (of hun variant ervan) r/w mag benaderen.

Als je dus een bestand er op wilt zetten moeten andere clients (initiators) read only mounten. Daar zit een tooltje voor meegeleverd.

Hoe ik dit onder Windows kan doen is me nog niet duidelijk; ook kom ik er niet achter hoe ik met iet (onder Debian) bepaalde gebruikers alleen read only toegang geef. Zou wel ideaal zijn, want in mijn geval schrijft de ene client en de andere leest. Tenminste, daarmee zou ik al heel tevreden zijn.

[SpeedingWilly]

Weet iemand de oplossing waarom ik mijn iScsi target (op een Synology 207+ NAS) alleen lokaal (LAN) kan benaderen en niet via WAN?

Wat ik al heb geprobeerd:
- Router in DMZ zetten
- Poort 3260 is geforward naar mijn NAS

De iScsi initiator op de PC die ik wil verbinden ziet wel de drive maar 'connecten' lukt niet.

Weet iemand de oplossing. Ik heb zelf het idee dat het niet aan de router ligt die ertussen zit.
Op een lokale PC in het netwerk lukt het dus wel.

[axis]

SpeedingWilly schreef op woensdag 16 september 2009 @ 08:42:
Weet iemand de oplossing waarom ik mijn iScsi target (op een Synology 207+ NAS) alleen lokaal (LAN) kan benaderen en niet via WAN?

Wat ik al heb geprobeerd:
- Router in DMZ zetten
- Poort 3260 is geforward naar mijn NAS

De iScsi initiator op de PC die ik wil verbinden ziet wel de drive maar 'connecten' lukt niet.

Weet iemand de oplossing. Ik heb zelf het idee dat het niet aan de router ligt die ertussen zit.
Op een lokale PC in het netwerk lukt het dus wel.

Het kan zijn dat je target software niet NAT-compatible is, zoals ook het geval was in dit topic. In dat geval lukt het portal verhaal wel (ophalen van lijstje met targets), maar de portal stuurt je vervolgens naar een intern ip-adres, wat dus niet werkt remote.. Daar is denk ik het makkelijkst achter te komen door een sniffer op je machine te draaien en te kijken wat er langs komt.

Ik weet trouwens niet of je OS kan omgaan met een lokale disk (denkt je OS) die een gigaaaantische latency heeft, en maar ~1MB/s throughput heeft (weet niet wat voor connectie je hebt). Veel leveranciers van iSCSI producten geven daarom aan dat ze alleen maar situaties ondersteunen op een >1Gbps netwerk.

[SpeedingWilly]

Bedankt axis, jij hebt het zeer waarschijnlijk bij het rechte eind, zie dit topic op het Synology forum:
http://forum.synology.com...3dd64b0e26dda40bdb7755f38

Dus synology zal aan de bak moeten om dit 'probleem' op te lossen.

Wat betreft de latency vanwege 'traag' internet denk ik dat dat wel zal meevallen. Ik wil een iScsi drive hosten vanaf mijn NAS en bij mijn ouders mounten. We hebben beide 100mbit glasvezel internet, dus dat zal best wel goed werken.