Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie
Toon posts:

inrichting VMware icm HP EVA 4100

Pagina: 1
Acties:

  • Grolsch
  • Registratie: maart 2003
  • Laatst online: 22:30
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.

PVOUPUT - 7000WP - 40 x SF175 - Fronius Symo 8.2-3-M - Twente


  • Grolsch
  • Registratie: maart 2003
  • Laatst online: 22:30
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]

PVOUPUT - 7000WP - 40 x SF175 - Fronius Symo 8.2-3-M - Twente


  • Grolsch
  • Registratie: maart 2003
  • Laatst online: 22:30
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.

PVOUPUT - 7000WP - 40 x SF175 - Fronius Symo 8.2-3-M - Twente


  • Grolsch
  • Registratie: maart 2003
  • Laatst online: 22:30
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 :?

PVOUPUT - 7000WP - 40 x SF175 - Fronius Symo 8.2-3-M - Twente


  • Grolsch
  • Registratie: maart 2003
  • Laatst online: 22:30
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".

PVOUPUT - 7000WP - 40 x SF175 - Fronius Symo 8.2-3-M - Twente


  • Grolsch
  • Registratie: maart 2003
  • Laatst online: 22:30
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.

PVOUPUT - 7000WP - 40 x SF175 - Fronius Symo 8.2-3-M - Twente

Pagina: 1


Apple iPhone 12 Microsoft Xbox Series X LG CX Google Pixel 5 Black Friday 2020 Samsung Galaxy S20 4G Sony PlayStation 5 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 - 2020 Hosting door True