Hyper-V: VHD's op verschillende volumes

[dotacom]

Beste Tweakers,

Wij gaan binnenkort een nieuwe Hyper-V server aankopen waar een vijftal VM's op zullen draaien.
Een van die VM's vereist veel performantie gezien dit de SQL server wordt waarop productie database zal draaien.
De overige 4 VM's vragen geen hoge performantie.

Het idee is om 3 arrays te confgigureren:
1. 300 GB (RAID1, 2*300 GB) => Operating System
2. 1 TB (RAID10, 4*500 GB) => SSD volume (snel)
3. 1 TB (RAID10, 4*500 GB) => HDD volume (trager)

Nu twijfel ik nog om de volledige SQL-VM op de snelle storage te plaatsen of alleen de VHD's die performantie vragen.
Zo zal op deze SQL VM ook een volume (vb: F:\) komen waar de back-ups van alle databases komen te staan + wat statische data.
Dit volume vraagt uiteraard geen performante storage.
Is het een "goed" idee om de verschillende VHD's op verschillende volumes te zetten?

Via Google vind ik niet echt voorbeelden waar dit wordt uitgevoerd maar zie niet echt in waardoor dit niet een goeie oplossing kan zijn.

[FireDrunk]

Waarom zou het *geen* goed idee zijn? Elke partitie/schijfletter een eigen VHD lijkt mij zeker een best practice, en een VHD op een andere schijf/volume plaatsen op de host kost ook geen enkele moeite.

Dus nogmaals, waarom niet?

[redfoxert]

Zo hebben wij ook verschillende soorten storage aan onze VM's hangen. Van snel SSD storage tot traag NL-SAS (SATA). VM's krijgen wat ze nodig hebben, elke disk een eigen VHD of VMDK op het geschikte storage.

[dotacom]

In verleden heb ik steeds dezelfde VM op hetzelfde volume gezet.
Voordeel hiervan is dat alles overzichtelijk bleef.
Bedankt voor de bevestiging dat het anders ook kan.

[redfoxert]

dotacom schreef op maandag 11 april 2016 @ 13:51:
In verleden heb ik steeds dezelfde VM op hetzelfde volume gezet.
Voordeel hiervan is dat alles overzichtelijk bleef.
Bedankt voor de bevestiging dat het anders ook kan.

Stel dat je een VM hebt van in totaal 500GB. Daarvan is 100GB je database en heeft dus snel storage nodig. Dan zet je die VM toch niet in zijn geheel op snel storage als dat niet noodzakelijk is? Dan gooi je 400GB snel storage (dus hogere kosten) "weg" ten koste van andere VM's die wellicht hier ook gebruik van zouden kunnen of moeten maken. Anderszijds heb je weer sneller investeringen nodig in snel storage om aan de vraag te kunnen voldoen.

Daarom, plaats je data daar waar het hoort, als je verschillende soorten storage hebt.

[Question Mark]

dotacom schreef op maandag 11 april 2016 @ 13:26:
Een van die VM's vereist veel performantie gezien dit de SQL server wordt waarop productie database zal draaien.
De overige 4 VM's vragen geen hoge performantie.

Het idee is om 3 arrays te confgigureren:
1. 300 GB (RAID1, 2*300 GB) => Operating System
2. 1 TB (RAID10, 4*500 GB) => SSD volume (snel)
3. 1 TB (RAID10, 4*500 GB) => HDD volume (trager)

Hoeveel IOPS ben je nodig voor de SQL server en hoe groot zijn je DB's?

Voor hetzelfde geld kun je wellicht 15x een 500 GB disk aanschaffen en wat extra memory voor de host. Als je dan de disken in één grote array plaatst, heb je een snellere disk performance voor alle VM's.

En aangezien je SQL wat meer memory voor caching kunt geven, win je daar ook weer performance.

[Brahiewahiewa]

Question Mark schreef op maandag 11 april 2016 @ 14:44:
[...]Voor hetzelfde geld kun je wellicht 15x een 500 GB disk aanschaffen en wat extra memory voor de host. Als je dan de disken in één grote array plaatst, heb je een snellere disk performance voor alle VM's...

Op papier wel, of - zo je wilt - in de benchmarks wel. In de praktijk moet je de IOPS met 4 machines delen en blijft er dus maar een kwart van over

[Question Mark]

Vandaar de vraag ook over hoeveel IOPS we het hebben. Zonder die info kan er niks zinnigs geroepen worden.

Brahiewahiewa schreef op maandag 11 april 2016 @ 14:50:
[...]

Op papier wel, of - zo je wilt - in de benchmarks wel. In de praktijk moet je de IOPS met 4 machines delen en blijft er dus maar een kwart van over

Dat regel je in met storage QOS op Hyer-V. Daarmee is per Virtual Disk te regelen hoeveel IOPS deze mag gebruiken.