iSCSI thuis

[mahi]

Verwijderd schreef op dinsdag 13 september 2005 @ 12:13:
Maar niet alleen in Windows hoop ik? Zo ja moet je dus toch al een OS draaien.

Nou, eerlijk gezegd heb ik dat niet getest. De Microsoft iSCSI initiator die ik gebruik werkt volgens mij enkel onder Windows, maar ik kan er naast zitten. Ik weet dat het mogelijk is om met iSCSI te booten zonder dat er een fysieke schijf in je systeem moet zitten, maar daarin heb ik me absoluut nog niet in verdiept. Mij was het puur en enkel te doen om in een bestaande Windows omgeving een network share beschikbaar te krijgen als een schijnbaar fysieke disk omwille van een softwareprobleem.

[axis]

mahi schreef op dinsdag 13 september 2005 @ 15:58:
[...]
- Intel Celeron D 320 (bakje heeft niet veel rekenkracht nodig - is enkel fileserver)

Vergis je niet in die processorkracht, het kost redelijk wat CPU power om al die data in te pakken in iSCSI pakketjes, en vice versa..

[axis]

Maar niet alleen in Windows hoop ik? Zo ja moet je dus toch al een OS draaien.

Een iSCSI client heet een iSCSI initiatior, en Microsoft heeft er een voor Windows, maar voor elk OS zijn er software initiators volgens mij.. Linux en FreeBSD in ieder geval wel.

[mahi]

axis schreef op dinsdag 13 september 2005 @ 17:33:
Vergis je niet in die processorkracht, het kost redelijk wat CPU power om al die data in te pakken in iSCSI pakketjes, en vice versa..

Ja dat weet ik, maar het systeem was origineel enkel bedoeld als Samba server. En daarvoor was de Celeron meer dan snel genoeg voor. Ik had op dat moment nog niet eens van iSCSI gehoord.

In mijn geval moet iSCSI enkel instaan voor een relatief kleine partitie waarop data staat die "fysiek" op de client pc's moet staan (de software weigert te werken met shares en mapped drives). De "grote" opslag gebeurt nog steeds via Samba. Daar de performance van iSCSI in mijn geval niet zo cruciaal is, heb ik me er eerlijk gezegd nog niet verder in verdiept. Misschien dat ik wanneer ik wat meer tijd heb wel eens uitgebreider onderzoek wat de impact is van m'n netwerkkaarten, processors,... en dan een afweging maak om deze te upgraden en geheel over te stappen op iSCSI. Maar dat is allemaal voor later.

[H!GHGuY]

Verwijderd schreef op dinsdag 13 september 2005 @ 12:02:
[...]

Wat is dit dan (Microsoft iSNS Server 3.0)?

iSNS server is een iSCSI beheer programma als ik het zo mag stellen...

daarmee kun je dacht ik targets aan initiators koppelen. de target meld zich aan op de iSNS server, en zo ook de client. daarna kan de client zonder veel poespas met CHAP en andere de bronnen gebruiken.

[axis]

Aha, leuk! VMware ESX 3.0 zal ook iSCSI gaan ondersteunen, hardware controllers, maar er zit ook een software iSCSI initiator in de vmkernel.

Op VMTN is een leuke intro te vinden, die ook het een en ander uitlegt over wat iSCSI nu precies is, en hoe dat vergelijkt met bijvoorbeeld NAS.

Alleen jammer dat in tegenstelling tot sommige sprekers deze vent absoluut niet kan spreken.. Bepaalde andere audio recordings waren leuk en enthousiast, en deze vent klinkt uhm.. niet echt enthousiast.. Maar goed, luister zelf:

iSCSI and NAS in ESX 3.0
This session introduces iSCSI and NAS technology, including the adapters and software products that are supported and available with the release of ESX Server 3. Features including authentication, discovery, administration and high availability are discussed. How the technologies can be used in ESX Server 3 for boot, host and guest support is included, as is information from the most up to date perfromance testing. Level 3: Intermediate

audio recording
presentation materials

[Shuriken]

axis schreef op vrijdag 16 december 2005 @ 21:45:
Aha, leuk! VMware ESX 3.0 zal ook iSCSI gaan ondersteunen, hardware controllers, maar er zit ook een software iSCSI initiator in de vmkernel.

Op VMTN is een leuke intro te vinden, die ook het een en ander uitlegt over wat iSCSI nu precies is, en hoe dat vergelijkt met bijvoorbeeld NAS.

Alleen jammer dat in tegenstelling tot sommige sprekers deze vent absoluut niet kan spreken.. Bepaalde andere audio recordings waren leuk en enthousiast, en deze vent klinkt uhm.. niet echt enthousiast.. Maar goed, luister zelf:

iSCSI and NAS in ESX 3.0
This session introduces iSCSI and NAS technology, including the adapters and software products that are supported and available with the release of ESX Server 3. Features including authentication, discovery, administration and high availability are discussed. How the technologies can be used in ESX Server 3 for boot, host and guest support is included, as is information from the most up to date perfromance testing. Level 3: Intermediate

audio recording
presentation materials

Alleen zal het waarschijnlijk niet performen. Maar leuk voor thuis prutsen

[axis]

Wat zal waarschijnlijk niet peformen? iSCSI, NAS of ESX?

[Shuriken]

axis schreef op zondag 18 december 2005 @ 00:23:
Wat zal waarschijnlijk niet peformen? iSCSI, NAS of ESX?

ESX over iSCSI. Tenminste met de bovenstaande oplossing lijkt het me niet dat je een goede performance gaat halen.

[ Voor 22% gewijzigd door Shuriken op 18-12-2005 10:55 ]

[UltraSub]

Waarom niet? Als je er nics in zet met een iscsi offload engine?
Zoveel doet zo'n ESX bak vol met windows machines doorgaans niet aan IO. Wat gebrabbel ja.. Maar verder? Naaaah..

[Shuriken]

UltraSub schreef op zondag 18 december 2005 @ 11:29:
Waarom niet? Als je er nics in zet met een iscsi offload engine?
Zoveel doet zo'n ESX bak vol met windows machines doorgaans niet aan IO. Wat gebrabbel ja.. Maar verder? Naaaah..

Daar heb ik hier boven niets over gelezen Ik had het over iscsi over een simpel ethernet kaartje. Ik hoop in elk geval dat mn Sata controller beter performed.

[UltraSub]

Um.. ja das waar inderdaad, staat er ook niet. Sorry

[axis]

Ja, als je inderdaad een simpele P3 met een 5400RPM disk hebt, en die wilt daar VMFS op gaan draaien, zal dat niet zo snel zijn inderdaad ja Maar ik ben benieuwd hoe het in de praktijd uit zal gaan pakken

[kleinesmurf]

Leuk topic, ik vond al weinig duidelijke en kant-en-klare info over iSCSI.
Ik leerde iSCSI kennen door verhalen van een kameraad - die vertelt graag zo'n dingen op cafe...
Ik ga er dit weekend mee aan de slag en post ervaringen (ik hoop dat dit topic dat toelaat)
Alleszins al dank aan Tweakers en de TS voor dit T!

[axis]

kleinesmurf schreef op vrijdag 24 februari 2006 @ 16:18:
Ik ga er dit weekend mee aan de slag en post ervaringen (ik hoop dat dit topic dat toelaat)

Dat is juist wat we willen!

[kleinesmurf]

axis schreef op vrijdag 24 februari 2006 @ 16:28:
[...]

Dat is juist wat we willen!

Fijn

* Kleinesmurf voelt axis ongeduldig op zijn vingers kijken

[Femme]

Verwijderd schreef op zaterdag 20 augustus 2005 @ 06:00:

Wat hier naar mijn enorm idiote mening over het hoofd gezien word is dat iSCSI niet zomaar voor een netwerkje bedoelt is. Ik zeg bewust niet ``prof rotzooi'', maar dit is SCSI, niet een of ander random communicatieprotocol dat ook nog ns moet worden geencapsuleerd in TCP/IP packets. Daar zijn 1337 andere oplossingen voor te bedenken, de meest simpele gewoon een device file sharen via NFS of deze via een simpele socket doorlussen naar een Windowsdrivertje die het ook allemaal mooier voordoet dan het is. Daar heb je geen iSCSI voor nodig...

...waar iSCSI wel voor bedoeld is, is gebruikmaken van het SCSI protocol over TCP/IP. het SCSI protocol is, vergeleken met vrijwel elke andere storagetechnologie, superieur, nog helemaal afgezien van de fysieke laag. Om dat uit te leggen heb ik een heel boek nodig, en dat is er ook (The Book of SCSI, http://www.scsifaq.org; /me houdt trots zijn fysieke kopie omhoog), maar je kunt stellen dat dit eigenlijk een enorme degradatie ervan is. iSCSI is eigenlijk gewoon de fysieke laag aanpassen, en die fysieke laag hangt helemaal af van het medium waar het over gaat. Het probleem is, zelfs met dual gigabit haal je nog ``maar'' 400mbyte/s.... das maar 80mbyte/s meer dan SPI-4 (meestal ietwat verkeerd aangeduid als Ultra320) aankan. Bovendien is de latency stukken hoger.

[...]

- iSCSI is in principe puur bedoeld als een methode om bestaande bekabelingslimieten te omzeilen, met een potentieel hogere snelheid dan enige seriele SCSI-interface, en met moeite een hogere snelheid als een SPI-interface;
- iSCSI is voor redelijk gebruik nogal duur, en de goedkopere varianten doen de voordelen van het SCSI-protocol teniet;

Dat zie je toch verkeerd. iSCSI is ontwikkeld als betaalbaar alternatief voor Fibre Channel-gebaseerde storage area networks (SAN's). Het is dus wel voor een "netwerkje" bedoeld. iSCSI moet je niet vergelijken met NAS. Het verschil tussen een SAN en NAS is dat bij de eerste de storage op blokniveau wordt aangesproken terwijl dat bij NAS op bestandsniveau gebeurt. Daardoor is het bijvoorbeeld mogelijk om te booten vanaf een volume op een SAN en bepaald de server die met het SAN verbonden is zelf wat voor bestandssysteem er op het volume draait.

Het grote voordeel van iSCSI is dat het over normale IP-netwerken getransporteerd kan worden. De investeringen in infrastructuur zijn daardoor veel lager dan bij Fibre Channel, wat overigens ook gebaseerd is op het SCSI-protocol. Qua prestaties loopt iSCSI nog wel achter op FC, maar als over een paar jaar 10Gb ethernet betaalbaar wordt, hoeft de performance van iSCSI geen probleem meer te zijn.

[axis]

Zou het mogelijk zijn om 1Gbps adapters te teamen, zodat je misschien toch aan de 2Gbps van FC zou kunnen komen?

Heb al wel redelijk wat met intel server adapters gewerkt die je schijnbaar makkelijk kunt teamen, maar heb er in de praktijk nog geen ervaring mee.

[Kippenijzer]

Teamen/Trunken, mits als je apparatuur het ondersteund kan natuurlijk gewoon (dus zowel je server als de switch waar je hem op aansluit). iSCSI gaat gewoon over je reguliere TCP/IP stack, en als die over een trunk loopt, kan hij dus ook van de volledige bandbreedte daarvan gebruik maken. Maar he4t voornaamste snelheidsverscil zal hem zitten in de veel hogere latency, dan in het "tekort" aan bandbreedte. Sowiezo, met de nieuwe 10Ge kaartjes van Intel (jaja, over Copper, helaas maar 15 meter kabellengte maximaal) zou zelfs dat niet zo'n probleem zijn, dus het zit hem echt in de hogere latency

[kleinesmurf]

* Kleinsmurfke is dit weekend gestart met voorbereidingen om iSCSI te gebruiken...
Om snelheidsproblemen te vermijden wou ik de iSCSI stuff niet over mijn WLAN maar dus over een 2e en bekabeld netwerk... en daarvoor maar ineens gekeken om mijn oud stofverzamelend 10mbps hubje te vervangen...
De CD met Linux Suse 9.2 ligt klaar... nu nog een PC ineen krijgen
* Kleinsmurfke heeft wel nog een mobo, cpu, wat ram...

Niets spectaculair, weinig concreets... I know... Ik had nog een aantal andere verplichtingen ook...

[Verwijderd]

BackSlash32 schreef op zaterdag 13 augustus 2005 @ 21:00:
Jup

Zo zou je met Gbit ethernet en een SATA Raid server met 4x250GB toch een leuke 0.72 TB storage kunnen maken..

Hardwarekeuze : Cheap-Ass Raid 5 fileserver

Een andere mogelijkheid is natuurlijk een LVM based backend voor je verplichte logfile storage omdat Ome Piet-Hein Donner zo graag wil dat je je logfiles voor 2 jaar moet bewaren + direct moet kunnen laten raadplegen....

Hou jij een logfile storage bij van 2 jaar???

[Verwijderd]

Femme schreef op vrijdag 24 februari 2006 @ 20:17:
[...]


Dat zie je toch verkeerd. iSCSI is ontwikkeld als betaalbaar alternatief voor Fibre Channel-gebaseerde storage area networks (SAN's). Het is dus wel voor een "netwerkje" bedoeld. iSCSI moet je niet vergelijken met NAS. Het verschil tussen een SAN en NAS is dat bij de eerste de storage op blokniveau wordt aangesproken terwijl dat bij NAS op bestandsniveau gebeurt. Daardoor is het bijvoorbeeld mogelijk om te booten vanaf een volume op een SAN en bepaald de server die met het SAN verbonden is zelf wat voor bestandssysteem er op het volume draait.

Het grote voordeel van iSCSI is dat het over normale IP-netwerken getransporteerd kan worden. De investeringen in infrastructuur zijn daardoor veel lager dan bij Fibre Channel, wat overigens ook gebaseerd is op het SCSI-protocol. Qua prestaties loopt iSCSI nog wel achter op FC, maar als over een paar jaar 10Gb ethernet betaalbaar wordt, hoeft de performance van iSCSI geen probleem meer te zijn.

iSCSI is inderdaad een goedkoper alternatief voor een SAN. Het is echter geen SAN (Storage Array Network). In feite is iSCSI een heel leuk "extraatje" voor NAS. Het is immers storage die gewoon aan je communicatie-netwerk gekoppeld is, terwijl je bij SAN een heel duidelijke (fysieke) scheiding ziet tussen je communicatie-netwerk en je storage-netwerk.

Wat je met iSCSI dus bereikt is: blockdata transporteren over een packet-based communicatienetwerk.

Dat heeft bijvoorbeeld dit als voordeel:

Another important benefit that iSCSI brings to the world of IP storage is that it works well over WAN links (unlike NAS protocols). This gives IT managers another option for the mirroring of data over the WAN besides protocols such as FCIP (Fibre Channel over IP), which have been used in the past to extend the reach of Fibre Channel SANs.

En een mogelijk nadeel (voor de toekomst)

Although no major security issues related to iSCSI have been reported, it is safe to say that iSCSI will become a more attractive target for hackers as the protocol becomes more commonly used.

Quotes zijn van eWEEK

[axis]

kleinesmurf schreef op dinsdag 28 februari 2006 @ 08:50:
daarvoor maar ineens gekeken om mijn oud stofverzamelend 10mbps hubje te vervangen...

Sja, met 10mbps haal je dus een theoretisch maximale disk transfer van 1,25MB/s.. spannend

Verwijderd schreef op dinsdag 28 februari 2006 @ 09:51:
[...]
iSCSI is inderdaad een goedkoper alternatief voor een SAN. Het is echter geen SAN (Storage Array Network). In feite is iSCSI een heel leuk "extraatje" voor NAS. Het is immers storage die gewoon aan je communicatie-netwerk gekoppeld is, terwijl je bij SAN een heel duidelijke (fysieke) scheiding ziet tussen je communicatie-netwerk en je storage-netwerk.

Dat ben ik niet helemaal met je eens.. In een professionele omgeving heb je iSCSI HBA's, en iSCSI SAN dozen, al dan niet linux pc'tjes of NetApp filers, etc.. Net zoals je nu hebt met FC kabeltjes en HBA's.

Het enige verschil is dan het protocol en de bekabeling..

Maar ik geef je wel deels gelijk, je KUNT het gebruiken als een heel leuk "extraatje" voor NAS.

En sja, qua hackers.. Je SAN (Storage Area Network, of dit nu iSCSI of FC is maakt dus niet uit) hangt idealiter nooit aan je productienetwerk als je iSCSI HBA's gebruikt, of je bekommert om security.

Maar goed, da's mijn visie

[Femme]

Verwijderd schreef op dinsdag 28 februari 2006 @ 09:51:
[...]

iSCSI is inderdaad een goedkoper alternatief voor een SAN. Het is echter geen SAN (Storage Array Network). In feite is iSCSI een heel leuk "extraatje" voor NAS. Het is immers storage die gewoon aan je communicatie-netwerk gekoppeld is, terwijl je bij SAN een heel duidelijke (fysieke) scheiding ziet tussen je communicatie-netwerk en je storage-netwerk.

Wat je met iSCSI dus bereikt is: blockdata transporteren over een packet-based communicatienetwerk.

Of het fysieke netwerk gedeeld wordt met een IP-netwerk dat ook voor andere toepassing wordt gebruikt, is niet relevant om van een SAN te kunnen spreken. Een SAN is een netwerk dat storage met servers en clients verbindt. Over welke fysiek netwerk dat gaat is niet belangrijk. Wel doelt men met SAN doorgaans op een netwerk waarin de storage op blokniveau wordt aangesproken in plaats van op bestandsniveau, zoals bij NAS-apparaten. Het protocol is meestal een derivaat van SCSI. iSCSI is ontwikkeld als betaalbaar alternatief voor Fibre Channel.

Als je wilt kun je het hele iSCSI-netwerk fysiek scheiden van het normale IP-netwerk, hoewel dat een aantal voordelen van iSCSI teniet zal doen.

iSCSI kan vanwege de lage kosten natuurlijk ook gebruikt worden als alternatief voor een NAS-systeem, maar dan bouw je feitelijk een SAN.

[ Voor 6% gewijzigd door Femme op 28-02-2006 12:00 ]

[kleinesmurf]

axis schreef op dinsdag 28 februari 2006 @ 10:28:

Sja, met 10mbps haal je dus een theoretisch maximale disk transfer van 1,25MB/s.. spannend

Net omwille van de vloek-reactie-uitlokkende snelheid heb ik een Giegabietje op het oog...
Er komt deze week een SMC Gigabitje binnen. Met enige kabeltjes en een Gbps PCI kaartje... mijn PC (nu effe tot "PC nummer 1" gedoopt) heeft al een Gbps nicje ingebouwd...
Nu nog Linux in sneltempo gewoon worden

[alt-92]

Verwijderd schreef op dinsdag 28 februari 2006 @ 09:15:
Hou jij een logfile storage bij van 2 jaar???

Volg jij het nieuws wel eens?
Zo gek is dat niet hoor, vorig jaar een verzoek van de belastingdienst gehad voor een aantal e-mails uit 2003 omdat daar financieel belangrijke gegevens in bleken te staan.

[Verwijderd]

Ik zal nu wel een heel domme vraag stellen... maar, wat is nou eigenlijk het voordeel van SAN/NAS... je verplaatst de schijf toch alleen maar?

Dan is dat natuurlijk een voordeel als dat van kantoor op een van de 200 etages naar je datacenter gaat... Maar als je de server achter je het SAN voor je laat gebruiken is dat voordeel ook weg...

Mss idee om aan de OM FAQ een SAN/NAS/DAS deel toe te voegen??? (En als het er al is, iets duidelijker neer zetten... want ik kon het niet vinden...)

[_-= Erikje =-_]

Is het nou ook mogelijk om 1 target te delen tussen initiators? dus bv 2 mailservers die hun mailboxen op 1 volume wegschrijven zodat een 3e popserver die mail kan serveren?

[DeBolle]

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.

[_-= Erikje =-_]

't lijkt me idd meer afhankelijk van het filesystem idd. iSCSI is eingelijk een soort NBD (network distributed blockdevice)

[connected]

ik heb net een aanvraag gedaan naar wat test software van emboot,
met deze software moet het mogelijk zijn om dmv eerst een pxe te doen en heel windows systeem te booten over iscsi
http://www.emboot.com/products_netBoot-i.htm

[polthemol]

ben ook maar eens aan de slag gegaan met iscsi (Was op zoek naar een mooi systeem om een fileserver te maken maar wel dat het fysieke schijven bleven).

Nu is het enige wat ik me nog afvraag het volgende:

mijn huidige setup is een dual 2600 met een 30 gig ideschijf, 2 * 120 gig sata striping voor mijn vmware en 3 *320 gig voor datameuk (muziek, backups voor de filmindustrie, dat geneuzel allemaal).

Die 320 gigs wil ik dan als iscsischijven gaan gebruiken, maar mijn vraag is: Wat gebeurt er met die data stel mijn os-schijf gaat op zijn gat. Zijn ze bij een reinstall nog altijd bereikbaar of kan ik dagdag zwaaien naar mijn data ?

(vergeten te vermelden maar: gebruik softwarematige oplossing, debian linux)

[ Voor 5% gewijzigd door polthemol op 24-02-2007 15:51 ]

[polthemol]

maar even trialanderror gedaan (server slopuh !)

Je kunt dus gewoon je ntfsschijven van windows overpleuren naar je linuxserver, config van je iscsi aanpassen en alle zooi blijft er netjes opstaan

[Bierkameel]

Dat zal vast wel werken maar het schrijven naar NTFS onder Linux is nog niet geweldig, zeker niet iets wat ik op een server zou willen draaien.

[Xiphalon]

Eh, bierkameel, het zal linux in dit geval scheit wezen wat er op de schijven aan FS staat. De schijven worden op block nivo via iSCSI doorgesluisd naar de windows initiator, die de schijven dan als fysieke ziet. Voor windows zijn de schijven verplaatst naar een andere controller.

[polthemol]

idd darkmage ik wist alleen niet zeker of hij de boel echt format of dat het op je server zelf gebeurt. Maar werkt perfect alleen straks nog proberen paar netwerkkaarten te trunken dat ik wat meer bandwidth heb.

[Wim Leers]

Erg interessant dit. Alleen jammer dat het niet goed samenwerkt met software RAID .

Ik wil dit zeker zelf ook gaan uittesten, maar dan moet ik wel eerst een hardwarematige RAID controller op de kop zien te tikken (atm gebruik ik onboard SiI3112r)... Ik wil het gebruiken voor backups van m'n MacBook Pro, atm naar een 320 GB externe HDD, via USB 2, dus pokketraag (disk slim clonen, dus backup progsel kijkt welke bestanden veranderd zijn, maw scant de hele meuk en kopieert de veranderde bestanden). iSCSI zou hogere snelheden moeten halen via gigabit lijkt me? Latency zou vergelijkbaar moete zijn met USB 2.0?

[dj_dysaster]

Geniaal systeem dat iscsi, ik draai het hier sinds een poosje op een test raid5 array van 4x 250GB schijven icm mdadm. En het gaat als een trein, ik zal binnekort is een gigabit switchje zoeken voor de nodige benchmarks maar tot nu toe niets anders dan lof.

[deadlock2k]

-

[ Voor 99% gewijzigd door deadlock2k op 06-08-2021 15:44 ]

[Wim Leers]

deadlock2k schreef op woensdag 14 maart 2007 @ 15:58:
[...]

iSCSI is een protocol waarmee met de schijf zelf gecommuniceerd kan worden, via Ethernet en de andere daarvoor bestemde TCP/IP draagmethoden. In principe maakt het niet zoveel uit wat voor onderliggende hardware er gebruikt wordt, maar het is alleen nuttig als je je schijf 1 op pc's 2, 3 en 4 wil benaderen alsof het een eigen schijf is.

Het zou dus gaan dienen voor back-ups in mijn geval. Niet meer sleuren met externe HDD's, en omdat het over het (overal beschikbare) netwerk gaat, kan je het makkelijker automatiseren (enige vereiste is dat iSCSI target server aanstaat)

deadlock2k schreef op woensdag 14 maart 2007 @ 15:58:
Voor in netwerken thuis is het niet zo heel interresant. Het is eigenlijk not done om iSCSI verkeer over hetzelfde fysieke netwerk te laten lopen als de rest van het netwerkverkeer. Ook VLAN'ing is meestal not done, omdat je er zeker van wil zijn dat als er iets gebeurd met je switches, je iSCSI SAN of NAS dan blijft werken.

Gescheiden verkeer is inderdaad beter, maar het gaat mij niet om de maximale snelheid. We hebben hier toch allemaal onboard (lees: niet de beste) Gigabit NIC's dus maximale snelheid zouden we sowieso al niet halen.

deadlock2k schreef op woensdag 14 maart 2007 @ 15:58:
Ik las ook een verhaal over clustering en het benaderen van bestanden vanaf meerdere machines.
Onder Netware is het zo dat het niet mogelijk is om binnen een cluster hetzelfde SAN-volume op meerdere machines te mounten. Ik heb geen verstand van iSCSI onder Linux of Windows, maar het lijkt me absoluut niet iets wat je zomaar wil doen in verband met onder meer datacorruptie. Shares zijn goed genoeg op dat moment lijkt me, ook al is het heel leuk speelgoed.

Via iSCSI is het inderdaad niet mogelijk om 1 volume ("target") vanuit meerdere machines te mounten ("initiaten"), maar dat is ook niet de bedoeling.
Voor backups telkens een RAID-1 array (waarschijnlijk softwarematig, dus 2 iSCSI targets). Maar ik geloof dat je dmv IET (Linux iSCSI Enterprise Target) en LVM een software RAID kunt aanmaken en deze array dan presenteren als een enkel target?
Ik heb nog een hoop opzoekwerk te doen

[Xiphalon]

Bashrat schreef op woensdag 21 maart 2007 @ 12:49:
[...]

Via iSCSI is het inderdaad niet mogelijk om 1 volume ("target") vanuit meerdere machines te mounten ("initiaten"), maar dat is ook niet de bedoeling.

[...]

Echt wel, ik heb hier 2 machines staan met Solaris 10 erop, die via OCFS2 allemaal dezelfde schijven mounten via iSCSI.
Het kan dus wél, maar je moet er een cluster-ready filesysteem opzetten.

[axis]

Bashrat schreef op woensdag 14 maart 2007 @ 00:02:
Erg interessant dit. Alleen jammer dat het niet goed samenwerkt met software RAID .

Ik wil dit zeker zelf ook gaan uittesten, maar dan moet ik wel eerst een hardwarematige RAID controller op de kop zien te tikken (atm gebruik ik onboard SiI3112r)... Ik wil het gebruiken voor backups van m'n MacBook Pro, atm naar een 320 GB externe HDD, via USB 2, dus pokketraag (disk slim clonen, dus backup progsel kijkt welke bestanden veranderd zijn, maw scant de hele meuk en kopieert de veranderde bestanden). iSCSI zou hogere snelheden moeten halen via gigabit lijkt me? Latency zou vergelijkbaar moete zijn met USB 2.0?

iSCSI lijkt me hier overkill, en zorgt alleen voor nodeloze complexiteit. Je hebt hier niet echt een block level device nodig.. Denk dat je beter een linux doosje met een NFS share of bijvoorbeeld een windows doosje met smb share kunt gebruiken.

Ik heb een backup scriptje op mijn macbook pro die een NFS share mount en alles behalve 1 dir synchroniseert (alleen de wijzigingen dan)

code:

mkdir /Volumes/Backup
mount fileserver.hongens.local:/bigdisk/shared/BACKUPS/ANGELOMOBIEL /Volumes/Backup && \
rsync -vrtz --progress --delete /Users/angelo /Volumes/Backup --exclude=angelo/Desktop/TO_BURN/*
umount /Volumes/Backup
rm -r /Volumes/Backup

Dat wil niet zeggen dat iSCSI niet leuker is om mee te spelen, maar dit is simpeler.. soms synchroniseer ik als ik thuis ben, of soms remote over een VPN. Het is dan wel 40GB, maar aangezien ie toch maar de wijzigingen compressed overpompt.

[Wim Leers]

darkmage schreef op woensdag 21 maart 2007 @ 16:38:
[...]

Echt wel, ik heb hier 2 machines staan met Solaris 10 erop, die via OCFS2 allemaal dezelfde schijven mounten via iSCSI.
Het kan dus wél, maar je moet er een cluster-ready filesysteem opzetten.

Uiteraard, maar een cluster-ready FS gebruiken is niet erg handig voor dagelijks gebruik, dat is dus helemaal niet van toepassing.

axis schreef op donderdag 22 maart 2007 @ 21:38:
[...]

iSCSI lijkt me hier overkill, en zorgt alleen voor nodeloze complexiteit. Je hebt hier niet echt een block level device nodig.. Denk dat je beter een linux doosje met een NFS share of bijvoorbeeld een windows doosje met smb share kunt gebruiken.

Ik heb een backup scriptje op mijn macbook pro die een NFS share mount en alles behalve 1 dir synchroniseert (alleen de wijzigingen dan)

code:

mkdir /Volumes/Backup
mount fileserver.hongens.local:/bigdisk/shared/BACKUPS/ANGELOMOBIEL /Volumes/Backup && \
rsync -vrtz --progress --delete /Users/angelo /Volumes/Backup --exclude=angelo/Desktop/TO_BURN/*
umount /Volumes/Backup
rm -r /Volumes/Backup

Dat wil niet zeggen dat iSCSI niet leuker is om mee te spelen, maar dit is simpeler.. soms synchroniseer ik als ik thuis ben, of soms remote over een VPN. Het is dan wel 40GB, maar aangezien ie toch maar de wijzigingen compressed overpompt.

Ik snap je punt en hier was ik ook al over aan het nadenken. Ik ben het nog gewoon om met devices en niet shares te werken, omdat tot nu toe elke share traag was (Windows & shares: de traagste flutzooi ooit... Explorer hangt >10 seconden gewoon om de share's root dir te kunnen zien...).
NFS heb ik nog nooit gebruikt, en kan misschien wel een beter alternatief zijn.

Hoedanook ga ik waarschijnlijk OpenFiler gebruiken, en kan ik dus beide "for free" gebruiken en door elkaar mixen, iSCSI en NFS (en samba ook) dus, en wat mee experimenteren.

[axis]

Bashrat schreef op donderdag 22 maart 2007 @ 22:05:
[...]
NFS heb ik nog nooit gebruikt, en kan misschien wel een beter alternatief zijn.

Hoedanook ga ik waarschijnlijk OpenFiler gebruiken, en kan ik dus beide "for free" gebruiken en door elkaar mixen, iSCSI en NFS (en samba ook) dus, en wat mee experimenteren.

Voor mijn gevoel is NFS stukken sneller dan SMB.. Niet qua maximale doorvoer, maar het voelt 'snappier' aan, er gaan volgens mij veel sneller kleine files doorheen. Met die iSCSI zal dat denk ik nog sneller gaan, aangezien alles in 1 grote stream over de lijn gaat, en niet voor elke file een nieuwe transactie opgezet hoeft te worden. Althans, dat zegt mijn gevoel.. Zelf ook nog niet veel ervaring mee.. Niets tegen samba hoor, zit nu files naar een windows machientje te backuppen @30MB/s, en dat vind ik prima..

Voordeel van NFS boven iSCSI is wel dat je met putty of je ingebakken terminal ssh naar je server kunt connecten vanuit waar ter wereld, en snel je data kunt manipuleren. Even een foldertje inpakken, parren, ftp'en, etc. Dat kan niet als je een iSCSI volume hebt. Tenzij je die weer op de localhost gaat mounten, moeilijk moeilijk.

[Wim Leers]

axis schreef op donderdag 22 maart 2007 @ 22:24:
[...]

Voor mijn gevoel is NFS stukken sneller dan SMB.. Niet qua maximale doorvoer, maar het voelt 'snappier' aan, er gaan volgens mij veel sneller kleine files doorheen. Met die iSCSI zal dat denk ik nog sneller gaan, aangezien alles in 1 grote stream over de lijn gaat, en niet voor elke file een nieuwe transactie opgezet hoeft te worden. Althans, dat zegt mijn gevoel.. Zelf ook nog niet veel ervaring mee.. Niets tegen samba hoor, zit nu files naar een windows machientje te backuppen @30MB/s, en dat vind ik prima..

Voordeel van NFS boven iSCSI is wel dat je met putty of je ingebakken terminal ssh naar je server kunt connecten vanuit waar ter wereld, en snel je data kunt manipuleren. Even een foldertje inpakken, parren, ftp'en, etc. Dat kan niet als je een iSCSI volume hebt. Tenzij je die weer op de localhost gaat mounten, moeilijk moeilijk.

Met 30 MBps zou ik HEEL erg blij zijn, dat zou sneller zijn dan ik nu met USB 2.0 op een externe HDD (320 GB) haal
En ik geloof maar al te graag dat NFS veel snappier is dan SMB...

Zoals ik al zei, ik ga een beetje met ze allemaal experimenteren. Benchmarks zal ik vast nog wel in OM posten zodra ik zover ben. We zijn best wel OT gegaan, dus miss best terug over iSCSI nu? Sorry!

[Verwijderd]

even voor de geinteresseerden:
novell en M$ werken samenin de virtualisatie voor windows en linux omgeving. en link

en daarbij dan ivm dit iscsi topic:
[url="http://www.novell.com/connectionmagazine/2007/q1/pdf/techtalk7_q107.pdf"]maak zelf een iscsi testopstelling met dit stukje tekst/url]

[Bastiaan V]

heeft iemand al naar ATAoE gekeken?

Ik heb eerlijk gezegd nog niets geprobeerd met iSCSI, maar heb me er wel verdiept. tijdens dit proces kwam ik ATAoE tegen, wat voor mij alleen maar voordelen had. simpele implementatie, snel, en weinig overhead. Enige nadeel is dat er geen routing plaats kan vinden, oftewel, je server moet in het zelfde subnet zitten als je client(s). Wat niet snel een probleem zal zijn imho,

[JJay]

Whoeii interessant topic, het hele iSCSI-at-home idee zit al maanden in m'n hoofd en aangezien 'k een vrije week heb konden m'n ideeën ook getest worden; korte samenvatting:

M'n 200GB Lacie Firewire/USB disk is aan vervanging toe, de combinatie lage performance (zie graphs) af en toe storingen en gebrek aan ruimte vormen de motivatie om naar iets nieuws op zoek te gaan. Voor een vervanger staan alle opties open; een tweaker is niet bang voor een experiment :-)
Het uitgebreide verhaal zal ik achterwege; kort gezegt door eerdere ervaring met iSCSI op m'n werk (NetApp ) en een hoop spannend research werk in het vooruitzicht zou het de volgende opstelling worden.

iSCSI Initiator 'client'
HP xw6000 Workstation
Dual 2,66GHz Xeon, Intel E7202
NIC: Broadcom BCM57xx serie 10/100/1000 MBit
Software: Microsoft Windows XP SP2 en Microsoft iSCSI initiator 1.5

iSCSI Target 'server'
DIY rackmount fileserver en router op basis van Asus PSCH-SR/SCSI
2,4GHz 533MHz CPU, Intel
Software: Debian r3.1, iscsitarget
Storage: Div. Raid-0, Raid-1 en linear arrays op SATA-150 en ATA-100

Beide machines zijn uitgerust met een fatsoenlijk high-end moederbord (Intel E72xx series), wat hardware betreft zitten we dus wel goed. Nu de software nog:

In een paar uur tijd zijn de volgende stappen doorlopen (ja, * JJay loves OSI :-))

• Netwerk maken (GBit NIC's dmv. Cross-cable aan elkaar, auto-negotiation fixen, Jumbo frames enable'en etc..)
• TCP/IP testing en tuning Windows XP en Linux
• Netwerk throughput tussen initiator/target bepalen en optimaliseren
• iSCSI target software optimaliseren dmv. NullIo device
• Throughput meten van de disk arrays op de server
• Throughput meten van de disk arrays over iSCSI

Op dit moment haal 'k de volgende resultaten:

• TCP throughput Linux kernel = 2,04Gb/sec, XP 'kernel' = 840Mb/sec (beide zwaar geoptimized)
• TCP throughput over netwerk ~ 640Mb/sec
• Throughput raid-arrays (RAID-1 over ATA100 ~433Mb/sec)
• Throughput iSCSI disk (NullIo ~ 455Mb/sec, RAID-1 over ATA100 ~ 414Mb/sec)

Dat is zo'n 55MB/sec, dat valt lang niet tegen na een middagje hobby'en. Ik weet niet of het hier op z'n plaats is maar 'k zou graag de methoden en resultaten van de verschillende stappen hier posten als daar vraag naar is? Ben benieuwd wie er nog meer op deze manier met iSCSI bezig is en feedback is meer dan welkom :-)

Owjah, bijna vergeten: heb gisteren een nieuwe set SATA disks besteld en een hot-swap enclosure voor in de server. Deze gaan er voor zorgen dat de huidige testopstelling het Lacie diskje ook werkelijk kan vervangen. M'n keuze is gevallen op 3 320GB WD 'RAID Edition' disks, die voorlopig op RAID-1 gaan werken. Verder staat er nog een fatsoenlijke (PCI-X) SATA controller en een upgrade naar RAID-10 in de planning..

[ Voor 7% gewijzigd door JJay op 29-06-2007 15:47 ]

[Ingo]

Ik kende tot voor 2 weken iSCSI niet maar heb nu ook eens een testsysteempje opgezet om te kijken of het bruikbaar is - lees:performed (At home just for fun).

iSCSI initiator:
Asus P5BE-plus
Intel C2D E6600 met 2GByte memory
NIC: onboard Marvell Yukon 88E8056 Gbit
Software: Dual Boot: Windows XP SP2 met Microsoft iSCSI Software Initiator Version 2.04 en Windows Vista

iSCSI Target
Asus P4P800
Intel P4 Celeron 2Ghz met 1 Gbyte memory
NIC: onboard 3com Gbit LOM (3C940)
Harddisk: 1x aparte voor Openfiler install en 1x apart ca. 7 jaar oude IDE 40GB disk voor SAN. (Als Openfiler bruikbaar lijkt wil ik een S-ATA hardware Raid5 opbouwen)
Software: Openfiler 2.2 (gebruikt iscs-target-0.4.14 ) (Openfiler = Linux Opensource NAS/SAN met iSCSI support voor SAN)

De Openfiler SAN zit (momenteel) nog gewoon op miij standaard Gbit LAN met Gbit switch. Op de WinXP heb ik Jumbo Frames enabled en op de Openfiler heb ik de MTU size op 9000 bytes gezet. Op Openfiler een volume gecreerd van 10GB en deze via de WinXP machine geformateerd op NTFS welke vervolgens zichtbaar is als lokale drive op WinXP. Vervolgens een file van paar honderd MB gecopieerd van de WinXP PC naar de SAN partitie. Met hand getimede throughput van zo’n 4-5 MB/sec. Zeer traag dus. Dezelfde file over het netwerk copieren naar een andere WinXP machine gaat zeker 2x zo snel.
Om de oude SAN harddisk als vertragende factor uit te sluiten vervolgens een 800GB RAMdisk onder Linux aangemaakt een als SAN disk connected met WinXP PC. Throughput wordt nu ca. 8MB/s, nog steeds erg traag maar dit kan ook liggen hoe de RAMdisk nu precies werkt binnen Linux maar ik ben slechts een Linux beginner …

Iometer dus maar eens geinstalleerd om de Gbit LAN throughput te testen. Een quick test met 4K blokken levert ca. 15MB/sec op.
Binnenkort de WinXP PC en Openfiler direct via crosscable aansluiten. Met Vista heb ik nog niet getest maar die schijnt een zelf optimaliserende TCP stack te hebben vergeleken met WinXP, toch maar eens doen dus.

Mijn vragen:
- hoe kan ik zien of de Jumboframes wel werken ?
- Is 15MB/sec voor dit soort onboard Nic’s redelijk of moet daar meer mee te behalen zijn ?
- Is er met een “echte” Gbit LAN kaart met Intel 1000Pro of Broadcom 57xx chipset een hogere troughput te halen of scheelt dit vooral cpu-load
- wat en hoe kan er aan aan de WinXP kant nog geoptimaliseerd worden (TCP registry settings ?)
- wat en hoe kan er aan de Openfiler (rPath) Linux kan nog geoptimaliseerd worden (iSCSI target).

@JJay ik ben dus er benieuwd hoe jij geoptimaliseerd hebt en wat voor meet tools je gebruikt.

[JJay]

Hey koel, meer mensen die aan de hobby gaan met iSCSI

Allereerst, 15 MB/sec klinkt als de throughput die je met Windows haalt als de boel nog niet geoptimaliseerd is. Mijn broadcom NICjes deden 'out-of-the-box' zo'n 120-140mbit. Ruimte genoeg voor betering dus!

Voor het gemak kun je misschien eerst testen zonder dat je switch er tussen zit, crosscable dus..? Daarmee elimineer je alvast weer wat mogelijke problemen, als je netwerk goed loopt kun je 'em d'r zo weer tussen hangen

Onder linux kun je zien of Jumbo frames aanstaan dmv. 'ifconfig' (of 'ip link sh', als je iproute2 tools hebt). Beide vermelden de MTU size, die zou bij jumbo frames op 9000 moeten staan.
Windows XP is een ander verhaal, de TCP/IP settings zitten daar (schrik niet) diep in het register weg gepropt. Hiervoor moet je eerst de 'adapter id' opgraven dmv. de registery entries in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Network\{4D36E972-E325-11CE-BFC1-08002BE10318}\<ID for Adapter>\Connection
Volgens is dezelfde key ook terug te vinden in de devicemanager, maar dat weet ik niet meer zeker.

Een erg nuttige handleiding hiervoor en een beschrijving van alle registry settings vind je op technet: TCP/IP and NBT configuration parameters for Windows XP
Hier zit ook de MTU size tussen, samen met andere bruikbare settings.

Zoals je zelf al aangeeft is het het erg waardevol om eerst je netwerk goed te testen, voordat je begint met iSCSI'en. Ik heb hier eerst iperf gebruikt, een netwerk test tooltje waar zowel voor windows als linux en binaries voor te vinden zijn. Eerst maar eens een simpele UDP throughput test doen, hiermee kun je de capaciteit van je netwerk meten zonder dat je moeilijke instellingen hoeft te doen die bij TCP wel nodig zijn. Je moet zelf de bandbreedte opgeven en zodra je packetloss ziet begin je teveel te vragen van je netwerk.

Je kan ook hier de MTU size bepalen (optie '-l' in iperf, zo uit m'n hoofd), als je dit op 9000 zet en de snelheid dondert in elkaar dan komen je 'jumbo frames' niet goed binnen aan de overkant. Het kan ook zijn dat je tcp/ip stack simpelweg weigert te verzenden (bij windows bijv.).

Soms moet je even wat settings proberen voordat je een flink score krijgt. Alles boven de 500mbit vind ik al heel wat, boven 700mbit is stoer, veel hoger gaat 't waarschijnlijk niet.

De volgende stap is TCP, dan zijn er meer settings waar je op moet letten:

• TcpWindowSize, de default window size, staat bij mij op 128k (0x00020148)
• GlobalMaxTcpWindowSize, absolute max., 1M (0x00100000)
• ForwardBufferMemory, grootte van transmit buffer (0x0006de00)
• DisableTaskOffload (0), dit zet Tx/Rx off loading weer aan als je NIC dat ondersteund (hoeft alleen als je SP2 hebt)
• Tcp1323Opts, moet op '3' staan, daarmee enable je automatische window scaling

De TcpWindowSize is een fijne parameter, je kan de eerst de optimale waarde setting opzoeken dmv. iperf en daarna instellen. Vergeet niet dat je bij Windows steeds moet rebooten

Ben benieuwd of je hiermee meer uit je netwerk geperst krijgt

[Dukey]

Ah hier hoor ik thuis...

Vorige week liggen stoeien met Open-E iSCSI-R3 Enterprise demo-cd op m'n server.

Asus P5W64 WS
Intel E6400
2Gb Corsair
8x 500Gig Maxtor's en Western Digital's
Promise Supertrack EX8350
etc

Ben nu nog een proef aan doen met die demo-cd met maar twee 500gig schijven (dat kon m'n raid-6 missen )), maar ik ben zeer positief. Zeker vanwege de simpele werking, had alles draaien binnen 10-15min meen ik. Wat zeker ook positief is, is de ondersteuning van m'n raid controller. De originele Promise beheertool was ingebakken in de software. Heb begrepen dat voor andere raid controller fabrikanten dat ook het geval is. Heb een apart netwerkje gemaakt richting mijn HTPC, allemaal gigabit. Haal snelheden van rond de 40mb/s, waarbij de HTPC de limiterende factor is (zit een oud 40gig schijfe in).

Ging mij vooral om dat ik blu-ray's en hd-dvd's stottervrij kon afspelen over het netwerk, dat lukte me namelijk niet met een normale fileshare. Bij een normale fileshare kreeg ik om de 2-3minuut een hapering in het beeld, als of ie iets wilt laden, wat nogal storend was. Met iSCSI krijg ik zelfs over 100mbit een vloeiend lopende film. Wat ook anders is bij iSCSI is dat je een 100mbit lijn ECHT dicht kan trekken (99%), is me bij een normale ethernet verbinding nooit gelukt. Jumbo frames heb ik trouwens niet aanstaan, levert dit veel verbetering op?

Werd alleen niet zo vrolijk over het prijskaartje van de Open-E versie die ik minstens nodig had, 280 euro. De 160 euro versie kan geen hardware controllers aan.

[ Voor 5% gewijzigd door Dukey op 26-07-2007 08:25 ]

[axis]

Leuke informatie allemaal..

Toen ik dit topic opende zat er in FreeBSD volgens mij nog geen iSCSI-target, nu ondertussen wel. In de ports (net/iscsi-target) zit de target die geport is van NetBSD als ik me niet vergis.

Ik heb vorige week op een van m'n FreeBSD boxes deze geinstalleerd, en ik had in 5 minuten een werkende target. Kwestie van config filetje aanpassen en klaar Jammer alleen dat dit een oude stronttrage doos is, dus geen idee hoe de performance is op snelle hardware met fatsoenlijke disks.

[ Voor 4% gewijzigd door axis op 26-07-2007 14:29 ]

[sPENKMAN]

Een tijdje terug had ik dit topic al bookmarked om in de toekomst ermee te gaan spelen maar ik loop toch vast bij het compilen van de software wanneer ik deze stappen volg. Het compilen gaat zowel bij iscsitarget-0.4.13 als bij iscsitarget-0.4.15 fout met de onderstaande melding:

code:

 make KERNELSRC=../linux-2.6.18
make -C usr
make[1]: Entering directory `/stor/source/iscsitarget-0.4.13/usr'
cc -O2 -fno-inline -Wall -Wstrict-prototypes -g -I../include   -c -o ietd.o ietd.c
cc -O2 -fno-inline -Wall -Wstrict-prototypes -g -I../include   -c -o iscsid.o iscsid.c
cc -O2 -fno-inline -Wall -Wstrict-prototypes -g -I../include   -c -o conn.o conn.c
cc -O2 -fno-inline -Wall -Wstrict-prototypes -g -I../include   -c -o session.o session.c
cc -O2 -fno-inline -Wall -Wstrict-prototypes -g -I../include   -c -o target.o target.c
cc -O2 -fno-inline -Wall -Wstrict-prototypes -g -I../include   -c -o message.o message.c
cc -O2 -fno-inline -Wall -Wstrict-prototypes -g -I../include   -c -o ctldev.o ctldev.c
cc -O2 -fno-inline -Wall -Wstrict-prototypes -g -I../include   -c -o log.o log.c
cc -O2 -fno-inline -Wall -Wstrict-prototypes -g -I../include   -c -o isns.o isns.c
cc -O2 -fno-inline -Wall -Wstrict-prototypes -g -I../include   -c -o chap.o chap.c
chap.c:20:25: error: openssl/sha.h: No such file or directory
chap.c:21:25: error: openssl/md5.h: No such file or directory
chap.c: In function âchap_calc_digest_md5â:
chap.c:303: error: âMD5_CTXâ undeclared (first use in this function)
- soort gelijke foutmeldingen even gestript
make[1]: *** [chap.o] Error 1
make[1]: Leaving directory `/stor/source/iscsitarget-0.4.13/usr'
make: *** [progs] Error 2

De linux-kernel-headers alswel de kernelsource zijn beide aanwezig dus daar lijkt het niet aan te liggen. Nou verwachte ik openssl libs te missen dus deze heb ik met apt-get geinstalleerd maar dit mocht helaas niet baten. Ook het zoeken op Google met de bovenstaande fouten brengt eigenlijk niets naar boven.

Heeft iemand dit probleem wel eens aan de hand gehad?

De "server" is een vmware sessie met kernel versie 2.6.18 met openvz (2.6.18-028stab039). Hoewel het mij niet relevant lijkt is de /stor is een soft raid-5 welke met mdadm is opgezet.

EDIT:
Het was dus de libssl-dev welke ik miste

[alt-92]

JJay schreef op woensdag 25 juli 2007 @ 22:46:
[....]

De TcpWindowSize is een fijne parameter, je kan de eerst de optimale waarde setting opzoeken dmv. iperf en daarna instellen.
Vergeet niet dat je bij Windows steeds moet rebooten

/laat maar behulpzaam:
Rebooten is niet nodig. Adapter disablen en weer enablen heeft hetzelfde effect

Oh, en http://www.rocketdivision.com/news.html :

Rocket Division Software announces free versions of StarWind iSCSI Target and StarPort iSCSI Initiator.
[...]
The free version of StarWind provides up to 2TB of storage capacity and allows only single client host to be connected.

[...]
With the addition of the free StarPort iSCSI initiator customers have a single point of support for both the server side storage SAN and the client side iSCSI agent.

[ Voor 37% gewijzigd door alt-92 op 03-09-2007 15:41 ]

[alt-92]

Vandaag kwam ik ook nog http://www.nimbusdata.com/products/mysan/details.htm tegen.

MySAN is een Windows-based iSCSI target applicatie, en het schijnt gratis te zijn
Ik heb in ieder geval even de RC1 gedownload en ga er binnenkort even een testje mee doen.

[charlie]

Ben deze week aan de slag gegaan met Openfiler.

Heb er toch wel een paar serieuze problemen mee:

Formatteren (zelfs Quick format) gaat enorm traag, reken op een half uurtje voor een volume van een 500 Gb.
Write performance is verbluffend, haar soms tot 90% througput op Gigabit netwerk, 60Mb/sec vanop een raptor is geen enkel probleem. Backup to disk haalt ook vlot tot 3Gb/min, maar als Backup exec aan de verify begint zakt de snelheid tot op het niveau van een floppy drive, om tenslotte gans de server te doen crashen (iSCSI initiator probeert te reconnecten, maar dat lukt niet) ook access tot te web interface lukt niet meer, zelfs een ping komt niet meer terug.
Enkel een reboot brengt hem terug tot leven.

Kopieren van directories met vele kleine files gaat soms ook tergend langzaam. Vreemd genoeg gaat deze snelheid soms omhoog als je tegelijk een andere file kopieert naar hetzelfde volume.

Target server is een Asus P5ND2 met Core2 E4500CPU en 2gb memory. 4X 1Tb SATA en 2X 750Gb PATA schijven.

Ga toch eens met freenas proberen ook ...

[ Voor 0% gewijzigd door charlie op 26-09-2007 11:42 . Reden: freenas ipv opennas ]

[charlie]

Intussen een beetje gespeeld met FreeNas.
Is zelfs niet Beta te noemen. Bedroevende stabiliteit.
Ga nieuwe release, van Openfiler afwachten. Anders wordt het een Linux Distro, of zelfs een windows machine... Wordt vervolgd...

[ronny]

charlie schreef op maandag 15 oktober 2007 @ 14:01:
Intussen een beetje gespeeld met FreeNas.
Is zelfs niet Beta te noemen. Bedroevende stabiliteit.
Ga nieuwe release, van Openfiler afwachten. Anders wordt het een Linux Distro, of zelfs een windows machine... Wordt vervolgd...

Misschien is het verstandig om even contact op te nemen met Enlichtenment
Of eens te kijken in het DIY RAID NAS bouwen
Daar is heel veel info te vinden over FreeNAS. Aangezien er best veel mensen zijn die het al maanden stabiel hebben draaien lijkt mij het toch een redelijk status te hebben verdiend.

[charlie]

ronny schreef op maandag 15 oktober 2007 @ 16:11:
[...]

Misschien is het verstandig om even contact op te nemen met Enlichtenment
Of eens te kijken in het DIY RAID NAS bouwen
Daar is heel veel info te vinden over FreeNAS. Aangezien er best veel mensen zijn die het al maanden stabiel hebben draaien lijkt mij het toch een redelijk status te hebben verdiend.

Heb inderdaad eens op DIY RAID NAS bouwen gekeken, meestal begin ik ook achteraan te lezen, en ik stuutte direct op een medetweaker die dezelfde problemen had ervaren als ik nu. Ik heb ooit oudere build op een VM wel vrij fatsoenlijk aan het draaien gekregen, maar de huidige RC is echt rampzalig te noemen. Vermits ik er toch een paar TB aan backupdata aan wil hangen, wil ik toch liever een systeem waar ik wat meer vertrouwen in heb.

Ben in afwachting trouwens maar eens met OpenSuse en IET... aan de slag gegaan

[axis]

charlie schreef op maandag 15 oktober 2007 @ 20:55:
[...]


Heb inderdaad eens op DIY RAID NAS bouwen gekeken, meestal begin ik ook achteraan te lezen, en ik stuutte direct op een medetweaker die dezelfde problemen had ervaren als ik nu. Ik heb ooit oudere build op een VM wel vrij fatsoenlijk aan het draaien gekregen, maar de huidige RC is echt rampzalig te noemen. Vermits ik er toch een paar TB aan backupdata aan wil hangen, wil ik toch liever een systeem waar ik wat meer vertrouwen in heb.

Ben in afwachting trouwens maar eens met OpenSuse en IET... aan de slag gegaan

Sinds de nieuwe release van Solaris vorige maand, zit er ook een iSCSI target in.. In combinatie met ZFS erg leuk, en heb er al veel over gelezen, maar ben er nog niet aan toe gekomen.. Ik neem aan dat de stabiliteit van Solaris toch wel goed zou moeten zijn, Sun heeft een leger programmeurs in dienst en een hele grote bak met geld..

[axis]

Ik ben trouwens een paar weken geleden aan het testen gegaan met 2 poweredges, en ik haalde daar een schamele 60MB/s met atto benchmark.. Target was ook maar een oude dual xeon 2.8GHz, 2GB, 2*146GB 10.000RPM U320 in RAID0, maar toch vond ik de resultaten tegenvallen.

Netwerk zal niet de bottleneck zijn geweest, ik haalde met iperf 99% van 1Gbps

Bovenstaande waardes die ik had waren trouwens met een FreeBSD target (ze hebben een paar maanden geleden de NetBSD iSCSI target geport, is beschikbaar vanuit de ports), en Windows Server 2003 clients met de Microsoft software initiator.

Ik kan binnenkort als ik een server over heb eens testen met 6*15.000RPM in RAID0 (SAS), kijken ik daar iets meer kan krijgen.

[Paul]

charlie schreef op maandag 15 oktober 2007 @ 20:55:
De huidige RC is echt rampzalig te noemen.

Het is erg irritant dat er een bug in de "full" installatie (dus niet eens de live-cd of zelfs maar de "embedded" install) zat (!, is opgelost in RC2) die je / read-only mount (als in, meteen de eerste keer nadat je het geïnstalleerd hebt, dus het is niet iets dat zich "opeens" ontwikkeld), maar dat is iets wat dus helemaal niets met de stabiliteit, betrouwbaarheid of dataintegriteit te maken heeft. Wel ben ik het met je eens dat het ontzettend slordig is. Je krijgt het idee dat de developers de full-install van RC1 op geen enkele manier getest hebben, want hij gaat op alle manieren fout.

Verder is FreeNAS weinig meer dan een webbased front-end voor Samba, rsync, een ftp-server en zo nog wat.

[Mavvie]

Dankzei een hele nette startpost (wat verouderd maar het werkt wel) is het ook mij gelukt om een iSCSI device te connecten op mijn windows machine.

Nu is het zo dat Lun 0 nu als target /dev/sda1 heeft. Mijn vraag is of het ook mogelijk is om een map als target te gebruiken. Ik ben al bezig geweest om de een map als target te gebruiken maar vervolgens ziet hij geen schijf.

Ik weet namelijk dat bij een 'echte' SAN omgeving er gewoon een Lun aangemaakt wordt en gezegd dat deze lun 8gb is en dat er dan een schijf van 8gb ontstaat als je deze lun connect

[ Voor 19% gewijzigd door Mavvie op 23-05-2008 10:08 ]

[DeBolle]

Dan maak je een partitie van de gewenste grootte en gebruik je dat als target. Als je LVM gebruikt kun je een lvol als target gebruiken.

[Captain Pervert]

Even een bump voor twee vragen.

1. Wat is de meerwaarde van een iSCSI drive boven een netwerkshare? De snelheid?
2. Kan je een iSCSI target opzetten, booten vanaf een diskless client, Windows XP setup starten, F6 indrukken, iSCSI driver opgeven en daarna Windows XP op de iSCSI drive installeren?

[axis]

Captain Pervert schreef op dinsdag 07 oktober 2008 @ 11:18:
Even een bump voor twee vragen.

1. Wat is de meerwaarde van een iSCSI drive boven een netwerkshare? De snelheid?
2. Kan je een iSCSI target opzetten, booten vanaf een diskless client, Windows XP setup starten, F6 indrukken, iSCSI driver opgeven en daarna Windows XP op de iSCSI drive installeren?

Het is een share op een ander niveau.. Als je een windows fileshare neemt, deelt windows bestanden. De server beheert het filesystem, en als een client om een bestandje vraagt, geeft ie dat.

Bij iSCSI werkt het net ietjes anders, een client connect naar de target (server) en geeft aan dat ie wil connecten naar een volume, en vervolgens deelt de target alleen blokjes.. Die target heeft geen flauw idee wat het voor data is, interesseert hem ook niet. De initiator (de client dus) ziet een grote 'disk', een rij met blokjes, en die kun je formatteren met welk filesystem je maar wilt, en windows ziet deze als 'lokale schijf'.

Wat is handiger? Sja, maakt op zich niet zoveel uit, het gaat erom waar de controle over het bestandssysteem ligt, of meerdere clients moeten connecten, etc. Als je excel sheetjes wil delen met je kantoor, heb je niets aan iSCSI (om te delen dan), en aan de andere kant, als je een database server wil draaien, heb je weer (bijna) niets aan een windows fileshare.

Ze hebben beiden hun voor- en nadelen, en zijn op hun eigen manier een verschillend stuk gereedschap op hetzelfde doel te bereiken, namelijk dat je op de ene pc data wil bereiken die op een andere pc staat.

Edit: en euh, je 2 vraag weet ik niet zeker, volgens mij moet dat wel kunnen, alleen heb je misschien hulp nodig van een netwerkkaart die een deel van het bootproces op zich neemt (HBA mode), maar misschien ook wel niet. Misschien kan iemand anders daar antwoord op geven.

[ Voor 7% gewijzigd door axis op 07-10-2008 20:57 ]

[Shuriken]

Captain Pervert schreef op dinsdag 07 oktober 2008 @ 11:18:
Even een bump voor twee vragen.

1. Wat is de meerwaarde van een iSCSI drive boven een netwerkshare? De snelheid?
2. Kan je een iSCSI target opzetten, booten vanaf een diskless client, Windows XP setup starten, F6 indrukken, iSCSI driver opgeven en daarna Windows XP op de iSCSI drive installeren?

1. Inprincipe is iSCSI natuurlijk nooit bedoeld als een file sharing protocol. Maar als goedkopere vervanger van Fiber Channel als SAN verbinding. Dus een vergelijking met CIFS/SMB gaat compleet mank. iSCSI bied je toegang tot een fysieke schijf geen share. Het voordeel is dat je bevoorbeeld zelf kan kiezen wat voor filesystem je gebruikt (NTFS, Ext3 enz) maar in de profesionele sfeer brengt het natuurlijk nog wat extra zaken.

2. B.v. Intel ondersteund in een aantal NIC kaarten iSCSI boot. Ik neem aan dat je daarmee een systeem zou moeten kunnen booten vanaf SAN.

[spone]

Misschien leuk om te vermelden dat Etherboot/gPxE (http://etherboot.org/wiki/) een systeem via PXE, floppy of iso ook kan booten vanaf een iSCSI of AoE target, zonder dat de netwerkkaart daar specifiek ondersteuning voor hoeft te bieden.

[ Voor 19% gewijzigd door spone op 15-10-2008 20:45 ]

[Verwijderd]

alt-92 schreef op dinsdag 25 september 2007 @ 23:11:
Vandaag kwam ik ook nog http://www.nimbusdata.com/products/mysan/details.htm tegen.

MySAN is een Windows-based iSCSI target applicatie, en het schijnt gratis te zijn
Ik heb in ieder geval even de RC1 gedownload en ga er binnenkort even een testje mee doen.

Gek, hij is na ruim 1,5 jaar nog steeds RC1.

Ik ga i.i.g. ook iSCSI gebruiken. Ik heb er nog wel even een vraag over. Kan de plek waar de target naar linkt ook gewoon een file (=deel van een partitie) zijn? Of moet het een hele partitie zijn?

[Shuriken]

Verwijderd schreef op zaterdag 28 februari 2009 @ 20:17:
[...]

Gek, hij is na ruim 1,5 jaar nog steeds RC1.

Ik ga i.i.g. ook iSCSI gebruiken. Ik heb er nog wel even een vraag over. Kan de plek waar de target naar linkt ook gewoon een file (=deel van een partitie) zijn? Of moet het een hele partitie zijn?

Onder Linux is dat wel een mogelijkheid. Of dat met Nimbus Mysan kan weet ik niet.

[Verwijderd]

darkmage schreef op zondag 25 februari 2007 @ 13:03:
Eh, bierkameel, het zal linux in dit geval scheit wezen wat er op de schijven aan FS staat. De schijven worden op block nivo via iSCSI doorgesluisd naar de windows initiator, die de schijven dan als fysieke ziet. Voor windows zijn de schijven verplaatst naar een andere controller.

Je bedoelt (fysiek) blockniveau van de schijf? M.a.w. alles wat op de schijf stond (Fat32, NTFS, etc.) voordat deze beschikbaar werd gemaakt via iSCSI blijft gewoon zichtbaar door de iSCSI link? Dat zou wel erg handig zijn zeg...

[ Voor 4% gewijzigd door Verwijderd op 28-02-2009 23:54 ]

[axis]

Verwijderd schreef op zaterdag 28 februari 2009 @ 23:53:
[...]

Je bedoelt (fysiek) blockniveau van de schijf? M.a.w. alles wat op de schijf stond (Fat32, NTFS, etc.) voordat deze beschikbaar werd gemaakt via iSCSI blijft gewoon zichtbaar door de iSCSI link? Dat zou wel erg handig zijn zeg...

Bij veel iSCSI targets kun je kiezen waar je je data op wilt zetten. Een raw stukje schijf (partitie, slice, etc), of in een file binnen je bestaande filesystem.

Op een BSD machine kan ik zo een nieuwe 10GB file aanmaken ergens in een mapje naar mijn keuze, en die kiezen als 'backend' voor een iSCSI lun.


Oud topic dit trouwens, maar nog steeds erg leuk. Ondertussen heb ik ook al wat meer ervaring met iSCSI op de zaak.. Ff pimpen:

[Verwijderd]

axis schreef op zondag 01 maart 2009 @ 13:04:
Oud topic dit trouwens, maar nog steeds erg leuk.

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?

[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.