inrichting VMware icm HP EVA 4100

[Grolsch]

Hallo Tweakers,

De kogel is hier eindelijk door de kerk, en er is een nieuwe HP EVA4100 besteld.

Momenteel heb ik dus 2 VMware ESX 3 hosts die dmv iscsi zijn gekoppeld de huidge iSCSI SAN.

Op de iSCSI doos heb ik 1 600GB grote disk toegewezen aan beide ESX machines, en dit is dus mijn VMFS Volume in VMWARE.

Per virtual machine wordt er dus een mapje aangemaakt, met daarin de VMDK files van de VM.

Nu komen er per ESX server 2 fibrechannel kaartjes in welke op de nieuwe EVA4100 aangesloten gaan worden.

Nu is mijn vraag eigenlijk de volgende:

scenario 1:
Wat is verstandig, wederom 1 grote virtual disk aanmaken op mijn SAN van 1,zoveel TB, en deze toewijzen aan m'n ESX Servers, en deze datastore als 1 grote VMFS Volume gaan gebruiken.

En dan vervolgens per VM weer een submap aan te gaan maken op dit grote VMFS Volume, en daar weer de vmdk files neer te zetten (zoals in de oude situatie):?

scenario 2:
Of is het verstandig om bijvoorbeeld voor mijn exchange database (100GB) gebruik te maken van RAW Device mappings in Virtual Center

Ik snap de feitelijke verschillen wel, maar heeft dit bepaalde voordelen / nadelen welke ik over het hoofd zie

Ik kan mij bijvoorbeeld voorstellen dat in geval van scenario 2, ik de LUN vrij eenvoudig aan een fysieke machine kan gaan koppelen, want er is helemaal geen sprake van VMFS partities, maar van NTFS.

Maar wat is bijvoorbeeld sneller

Alvast bedankt voor jullie hulp.

[Anoniem: 167137]

Kies voor de scenario dat je alle disks in 1 group gooit en een LUN aanmaakt volgens de grootte die jij wilt, (extenden kan later altijd maar is niet fraai)

Na mijn weten kun je met RAW disks niet gaan vmotionen of HA en DRS gebruiken.

Hou er wel rekening mee dat je per LUN maar 1 Storage processor kan gebruiken op je Eva ! Je kunt niet via 2 SP's dezelfde LUN benaderen.

[Asteroid9]

Scenario 1 geeft wel de meeste flexibiliteit, en is ook de opzet die ik gebruik.
Hierbij kun je met snapshots werken en kun je de vmdk files eventueel volledig backuppen om een uitwijkscenario te ondersteunen.

Scenario 2 is vooral interessant als je op SAN niveau met snapshots en incremental copies wil gaan werken.
Lijkt me op een kleine EVA niet direct van toepassing.
Geeft bovendien inderdaad minder flexibiliteit met HA / VMotion.

[ZeRoC00L]

Anoniem: 167137 schreef op donderdag 28 februari 2008 @ 19:34:
Na mijn weten kun je met RAW disks niet gaan vmotionen of HA en DRS gebruiken.

Is niet juist, RDM is wel mogelijk met VMotion en wordt ook ondersteund door VMware.

[Grolsch]

scenario 1 heeft naar mijn bescheiden mening 2 nadelen.

nadeel 1 = je moet van te voren gigantisch goed in kunnen gaan schatten hoeveel disk-space je nodig hebt voor al je vm's, want het uitbreiden van een VMFS volume kan namelijk niet. (wel een ander foefje, dat weet ik, je kunt alleen een extend toevoegen, maar is niet aan te raden).

nadeel 2 = STEL JE VOOR dat er iets gebeurd met desbetreffens VMFS volume. Op dat moment zegt VMWARE dood leuk (ik spreek uit ervaring) maak maar een nieuw VMFS volume aan.
Ik heb straks een SAN met 1,7 TB netto opslag, stel ik maak dus 1 VMFS volume van 1,5 TB aan, en daar gebeurt "iets" mee, dan heb ik een probleem.

2 voordelen voor scenario 2 zijn de volgende

voordeel 1 = Als ik RDM gebruik, kan ik heel eenvoudig het volume groter maken op de EVA, en vervolgens met diskpart een HD extenden. Mocht ik dit willen met een VMDK file, dan moet de VM down, en dan moet ik met vmdktools aan de gang.

Voordeel 2 = Ik kan desbetreffende LUN aan elke wille keurige server (virtueel of fysiek) koppelen, omdat het gewoon een NTFS partitie is. Stel je voor dat geheel VMware onderuit gaat, dan kan ik met bijv. m'n management server desbetreffende LUN benaderen om onze "o-zo-belangrijke" bestanden te benaderen.

Ik zal zelf nazoeken of VMOTION of HA niet werkt met scenario 2.

[ Voor 3% gewijzigd door Grolsch op 29-02-2008 09:06 ]

[Asteroid9]

Ik heb ESX toch nog nooit uit zichzelf VMFS volumes aan zien maken.
Wel een corrupt volume gehad na een hardware storing, maar dat bleef mooi zo staan tot ik zelf recovery acties ging proberen.

Kan me dit echt niet voorstellen, heb je hier meer informatie over?

[Equator]

Wat Grolsch bedoelt is dat VMWare support dan zegt: Je zal een nieuw VMFS aan moeten maken..

ESX zal dat niet uit zichzelf doen lijkt mij

[Asteroid9]

Ah, my bad, beetje slecht geinterpreteerd.

Vreemde opmerking van de support wel, ESX heeft standaard al aardig wat recovery tools aan boord.
Je zou toch verwachten dat ze die dan op hun minst aanbevelen.

[Grolsch]

Asteroid9 schreef op vrijdag 29 februari 2008 @ 09:41:
Ah, my bad, beetje slecht geinterpreteerd.

Vreemde opmerking van de support wel, ESX heeft standaard al aardig wat recovery tools aan boord.
Je zou toch verwachten dat ze die dan op hun minst aanbevelen.

na diverse dingen geprobeerd te hebben, was hun oplossing "maak maar een nieuw VMFS volume", en verwijder de oude.

Maar er zijn vast en zeker meer mensen welke VMWARE gebruiken icm een SAN, dus graag tips en advies.

Ik weet zelf bijvoorbeeld dat een grote organisatie (UT Twente) scenario 2 heeft.

[MoBi]

je kunt vmfs later niet uitbreiden. Ik zou werken met een vmfs van 300 gb en daar alleen de boot gedeelte van je servers op klappe en via rdm de data partities aanmaken. Dit geeft een iets hogere performance en de rdm kun je later grote maken door je lun te vergroten.

[Grolsch]

MoBi schreef op vrijdag 29 februari 2008 @ 12:18:
je kunt vmfs later niet uitbreiden. Ik zou werken met een vmfs van 300 gb en daar alleen de boot gedeelte van je servers op klappe en via rdm de data partities aanmaken. Dit geeft een iets hogere performance en de rdm kun je later grote maken door je lun te vergroten.

ok, maar RDM geeft dus geen problemen met Vmotion / DRS / HA

[Asteroid9]

Snapshot functionaliteit raak je dus wel kwijt met RDM's, is ook iets om rekening mee te houden.

Ik zie de voordelen van RDM niet zo zeer. Je wil juist virtualiseren en met RDM's raak je die isolatie tussen hardware en software nou net weer kwijt.
Een VMFS volume kan corrupt raken ja, maar een NTFS volume net zo goed.

Voor zeer grote volumes kun je RDM's overwegen, maar voor een Exchange store van 100GB zou ik het zeker niet doen.
Ik heb hier nu ook een slordige 3TB aan vmfs volumes.

[Question Mark]

Vmware zegt in VMFS - best practices het volgende:

Even with all the advantages of VMFS, there are still some cases where it makes more sense to use RDM storage access. Two scenarios that call for raw disk mapping are:

• Migrating an existing application from a physical environment to virtualization
• Using Microsoft Cluster Services (MSCS) for clustering in a virtual environment

Volgens mij spelen beide zaken niet zo bij TS. Wel adviseerde onze leverancier destijds om een maximale grootte van 500 GB aan te houden voor VMFS volumes. Dat kom ik echter niet tegen in dit document...

[Wirehead]

Hier zetten we de C: drives op vmfs en datadisks op RDM, op die manier kan je nog altijd configs, ... snapshotten, en heb je pure performance op datadisks.

Geen issues met DRS/Vmotion. ESX3.0.2 met HP EVA

[Grolsch]

Dat je dus geen snapshots kon maken van RDM volumes wist ik niet, en dat is bijna zeker een argument om dus gebruik te gaan maken VMFS volume's.

Dit omdat wij ESX Ranger gebruiker voor backups2disk van de VM's.

Die tip van max. 500GB per VMFS volume is inderdaad handig. Mocht er 1 corrupt raken dan is het "minder erg".

[seq_uence]

euhm, EVA4400 is net released. ;-)
Wij gaan ook dit jaar onze SAN oplossing vervangen voor een 4400 of 6100.

Er zijn genoeg dicussies over wel of geen RDM's en ook over de config van een EVA op zich.
De EVA zou ik op 1 grote RAID5 laten draaien om zo schaalbaar mogelijk te zijn, wel relatief veel disks inzeten, dus liever 16x 146 dan 8x300GB. Mits de uitbreidingscapaciteit dit toelaat.
Wanneer je alleen de system volumes van de server virtualiseerd zou je een RAID0+1 voor het VMFS aan kunnen maken.

Exchange gaan wij voorlopig niet virtualiseren ivm de performance, onze Exchange omgeving is geclusterd dus is al redundant. Datadisks die snel groeien of veel performance eisen zou ik als RDM toewijzen aan de server, online te vergroten en hogere performance, je koopt toch niet een EVA om vervolgens Vmware uit te laten zoeken hoe de data op de disk wordt gezet ?

En ESX snapshots laten maken van een RDM gaat inderdaad niet, Vmotion en HA ook niet. De aankomende functionaliteit (site recovery) ondersteund voor zover ik heb begrepen helaas ook alleen virtuele disks op het VMFS volume.

[SpamLame]

Grolsch schreef op donderdag 28 februari 2008 @ 16:45:
Hallo Tweakers,

{knip]

scenario 1:
Wat is verstandig, wederom 1 grote virtual disk aanmaken op mijn SAN van 1,zoveel TB, en deze toewijzen aan m'n ESX Servers, en deze datastore als 1 grote VMFS Volume gaan gebruiken.
En dan vervolgens per VM weer een submap aan te gaan maken op dit grote VMFS Volume, en daar weer de vmdk files neer te zetten (zoals in de oude situatie):?

scenario 2:
Of is het verstandig om bijvoorbeeld voor mijn exchange database (100GB) gebruik te maken van RAW Device mappings in Virtual Center

[knip2]

Waar ik in geintreseerd ben is in welke configuratie die EVA4100 bestelt is (en ja de 4400 is net uit)
Hoeveel diskshelfs krijg je en hoe belangrijk wordt beschikbaarheid gevonden. Is overigens ook iets wat ik in vorige topic schreef. Niet dat het uitmaakt daar je met een EVA4[01]00 en VRAID5 lun's altijd een risico loopt ivm mogelijk diskshelf uitval. Probeer waar je dat kan VRAID1 aan te maken, maar bedenk dat je geen migratie van RAID level kan uitvoeren.

Persoonlijk (en bij mijn huidige opdracht is dat ook zo) ben ik niet overtuigt van het nut van RDM.
Zoals eerder opgemerkt raak je je virtualisatie kwijt, hoewel ik met voor kan stellen dat niet anders kan (MS clustering tussen virtueel en fysiek bv.). Verder heb ik (we) begrepen dat RDM werkt met pointers binnen VMFS. Als het VMFS corrupt zou raken ben je evengoed je toegang kwijt aangezien de poiters weg kunnen zijn. Uiteraard is herstel makkelijker, daar presenteren aan een fysieke windows machine voldoende moet zijn. En om dat het VMFS volume er nog steeds tussen zit, hebben wij dat vertaald als zijnde 2 IO's per werkelijke IO. Eerst in het VMFS volume dan het RAW device.

Elders meegemaakt dat de volumes 300Gb zijn en alhier is 400 Gb de grootte van de LUN's, niet echt ergens op gebaseerd, meer een mix wat is handig en wat kost het. Gezien de ander reactie lijkt het me dat je beter kan kiezen voor meerdere kleinere LUN's. Overigens hebben meerdere LUN het voordeel dat de IO's over meer diskque verspreid worden wat je een betere performance zou kunnen bieden. Tevens kan je gaan loadbalancen over HBA's en controller's.
Overigens kan je in VM's ook je disken vergroten als je ze extend middels diskmanagement op een nieuw aangemaakte VMDK (al dan niet in dezelfde datastore), dus dat hoeft niet een issue te zijn.
Datastore vergroten zou je kunnen afvangen met Storage VMotion als je net offline kan. Nieuwe groter e Datastore aanmaken, VM's VMotionen naar nieuwe datastore, oude weggooi-en-aanmaken of vergroten en presto. Moet je wel wat slack hebben om te kunnen doen, wat zowiezo al aan te raden is.

Het argument voor RDM van seq_uence snap ik wel, maar van de andere kant, waarom zou je VMware het niet uit laten zoeken, hetzelfde kan je doen of doe je al met je storage (hier een EVA) vanaf het moment dat we afstapte van direct op blokken disk krassen. Nu regelt een filesysteem zelf al waar zijn data staat en daar heb je geen volle controle over waar in het filesysteem dit geplaatst wordt.
Mijn insteek is meer, ik wil in de basis, opslag met bepaalde performance en beschikbaarheid tegen een schappelijke prijs. Waar het staat boeit me niet.
Nu moet ik even meedelen dat het me wel boeit, IRL HP EVA knoppendrukkert, maar bovenstaande is wat ik verkoop naar de klant.

[ Voor 47% gewijzigd door SpamLame op 03-03-2008 22:21 ]

[Grolsch]

SpamLame schreef op maandag 03 maart 2008 @ 22:06:
[...]


Waar ik in geintreseerd ben is in welke configuratie die EVA4100 bestelt is (en ja de 4400 is net uit)
Hoeveel diskshelfs krijg je en hoe belangrijk wordt beschikbaarheid gevonden. Is overigens ook iets wat ik in vorige topic schreef. Niet dat het uitmaakt daar je met een EVA4[01]00 en VRAID5 lun's altijd een risico loopt ivm mogelijk diskshelf uitval. Probeer waar je dat kan VRAID1 aan te maken, maar bedenk dat je geen migratie van RAID level kan uitvoeren.

Ik heb de EVA4100 besteld met 1 diskshelf en 8x300GB schijven.
Wel dubbele switches etc.

Ik heb ook gezien dat de 4400 uit is ondertussen, maar dat is weer lichtelijk overkill.

De afweging voor 1 diskshelf is puur financieel. Beschikbaarheid is wel erg belangrijk, maar als je het dan goed wil doen moet je ook je eva weer dubbel gaan uitvoeren.
Waarom zou ik een VRAID 1 aan gaan maken Ik denk dat wij kiezen voor voor een VRAID5.

Ik heb gesproken met iemand die een EVA in gebruik heeft met 70 schijven, en deze heeft tot dusver 1 x meegemaakt dat een schijf uitvalt, volgens hem zou ik gewoon een VRAID5 aan moeten maken.

Persoonlijk (en bij mijn huidige opdracht is dat ook zo) ben ik niet overtuigt van het nut van RDM.
Zoals eerder opgemerkt raak je je virtualisatie kwijt, hoewel ik met voor kan stellen dat niet anders kan (MS clustering tussen virtueel en fysiek bv.). Verder heb ik (we) begrepen dat RDM werkt met pointers binnen VMFS. Als het VMFS corrupt zou raken ben je evengoed je toegang kwijt aangezien de poiters weg kunnen zijn. Uiteraard is herstel makkelijker, daar presenteren aan een fysieke windows machine voldoende moet zijn. En om dat het VMFS volume er nog steeds tussen zit, hebben wij dat vertaald als zijnde 2 IO's per werkelijke IO. Eerst in het VMFS volume dan het RAW device.

Daar zit een kern van waarheid in, wij gaan ook voor meerdere VMFS kiezen naar aanleiding van dit topic.

Elders meegemaakt dat de volumes 300Gb zijn en alhier is 400 Gb de grootte van de LUN's, niet echt ergens op gebaseerd, meer een mix wat is handig en wat kost het. Gezien de ander reactie lijkt het me dat je beter kan kiezen voor meerdere kleinere LUN's. Overigens hebben meerdere LUN het voordeel dat de IO's over meer diskque verspreid worden wat je een betere performance zou kunnen bieden. Tevens kan je gaan loadbalancen over HBA's en controller's.

Correct me i'f i'm wrong maar het maakt met een EVA niet uit of je meerdere LUNS aanmaakt, hoemeer spindels, hoe meer performance. Hij gebruikt gewoon alle schijven dwars door elkaar heen.

Overigens kan je in VM's ook je disken vergroten als je ze extend middels diskmanagement op een nieuw aangemaakte VMDK (al dan niet in dezelfde datastore), dus dat hoeft niet een issue te zijn.

Je kunt dmf vmdktools alleen de disk vergroten op het moment dat je VM offline is. Extenden kan idd wel online in win2k3, maar de VMDK file vergroten moet dus helaas offline.

Datastore vergroten zou je kunnen afvangen met Storage VMotion als je net offline kan. Nieuwe groter e Datastore aanmaken, VM's VMotionen naar nieuwe datastore, oude weggooi-en-aanmaken of vergroten en presto. Moet je wel wat slack hebben om te kunnen doen, wat zowiezo al aan te raden is.

Dat zou dus inderdaad een optie zijn.

Het argument voor RDM van seq_uence snap ik wel, maar van de andere kant, waarom zou je VMware het niet uit laten zoeken, hetzelfde kan je doen of doe je al met je storage (hier een EVA) vanaf het moment dat we afstapte van direct op blokken disk krassen. Nu regelt een filesysteem zelf al waar zijn data staat en daar heb je geen volle controle over waar in het filesysteem dit geplaatst wordt.
Mijn insteek is meer, ik wil in de basis, opslag met bepaalde performance en beschikbaarheid tegen een schappelijke prijs. Waar het staat boeit me niet.
Nu moet ik even meedelen dat het me wel boeit, IRL HP EVA knoppendrukkert, maar bovenstaande is wat ik verkoop naar de klant.

Tsjah, wat ik tot dusver begrepen heb gaat de voorkeur uit naar VMFS volumes, of er moet een dusdanig goed argument zijn om het niet te doen (snapshotten op EVA niveau / Clustering / snel kunnen schakelen tussen Virtueel en Fysiek.

[SpamLame]

Grolsch schreef op dinsdag 04 maart 2008 @ 09:55:
[...]

Ik heb de EVA4100 besteld met 1 diskshelf en 8x300GB schijven.
Wel dubbele switches etc.

Ik heb ook gezien dat de 4400 uit is ondertussen, maar dat is weer lichtelijk overkill.

De afweging voor 1 diskshelf is puur financieel. Beschikbaarheid is wel erg belangrijk, maar als je het dan goed wil doen moet je ook je eva weer dubbel gaan uitvoeren.
Waarom zou ik een VRAID 1 aan gaan maken Ik denk dat wij kiezen voor voor een VRAID5.

Ik heb gesproken met iemand die een EVA in gebruik heeft met 70 schijven, en deze heeft tot dusver 1 x meegemaakt dat een schijf uitvalt, volgens hem zou ik gewoon een VRAID5 aan moeten maken.

Mijn opmerking over VRAID 1 of 5 gaan op bij 2 resp 8 shelfs (of meer). Aangezien je 1 shelf hebt boeit het nu niet. Het is ook niet mijn bedoeling je van VRAID5 af te houden, ik gebruik het ook veelvuldig uit kosten overweging. Kan alleen de opmerking van de iemand met 70 disken niet plaatsen. 70 schijven waarvan 1 stuk is gegaan is de motivatie voor hem om VRAID5 te doen? althans zo lees ik het. Raidlevels en andere settings, maak je omdat ze, om een of andere reden, belangrijk zijn voor je organisatie. Leuk leesvoer is de EVA best practice white paper.

Helaas heb ik door het uitvallen van 1 disk een complete EVA 8000 (2cd12 168 disks) op zijn plaat zien, 2 keer dezelfde EVA binnen 1 week doordat er een firmware issue was.
Overigens zijn 8 schijven het minimale en kan je al niet meer preventief een schijf ungroupen als de EVA dat meld.

Daar zit een kern van waarheid in, wij gaan ook voor meerdere VMFS kiezen naar aanleiding van dit topic.


[...]


Correct me i'f i'm wrong maar het maakt met een EVA niet uit of je meerdere LUNS aanmaakt, hoemeer spindels, hoe meer performance. Hij gebruikt gewoon alle schijven dwars door elkaar heen.

Klopt wat je zegt, ik doelde op de OS zijde van het geheel. Elke disk (of LUN) heeft zijn eigen que's waarin schrijf/leesopdrachten terecht komen (kijk bv eens in perfmon bij de physical disks).
Daarnaast gebruikt ESX maar 1 pad per LUN is is de rest voor failover (fixed in A/A en MRU in A/P), meerdere LUN's bied je de mogelijkheid te balancen over de controller hostports, de controllers onderling en de HBA's in de server. Als je van plan bent meerdere datastore's te maken (en dat vat ik op aan je antwoorden) dan heb je al van plan met meerdere LUN's te werken en zal je alleen de LUN's nog moeten verdelen over de paden (om en om preffered/active maken binnen ESX).

Pun van aandacht is dat op elke ESX de LUN door dezelfde controller wordt afgehandeld. Is dat niet het geval dan zal de mirror port belast worden met het doorsluizen van IO's of wordt de controle over de LUN steeds tussen de controllers heen en weer gegooit.

Je kunt dmf vmdktools alleen de disk vergroten op het moment dat je VM offline is. Extenden kan idd wel online in win2k3, maar de VMDK file vergroten moet dus helaas offline.

Ook hier leg ik verkeerd uit of vat je me verkeerd op. Mijn insteek is VM (w2k3 dyn.disks of linux met LVM) draait dus vmdk is in gebruik en niet te extenden. Wel kan je een nieuwe vmdk aanmaken en toekennen aan je VM. Binnen je VM kan je dan weer je partitie spannen naar de nieuwe disk (vmdk).

Dat zou dus inderdaad een optie zijn.


[...]


Tsjah, wat ik tot dusver begrepen heb gaat de voorkeur uit naar VMFS volumes, of er moet een dusdanig goed argument zijn om het niet te doen (snapshotten op EVA niveau / Clustering / snel kunnen schakelen tussen Virtueel en Fysiek.

[ Voor 11% gewijzigd door SpamLame op 05-03-2008 21:26 ]