Advies m.b.t. capaciteit DL380 G5 i.c.m. VMWare ESXi

[wjjkoevoets]

Navigatie

1. Doel 2. Materieel 3. Overige Diensten 4. Geplande Configuratie 5. RAID 6. OTAP 7. Advies

1. Doel

Om bepaalde zaken beter te kunnen monitoren en te regelen wil ik het volgende bereiken op mijn thuisserver: - Volledig gevirtualiseerde omgeving op 1 fysieke server - Het volledig in beheer nemen van e-mail met Microsoft Exchange 2013 - Het opslaan van documenten e.d. op de server middels folder redirection GPO's - Uitbreiding in de toekomst met Microsoft SCCM 2012 - Dit voor maximaal 5 gelijktijdige gebruikers - En met goede performance

2. Materieel

Ik ben van plan om gebruik te maken van een HP Proliant DL380 G5 server die naar mijn inzien redelijk goed uitgerust is voor de beoogde taak. Het systeem heeft op dit moment de volgende specificaties: BIOS: P56 (NX-bit, VT, Static High Performance mode) CPU: 2x Intel Xeon E5420 2.50 GHz Quad-Core RAM: 16GB PC2-5300F RAID: HP Smart Array P400 512MB BBWC Storage: 8x 72GB 10K disks NIC: 2x 1Gbit (draait echter maar op 100Mbit vanwege het netwerk) - Load Balanced via ESXi Beoogde Hypervisor: HP VMWare ESXi v5.1 U1 Ik heb mijzelf er onvoldoende in verdiept, maar ik heb begrepen dat voor het draaien van Hyper-V een installatie van Windows Server 2012 vereist is. Dit lijkt mij in mijn geval niet wenselijk, omdat resources beperkt zijn (Storage en RAM). Backup Storage: Maxtor Diamondmax 9 80GB USB2.0 (Bare Metal Backup) * * Tijdelijke oplossing, totdat ik een geschikte printplaat vind voor mijn Seagate 7200.10 zodat er Full Backups gemaakt kunnen worden (V&A gevraagd: Seagate Barracuda 7200.10 ST3400620AS, 400GB Printplaat).

3. Overige Diensten

Om e.e.a. goed te laten werken heb ik het volgende inmiddels ook geregeld (of het gaat nog geregeld worden): - Domeinnaam - Single-name SSL Certificaat voor mail.domein.nl - SRV*/SPF/MX/A Records - Backup Mail Exchanger - Backup subdomein * SRV record is nodig in verband met autodiscover in combinatie met een single-name SSL Ceriticaat

4. Geplande Configuratie

Zoals aangegeven ben ik van plan om VMWare ESXi te gaan gebruiken als Hypervisor (tenzij iemand met een "compelling argument" komt om Hyper-V te gebruiken). Ik heb op dit moment een configuratie van 3 Virtual Machines in gedachte die mijn doel moeten gaan waarmaken: Virtual Machine 01: CPU: 2x Intel Xeon E5420 2.50 GHz Quad-Core (Volledig beschikbaar) RAM: 4GB Storage: 50GB VMWare Paravirtual NIC: VMXnet3 OS: Windows Server 2012 Core Beoogde rollen: Primary DC, Primary DNS, DHCP + Windows Server Backup Virtual Machine 02: CPU: 2x Intel Xeon E5420 2.50 GHz Quad-Core (Volledig beschikbaar) RAM: 4GB Storage: 50GB VMWare Paravirtual NIC: VMXnet3 OS: Windows Server 2012 Core Beoogde rollen: Secondary DC, Secondary DNS, DHCP (Load Balance), Webserver (Geen IIS) + Windows Server Backup Virtual Machine 03: CPU: 2x Intel Xeon E5420 2.50 GHz Quad-Core (Volledig beschikbaar) RAM: 16GB Storage: 50GB + 292GB VMWare Paravirtual NIC: VMXnet3 OS: Windows Server 2012 Standard Beoogde rollen: Exchange, IIS, Storage (Home folders e.d.) + Windows Server Backup * * Eventueel later uitbreiding met Microsoft SCCM 2012

5. RAID

Mijn bedoeling is om middels mijn RAID controller twee RAID arrays aan te maken. Ik zat te denken aan de volgende configuratie: - RAID0 (2x72GB) - Wat betekend dat de OS partitie ongeveer 43GB zal zijn - RAID5 (6x72GB) - Wat betekend dat de resterende ruimte neer zal komen op ca. 290GB (24GB = Vmware Swap) Het lijkt me dat de controller met 512MB BBWC voldoende sap moet leveren om dit draaiende te houden.

6. OTAP

Omdat mijn volledige mailsysteem afhankelijk zal zijn van deze server is het essentieel dat wat ik voor ogen heb daadwerkelijk haalbaar is met de hardware die ik heb. Niks gaat in productie, totdat e.e.a. uitvoerig getest is. Zo ook bij mijn server. Ik ben dan ook aan de slag gegaan om een soort van pilot te starten om te kijken wat we voor elkaar kunnen krijgen en hoe de performance daarbij is. De pilot situatie komt grootendeels overeen met bovengenoemde situatie. Een uitzondering hierop is de RAID configuratie (1 groot RAID5 array). Het opzetten van de services is allemaal prima gelukt en ook alles lijkt naar behoren te werken in de huidige pilot omgeving. Ik merk wel dat met alle home folders re-directed ik toch erg tegen de storage limieten zit te haperen. Ook is ca. 43GB voor het OS wel aan de kleine kant heb ik het idee. Vooral Exchange moet volgens Microsoft een pagefile hebben met een grootte van physical RAM+10MB, dat is is technisch niet mogelijk met mijn configuratie. Verder merk ik ook dat de performance toch minder is dan ik had verwacht. Mijn kennis van ESXi is erg beperkt, maar ik heb een vermoeden dat het komt door mijn storage configuratie en niet zo zeer door de beschikbare processorkracht of de hoeveelheid RAM. 1 groot RAID5 array is natuurlijk niet de meest charmante optie, maar aan de andere kant vraag ik me af of RAID0 hier nou echt veel verbetering in brengt. Dit brengt grote twijfels met zich mee wanneer er daadwerkelijk 5 gebruikers actief zijn op de server. Nu is de server nog " vers", maar over drie maansen vrees ik dat het toch een stuk minder gaat. Als ook de footprint van SCCM er nog bij komt weet ik niet wat er zal gebeuren.

7. Advies

Ik hoop dat iemand met meer kennis en ervaring van virtualisatie mij een indicatie kan geven of mijn verwachtingen wel realitisch zijn met de huidige hardware. Komt de verminderde performance door configuratie in ESXi zelf? Ik had getracht "resources" te reserveren per server, maar dat had eerder een averechts effect. Het instellen van "Static High Performance" mode in de BIOS volgens VMWare KB artikels heeft het probleem wel iets verminderd. Gezien het storage probleem ben ik van plan een aantal schijven te gaan vervangen door grote exemplaren. Is het gezien de performance, waarvan ik vermoed dat deze storage gerelateerd is, verstandig om over te schakelen op bijv. 146GB 15K schijven? Er is niet veel over van mijn budget, maar ik denk dat ik me toch verkeken heb en toch weer zal moeten investeren.

[CMD-Snake]

Als ik zo snel door je post scroll zie ik al meteen een over commit aan geheugen.

De host heeft 16Gb geheugen. Jij geeft in totaal 24Gb uit aan je VM's. Dat is echt iets wat je niet moet doen en het kost je enorm in je performance. Waarschijnlijk zit je host constant dan in geheugen nood en probeert dit met diverse technieken op te lossen, je eindigt ermee dat de VM host zich suf staat te swappen.

Je wilt ook producten draaien die erg veel geheugen gaan gebruiken, Exchange heeft een enorme behoefte aan geheugen en zal zoveel mogelijk pakken als er is. Als je SCCM wilt gebruiken heb je nog een SQL Server nodig die ook wel wat RAM lust. SCCM is overigens ook niet vies van wat geheugen gebruik afhankelijk van hoe groot de omgeving is en wat je er allemaal mee doet.

Een tip zou dus zijn om meer geheugen te plaatsen. Of geef je VM's minder RAM. Bedenk ook dat de host zelf geheugen nodig heeft. ESXi heeft ook wat nodig voor zichzelf.

Processor kan je veilig over committen. Het risico is daar lager.

In je storage zie ik ook dat je RAID 0 wilt gebruiken. Niet doen zou ik zeggen. Ik zou kiezen voor RAID 1. Ja, je hebt mindere schrijf performance, maar als een disk kapot gaat draait de boel nog vrolijk door als je een goede RAID kaart hebt. Bij RAID0 is het over als een schijf sterft. Dan moet je een back-up terug gaan zetten.

Let wel dat de gratis versie van VMWare ESXi beperkt is. De eerste paar dagen heb je alle functies, maar als de trial verloopt en je de gratis versie gebruikt zijn een hoop functies weg. Plus zonder vSphere is beheer lastiger.

Hyper-V is net zo volledig en de gratis versie kent geen echte beperkingen anders dan dat het een server core installatie moet zijn en je geen andere rollen mag activeren. Bedenk ook dat als je Windows Server als Hyper-V host hebt je recht hebt op gratis VM's. Standard Edition geeft recht op 1 gratis Standard Edition VM. Als je Datacenter Edition hebt is je aantal VM's onbeperkt. Maar dat is duur.

In theorie heb je voor jouw huidige wens twee Standard Edition licenties nodig. 1 is de Hyper-V host. De licentie van de host gebruik je dan nogmaals voor 1 VM. De overige twee VM's kunnen dan ook draaien op 1 licentie. Overigens maakt het natuurlijk niet uit als je draait op Technet/MSDN licenties. Die kosten je natuurlijk niets extra's.

[Dennism]

Als eerste zou ik kijken naar ESXI 5.5, anders begin je al met een achterstand

Verder de machine zelf: CPU kracht is ruim afdoede voor jouw doeleinden. Ram kan een bottle neck zijn, dit is echter afhankelijk van bijv de load op de exchange server. Bij een lage load kan deze makkelijk uit met bijv 8GB. Denk ook aan het feit dat ESX volgens mij zelf ook iets van 2GB reserveerd voor zichzelf, waardoor je eigenlijk maar 14GB netto hebt. 2 NIC's kan ook en bottlenneck zijn, zeker op 100mbit, upgrade naar 1Gbit zal dan ook een prio zijn denk ik. Als je kiest vooor een NAS storage erbij (zie verder op in mijn post) zou ik mogelijk een upgrade aanraden naar 4 nic's, daar dit voor een paar tientjes kan (zie bijv V&A). Ook als je wil oefenen met ESXI is dit aan te raden.

Verder inderdaad zoals CMD al aangeeft geheugen niet over commiten. Om geheugen te besparen zou je ervoor kunnen kiezen om DC1 en DC2 in core modus te draaien. Dit bespaard aardig wat resources (wij draaien sommige DC's met 1GB ram in core modus) en is voor zoveer ik weet best practise bij Windows 2012 beheer kan je dan doen vanaf de Server Manager op de 3de installatie. Je zal dan alleen even moeten bekijken of je webserver het ondersteund om te draaien in core modus

Qua storage zit je denk ik wel erg krap. Ik zou ESX van USB stick gaan draaien zodat je daar niet al te al teveel storage aan verliest. Server 2012 wordt geloof ik al aangeraden om voor 60GB te kizen bij de install voor de c:\ partitie. Raid 0 niet gebruiken tenzij je goede backups hebt en downtime geen probleem is, 1 schijf dood is alles weg, en uit ervaring weet ik dat deze schijven nog wel eens willen overlijden. Ik weeet niet of je eventueel nog budget hebt. Maar anders zou je er ook voor kunnen kiezen om er een NAS naast te zetten voor data opslag. Je kan dan de disks in de machine gebruiken om bijv een Raid 10 aan te maken van de 8 interne schijven voor de OS/programma partities en de data schijven op een NAS te plaatsen, dit zal ook performance schelen om je interne storage minder IOPS hoeft af te handelen. Dit doe ik zelf ook in mijn homelab.

[ppl]

Mocht ESXi toch teveel beperkingen hebben en is Hyper-V nog steeds geen oplossing dan zou XenServer een goed alternatief kunnen zijn. Met ESXi 5.5 heb je echter weinig beperkingen, de meest belangrijke (maximaal hoeveelheid geheugen) is sinds 5.5 opgeheven (je kunt nu dus 128GB gebruiken als je dat hebt ipv max. 32GB zoals bij ESXi 5.1 en lager).

Naast geheugen is ESXi ook gebrand op goede snelle I/O. Een RAID array doet al veel (naast een stukje high availability), ssd's doen nog meer (kijk even naar het prijsverschil tussen ssd en 15k SAS schijf).

Het toewijzen van resources aan een vm is zo ongeveer het belangrijkste onderdeel. Het beste lijkt een conservatieve aanpak te zijn. Wees dus terughoudend in hoeveelheid geheugen en cpu power die je aan een vm toewijst. Je kunt ook resource pools aanmaken in ESXi om performance beter onder controle te houden (je kunt dit overigens ook per vm doen). Let ook op wat je toewijst aan disk size en of deze thick of thin provisioned is. Wijs zeer zeker ook niet aan iedere vm dezelfde hoeveelheid resources toe. Bekijk per vm wat het nodig heeft en begin klein want je kunt het altijd opschalen als het niet voldoende blijkt te zijn. Daardoor kun je vm's die geheugen nodig hebben dat ook geven.

Als je toch Windows Server 2012 gebruikt loont het zich om de servers zonder GUI te installeren. Dat bespaart weer wat resources. Management kun je via 1 server doen of via een client. Dat levert ook een stukje security omdat je hier een zogenaamde bastion host van maakt.

Tot slot nog iets wat niet met performance te maken heeft: aangezien je alles op de virtualisatie host wil gaan draaien is het ook niet onverstandig om eens naar de networking mogelijkheden te gaan kijken. De gratis ESXi versie is hierin beperkt (ja je kunt nog wel iets met LACP/trunking doen voor network failover en ja je hebt nog wel een virtuele switch). Hoe dat bij een Hyper-V en een XenServer zit weet ik niet. Wellicht nog wel op te vangen door gebruik van VLANs.

[ Voor 7% gewijzigd door ppl op 06-10-2013 22:33 ]

[Wim-Bart]

Virtual Machine 01:
CPU: 2x Intel Xeon E5420 2.50 GHz Quad-Core (Volledig beschikbaar)
RAM: 4GB
Storage: 50GB VMWare Paravirtual
NIC: VMXnet3
OS: Windows Server 2012 Standard
Beoogde rollen: Primary DC, Primary DNS, DHCP + Windows Server Backup

Virtual Machine 02:
CPU: 2x Intel Xeon E5420 2.50 GHz Quad-Core (Volledig beschikbaar)
RAM: 4GB
Storage: 50GB VMWare Paravirtual
NIC: VMXnet3
OS: Windows Server 2012 Standard
Beoogde rollen: Secondary DC, Secondary DNS, DHCP (Load Balance), Webserver (Geen IIS) + Windows Server Backup

Virtual Machine 03:
CPU: 2x Intel Xeon E5420 2.50 GHz Quad-Core (Volledig beschikbaar)
RAM: 16GB
Storage: 50GB + 292GB VMWare Paravirtual
NIC: VMXnet3
OS: Windows Server 2012 Standard
Beoogde rollen: Exchange, IIS, Storage (Home folders e.d.) + Windows Server Backup *

A. Server 2012 wil gewoon 60 GB hebben tijdens installatie.
B. Afhankelijk van aantal mailboxen is Exchange + IIS met 8 GB al zat maar wel met 4 cores.
C. Een DC heeft met 1 GB en 1 Core al meer dan zat, ook onder 2012. Dus met 2GB per machine ben je al klaar.
D. Maak voor storage gewoon een 4e VM. Met 2GB geheugen en 1 CPU.

[Dronium]

Je schrijft bij iedere VM "2x Intel Xeon E5420 2.50 GHz Quad-Core (Volledig beschikbaar)" maar hoeveel vCPU's heb je aan de verschillende VM's toegekend? Als dat bij iedere VM 8 vCPU's zijn kan daar ook wel eens een bottelneck zitten.

Wat betreft Exchange: Ik heb zelf een Exchange 2010 server draaien met 3 normale een 10 tal lichte gebruikers, de VM heeft "maar" 4 Gb geheugen, maar er zijn geen klachten over de performance. Ik weet niet hoe groot het verschil is met Exchange 2013 maar ik denk dat het met 6 of 8 Gb ook prima werkt.

[Question Mark]

@TS: complimenten voor de TS.

Waarom ga je gebruik maken van 2 DC's op dezelfde fysieke host? Is dat niet wat overbodig?

Verder zou ik persoonlijk kiezen om alle userdata op de DC te plaatsen, en de Exchange server dedicated laten zijn. Die machine gaat relatief zwaar belast worden, terwijl je DC eigenlijk niet zoveel te doen heeft.

[CAPSLOCK2000]

- Je hebt meer RAM nodig.
- Koop 2 SSD's ipv van 8 draaischijven, dat is sneller en goedkoper

[Dennism]

CAPSLOCK2000 schreef op maandag 07 oktober 2013 @ 15:38:
- Je hebt meer RAM nodig.
- Koop 2 SSD's ipv van 8 draaischijven, dat is sneller en goedkoper

Werken de huidige consumenten SSD's wel prettig in een G5 dan? Heb in het verleden wat SSD's getest icm de P400 maar alleen maar rare problemen (o.a. uitvallers omdat het systeem geen temperatuur reading kreeg en dus een thermal shutdown gingg uitvoeren, continu meldigen dat de SSD's failed of ready to fail waren terwijl er niets aan de hand was). De enige SSD waarmee het wel normaal liep was er een die van HP zelf was, maarja dan betaalde je ook 600 euro geloof ik voor een 120GB SSD.

[ Voor 6% gewijzigd door Dennism op 07-10-2013 18:20 ]

[wjjkoevoets]

Bedankt voor de uitgebreide reacties allemaal. Er zijn dankzij jullie reacties een aantal zaken (pijnlijk ) duidelijk geworden.

CMD-Snake schreef op zondag 06 oktober 2013 @ 18:24:
Als ik zo snel door je post scroll zie ik al meteen een over commit aan geheugen.

De host heeft 16Gb geheugen. Jij geeft in totaal 24Gb uit aan je VM's. Dat is echt iets wat je niet moet doen en het kost je enorm in je performance. Waarschijnlijk zit je host constant dan in geheugen nood en probeert dit met diverse technieken op te lossen, je eindigt ermee dat de VM host zich suf staat te swappen.

Dennism schreef op zondag 06 oktober 2013 @ 19:22:
Verder inderdaad zoals CMD al aangeeft geheugen niet over commiten. Om geheugen te besparen zou je ervoor kunnen kiezen om DC1 en DC2 in core modus te draaien. Dit bespaard aardig wat resources (wij draaien sommige DC's met 1GB ram in core modus) en is voor zoveer ik weet best practise bij Windows 2012 beheer kan je dan doen vanaf de Server Manager op de 3de installatie. Je zal dan alleen even moeten bekijken of je webserver het ondersteund om te draaien in core modus

ppl schreef op zondag 06 oktober 2013 @ 22:29:
Het toewijzen van resources aan een vm is zo ongeveer het belangrijkste onderdeel. Het beste lijkt een conservatieve aanpak te zijn. Wees dus terughoudend in hoeveelheid geheugen en cpu power die je aan een vm toewijst. Je kunt ook resource pools aanmaken in ESXi om performance beter onder controle te houden (je kunt dit overigens ook per vm doen). Let ook op wat je toewijst aan disk size en of deze thick of thin provisioned is. Wijs zeer zeker ook niet aan iedere vm dezelfde hoeveelheid resources toe. Bekijk per vm wat het nodig heeft en begin klein want je kunt het altijd opschalen als het niet voldoende blijkt te zijn. Daardoor kun je vm's die geheugen nodig hebben dat ook geven

Ik heb me hier ernstig op verkeken en geen rekening gehouden met de footprint van ESXi zelf. Ik heb e.e.a. gecontroleerd en ik ben het systeem aan het verstikken als het om de hoeveelheid beschikbaar geheugen gaat. VM1 en VM2 gebruiken respectievelijk 3,5GB en 3,6GB. Windows ziet natuurlijk dat er een hoeveelheid geheugen beschikbaar is en maakt er gretig gebruik van. Niet over nagedacht en dus verlies ik met 2 VMs al meer dan de helft van mijn beschikbare hoeveelheid geheugen! Tel daarbij het gebruik van 5,9GB van VM3 op en de footprint van ESXi zelf en er blijft niks meer over. Terug naar de tekentafel hiermee!

Overigens VM1 en VM2 draaien op Server 2012 Core! Vergeten dit te melden in mijn startpost! Geïnstalleerd als standaard, daarna ingesteld en daarna ingesteld op Core, verder beheer via VM3.

Voor de Virtual Disks heb ik de standaard instelling van Thick Provisioning Lazy Zero laten staan. Thin Provisioning lijkt mij juist meer IOPS kosten met een nog grotere strain. Eager Zero schijnt niet veel verschil uit te maken heb ik begrepen.

CMD-Snake schreef op zondag 06 oktober 2013 @ 18:24:
Je wilt ook producten draaien die erg veel geheugen gaan gebruiken, Exchange heeft een enorme behoefte aan geheugen en zal zoveel mogelijk pakken als er is. Als je SCCM wilt gebruiken heb je nog een SQL Server nodig die ook wel wat RAM lust. SCCM is overigens ook niet vies van wat geheugen gebruik afhankelijk van hoe groot de omgeving is en wat je er allemaal mee doet.

Een tip zou dus zijn om meer geheugen te plaatsen. Of geef je VM's minder RAM. Bedenk ook dat de host zelf geheugen nodig heeft. ESXi heeft ook wat nodig voor zichzelf.

Wat je dus eigenlijk stelt is dat ik dit allereerst beter uit moet denken en de beschikbare resources eerst moet uitbreiden en daarna beter en efficiënter moet verdelen. Om maar even een voorbeeld te noemen met beperkt budget (2e hands hardware):

BIOS: P56 (NX-bit, VT, Static High Performance mode)
CPU: 2x Intel Xeon E5420 2.50 GHz Quad-Core
RAM: 24GB PC2-5300F
RAID: HP Smart Array P400 512MB BBWC
Storage: 8x 146GB 10K disks + 4GB USB stick
NIC: 2x 1Gbit (draait echter maar op 100Mbit vanwege het netwerk) - Load Balanced via ESXi
Beoogde Hypervisor: HP VMWare ESXi v5.1 U1

USB: ESXi installatie
RAID0: 2x146GB - Voor alle Server 2012 OS'en (~65GB per OS)
RAID5: 6x146GB - Mailbox storage, home folder storage, SCCM packages e.d.

ESXi (2GB RAM)
VM1 (1CPU-AffinityMask 6 - 1GB RAM - 65GB): Server 2012 Core + (P)DC + DNS + DHCP
VM2 (1CPU-AffinityMask 7 - 1GB RAM - 65GB): Server 2012 Core + (P)DC + DNS + DHCP + Webserver (Geen IIS)
VM3 (4CPU-AffinityMask 0,1,6,7 - 10GB RAM - 65GB + 40GB): Server 2012 + Exchange 2013 + Server Management
VM4 (4CPU-AffinityMask 2,3,4,5 - 10GB RAM - 65GB + Rest): Server 2012 Core + SCCM 2012 + Storage

CMD-Snake schreef op zondag 06 oktober 2013 @ 18:24:Processor kan je veilig over committen. Het risico is daar lager.

Is het niet beter om specifiek aan te geven welke server wat tot zijn beschikking heeft, zoals in bovengenoemde voorbeeld?

CMD-Snake schreef op zondag 06 oktober 2013 @ 18:24:
In je storage zie ik ook dat je RAID 0 wilt gebruiken. Niet doen zou ik zeggen. Ik zou kiezen voor RAID 1. Ja, je hebt mindere schrijf performance, maar als een disk kapot gaat draait de boel nog vrolijk door als je een goede RAID kaart hebt. Bij RAID0 is het over als een schijf sterft. Dan moet je een back-up terug gaan zetten.

Ik begrijp je redenatie. Mijn voorkeur voor RAID0 is simpelweg een financiële overweging. Als ik bovenstaand als voorbeeld neem zou ik twee RAID1 arrays nodig hebben en één RAID5 array. Dan mis ik meteen 3x146GB. Van het RAID5 array zal pakweg 400GB storage useable zijn en dan moet er nog 24GB + aan VMWare Swapfiles plus nog eens 10GB voor het pagefile van de Exchange server vanaf getrokken worden. Dan neem ik de NTFS overhead nog niet eens in beschouwing. Mijn beschikbare hoeveelheid storage gaat er dan maar mondjesmaat op vooruit. Ik zou dan al moeten kijken of 2x300GB + 6x146GB. Dilemma dit!

Dennism schreef op zondag 06 oktober 2013 @ 19:22:
Als eerste zou ik kijken naar ESXI 5.5, anders begin je al met een achterstand

Overwogen, maar besloten hier niet voor te kiezen, omdat ESXi 5.0 de laatste officieel ondersteunde versie is voor G5 servers. Het HP image van 5.1 is voor zo ver ik weet de laatste versie die HP drivers voor mijn server heeft. 5.5 is volgens mij alleen geschikt voor G7 en gen8 servers van HP en ik durfde het dan ook niet aan om het te proberen. Jij hebt hier een andere ervaring mee misschien?

Dennism schreef op zondag 06 oktober 2013 @ 19:22:
Verder de machine zelf: CPU kracht is ruim afdoede voor jouw doeleinden. Ram kan een bottle neck zijn, dit is echter afhankelijk van bijv de load op de exchange server. Bij een lage load kan deze makkelijk uit met bijv 8GB. Denk ook aan het feit dat ESX volgens mij zelf ook iets van 2GB reserveerd voor zichzelf, waardoor je eigenlijk maar 14GB netto hebt.

Van de CPU had ik verwacht dat deze inderdaad voldoende zou zijn. Zoals ik al aangaf heb ik me echter op de hoeveelheid RAM verkeken en totaal geen rekening gehouden met de footprint van ESXi. Vandaar bovengenoemde voorbeeld.

De load zal met maximaal 5 gelijktijdige gebruikers niet heel hoog zijn. Ook de mailboxgrootte zal erg beperkt zijn (ik denk 1GB TOTAAL). OWA en ActiveSync zullen wel gebruikt worden. Zou dit toch te doen zijn met 8GB? Ik heb een slecht beeld van het geheugengebruik van Exchange, want ik heb het alleen mogen aanschouwen in “business” situaties (ca. 4000 mailboxen) en dat ga je niet redden met 8GB

Dennism schreef op zondag 06 oktober 2013 @ 19:22:
2 NIC's kan ook en bottlenneck zijn, zeker op 100mbit, upgrade naar 1Gbit zal dan ook een prio zijn denk ik. Als je kiest vooor een NAS storage erbij (zie verder op in mijn post) zou ik mogelijk een upgrade aanraden naar 4 nic's, daar dit voor een paar tientjes kan (zie bijv V&A). Ook als je wil oefenen met ESXI is dit aan te raden.

Qua storage zit je denk ik wel erg krap. Ik zou ESX van USB stick gaan draaien zodat je daar niet al te al teveel storage aan verliest. Server 2012 wordt geloof ik al aangeraden om voor 60GB te kizen bij de install voor de c:\ partitie. Raid 0 niet gebruiken tenzij je goede backups hebt en downtime geen probleem is, 1 schijf dood is alles weg, en uit ervaring weet ik dat deze schijven nog wel eens willen overlijden. Ik weeet niet of je eventueel nog budget hebt. Maar anders zou je er ook voor kunnen kiezen om er een NAS naast te zetten voor data opslag. Je kan dan de disks in de machine gebruiken om bijv een Raid 10 aan te maken van de 8 interne schijven voor de OS/programma partities en de data schijven op een NAS te plaatsen, dit zal ook performance schelen om je interne storage minder IOPS hoeft af te handelen. Dit doe ik zelf ook in mijn homelab.

Het vervelende van het overschakelen naar 1Gbit is dat ik gelijk een heleboel apparatuur moet vervangen, omdat het simpelweg geen 1Gbit ondersteund. Mijn vaste computers zijn allebei voorzien van Gbit NICs, maar ik heb hier minstens 4 APs, 2 printers en nog wat andere randapparatuur die vervangen zou moeten worden. Hetzelfde geldt dus eigenlijk ook voor het plaatsen van een NAS. Als ik het geld had had ik alleen maar Gbit apparatuur en een NAS gevuld met een paar 2TB schijven i.c.m. ZFS. Stopte ik per OS een compatible SSD in de server en gaan met die banaan. Wat betreft RAID0, dat zal ik even voor mezelf uit moeten vogelen.

ppl schreef op zondag 06 oktober 2013 @ 22:29:
Mocht ESXi toch teveel beperkingen hebben en is Hyper-V nog steeds geen oplossing dan zou XenServer een goed alternatief kunnen zijn. Met ESXi 5.5 heb je echter weinig beperkingen, de meest belangrijke (maximaal hoeveelheid geheugen) is sinds 5.5 opgeheven (je kunt nu dus 128GB gebruiken als je dat hebt ipv max. 32GB zoals bij ESXi 5.1 en lager).

Ik denk dat ik met mijn server, qua hard en software nou niet echt direct tegen de limieten ga lopen van ESXi. Ik gebruik, naar mijn bescheiden mening, vooral de basis functies van het pakket en een betaalde licentie heeft niet echt veel meerwaarde voor mij.

ppl schreef op zondag 06 oktober 2013 @ 22:29:
Naast geheugen is ESXi ook gebrand op goede snelle I/O. Een RAID array doet al veel (naast een stukje high availability), ssd's doen nog meer (kijk even naar het prijsverschil tussen ssd en 15k SAS schijf).

Ik ben niet van plan om schijven nieuw aan te schaffen, dit omdat 15K schijven met redelijke capaciteit of SSDs met soortgelijke capaciteit gewoon een stuk duurder zijn. Het is een thuisserver dus ik kan best met uitval van een schijf leven (Dus tweedehands is geen bezwaar in deze, immers zijn mijn huidige schijven ook gebruikt). Mijn backup Exchanger houdt e-mails 10 dagen vast en availability is voornamelijk voor mijzelf een probleem, niet zo zeer voor andere gebruikers.

ppl schreef op zondag 06 oktober 2013 @ 22:29:
Tot slot nog iets wat niet met performance te maken heeft: aangezien je alles op de virtualisatie host wil gaan draaien is het ook niet onverstandig om eens naar de networking mogelijkheden te gaan kijken. De gratis ESXi versie is hierin beperkt (ja je kunt nog wel iets met LACP/trunking doen voor network failover en ja je hebt nog wel een virtuele switch). Hoe dat bij een Hyper-V en een XenServer zit weet ik niet. Wellicht nog wel op te vangen door gebruik van VLANs.

Ho, stop! Hier ga ik even op de rem trappen haha. Networking is niet echt mijn ding en termen als LACP zeggen mij niks moet ik bekennen. De huidige setup is zoals aangegeven vrij simpel. Ik ben al blij dat ESXi het eenvoudig maakt om load balancing in te stellen.

Wim-Bart schreef op zondag 06 oktober 2013 @ 22:39:
[...]


A. Server 2012 wil gewoon 60 GB hebben tijdens installatie.
B. Afhankelijk van aantal mailboxen is Exchange + IIS met 8 GB al zat maar wel met 4 cores.
C. Een DC heeft met 1 GB en 1 Core al meer dan zat, ook onder 2012. Dus met 2GB per machine ben je al klaar.
D. Maak voor storage gewoon een 4e VM. Met 2GB geheugen en 1 CPU.

A. Officiële minimum voor Server 2012 is (even uit mijn hoofd) ca. 35GB. Dat het geen recommended practice is ben ik wel helemaal met je eens. Ik ga mijn hardware configuratie wel herzien, zoals boven aangegeven
B. Dat zou dan mogelijk moeten zijn met bovengenoemde configuratie
C. Dat gaat sowieso gebeuren inderdaad. 1CPU, 1GB RAM en Server 2012 Core
D. Storage zal niet intensief gebruikt worden, zou denk in mijn geval teveel resources kosten en overkill zijn.

Dronium schreef op zondag 06 oktober 2013 @ 22:40:
Je schrijft bij iedere VM "2x Intel Xeon E5420 2.50 GHz Quad-Core (Volledig beschikbaar)" maar hoeveel vCPU's heb je aan de verschillende VM's toegekend? Als dat bij iedere VM 8 vCPU's zijn kan daar ook wel eens een bottelneck zitten.

Wat betreft Exchange: Ik heb zelf een Exchange 2010 server draaien met 3 normale een 10 tal lichte gebruikers, de VM heeft "maar" 4 Gb geheugen, maar er zijn geen klachten over de performance. Ik weet niet hoe groot het verschil is met Exchange 2013 maar ik denk dat het met 6 of 8 Gb ook prima werkt.

vCPU is voor alle hosts in de huidige pilot gelijk (2 sockets, 2 Quad-Core CPUs). Ik wil dit dus in de uiteindelijke configuratie aanpassen naar gelang bovenstaande voorbeeld, mits dat natuurlijk een goed idee zou zijn (gebruik van AffinityMasks bijvoorbeeld).

Dat valt helemaal niet tegen! Ik heb niet echt de indruk dat Exchange 2013 nu echt noemenswaardig veel zwaarder draait dan 2010. Wel valt op dat IIS Worker processon de CPU wel aan het werk zetten.

Question Mark schreef op maandag 07 oktober 2013 @ 09:25:
@TS: complimenten voor de TS.

Waarom ga je gebruik maken van 2 DC's op dezelfde fysieke host? Is dat niet wat overbodig?

Verder zou ik persoonlijk kiezen om alle userdata op de DC te plaatsen, en de Exchange server dedicated laten zijn. Die machine gaat relatief zwaar belast worden, terwijl je DC eigenlijk niet zoveel te doen heeft.

Dank u!

Volgens Microsoft is het best practice om tenminste twee domain controllers te hebben en een DNS backup. Ik heb dat dan ook gedaan. En als je dan toch bezig bent kan je net zo goed ook meteen DHCP zo inregelen, zoveel performance kost dat denk ik niet. Ik ben een beetje huiverig om de userdata op de DC te plaatsen, omdat dat systeem niet al teveel capaciteit zou gaan krijgen.

CAPSLOCK2000 schreef op maandag 07 oktober 2013 @ 15:38:
- Je hebt meer RAM nodig.
- Koop 2 SSD's ipv van 8 draaischijven, dat is sneller en goedkoper

Meer RAM lijkt me na alle posts in het topic inderdaad een goede oplossing, vooral als ik SSCM in de mix wil gooien. Wat betreft de schijven, ik ben van plan deze tweedehands te kopen. *Afkloppen* Ik ben tot nu toe in heel mijn “thuisserver carrière” nog maar een stuk of 5 defecte schijven tegen gekomen. Allemaal Fujitsu 9,1GB 7200RPM schijven (1997/1998, overleden in 2007). Voor de rest nog nooit met een enkele SAS of SCSI schijf problemen gehad. Not afraid of living on the edge when it comes to the most unreliable part of the server

Dennism schreef op maandag 07 oktober 2013 @ 18:19:
[...]


Werken de huidige consumenten SSD's wel prettig in een G5 dan? Heb in het verleden wat SSD's getest icm de P400 maar alleen maar rare problemen (o.a. uitvallers omdat het systeem geen temperatuur reading kreeg en dus een thermal shutdown gingg uitvoeren, continu meldigen dat de SSD's failed of ready to fail waren terwijl er niets aan de hand was). De enige SSD waarmee het wel normaal liep was er een die van HP zelf was, maarja dan betaalde je ook 600 euro geloof ik voor een 120GB SSD.

SSD support zal wel beperkt zijn voor deze controllers. Het is immers niet de jongste meer in ik betwijfel of HP nog de moeite zou doen om een firmware update uit te brengen. Misschien dat men juist daarom wel een gemodificeerde SSD uit brengt die de fix aan de kant van de SSD heeft die meteen voor elke veoruderde storage controller van HP werkt. Helaas betaal je daar dan ook penning 16 voor.


En nu is mijn typ arm even defect

[Dronium]

VM1 (1CPU-AffinityMask 6 - 1GB RAM - 65GB): Server 2012 Core + (P)DC + DNS + DHCP
VM2 (1CPU-AffinityMask 7 - 1GB RAM - 65GB): Server 2012 Core + (P)DC + DNS + DHCP + Webserver (Geen IIS)
VM3 (4CPU-AffinityMask 0,1,6,7 - 10GB RAM - 65GB + 40GB): Server 2012 + Exchange 2013 + Server Management
VM4 (4CPU-AffinityMask 2,3,4,5 - 10GB RAM - 65GB + Rest): Server 2012 Core + SCCM 2012 + Storage

Ik werkt met VMware sinds versie 3.5 en ben nog nooit tegen een situatie aangelopen waar het nodig was om AffinityMasks in te stellen. Dat moet je ESXi mooi zelf uit laten zoeken.

Ik begrijp je redenatie. Mijn voorkeur voor RAID0 is simpelweg een financiële overweging. Als ik bovenstaand als voorbeeld neem zou ik twee RAID1 arrays nodig hebben en één RAID5 array. Dan mis ik meteen 3x146GB. Van het RAID5 array zal pakweg 400GB storage useable zijn en dan moet er nog 24GB + aan VMWare Swapfiles plus nog eens 10GB voor het pagefile van de Exchange server vanaf getrokken worden. Dan neem ik de NTFS overhead nog niet eens in beschouwing. Mijn beschikbare hoeveelheid storage gaat er dan maar mondjesmaat op vooruit. Ik zou dan al moeten kijken of 2x300GB + 6x146GB. Dilemma dit!

Thuis draait een Homebrew server (Core i7 920 stock / 24 Gb memory) met 4x een 1Tb SATA disk (WD Green series) aan een P400 met Cache en een Battery Backup. Die laatste is het belangrijkste voor je performance, zonder dat ding wordt de write cache van je controler uitgeschakeld
Al mijn disks zijn thin provisioned en daar merkt je qua performance eigenlijk niets van. maar het scheelt een hoop ruimte:
Win 2008r2 Core (DC/DNS/DHCP) 42,11Gb provisioned - 16,51Gb Used
Win 2012 Core (DC/DNS) 44,2Gb provisioned - 12,96 Gb Used
Win 2008r2 full + Exchange 2010 144,11Gb provisioned 58,11Gb Used

[...]

Overwogen, maar besloten hier niet voor te kiezen, omdat ESXi 5.0 de laatste officieel ondersteunde versie is voor G5 servers. Het HP image van 5.1 is voor zo ver ik weet de laatste versie die HP drivers voor mijn server heeft. 5.5 is volgens mij alleen geschikt voor G7 en gen8 servers van HP en ik durfde het dan ook niet aan om het te proberen. Jij hebt hier een andere ervaring mee misschien?

Gewoon proberen, het is een echte HP server dus dat zal wel lukken. Er zijn genoeg whiteboxen (zoals die van mij) die helemaal niet ondersteund worden maar waar het gewoon op werkt.

Van de CPU had ik verwacht dat deze inderdaad voldoende zou zijn. Zoals ik al aangaf heb ik me echter op de hoeveelheid RAM verkeken en totaal geen rekening gehouden met de footprint van ESXi. Vandaar bovengenoemde voorbeeld.

Geheugen overcommiten is meestal funest voor je performance omdat er dan disk IO aan te pas moet komen.

De load zal met maximaal 5 gelijktijdige gebruikers niet heel hoog zijn. Ook de mailboxgrootte zal erg beperkt zijn (ik denk 1GB TOTAAL). OWA en ActiveSync zullen wel gebruikt worden. Zou dit toch te doen zijn met 8GB? Ik heb een slecht beeld van het geheugengebruik van Exchange, want ik heb het alleen mogen aanschouwen in “business” situaties (ca. 4000 mailboxen) en dat ga je niet redden met 8GB

Exchange (vanaf versie 2007) heeft de eigenschap om all het geheugen te claimen (dus niet perse gebruiken) dat beschikbaar is. Gewoon bij 6Gb beginnen en alleen ophogen als je merkt dat het niet performed. Dat geld ook voor je vCPU's, beginnen met 2 en alleen ophogen indien nodig. En denk er aan 3 vCPUs kan tegenwoordig ook.

Volgens Microsoft is het best practice om tenminste twee domain controllers te hebben en een DNS backup. Ik heb dat dan ook gedaan. En als je dan toch bezig bent kan je net zo goed ook meteen DHCP zo inregelen, zoveel performance kost dat denk ik niet. Ik ben een beetje huiverig om de userdata op de DC te plaatsen, omdat dat systeem niet al teveel capaciteit zou gaan krijgen.

Als je (zoals hier boven vermeld) de storage niet te zwaar gaat belasten is een DC op Windows Core de locatie voor je files. Heb je meteen een reden om een van de DC's op de andere Raid set te zetten, dan ben je bij een crash van je Raid 0 tenmiste niet je domain kwijt. Als je beide DC's op dezelfde Raidset plaatst schoffel je het nut van een 2e DC nogal onderuit. Als je niet te hard aan je storage gaat trekken is thin provisioning zowiezo een mooie optie, dan kun je naar Raid 10 ipv Raid 0. Dat performance verschil ga je dat in een thuis situatie met jouw hardware niet merken.

Meer RAM lijkt me na alle posts in het topic inderdaad een goede oplossing, vooral als ik SSCM in de mix wil gooien.

Meer RAM is altijd beter

En nu is mijn typ arm even defect

Welkom in de Wondere wereld van de IT

Kort samen gevat.

• Resource management zoveel mogelijk aan ESXi overlaten
• Indien mogelijk je raid 0 kwijt raken (thin provisioning)
• DC's verdelen over de 2 Raidsets
• Resources voor je VMs zolaag mogelijk inschalen en alleen ophogen indien nodig
• Meer geheugen is altijd beter

[ppl]

wjjkoevoets schreef op maandag 07 oktober 2013 @ 19:56:
Voor de Virtual Disks heb ik de standaard instelling van Thick Provisioning Lazy Zero laten staan. Thin Provisioning lijkt mij juist meer IOPS kosten met een nog grotere strain. Eager Zero schijnt niet veel verschil uit te maken heb ik begrepen.

De meningen lijken hier een beetje over uiteen te lopen maar waar iedereen wel zeker over is: thin provisioned neemt minder ruimte in beslag dan thick provisioned. Dat is eigenlijk de enige echte reden om voor thin provisioned te gaan. Het voorkomt in de toekomst wat gedoe met je vm's omdat je daar weer de disk moet gaan vergroten. Je hoeft dan alleen de storage voor je ESXi server te vergroten (hebben meer vm's baat bij). Qua performance zou ik me niet druk maken, velen zeggen dat ze het verschil niet merken.

Wat je dus eigenlijk stelt is dat ik dit allereerst beter uit moet denken en de beschikbare resources eerst moet uitbreiden en daarna beter en efficiënter moet verdelen.

Dat is wel het idee. Virtualisatie betekent dat je resources efficiënter kunt maar ook moet gaan inzetten. Als je het verkeerd doet loop je tegen performance problemen aan. Wat mensen vaak ook nog wel eens vergeten: veel operating systems, waaronder ook Windows, kunnen prima met een paar maatjes minder. Het hoeft allemaal niet met een sloot aan cpu's en geheugen.

VM1 (1CPU-AffinityMask 6 - 1GB RAM - 65GB): Server 2012 Core + (P)DC + DNS + DHCP
VM2 (1CPU-AffinityMask 7 - 1GB RAM - 65GB): Server 2012 Core + (P)DC + DNS + DHCP + Webserver (Geen IIS)
VM3 (4CPU-AffinityMask 0,1,6,7 - 10GB RAM - 65GB + 40GB): Server 2012 + Exchange 2013 + Server Management
VM4 (4CPU-AffinityMask 2,3,4,5 - 10GB RAM - 65GB + Rest): Server 2012 Core + SCCM 2012 + Storage

Pas op met het toewijzen van vCPU's. Veruit de meeste performance problemen bij de hobbyisten ontstaan door het toewijzen van teveel vCPU's (en in zekere mate ook wel het overcommitten van geheugen). VMware hanteert de vuistregel: aantal fysieke cores/2 = maximum aantal toe te wijzen vCPU's aan een vm. Bij een quad core cpu met hyperthreading zijn er maar 4 fysieke cores dus kun je maar maximaal 2 vCPU's aan een vm toewijzen. Doe je meer dan houdt je niks over voor de rest en wordt alles heel traag. ESXi is verder ook slim genoeg om zelf de workload over de beschikbare cpu cores (hyperthreading meegerekend) te verdelen. Het beste is het toewijzen van 1 vCPU en pas dat aantal omhoog te schroeven wanneer het cpu gebruik van de vm vrijwel continu rond de 80~100% blijft hangen (beter is om eerst te gaan kijken waarom hij dat doet; wellicht valt er in de vm zelf wat tweaks toe te passen).
Hyperthreading is een leuk extraatje maar op die "cores" moet je niet rekenen omdat dit geen echte cores zijn. Het hyperthreading deel moet je gewoon aan ESXi overlaten; houdt je verder gewoon aan de vuistregel.

Als je wat meer wil weten: zoek eens wat gerichter op zaken als geheugenmanagement van ESXi. Er zijn diverse whitepapers van VMware zelf als ook sites die hierover hebben geschreven. vmug.nl is een aardige om te beginnen (Nederlandse VMware usergroup; zie hun blogroll rechtsonder voor meer handige sites).
Neus vooral ook zelf eens rond in de vSphere client. Het heeft aardig wat monitoring opties om de performance van de verschillende vm's in de gaten te houden als ook van de server zelf. Dat geeft je vaak al een goed idee of je teveel of te weinig resources hebt uitgedeeld aan een vm.

Ho, stop! Hier ga ik even op de rem trappen haha. Networking is niet echt mijn ding en termen als LACP zeggen mij niks moet ik bekennen. De huidige setup is zoals aangegeven vrij simpel. Ik ben al blij dat ESXi het eenvoudig maakt om load balancing in te stellen.

Het instellen is niet zo heel moeilijk en gelukkig is er overal en nergens ook prima documentatie over te vinden. Het is wel slim om je daar wat meer in te verdiepen wanneer je alles op die ESXi doos wil doen, dan weet je een beetje wat wel en niet kan.

En nu is mijn typ arm even defect

Misschien toch maar een secretaresse erbij nemen

[Dennism]

Het vervelende van het overschakelen naar 1Gbit is dat ik gelijk een heleboel apparatuur moet vervangen, omdat het simpelweg geen 1Gbit ondersteund. Mijn vaste computers zijn allebei voorzien van Gbit NICs, maar ik heb hier minstens 4 APs, 2 printers en nog wat andere randapparatuur die vervangen zou moeten worden. Hetzelfde geldt dus eigenlijk ook voor het plaatsen van een NAS. Als ik het geld had had ik alleen maar Gbit apparatuur en een NAS gevuld met een paar 2TB schijven i.c.m. ZFS. Stopte ik per OS een compatible SSD in de server en gaan met die banaan. Wat betreft RAID0, dat zal ik even voor mezelf uit moeten vogelen.

Voor Gbit hoef je alleen je switch te vervangen Printers / AP's kunnen gewoon op 100mbit blijven draaien zonder problemen terwijl de rest op gbit staat.

[Wim-Bart]

Ik zie dat je DC's core installaties zijn, dus met 1GB per VM en 1 vCPU per VM zit je wel safe. Zelf heb ik 2012 met GUI draaien onder 2 GB maar dat is overkill. Ga nu zelf eens testen met 1GB :-)

Exchange, kan je testen tussen 6 en 8GB, zelf had ik eerst 12GB met 20 mailboxen inclusief public folders, Archiving en CAS/OWA op de zelfde machine. Dit kon met gemak terug naar 6GB.

Bovendien je hebt 2 x een DC, dus die kan je gewoon thin provisionen. Merk je niks nada noppes van.

[CMD-Snake]

wjjkoevoets schreef op maandag 07 oktober 2013 @ 19:56:
Voor de Virtual Disks heb ik de standaard instelling van Thick Provisioning Lazy Zero laten staan. Thin Provisioning lijkt mij juist meer IOPS kosten met een nog grotere strain. Eager Zero schijnt niet veel verschil uit te maken heb ik begrepen.

Die impact valt wel mee. Het grote verschil is dat met Thick Provisioning je meteen een bestand hebt van zeg 40Gb. Bij Thin groeit het bestand rustig mee. Als je dus niet de volledige schijf gebruikt in de VM dan bespaar je juist ruimte.

Je kan eventueel meer ruimte nog besparen als je Hyper-V gaat draaien. Bij een volledige versie kan je ook van de File Server rol deduplicatie instellen. Je ontdubbeld dan alles in je storage. In feite dus elke Windows installatie van een VM is dubbel, kost in het begin wel een hoop CPU kracht, maar uiteindelijk bespaar je flink ruimte daarna.

Eventueel kan je ook nog in Hyper-V één VHD maken als basis image en de servers draaien met differencing disks. Die baseer je dan op die ene image VHD. Voordeel is dat je dan meer een VHD hebt als referentie en alle unieke eigenschappen van de VM's sla je op in de differencing disks.

USB: ESXi installatie
RAID0: 2x146GB - Voor alle Server 2012 OS'en (~65GB per OS)
RAID5: 6x146GB - Mailbox storage, home folder storage, SCCM packages e.d.

ESXi (2GB RAM)
VM1 (1CPU-AffinityMask 6 - 1GB RAM - 65GB): Server 2012 Core + (P)DC + DNS + DHCP
VM2 (1CPU-AffinityMask 7 - 1GB RAM - 65GB): Server 2012 Core + (P)DC + DNS + DHCP + Webserver (Geen IIS)
VM3 (4CPU-AffinityMask 0,1,6,7 - 10GB RAM - 65GB + 40GB): Server 2012 + Exchange 2013 + Server Management
VM4 (4CPU-AffinityMask 2,3,4,5 - 10GB RAM - 65GB + Rest): Server 2012 Core + SCCM 2012 + Storage


Is het niet beter om specifiek aan te geven welke server wat tot zijn beschikking heeft, zoals in bovengenoemde voorbeeld?

Nee, dat is het niet. Je kan de hypervisor dwingen, maar dat kan je performance kosten. Ik laat dit altijd aan de hypervisor over. Die kan precies zien welke CPU hoe druk is etc. etc.. Als je alles vast gaat zetten kan je hypervisor niet meer schuiven met resources. Dat ga je echt merken als je VM's onder druk komen te staan.

Ik begrijp je redenatie. Mijn voorkeur voor RAID0 is simpelweg een financiële overweging. Als ik bovenstaand als voorbeeld neem zou ik twee RAID1 arrays nodig hebben en één RAID5 array. Dan mis ik meteen 3x146GB. Van het RAID5 array zal pakweg 400GB storage useable zijn en dan moet er nog 24GB + aan VMWare Swapfiles plus nog eens 10GB voor het pagefile van de Exchange server vanaf getrokken worden. Dan neem ik de NTFS overhead nog niet eens in beschouwing. Mijn beschikbare hoeveelheid storage gaat er dan maar mondjesmaat op vooruit. Ik zou dan al moeten kijken of 2x300GB + 6x146GB. Dilemma dit!

Het is een ontwerpkeuze. Ik wijs je alleen op de risico's. Waarom eigenlijk SAS schijven? Als het toch niet zo druk wordt kan je gewone SATA schijven nemen. Zijn een stuk goedkoper en ruimer. Tevens als je uit iets als de WD Blue of Black lijn koopt gaan ze ook nog heel lang mee.

Volgens Microsoft is het best practice om tenminste twee domain controllers te hebben en een DNS backup. Ik heb dat dan ook gedaan. En als je dan toch bezig bent kan je net zo goed ook meteen DHCP zo inregelen, zoveel performance kost dat denk ik niet. Ik ben een beetje huiverig om de userdata op de DC te plaatsen, omdat dat systeem niet al teveel capaciteit zou gaan krijgen.

Ja, in een bedrijfsomgeving is twee DC's of meer aanbevolen. Maar jij draait alles virtueel op een systeem. Als je hypervisor ermee stopt, dan is alles toch weg. Je zou in feite dan die tweede DC fysiek moeten maken.

De kans op software falen is heel klein tegenwoordig.

Meer RAM lijkt me na alle posts in het topic inderdaad een goede oplossing, vooral als ik SSCM in de mix wil gooien. Wat betreft de schijven, ik ben van plan deze tweedehands te kopen. *Afkloppen* Ik ben tot nu toe in heel mijn “thuisserver carrière” nog maar een stuk of 5 defecte schijven tegen gekomen. Allemaal Fujitsu 9,1GB 7200RPM schijven (1997/1998, overleden in 2007). Voor de rest nog nooit met een enkele SAS of SCSI schijf problemen gehad. Not afraid of living on the edge when it comes to the most unreliable part of the server

Koop gewoon SATA disks. De wat mindere performance weegt echt wel op tegen de enorme besparing. Een grote SAS schijf kost een veelvoud van een SATA schijf.

[Dennism]

CMD-Snake schreef op maandag 07 oktober 2013 @ 23:00:


Het is een ontwerpkeuze. Ik wijs je alleen op de risico's. Waarom eigenlijk SAS schijven? Als het toch niet zo druk wordt kan je gewone SATA schijven nemen. Zijn een stuk goedkoper en ruimer. Tevens als je uit iets als de WD Blue of Black lijn koopt gaan ze ook nog heel lang mee.


Koop gewoon SATA disks. De wat mindere performance weegt echt wel op tegen de enorme besparing. Een grote SAS schijf kost een veelvoud van een SATA schijf.

Hou je er wel rekening mee dat de P400 controller erom bekend staat deze vrij picky is qua schijven. Zomaar een advies geven voor WD black of blue's zou ik niet doen zonder te testen. Kleine guideline bij deze controller is dat alles met een HP firmware dat op de compatibility list staat werkt, alles wat niet op de lijst staat is een gok en kan wel of niet werken tot 2TB, daarboven is volgens mij sowieso niet compatible. Daarnaast heeft deze controller geloof ik schijven nodig met een TLER firmware als je geen array problemen wil.

[Farg0]

Overwogen, maar besloten hier niet voor te kiezen, omdat ESXi 5.0 de laatste officieel ondersteunde versie is voor G5 servers. Het HP image van 5.1 is voor zo ver ik weet de laatste versie die HP drivers voor mijn server heeft. 5.5 is volgens mij alleen geschikt voor G7 en gen8 servers van HP en ik durfde het dan ook niet aan om het te proberen. Jij hebt hier een andere ervaring mee misschien?

https://my.vmware.com/web...A-19SEP2013&productId=353

werkt nochtans perfect hier op DL360 & DL380 G5

[Jazzy]

Twee domain controllers op dezelfde fysieke server heft geen/weinig meerwaarde. Het idee hiervan is dat je domain en DNS beschikbaar blijkt als er een fysieke server wegvalt. In jouw situatie zou ik kiezen voor een enkele DC, dat scheelt je resources en vermindert de complexiteit.

[CMD-Snake]

Dennism schreef op maandag 07 oktober 2013 @ 23:16:

Hou je er wel rekening mee dat de P400 controller erom bekend staat deze vrij picky is qua schijven. Zomaar een advies geven voor WD black of blue's zou ik niet doen zonder te testen. Kleine guideline bij deze controller is dat alles met een HP firmware dat op de compatibility list staat werkt, alles wat niet op de lijst staat is een gok en kan wel of niet werken tot 2TB, daarboven is volgens mij sowieso niet compatible. Daarnaast heeft deze controller geloof ik schijven nodig met een TLER firmware als je geen array problemen wil.

Ik heb thuis een Hyper-V server op basis van een PowerEdge server. De Dell RAID kaart accepteert gelukkig een hoop. Privé koop ik liever niet die dure SAS schijven.

WD Blue en Black zei ik enkel als voorbeeld. WD heeft ook SATA schijven met TLER functie. Andere merken verkopen ook disks uit series die langer moeten leven. Sowieso moet je wel wat betere SATA schijven nemen in verband met de levensduur. Reguliere schijfjes gaan vrij snel stuk als ze 24/7 draaien.

[wjjkoevoets]

Dronium schreef op maandag 07 oktober 2013 @ 21:12:
Ik werkt met VMware sinds versie 3.5 en ben nog nooit tegen een situatie aangelopen waar het nodig was om AffinityMasks in te stellen. Dat moet je ESXi mooi zelf uit laten zoeken.

ppl schreef op maandag 07 oktober 2013 @ 21:33:
Pas op met het toewijzen van vCPU's. Veruit de meeste performance problemen bij de hobbyisten ontstaan door het toewijzen van teveel vCPU's (en in zekere mate ook wel het overcommitten van geheugen). VMware hanteert de vuistregel: aantal fysieke cores/2 = maximum aantal toe te wijzen vCPU's aan een vm. Bij een quad core cpu met hyperthreading zijn er maar 4 fysieke cores dus kun je maar maximaal 2 vCPU's aan een vm toewijzen. Doe je meer dan houdt je niks over voor de rest en wordt alles heel traag. ESXi is verder ook slim genoeg om zelf de workload over de beschikbare cpu cores (hyperthreading meegerekend) te verdelen. Het beste is het toewijzen van 1 vCPU en pas dat aantal omhoog te schroeven wanneer het cpu gebruik van de vm vrijwel continu rond de 80~100% blijft hangen (beter is om eerst te gaan kijken waarom hij dat doet; wellicht valt er in de vm zelf wat tweaks toe te passen).
Hyperthreading is een leuk extraatje maar op die "cores" moet je niet rekenen omdat dit geen echte cores zijn. Het hyperthreading deel moet je gewoon aan ESXi overlaten; houdt je verder gewoon aan de vuistregel.

CMD-Snake schreef op maandag 07 oktober 2013 @ 23:00:
Nee, dat is het niet. Je kan de hypervisor dwingen, maar dat kan je performance kosten. Ik laat dit altijd aan de hypervisor over. Die kan precies zien welke CPU hoe druk is etc. etc.. Als je alles vast gaat zetten kan je hypervisor niet meer schuiven met resources. Dat ga je echt merken als je VM's onder druk komen te staan.

Ik heb gelukkig geen CPUs met hyperthreading (sowieso nooit een fan van geweest). Conservatief beleid is hier dus het devies. Terughoudend met de toewijzing van CPUs aan een machine en VMWare de managementtaken op zich laten nemen. En ja, wat je (ppl) zegt is gezien het uitgangspunt van virulisatie eigenlijk ook logisch. Een CPU die staat te werken is een stuk efficiënter dan eentje die idle'd, dus met minimale toewijzing valt de meeste efficiëntie te halen.

Dronium schreef op maandag 07 oktober 2013 @ 21:12:
Thuis draait een Homebrew server (Core i7 920 stock / 24 Gb memory) met 4x een 1Tb SATA disk (WD Green series) aan een P400 met Cache en een Battery Backup. Die laatste is het belangrijkste voor je performance, zonder dat ding wordt de write cache van je controler uitgeschakeld
Al mijn disks zijn thin provisioned en daar merkt je qua performance eigenlijk niets van. maar het scheelt een hoop ruimte:
Win 2008r2 Core (DC/DNS/DHCP) 42,11Gb provisioned - 16,51Gb Used
Win 2012 Core (DC/DNS) 44,2Gb provisioned - 12,96 Gb Used
Win 2008r2 full + Exchange 2010 144,11Gb provisioned 58,11Gb Used

CMD-Snake schreef op maandag 07 oktober 2013 @ 23:00:
Die impact valt wel mee. Het grote verschil is dat met Thick Provisioning je meteen een bestand hebt van zeg 40Gb. Bij Thin groeit het bestand rustig mee. Als je dus niet de volledige schijf gebruikt in de VM dan bespaar je juist ruimte.

Hm, dit zou natuurlijk een uitkomst bieden. Bij normaal gebruik verwacht ik niet dat Windows meer dan ca. 35-40GB gaat gebruiken op de C: schijf. Ik kan dus feitelijk 60GB partities maken, zodat Windows tevreden is (kijkend naar mijn Windows 8 machine, die draait al maanden op een 50GB partitie met ca. 20GB aan free space). Gevolg is dat ik, redelijkerwijs, meer storage kan benutten voor andere zaken. Op het moment dat de Windows partitie vol zou lopen is er naar mijn mening toch al iets mis! Ik zou monitoring software kunnen gebruiken om het disk gebruik in de gaten te houden. Als thin provisioning dusdanig weinig real life impact heeft op performance dan ga ik zeker over.

Mag ik trouwens vragen hoe je die Sever 2012 Core installatie zo belachelijk klein hebt gekregen, Dronium (Win 2012 Core (DC/DNS) 44,2Gb provisioned - 12,96 Gb Used)?

Ja, ik weet het, een maatje van mij klaagde dat zijn P400 slecht presteerde. Meneer bleek geen BBWC te hebben met als gevolg dat de controller de write cache uitschakelde. Performance was werkelijk om te huilen. Mijn controller had in eerste instantie 256MB cache, maar ik kon spotgoedkoop aan 512MB komen, dus dat ook maar meteen in orde gemaakt en de batteries zijn vooralsnog in orde.

Dronium schreef op maandag 07 oktober 2013 @ 21:12:
Gewoon proberen, het is een echte HP server dus dat zal wel lukken. Er zijn genoeg whiteboxen (zoals die van mij) die helemaal niet ondersteund worden maar waar het gewoon op werkt.

Farg0 schreef op maandag 07 oktober 2013 @ 23:31:
https://my.vmware.com/web...A-19SEP2013&productId=353

werkt nochtans perfect hier op DL360 & DL380 G5

Sounds like a plan! Upgrade naar ESXi v5.5 HP met installatie op dedicated usb stick.

Wim-Bart schreef op maandag 07 oktober 2013 @ 22:58:
Ik zie dat je DC's core installaties zijn, dus met 1GB per VM en 1 vCPU per VM zit je wel safe. Zelf heb ik 2012 met GUI draaien onder 2 GB maar dat is overkill. Ga nu zelf eens testen met 1GB :-)

Exchange, kan je testen tussen 6 en 8GB, zelf had ik eerst 12GB met 20 mailboxen inclusief public folders, Archiving en CAS/OWA op de zelfde machine. Dit kon met gemak terug naar 6GB.

Bovendien je hebt 2 x een DC, dus die kan je gewoon thin provisionen. Merk je niks nada noppes van.

Ja, de domain controllers zullen er qua specificaties flink op achteruit gaan en met thin provisioning besparen we dan nog eens een hoop aan storage. Veel efficiënter dan mijn huidige configuratie.

Als dat al draait op 6GB (Hoeveel vCPU trouwens?) dan moet ik dat makkelijk redden met alleen CAS, OWA, 5 mailboxen en MAX. 5 GB aan mail. Ook dit wordt dus experimenteren om te kijken wat we wel kunnen maken en wat we niet kunnen maken. Overigens moet ik wel bekennen dat het mij persoonlijk niet al te verstandig lijkt om onder 6GB te gaan met Exchange.

CMD-Snake schreef op maandag 07 oktober 2013 @ 23:00:
Je kan eventueel meer ruimte nog besparen als je Hyper-V gaat draaien. Bij een volledige versie kan je ook van de File Server rol deduplicatie instellen. Je ontdubbeld dan alles in je storage. In feite dus elke Windows installatie van een VM is dubbel, kost in het begin wel een hoop CPU kracht, maar uiteindelijk bespaar je flink ruimte daarna.

Eventueel kan je ook nog in Hyper-V één VHD maken als basis image en de servers draaien met differencing disks. Die baseer je dan op die ene image VHD. Voordeel is dat je dan meer een VHD hebt als referentie en alle unieke eigenschappen van de VM's sla je op in de differencing disks.

Ho, wacht even, deduplication, begrijp ik dit nu goed? Stel je draait Hyper-V server met daarop 5 Virtual Machines. Al deze machines hebben een Windows Server 2012 Standard installatie. 99% van de bestanden voor deze Virtual Machines zijn dus identiek. Deduplication “verwijderd” dus alle duplicaten met als gevolg dat er nog maar één Windows Server 2012 installatie aan ruimte nodig is voor 5 Virtual Machines?

En bij differencing disks zou je dus bijvoorbeeld één “image” maken met een server 2012 core installatie die gelijktijdig door mijn 2 Domain Controller Virtual Machines gebruikt kunnen worden? Dat zou dan toch de benodigde schijfruimte voor 2 domain controllers nagenoeg halveren? Het schijnt ook nog een verwaarloosbare impact op de performance te hebben.

Als dit alles klopt moet ik toch maar eens serieus Hyper-V server gaan overwegen.

CMD-Snake schreef op maandag 07 oktober 2013 @ 23:00:
Ja, in een bedrijfsomgeving is twee DC's of meer aanbevolen. Maar jij draait alles virtueel op een systeem. Als je hypervisor ermee stopt, dan is alles toch weg. Je zou in feite dan die tweede DC fysiek moeten maken.

De kans op software falen is heel klein tegenwoordig.

Jazzy schreef op dinsdag 08 oktober 2013 @ 07:44:
Twee domain controllers op dezelfde fysieke server heft geen/weinig meerwaarde. Het idee hiervan is dat je domain en DNS beschikbaar blijkt als er een fysieke server wegvalt. In jouw situatie zou ik kiezen voor een enkele DC, dat scheelt je resources en vermindert de complexiteit.

Jullie hebben gelijk hoor. Het is ook meer een dingetje voor mezelf dan dat het echt een meerwaarde heeft. Aangezien ik toch van plan ben te upgraden en met de goede tips die ik hier gekregen heb moet ene tweede DC geen enkel probleem meer vormen

CMD-Snake schreef op maandag 07 oktober 2013 @ 23:00:
Koop gewoon SATA disks. De wat mindere performance weegt echt wel op tegen de enorme besparing. Een grote SAS schijf kost een veelvoud van een SATA schijf.

Wat betreft SATA schijven:

Dennism schreef op maandag 07 oktober 2013 @ 23:16:
Hou je er wel rekening mee dat de P400 controller erom bekend staat deze vrij picky is qua schijven. Zomaar een advies geven voor WD black of blue's zou ik niet doen zonder te testen. Kleine guideline bij deze controller is dat alles met een HP firmware dat op de compatibility list staat werkt, alles wat niet op de lijst staat is een gok en kan wel of niet werken tot 2TB, daarboven is volgens mij sowieso niet compatible. Daarnaast heeft deze controller geloof ik schijven nodig met een TLER firmware als je geen array problemen wil.

In tegenstelling tot de PERC RAID controllers waar ik mee heb mogen werken is de P400 nogal een zeikerd (eigenlijk alle wat oudere Smart Array controllers naar mijn mening). Hoewel SATA schijven spotgoedkoop zijn in vergelijking met SAS schijven is het verschil tweedehands niet zo heel groot. Zo heb ik vandaag de eerste stap gezet richting een upgrade: 5x146GB 10K voor vijf tientjes (Met dank aan een medetweaker!) De goedkoopste 2.5" schijf in de pricewatch is een Samsung Spinpoint M7 zonder CCTL en dat is maar voor 160GB Dan ga ik toch liever voor, gelet op mijn persoonlijke ervaring, een tweedehands server schijf met manufacture dates tussen 2010 en 2012. Ik besef maar al te goed dat dit in geen enkele vorm garantie is voor een schijf die lang mee zal gaan, maar ik ben bereid, nogmaals vanwege mijn eigen ervaring, het risico te nemen.

CMD-Snake schreef op dinsdag 08 oktober 2013 @ 08:53:
WD Blue en Black zei ik enkel als voorbeeld. WD heeft ook SATA schijven met TLER functie. Andere merken verkopen ook disks uit series die langer moeten leven. Sowieso moet je wel wat betere SATA schijven nemen in verband met de levensduur. Reguliere schijfjes gaan vrij snel stuk als ze 24/7 draaien.

Ik moet dat toch tegenspreken. Ik heb mijn reguliere systemen vaak 24 uur per dag aanstaan en ik heb zelf nog nooit een defecte harde schijf gehad. Ik heb hier twee “dubieuze” Diamondmax 9’s liggen van 80GB met prima SMART waardes (oké, één van de schijven heeft al een jaar of twee één re-allocated sector). Manufacture date van deze schijf is JAN2004. Zelfs een IBM “Deathstar” heeft het zes jaar lang uitgehouden bij mij (uiteindelijk verkocht). Niet echt een schijf die bekend stond om zijn survival skills.

ppl schreef op maandag 07 oktober 2013 @ 21:33:
Dat is wel het idee. Virtualisatie betekent dat je resources efficiënter kunt maar ook moet gaan inzetten. Als je het verkeerd doet loop je tegen performance problemen aan. Wat mensen vaak ook nog wel eens vergeten: veel operating systems, waaronder ook Windows, kunnen prima met een paar maatjes minder. Het hoeft allemaal niet met een sloot aan cpu's en geheugen.

Als je wat meer wil weten: zoek eens wat gerichter op zaken als geheugenmanagement van ESXi. Er zijn diverse whitepapers van VMware zelf als ook sites die hierover hebben geschreven. vmug.nl is een aardige om te beginnen (Nederlandse VMware usergroup; zie hun blogroll rechtsonder voor meer handige sites).
Neus vooral ook zelf eens rond in de vSphere client. Het heeft aardig wat monitoring opties om de performance van de verschillende vm's in de gaten te houden als ook van de server zelf. Dat geeft je vaak al een goed idee of je teveel of te weinig resources hebt uitgedeeld aan een vm.

Het instellen is niet zo heel moeilijk en gelukkig is er overal en nergens ook prima documentatie over te vinden. Het is wel slim om je daar wat meer in te verdiepen wanneer je alles op die ESXi doos wil doen, dan weet je een beetje wat wel en niet kan.

Ik heb totdat ik er zelf mee ging experimenteren nooit echt een hoge pet op gehad van virtualisatie, maar dit is in de laatste paar weken volledig omgeslagen. Ik begrijp nu heel goed waarom bedrijven en instellingen massaal overstappen naar virtualisatie. Je schopt een hoop oude servers buiten en de servers die je nog hebt worden erg efficiënt gebruikt. Ook een stuk beter voor het milieu.

Ja, een beter begrip van het geheugenmanagement van ESXi (en ook Hyper-V) is in deze wel wenselijk. Vooral omdat ik heb laten zien dat ik de plank compleet heb misgeslagen met mijn originele plan. Die site heeft trouwens een aantal interessante forumtopics als ik het zo eens even snel bekijk!

De monitoring van vSphere is nog niet helemaal wat ik er van verwacht, maar ik ga er toch nog eens verder naar kijken. Het excessieve geheugengebruik van mijn 2 DC VMs werd in ieder geval vlekkeloos door ESXi bevestigd (ik had het dus zelf kunnen verzinnen als ik van tevoren beter had gekeken).

Dennism schreef op maandag 07 oktober 2013 @ 21:49:
Voor Gbit hoef je alleen je switch te vervangen Printers / AP's kunnen gewoon op 100mbit blijven draaien zonder problemen terwijl de rest op gbit staat.

Maak daar maar van "switches" en een paar routers (die fungeren als AP alsmede switch)

Op dit moment zou ik alleen mijn tweede PC kunnen voorzien van Gbit internet, de rest zit allemaal wel vast aan een Mbit switch vanwege dit hopeloze onvriendelijke huis!

ppl schreef op maandag 07 oktober 2013 @ 21:33:
Misschien toch maar een secretaresse erbij nemen

Ik wil niemand hier tekort doen, maar dit is tot nu toe wel het beste advies wat ik heb gekregen (j/k )


Wat betreft de hardware heb ik ondertussen niet stil gezeten. Ik heb al aangegeven dat ik de server ga upgraden en heb de eerste stap reeds gezet. Ik ga al mijn 72GB schijven in de verkoop zetten alsmede 8 FB-DIMMs van 2GB per stuk. Ik heb nu, uiteraard onder voorbehoud het volgende voor ogen:

BIOS: P56 (NX-bit, VT, Static High Performance mode)
CPU: 2x Intel Xeon E5420 2.50 GHz Quad-Core
RAM: 24GB PC2-5300F (Of zelfs 32GB, even afhankelijk van de kosten)
RAID: HP Smart Array P400 512MB BBWC
Storage: 8x 146GB 10K disks
NIC: 2x 1Gbit (draait echter maar op 100Mbit vanwege het netwerk) - Load Balanced via ESXi
Beoogde Hypervisor: HP VMWare ESXi v5.5 OF Microsoft Hyper-V Server 2012

Ik ga nu even op zoek naar een typmiep

[Jazzy]

wjjkoevoets schreef op woensdag 09 oktober 2013 @ 00:35:
Als dat al draait op 6GB (Hoeveel vCPU trouwens?) dan moet ik dat makkelijk redden met alleen CAS, OWA, 5 mailboxen en MAX. 5 GB aan mail. Ook dit wordt dus experimenteren om te kijken wat we wel kunnen maken en wat we niet kunnen maken. Overigens moet ik wel bekennen dat het mij persoonlijk niet al te verstandig lijkt om onder 6GB te gaan met Exchange.

Het is niet zozeer de vraag of het verstandig is, maar vooral wanneer de performance nog een beetje te doen is. Voor een labopstelling werkt het met 4 GB ook nog wel, prima voor als je wat wilt testen of uitproberen. Verder is de minimale eis die Microsoft stelt 8 GB.

Ho, wacht even, deduplication, begrijp ik dit nu goed? Stel je draait Hyper-V server met daarop 5 Virtual Machines. Al deze machines hebben een Windows Server 2012 Standard installatie. 99% van de bestanden voor deze Virtual Machines zijn dus identiek. Deduplication “verwijderd” dus alle duplicaten met als gevolg dat er nog maar één Windows Server 2012 installatie aan ruimte nodig is voor 5 Virtual Machines?

Ik heb niet de hele draad gelezen dus herhaal misschien iets, maar dedup voor VM's wordt momenteel alleen ondersteund voor VDI-omgevingen. Het werkt ook prima met andere workloads maar dat is nog niet uitvoerig getest voor Microsoft. Maar in ieder geval win je zowel schijfruimte als performance.

Als dit alles klopt moet ik toch maar eens serieus Hyper-V server gaan overwegen.

Er zijn nog meer voordelen. Zo is de HCL van VMware nogal specifiek, voor Hyper-V geldt dat zolang het Windows draait je het kunt gebruiken. Verder is de beheerinterface een stuk vertrouwder, ik heb het dan met name over de parent-partition. Denk bijvoorbeeld aan performance troubleshooten met extop of met Perfmon...

[Wim-Bart]

Ik draai met 4 cores op Hyper-v voor mijn exchange 2013 VM met een AMD FX-8120. Exchange installatie was trouwens wel een hell of a job. Onder hyper-v kreeg ik het alleen aan de praat met een fixed pagefile op C: (Disk C:) is dynamic (thin provisoned) en de D: disk waarop Exchange staat met datastores is Fixed, dus NIET Thin provisoned. Heb 4 exchange databases. 1 x de default met daarin alleen de default mailboxen, een user datavbase, een archive database en een public folder database. Ondr hyper-v wil de information store niet starten wanneer de databases op een thin provisioned disk staan, onder ESX werkt het wel.

Overigens, met dedup in Server 2012R2 heb je twee positieve eigenschappen:
1. Je kan je OS disks Deduppen van je VM's, om een voorbeeld tw geven, heb nu 360GB geprovisioned op een partitie mete dedup van 160GB, met 63GB vrije diskruimte. Alle VM's zijn Server 2012/2012R2.
2. De onderliggende fisken zijn 2xWD 250GB 7200rpn SATA3 in raid-1 op de AMD integrated controller. En eerst was het niet vooruit te branden met meer dan 2 VMs, maar met Dedup vaan 2012R2 heb ik alles er naartoe gezet, draaien nu 6 VM's op.

[Dronium]

wjjkoevoets schreef op woensdag 09 oktober 2013 @ 00:35:
Mag ik trouwens vragen hoe je die Sever 2012 Core installatie zo belachelijk klein hebt gekregen, Dronium (Win 2012 Core (DC/DNS) 44,2Gb provisioned - 12,96 Gb Used)?

Daar heb ik geen moeite voor gedaan. Installatie van Windows 2012 meteen in Core modus, netwerk settings instellen middels Sconfig, DCpromo middels answer-file. Het is een test machine met verder alleen DNS en DHCP. De tweede DC is zelfs nog ietsje kleiner, de vmdk zit rond de 10 Gb.
Let wel dat de server na de initiele setup nooit is geupdate, en bij die 12,96 Gb nog 2 Gb zit voor de .vswp

[ppl]

Jazzy schreef op dinsdag 08 oktober 2013 @ 07:44:
Twee domain controllers op dezelfde fysieke server heft geen/weinig meerwaarde. Het idee hiervan is dat je domain en DNS beschikbaar blijkt als er een fysieke server wegvalt. In jouw situatie zou ik kiezen voor een enkele DC, dat scheelt je resources en vermindert de complexiteit.

Voor een productie omgeving is het een beetje raar, dan kun je inderdaad beter de resources besparen en voor maar 1 DC gaan. Je kunt er natuurlijk ook een leeromgeving van maken. Dan gaat het er meer om dat je 2 DC's op zet en goed met elkaar laat werken. Als die virtualisatie bak uitvalt, ach... Virtualisatie is niet alleen handig voor productie, ook voor test- en leeromgevingen. We gebruiken het voor onze stagiairs zodat zij een mooi projectje in elkaar kunnen knutselen. Ons scheelt het geld omdat we maar 1 machine kwijt zijn. Ondanks dat kunnen ze toch een compleet bedrijfsnetwerk nabootsen. Zelf willen we er ook nog wel eens gebruik van maken trouwens

wjjkoevoets schreef op woensdag 09 oktober 2013 @ 00:35:
De monitoring van vSphere is nog niet helemaal wat ik er van verwacht, maar ik ga er toch nog eens verder naar kijken. Het excessieve geheugengebruik van mijn 2 DC VMs werd in ieder geval vlekkeloos door ESXi bevestigd (ik had het dus zelf kunnen verzinnen als ik van tevoren beter had gekeken).

Het is niet het meest grandioze wat er is maar het zit wel op een dusdanig niveau dat je een aardig idee kunt krijgen wat er gebeurd en waar je problemen zou moeten zoeken (voor het ontdekken van trends heb je ook niet een supergeweldige monitoring nodig, dat kan heel basic). Je hebt wel tools die ver gaan in dat monitoring maar dat wordt en complex en prijzig.

[Jazzy]

Wim-Bart schreef op woensdag 09 oktober 2013 @ 17:13:
Ik draai met 4 cores op Hyper-v voor mijn exchange 2013 VM met een AMD FX-8120. Exchange installatie was trouwens wel een hell of a job. Onder hyper-v kreeg ik het alleen aan de praat met een fixed pagefile op C: (Disk C:) is dynamic (thin provisoned) en de D: disk waarop Exchange staat met datastores is Fixed, dus NIET Thin provisoned. Heb 4 exchange databases. 1 x de default met daarin alleen de default mailboxen, een user datavbase, een archive database en een public folder database. Ondr hyper-v wil de information store niet starten wanneer de databases op een thin provisioned disk staan, onder ESX werkt het wel.

Zo lang het OS maar de volledige schijfruimte ziet is er voor Exchange niets aan de hand. Sterker nog, Exchange kan niet zien of je een dynamically expanding disk gebruikt of zelfs thin provisioning op de storage-laag doet. Zo lang je maar geen auto-growing disk gebruikt want dat is niet ondersteund, dus dat Exchange het ene moment 10 GB vrije schijfruimte ziet en even later opeens 50 GB. Een page-file is ook geen harde eis trouwens, zeker geen deployment blocker. Ik denk dus dat je tegen andere issues aan bent gelopen, niet per se gerelateerd aan Hyper-V of VMware.

[Wim-Bart]

Oc Exchange het ziet of niet, bij ving bij de setup niet verder bij mounten database. Na 3 pogingen de disk waarop Exchange installeerde vervangen door een "vaste" size disk en de installatie liep als een zonnetje.

Of exchange het ziet weet ik niet maar toch was er iets niet goed. Misschien werd ik genekt door de beperkte iops maar vastzetten van de disksize was de oplossing met Hyper-V.

[wjjkoevoets]

Jazzy schreef op woensdag 09 oktober 2013 @ 14:58:Het is niet zozeer de vraag of het verstandig is, maar vooral wanneer de performance nog een beetje te doen is. Voor een labopstelling werkt het met 4 GB ook nog wel, prima voor als je wat wilt testen of uitproberen. Verder is de minimale eis die Microsoft stelt 8 GB.

Het is geen labopstelling. Ik denk dat ik voor de Exchange server 6 of 8 GB ga hanteren afhankelijk van de performance die ik krijg. Maar als Exchange al mogelijk is op 6GB met een goed aantal mailboxen dan zie ik weinig problemen wanneer ik 24 of 32 GB RAM in mijn server heb zitten

Dronium schreef op woensdag 09 oktober 2013 @ 19:04:
Daar heb ik geen moeite voor gedaan. Installatie van Windows 2012 meteen in Core modus, netwerk settings instellen middels Sconfig, DCpromo middels answer-file. Het is een test machine met verder alleen DNS en DHCP. De tweede DC is zelfs nog ietsje kleiner, de vmdk zit rond de 10 Gb.
Let wel dat de server na de initiele setup nooit is geupdate, en bij die 12,96 Gb nog 2 Gb zit voor de .vswp

Duidelijk. Mijn volgende DC installaties zullen vanaf het begin netjes als Core geïnstalleerd worden (Thin provisioned uiteraard). Configuratie middels PowerShell moet geen problemen opleveren en het is voor mezelf ook nog eens een nuttige leerervaring.

ppl schreef op woensdag 09 oktober 2013 @ 23:36:
Voor een productie omgeving is het een beetje raar, dan kun je inderdaad beter de resources besparen en voor maar 1 DC gaan. Je kunt er natuurlijk ook een leeromgeving van maken. Dan gaat het er meer om dat je 2 DC's op zet en goed met elkaar laat werken. Als die virtualisatie bak uitvalt, ach... Virtualisatie is niet alleen handig voor productie, ook voor test- en leeromgevingen. We gebruiken het voor onze stagiairs zodat zij een mooi projectje in elkaar kunnen knutselen. Ons scheelt het geld omdat we maar 1 machine kwijt zijn. Ondanks dat kunnen ze toch een compleet bedrijfsnetwerk nabootsen. Zelf willen we er ook nog wel eens gebruik van maken trouwens

Ja, die twee DCs wil ik gewoon puur voor mezelf. Het werkt gewoon lekker, kan het niet goed beschrijven. Het is alsof “het zo moet zijn”. En net wat je aangeeft, virtualisatie biedt die mogelijkheden gewoon. Je kan een aardige omgeving knutselen als je bij wijze van spreken drie fysieke servers hebt. Ik ben wel onder de indruk van VMWare’s DRS, DPM en vMotion. Laat iemand daar mee aan de slag gaan en gooi 5 diverse VMs op iedere bak en je hebt volgens mij al een aardig interessant iets opgezet.

ppl schreef op woensdag 09 oktober 2013 @ 23:36:
Het is niet het meest grandioze wat er is maar het zit wel op een dusdanig niveau dat je een aardig idee kunt krijgen wat er gebeurd en waar je problemen zou moeten zoeken (voor het ontdekken van trends heb je ook niet een supergeweldige monitoring nodig, dat kan heel basic). Je hebt wel tools die ver gaan in dat monitoring maar dat wordt en complex en prijzig.

Ja, ik zal het alleen even wat netter in moeten stellen. Out of the box vind ik dat het te weinig nuttige informatie geeft. Dat heeft deels met een gebrek aan kennis te maken en gewoon een deel aan informatie die ik niet interessant vind (Leuk om te zien hoeveel stroom de server verbruikt, maar dat kan ik via ILO ook buiten mijn eigen netwerk zien). ThirdP monitoring software is voor mijn situatie overkill. Al zou ik best wel eens een keer willen experimenteren met Nagios

Wim-Bart schreef op woensdag 09 oktober 2013 @ 17:13:Overigens, met dedup in Server 2012R2 heb je twee positieve eigenschappen:
1. Je kan je OS disks Deduppen van je VM's, om een voorbeeld tw geven, heb nu 360GB geprovisioned op een partitie mete dedup van 160GB, met 63GB vrije diskruimte. Alle VM's zijn Server 2012/2012R2.
2. De onderliggende fisken zijn 2xWD 250GB 7200rpn SATA3 in raid-1 op de AMD integrated controller. En eerst was het niet vooruit te branden met meer dan 2 VMs, maar met Dedup vaan 2012R2 heb ik alles er naartoe gezet, draaien nu 6 VM's op.

Dit is me nog even allemaal te vaag. Ik word van Google ook niet echt veel wijzer, behalve dan dat Deduplication in bepaalde scenario's belachelijk veel schijfruimte kan opleveren zonder prestatieverlies en dat het feitelijk een soort hardlinken is. Ja, het hele idee erachter is logisch, als een set bitjes en bytes meerdere malen ergens op een schijf staan is het logisch dat het efficiënter is om de duplicaten te verwijderen. Ik begrijp echter ook dat het voor OS'en niet gebruikt kan worden en dat het op VMs ook niet real-time uitgevoerd kan worden (Ik wil hierbij benadrukken dat real-time deduplication van mijn VMs in mijn situatie geen vereiste is, gecontroleerde VM down time is geen gigantisch probleem). Even een aantal stellingen om te controleren of ik dit in de smiezen heb:

1. Op mijn Hyper-V server draai ik drie VMs. Hyper-V server is geïnstalleerd op de C: schijf. De VMs zijn alle drie Windows Server 2012 R2 domain controllers. Deze VMs staan op de D: schijf. Ik stop mijn VMs en draai een deduplication job op mijn D: schijf. Deduplication verdeeld alles in kleine "chunks" en bemerkt dat er belachelijk veel data hetzelfde is. Na vrolijk 3 uur te hebben gedraaid blijkt dat de benodigde schijfruimte van 45GB terug gebracht is naar ca. 16GB. Drie maal alle Windows bestanden is immers ruimteverspilling

2. In stelling 1 haal ik aan dat VMs gestopt moeten zijn tijdens het deduplication proces, omdat deduplication niet uitgevoerd kan worden op actieve VMs

3. Na een poos installeer ik een groot softwarepakket (ca. 8GB) op twee van de drie VMs. Nadat ik dit gedaan stop ik de VMs en draai wederom het deduplication proces. Immers is het deduplication proces niet real-time vanwege het gebruik van VMs

4. Ik heb een volledige licentie nodig voor Deduplication in mijn geschetste situatie. Immers draai ik op de server niet alleen de Hyper-V rol, maar ook de Files en Storage rol

Dit is het beeld wat ik nu heb van Hyper-V Server i.c.m. deduplication, maar ik weet niet of dit nu heel accuraat is.


Verder ben ik nog altijd bezig met het opvolgen van de raad die ppl mij heeft gegeven om mij wat meer te verdiepen in de werking van VMWare's Hypervisor (en ik denk dat ik na jullie reacties ook eens een blik moet gaan werpen op Hyper-V). In de tussentijd dat ik niet heb gepost in dit draadje heb ik van de gelegenheid gebruik gemaakt om mijn VCA-DCV certificaat te halen om zo een beter beeld te krijgen van VMWare's hypervisor. Ik moet zeggen dat het wel ontzettend, echt ontzettend jammer is dat VMWare certificeringen echt belachelijk duur zijn! Erg interessante stof. Maar goed, daar hebben we het VMWare certificeringen draadje voor.

Verder ben ik nog altijd bezig om geschikte hardware te vinden voor mijn server. De focus ligt allereerst op het vergroten van de storage capaciteit. Dit is, zoals ik al aangaf in mijn laatste post, goed op weg met 5x146GB schijven. Ik ben bezig om nog eens drie schijven te regelen van dergelijke capaciteit. Ik heb meteen het geheugen en de 72GB aangeboden ter verkoop aangezien ik deze hardware toch niet meer zal kunnen gebruiken.

Heeft iemand hier trouwens ervaring met VMWare's data deduplication? Ik heb zo'n vermoeden dat dit bij Microsoft wat handiger en makkelijker in te regelen is.

Overigens wil ik iedereen wederom bedanken voor de uitgebreide en inzichtvolle reacties die ik heb gekregen op mijn vragen