Hyper-V over SMB (Del 1)

Hyper-V kom som en etterlengtet serverrolle for første gang i Windows Server 2008.

Det var mulig – allerede den gang å kjøre Hyper-V sammen med Windows Failover Cluster for å få en løsning som var høy-tilgjengelig. Dette forutsatte at man kun hadde en virtuell maskin per LUN, siden det var LUN-et som feilet over mellom nodene i clusteret. Om man hadde flere virtuelle maskiner på ett og samme LUN, så ville dette medføre nedetid for de andre maskinene.

Windows Server 2008 R2 introduserte Clustered Shared Volumes som gjorde det mulig å ha så mange VM-er på ett og samme LUN som det teknisk sett var mulig, der alle nodene i clusteret hadde fulle lese – og skriverettigheter til VM-ene. Nå kunne man endelig kjøre ‘Live Migration’ mellom nodene i clusteret, men det var begrenset til en migrering om gangen. Dvs, en node i clusteret kunne ikke delta i flere migreringen om gangen.

Begge løsningene over forutsatte at man hadde en form for shared storage, og med shared storage så mener jeg SAN (Storage Area Network).

SAN-teknologi er vanligvis forbeholdt større organisasjoner (iallefall i kroner og ører) siden det er en stor kostnad forbundet med dette. Nodene i clusteret hadde vanligvis tilgang til SAN-et via Fibre Channel eller iSCSI (1Gbe eller 10Gbe). Så block storage var essensielt i et Hyper-V Cluster.

Eksempel på typiske Hyper-V Clusters med iSCSI - SAN

De vanligste fallgruvene ved design av Hyper-V Clusters var relatert til nettverk og storage:

Man burde følge best practice og ha dedikerte nettverkskort i nodene til forskjellige formål.

1 NIC til Management – I mange tilfeller er Hyper-V hostene på et eget nettverk i datasenteret.

1 NIC til hvert eksterne virtuelle nettverk – Når man oppretter et external virtuelt nettverk så binder man et fysisk nettverkskort i hosten til dette nettverket. Dette er eneste typen nettverk som tillater de virtuelle maskinene som er tilkoblet, å kommunisere ut mot LAN/Internet. (I Windows Server 2012 heter det nå Virtual External Switch).

1 NIC til Live Migration – Ved Live Migration mellom nodene i et cluster så blir Memory overført via ethernet og kan derfor være en stor belastning for nettverket avhengig av hvor mye RAM den virtuelle maskinen bruker.

1 NIC til iSCSI – Om man kobler Hyper-V hostene mot SAN-et via iSCSI så bør dette være på et dedikert nettverk. Virtuelle maskiner er filer på disk og man vil derfor ikke ha en potensiell flaskehals ved å kombinere dette med et annet nettverk.

1 NIC til Cluster – Når man tar backup av en virtuell maskin på et CSV, så vil noden som er eier av volumet være den som kontrollerer tilgang. Dvs, alle andre noder i clusteret vil lese/skrive til sine virtuelle maskiner via denne noden. Dette kalles for ‘redirected mode’. I tillegg blir dette nettverket brukt av nodene til å detektere heartbeat og helsetilstand i clusteret.

Om man foretrekker blade-servere så kan en slik konfigurasjon være utfordrende.

I tillegg så ønsker man å eliminere alle single-point of failures når man designer et cluster, så man benyttet gjerne nettverks-teaming på samtlige nettverk der det lot seg gjøre og konfigurerte iSCSI trafikken til å benytte Microsoft’s egen MPIO.

I Windows Server 2012 kan man designe tilsvarende nettverk for Hyper-V Clusters ved å bruke langt færre nettverkskort i serverene. Dette kan realiseres ved å bruke LBFO og QoS (Converged Fabric) – men det er en annen bloggpost.

Hyper-V i Windows Server 2012 krever ikke lenger Failover Cluster og SAN for å kjøre Live Migration.

Faktisk, så trenger du ikke noen form for shared storage i det hele tatt.

Det som gjør dette mulig i utgangspunktet er Live Storage Migration, som lar deg migrere vhd-filer, snapshots, konfigurasjon – ja alle assosierte filer til VM-ene til en ny lokasjon uten nedetid.

Dette gjør det også mulig å kjøre Shared-Nothing Live Migration mellom Hyper-V servere, forutsatt at de er i samme domene. Da vil det i utgangspunktet bli kjørt en Live Storage Migration først hvor alle filer blir kopiert til ny lokasjon, før en «vanlig» Live Migration starter ved å overføre memory pages.

Avhengig av hvordan man vil utføre og administrere dette, så må man i noen tilfeller konfigurere Constrained Delegation i Active Directory på samtlige Hyper-V servere som skal delta i denne leken.

(Dette blir en egen bloggpost på et senere tidspunkt).

En siste nyhet relatert til Live Migration i Hyper-V i Windows Server 2012, inkluderer SMB3.0 (Server Message Block) protokollen.

Man kan kjære virtuelle maskiner fra et vanlig file share (\\filserver\navnpådeltmappe) i Windows Server 2012.

Dette forutsetter selvsagt at SMB3.0 blir brukt både på klient – og serversiden i denne konfigurasjonen.

Dette er en veldig interessant nyhet og kan bidra til enorme kostnadsbesparelser for alle og enhver. Ved å lage Hyper-V clusters som bruke file share fremfor SAN som shared storage, så vil man fortsatt få høy-tilgjengelighet – men til en betydelig mindre pris.

Vi skal se på «hva, hvorfor og hvordan» i neste bloggpost i denne serien .