DFS i.s.m. VMware 4.1

[Verwijderd]

Beste IT'ers,

Wij hebben op dit moment een Fysieke DC met File server rol in één. Wij willen deze rollen van elkaar los koppelen (i.v.m. migratie naar een nieuw SAN en upgrade van w2k3 r2 naar w2k8 r2 DC).

Nu het volgende. Wij voeren beleid om zo veel mogelijk servers te gaan virtualiseren, maar zitten met VMware 4.1.0 ESXi met een limiet van 2 TB op onze datastores.

Ik heb al onder Windows 2 datastores van 2 TB aan de server toegewezen en dara een spanned volume van gemaakt. Ik heb daar als test een hoop data naar toe gekopieërd, maar liep tegen het probleem aan, dat VMware eerst één data store volschrijft en dan pas de andere. Je raad het al, als in VMware een datastore helemaal volloopt, dan gaat een machine down.

Ik heb toch het liefst één partitie van 4 TB in totaal op de fileserver. Daarmee DNS inrichten voor replicatie naar een andere site (gaat om +/- 200 GB data dat gerepliceerd moet worden).

Ik hoor graag wat opties van jullie.

Alvast hartelijk dank!

[MdBruin]

Maak je wel gebruik van een aparte data partitie?
Zelf zou ik een OS en een data partitie aanmaken, dan zou als de data partitie vol raakt niet de virtuele machine down moeten gaan.

Andere optie is om een iSCSI target aan te maken op je SAN en deze aan je VM te hangen, dan zou je geen last van de limiet mogen hebben.

[Turdie]

Hiervoor kun je volgens mij een RDM(Raw Device Mapping) gebruiken.

[MAX3400]

Een datastore van 2TB en die krijg je vol door hoe?

Volgens mij maak je de verwarring met datastores & virtual disks; zolang je je virtual disks netjes "bedenkt" en inricht, hoeft je datastore helemaal niet vol te lopen. Hierdoor hoef je dus ook je datastores niet aan elkaar te koppelen/spannen.

[kroegtijger]

MdBruin schreef op donderdag 16 augustus 2012 @ 11:34:
Andere optie is om een iSCSI target aan te maken op je SAN en deze aan je VM te hangen, dan zou je geen last van de limiet mogen hebben.

Dat lijkt mij de beste en waarschijnlijk ook de snelst werkende oplossing inderdaad

[My-life]

MAX3400 schreef op donderdag 16 augustus 2012 @ 11:38:
Een datastore van 2TB en die krijg je vol door hoe?

Volgens mij maak je de verwarring met datastores & virtual disks; zolang je je virtual disks netjes "bedenkt" en inricht, hoeft je datastore helemaal niet vol te lopen. Hierdoor hoef je dus ook je datastores niet aan elkaar te koppelen/spannen.

Precies, als je een disk van 1.9TB aanmaakt op een datastore van 2TB dan kan hij niet vollopen.

Is het overigens niet mogelijk om de data op de fileserver te splitsen? Als het bijvoorbeeld meerdere shares zijn lijkt mij dit een betere oplossing. Ook handiger met bijvoorbeeld back-ups en in de toekomst bij andere migraties.

[ Voor 18% gewijzigd door My-life op 16-08-2012 12:11 ]

[kroegtijger]

My-life schreef op donderdag 16 augustus 2012 @ 11:59:
[...]

Precies, als je een disk van 1.9TB aanmaakt op een datastore van 2TB dan kan hij niet vollopen.

Is het overigens niet mogelijk om de data op de fileserver te splitsen? Als het bijvoorbeeld meerdere shares zijn lijkt mij dit een betere oplossing. Ook handiger met bijvoorbeeld back-ups en in de toekomst bij andere migraties.

Zou ook een mogelijkheid zijn, maar dat betekend dat je dus 0.1TB niet gebruikt, en dat is eigenlijk ook wel weer zonde... Waarom niet via iSCSI je verbinding maken? Dan kan je ook nog gaan uitbreiden in de toekomst

[Question Mark]

MdBruin schreef op donderdag 16 augustus 2012 @ 11:34:
Andere optie is om een iSCSI target aan te maken op je SAN en deze aan je VM te hangen, dan zou je geen last van de limiet mogen hebben.

Let wel op dat dit qua support een beetje een grijs gebied is. Verder moet je zaken zoals beschikbaarheid en multipathing nu vanuit je VM gaan regelen, terwijl dit voor je hosts allemaal al geregeld is. Aanbieden als RDM is dan veel eenvoudiger.

kroegtijger schreef op donderdag 16 augustus 2012 @ 12:24:
[...]
Zou ook een mogelijkheid zijn, maar dat betekend dat je dus 0.1TB niet gebruikt, en dat is eigenlijk ook wel weer zonde...

Lijkt me niet... Een datastore wil je helemaal niet tot de nok toe vol hebben. Dat levert juist problemen op (geen ruimte meer voor .vswp bestanden en snapshots).

[ Voor 29% gewijzigd door Question Mark op 16-08-2012 12:57 ]

[Rolfie]

Je moet je ook vragen of je wel 2TB LUNS wil hebben?

Voor IO performance is het vaak, hoe meer LUNs hoe beter de performance.
We houden bij ons 600GB Luns aan wat goed te backup maar ook goed te checkdisken is.

Je zou het LUN nog kunnen groten naar 1TB. Maar veel groter zou ik ze niet snel maken.
DFS of anders MP werkt goed.

[kroegtijger]

Question Mark schreef op donderdag 16 augustus 2012 @ 12:55:
[...]

Let wel op dat dit qua support een beetje een grijs gebied is. Verder moet je zaken zoals beschikbaarheid en multipathing nu vanuit je VM gaan regelen, terwijl dit voor je hosts allemaal al geregeld is. Aanbieden als RDM is dan veel eenvoudiger.

Zou op zich geen probleem hoeven op te leveren natuurlijk, maar het is wel wat meer werk dan wanneer je het als RDM aan gaat bieden inderdaad.

Lijkt me niet... Een datastore wil je helemaal niet tot de nok toe vol hebben. Dat levert juist problemen op (geen ruimte meer voor .vswp bestanden en snapshots).

Met een iSCSI hoef je m ook niet tot de nok toe vol te proppen, omdat je er voor die tijd alweer disks bij hebt geprikt. Dat kan je met je VMWare-oplossing niet, omdat je dan aan de 2TB-limiet komt.

Hoe zit dit eigenlijk in vSphere 5? Ik mag toch aannemen dat dit inmiddels al wel is opgelost door de mannen van VMWare? En als TS over een support-contract beschikt, mag hij gewoon upgraden hier naartoe.

[kroegtijger]

Rolfie schreef op donderdag 16 augustus 2012 @ 12:59:
Je moet je ook vragen of je wel 2TB LUNS wil hebben?

Voor IO performance is het vaak, hoe meer LUNs hoe beter de performance.
We houden bij ons 600GB Luns aan wat goed te backup maar ook goed te checkdisken is.

Je zou het LUN nog kunnen groten naar 1TB. Maar veel groter zou ik ze niet snel maken.
DFS of anders MP werkt goed.

in ESX3.5 was dat inderdaad nog een probleem, maar vanaf 4.1 zou daar geen performance-loss meer in zijn. Zolang je over een goede storage beschikt, zoals een Dell Equallogic, dan zou het als een trein moeten lopen volgens mijn

[Question Mark]

kroegtijger schreef op donderdag 16 augustus 2012 @ 13:08:
[...]
Met een iSCSI hoef je m ook niet tot de nok toe vol te proppen, omdat je er voor die tijd alweer disks bij hebt geprikt. Dat kan je met je VMWare-oplossing niet, omdat je dan aan de 2TB-limiet komt.

Weet ik, maar ik reageerde eigenlijk op de stelling dat het zonde was om 0,1 TB van je datastore niet te gebruiken.

Hoe zit dit eigenlijk in vSphere 5? Ik mag toch aannemen dat dit inmiddels al wel is opgelost door de mannen van VMWare? En als TS over een support-contract beschikt, mag hij gewoon upgraden hier naartoe.

VMFS 5 kent een lun size van 64 TB. (Of je dat moet willen is een tweede overigens). VMDK's daarentegen zijn nog steeds beperkt tot 2 TB, VMDK's groter dan 2 TB moet dus als RDM aangeboden worden.

http://kb.vmware.com/self...playKC&externalId=2003813

[MAX3400]

Rolfie schreef op donderdag 16 augustus 2012 @ 12:59:
Voor IO performance is het vaak, hoe meer LUNs hoe beter de performance.

Lijkt me niet helemaal correct... Ligt eraan over welk merk & type storage we praten maar je hebt natuurlijk de mogelijkheid om op veel storage-devices natuurlijk 60 LUNs aan te maken op een 4-disk array. Ga je dan ook nog eens verschillende protocollen babbelen tegen die 60 units, dan is het qua I/O.

[Verwijderd]

het is het HP P6300 SAN !

[Verwijderd]

Maar als ik het goed begrijp... Als ik het volgende doe:
- Ja, ik mag upgraden naar VMware 5
- Dan maak ik een datastore van 4 - 5 TB aan...
- Binnen windows van 2 x 2TB VMDK's als spannend volume configureren...

Dan ben ik er ook? simplest way?

[Question Mark]

Ligt eraan.... Afhankelijk van de grootte en complexiteit van je VSphere omgeving kan een versie upgrade een aardig project zijn. (even afgezien van het feit dat je toch ooit eens moet upgraden). Verder vind ik een spanned volume binnen een guest OS geen nette oplossing. In mijn ogen regel je (zeker als je een SAN hebt) zulke zaken op je storagelaag,en niet binnen een guest.

De beste oplossing is eigenlijk niet 1-2-3 aan te geven. Dat ligt ook aan de features van je storageoplossing en hoeveel I/O verkeer die fileserver voor zijn kiezen gaat krijgen.

[ Voor 11% gewijzigd door Question Mark op 16-08-2012 14:43 ]

[MAX3400]

Ben het eens met Question Mark; waarom wil/ga je "oude" technieken gebruiken binnen een VM i.p.v. gebruik te maken van de technologieen die voor je neus staan. Sowieso het "houtje touwtje beheer van disks" wil/moet je vanaf en ervoor zorgen dat je, zeker op lange termijn, binnen je guests eigenlijk geen vinger hoeft uit te steken.

Anders is het resultaat wildgroei van protocollen, disks, provisioning, etc. en heb je alleen maar meer redenen om je I/O van je SAN te verlagen.

[DrFlash]

Question Mark schreef op donderdag 16 augustus 2012 @ 14:42:
Ligt eraan.... Afhankelijk van de grootte en complexiteit van je VSphere omgeving kan een versie upgrade een aardig project zijn. (even afgezien van het feit dat je toch ooit eens moet upgraden).

Ik heb m'n ESX omgeving van 6 hosts (niet superveel weet ik) met ongeveer 50 VM's al meerdere keren geupgrade, van versie 2.5 naar 3, naar 3.5i naar 4.1i en nu naar 5. Het is echt niet lastig, hooguit veel werk. host leegmaken -> cd erin met nieuwe versie -> host met nieuwe versie online brengen, en de volgende host leeg maken....

aan de TS, mag ik vragen wat voor data er in die 4TB moet staan ? ik kan me namelijk niet voorstellen dat je echt 4tb in 1 volume moet hebben en dat het niet over bijv 2 of 4 volumes (shares) verspreid kan worden.

Wat betreft de opmerking over 1.9tb gebruiken van de 2tb beschikbaar, is altijd verstandig en moet vaak ook. over het algemeen valt het nog wel mee, je verliest maar 5% van je opslagruimte. Ik heb nu een omgeving waar het extreem is:

Netapp Streched Metro cluster met intern een RAID10 vergelijkbare oplossing. dat betekend dus al dat ik voor elke 1 schijf opslag, er 4 moet kopen (raid 10 = 2 disken, en het cluster is ook nog een kopie van elkaar)
vervolgens kan er in de volumes maximaal 90% van de opslag gebruikt worden voordat deze gaat klagen, en als er shadow copies gebruikt worden moet er nog meer gereserveerd worden (bij ons 100%). Dan de vmware omgeving er overheen die begint te klagen bij 80% volume gebruik, en dan nog windows servers die ook klagen bij 90%.
in het kort... we gebruiken maar 8.1% van de ingekochte opslag daadwerkelijk :-)

[Razwer]

volume license klant?
http://www.petri.co.il/cr...n-windows-server-2012.htm

kan officieel vanaf vanavond

edit: azijn pissen over of volumes van meer dan 2TB wel of niet nodig zijn lijkt me onnodig.
anyways, zolang je de verschillende luns via vmware als disk aan het OS aan bied kan je er gewoon een storage pool van maken en over je 2TB limiet heen.

[ Voor 49% gewijzigd door Razwer op 16-08-2012 19:16 ]