Archief - file server sizing

menace2070 zei:

zoals ik al aanhaalde, als het voor een school is kosten die licenties amper geld
esxi kost zelfs geen geld... heb je wel geen vmotion etc...
maar ikbedoel komaan, de essentials van esx kost ocharme 600€

Klik om te vergroten...

Met de Essentials versie heb je ook geen VMotion e.d.
De versie hoger is al direct meer dan € 3000..
Maar daar heb je dan heb je ook geen Storage VMotion, daarvoor leg je € 18000.. En dat is dan met de kits, waarbij je snel tegen limieten aanloopt qua hosts.

Btw, "overhead" betekent iets heel anders dan meer geheugen/CPU in een server plaatsen voor de toekomst. Dat heet "over dimensioneren".
In IT betekent de term overhead bvb. de extra resources die een vSphere host nodig heeft om zaken uit te voeren, die niet rechtstreeks te linken zijn aan de guests eronder, maar die dus wel nodig zijn om de vSphere te doen draaien.

ShPonGle zei:

Maak zelf de beste keus rekening houdend met jullie huidige omgeving en deze naar de toekomst toe (mochten jullie bvb. een MSA aanschaffen - want ESX zonder storage Vmotion mogelijkheid, dus met enkel VM's op DAS is niet echt waaw)
VMware Communities: DL360 or Dl380

Klik om te vergroten...

Je haalt hier volgens mij 2 zaken door elkaar. Voor VMotion te doen heb je enkel shared storage nodig. Geen Storage VMotion licentie.
Storage VMotion is alleen handig als je de VMDK's tussen datastores (verschillende LUN's of zelfs totaal verschillende storage boxen) op een gemakkelijke manier wil kunnen moven. En zelfs als je ze wil moven heb je dat niet nodig, manueel gaat dat ook..
Om een guest te moven tussen vSphere hosts heb je dit niet nodig.

.conne. zei:

Btw, "overhead" betekent iets heel anders dan meer geheugen/CPU in een server plaatsen voor de toekomst. Dat heet "over dimensioneren".
In IT betekent de term overhead bvb. de extra resources die een vSphere host nodig heeft om zaken uit te voeren, die niet rechtstreeks te linken zijn aan de guests eronder, maar die dus wel nodig zijn om de vSphere te doen draaien.

Klik om te vergroten...

rofl ja meester...

menace2070 zei:

rofl ja meester...

Klik om te vergroten...

Ik wou niet als je meester overkomen, maar ik vind dat als je een term gebruikt, dat je hem dan juist moet gebruiken..
Hier op dit forum is dat misschien niet zo belangrijk, maar in uw job des te meer.

Voor DC's en fileservers vind ik 2 Quad- of Six-Core CPU's en meer dan 12 GB RAM toch wel zwaar overdreven, tenzij je naar de toekomst toe wilt denken, om die dan later om te zetten naar vSphere (of andere) servers.
Ik denk dat je voor een fileserver als bottleneck eerder gaat moeten kijken op niveau van netwerkconnecties en storage. Ik zou toch kijken naar een degelijke SAN die eventueel de redundancy kan opvangen via snapshots of iets dergelijks.
Persoonlijk zou ik ook nooit een fileserver virtueel draaien, tenzij je de data disks via een raw device mapping doet (zij het via FC of iSCSI). Files opslaan in een VMDK (zeker 1.8 TB) zou ik toch niet aanraden..

.conne. zei:

Je haalt hier volgens mij 2 zaken door elkaar. Voor VMotion te doen heb je enkel shared storage nodig. Geen Storage VMotion licentie.
Storage VMotion is alleen handig als je de VMDK's tussen datastores (verschillende LUN's of zelfs totaal verschillende storage boxen) op een gemakkelijke manier wil kunnen moven. En zelfs als je ze wil moven heb je dat niet nodig, manueel gaat dat ook..
Om een guest te moven tussen vSphere hosts heb je dit niet nodig.

Klik om te vergroten...

idd my bad, die "storage" stond daar te veel

Persoonlijk zou ik ook nooit een fileserver virtueel draaien, tenzij je de data disks via een raw device mapping doet (zij het via FC of iSCSI). Files opslaan in een VMDK (zeker 1.8 TB) zou ik toch niet aanraden..

Klik om te vergroten...

Waarom niet, wat zijn de gevaren?

ShPonGle zei:

idd my bad, die "storage" stond daar te veel

Waarom niet, wat zijn de gevaren?

Klik om te vergroten...

De fileserver zelf vind ik geen probleem om virtueel te draaien (hoewel fysiek nog altijd performanter gaat zijn), maar de files in een VMDK stoppen, die op een VMFS bestandssysteem staat, dat vind ik maar vies, maar dat is eerder persoonlijk.
Het is ook de enige reden die ik kan aanbrengen, want voor de rest is er eigenlijk weinig verschil tussen een RDM en een VMDK.
Ze kunnen beide "maar" 2 TB groot zijn. Dus met de TS zijn 1.8 TB (+ groei) is dat al nipt.
Naar performance toe maakt het niet uit, VMDK's en RDM's zijn ongeveer even snel, zie ook:
http://www.vmware.com/files/pdf/performance_char_vmfs_rdm.pdf

Ik denk ook naar backup toe, dat er wel goed moet nagedacht worden hoe dat gaat aangepakt worden, en wat de requirements zijn, bvb:
- single file restore nodig?
- kortste periode in de tijd dat je moet kunnen teruggaan?
- hoe lang backups bijhouden?
- ...
Al deze vragen gaan mee bepalen welke strategie dat er gaat genomen worden. Dat kan snapshots zijn op niveau van VMWare (met veeam of iets anders), of snapshots op niveau van de storage. Of misschien zelfs op file niveau, al lijkt me een backup nemen van 1.8 TB op die manier, niet echt handig.
De strategie die men daar neemt, gaat ook voor een stuk bepalen welke strategie er gaat moeten genomen worden voor de storage van die files.


Hetgeen wij persoonlijk doen bij ons is:
Voor de vSphere cluster, storage op NetApp via NFS.
Voordeel van NFS is dat je het volume heel gemakkelijk kan vergroten, en met een simpele refresh in vSphere is het vergroot. Qua performance is het vaak ook sneller dan iSCSI en FC, dit komt vooral door de soort I/O dat vSphere genereert. Je kan ook aan thin provisioning gaan doen (standaard bij NFS).
Eén van de voordelen van NetApp is het kunnen maken van snapshots. Daarmee kan je individuele VM's restoren, zelfs single file restore kan.
Andere storage oplossingen hebben vaak ook gelijkaardige functies.

Voor de fileserver gebruiken we eigenlijk geen enkele van de reeds aangegeven oplossingen. Onze "fileservers" zitten op het niveau van de NetApp box die ook CIFS (SMB) kan doen. De NetApp neemt regelmatig snapshots, waar we kunnen naar terugkeren.