Windows Server 2016 Hyper-V: Sikrere, men ikke raskere

Med Windows Server 2016 har Microsoft introdusert en lang liste over forbedringer av Hyper-V. I tillegg til funksjonelle tillegg som containerstøtte, nestet virtualisering og økt minne og vCPU-grenser, finner du en rekke nye funksjoner, inkludert sjekkpunkter i produksjonsklassen og muligheten til å legge til minne- og nettverkskort, som letter administrasjonen.

Men Microsofts hovedmål i 2016 Hyper-V-utgivelsen ser ut til å ha vært å forbedre sikkerheten. Faktisk vil jeg gå så langt som å si at Hyper-Vs nye killer-funksjon er skjermede virtuelle maskiner, som fungerer med BitLocker-kryptering og en verge-tjeneste for å sikre at virtuelle maskiner bare kjører på autoriserte verter.

Hvis en Hyper-V 2016-funksjon ville presse meg til å oppgradere, ville det være den skjermede VM-funksjonen. Men muligheten til å tildele mer minne til generasjons 2 virtuelle maskiner, og muligheten til å legge til minne og nettverkskort til virtualiseringsverter, er også store trekkplaster.

Ett område som Hyper-V 2016 kanskje ikke forbedrer, er VM-ytelsen. Faktisk indikerer Sandra-testene mine for en virtuell Windows Server 2012 R2-maskin på Hyper-V 2012 R2 versus Hyper-V 2016 et skritt bakover. Jeg vil ikke kalle disse resultatene definitive på noen måte, men husk det når du begynner å evaluere Windows Server 2016 Hyper-V for dine egne arbeidsbelastninger.

Oppsettprosessen for Hyper-V

I forbindelse med denne gjennomgangen oppgraderte jeg en eksisterende Windows Server 2012 R2-server til Windows Server 2016. For det meste var oppgraderingsprosessen nesten identisk med installasjonen av Windows Server 2012 R2. Forskjellen var at installasjonsveiviseren viser en advarsel om at Windows Server-oppgraderinger ikke anbefales, og at du bør utføre en ren installasjon. Installasjonsveiviseren hindrer deg ikke i å utføre en oppgradering på stedet, men du må klikke på Bekreft-knappen for å bekrefte advarselen.

Jeg gikk videre med oppgraderingsprosessen (selv om jeg siden har utført flere rene installasjoner) fordi jeg ønsket å se hva som ville skje. Dessuten kjørte serveren jeg oppgraderte en ren installasjon av Windows Server 2012 R2. Jeg hadde installert Hyper-V-rollen og opprettet noen virtuelle maskiner, men jeg hadde ikke installert ytterligere programvare (bortsett fra Microsoft-oppdateringer) eller aktivert unormale konfigurasjonsinnstillinger.

Oppgraderingsprosessen for Windows Server gikk veldig greit. Alle mine eksisterende operativsysteminnstillinger ble bevart, og de virtuelle maskinene mine forble funksjonelle etter oppgraderingen. Videre følte Hyper-V Manager seg fortsatt helt kjent. Selv om Microsoft har introdusert en rekke nye Hyper-V-funksjoner i Windows Server 2016, har Hyper-V Manager endret seg veldig lite. Administratorer med tidligere Hyper-V-erfaring er sikker på at de føler seg hjemme når de bruker den nye versjonen.

Rullende oppgraderinger av Hyper-V-klynger

Selv om jeg opprinnelig utførte en stedlig oppgradering av en enkelt Hyper-V-vert, støtter Microsoft også rullende oppgraderinger av klyngede Hyper-V-distribusjoner. Dette betyr at servere som kjører Windows Server 2016 Hyper-V kan legges til eksisterende Windows Server 2012 R2 Hyper-V-klynger og i hovedsak etterligne Windows Server 2012 R2 Hyper-V-verter, og dermed tillate dem å delta fullt ut i klyngen. Windows Server 2012 R2 Hyper-V virtuelle maskiner kan overføres direkte til Windows Server 2016 Hyper-V-noder, og derved muliggjør en klyngeoperativsystemoppgradering uten å ta noen av de virtuelle maskinene offline.

I prosessen med å skrive denne gjennomgangen distribuerte jeg en tre-node-klynge av Windows Server 2012 Hyper-V-servere, og la deretter til en Windows Server 2016 Hyper-V-node. Jeg var i stand til å bli med i noden til klyngen og leve migrere virtuelle maskiner frem og tilbake mellom de to forskjellige Hyper-V-versjonene. Kort fortalt fungerte den rullende oppgraderingsprosessen feilfritt.

Jeg fullførte klyngeoppgraderingen i løpet av en ettermiddag, men Microsoft tillater langsiktig sameksistens mellom Hyper-V-versjoner i en klynge. Langsiktig sameksistens vil helt sikkert være lettere nå som Microsoft har modernisert Hyper-V Manager, slik at den kan brukes samtidig med flere Hyper-V-versjoner. Fra Hyper-V Manager i Windows Server 2016 kan du også administrere Hyper-V på Windows Server 2012 og Windows Server 2012 R2.

En ulempe med den nye Hyper-V Manager: Fordi Microsoft nå leverer oppdateringer til Hyper-V Integration Services gjennom den normale oppdateringsprosessen, ser det ut til at alternativet for å distribuere integrasjonstjenestene er fjernet. Installasjon av integrasjonstjenester via Windows Update høres ut som fremgang, men det ville ikke skade å ha den gamle metoden tilgjengelig som en reserve.

Merk at når alle klyngenodene dine kjører Windows Server 2016 Hyper-V, og du har oppdatert klyngens funksjonelle nivå (en bevisst administrativ handling du utfører gjennom PowerShell), vil du miste muligheten til å legge til Windows Server 2012 R2-noder til klynge. Etter at du har oppdatert klyngens funksjonsnivå, er det ingen vei tilbake.

Skjermede virtuelle maskiner

Mens det er gjort mye arbeid gjennom årene for å beskytte virtuelle maskiner mot trusler utenfor, har virtuelle maskiner (inkludert de på konkurrerende plattformer som VMware, Xen og KVM) vært sårbare for kompromisser av en useriøs administrator. Ingenting hindrer en administrator i å kopiere en hel VM til en USB-flashstasjon og gå ut døren med den. Visst, det var tidligere mulig å kryptere virtuelle harddisker, men en autorisert administrator kan enkelt angre enhver kryptering på VM-nivå.

I Windows Server 2016 Hyper-V krypterer den skjermede VM-funksjonen en virtuell maskins disker og tilstand på en måte som forhindrer andre enn VM- eller leietakeradministratorer fra å starte VM eller få tilgang til innholdet. Funksjonen fungerer ved å dra nytte av en ny Windows Server-funksjon kalt Host Guardian Service, som har nøklene til kryptering og dekryptering av skjermede virtuelle maskiner.

Host Guardian Service sjekker om Hyper-V-verten er autorisert eller “attestert” til å kjøre den virtuelle maskinen. Det er riktig - administratorer er i stand til å begrense skjermede virtuelle maskiner, så de vil bare kjøre på bestemte verter som består attestertesten. Dette betyr at hvis en useriøs administrator skulle kopiere en skjermet VM til en flash-stasjon, ville VM-kopien være ubrukelig for administratoren. VM vil ikke kunne kjøre utenfor organisasjonen, og innholdet vil være utilgjengelig fordi nøklene som trengs for å dekryptere VM er beskyttet av Host Guardian Service.

Host Guardian Service støtter to forskjellige attesteringsmodi, kalt admin-klarert attest og TPM-klarert attest. Admin-klarert attest er den enkleste av de to modusene å distribuere, men ikke så sikker som TPM-klarert attest. Administrator-pålitelige verter er basert på medlemskap i Active Directory-sikkerhetsgrupper, mens verter som er betrodd TPM er basert på TPM-identitet og til og med oppstart- og kodeintegritetskontroller.

I tillegg til den mer komplekse konfigurasjonsprosessen, har TPM-pålitelig attestasjon noen maskinvarekrav. Vokte verter må støtte TPM 2.0 og UEFI 2.3.1 eller høyere. I motsetning til dette har ikke administrator-klarert attestasjon noen vesentlige maskinvarekrav utover de som er nødvendige for å kjøre Hyper-V.

Selv om det meste av mediedekningen knyttet til Hyper-V 2016-sikkerhet har fokusert på skjermede virtuelle maskiner, har Microsoft introdusert andre sikkerhetsforbedringer. For eksempel støtter Hyper-V nå Secure Boot for noen Linux-virtuelle maskiner. I følge Microsoft inkluderer de støttede Linux-versjonene Ubuntu 14.04 og nyere, Suse Linux Enterprise Server 12 og senere, Red Hat Enterprise Linux 7.0 og nyere, og CentOS 7.0 og nyere.

En annen betydelig sikkerhetsforbedring er støtte for BitLocker-basert OS-diskkryptering i generasjon 1 virtuelle maskiner. Denne spesielle sikkerhetsforbedringen har ikke fått særlig oppmerksomhet fra pressen, men den er viktig på grunn av antall generasjons 1-maskiner som kjører i produksjonsmiljøer. Tross alt støttes generasjons 2 virtuelle maskiner bare for bruk med spesifikke gjesteoperativsystemer. Selv om listen over støttede gjesteoperativsystemer har vokst gjennom årene, fortsetter noen Linux-distribusjoner som tenkelig kan kjøres på generasjons 2 virtuelle maskiner, på generasjon 1 virtuelle maskiner, ganske enkelt på grunn av manglende evne til å endre VM-versjonen.

Windows-containere

En av de viktigste funksjonene som ble introdusert i Windows Server 2016 er containere, hvorav det er to typer. Windows Server-containere deler en OS-kjerne med verten (og andre containere som kan kjøre på verten), mens Hyper-V-containere bruker hypervisor og et lett gjest OS (Windows Server Core eller Nano Server) for å gi et høyere nivå av isolasjon. Tenk på Hyper-V-containere som lette virtuelle maskiner.

Til dags dato har jeg brukt litt tid på å eksperimentere med begge typer containere. Min vurdering: Selv om containere ser ut til å fungere som annonsert, er det en bratt læringskurve knyttet til bruk av dem. Containere må opprettes og administreres på kommandolinjen (i motsetning til å bruke Hyper-V Manager) via Docker-kommandosyntaks, som er veldig forskjellig fra andre kommandolinjemiljøer som PowerShell.

Jeg tror containere vil vise seg å være relevante for Windows-administratorer, men jeg anbefaler på det sterkeste å bruke tid i et laboratoriemiljø på å bli vant til Docker og dens mange nyanser før du distribuerer containere i produksjonen.

Ytelsesspørsmål

I et forsøk på å teste ytelsen til Windows Server 2016, tok jeg en ny server på nettet, og kjørte en ren installasjon av Windows Server 2012 R2 Hyper-V. Denne serveren var utstyrt med avansert, aldrende maskinvare, men gitt målet var å kontrollere relativ ytelse, var ikke moderne maskinvare virkelig nødvendig.

Med den nye Windows Server 2012 R2 Hyper-V-serveren på nettet opprettet jeg en generasjon 2 virtuell maskin som kjører Windows Server 2012 R2. Både verts- og gjesteoperativsystemene ble fullstendig lappet, og test-VM min var den eneste virtuelle maskinen som var til stede på verten.

Når det nye gjest OS var i gang, installerte jeg Sandra 2016 i den virtuelle maskinen for å måle ytelsen til den virtuelle maskinen. Jeg var først og fremst interessert i CPU, lagring, minne og nettverksytelse.

Med et basissett av beregninger i hånden oppgraderte jeg Hyper-V-verten til Windows Server 2016. Microsoft fraråder oppgraderinger på stedet, men jeg valgte å utføre en i stedet for en ren installasjon for å holde testmiljøet mitt like konsistent som mulig på tvers av alle testene.

Da oppgraderingen var fullført, startet jeg opp VM, som fremdeles kjørte Windows Server 2012 R2. Deretter prøvde jeg å oppgradere Hyper-V Integration Services på VM, men Microsoft har fjernet muligheten til å gjøre dette manuelt. Integrasjonstjenestene leveres nå via Windows Update.

Etter fullstendig lapping av Windows Server 2016 Hyper-V Host, gjentok jeg referansetestene for å se om den nye versjonen av Hyper-V ville gi noen ytelsesgevinster. Det motsatte viste seg å være sant. Min VM så en betydelig reduksjon i ytelsen.

For den siste testen min, utførte jeg en oppgradering av gjesteoperativsystemet til Windows Server 2016. Jeg lappet det nye gjeste-operativsystemet fullt ut og gjentok referansetestene mine en siste gang. Denne gangen forbedret VM-ytelsen meg stort sett, men ikke helt til nivået på den opprinnelige Windows Server 2012 R2 VM som kjører på en Windows Server 2012 R2-vert, og noen få tester så ytelsen ytterligere redusert.

Jeg har listet opp beregningene som jeg har satt mål for, og resultatene nedenfor.

I henhold til Sandra-testene, presterte ikke Windows Server 2012 R2 VM like bra på Windows Server 2016 Hyper-V som den gjorde på den forrige Hyper-V-versjonen. Jeg kjørte hvert referanseindeks flere ganger (mens verten var inaktiv) i et forsøk på å sikre at beregningene mine var nøyaktige. Den virtuelle maskinens ytelse forbedret seg når gjest OS ble oppgradert til Windows Server 2016, men ikke til nivået på Windows Server 2012 R2-gjesten som kjører på Windows Server 2012 R2 Hyper-V.

Naturligvis bør du ta disse (og andre) referanseresultatene med et saltkorn. Referanser reflekterer ikke alltid virkeligheten, og disse funnene representerer bare ett sett tester på en maskinvarekonfigurasjon. Videre er jeg villig til å gi Microsoft fordelen av tvil fordi beregningene ble fanget på en vert som hadde blitt oppgradert fra en tidligere Windows Server-versjon, i stedet for en vert som kjører en ren installasjon.

Den eneste meningsfulle testen av Windows Server 2016 Hyper-V-ytelsen vil være dine faktiske arbeidsbelastninger på din faktiske maskinvare. Gitt resultatene av Sandra-testene, vil du se nøye på ytelsen til Hyper-V 2016.