[ESX] Datastore voor OS per VM?

[BP_LOZ]

Ik heb met een collega een discussie over het gebruik van datastores in ESX4.
Hij stelt voor om een datastore beschikbaar te maken (bijv. 500GB) voor de installatie van het OS.
Overige disks zijn overigens iSCSI volumes.
Als datastore deze vol zit wil hij een volgende aanmaken die ook weer 500GB groot is.

Ik zeg per VM een datastore aan maken van 100GB?.
Als ik per VM een datastore maak, dan heb ik dus ook op mijn SAN 1 volume per VM. Raakt een volume corrupt of wat dan ook, dan verlies ik "slechts" 1 machine.
Ik vind dit ook overzichtelijker, maar dat is persoonlijk.
Verder heb ik op deze manier 1 lun per machine, wat m.i. beter perfomeerd dan 8 machines op 1 lun.

Wat zeggen jullie?

[ Voor 7% gewijzigd door BP_LOZ op 25-02-2010 13:19 ]

[FireDrunk]

Datastore != LUN toch?
in 1 datastore kun je toch meerdere volumes maken die je weer aan machine's geeft?

[BP_LOZ]

Misschien verwoord ik mij niet goed.
Op het SAN wil hij 1 volume aanmaken en daar meerdere VM's op kwijt, waar ik zet per VM een volume.

[FireDrunk]

Ik zou op je SAN 1 groot volume aanmaken, die als datastore in ESX hangen, en daar meerdere VM's op aanmaken...

Tenzij ik gek ben hoor

[BP_LOZ]

thijs_cramer schreef op donderdag 25 februari 2010 @ 12:29:
Ik zou op je SAN 1 groot volume aanmaken, die als datastore in ESX hangen, en daar meerdere VM's op aanmaken...

Tenzij ik gek ben hoor

Waarom zou je hiervoor kiezen en kun je dat onderbouwen?

[ Voor 7% gewijzigd door BP_LOZ op 25-02-2010 12:32 ]

[FireDrunk]

Omdat je VM's dan een dynamische size kunnen hebben.
Zonder omkijken kan 1 van de vm's dus 400GB in gebruik nemen en de rest de overige 100GB.
In jou situatie zou je per VM steeds moeten controleren of de ruimte nog wel genoeg is...

[Question Mark]

BP_LOZ schreef op donderdag 25 februari 2010 @ 12:30:
[...]

Waarom zou je hiervoor kiezen en kun je dat onderbouwen?

Hoe meer spindels in je LUN/Datastore, des te beter je disk I/O performance over het algemeen wordt.

[RvV]

Ik zou het liefst grote datastores maken waar je veel VM's in zet. Hoewel VMware zelf aan geeft liefst niet al te groot te gaan (500GB en 10VM's max dacht ik?) heb ik zelf nog geen problemen gehad met LUN's van 1,5TB en 20+ VM's..

Je hebt veel loze ruimte als je veel datastores aanmaakt omdat je per datastore een bepaalde ruimte wilt resereren voor je snaps.

[FireDrunk]

Question Mark schreef op donderdag 25 februari 2010 @ 12:35:
[...]

Hoe meer spindels in je LUN/Datastore, des te beter je disk I/O performance over het algemeen wordt.

Het is toch een SAN... Dus netwerkgelimiteerd lijkt me

[Verwijderd]

best practice is een datastore van 500-1000GB aanmaken en deze vullen met VMs, rekening houdend met snapshots en andere (tijdelijke) bestanden 5-10% vrij houden op de datastore

als je per VM een datastore wilt hebben, heb je veel loze ruimte, is het omslachtiger een vmdk uit te breiden, moet je voor elke nieuwe VM een datastore aanmaken, moet je meer monitoren, flink veel overhead dus, en voor zover ik kan bedenken, heeft het geen voordelen

8x 1 VM per datastore heeft niet per definitie een betere performance dan 1x 8 VMs op een datastore, de I/O op de HBA's van de host en op de SAN controller zijn gelijk

[FireDrunk]

Er zou hoogstens wat Caching voordeel kunnen ontstaan door Read-Ahead... Maar ik denk ook (zoals Frivole Hnkie zegt) dat dat te verwaarlozen is...

[Question Mark]

thijs_cramer schreef op donderdag 25 februari 2010 @ 12:38:
[...]
Het is toch een SAN... Dus netwerkgelimiteerd lijkt me

Ligt compleet aan het SAN. San's waar wij onze ESX datastore op hebben staan zijn met 8GB fiber gekoppeld aan de hosts. Reken maar uit wat de bandbreedte dan is. Dan heb je echt wel wat spindels nodig wil je dat volkrijgen.

[FireDrunk]

Question Mark schreef op donderdag 25 februari 2010 @ 12:53:
[...]
Ligt compleet aan het SAN. San's waar wij onze ESX datastore op hebben staan zijn met 8GB fiber gekoppeld aan de hosts. Reken maar uit wat de bandbreedte dan is. Dan heb je echt wel wat spindels nodig wil je dat volkrijgen.

I stand corrected, ik ging uit van simpel 1GBit iSCSI... Maar dat is ook alweer verouderd ;P

[Question Mark]

thijs_cramer schreef op donderdag 25 februari 2010 @ 12:55:
[...]
I stand corrected, ik ging uit van simpel 1GBit iSCSI... Maar dat is ook alweer verouderd ;P

Het gaat hier ook over ISCSI, maar tegenwoordig zie ik al heel vaak dat fiber vervangen wordt door 10GB Ethernet. Voor een simpel SAN heb je overigens gelijk. Daar is je bandbreedte van 1 GB al vaak je bottleneck.

Storageinrichting ligt verder ook aan het type SAN en de mogelijkheden hiervan. Met meerdere controllers in het SAN kan het een voordeel zijn om meerdere Lun's aan te maken. Elke Controller kan dan een active path naar dit LUN krijgen.

Beetje zonde om één Lun aan te maken met één active path naar slechts één controller. Dan zou één van je dure controllers (het passive path) niets te doen hebben. In zulke gevallen kun je beter je I/O verdelen door dan twee LUN's aan te maken.

[BP_LOZ]

Chips.. Ik moet dus concluderen dat niet ik maar mijn collega gelijk heeft.

[Verwijderd]

BP_LOZ schreef op donderdag 25 februari 2010 @ 13:12:
Chips.. Ik moet dus concluderen dat niet ik maar mijn collega gelijk heeft.

ik hoop voor je dat je er niet te veel kratten bier op hebt ingezet

in principe moet je virtuele storage zien als een grote storagepool en zo min mogelijk datastores aanmaken om administratieve overhead te beperken en zoveel mogelijk met scalability te kunnen doen

[ Voor 27% gewijzigd door Verwijderd op 25-02-2010 13:16 ]

[FireDrunk]

BP_LOZ schreef op donderdag 25 februari 2010 @ 13:12:
Chips.. Ik moet dus concluderen dat niet ik maar mijn collega gelijk heeft.

Jup, gl with that