Hyper-V doporučení

Radek Doležel -

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)