Innledning

En viktig faktor når du planlegger lagringsplass for nye Hyper-V verter (eller ny lagringsplass for eksisterende verter) er spørsmålet om sikkerhet. Faktum i saken er at all programvare har hull i den, fordi programvaren er basert på tillit grenser, og det må være noen mekanisme for å krysse disse grensene. Undergraving slik mekanisme utsetter vertskap for mulig malware infeksjon eller utnyttelser som kan gjøre det mulig for en angriper å ta kontroll over verten og derfra lansere et angrep på hele nettverket og bringe virksomheten i kne. ​​

Det er viktig derfor å alltid følge beste praksis for å sikre sikkerheten til Hyper-V verter og de VMs som kjører på dem - de aller VMs som din bedrift er avhengig av. La oss derfor vurdere noen av trinnene, både generelt og lagring-relatert, at du alltid bør følge når du planlegger lagringsplass for Hyper-V verter i særdeleshet og planlegging vert utplassering generelt. Det er også viktig å følge beste praksis for å opprettholde vertssystemer for å sikre at planlagt eller ikke planlagt vedlikehold ikke forårsaker avbrudd i kontinuiteten i virksomheten din. Til slutt er det viktig før du implementerer nye lagrings at den vil fungere som forventet å støtte behovene til VM arbeidsoppgaver.

pålitelige kilder

Enhetsdrivere er klarert programvare som i utgangspunktet kan gjøre noe når de er montert på en vert. Dette inkluderer ikke bare lagringsdrivere, men også nettverksdrivere og eventuelle andre drivere på verten. Noen driver på verten kan potensielt snappe data i VM data banen og i utgangspunktet gjøre noe det vil med VM. Dette er en generell betraktning som gjelder for alle versjoner av Hyper-V og også til andre hypervisors som de fra VMware, Xen, KVM og så videre.

Så bunnlinjen er, må du ha en pålitelig kilde for lagring drivere (og eventuelle andre drivere) du skal installere på vertene. Faktisk er beste praksis med Hyper-V til å ikke installere noen annen programvare (inkludert andre serverroller) på vertene. Du bør også planlegge på distribusjon av dine Hyper-V vertene i minimale konfigurasjoner, for eksempel en Server Core-installasjonen eller en Minimal Server Interface installasjon, ikke en full installasjon.

drivere Oppdatere enhets

Oppdatering enhet drivere på produksjonsservere kan være en vanskelig ting. Hvor mange av oss sysadmins har holdt pusten mens du gjør det, og da pustet lang sukk av lettelse da alt fortsatt fungerte fint etterpå? Det siste du ønsker å gjøre er å bryte en produksjonsserver ved å oppdatere en driver på den.

Dette gjelder også drivere for lagringsenheter. Jeg har hørt om tilfeller der en admin oppdatert en driver for en lagringsenhet som brukes av VMs kjører på en Hyper-V host og VMs kunne ikke startes på nytt igjen etterpå. Du må planlegge å teste grundig nye enhetsdrivere på lab vertene før du kaster dem ut til dine produksjons vertene.

Patching verter

Det samme råd om testing i et laboratorium gjelder patching produksjons verter. For eksempel, jeg vet om en historie der admin lappet en produksjon vert kjører Windows Server 2012 som hadde Fibre Channel-vertsbussadaptere (HBA) for tilkobling med en Storage Area Network (SAN). Mystisk, når lappene ble påført de HBA sluttet å virke ble vist som ikke støttes i Hyper-V Manager. Med andre ord, patching vertsoperativsystemet forårsaket SAN-tilkobling til å mislykkes som brakte ned hele VMs kjører på verten. Heldigvis fjerne og deretter installere driverne HBA restaurert SAN-tilkobling, men den moralske her er klar: plan for å teste eventuelle oppdateringer for vertene i laboratoriet før du lappe vertene i produksjonsmiljøet

iSCSI-lagring for vertene.

Hvis Hyper-V host bruker iSCSI disker (dvs. fjernblokkbasert lagring) deretter under planleggingen av distribusjonen du trenger for å sikre at nettverkskonfigurasjonen av verten vil gi tilstrekkelig båndbredde for hver iSCSI-initiator . Hvis du bestemmer deg for at en enkelt fysisk nettverkskort (NIC) kan gi tilstrekkelig båndbredde for vertens lagring trafikk, så gå med det som det er den enkleste tilnærmingen. Men dersom du trenger mer båndbredde for lagring trafikk, kan du bruke et par virtuelle nettverkskort (vNICs) som har multipath I /O (MPIO) mulig lagvis oppå din fysiske NIC team. Fordelen med å bruke MPIO i et slikt scenario er at det muliggjør multipleksing av vertens lagringstrafikk i flere TCP-strømmer så teaming lag kan laste-balansere trafikk over flere fysiske nettverkskort.

Pass-through disker

Når du planlegger lagringsplass for Hyper-V verter som kjører Windows Server 2012 eller Windows Server 2012 R2, bør du unngå å bruke pass-through disker for noen VM-lagringsformål. Det er på grunn av fire grunner. Først er ytelsen til faste VHDer (og spesielt VHDXs) i Windows Server 2012 /2012R2 nå så god som resultatene for pass-through disker i tidligere versjoner av Windows Server. For det andre vil en rekke nyttige nye funksjonene i Windows Server 2012 /R2 ikke fungerer med pass-through disker inkludert Hyper-V Replica og VSS backup på vertsoperativsystemet. I tillegg, hvis et VM er ved hjelp av pass-through-plater og deretter sin bevegelighet er begrenset til å bli flyttet rundt på den samme gruppen når delt lagring anvendes. Og du kan ikke lett endre størrelsen på et pass-through disk måten du kan en virtuell disk. Tredje, pass-through disker legge ekstra administrativ kompleksitet siden du skal håndtere direkte med SAN LUN i stedet for gjennom abstraksjon lag av virtuelle disker. Og for det fjerde, ved hjelp av pass-through disker betyr sløse lagringskapasitet siden en gjennomgangs disk er utelukkende eies av en enkelt VM.

Sikkerhetskopier

Det er i utgangspunktet ingen grense for hvor mange disker en Hyper -V klynge kan konfigureres til å bruke, og dette inkluderer både CSV og ikke-CSV disker. Dette gir mye fleksibilitet i utformingen av lagringsarkitektur av Hyper-V host klynger.

Generelt bør du vurdere å bruke flere mindre CSVs i stedet for færre større funn for Hyper-V host klynge. Begrunnelsen for forslaget er at hvis diskplass på en liten CSV fylles opp, vil bare noen få VMs (de få som bruker CSV) bli påvirket i stedet for mange.

er en enda større hensyn imidlertid sikkerhetskopier . Det er som regel raskere å sikkerhetskopiere din vert klynge hvis du har mye mindre CSVs spredt over nodene for ditt klyngen. Det er fordi VSS sikkerhetskopier kan parallelliserte. En generell anbefaling for planlegging CSV lagring for en Hyper-V host klyngen er å ha en CSV per node av klyngen.

Til slutt, hvis du trenger å sikkerhetskopiere Hyper-V host klynge da være oppmerksom på at Windows Server Backup funksjon som inkluderes i Windows Server 2012 /2012R2 har kun begrenset støtte for CSVs (for mer informasjon se denne linken). Viktigst, støtter Windows Server Backup bare filbasert sikkerhetskopiering av CSV volumer; den støtter ikke VM-baserte backup. Så i stedet for Windows Server Backup, bør du virkelig bruke System Center Data Protection Manager eller tilsvarende tredjeparts Hyper-V backup produktet for sikkerhetskopiering av verts klynger. Men hvis Hyper-V verter er ikke-gruppert, vil Windows Server Backup lar deg velge et VM når du konfigurerer din tidsplan. Anmeldelser