Toon posts:

[ESX] vm met veel data aanbieden via iSCSI

Pagina: 1
Acties:

  • Remco
  • Registratie: januari 2001
  • Laatst online: 21:21
Wij hebben een fc SAN waarop wij een fileserver willen gaan virtualiseren. Echter heeft deze server veel data (ongeveer 500 Gb). Nu was het plan om de server te virtualiseren en de data aan te bieden via iSCSI wat ook op hetzelfde SAN draait.
Maar nu vroeg ik me af of we de data niet via onze glas (2 * 8Gbit) verbinding met het SAN kunnen benaderen. Deze verbinding is veel sneller, en hoeft de data niet via onze switches dan te benaderen.
Kan zoiets met RDM ? Of moet het vanuit de vm gebeuren, zoals we zouden gaan doen met de iSCSI implementatie.

The best thing about UDP jokes is that I don't care if you get them or not.


  • djeems
  • Registratie: augustus 2010
  • Laatst online: 11-06-2014
wat is nu precies de bedoeling?
een SAN is iets anders als een ESX host en rdp en iSCSI kun je ook niet vergelijken.

doe je het beheer zelf? anders iemand raadplegen die meer hiervan weet...

  • RvV
  • Registratie: juli 2000
  • Laatst online: 22:00
Eigenlijk vraag je jezelf dus af of je de data binnen de VM moet houden of het appart op een iSCSI lun moet aanbieden? Binnen de VM kun je ook een share aanmaken en klaar.. data op een iSCSI lun kun je niet echt makkelijk aanbieden aan medewerkers.
Ik weet niet precies wat voor data het is, maar wij hebben op onze EMC een CIFS server gemaakt. Dat is handiger.

  • Remco
  • Registratie: januari 2001
  • Laatst online: 21:21
RvV schreef op maandag 11 oktober 2010 @ 19:42:
Eigenlijk vraag je jezelf dus af of je de data binnen de VM moet houden of het appart op een iSCSI lun moet aanbieden? Binnen de VM kun je ook een share aanmaken en klaar.. data op een iSCSI lun kun je niet echt makkelijk aanbieden aan medewerkers.
Ik weet niet precies wat voor data het is, maar wij hebben op onze EMC een CIFS server gemaakt. Dat is handiger.
Klopt, daar twijfelen we over. Als ik lees op VMware is het niet echt best practice om grote datastores aan te maken. Echter VMware geeft geen harde cijfers over het aantal vm's en Gb's per datastore. Maar wij hebben zo'n beetje alle postings doorgenomen en zijn tot een gemiddelde gekomen van ongeveer 500 Gb per datastore en een max van 15 vm's per datastore.
Ik wil eigenlijk dus niet de data plaatsen in een datastore, maar op iSCSI. Maar als je bedenkt hoe het path dan gaat lopen, is vanuit de vm net netwerk op en weer terug het SAN in naar het iSCSI target. Makkelijker zou zijn als ik dat target via fc kan benaderen.
De data waarom het gaat zijn user en team directories. Losse bestandjes dus.
Ons SAN heeft geen CIFS optie.

The best thing about UDP jokes is that I don't care if you get them or not.


  • Remco
  • Registratie: januari 2001
  • Laatst online: 21:21
djeems schreef op maandag 11 oktober 2010 @ 19:35:
een SAN is iets anders als een ESX host en rdp en iSCSI kun je ook niet vergelijken.
Volgens mij begrijp je me niet helemaal.
Lees anders ook nog eens de post van hierboven door.

The best thing about UDP jokes is that I don't care if you get them or not.


  • TheBorg
  • Registratie: november 2002
  • Laatst online: 21:14

TheBorg

Resistance is futile.

djeems schreef op maandag 11 oktober 2010 @ 19:35:
anders iemand raadplegen die meer hiervan weet...
Precies, op een forum ofzo. Kijk eens op GoT. :+

  • Dronium
  • Registratie: januari 2007
  • Laatst online: 23:46
Over hoeveel data praten we eigenlijk? en welk OS? wat voor Storage heb je? (fc SAN's zijn er zoveel)

Een VMFS datastore kan met extends aardig opgerekt worden, er zit echter een beperking in de maximale grote van een VMDK-file, namelijk 2 TB. Daarmee word de grote van een basis disk dus ook beperkt tot 2 TB. Maar je kunt natuurlijk meerdere disks voor je server aanmaken.

Bij iSCSI word je mogelijk beperkt door de snelheid van je netwerk, maar kun je inderdaad volumes maken zo groot als je storage kan verzorgen.

Een ander alternatief is mogelijk het gebruik van RDM's (Raw Device Mappings), daarmee koppel je een LUN van je storage direct aan een VM. Hierbij loopt het verkeer server <-> disk dus gewoon over je fibre connecties maar heb je net als bij iSCSI geen beperking van 2 TB per disk.

Als je, ook in de toekomst, onder de 2 TB denkt te blijven zou ik echter gewoon kiezen om het in een VMDK te zetten, dat bied bij virtualizatie de meeste flexibiliteit.

  • ItsValium
  • Registratie: juni 2009
  • Laatst online: 22:24
Lijkt me allemaal een beetje verward overkomen zoals ik het lees, echter zou ik je aanraden om gewoon je data via een normale windows-share vanuit een vm aan te bieden. Veel makkelijker werken, ook voor medewerkers en anderen, terwijl aanbieden via iSCSI-shares zonder tussenkomst van je VM het een pak gecompliceerder maakt voor de gebruikers.

Dit houd het wat overzichtelijker denk ik tov het gemengd gebruik van normale shares en iSCSI-shares. En wees gerust wat je opmerking betreft over 15 VM's op datastores van max 500GB, ik werk dagelijks met veel grotere aantallen VM's op grotere datastores en heb er geen enkel probleem mee. Op voorwaarde dat je SAN de nodig IOPS kan leveren natuurlijk.

  • Remco
  • Registratie: januari 2001
  • Laatst online: 21:21
Ik bedoel het inderdaad anders. De data word via standaard windows shares via de AD aangeboden. Echter is het nu een fysieke machine met local storage.
Nu wil ik liever niet de storage in mijn vm zetten. Dus blijft er iSCSI over, om toch de data via een windows share aan te bieden.
Alleen dan gaat het verkeer een beetje heen en weer. Dus vroeg ik me af of we de data kunnen publiceren via een windows share, maar de server de data niet via iSCSI, maar via fc te laten benaderen.

Het maximaal aantal vm's per datastore heeft niet zoveel te maken met het aantal IOPS, maar wel met het locken.
The reason for limiting the number of VM's per datastore is due to SCSI reservations, the VMFS file system stores meta data about the files on a VMFS system and that meta data describe who has access to what files/VM's. For a change in the meta data, i.e. which server is allowed to access a file. ESX server will send out a SCSI reservation to lock it so that other ESX servers cannot change it at the same time (which could cause corruption) This allows multiple servers to access the same file system and prevent corruption. These meta data changes happen when a VM is turned on or off, hence the VM's files are assigned to the ESX server that is running that machine at the time. This also happens when Vmotion moves a machine from one physical host to another, hence updating the meta data that tells which ESX server has access to those files. There are also other things that can cause a SCSI reservation, but powering on and off, and Vmotion are the big two. And of coures higher I/O Guests will increase the contention for SCSI reservations increasing the risk that a lock will conflict with another, which will cause a failure to reservere a lock and the operation will return as a failed operation.

The best thing about UDP jokes is that I don't care if you get them or not.


  • GH45T
  • Registratie: november 2003
  • Laatst online: 20-09 08:54
Hoe bedoel je dit alles nu eigenlijk, ik lees server virtualiseren op je SAN en RDP in combinatie met fibrechannel, hoe je die combinaties maakt begrijp ik niet helemaal.

Maar je bedoelt waarschijnlijk dat je een VM maakt op een ESX host en van daaruit via fibrechannel met je SAN verbinding maakt, correct?

Als je ESX host een fibrechannel controller heeft en deze is ook verbonden met de SAN dan moet dat kunnen. Je kunt gewoon een LUN aanspreken via fibrechannel, dat hoeft niet perse per iSCSI.

  • Remco
  • Registratie: januari 2001
  • Laatst online: 21:21
Ik wil inderdaad via ESX een fileserver virtualiseren. De datastore van ESX staat op een SAN welke gekoppeld is via 2 * 8 Gb fc.
Ik wil de data niet in de vm zelf zetten.
De enige mij bekende manier is dan om de data via iSCSI aan de server aan te bieden die deze dan weer aan via een windows share deelt.
Echter zat ik me af te vragen of ik niet de data via de fiber kaarten kan benaderen, dat is toch aanzienlijk sneller en belast mijn ethernet switches niet.
RDP is een typo. Moet dus RDM zijn.

The best thing about UDP jokes is that I don't care if you get them or not.


  • MoBi
  • Registratie: oktober 1999
  • Laatst online: 16-09 11:11
Data via je fiberkaarten benaderen kan via een RDM, Je maakt een lun aan op je fc san, koppelt deze via rdm aan een virtuele fileserver als disk. Kopieert de data van je oude fysieke server naar je virtuele op de rdm disk. En deelt het geheel via je virutele windows share.

Volgens mij zit je te lullen, want ik voel nattigheid....


  • Bloodshot
  • Registratie: maart 2006
  • Laatst online: 22-09 16:27
Een virtuele file-server? Past dat goed bij de disk-i/o-bottleneck waar VM's relatief snel last van hebben?

  • Ethirty
  • Registratie: september 2007
  • Nu online

Ethirty

Who...me?

Kan je niet een LUN aanmaken op je SAN voor je data, de file-server virtualiseren en dan een RDM mappen naar je data-LUN?

De limiet voor een VMFS is volgens VMware rond de 2TB. Daarnaast vraag ik me af hoe handig het is om een vmdk van ~500GB te hebben. Dit kan sowieso alleen als je VMFS is geformateerd met >2MB blocksize.

#team_UTC+1

An investment in knowledge always pays the best interest - Benjamin Franklin
You can call me McOverloper  Mini '12 i7/16/256  Air '13 i5/8/256  iPad mini 5 64GB  iPhone 8 64GB


  • redfoxert
  • Registratie: december 2000
  • Niet online
Remco schreef op dinsdag 12 oktober 2010 @ 01:32:
Alleen dan gaat het verkeer een beetje heen en weer.
Als je weet hoeveel verkeer er door de server nu gaat kan je bepalen of je de data binnen je VM wilt houden of via een iSCSI connectie op je SAN moet zetten geshared via een virtuele server.

Persoonlijk zou ik voor die laatste optie kiezen, ook vanwege backup mogelijkheden, in plaats van de data binnen je VM te houden.

  • MagicTempest
  • Registratie: maart 2001
  • Laatst online: 12:24

MagicTempest

Fly pig!

Wij hebben hier meerdere fileservers virtueel met daaraan raw luns gekoppeld. Dit werkt gewoon zonder problemen. De performance is overigens wel beduidend lager dan wanneer je fysieke servers met fysieke storage hebt.

Ik denk dat als je iSCSI gebruikt de performance zelfs nog een stuk lager zal zijn in vergelijking met fc.

With sufficient thrust pigs fly just fine. However, this is not necessarily a good idea. It is hard to be sure where they are going to land, and it could be dangerous sitting under them as they fly overhead. rfc 1925


  • SpamLame
  • Registratie: augustus 2000
  • Laatst online: 23-09 09:10
Hoi Remco

Wat het makelijkste is om je huidige fileserver te virtualiseren, is om de bestaande LUN aan te houden (ook wanneer je fileserver gevirtualiseert is). Waarbij ik nu dus de aanname doe dat je huidige data ook al op het SAN staat.
Dit kan je doen door alleen RDM maar ik zou kiezen voor RDM icm NPIV , waarmee je WWN's voor je VM kan creeeren.
Zodra dat gedaan is kan je middels de bekende methode als Zoning, Mapping en Masking je LUN kopppelen aan je VM.
Nadeel, als je het zo wilt noemen, is wel dat je VM het SAN zien kan. Drivers (denk aan MPIO bv) die je op een fysieke host installeert zal je ook binnen de VM moeten installeren.

Of iSCSI slechter performt dan FC valt niet te zeggen, omdat je niks over je netwerk vertelt, daarnaast is het afhankelijk van de infrastructuur en inrichting.
Stel dat je je server inricht met 10G iSCSI HBA's dan zou je performance ongv. gelijk kunnen zijn.

[Voor 24% gewijzigd door SpamLame op 12-10-2010 17:01. Reden: Hmmz lees nergens dat je huidige datat ook op het SAN staat]

WoWs-id dionvdc_ wows numbers wows referral


  • Question Mark
  • Registratie: mei 2003
  • Laatst online: 16:08

Question Mark

Moderator SWS/WOS

F7 - Nee - Ja

SpamLame schreef op dinsdag 12 oktober 2010 @ 16:40:
Dit kan je doen door alleen RDM maar ik zou kiezen voor RDM icm NPIV , waarmee je WWN's voor je VM kan creeeren.
Wat is in het geval van de TS hier het voordeel van tov een regulier RDM?

MCSE NT4/2K/2K3, MCTS, MCITP, CCA, CCEA, CCEE, CCIA, CCNA, CCDA, CCNP, CCDP, VCP, CEH + zwemdiploma A & B

Pagina: 1


Nintendo Switch (OLED model) Apple iPhone 13 LG G1 Google Pixel 6 Call of Duty: Vanguard Samsung Galaxy S21 5G Apple iPad Pro (2021) 11" Wi-Fi, 8GB ram Nintendo Switch Lite

Tweakers vormt samen met Hardware Info, AutoTrack, Gaspedaal.nl, Nationale Vacaturebank, Intermediair en Independer DPG Online Services B.V.
Alle rechten voorbehouden © 1998 - 2021 Hosting door True

Tweakers maakt gebruik van cookies

Bij het bezoeken van het forum plaatst Tweakers alleen functionele en analytische cookies voor optimalisatie en analyse om de website-ervaring te verbeteren. Op het forum worden geen trackingcookies geplaatst. Voor het bekijken van video's en grafieken van derden vragen we je toestemming, we gebruiken daarvoor externe tooling die mogelijk cookies kunnen plaatsen.

Meer informatie vind je in ons cookiebeleid.

Sluiten

Forum cookie-instellingen

Bekijk de onderstaande instellingen en maak je keuze. Meer informatie vind je in ons cookiebeleid.

Functionele en analytische cookies

Deze cookies helpen de website zijn functies uit te voeren en zijn verplicht. Meer details

janee

    Cookies van derden

    Deze cookies kunnen geplaatst worden door derde partijen via ingesloten content en om de gebruikerservaring van de website te verbeteren. Meer details

    janee