Hvis en virksomhet allerede har et SAN utplassert i deres miljø, er det bare fornuftig å bruke den som hovedlagringsenheten for alle dine servere hvis dette er mulig. Og det har vært mulig siden Windows 2000 Server fordi Microsoft har designet denne og senere versjoner av Windows Server for å kunne starte opp operativsystemet direkte fra SAN i stedet for å måtte bruke en lokal disk inni eller festet til serveren.
< p> I oppstart fra SAN tilnærming, ligger operativsystemet på SAN, ikke på en disk inne eller direkte knyttet til serveren. En vertsbussadapter (HBA) inne i serveren er konfigurert slik at serveren kan finne riktig OS bildet for å starte opp fra på vedlagte SAN. Med andre ord, er HBA på serveren er konfigurert til å bruke en bestemt logisk enhetsnummer (LUN) på SAN.

Fordeler med oppstart fra SAN

Starter Windows servere direkte fra SAN har andre fordeler i tillegg til å eliminere behovet for å kjøpe disker for hver server i ditt miljø. For eksempel kan du nå bruke diskløse bladservere som kan passe inn i stativer i datasenteret. Bladservere generelt tar mindre plass og bruker mindre strøm enn tårnservere. Bladservere kan enten være mindre eller dyrere enn sammenlignbare tårn imidlertid avhengig av leverandøren du skaffe fra.

Boot fra SAN gjør det også lettere å sikre kontinuitet i tilfelle en katastrofe. Ved ganske enkelt å kopiere lagrings fra SAN i ditt datasenter til et annet SAN på et eksternt område, kan du sikre at du vil være i stand til å gjenopprette driften raskt dersom noe skulle skje med din primære nettstedet.

Boot fra SAN gjør også det enklere å administrere operativsystembilder for dine servere. Det er fordi alle system volumene er plassert på ett sted i stedet for å bli fordelt over flere systemer hele nettstedet. Dette betyr også at du kan distribuere nye OS-bilder raskere, noe som kan gjøre det mulig for bedriften å skalere opp raskere å bo på linje med markedet.

Boot fra SAN kan også øke tilgjengeligheten og ytelsen til servere ved hjelp redundante HBA, brytere, kabler og kontrollerporter på SAN. Windows Server 2008 R23 og inkluderer senere støtte for Multipath I /O (MPIO), noe som gir redundante fysisk sti komponenter for å bli brukt til å opprette flere logiske stier mellom serveren og SAN.

Oppstart Hyper-V verter fra et SAN

Du kan definitivt konfigurere Hyper-V vertene å starte opp fra SAN i stedet for fra lokal lagring. Faktisk er det ingen spesielle krav til gjennomføring oppstart fra SAN med Windows-servere som kjører Hyper-V-rollen i motsetning til servere som ikke har denne rollen installert. Likevel servere i datasenteret kan eller ikke kan støtte oppstart fra SAN, så ikke hoppe på bandwagon ennå. Å avgjøre om en bestemt server system kan med hell starte en bestemt Windows Server operativsystemet fra SAN, må du gjøre to ting:

Kontroller om serversystemet er sertifisert for den aktuelle Windows Server-operativsystemet. Du kan finne ut av dette ved å søke på Windows Server Catalog for systemet. Se http://windowsservercatalog.com.

Dersom systemet er sertifisert i Windows Server Catalog og leverandøren har bekreftet at den støtter oppstart fra SAN, kan du fortsette med å konfigurere systemet til å starte opp fra SAN. Hvordan gjør du dette? Det avhenger av systemer og SAN involvert, og generelt må du snakke med både systemleverandøren og SAN leverandøren for å finne ut hvilke konkrete skritt du må konfigurere systemet ditt, HBA du har installert på systemet ditt, og SAN-infrastruktur

For eksempel walkthrough bruke en Fibre Channel SAN, en eldre Emulex HBA, og et eldre operativsystem (Windows Server 2008 R2) kan du se whitepaper tittelen "Windows Boot fra SAN &ndash.; En Executive Oversikt og detaljerte tekniske forskriftene for System Administrator "som er tilgjengelig fra Microsoft Download Center.

Dette whitepaper ble opprinnelig skrevet for Windows Server 2003 og ble senere oppdatert for Windows Server 2008 R2. Hvorfor har ikke det blitt oppdatert for Windows Server 2012 R2? Sannsynligvis fordi gjennomføre oppstart fra SAN er i utgangspunktet en per-leverandør prosedyre.

En viktig ting å huske på, men når du konfigurerer boot fra SAN er å ha bare én lagring banen konfigurert under operativsystemet provisioning scenen. Så når operativsystemet har blitt utplassert på bladserver kan du bruke MPIO å konfigurere en sekundær lagring bane for redundans formål.

Starter virtuelle maskiner fra en SAN

OK, slik at du kan lagre roten delingen av en Hyper-V host på en LUN av en SAN å starte verts direkte fra SAN. Hva med virtuelle maskiner som kjører på Hyper-V host? Kan du starte en virtuell maskin fra et SAN?

Ja og nei, men stort sett ingen. Først kan du ikke starte en virtuell maskin direkte fra et operativsystem på en LUN fordi den virtuelle Fibre Channel-adapter inkludert i Windows Server 2012 og senere ikke inneholde nødvendig boot kode for å gjøre dette skje. Virtual Fibre Channel er en funksjon som ble introdusert i Windows Server 2012 som gjør at virtuelle maskiner for å få direkte tilgang til Fibre Channel lagrings. Virtual Fibre Channel fungerer med FC HBA og FCoE konvergerte nettverksadaptere. Det er en flott funksjon, men den støtter ikke starte den virtuelle maskinen fra SAN

Men det er to måter du kan starte opp en virtuell maskin fra et SAN.

Disse metodene er ikke anbefalt men fordi de innebærer å opprette og administrere så mange LUN som du har virtuelle maskiner. Så hvis du har dusinvis av virtuelle maskiner som kjører på Hyper-V host, vil du trenger for å administrere dusinvis av LUNene på SAN. Det er bare ikke en god idé fordi SAN er ment å forenkle lagringsadministrasjon ved å sentralisere lagrings, de er ikke ment for å gjøre lagring mer komplisert i miljøet.

En mye bedre tilnærming ville være å sette oppstartsvolum av dine virtuelle maskiner på den delte volumet av en rekke klynge og bare plassere datamengder velger virtuelle maskiner på SAN og bruke virtuelle FC å tillate dem å få tilgang til datamengder.

Revisiting boot fra SAN

Så boot fra SAN bør generelt bare brukes til å starte din Hyper-V vertene fra SAN og ikke for å starte den virtuelle maskiner som kjører på disse vertene. Og boot fra SAN kan gi noen klare fordeler for virksomheten som vi tidligere beskrevet i denne artikkelen.

Men starter opp Hyper-V vertene fra et SAN egentlig en god idé?

Kanskje. Det viktige spørsmål å stille deg selv er hvorfor du ønsker å starte din Hyper-V vertene fra SAN. Er det drevet av selskapets politikk? Ved rene kostnadsbetraktninger? Ved behov for større ytelse eller tilgjengelighet?

Bare fordi du allerede har en SAN utplassert betyr ikke at du trenger å bruke den. Faktisk, hvis SAN har bare harddisker og ingen SSD så kan du lage dine eksisterende Hyper-V verter lynrask ved å erstatte HDD som deres OS volum bor med SSD. Og siden enterprise-klassen SSD er raskt fallende i pris, mens dramatisk økende i kapasitet, kan du gjøre en slik erstatning billig.

På den annen side kan det være bedre og nesten like billig å oppgradere noen av de HDD i din SAN til SSD og deretter bruke SSD for LUNene dine Hyper-V vertene vil starte opp fra. På den måten kan du likevel sentralt administrere lagring samtidig få ytelsen fordel som bruker SSD kan gi.

En annen boot fra SAN betraktning (og dette er kort omtalt i whitepaper nevnt tidligere) er at implementering boot fra SAN kan innebære noen tøffe valg. En av de tøffeste av disse er hvor du skal plassere pagefile av serverne som vil bli oppstart fra SAN. Generelt kan du få best mulig ytelse ved å plassere pagefile på en lokal disk i stedet for et LUN på SAN. Dette betyr at bladene vil trenge minst disken (HDD eller SSD) i dem, og avhengig av leverandøren dette kan drive opp kostnadene betraktelig.

Også tenke på hva som kan skje når SAN leverandøren bestemmer seg for å frigjøre oppdatert firmware for SAN. Du må kanskje ta ned alle dine servere mens du oppdaterer din SAN firmware, og hvis noe går galt med firmware-oppdateringen kan du ikke være i stand til å starte noen av dine servere.

På den annen side, er det noen spesielle brukstilfeller hvor boot fra SAN kan være en gudegave for bedrifter. For eksempel, la oss si en av dine serversystemer plutselig dør. Ved bruk av SAN profilen din død server til et system som ble holdt i reserve for slike hendelser, kan reserve systemet umiddelbart anta identiteten og arbeidsmengden på den mislykkede server, noe som resulterer i minimal avbrudd for din virksomhet. Selvfølgelig kan failover clustering gi lignende tilgjengelighet fordeler, men det kan være situasjoner der SAN tilnærming er enklere eller mer kostnadseffektivt for deg enn clustering tilnærming.

Eller la oss si at du har brukt et serversystem at støvler fra SAN for et bestemt formål, og nå du ønsker å bruke som system til et annet formål. Ved ganske enkelt å endre oppstarts LUN systemet er konfigurert til å starte opp fra, identiteten til de endringene server, og systemet kan brukes på nytt.

Så er det spørsmål om overvåking lagring utnyttelse for servere. Boot fra SAN lar deg bruke leverandørens programvare for å gjøre dette. Hvis du bruker lokal (direkte vedlagt) lagring i stedet for Hyper-V verter, må du overvåke lagring over et bredt spekter av systemer i datasenteret og for at du trenger en annen overvåking løsning som Microsoft Operations Manager, IBM Tivoli , HP Openview, og så videre. Slike løsninger koster penger, men hvis du allerede har en av dem du kan bruke det uten å pådra seg ytterligere kostnader.

Enten å gjennomføre oppstart fra SAN for Hyper-V vertene er Konklusjon
ikke en enkelt spørsmål. Mange forskjellige ting må tas i betraktning før du tar en avgjørelse om dette, og forhåpentligvis denne artikkelen har gitt deg noen måter du kan få din planprosessen startet. Anmeldelser