Dostal jsem se k materiálu vhodnému při návrhu Hyper-V řešení. Obsahuje spoustu pravidel a doporučení, kterých by se měl člověk při designu řídit, akorát nemá šanci si je pamatovat. Proto alespoň heslovitě.
CPU
- preferovat velikost L2 a L3 cache pamětí před vyšší frekvencí procesoru
RAM
- odvozovat velikost RAM jak podle nároků virtuálů, tak také podle pravidla, které říká, aby každé jádro mělo min. 2GB RAM, doporučeno je pak mít 4GB RAM na jádro
- počítat s min. 1GB rezervou pro OS v “parent” instanci (pokud to není Core edice, ale GUI, tak přidat ještě víc)
chassis a MB
- preferovat provedení s dostatečným množstvím externích PCIe – budou potřeba pro síťové karty
NIC / HBA
- používat 64-bitové ovladače, které podporují DMA větší než 4GB (kde si tohle ověřovat netuším)
- používat single port adaptéry (v praxi dost dobře nemožné kvůli omezení počtu PCIe)
- offload síťovky a iSCSI HBA používat s rozmyslem – konzultovat předem dopady s prodejcem (offload síťovky mohou brzy znamenat úzké hrdlo, které nelze snadno odstranit)
- pro ne-clusterový stroj navrhovat 6-7 fyzických síťovek
- pro clusterový stroj navrhovat 8-9 fyzických síťovek
1x dedikovaný management fyzického stroje
2x iSCSI síťovka (žádný teaming!) využívaná výhradně “Parent” instancí Hyper-V
2x iSCSI síťovka (žádný teaming!) dedikovaná pro iSCSI konektivitu přímo z virtuálních mašin
2x+ síťovka (možný a doporučený teaming, VLAN atd.) pro aplikační využití serveru (tj. klasický back-end, front-end)
1x dedikovaná síťovka pro Cluster Heartbeat
1x dedikovaná síťovka pro Cluster Live Migration (a to již jsem viděl i návrhy, kde se doporučuje nemít 1Gbps, ale raději 10Gbps) - k výše uvedenému lze přidat ještě další síťovku dedikovanou pro zálohování
- dodatečné přidání síťové karty do Core edice je docela problém
- nesnažit se rozchodit Hyper-V na Marvell síťovkách, používat výhradně Broadcom/Intel
LUN / pole
- oddělit LUNy pro OS, LUNy pro uložení VHD s OS virtuálů, LUNy pro data aplikací virtuálů
- používat vhodný typ RAID
- instalovat MPIO software výrobce HW
- zvolit správný typ disku reprezentovaného virtuálu – může to být VHD, pass-through disk nebo přímo připojený disk, nejčastěji prostřednictvím iSCSI. VHD má limit 2TB, ale výhodu v podpoře Hyper-V VSS Writeru. Pass-through může být větší než 2TB, ale musí se řešit extra podpora VSS, složité nastavení např. v Hyper-V clusteru atd. Přímé připojení iSCSI může být větší než 2TB, ale musí se řešit VSS, třeba pomocí EqualLogic ASM/ME nainstalovaného do virtuálu.
- VHD – vždy volit fixed size disky
- použivat syntetický iSCSI řadič
- pokud je aplikačních dat méně, umístit je přímo do VHD disku
- na LUNech Hyper-V, které bude řízeno VMM, počítat nejen s velikostí vlastního VHD, ale započítat ještě velikost paměti virtuálu a maximální velikost ISO obrazu, který může být k virtuálu namapován ve virtuálním DVD
Hyper-V
- uvnitř virtuálů nainstalovat vždy nejnovější Integration Services (což zpravidla není verze, kterou vám tam nainstaluje VMM)
- volit takové zálohování, které využívá VSS (typicky Microsoft DPM Server), kombinovat s řešením výrobce HW, např. EqualLogic Auto-Snapshot Manager / Microsoft Edition
- pokud to HW umožní, preferovat HW snapshoty proti SW snapshotům – důvod = rychlost zálohy/obnovy. Nutností je samozřejmě dostatečná disková kapacita na poli.
- nezapomenout, že u Hyper-V, které je nutné přenést na jiný HW, je nejprve potřeba provést export virtuální mašiny
- u kritických aplikací replikovat snapshoty do backup lokace (pro účely Disaster recovery)
- u nejkritičtějších aplikací počítat s geo clusterem
A další doporučení
- Hyper-V a AD, KB888794, Running DC in Hyper-V
- na virtuálním AD částečně zakázat synchronizaci času s hostitelem
- nikdy neexportovat virtuál, který je doménovým řadičem
- v Hyper-V serveru, na němž běží virtuální AD, nepoužívat ATA/IDE disky, ale SCSI
- ve virtuálním AD nepoužívat virtuální IDE disk, místo toho použít virtuální SCSI disk
- nepoužívat snapshot na AD, tj. při vypínání Hyper-V se musí virtuální AD korektně kompletně vypnout (Shut down guest OS), tj. nikoliv Save state
- ve virtuálním AD nepoužívat diferenciální disky
- případný restore virtuálního AD provádět výhradně podporovanými zálohovacími nástroji (tj. např. neobnovit bezhlavě snapshot z pole), podporovanou cestou je spustit Windows Server Backup ve virtuálním OS (pak existuje samozřejmě možnost DPM klienta nainstalovaného ve virtuálním OS)
- nepoužívat VHD soubor, jenž pochází z již nainstalovaného doménového řadiče, k vytvoření nového doménového řadiče – vyhneme se tím problému při rollbacku update sequence number (USN)
- spuštění sysprep na doménovém řadiči není podporováno (nikde, tj. ani na fyzickém stroji)