Teknisk om Hyper-V Failover Cluster og Nettverk
Hyper-V Failover Cluster
Et cluster består av to eller flere servere (noder) som samarbeider om å kjøre en tjeneste. Hvis en server i clusteret ikke fungerer, overtar den andre serveren kjøringen av de clustrede tjenestene, og vise versa. Herav navnet Failover Cluster, fordi tjenesten som kjører på den ene noden “fails over” til den andre noden. Når det så gjelder et Hyper-V Failover Cluster kan man si at clusteret “bosser” på arbeidsoppgavene som består i å kjøre en eller flere Hyper-V virtuelle maskiner. Hvis node 1 ikke virker, vil de virtuelle maskiner bli kjørt på node 2. Herav har vi navnet Hyper-V Failover Cluster.
Det er viktig å holde fast ved at det kun er en node som kjører en spesifikk virtuell maskin av gangen, og at denne noden eier alle resursene knyttet til den spesifikke virtuelle maskinen. Den samme noden kan også kjøre andre virtuelle maskiner, og den andre noden kan kjøre sine. Nodene i clusteret kan overta virtuelle maskiner fra hverandre.
Felles lagring
En virtuell maskin består forenklet sett av innstillinger og en eller flere virtuell harddisker. Innstillingene og de(n) virtuelle harddisken må ligge på et delt lager, og alle nodene i et Hyper-V Failover Cluster må ha tilgang til lageret. Lokale disker på nodene med delte kataloger, kan ikke benyttes. Man må bruke en teknologi som kan benevnes Storage Area Network forkortet til SAN. Nodene må være tilkoblet SAN-et via iSCSI (vanlige nettverkskabler) eller Fiber. SAN-et kan være hardware basert eller software basert. Hvis software basert, så kjører gjerne denne programvaren (iSCSI Target) på en Windows server. For eks. Microsoft iSCSI Target som ble brukt på en W2K8 R2 x64 server for å lage denne artikkelen.
Figur 1 – iSCSI har blidt en populær løsning fordi løsningen bruker vanlige nettverkskort koblet sammen i en eller flere svitsjer. På tjeneren kjører iSCSI Target, mens iSCSI Initiator kjører på klientene. Feiltoleranse og Multipath (flere veier til Rom) oppnås ved flere nettverkskort, svitsjer og subnet.
På SAN-et opprettes det containers eller logiske enheter (betegnelsen varierer med teknologien) som her benevnes LUNs, og de gjøres tilgjengelige for alle noder i clusteret. Opprettede kontainere ligger på den underliggende hardware, dvs harddisker som kan være konfigurert i et eller flere RAIDs. For å få tilstrekkelig båndbredde for mange virtuelle maskinen, anses SAS disker som det beste alternativet, fremfor andre typer av disker. Dette skrevet, så kan ytelsen til SAS disker kompenseres med flere disker av andre type for eks SATA.
Beste Praksis
Når iSCSI benyttes, er det beste praksis å legge denne formen for kommunikasjon i et eget “privat nettverk” (dvs. eget subnet), og minst benytte CHAP autentisering for pålogging på SAN-et. Merk at IPsec er ikke støttet for Microsoft iSCSI Initiator.
VM og disk er en enhet når CSV ikke benyttes
I operativsystemet på nodene, fremstår LUNs som harddisker, for eks. i Disk Manager. Disker som skal benyttes av clusteret skal være av typen Basic Disker med MBR eller GPT, og de må formateres med NTSF. Når diskene er satt opp på begge noder, må de legges til som “storage” i Failover Cluster Manager. På denne harddisken kan så virtuelle maskiners innstillinger og virtuelle harddisker legges. Den noden som kjører den virtuelle maskinen eier da den delte harddisken på SAN-et som den virtuelle maskinen ligger på. Andre noder har da ikke tilgang til denne harddisken som vil ha status offline i Disk Manger, på den ikke eiende noden.
Figur 2 – En virtuell maskin (VM) er uløselig knyttet sammen med harddisken den ligger på (dependency). Når en VM flyttes fra en node til en annen, skifter også eierskapet av harddisken som den virtuelle maskinen ligger på.
Når en virtuell maskin (VM) migreres eller flyttes fra en node til en annen, vil eierskapet for alle harddisker som VM-en har innstillinger eller virtuelle harddisker på, flyttes til den nye eieren av den virtuelle maskinen. Det gjelder også for det tilfelle at virtuelle harddisker ligger på forskjellige LUNs, i det plasseringen kan være gjort på forskjellige RAID volumer på den underliggende hardware begrunnet med optimalisering.
Hvis det nå er slik at det ligger flere virtuelle maskiner på den samme SAN LUN harddisken, så må alle disse virtuelle maskiner også bytte node hvis en VM flyttes fra en node til en annen. Her gjelder en for alle og alle for en. Det er med andre ord kun en node av gangen som eier LUNet på SAN-et og de virtuelle maskinene som ligger på dette LUNet. Alle virtuelle maskiner plassert på et og samme LUN må kjøre på den samme eiende noden. Dette benevnes gjerne “shared-nothing” clustering modellen.
Den begrensningen som disk eierskapet legger, fører gjerne til at det opprettes en harddisk for hver enkelt virtuell maskin på SAN-et. Vi forstår intuitivt at dette kan være et problem dersom man har flere virtuelle maskiner enn bokstaver i alfabetet. For å komme rundt denne problemstillingen må man benytte Cluster Shared Volumes (CSV) som ble introdusert med Windows Server 2008 R2.
Tips
Det kan være viktig å være oppmerksom på at man ikke trenger å benytte CSV disker for å utføre Quick og/eller Live migration. Bare så det er nevnt! To av årsakene til at man ikke ønsker å benytte CSV, kan være knyttet til backup og de ekstra kravene som CSV stiller til nettverket mellom nodene i clusteret. Quick migration kom med Windows Server 2008 RTM, mens Live migration og CSV kom med Windows Server 2008 R2.
Migreringsformer av virtuelle maskiner
Figur 3 – Nå Quick Migration benyttes vil den virtuelle maskinen lagres i Saved State. Deretter flyttes den til den andre noden, hvor den gjenopprettes. Ved Live Migration synkroniseres memory fra den ene noden til den andre, og deretter overføres kjøringen av den virtuelle maskinen til den nye noden. Den virtuelle maskinen forblir online hele tiden under denne prosessen i motsetning til Quick Migration som går offline i saved state under migraringen.
Når en node ikke kan kjøre en eller flere virtuelle maskiner, må de overføres til den andre noden. Overføringen kan skje på tre vis. Den første måten er å stoppe den virtuelle maskinen for så starte den på den andre noden. Den andre måten er å lagre den virtuelle maskinen i “saved starte” for å gjenopprette den på den andre noden (Quick Migration). Den tredje måten er å overføre den virtuelle maskinen ved å synkronisere memory fra den ene noden til den andre som overtar (Live Migration). Quick og Live Migration krever like prosessorer, alternativt prosessorer med samme design og VM i kapabilitetsmodus.
Man kan i grunnen si at det er et fjerde alternativ også, i det en av nodene krasjer eller låser seg av annen årsak. I så fall vil de virtuelle maskinene som “krasjet” bli forsøkt restartet på den fungerende noden, så sant autostart (som er default verdien) for virtuelle maskiner i Failover Cluster manager, ikke er overstyrt, og at Autostart i Start Action i Hyper-V er stilt til Nothing.
Beste praksis
Det anses å være beste praksis å stille Automatic Start Action til Nothing i den virtuelle maskinenes egenskaper i Hyper-V for at start innstillinger konfigurert i Failover Cluster manager skal styre starten av den virtuelle maskinen.
Cluster Shared Volumes
Figur 4 – I denne figuren er laget for å illustrere hvordan harddisken som den virtuelle maskinen følger med eiende node, og hvordan dette endrer seg når CSV disk benyttes.
Cluster Shard Volumes (CSV) er en feature i Hyper-V Failover Cluster. En harddisk på SAN-et kan gjøres tilgjengelig for lese og skrive operasjoner for alle noder ved at man benytter Failover Cluster management panelet, aktiverer Cluster Shared Volumes, og legger til disken som CSV. Når virtuelle maskiner ligger på CSV kan de fritt overføres mellom noder i clusteret, uavhengig av eierskapet til CSV disken. Men husk at CSV er ikke en betingelse for å bruke Quick og Live Migration, og at det stilles flere krav til “cluster nettverket” for CSV redirection kommunikasjon. Dette blir nærmere beskrevet om litt.
Tips
For å kunne legge til et CSV volum, må man først legge til volumet som cluster storage i Failover Cluster manager.
Cluster modeller
Hyper-V Failover Clusteret kan dele arbeidet med å kjøre virtuelle maskiner på tre vis, Aktive-passive cluster, Active-active cluster og Mix-and-match cluster.
· Active-passive cluster – I denne modellen kjører alle virtuelle maskiner på en og samme node. Den noden kjører ingen virtuelle maskiner. Hvis noe skjer med node 1 overtar node 2. I dette tilfellet trenger man ikke dobbelt opp med memory.
· Active-active cluster – I denne modellen kjørers det virtuelle maskiner på begge nodene. Noen på node 1 og noen på node 2. Dersom noe skjer med en node, overføres de virtuelle maskiner til den andre noden. Overtagende node må derfor ha dobbelt opp med resurser (prosessor, memory og båndbredde) til å kjøre alle virtuelle maskiner samtidig. Begge noder må derfor ha ledig prosessorkraft, memory og båndbredde for å takle begge nodenes samlede oppgaver.
· Mix-and-match cluster – Denne modellen består av flere noder enn to, som kombinerer de to foregående cluster typene. Noen noder er konfigurert til Active-passive og noen til Active-Active. De enkelte noder må her ha ressurser i forhold til sine tildelte og fail-over oppgaver.
Hardware betingelser
Understående tabell oppsummerer hardware forutsetninger og betingelser. En mer utførlig beskrivelse finnes her.
Tabell 1 – Hardware forutsetninger for et to noders Hyper-V Failover Cluster
|
Forutsetninger
|
Beskrivelse
|
|
Servere
|
For et to noders Hyper-V Failover Cluster trenger man i utgangspunktet to like servere med like komponenter. Hardware komponentene må være Windows Server 2008 sertifiserte. Dersom servere ikke er like (NICs osv.), må de i alle falle la seg konfigurere likt!
|
|
Prosessor
|
Hyper-V krever x64 prosessor, hardware assistert virtualisering og hardware Data Execution Prevensjon (DEP). Det er mulig å benytte ulike prosessorer fra samme leverandør. Microsoft skriver om dette slik:
“Processor compatibility: If you are using different processor versions on the nodes in the cluster, live migration may fail. To perform a live migration of a virtual machine to another physical computer with a different processor, you must first select the Migrate to a physical computer with a different processor version setting in Hyper-V Manager. This setting ensures that the virtual machine uses only the features of the processor that are available on all versions of a virtualization-capable processor by the same processor manufacturer. It does not provide compatibility between different processor manufacturers. This allows you to move a running virtual machine to a physical computer with different processor features without restarting the virtual machine. The setting is also useful for high availability and backup and recovery scenarios because it makes it easier to move a highly available virtual machine to another node in a cluster or restore the virtual machine to different hardware.”
Se også avsnitt om prosessor kapabilitetsmodus.
|
|
Nettverkskort
|
Man trenger minst 2 nettverkskort, anbefalt er 4 eller fler i hver host, med tillegg av eventuelle nettverkskort i forbindelse med lagring.
|
|
Lagring
|
Windows 2008 støtter iSCSI, Serial Attached SCSI eller Fiber Storage Area Network. SAN-et kan være softwarebasert eller hardwarebasert med båndbredde på 1 Gbps eller bedre.
|
|
Delte lagringskontainere
|
Delte lagringskontainere (shared storage containers) må være kompatible med Windows Server 2008 og lagringen må minst inneholde to LUNs (volumer):
· Det første volumet er en “witness disk” som inneholder delt cluster informasjon, og benevnes Quorum disk. Disken må minst være 512 MB stor.
· Det andre volumet og eventuelt påfølgende volumer (disker) må være store nok til å inneholde den virtuelle maskinen med tillegg av VSS snapshot (10 til 20 % fri disk). Clustrede volumer kan være MBR eller GPT volumer. Alle disker må være NTSF formatert.
|
Software betingelser
Understående tabell oppsummerer software forutsetninger og betingelser. En mer utførlig beskrivelse finnes her.
Tabell 2 – Software forutsetninger for et to noders Hyper-V Failover Cluster
|
Forutsetninger
|
Beskrivelse
|
|
Operativsystem
|
Windows Server 2008 Enterprise R2 eller Windows Server 2008 Datacenter R2. Merk at samme versjon av operativsystemet må kjøres på alle noder. I denne artikkelen ble W2K8 R2 med GUI benyttet. Det er mulig å bruke Windows Server 2008 RTM (Enterprise eller Datacenter) uten Live Migration.
Hyper-V Server 2008 R2, som kan lastes ned “gratis” og som støtter Live Migration, kan brukes. Den er imidlertid Server Core og trenger in management server eller arbeidsstasjon for administrasjon. For administrasjon av Server Core, sjekk denne artikkelserien.
- Alle noder i clusteret må benytte samme versjon av Windows Server 2008, og samme type installasjon dvs. server core eller GUI.
- Alle noder bør ha de like programvare oppdateringer (patcher og service pakker).
|
|
Lisensiering
|
W2K8 Enterprise eller høyere må benyttes, husk at Hyper-V Server 2008 R2 er fundert på Enterprise. W2K8 Enterprise tillater 1 + 4 installasjon, mens W2K8 Datacenter tillater 1 + ∞. En lisens for operativsystemet må foreligge på begge servere i et 2 noders cluster. Totalt kan man da kjøre 8 virtuelle servere med Enterprise og uendelig med servere for Datacenter. Microsoft skriver om lisensiering her.
Alternativt må man ha individuell lisens for den virtuelle maskinen, dvs. en vanlig lisens som ikke er OEM. Lisensen kan da ikke benyttes på hardware i tillegg.
|
Nettverkstjenester
Understående tabell oppsummerer nødvendige nettverkstjenester.
Tabell 3 – Oversikt over nødvendige nettverkstjenester for å kjøre et 2 noders cluster
|
Forutsetninger
|
Beskrivelse
|
|
DNS
|
Serverne i clusteret må benytte DNS for navneresolusjon.
|
|
Domain role
|
Alle nodene i clusteret må være i samme Active Directory domene.
|
|
Domain Controller
|
Det anbefales at nodene i clusteret er member servere i et domene med en eller flere Domain Controllere. Det er beste praksis at alle servere i clusteret har samme Domain Rolle. Hostene kan konfigureres som Domain Controllere.
|
|
Klienter
|
Klienter er nødvendig for testing.
|
|
Konto for administrasjon
|
Når clusteret opprettes må man være pålogget som domene administrator, det gjelder forså vit også administrasjon av Hyper-V Failover Clusteret. For flere detaljer sjekk her.
|
Hva nå om du ønsker å virtualisere alt?
Hvis du skal virtualisere Domain Controllere så er første bud å sette seg grundig inn i problemstillingen. Dette ligger noe utenfor denne artikkelen så her er noen linker for at du skal kunne sette deg inn i saken. Active Directory i Hyper-V environments Part 1, Part 2, Part 3, Part 4, Part 5 og Part 6, og glem ikke KB888794. Du finner også stoff om dette her, her og her!
Prosessor kompatibilitetsmodus
Prosessor kompatibilitetsmodus gjør det mulig å bruke hardware som ikke er helt standardisert. Processor Compatibility Mode virker på den måten at Hyper-V slår av prosessor egenskaper (features) som kan være forskjellige mellom prosessorer av samme arkitektur inne i den virtuelle maskinen. Processor Compatibility Mode slås på for en og en virtuell maskin av gangen, og Quick og Live Migration kan da utføres fra en node til en annen. Kompatibilitetsmodus tillater ikke migrering mellom AMD og Intel, men vil fungere mellom prosessorer av samme arkitektur fra samme leverandør.
Før du slår på prosessor kompatibilitetsmodus bør du være klar over følgende:
- Ytelsen i den virtuelle maskinen kan bli dårligere i det alle prosessorens egenskaper på hosten, nødvendigvis ikke vil bli brukt.
- Programmer som er avhengig av spesifikke akselerasjons-relaterte prosessoregenskaper vil få redusert ytelse. Prosessor egenskaper for multimedia, high-performance computer (HPC) og kryptering vil sannsynligvis bli påvirket.
- Programmer som benyttet ikke-standard måter å utnytte prosessorer på, kan feile etter en migrering, selv om prosessor kompatibilitetsmodus er slått på.
- Noen programmer kan benytte seg av egenskaper som slås av pga. kompatibilitetsmodus.
Tips
En VM kan selvfølgelig tas ned (shutdown) for så å startes på en annen node. Man må da være oppmerksom på at endring av prosessor fra den ene noden til den andre vil kunne trigge produktaktivering.
Cluster Quorum konfigurasjon
Når du skal sette opp et cluster er det en fordel om alle noder er til stede på det tidspunkt clusteret skal settes opp dvs. installeres, og at nodene har tilgang til det delte lager, i det korrekt Quorum modell da automatisk blir valgt.
For det tilfelle at et 2 noders cluster skal opprettes, må følgende være tilstede:
- En Quorum disk på mist 512 MB på delt lager.
- En eller flere datadisker med nødvendig plass for en eller flere virtuelle maskiner på delt lager.
Diskene må være av type Basic Disks, MBR eller GPT og formatert med NTSF, og være tilgjengelige for begge noder. Hvis iSCSI benyttes, bør kommunikasjonen gå på dedikerte svitsjer. Merk at W2K8 iSCSI Initiator ikke støttet teaming.
Cluster Quorum inneholder clusterets konfigurasjonsdata for bla å kunne gjenopprette clusteret til en arbeidende status. Hver node i clusteret trenger tilgang til Quorum ressursen, uansett hvilken Quorum modell man benytter. Alternativet er at noden ikke kan delta i clusteret. For å unngå en situasjon der en eller flere noder tror den er eieren av Quorum (split brain), kan vi velge mellom fire Failover Cluster Quorum modeller. Uten å komme for langt inn på dette, så vil clusteret automatisk velge den modellen som passer best. For et to noders cluster, vil default valg være Node and Disk Majority Quorum.
Når Node and Disk Majority Quorum modellen benyttes, ligger Quorum disken på SAN-et. Denne modellen passer for Hyper-V Failover Cluster der alle noder er knyttet til et og samme SAN. En kopi av Quorum blir vedlikeholdt på “witness” disken, i tillegg til at hver node har en kopi. Clusteret vil fungere så lenge Quorum disken kan kontaktes og så lenge ½ (halvparten) av antallet noder fungerer. Quorum disken må være minst 512 MB stor.
Tips
For at Cluster installasjonswizarden skal velge beste løsning, påse at alle noder kjører, og blir meldt inn samtidig!
Figur 5 – For å sjekke Quorum Configuration, start Failover Cluster Manager, klikk på clusternavnet, velg More Actions i Actions, og klikk på Configure Cluster Quorum Settings.
Cluster nettverk
I et Hyper-V Failover Cluster har vi nettverkstrafikk av det som må kunne betegnes som ulike typer. Trafikken foregår på forskjellige subnet, også for det tilfellet at VLan tagging benyttes. Nettverkene som clusteret benytter seg av, deles opp etter den “typen” av trafikk som passerer igjennom det. I relasjon til Hyper-V Failover Cluster skilles det også mellom Private og Public nettverk. Clusteret foretar en vurdering av nettverkene og klassifiserer disse som vist i tabellen under. La oss gå i detaljer.
Tabell 4 – Forskjellen mellom private og public nettverk i cluster
|
Nettverkstype
|
Beskrivelse
|
|
Private
|
I cluster sammenheng, er et Private nettverk er et nettverks som ikke har Gateway. Private nettverk vil typisk bestå av separate subnet, og nettverkskortene konfigureres med IP adresse og subnetmaske, og kan gjerne kobles i en egen svitsj.
|
|
Public
|
Et Public nettverk i relasjon til cluster, er et nettverk med Gateway, Public nettverk konfigureres vanligvis med IP adresse i et separat subnet, subnet maske, gateway og DNS.
|
Tips
For å få feiltolerante svitsj-løsninger kan man teame nettverkskort i hostene og plassere de teamede NICs i hver sin svitsj, og LAG-koble svitsjene sammen. Nettverkskort benyttet til iSCSI kan ikke teames. Feiltoleranse for disse skapes ved at nettverkskort for iSCSI konfigureres med forskjellige subnet og kobles i forskjellige svitsjer. Enn videre kan MultiPath på iSCSI Initiator slås på.
Når vi nå kjenner definisjonen på private og public nettverk i relasjon til Hyper-V Failover Cluster, er det på tide å ta en titt på tabellen under som oppsummerer de respektive nettverk vi finner i clusteret.
Tabell 5 – Nettverksoversikt for Hyper-V Failover Cluster
|
Nettverksbenevnelse
|
Kan bruke teaming
|
Nettverks-type
|
Nettverks-trafikk
|
Beskrivelse
|
|
Storage
|
Nei
|
Private
|
Høy
|
I dette nettverket finner vi iSCSI eller Fiber Channel. Et eksempel på konfigurasjon av Microsoft iSCSI Target er inkludert i denne artikkelen. Forøvrig må det vises til leverandørens anvisninger for SAN-et.
|
|
Virtuelle maskiner
|
Ja
|
Public
|
Varierende
|
Et nettverk for virtuelle maskiner vil gjerne være public, i det de virtuelle maskiner skal kommunisere med resten av domenet og verden. De virtuelle maskiner i denne sammenheng er knyttet til en virtuell svitsj som i sin tur er forbudet til et fysisk nettverksadapter.
Det går an å ha virtuelle maskiner i flere ulike nettverk, men hvis man skal kommunisere med resten av verden, må man knytte virtuelle nettverk til fysiske nettverkskort via en virtuell svitsj. Det fysiske nettverkskort er så koblet videre i sine respektive nettverk.
Uten å komme for langt inn på dette, kan vi ha virtuelle svitsjer som er Private, Internal, External og Dedicated. For det tilfellet at External og eller Dedicated nettverk benyttes, så er den virtuelle svitsjen knyttet til et eksternt nettverkskort som er koblet i et subnet.
Se også avsnitt om virtuelle nettverk i denne artikkelen.
|
|
Management
|
Ja
|
Public
|
Lav
|
Nettverket er vanligvis å regne som et generelt Lan, dersom det ikke er konstruert særskilte nettverk for management, for eks i sikker sone eller DMZ. I dette nettverket befinner det seg en eller flere Domain Controllere, hvis hostene selv ikke er Domain Controllere. Nettverket benyttes for å administrere virtuelle hoster, for eks med System Center Essentials 2010 eller SC Virtual Machine Manager 2010.
|
|
Cluster Shared Volumes
|
Ja
|
Private
|
Lav og høy
|
Dette er et privat nettverk som forbinder nodene i clusteret med hverandre. Nettverket benyttes for Redirected I/O i forbindelse med backup og hvis en node ikke greier å kommunisere med det felles lager. Nettverket konfigureres som et privat subnet der subnettet er unikt. Dette blir nærmere forklart i det etterfølgende.
|
|
Live Migration
|
Ja
|
Private
|
|
Et privat subnet som er unikt og som benyttes for overføring av virtuelle maskiner fra en node til en annen under Live Migration. Nettverket brukes for overføring (synkronisering) av en virtuell maskins memory og innstillinger.
|
|
Cluster Heartbeat
|
Ja
|
Private
|
|
Nodene i clustered hilser stadig vekk på hverandre og utveksler informasjon, eg: “hei er du der?”. Denne kommunikasjonen vil foregå på alle nettverk som clusteret for lov til å kommunisere på. Dersom man setter opp egne NICs for dette, vil nettverket konfigureres som et privat, unikt subnet. Merk at nodene i prinsippet vil starte “fail-over” når de ikke kan kommunisere med hverandre.
|
|
Other Networks
|
Ja
|
|
|
Andre nettverk kan for eks bestå av DMZ soner, eller flere nettverkskort til domenet.
Merk at dersom flere nettverkskort er koblet i samme subnet (ikke teamet), så vil clusteret ignorere disse og det første nettet vil velges.
|
Figur 6 – To eller flere nettverkskort er nødvendig (med tillegg for lagring), for å dekke kommunikasjonsbehovet til Hyper-V Failover Clusteret. Dersom clusteret kun har to nettverkskort, anbefales det å benytte QoS for å sikre konnektivitet. Fire nettverkskort på 1 Gbps eller mer er den anbefalte løsningen.
I den overstående figuren vises det to diagrammer. Det ene diagrammet har 2 nettverkskort tilgjengelig for clusteret (venstre), og den andre 4 nettverkskort (høyre). I begge tilfeller vises det hva disse nettverkskortene benyttes til. Nå er de slik at denne oppstillingen nødvendigvis ikke passer med de servere som du har. Av den grunn er det inkludert en tabell utarbeidet av Microsoft som viser ulike løsninger med tanke på de nettverkskort som befinner seg i dine servere.
Tabell 6 – Anbefalte, støttede og ikke anbefalte nettverskonfigurasjoner for Live Migration
|
Host configuration
|
Virtual machine access
|
Management
|
Cluster and Cluster Shared Volumes
|
Live migration
|
Comments
|
|
4 network adapters with 1 Gbps
|
Virtual network adapter 1
|
Network adapter 2
|
Network adapter 3
|
Network adapter 4
|
Recommended
|
|
3 network adapters with 1 Gbps; 2 adapters are teamed for link aggregation (private)
|
Virtual network adapter 1
|
Virtual network adapter 1 with bandwidth capped at 10%
|
Network adapter 2 (teamed)
|
Network adapter 2 with bandwidth capped at 40% (teamed)
|
Supported
|
|
3 network adapters with 1 Gbps
|
Virtual network adapter 1
|
Virtual network adapter 1 with bandwidth capped at 10%
|
Network adapter 2
|
Network adapter 3
|
Supported
|
|
2 network adapters with 10 Gbps
|
Virtual network adapter 1
|
Virtual network adapter 1 with bandwidth capped at 1%
|
Network adapter 2
|
Network adapter 2 with bandwidth capped at 50%
|
Supported (1
|
|
2 network adapters with 10 Gbps; 1 network adapter with 1 Gbps
|
Virtual network adapter 1 (10 Gbps)
|
Network adapter 2 (1 Gbps)
|
Network adapter 3 (10 Gbps)
|
Network adapter 3 with bandwidth capped at 50%
|
Supported
|
|
2 network adapters with 10 Gbps; 2 network adapters with 1 Gbps
|
Virtual network adapter 1 (10 Gbps)
|
Network adapter 2 (1 Gbps)
|
Network adapter 3 (1 Gbps)
|
Network adapter 4 (10 Gbps)
|
Supported
|
|
3 network adapters with 1 Gbps; 2 adapters are teamed for link aggregation (public)
|
Virtual network adapter 1
|
Virtual network adapter 1 with bandwidth capped at 5%
|
Network adapter 2 (teamed)
|
Network adapter 2 with bandwidth capped at 90% (teamed)
|
Not recommended
|
|
2 network adapters with 1 Gbps
|
Virtual network adapter 1
|
Virtual network adapter 1 with bandwidth capped at 10%
|
Network adapter 2
|
Network adapter 2 with bandwidth capped at 90%
|
Not recommended
|
|
1 network adapter with 10 Gbps; 1 network adapter with 1 Gbps
|
Virtual network adapter 1 (10 Gbps)
|
Virtual network adapter 1 with bandwidth capped at 10%
|
Network adapter 2 (1 Gbps)
|
Network adapter 2 with bandwidth capped at 90%
|
Not recommended
|
1) This configuration is considered recommended if your configuration has a redundant network path available for Cluster and Cluster Shared Volumes communication.
Cluster Shared Volume og (CSV) redirected I/O
Med W2K8 R2 fikk vi CSV som er en funksjon som kan legges til Hyper-V Failover Clusteret. Som tidligere nevnt, kan kun en node bruke en og samme harddisk på SAN-et, selv om volumene prinsipielt sett er tilgjengelige for alle noder. Når et volum på clusteret oppgraderes fra cluster storage til CSV, fjernes denne begrensningen, og en og samme disk kan benyttes samtidig av flere noder og det kan ligge flere virtuelle maskiner på CSV disken som kjøres av hver sine respektive noder i clusteret.
Det slik at CSV også innebærer redirigert I/O under gitte forhold. Vi innsikt i dette for å forstå betydningen av CSV nettverket. Vi skal derfor ta en nærmere titt på i dette nå, men først må vi bli enige om hvilken rute en normal kommunikasjon tar. Normal kommunikasjonen mellom en virtuell maskin og VHD filen (harddisken) som ligger på SAN-et, går igjennom hosten som kjører den virtuelle maskinen, via tilkoblingen til SAN-et. Det er logisk, men det er ikke logisk at denne kommunikasjonen vil bli redirigert til et annet nettverk under gitte forhold! CSV nettverket vil benyttes for iSCSI av en eller flere noder i clusteret ved backup av CSV disken og eller hvis iSCSI nettverket feiler for en eller flere noder.
Redirigering (CSV redirected I/O mode) av disk input/output oppstår under følgende forhold:
1) Når en node mister kommunikasjonen med SAN-et.
2) Når det tas en host backup (operating system based backup(s)) eller såkalt “parent-partition based” backup. Sjekk her.
Når en CSV disk plasseres i redirigert I/O brukes CSV nettverket fra den ene hosten til den andre hosten som kommuniserer med SAN-et. Vi forstår at dette kan innebære en betydelig belastning på CSV nettverket dersom det ligger mange virtuelle maskiner på en og samme CSV disk, og at man må stille høye krav til CSV nettverket. På den annen side får vi bedre feiltoleranse!
Figur 7 – Når CSV befinner seg i redirigert I/O mode, vil CSV nettverket benyttes mellom hostene, og alle kommunikasjon til CSV disken vil gå via en node. Redirigering brukes ved backup og når en node ikke kan kommunisere med SAN-et.
Tips
For at CSV redirigering skal være vellykket må følgende konfigurasjoner være utført:
a) Disken for CSV må være MBR eller GPT og formatert med NTSF.
b) Driveletter må være den samme på begge hoster.
c) NTLM må være påslått på alle noder.
d) Nettverkskort som skal kunne benyttes for CSV kommunikasjon, må være konfigurert med Client for Microsoft Networks og File and Printer Sharing for Microsoft Networks.
e) Alle noder må ha et IP subnet i CSV nettverket, husk eventuelt VLan.
f) I Failover Clusters Management networks, må cluster kommunikasjon være tillatt på CSV nettverket.
Figur 8 – Når en virtuell maskin kjører på en vanlig disk (cluster shard volume), og kommunikasjonen til SAN-et brytes, så vil den virtuelle maskinen krasje (venstre). Hvis den virtuelle maskinen ligger på en CSV disk, så vil VM-en fortsette å fungere selv om noden den kjører på har mistet kommunikasjonen til SAN-et. Kommunikasjonen til SAN-et blir redirigert via CSV nettverket til den andre noden.
Styring og prioritering av nettverkstrafikk i clusteret
Clusteret har et behov for å kunne finne frem blant de mange nettverkskort for å prioritere å styre trafikk til de ulike nettverkene. Clusteret starter derfor med å dele nettverkene i Private og Public nettverk som tidligere beskrevet. Her skilles det henholdsvis mellom nettverk uten gateway og de med. Deretter introduserer clusteret en nummerering av nettverkene ved å knytte en Metric verdi til disse. Når dette er på plass, kan clusteret prioritere trafikken etter noen enkle som regler som bla skaper feiltoleranse.
I utgangspunktet blir Metric verdiene satt av clusteret selv. Automatikken bestemmes av nok en parameter pr nettverk, ved navn AutoMetric, og clusteret bruker sin automatiske logikk pr nettverk når AutoMetric er True. Vi kan overstyre innstillingen på hosten i Windows PowerShell. Når vi overstyrer verdien for et nettverk, blir AutoMetric automatisk stilt til False. Den kan selvfølgelig settes tilbake til True. De to understående tabellene oppsummerer betydningen av default Metric verdier og logikken for prioritering av nettverkstrafikk og feiltoleransen fremkommer ved at alternative nettverk blir valt. Pay attention og studer tabellene!
Tabell 7 – Automatiske Metric verdier
|
Metric verdi
|
Metric verdi
|
Beskrivelse
|
|
Private nettverk
|
1000 – 9999
|
Clusteret vil automatisk tildele private nettverk en Meric verdi mellom 1000 og 9999. Inkrement er 100.
|
|
Public nettverk
|
10000 – xxxxx
|
Clusteret vil automatisk tildele public nettverk en Metric Verdi som starter på 10000 og går oppover. Inkrement er 1000.
|
Tabell 8 – Regler i clusteret for prioritering av trafikk
|
Nr
|
Trafikk type
|
Beskrivelse
|
|
1
|
Live Migration
|
Clusteret vil velge det nettverket som har lavest Metric verdi. Hvorfor benevnes dette valget som “preferred”, jo fordi dersom det er en feil i dette nettverket så vil det nest laveste (osv.) benyttes. Det gjelder også de øvrige.
|
|
2
|
Cluster Shared Volumes
|
Clusteret vil automatisk velge det nettverket som har den nest laveste verdien.
|
|
3
|
Cluster Heartbeat
|
Cluster heartbeat vil foregå på alle nettverk der Cluster Networks er konfigurert med Allow cluster network communication on this network. Denne konfigurasjonen utføres i Failover Cluster Manager.
|
For det tilfellet at man ønsker å konfigurere Metric verdiene manuelt er det inkludert en tabell for dette under.
Tabell 9 – Forslag til manuelle verdier hvis du skal stille dette
|
Funksjon / nettverkstype
|
AutoMetric
|
Metric
|
|
Management
|
True
|
Auto
|
|
iSCSI (SAN) Storage
|
True
|
Auto
|
|
Live Migration
|
False
|
1000 – 1099
|
|
Cluster Shared Volumes
|
False
|
500 – 999
|
|
Other Networks
|
True
|
1500 – 1999
|
|
Cluster Heartbeat
|
False
|
Auto
|
|
Virtual Switches
|
True
|
Auto
|
Tips
Husk at du må stille hvilket nettverk som skal benyttes for Live Migration i Failover Cluster Manager. Se eget eksempel (avsnitt) på hvordan dette kan gjøres.
Hvis du nå trodde at du var ferdig så tar du feil. Clusteret utfører også en tredje innstilling med hensyn på hvilke nettverk som kan benyttes til hva. Denne innstillingen finnes i Failover Cluster Management panelet, og den benevnes vanligvis Cluster Network Role. I management panelet kan vi angi lovligheten av kommunikasjon i hvert nettverk med to og en tilleggs konfigurasjon. Disse konfigurasjoner oppsummeres i tabellen under, og i den påfølgende tabellen finner du vanlige innstillinger pr. nettverkstype.
Tabell 10 – Cluster networks Role
|
Role
|
Innstilling
|
|
0
|
Enabled - Do not allow cluster network communication on this network.
|
|
1
|
Enabled - Allow cluster network communication on this network.
Disabled - Allow clients to connect through this network.
|
|
3
|
Enabled - Allow cluster network communication on this network.
Enabled - Allow clients to connect through this network.
|
Tabell 11 – Cluster Network Roles pr nettverkstype
|
Funksjon / nettverkstype
|
Cluster Network Roles
|
|
Management
|
Enabled - Allow cluster network communication on this network.
Enabled - Allow clients to connect through this network.
|
|
Storage
|
Enabled – Do not allow cluster network communication on this network
|
|
Live Migration
|
Enabled – Do not allow cluster network communication on this network
|
|
Cluster Shared Volumes
|
Enabled - Allow cluster network communication on this network.
Disabled - Allow clients to connect through this network.
|
|
Other Networks
|
Konfigurasjon basert på gjellende miljø.
|
|
Cluster Heartbeat
|
Enabled - Allow cluster network communication on this network.
Disabled - Allow clients to connect through this network.
|
|
Virtual Switches
|
Disabled - Allow clients to connect through this network.
|
Tabell 12 – Forklaringer på Cluster Network Roles
|
Funksjon
|
Binding order
|
|
Allow cluster network communication on this network.
|
Select only this option if you want the Cluster service to exclusively use this network for inter-node communication traffic. Clients will not be able to connect to the CMS using this network.
|
|
Allow clients to connect through this network
|
Select both of these options if you want the Cluster service to use the network adapter for the cluster inter-node communication and for communication with external clients. The Cluster service will use this network for inter-node communication, and clients will be able to connect to the CMS using this network.
|
|
Do not allow cluster network communication on this network
|
Select only this option if you do not want to use the network in the cluster, or have the Cluster service manage the network. The Cluster service will not be able to use this network for inter-node communication, and clients will not be able to connect to the CMS using this network.
|
Og når du trodde du var ferdig kommer det ennå en nettverkskonfigurasjon! Denne gangen gjelder det Network adapter binding order på hostene.
Tabell 13 – Nettverk Adapter Binding Order
|
Funksjon / nettverkstype
|
Forslag 1
|
Forslag 2
|
File and printer Sharing for Microsoft Networks
|
Client for Microsoft Networks
|
|
|
Management
|
1
|
1
|
Ja
|
Ja
|
|
Storage (ISCSI)
|
2
|
5
|
Nei
|
Nei
|
|
Live Migration
|
3
|
2
|
Ja
|
Ja
|
|
Cluster Shared Volumes
|
4
|
3
|
Ja
|
Ja
|
|
Other Networks
|
5
|
8
|
*
|
*
|
|
Cluster Heartbeat
|
6
|
4
|
Nei
|
Nei
|
|
Virtual Machines (fysisk NIC)
|
7
|
6
|
*
|
*
|
|
Virtual Switches
|
8
|
7
|
*
|
*
|
*) I disse tilfellene må det gjøres konkret vurdering. For eks om man for virtuelle svitsjer og fysiske nettverkskort skal tillate kommunikasjon direkte til host eller ei. Dette vil være forskjellen mellom Internal, External og Dedicated virtuelle nettverk i Hyper-V manager.
**) NetBIOS slår undertegnede av på alle NICs.
Undertegnede har lett mye rundt for å sjekke hva som eventuelt er beste praksis på området uten å finne et definitivt svar på dette. Det synes imidlertid å være gjennomgående å prioritere public nettverk fremfor private nettverk. Argumentet som anvendes for dette er at trafikk fra brukere vil overstige trafikken fra øvrige nettverk. Det synes også å være gjennomgående enighet om at Management nettverkskortet skal stå først.
Tips
Husk at Client for Microsoft Networks og File and printer Sharing for Microsoft Networks må kjøre på det nettverkskortet som er dedikert for Cluster Shared Volumes. Hvis det skulle foreligge en feil på dette nettverket, vil Failover Clusteret forsøke å velge et annet nettverk. I så fall må dette nettverket være konfigurert med de samme tjenester!
Virtuelle nettverk
Det er nok på sin plass med en relativt rask forklaring på Virtuelle Nettverk og virtuell svitsj. Dette er to begreper som snurrer rundt hos de fleste. Det hjelper i praksis å forestille seg dette som en vanlig fysisk svitsj (analogi). Vi må opprette det MS kaller et Virtuelt Nettverk i Hyper-V Manager. La oss nå si at dette er en svitsj, selv om den er software basert og ligger i virtuell host et sted. Til en svitsj kan vi koble kabler og datamaskiner med nettverkskort, så også i server der Hyper-V er installert. Vi har ingen fysiske kabler, men parameter i egenskapene på det virtuelle nettverk, det fysiske nettverkskortet og de virtuelle maskiner. Vi beholder derfor kabelanalogien fordi den er bra for forståelsen.
Det er kun ett sted (foruten Virtual Machine Manager 2008 / 2010) der vi kan opprette et virtuelt nettverk. Det er i Hyper-V Manager som er installert på den virtuelle hosten. Når det virtuelle nettverket, (tenk på dette som en fysisk svitsj), er opprettet kan vi koble til computere med nettverkskort. I denne sammenheng er computere; virtuell host, den virtuelle maskin og det fysiske nettverkskortet, og siden kablene er programbasert, finnes det menyer med parametere hvorved komponentene kan knyttes til den virtuelle svitsjen. Dvs. at vi strekker kabler mellom virtuell host (parent partition), virtuelle maskiner (child partitions) og ”den inne i serveren” fysiske nettverkskortet. Det fysiske nettverkskortet har dog også en utvendig kabelplugg for det fysiske nettverket.
Når vi oppretter et virtuelt nettverk i Hyper-V Manager, kan vi velge mellom nettverkstyper dvs. hva som skal være tilkoblet den virtuelle svitsjen. Men, hva med nettverkskortet i den virtuelle maskinen? Vel, som alle nettverkskort må jo denne være tilkoblet en svitsj (eller lignende), og vi må angi hvilken svitsj den virtuelle maskinen skal være tilkoblet til i egenskapene på den virtuelle maskinen. Når du logger på den virtuelle maskinen finner du et nettverkskort der. Det må selvfølgelig konfigureres. Når det fysiske nettverkskortet forbindes til en virtuell maskin, forsvinner alle tjenester (protokoller, IP innstillinger osv.), og Hyper-Vs virtuelle svitsj tjeneste installeres og konfigureres. I så måte vil det fysiske nettverkskortet som er knyttet til en virtuell svitsj ikke ha noen IP adresse. IP adressene finner vi inne i den virtuelle maskin. Det er derfor tjenesten Microsoft Virtual Switch Protocol som besørger kommunikasjon mellom den virtuelle svitsjen og den fysiske svitsjen, slik at den fysiske svitsjen forstår hva som finnes av IP adresser, v-Lan, Mac adresser også videre i det virtuelle nettverket.
Av overstående er det mulig å forstå at vi har fire typer av koblinger, fordelt på tre virtuelle nettverkstyper. Disse er Private, Internal, External og Dedicated. De behandles nå hver for seg.
Private – denne typen av virtuelt nettverk kommuniserer kun med andre virtuelle maskiner som deltar i det samme private nettverket. Forenklet kan man si at det er en kabel mellom nettverkskortet i den virtuelle maskin til en virtuell svitsj, men den virtuelle svitsjen er ikke forbundet til host eller det fysiske nettverkskortet. Konsekvensen er at det kun er virtuelle maskiner som er knyttet til samme virtuell svitsj som kan snakke sammen. Alt i alt kan 512 virtuelle maskiner være knyttet til den samme virtuelle nettverkssvitsjen. Kommunikasjonshastigheten mellom de virtuelle maskinene vil være 10 Mbps dersom Integration Service er installert, og det ikke er virtuelle maskiner som benytter Legacy Network Adapter.
Gjesteoperativsystemets nettverkskort inne i den virtuelle maskinen vil ikke ha noen ip-adresse hvis vi ikke manuelt har konfigurert dette, eller en DHCP server i en virtuell maskin knyttet til den private svitsjen har konfigurert nettverkskortet. Du kan ikke konfigurere en DHCP server på den virtuelle svitsjen slik man kan på enkelte fysiske nettverkssvitsjer eller slik vi husker dette fra Virtual PC. For å prate sammen må selvfølgelig alle virtuelle maskiner knyttet til samme virtuelle svitsj, ha ip-adresser i samme subnett.
Internal – I dette tilfelle har vi fortsatt en virtuell svitsj og virtuelle maskiner som er tilkoblet den virtuelle svitsjen, og de kan kommunisere seg i mellom som beskrevet over. Tillegget i Internal nettverket er at det er koblet en kabel mellom den virtuelle svitsjen og virtuell host. Vi forstår derfor at virtuelle maskiner nå kan prate med den virtuelle host. Man kan for eks. ha en delt (shared) katalog på hosten.
Figur 9 – Prinsippene for Private, Internal, External og Dedicated virtual networks i Hyper-V.
External – betyr at den virtuelle maskinen gjennom den virtuelle svitsjen, skal kunne kommunisere med andre computere utenfor den virtuelle hosten. For å få til dette må det virtuelle nettverket (svitsjen) bindes til et fysisk nettverkskort på virtuell host. Med andre ord trekkes det en kabel mellom den virtuelle svitsjen og det fysiske nettverkskortet. Utover dette vil det pr default være mulig å kommunisere ”internt” med virtuell host i tillegg, idet External automatisk trekker en kabel mellom den virtuelle svitsjen og virtuell host.
Når man benytter et virtuelt nettverk av typen External vil følgende skje:
a) Det vil opprettes et virtuelt nettverkskort.
b) Innstillingene på det fysiske nettverkskortet som det virtuelle er knyttet til, vil kopieres over til det virtuelle nettverkskortet (når det gjelder ip, subnet, gateway og DNS).
c) Det fysiske nettverkskortet vil konfigureres med tjenesten Microsoft Virtual Network Switch Protocol, og andre tjenester slås av.
d) Dersom det fysiske nettverkskortet var konfigurert til å motta ip, vil det opprettede virtuelle nettverkskortet konfigureres til å motta ip fra DHCP.
God Praksis
Det er god praksis å konfigurere det virtuelle nettverkskortet med fast ip-adresse i henhold til det nettverket (subnettet) som det fysiske nettverkskortet er knyttet til.
Dedicated - I dette tilfellet lages det et isolert nettverk, idet den virtuelle maskinen ikke kan kommunisere uten å gå via en fysisk svitsj. Det etableres en direkte kontakt mellom nettverkskortet i den virtuelle maskinen og det fysiske nettverkskortet via en virtuell svitsj som ikke vil vises i networks på hosten. Dette et den anbefalte og ideelle løsning for hoster og for det tilfellet at man har flere nettverk å forholde seg til. For å sette opp et Dedicated virtuelt nettverk, velger man External og fjerner sjekken i Allow management operating system to share the network adapter.
Tips
Dette er den typen av virtuelle nettverk som undertegnede benytter selv på alle virtuelle nettverkskort. Det er den mest fleksible konfigurasjonen, idet fysiske nettverkskort kan kobles i et hvilket som helst subnett. Hvis du som undertegnede, har flere nettverk, eg Lan 1, Lan 2, DMZ osv, og du har et tilstrekkelig antall nettverkskort i hostene (nodene), vil denne konfigurasjonen sikre muligheten for å kunne koble disse nettverkskortene inn i ulike subnet for ulike formål uten å ta ned clusteret. Alternativet vil være å “bygge” opp VLan tagging.
Host Clustering
Du kan clustre virtuelle maskiner i Hyper-V. Figuren under viser to eksempler på dette. I det første eksempelet har vi et Hyper-V Failover Cluster på fysiske maskiner. På hver host finner vi så to virtuelle maskiner som så er konfigurert i et nytt Failover Cluster. I det andre eksempelet har man to separate Hyper-V Failover Clustre, og det kjører to separate clustre som virtuelle maskiner. Hvert Hyper-V Failover Cluster har så virtuelle maskiner som selv er noder i separate clustre. Du skal være glad i nettverkskort og subnett for disse konstruksjonene som er Microsoft supportert. Så var dette nevnt.
Figur 10 – Host Clustering er supportert av Microsoft.
Når man summer seg litt og trekker veksler på det som tidligere er lest, forstår man at Failover Clustrede virtuelle maskiner trenger tilgang til Quorum disk og felles lager for de(n) clustrede tjenestene. Dette kan gjøres inne i de virtuelle maskiner med iSCSI Initiator og nettverkskort forbundet til dedikerte virtuelle svitsjer knyttet til fysiske nettverkskort. Utover dette trenger man to nettverk i tillegg. Det første er et public nettverk og det andre et Privat nettverk. Public nettverket forbinder clusteret til resten av verden, mens Private nettverket er for cluster Heartbeat.
Sistnevnte vil være av typen dedikerte virtuelle svitsjer knyttet til fysiske nettverkskort forbundet sammen via en fysisk svitsj og et unikt subnett. Public nettverket forbinder hoster og de clustrede tjenestene til resten av verden, også her kan dette gjøres via virtuelle svitsjer og fysiske nettverkskort, alternativt knyttes clustrede tjenester inn i eksisterende virtuelle svitsjer for virtuelle maskiner og generelt Lan. De mest aktuelle (og lettest å få til) clustrede tjenester er DHCP server og File Server. Hvis man ønsker å clustre programmer så er MS SQL Server en kandidat. Husk at eventuelle programmer må være cluster opplyste (aware).
Backup av Hyper-V Failover Cluster
I dette avsnittet skal vi ta en meget kort titt på to backup løsninger for Hyper-V Failover Cluster.
Windows Server Backup
Ut av boksen kan Windows Server Backup benyttes til å ta sikkerhetskopi av clustrede noder og de cluster disker som for øyeblikket er online på noden. En slik sikkerhetskopi vil også dekke System State, Hyper-V og virtuelle maskiner som for øyeblikket kjører på noden. Når det gjelder Quorum så må en av nodene ta sikkerhetskopi av denne. Windows Server Backup blir ikke nærmere beskrevet her, WSB er beskrevet i andre artikler på smallbizserver.no i relasjon til virtualisering med Hyper-V. Pass på å sjekk KB982210, og sjekk beskrivelsen knyttet til DPM 2010.
Tips
Windows Server Backup støtter ikke CSV.
System Center Data Protection Manager 2010
Microsoft System Center Data Protection Manager 2010 kan ta backup av Hyper-V Failover Cluster, inkludert CSV. Backup kan gjøres hvert 15 minutt av noder og hele virtuelle maskiner, og med agent inne i virtuelle maskiner. Når agent er inne i virtuelle maskiner kan det bla tas backup av Exchange server (2003, 2007 og 2010), SQL server (2000, 2005 og 2008), SharePoint osv. Når man tar backup av hele virtuelle maskiner, kan item level recovery benyttes. I så fall må man også kjøre rollen Hyper-V på DPM 2010. Microsoft har skrevet et whitepaper om DPM 2010 og Hyper-V / Failover Cluster som kan lastes ned: How to protect Hyper-V with DPM 2010 whitepaper.
Figur 11 – Data Protection Manager 2010.
Figur 12 – Protecting Exchange Server med DPM 2010.
Noen konkrete råd knyttet til VSS, WSB, DPM 2010 og Hyper-V Failover Cluster
Denne artikkelen kommer ikke konkret in på bruk av DPM 2010, men for helhetens skyld vil jeg inkludere noen oppsummerende punkter som man må være oppmerksom på, basert på mine erfaringer.
· Dersom man skal benytte DPM 2010 og CSV vil default innstillingen av DPM 2010 forutsette hardware støtte i SAN-et for VSS snapshots. En slik hardware støtte er det mange som oppdager at SAN-et ikke har, eller at SAN-et ikke støtter DPM 2010 for Microsoft tested VSS hardware support for DPM 2010 sjekk denne linken her. For å komme rundt denne problemstillingen må man konfigurere DPM 2010 til serialized backup. Dette gjøres med en registry key, men man må i tillegg informere DPM 2010 hvilke virtuelle maskiner som ligger på CSV volumene. Dette gjøres med en XML fil og scheduled task på nodene i Hyper-V Failover Clusteret. De mest populære likene i denne forbindelsen er:
God Praksis for Hyper-V Failover Cluster
Understående tabell oppsummerer god praksis for Hyper-V Failover Cluster, basert på denne artikkelen.
Tabell 14 – God Praksis for Hyper-V Failover Cluster
|
Oppgaver
|
Beskrivelse
|
|
1
|
Hvis iSCSI benyttes for delt lagring:
- Benytt dedikerte feiltolerante svitsjer for iSCSI nettverket.
- Bruk et eget, lukket subnett for iSCSI kommunikasjon, og påse at subnett-masken på andre adaptere ikke inkluderer iSCSI nettverket.
- Bruk minimum CHAP autentisering ved pålogging.
- Ekskluder iSCSI nettverket fra cluster kommunikasjon.
- Benytt MULTI Path.
|
|
2
|
Bruk like servere som noder i Failover Clusteret. Dette med like servere gjelder all hardware, firmware og software osv, inkludert konfigurasjoner av hardware og software.
- Hvis prosessorer og nettverkskort ikke er like, så må dette grundig testes før Failover Clusteret settes i produksjon.
|
|
3
|
Bruk et tilstrekkelig antall nettverkskort i hostene. Sjekk Tabell 6 – Anbefalte, støttede og ikke anbefalte nettverskonfigurasjoner for Live Migration, og velg en løsning som er “Supported”.
- Hvis Microsoft anbefaler QoS, påse at nodene konfigureres med dette.
- Hvis Dell BMC planlegges brukt, velg nettverkskort med omhu, slik at dette vil fungere. Test det før clusteret settes i drift. I mange tilfeller krever BMC dedikert NIC.
|
|
4
|
Vurder hvilke nettverkskort som benyttes til hva, slik at det oppnås beste feiltoleranse med hensyn på at de ulike nettverk settes sammen med porter i ulike nettverkskort, slik at dersom et nettverkskort feiler så rammes ikke all type av samme kommunikasjon.
|
|
5
|
Bruk statiske IP-adresser (IPv4 og IPv6) på alle nettverkskort, og kontroller at alle nettverkskort er konfigurert likt med hensyn på adapters innstillinger, og konfigurer egne subnett for hvert enket nettverk. Bruk dedikerte svitsjer.
|
|
6
|
Konfigurer nettverk Adapter Binding likt på hostene.
|
|
7
|
Påse at alle nettverkskort er til stede, at nettverkene virker, og at navnene på nettverkskort og virtuelle nettverk er satt opp likt på alle hoster før clusteret opprettes, slik at cluster networks konfigureres korrekt med hensyn på Metric.
- Påse at nettverkstjenester er korrekt konfigurert for nettverk for CSV.
|
|
8
|
Hvis CSV planlegges brukt, sett deg grundig inn i forutsetninger og betingelser for sikkerhetskopiering. Windows Server Backup støtter ikke CSV.
|
|
9
|
Valider clusteret og rett feil og mangler før clusteret settes i produksjon.
- Les Microsoft support policy i KB943984.
- Valider clusteret ved hardware endringer.
|
|
10
|
Sjekk at korrekt Quorum modell er valg av clusteret.
|
|
11
|
Når clusteret er opprettet, sjekk nettverket:
- Gi nettverkene i Failover Cluster Manager meningsfylte navn ved å gi dem nye navn.
- Konfigurer Cluster Networks
o Ekskluder iSCSI nettverket fra Cluster kommunikasjon.
- Sjekk at Cluster Role og Metric’s er korrekt konfigurert i relasjon til de respektive nettverk.
|
|
12
|
Følg God Praksis for virtuelle maskiner som skal kjøre i Failover Clusteret, sjekk Tabell 33 – Om virtuell maskiner (VM) side 117 i denne artikkelen.
|
|
13
|
Sjekk at CSV redirection foregår i korrekt nettverk.
Tips
Denne kontrollen kan gjøres ved å starte en virtuell test maskin for så å koble fra nodens forbindelse til SAN-et.
|
|
14
|
Still nettverket for Live Migration på virtuelle maskiner i Failover Cluster Manager, og sjekk at trafikken i denne forbindelse foregår i korrekt nettverk.
Tips
Dette kan gjøres ved overvåkning i Task Manager under fanen Networks, mens en virtuell maskin migreres.
|
|
15
|
Når clusteret er opprettet, sjekk at failover fungerer for virtuelle maskiner i alle nettverk.
Tips
For at Live Migration skal fungere må nettverkskort og virtuelle svitsjer ha samme navn på alle noder på det tidspunkt clusteret opprettes.
|
|
16
|
Om antivirus på noder:
- Planning for Hyper-V security: “Do not run any applications, such as antivirus programs, in the management operating system---run all applications on virtual machines. By keeping the management operating system free of applications and running a Windows Server 2008 core installation, you will need fewer updates to the management operating system because nothing needs software updates except the Server Core installation, the Hyper-V service components, and the small (approximately 600 KB) hypervisor.” Note: If you need to use the full version of Windows Server 2008 and run applications in the management operating system, then you should run an antivirus program there.
- Anbefalinger for virusskanning for Enterprise/datamaskiner som kjører støttede versjoner av Windows – KB922158
- Virtual machines are missing in the Hyper-V Manager Console or when you create or start a virtual machine, you receive one of the following error codes: "0x800704C8", "0x80070037" or "0x800703E3" – KB961804
|
|
17
|
Tips
I påvente av SP1 for W2K8 R2, har jeg fått det rådet at man bør være måteholden med hurtigfikser.
|
|
18
|
Automatic Start og Stop Action henger sammen med din UPS. For det første trenger nodene en UPS programvare som er Hyper-V “aware”. Med dette menes at nedkobling av noden først skjer etter at virtuelle maskiner er stoppet.
- Sjekk konfigurasjonene av Virtual Machine Properties under fanen Settings i Failover Cluster Manager. Innstillingene er; Save, Shutdown, Shutdown (forced) og Turn off.
|
|
19
|
Når Hyper-V Failover Clusteret planlegges, må man passe på å velge en Cluster modell (Active-passiv, Active-active eller Mix-and-match) som passer med de ressursene (prosessor, memory og nettverkskort) nodene har, slik at man unngår en situasjon med overbelastning når failover inntreffer.
|
|
20
|
Når virtuelle maskiner opprettes, er det ikke nødvendigvis korrekt å “kaste” ressurser som prosessorer og memory inn i virtuelle maskiner når den underliggende programvaren hverken kan benytte flere prosessorer eller den mengden av memory som VM-en settes opp med. Dette kan fullstendig drepe et cluster med hensyn på ytelse. Man må særlig ha et edruelig forhold til prosessorer, og ikke tildele en virtuell maskin to eller flere prosessorer hvis dette ikke er påkrevd.
|
|
21
|
Hvis du planlegger å benytte Failback konfigurasjon av virtuelle maskiner, bør du kontrollere tidspunktene for dette, og legge Failback på tidspunkter hvor virtuelle maskiner ikke er benyttet av brukere og sikkerhetskopiering. Sjekk Tabell 35 – Virtual Machine properties i Failover Cluster Manager side 123 i denne atikkelen.
|
|
22
|
Konfigurer ikke noder i clusteret for automatisk oppdatering knyttet til MS Update. Dette vil kunne forårsake ukontrollert restart av noder i clusteret og tilhørende virtuelle maskiner.
|
|
23
|
Ta og test backup og restore av noder og virtuelle maskiner før Hyper-V Failover Clusteret settes i produksjon
|