Vmware ESX - VMFS of RDM lun's ?

[seq_uence]

Korte omschrijving infrastructuur:

- Windows 2003 SP2 Servers, Windows 2003 cluster, deel van de Windows servers gevirtualiseerd.
- Vmware ESX 3.5 Update 3, 2node cluster met totaal zo'n 10 vm's
- HP MSA1000 SAn met 1,5TB bruto volume
- 2 RAID 0+1 volumes VMFS van 140GB
- 5 vm's met een datavolume op het SAN

Wijziging infrastrucuur:

De MSA1000 wordt vervangen door een EVA4400 met 3,9TB bruto opslagcapaciteit. Tevens wordt de bandbreedte op de HBA's opgeschaald van 2 naar 4GB. De fabrics zijn sinds kort al 8GB, maar 8Gb HBA's zijn nog niet verkrijgbaar. Overigens gaat dit niet de bottleneck worden in onze omgeving.

Probleem:

Nou ja probleem, de vervanging van het SAN is natuurlijk het moment om te bekijken of we met RDM's blijven werken, of met virtuele disken op het VMFS volume. Ik heb enkele documenten doorgelezen waarin de performanceverschillen zijn bekeken, en dit is minimaal. Alleen bij 4k blocksize en intensief dataverkeer is de performance op een RDM hoger, wij hebben geen applicaties die met deze blocksize werken.

Gemiddeld is er wel een 5 tot 10% hogere CPU capaciteit nodig, verder zie ik dus weinig verschillen, nu bestaat de kans dat ik zaken heb gemist of dit verkeerd beoordeel. Daarom mijn post in PNS, ik hoop dat het een gezonde en leerzame discussie wordt.

(Om te voorkomen dat dit ondersneeuwd in een groot topic heb ik het bewust niet in het virtualisatie topic geplaatst, ik hoop dat het zo mag)

[SpamLame]

Als altijd is het antwoord "It depends".
Waarvoor is er destijds gekozen voor RDM en zijn die argumenten nu nog valide?

Bv, zijn er vm's waarvoor RDM noodzakelijk is , misschien in de vorm van een exchange cluster oid.

Als je van RDM naar VMFS wilt dan zal je je data die direct op de LUN geschreven wordt, moeten migreren naar vmdk files op VMFS, maar goed migreren moest je toch al.

RDM vereist meer administratie/beheer in je SAN en Storage array en ESX, omdat je extra wwn's (RDM gaat samen met NPIV) bij moet houden, bij VMFS heb je alleen te maken met de wwn's van je ESX hosts.
RDM biedt je dan wel de mogelijkheid de IO per vdisk, aan de EVA zijde, te meten ipv dat dat opgaat in de groter VMFS datastore. Maar met VMFS kan je wel weer snapshots maken en middels of door VCB je backup kunnen vereenvoudigen.

Volgens mij gaat storage vmotion alleen met VMFS. Als je kiest voor VMFS zal een volgende migratie naar een andere storage array (Merk en of Type) makkelijker kunnen verlopen.

Vergelijk dus de voor- en nadelen voor jullie omgeving eens en kijk waar je naar toe wilt met je omgeving, groei en beheer en investering die daarvoor noodzakelijk zijn etcetc en trek daaruit een conclusie.
Indien gewenst laat je je conclusie toetsen bij HP en of VMware (of hier).
Kan wel roepen iets roepen wat jezou moeten doen, maar daarvoor ken ik je omgeving niet en is er te weinig info is je startpost. Bv. als je ESX hosts die extra CPU last van VMFS niet aankunnen omdat ze vol zitten heeft dat weinig zin.

[ Voor 29% gewijzigd door SpamLame op 21-11-2008 13:06 ]

[ConZito]

Bij ons gebruiken we de ESX omgeving voornamelijk voor de huisvesting van developmentservers voor onze ontwikkelaars. Hieruit volgt dat binnen onze omgeving virtuele servers niet echt een lang leven hebben, hierdoor is er bij ons voor gekozen om RDM's te gebruiken voor de data en VMDK's voor het OS. Op deze manier is het voor ons veel economischer omspringen met de beschikbare storage op ons SAN, er is nu namelijk vrijwel geen ongebruikte ruimte binnen een VMFS-volume.

Bij bepaalde servers wil je ook niet anders, file-servers bijvoorbeeld, dan is RDM veel beter schaalbaar en beter behapbaar dan > 512GB VMDK's, zeker als het er enkele zijn.

Verder kan je met physical RDM's niet zomaar storage VMotionen, met virtual RDM's wel. Daarbij zijn er inmiddels alweer third-party plugins waarmee je hot kan storage VMotionen en die trekken zich helemaal geen zak aan of je RDM physical of virtual is.

Maar zoals SpamLame al aangeeft, wij kennen je omgeving niet dus leg dat eerst eens voor.

[Anoniem: 174333]

leuk item om mee te nemen is hoeveel RDM's je kan syncen als je een 2de EVA eraan hangt. Bij sommige storage fabrikanten is een VMFS dan een betere optie.

[SpamLame]

Anoniem: 174333 schreef op dinsdag 25 november 2008 @ 23:08:
leuk item om mee te nemen is hoeveel RDM's je kan syncen als je een 2de EVA eraan hangt. Bij sommige storage fabrikanten is een VMFS dan een betere optie.

Dat staat op de site, 256 single member DR groups. Voor de TS ligt die limiet op 16.
Maar de TS kijkt waarschijnlijk niet meer naar dit topic

[seq_uence]

Ik kijk nog wel naar dit topic, maar het is de afgelopen week erg druk geweest, op dit moment heb ik nog voorkeur voor RDM's vanwege meer flexibiliteit in grootte van de LUN's.

^^^ Waarom ligt de limiet bij 16 ? Of bedoel je de max grootte van 1 LUN ? Dan is 16TB voor ons wel voldoende.


edit: Heb het ook nog met de leverancier over RDM's of VMFS gehad, de engineer op lokatie is een ex HP man en geeft ook aan dat de performance ongeveer gelijk is, het is dus inderdaad een keuze die bepaald wordt door de soort data en inrichting van onze omgeving. En dat is een omgeving met een fileserver en database waarvan de groei moeilijk in te schatten is door steeds nieuwe implementaties en wijzigingen in beleid.

[ Voor 54% gewijzigd door seq_uence op 28-11-2008 21:28 ]

[SpamLame]

seq_uence schreef op vrijdag 28 november 2008 @ 21:20:
Ik kijk nog wel naar dit topic, maar het is de afgelopen week erg druk geweest, op dit moment heb ik nog voorkeur voor RDM's vanwege meer flexibiliteit in grootte van de LUN's.

^^^ Waarom ligt de limiet bij 16 ? Of bedoel je de max grootte van 1 LUN ? Dan is 16TB voor ons wel voldoende.

Ik ging hier in op saleattweak zijn opmerking over syncen naar een andere EVA (wat mogelijk voor jou op termijn gaat spelen. Hiermee bedoelt ie waarschijnlijk de Continuous Access licentie. De 16 slaat op hoeveel vdisken ( RDM of met VMFS) je kan repliceren naar een andere EVA in single member data replication groups. Mijn lijken die 16 het maximale aantal van die groups te zijn op jullie EVA. De EVA *100 kunnen 256 single member groepen aan.

[seq_uence]

Het zal wel aan mijn google skills liggen, maar ik kan die beperking van de 4400 nergens vinden, de 4400 is de opvolger van de 4100, kan meer Tb aan en de controllers zijn 2x zo snel. Waarom dan die beperking ?

edit: toch nog gevonden, wel vreemd dat het op de 4400 zoveel minder is...

[ Voor 15% gewijzigd door seq_uence op 01-12-2008 20:17 ]

[SpamLame]

seq_uence schreef op maandag 01 december 2008 @ 20:15:
Het zal wel aan mijn google skills liggen, maar ik kan die beperking van de 4400 nergens vinden, de 4400 is de opvolger van de 4100, kan meer Tb aan en de controllers zijn 2x zo snel. Waarom dan die beperking ?

edit: toch nog gevonden, wel vreemd dat het op de 4400 zoveel minder is...

De 4400 is ook niet de opvolger van de 4100. Deze serie *100 is 18 juni 2007geintroduceerd dus nog niet echt oud. Als de firmware xcs9 in de 4400 gelijk werkt aan de xcs6 firmware dan heeft de 4100 een streepje voor in beschikbaarheid lees RSsets en disk enclosure failure en ja dat gebeurt. Daarnaast laat een 4100 zich makkelijk uitbouwen naar 6100 of 8100 indien daar de noodzaak toe is.
De 4400 is wat dat betreft een op zichzelf staand product.

[ Voor 5% gewijzigd door SpamLame op 01-12-2008 20:37 ]

[seq_uence]

Wat ik begrepen heb van de leverancier (de engineer op lokatie is een ex HP storage man) is dat de 4400 wel degelijk de opvolger is van de 4100, en dat volgend jaar ook de 6400 en 8400 geintroduceerd word als opvolger van de bestaande 6100 en 8100......

edit: Bij een collega hebben ze een 4400 staan met 8 enclosures waarbij de disks verdeeld zijn en er een enclosure uit mag vallen. Ook hier dus redundancy voor wat betreft de RS sets.

[ Voor 26% gewijzigd door seq_uence op 01-12-2008 20:49 ]

[SpamLame]

Dat is nieuwe info voor mij. hmm als de 4400 ook net zoals de 4100 makkelijk laat uitbouwen naar een 6 of 8 variant, should be nice.

[Grolsch]

Ik weet niet of je er wat aan hebt, maar ik heb deze discussie (RDM vs VMFS) ook al eens gevoerd.

Zie : inrichting VMware icm HP EVA 4100

[edit]
ik lees dat je zelf ook mee hebt gediscuseerd in dat topic

[ Voor 18% gewijzigd door Grolsch op 02-12-2008 15:33 ]

[erwinb]

Mischien wat off topic, maar je ziet bij banken een trend naar NetApp storage i.c.m NFS als platform voor VMWare. Dit is zeer schaalbaar en je hebt als bijkomend voordeel dat FASDedup (Advanced Single Instance Storage) erbij kraagt. ASIS zorgt op voor een reductie van de gebruikt storage tot wel 90% (Zien we bij klanten).
RDM kan dan niet meer , maar er zijn wel whitepapers hoe dit op te lossen voor b.v. een microsoft cluster.

[seq_uence]

Grolsch schreef op dinsdag 02 december 2008 @ 15:27:
Ik weet niet of je er wat aan hebt, maar ik heb deze discussie (RDM vs VMFS) ook al eens gevoerd.

Zie : inrichting VMware icm HP EVA 4100

[edit]
ik lees dat je zelf ook mee hebt gediscuseerd in dat topic

En ik dacht dat jij niet meer in de ICT zat ?

Heb dat topic maar even weer doorgelezen, zit nu vol in de migratie en blijf nu bij RDM's

[seq_uence]

SpamLame schreef op zondag 30 november 2008 @ 16:50:
[...]


Ik ging hier in op saleattweak zijn opmerking over syncen naar een andere EVA (wat mogelijk voor jou op termijn gaat spelen. Hiermee bedoelt ie waarschijnlijk de Continuous Access licentie. De 16 slaat op hoeveel vdisken ( RDM of met VMFS) je kan repliceren naar een andere EVA in single member data replication groups. Mijn lijken die 16 het maximale aantal van die groups te zijn op jullie EVA. De EVA *100 kunnen 256 single member groepen aan.

Die 16 slaat dus niet op het aantal vdisken maar op het aantal disk groups. In elke disk group kunnen veel vdisken zitten....

Overigens blijkt het toch zo te zijn dat de 4400 een meer op zichzelf staand produkt is, de 6400 wordt meer robuust uitgevoerd door 2 aparte controllers net als de 4100. De 4400 heeft beide controllers in 1 behuizing, deze zijn echter wel hot swap.

[Jazzy]

erwinb schreef op dinsdag 02 december 2008 @ 19:31:
RDM kan dan niet meer , maar er zijn wel whitepapers hoe dit op te lossen voor b.v. een microsoft cluster.

Waarom heb je voor een Microsoft cluster vmdk's nodig?

[seq_uence]

Jazzy schreef op dinsdag 02 december 2008 @ 20:25:
[...]
Waarom heb je voor een Microsoft cluster vmdk's nodig?

Geen vmdk's Microsoft ondersteund alleen fysieke disken in een cluster.

[SpamLame]

seq_uence schreef op dinsdag 02 december 2008 @ 20:18:
[...]


Die 16 slaat dus niet op het aantal vdisken maar op het aantal disk groups. In elke disk group kunnen veel vdisken zitten....

Overigens blijkt het toch zo te zijn dat de 4400 een meer op zichzelf staand produkt is, de 6400 wordt meer robuust uitgevoerd door 2 aparte controllers net als de 4100. De 4400 heeft beide controllers in 1 behuizing, deze zijn echter wel hot swap.

Aangezien je inhaakt op mijn opmerking in SpamLame in "Vmware ESX - VMFS of RDM lun's ?" ,denk dat je DR group bedoelt ipv diskgroup. Waarbij ik met DR group bedoel, data replication groups ofwel een groep (kan ook 1 zijn) van gerepliceerde vdisken. Waar jij diskgroup zet lees ik groep (8 of meer) van fysieke disken waar 1 of meerdere vdisken.

Ik gaf daar het volgende aan.

De 16 slaat op hoeveel vdisken ( RDM of met VMFS) je kan repliceren naar een andere EVA in single member data replication groups.

Waarmee ik alleen aangeven wilde dat er hoogst waarschijnlijk een max van 16 DR groups op een 4400 bestaat, waarbij single member slaat op de aantal (1) vdisken die opgenomen zijn in de DR group.
En ja je kan meerdere vdisken in een DR group opnemen.

En ja er kunnen meerdere vdisken binnen een DG bestaan, maar ik heb ook niet beweert dat dat niet zo is.

[Jazzy]

seq_uence schreef op dinsdag 02 december 2008 @ 20:32:
[...]

Geen vmdk's Microsoft ondersteund alleen fysieke disken in een cluster.

Heb je een linkje naar meer informatie hier over? Ik heb vooral vanuit Exchange 2007 met storage te maken en daarbij worden zowel vmdk's (fixed size) als RDM's ondersteund door Microsoft.

[Zwelgje]

Jazzy schreef op dinsdag 02 december 2008 @ 21:28:
[...]
Heb je een linkje naar meer informatie hier over? Ik heb vooral vanuit Exchange 2007 met storage te maken en daarbij worden zowel vmdk's (fixed size) als RDM's ondersteund door Microsoft.

waarschijnlijk doelt hij op het feit dat je alleen een volume (lun) kan failoveren en niet een .vhd/vmdk op dat lun

naja met windows 2008 r2 is dat opgelost, dan kan je gewoon die .vhd's overgooien zonder dat je een lun hoeft over te zetten.

http://hyper-v.nu/blogs/h...age-en-virtualisatie.aspx

[Grolsch]

seq_uence schreef op dinsdag 02 december 2008 @ 20:15:
[...]


En ik dacht dat jij niet meer in de ICT zat ?

Heb dat topic maar even weer doorgelezen, zit nu vol in de migratie en blijf nu bij RDM's

Ik heb de ICT ook verlaten, maar ik blijf me intereseren voor de ICT, maar nu alleen nog maar hobbymatig

Maar wat voor mij destijds een erg groot nadeel was is dat HA / DRS en snapshotting niet werken bij RDM.

Toen ik mijn vorige werkgever verlaten heb liep alles als een tierelier met de EVA4100 icm VMWARE

[Zwelgje]

Grolsch schreef op woensdag 03 december 2008 @ 08:12:
[...]


Ik heb de ICT ook verlaten, maar ik blijf me intereseren voor de ICT, maar nu alleen nog maar hobbymatig

Maar wat voor mij destijds een erg groot nadeel was is dat HA / DRS en snapshotting niet werken bij RDM.

Toen ik mijn vorige werkgever verlaten heb liep alles als een tierelier met de EVA4100 icm VMWARE

offtopic, wat doe je nu dan voor werk

gewoon interesse in een mede (bekende naam) tweaker

_{..ben er een tijdje niet meer geweest op GoT namelijk zodoende mijn vraag}

[Grolsch]

Powershell schreef op woensdag 03 december 2008 @ 17:41:
[...]


offtopic, wat doe je nu dan voor werk

gewoon interesse in een mede (bekende naam) tweaker

_{..ben er een tijdje niet meer geweest op GoT namelijk zodoende mijn vraag}

Ik ben bij mijn vader in de zaak gegaan (Machinefabriek) met de intentie om de zaak op termijn (5~10 jaar) over te nemen.

Dus ipv allerlei high-tech snufjes ben ik nu bezig met allerlei mechanische technische snufjes

[Anoniem: 151099]

Grolsch schreef op woensdag 03 december 2008 @ 08:12:
[...]


Ik heb de ICT ook verlaten, maar ik blijf me intereseren voor de ICT, maar nu alleen nog maar hobbymatig

Maar wat voor mij destijds een erg groot nadeel was is dat HA / DRS en snapshotting niet werken bij RDM.

Toen ik mijn vorige werkgever verlaten heb liep alles als een tierelier met de EVA4100 icm VMWARE

snapshots moet je vanaf je SAN doen, maar idd HA is een probleem, daarom gaat mijn voorkeur uit naar VMFS

[Grolsch]

Anoniem: 151099 schreef op donderdag 04 december 2008 @ 07:54:
[...]

snapshots moet je vanaf je SAN doen, maar idd HA is een probleem, daarom gaat mijn voorkeur uit naar VMFS

Je "moet" niets

Ik maakte veelvuldig gebruik van de snapshot functionaliteit van VMWARE, met name voor Vmotion, ESXranger. Dat gaat toch echt niet lukken met snapshots op SAN niveau.

[Anoniem: 151099]

Grolsch schreef op donderdag 04 december 2008 @ 08:01:
[...]

Je "moet" niets

Ik maakte veelvuldig gebruik van de snapshot functionaliteit van VMWARE, met name voor Vmotion, ESXranger. Dat gaat toch echt niet lukken met snapshots op SAN niveau.

ja maar dat gaat toch niet als je RDM gebruikt?

[seq_uence]

Anoniem: 151099 schreef op donderdag 04 december 2008 @ 08:49:
[...]

ja maar dat gaat toch niet als je RDM gebruikt?

Dat ligt eraan hoe je de RDM hebt ingesteld. Een RDM in virtual mode kun je wel een snapshot van maken, wil je dat niet dan kun je aangeven dat de disk independend is en wordt deze bij een snapshot van de machine niet meegenomen. Dat laatste doe ik, in de backup (VCB icm Dataprotector) heb ik namelijk geen optie gevonden om specifieke disken te backuppen. Heb je dan een RDM in virtual mode dan wordt deze ook meegenomen, omdat ik alleen VCB gebruik voor de "image" van de machine wil ik die data niet meenemen.