SAN fysiek koppelen aan ESX machine

[Verwijderd]

Hallo allemaal,

Wij hebben op kantoor een discussie hoe we een san het beste kunnen koppelen aan een esx machine.
Het gaat hierbij om een Fujitsu TX 150 S6 icm met een qnap 859 nas.
De nas zal voorzien worden van 3 isci targets, 2 voor 2 esx datastores waarin 2 virtuele machines komen en 1 voor de data. Het isci target voor de data willen we dan direct in een 2008 server koppelen zonder tussenkomst van vmware.Nu is het onze bedoeling om de server te voorzien van een extra gigabit netwerk kaart zodat we de server met een netwerk kabel 1 op 1 op de nas aan kunnen sluiten. Mijn baas vind dit echter geen goed idee en vind dat we alles via een switch aan moeten sluiten. Ter verduidelijking 2 overzichten van beide mogelijkheden.





Wat vinden jullie?

[Jazzy]

Wat zijn je argumenten om een aparte NIC te gebruiken? Waarom vind jouw baas een switch beter?

Als die servers een beetje uit hun neus staan te peuteren dan zal het allemaal wel over 1 NIC werken. Als performance belangrijk is dan wil je een dedicated NIC voor iSCSI, tenzij die ene NIC teovallig een 10 Gb is. Als beschikbaarheid belangrijk is dan wil je alle NICs redundant uitvoeren.

Hoop dat je hier wat aan hebt.

Edit: Op de rest van het plaatje valt ook nog wel wat aan te merken en aangezien je de moed hebt om dit in P(rofessional)NS te plaatsen zullen anderen je daar wel op wijzen.

[ Voor 17% gewijzigd door Jazzy op 16-03-2012 21:19 ]

[Verwijderd]

Nou laat ik het zo zeggen, hij vind het niet nodig om hier een aparte nic voor te gebruiken (zit standaard 1 nic in een tx 150)

Alles zal aangesloten worden op een gigabit switch dus dan heeft een 10 Gb nic niet veel meerwaarde denk ik.
Er komen 2 2008 standaard servers op te draaien waarvan 1 dc is, de ander word een app server.
Het lijkt mij dat er zonder tussenkomst van een switch meer performance bereikt kan worden tussen de datastore en esx server.
Daarnaast kan ik eventueel de 2e nic van de nas nog aansluiten op de switch voor het isci target waar de data op komt.

[LeLo]

Meer bandbreedte is in de praktijk altijd aan te raden bij virtuele opstellingen met iSCSI oplossingen. Het ligt een beetje aan de verwachtte drukte op het LAN en het iSCSI netwerk, maar juist als je door een server (LAN) een grote hoeveelheid data van de storage (iSCSI) nodig hebt, zal het delen van één kabeltje een beperking worden.
Een extra netwerkkaartje lijken me ook de kosten niet in dit geval, dus mijn advies zou zijn om voor nu het iSCSI netwerk met een eigen NIC aan te sluiten op het NAS, later kun je dan met een extra switch zelfs een compleet iSCSI netwerk maken als je met fail-over op meerdere VMWare servers of QNAP's wilt gaan werken.

[Midas.e]

vooral aangezien de qnap multipath ondersteund zou ik de server uitrusten met 2 nics minimaal en dat lekker trunken met verschillende vlans voor iscsi en data, daarmee heeft je esx machine zowel voor iscsi meerdere gbits en voor je data netwerk hetzelfde, meer bandbreedte dus.

[Question Mark]

Verwijderd schreef op vrijdag 16 maart 2012 @ 21:11:
Het isci target voor de data willen we dan direct in een 2008 server koppelen zonder tussenkomst van vmware.

Waarom deze keuze, en waarom niet bv. via VMWare een vmdk, of een RDM aanbieden?

[GH45T]

wat zijn de verdere plannen, zal het waarschijnlijk uitgebreid gaan worden? wij hebben voor een sas oploasing gekozen ivm de performance. iscsi van 2 vm's op 1 gigabit lan kaart waar eventueel ook nog je data overheen gaat is gewoon een keiharde beperking. Nu is storage vaak de bottleneck. nu performed iscsi behoorlijk goed, maar de pakweg 125MB/s is bij gigabit lan een keiharde limiet.

[ralpje]

Met het oog op de toekomst: verwacht je dat je virtuele omgeving gaat groeien? Op het moment dat je het spul met een switch gaat uitrusten kun je wel makkelijker groeien in de toekomst. Extra fysieke host erbij, kabeltje in iSCSI-lan en dezelfde storage kunnen gebruiken.

[Verwijderd]

Bedankt voor al jullie reacties.

Waarom zou je er nog een laag tussen zetten door er een vmdk van te maken? Extra laag vertraagd alleen maar denk ik?

Ik denk niet dat het snel uitgebreid zal worden, maar we gaan morgen gewoon testen.
eerst met 1 nic en als het dan niet snel genoeg gaat doen we er een 2e bij in

[Freeaqingme]

vmdk's kan je wel op blocklevel gebruiken, dus hoeft niet echt te vertragen. Voordeel van vmdk's is dat je ze vanaf meerdere locaties kan mounten, en daardoor veel makkelijker een failover kan inrichten.

[cleopet]

Freeaqingme schreef op woensdag 21 maart 2012 @ 19:48:
vmdk's kan je wel op blocklevel gebruiken, dus hoeft niet echt te vertragen. Voordeel van vmdk's is dat je ze vanaf meerdere locaties kan mounten, en daardoor veel makkelijker een failover kan inrichten.

Dan nog, zelf zou ik eerder naar NFS kijken dan iscsi voor de esx datastores. Het maakt de schaalbaarheid -gezien vanuit de storage- veel flexibeler als een lun.

Het lijkt me dat de TS even goed moet inventariseren wat zijn wensen voor de toekomst zijn. Voor nu lijkt het een lood-om-oud-ijzer verhaal.
Als de te gebruikten switch Port Trunking/NIC Teaming van de Qnap ondersteund zou ik zelf denk ik voor de switch gaan.

Overigens:
Hoewel ik natuurlijk niet weet waar je de 2008 server met de directe datakoppeling naar de NAS voor gaat gebruiken, wijs ik je op het feit dat de NAS ook direct CIFS kan praten met de clients :-)