Microsoft Windows Server 2008 White Paper

Windows Boot from SAN An Executive Overview and Detailed

Technical Instructions for the System Administrator
Microsoft Corporation
Published: July 200
Abstract
Bootin from a storae area networ! "SAN#$ rather than from local dis!s on individual servers$ can ena%le
orani&ations to consolidate their IT resources$ minimi&e their e'ui(ment costs$ and reali&e considera%le
manaement %enefits %y centrali&in the %oot (rocess)
This white (a(er covers %oot from SAN technoloy as de(loyed with *icrosoft
+
Windows Server ,--. and
*icrosoft
+
Windows Server ,--/) It descri%es the advantaes and com(lexities of the technoloy$ and a
num%er of !ey SAN %oot de(loyment scenarios)
Microsoft Windows Server 2008 White Paper
!he infor"ation contained in this docu"ent represents the current
view of Microsoft Corporation on the issues discussed as of the
date of publication# $ecause Microsoft "ust respond to chan%in%
"ar&et conditions' it should not be interpreted to be a co""it"ent
on the part of Microsoft' and Microsoft cannot %uarantee the
accuracy of any infor"ation presented after the date of publication#
!his docu"ent is for infor"ational purposes only# M(C)*S*+!
M,-.S /* W,)),/!(.S' .0P).SS *) (MP1(.2' ,S !* !3.
(/+*)M,!(*/ (/ !3(S 2*C4M./!#
Co"plyin% with all applicable copyri%ht laws is the responsibility of
the user# Without li"itin% the ri%hts under copyri%ht' no part of this
docu"ent "ay be reproduced' stored in or introduced into a
retrieval syste"' or trans"itted in any for" or by any "eans
5electronic' "echanical' photocopyin%' recordin%' or otherwise6' or
for any purpose' without the e7press written per"ission of Microsoft
Corporation#
Microsoft "ay have patents' patent applications' trade"ar&s'
copyri%hts' or other intellectual property ri%hts coverin% sub8ect
"atter in this docu"ent# .7cept as e7pressly provided in any
written license a%ree"ent fro" Microsoft' the furnishin% of this
docu"ent does not %ive you any license to these patents'
trade"ar&s' copyri%hts' or other intellectual property#
9 200 Microsoft Corporation# ,ll ri%hts reserved#
Microsoft' Windows' Windows Server and Windows :ista are either
re%istered trade"ar&s or trade"ar&s of Microsoft Corporation in the
4nited States and;or other countries#
!he na"es of actual co"panies and products "entioned herein
"ay be the trade"ar&s of their respective owners#
Contents
Contents.......................................................................................................................................... 1
Introduction..................................................................................................................................... 2
Key Benefits of Boot from SAN .................................................................................................... 3
The Boot Process: An !er!ie" .................................................................................................. #
$C SAN Boot % Conce&ts and Confi'urations.............................................................................. (
Crash )um& $i*e Creation.............................................................................................................. +
C*uster Confi'uration..................................................................................................................... ,
Setu& Boot from SAN..................................................................................................................... -
Best Practices............................................................................................................................... 1+
Troub*eshootin' Boot from $C SAN ......................................................................................... 1-
Current .imitations to /indo"s Boot from SAN.......................................................................22
Additiona* 0esources................................................................................................................... 23
Summary ...................................................................................................................................... 2#
Windows Boot from 0i%re 1hannel SAN 2
Introduction
Today3s data centers have lare scale server de(loyments and an ever increasin challene for IT
administrators to effectively manae and control costs) One !ey way is to reduce the hardware
foot(rint %y re(lacin lare servers with hihly com(act rac!4mounta%le forms)
The densest of these forms is the %lade server$ which uses resources "such as device interfaces
and (ower su((lies# that are shared amon the %lade servers in an enclosure) In addition to
reducin the hardware$ electrical and s'uare footae costs$ %lade servers are hot (lua%le and
use sim(lified ca%le confiurations) Blade servers are also easier to manae since a sinle server
can manae all of the other servers in the same enclosure) While some %lade servers have
internal dis!s$ they tend to have lower (erformance and ca(acity than S1SI dis!s) This is hel(in
drive ado(tion of dis!less %lade servers that are used in com%ination with networ!ed storae)
Boot from SAN leads to reater O5E6 savins %y (rovidin %etter o(tions for administratin and
maintainin datacenter de(loyments) Nevertheless$ it leads to increased 1A5E6 savins %y
movin towards storae consolidation in a SAN rather havin a lot of local server storae)
Windows Boot from 0i%re 1hannel SAN ,
Key Benefits of Boot from SAN
Boot from SAN hel(s ena%le all of the 78AS9 advantaes of fa%ric connectivity 8edundancy$
Availa%ility$ Servicea%ility) The !ey %enefits are:
0educe Ser!er $oot&rints
Boot from SAN alleviates the necessity for each server to have its own direct4attached dis!$
eliminatin internal dis!s as a (otential (oint of failure) Thin dis!less servers also ta!e u( less
facility s(ace$ re'uire less (ower$ and are enerally less ex(ensive %ecause they have fewer
hardware com(onents)
Centra*i1ed Ima'e 2ana'ement
When o(eratin system imaes are stored on networ!ed dis!s$ all u(rades and fixes can %e
manaed at a centrali&ed location) 1hanes made to dis!s in a storae array are readily
accessi%le %y each server)
)isaster and Ser!er $ai*ure 0eco!ery
All the %oot information and (roduction data stored on a local SAN can %e re(licated to a SAN at a
remote disaster recovery site) If a disaster destroys functionality of the servers at the (rimary site$
the remote site can ta!e over with minimal downtime)
8ecovery from server failures is sim(lified in a SAN environment) With the hel( of sna(shots$
mirrors of a failed server can %e recovered 'uic!ly %y %ootin from the oriinal co(y of its imae)
As a result$ %oot from SAN can reatly reduce the time re'uired for server recovery)
3i'h A!ai*abi*ity
A ty(ical data center is hihly redundant in nature 4 redundant (aths$ redundant dis!s and
redundant storae controllers) When o(eratin system imaes are stored on dis!s in the SAN$ it
su((orts hih availa%ility and eliminates the (otential for mechanical failure of a local dis!)
0a&id 0ede&*oyment
Businesses that ex(erience tem(orary hih (roduction wor!loads can ta!e advantae of SAN
technoloies to clone the %oot imae and distri%ute the imae to multi(le servers for ra(id
de(loyment) Such servers may only need to %e in (roduction for hours or days and can %e readily
removed when the (roduction need has %een met) ;ihly efficient de(loyment of %oot imaes
ma!es tem(orary server usae a cost effective endeavor)
4reen
When %oot imaes are stored on a SAN$ it ena%les the server not to have any local s(innin
media) Boot from SAN can (rovide reater (ower efficiency and hel( larely towards datacenter
reen initiatives)
Windows Boot from 0i%re 1hannel SAN /
The Boot Process: An !er!ie"
The %oot (rocess "(reviously !nown as %ootin or %ootstra((in# is the iterative loadin of the
installed o(eratin system code from the %oot device into com(uter memory after the com(uter is
(owered on) The BIOS "Basic In(ut < Out(ut System# is the most %asic code and is loaded first
from the system firmware after 5OST initiali&ation (rocess) It initiali&es the com(uter hardware
and reads in code that loads the o(eratin system$ com(letes hardware setu( and (roduces a fully
functional o(eratin system residin in memory) See the A((endix for a more detailed descri(tion
of the %oot (rocess)
The %oot (rocess can occur from a direct attached dis!$ over a local area networ!$ or from
networ!ed storae) In all cases$ a critical ste( to a successful %oot is locatin the %oot dis!) The
device controllin that (rocess de(ends on the %oot ty(e)
.oca* Boot
The most common %ootin a((roach is to %oot from a direct4attached dis!) The server BIOS
locates the S1SI ada(ter BIOS$ which contains the instructions that allow the server to determine
which of the internal dis!s is the %oot device)
Boot from SAN
Bootin from SAN (rovides num%er of advantaes
8educe OS imae foot (rints
Ena%le centrali&ed imae manaement
Ena%le ra(id de(loyment scenarios
5rovide seamless disaster recovery o(tions
All of the a%ove !ey %enefits of SAN are discussed in the followin section of this white (a(er)
With %oot from SAN$ the %oot dis! resides on the storae area networ! "SAN#$ not locally on the
server) The server communicates with the SAN throuh a host %us ada(ter ";BA#) The ;BA3s
BIOS contain the instructions that ena%le the server to find the %oot dis!)
Boot from SAN offers the advantaes of reduced e'ui(ment costs) It also (rovides a num%er of
other advantaes$ includin reduced server maintenance$ im(roved security and %etter
(erformance) These factors are addressed in detail in the next section)
Windows Boot from 0i%re 1hannel SAN =
$C SAN Boot % Conce&ts and Confi'urations
IT administrators can ena%le servers to %oot from SAN %y confiurin the server and the
underlyin hardware com(onents) After (ower on self test "5OST#$ the server hardware
com(onent fetches the %oot %loc! from the device that is desinated as the %oot device in the
hardware BOIS settins) Once the hardware detects the %oot device$ it follows the reular %oot
(rocess as ex(lained in the A((endix)
The order in which drivers are loaded is different for local %oot and SAN %oot) 0or 01 SAN %oot
with *ulti45ath I<O "*5IO#$ the Device S(ecific *odule "DS*# driver ets loaded very early in the
%oot (rocess so it can hel( manae the (aths to the storae devices)
Sin'*e &ath Confi'uration
The sim(lest SAN confiuration is shown in 0iure 2$ two dis!less servers$ each with a sinle ;BA
connected to 0i%er 1hannel storae) This confiuration does not em(loy redundant com(onents$
which is a re'uirement for hih availa%ility servers) 0or %oot from SAN with Windows$ each server
must have sole access to its own dedicated %oot device)
$i'ure 1. Basic boot from SAN Confi'uration
Windows Boot from 0i%re 1hannel SAN >
2u*ti&ath Confi'uration
The confiuration shown in 0iure , (rovides hih availa%ility and hih (erformance with the
addition of redundant ;BAs$ ca%lin$ switches$ and array controller (orts)
$i'ure 2. $u**y 0edundant Boot from SAN Confi'uration
Windows Boot from 0i%re 1hannel SAN ?
Crash )um& $i*e Creation
In the event of a system or !ernel software com(onent failure$ a crash dum( file is created to aid
with dianosis of the failure) The crash dum( file must %e written to the system drive "1:#) With
%oot from SAN$ the crash dum( stac! and crash dum( file location is s(ecific to the ;BA (ath from
which the system is %ooted) This can create a (ro%lem with multi(athin solutions$ since the crash
dum( stac! does not have multi(ath drivers availa%le)
@sin the exam(le iven in 0iure , with Windows Server ,--/$ if the %oot (ath and crash dum(
file is throuh ;BA A and that ada(ter fails$ the system is no loner a%le to write the crash dum(
file) With Windows Server ,--.$ the crash dum( drivers are enhanced to ma!e them aware of all
the current availa%le (aths) Even with %oot (ath failure$ crash dum( file creation succeeds throuh
the other availa%le (aths)
Windows Boot from 0i%re 1hannel SAN A
C*uster Confi'uration
When im(lementin a *icrosoft 1luster Server "*S1S# or Windows 0ailover 1luster "W01#$ the
cluster servers re'uire the underlyin storae device to su((ort S1SI reserve<release or (ersistent
reservation command sets) 0or Windows Server ,--/$ cluster servers use S1SI reserve<release)
0or Windows Server ,--.$ S514/ 5ersistent 8eserve "58# IN and O@T commands are used to
reister and reserve cluster resources)
In a clustered environment$ the nodes must %e confiured correctly with each node havin sole
access to its %oot B@N and then to shared B@NS) This can %e done usin B@N &onin and
mas!in$ or B@N mas!in alone$ as descri%ed %elow:
5onin' and 2as6in'. This is a two ste( (rocess) 0irst$ a((ly a((ro(riate &onin to the
server and storae (orts) Second$ use mas!in to ensure that each server has sole
access to the a((ro(riate %oot B@N) When servers share non4%oot B@Ns$ the non4%oot
B@Ns must %e unmas!ed to all nodes in the cluster) If the storae array is used %y
additional shared clusters$ use &onin and mas!in to ensure that B@Ns used %y the
cluster are only availa%le to nodes inside the cluster)
2as6in' n*y. With this method$ all of the initiator (orts have access to all of the taret
(orts) B@N mas!in is used ensure that a((ro(riate B@Ns are unmas!ed for each initiator
(ort)
Once &onin and<or mas!in are com(lete$ install or confiure the clusterin software)
0or Windows Server ,--/$ it is recommended that the %oot B@N should %e on a se(arate S1SI
%us from the shared B@Ns) If all of the B@Ns are confiured with the same S1SI %us$ any %us4
level resets can cause disru(tion to the %oot B@N$ (otentially affectin (ain I<O and resultin in
timeouts and system crashes) With Windows Server ,--.$ there is no restriction 4 the %oot B@N
and shared B@Ns can share the same %us<(ath)
Windows Boot from 0i%re 1hannel SAN .
Setu& Boot from SAN
Key 0e7uirements
A !ey to effective de(loyment of %oot from SAN$ from the most %asic to(oloy to a com(lex
enter(rise confiuration$ is to ensure that %oth software and hardware com(onents are installed
accordin to s(ecified vendor re'uirements) This section outlines the underlyin re'uirements)
Ser!ers
If the server has %een in (roduction$ ensure that all dis!s are %ac!ed u( %efore connectin the
server to the SAN)
3BAs
8ecord the world4wide (ort name "WW5N# and world4wide node name "WWNN# for each ;BA
(rior to installation) The WW5N and WWNN are uni'ue addresses assined %y the
manufacturer and will %e used durin the confiuration (rocess)
Install the ;BA accordin to vendor instructions) Ensure that the ;BA su((orts %oot from
SAN)
Ensure that the ;BA has the correct firmware version installed)
Ensure that the correct version of the ;BA Stor(ort *ini(ort driver is installed) The Stor(ort
driver stac! allows the server to communicate with dis!s in the SAN as if they were local S1SI
dis!s)
Ensure that the ;BA settins are confiured to match all com(onents and follow vendor
recommendations)
Boot Bios
Ensure that the correct %oot BIOS is installed on the ;BA)
Ensure that the ;BA %oot BIOS is ena%led and correctly confiured) The default settin is
ty(ically disa%led) The %oot BIOS should %e ena%led on only one ada(ter (er server)
SAN $abric
Ensure a((ro(riate &onin techni'ues are a((lied)
8efer to the %est (ractices section for more details on redundancy)
Stora'e Array
1reate at least as many B@Ns as servers that will %e confiured for %oot from SAN) Ensure
a((ro(riate mas!in techni'ues are a((lied)
8efer to the %est (ractices section for more details on redundancy)
Basic Setu&
The %asic ste(s to setu( %oot from SAN are:
2) Disa%le and<or disconnect internal hard drives)
,) Allow a sinle (ath to storae when installin the o(eratin system "OS#) 0or multi(le
;BA (ort confiurations$ only one ;BA (ort should %e connected to the SAN durin
installation) The same restriction a((lies to the storae controller (orts)
Windows Boot from 0i%re 1hannel SAN C
/) Ensure that BIOS is ena%led for the ;BA (ort)
=) S(ecify a %oot B@N from the ;BA BIOS confiuration utility)
>) Derify that the ;BA BIOS finds the %oot B@N durin the early stae of the %oot)
?) Install the OS)
A) Add more *5IO (aths from the server after successfully com(letin the OS installation)
.) 1laim the dis!s for multi(ath with the *icrosoft DS* or a vendor4s(ecific DS*)
89am&*e: Confi'urin' 8mu*e9 3BA for Boot from SAN
Emulex ada(ters shi( with @niversal Boot code that is loaded in the ada(ter3s flash memory) The
@niversal Boot code su((orts three system ty(es) The two that are related to Windows are:
x.? BootBIOS 4 x.? and x?= BIOS4%ased (latforms
E0IBoot 4 Intel+ Itanium+ ?=4%it (rocessor (latforms that use the Extensi%le 0irmware
Interface "E0I#
Boot from SAN setu( is initiated %y enterin E1T8BF E or EABTF E while the server is startin)
The correct %oot code "x.? BootBIOS or E0IBoot# is executed and a utility is run to ena%le the
BIOS and s(ecify %oot device B@Ns) Other %oot (arameters can also %e set$ if needed)
@( to . different %oot entries can %e made (er (ort to su((ort scenarios that re'uire multi(le %oot
(aths) As an exam(le$ the system could %e confiured to %oot from a mirror imae if the (rimary
B@N is down)
The followin exam(le is %ased on the x.? BootBIOS and shows the ste(s to ena%le the BIOS
and set the %oot (ath:
2) Enter E1T8BF E or EABTF E while the server is initiali&in) A list of ada(ters on the server is
dis(layed)
Select the ada(ter to %e confiured) In this exam(le$ there is only one ada(ter)
Windows Boot from 0i%re 1hannel SAN 2-
,) Setu( o(tions are dis(layed)
Select , to confiure the ada(terGs (arameters)
/) The ada(ter confiuration menu is dis(layed)
Select 2 to ena%le the BIOS. The default values for all other o(tions should %e satisfactory)
Windows Boot from 0i%re 1hannel SAN 22
=) The next screen shows the BIOS disa%led)
Select 2 to ena%le the BIOS)
>) The BIOS is now ena%led) Enter EEscF twice to return to the main o(tions menu)
Select , to confiure the ada(ter3s (arameters)
?) A list of . %oot devices is shown)
Windows Boot from 0i%re 1hannel SAN 2,
The (rimary %oot device is the first entry shown and is the first %oota%le device) If the first
%oot entry fails due to a hardware error$ the other %oot o(tions will %e used in order) Select 2
to confiure the (rimary %oot device)
A) A scan is done for all (ossi%le %oot devices) If the ;BA is attached to a storae array$ it will %e
dis(layed as shown)
Enter -2 to select the array)
.) A window is dis(layed to enter the startin B@N)
Windows Boot from 0i%re 1hannel SAN 2/
Enter -- to dis(lay the first 2? B@Ns)
Windows Boot from 0i%re 1hannel SAN 2=
C) A listin of the first 2? B@Ns "if availa%le# is shown) The followin exam(le shows two B@Ns
availa%le)
Enter the num%er of the %oot B@N) Entry -2 "B@N :--# is selected in this exam(le)
2-) A window is dis(layed to s(ecify %oot device identification %y WW5N or Device ID "DID#)
WW5N is recommended for all %oot from SAN confiurations)
Select 2 to %oot usin the WW5N# Exit and save the confiuration) 8e%oot the system to
ma!e the chanes effective)
The Emulex utility$ ;BAnyware+$ also su((orts %oot from SAN manaement from a runnin
Windows Boot from 0i%re 1hannel SAN 2>
Windows Server ,--/ or Windows Server ,--. environment) 1hanes %ecome effective when
the system is re%ooted$ which is useful for server re4(ur(osin scenarios) This adds another level
of flexi%ility for %lade server de(loyments)
2i'ration to /indo"s 2::, and /indo"s 2::, 02
1onsider the followin scenarios:
A) Hou have a Windows ,--/ server and you want to mirate to Windows ,--.$ care should %e
ta!en with volume manaement settins when miratin) A non4%oota%le dis! can result if
settins are not im(lemented correctly)
In order to ensure successful miration from Windows ,--/ Server to Windows Server ,--.$
the /o,utoMount settin must %e disa%led for the %oot dis!) If the /o,utoMount settin is not
disa%led$ then the SAN (olicy will %e cleared durin the miration and the (olicy will %e set to
*ffline or *fflineShared %ased on the SI@)
The S,/ Policy settin should also %e set to *nline for dis!s %efore claimin them as *5 Dis!
Devices)
B) Hou have a Windows Server ,--. machine with the Active Directory role installed) This server
uses *5IO$ and stores the active directory data%ase on a SAN attached drive other than the
%oot volume)
In order to ensure successful miration from Windows Server ,--. to Windows Server ,--.
8,$ the SAN (olicy must %e set to 7OnlineAll9 (rior to u(radin Windows so that the Active
Directory data%ase is availa%le durin the u(rade)
Windows Server DDS SAN (olicy is used to define the dis! (olicyJ the (olicy o(tions are
*nline$ *ffline$ and *fflineShared "see the DDS documentation for more details#) In order for
SAN %oot to wor! with Windows Server ,--.$ the SAN (olicy settin has to %e *nline for the
dis! on which the OS resides) @se dis!(art to chane these SAN (olicy settins)
Windows Boot from 0i%re 1hannel SAN 2?
Best Practices
Pa'in' )is6
A (aefile is a reserved (ortion of the hard dis! that is used to ex(and the amount of virtual
memory availa%le to a((lications) 5ain is the (rocess of tem(orarily swa((in out the inactive
contents of system (hysical memory to hard dis! until those contents are needed aain) Since the
o(eratin system must have unrestricted access to the (aefile$ the (aefile is commonly (laced
on the same drive as system files) Thus$ the 1: drive normally includes %oot$ system and (ain
files
2
)
While there is nelii%le contention %etween the %oot reads and (ain writes$ there can %e
considera%le resource contention %etween systems on the SAN when they are all tryin to do
(ain I<O$ or when many systems attem(t to %oot simultaneously from the same storae (ort)
One way to lessen resource contention is to se(arate non4data I<O "such as (ain$ reistry
u(dates and other %oot4related information# from data I<O sources "such as SKB or Exchane#)
Different scenarios to se(arate non4data I<O and data I<O are shown %elow:
.ocations for Non%)ata I; $i*es
$i*es Scenario 1 Scenario 2 Scenario 3
Boot SAN SAN SAN
System SAN SAN .oca*
Pa'efi*e SAN .oca* .oca*
0edundancy < A!oid Sin'*e Point of $ai*ure
One of the maLor %enefits of SAN ado(tion is hih availa%ility) The followin section outlines some
of the SAN inter4com(onents that can %e confiured redundantly to avoid any sinle (oint of
failure)
Stora'e Contro**er 0edundancy
1onfiure storae arrays with multi(le controllers to (rovide redundant array (orts and avoid any
sinle (oint of failures at the array controller level)
)is6 0edundancy
1onfiure the array usin different 8AID rou(s as re'uired to (rovide redundancy at the dis!
level)
Path 0edundancy
1
System files are required to run the Windows operating system. Boot files are required to boot Windows. The boot files include
boot.ini, Ntldr and Ntdetect. The paging file is typically called pagefile.sys.
Windows Boot from 0i%re 1hannel SAN 2A
1onfiure SAN infrastructure "switches$ ;BA (orts# to (rovide redundancy and avoid any (oint of
(ath failures)
)istributed .oad
SAN infrastructure is always a limited resource and the num%er of systems that can %e relia%ly
%ooted from a SAN at the same time is limited) In order to have %etter %oot time (erformance$ %oot
B@NS should %e distri%uted across controllers and storae tarets to avoid %ottlenec!s)
$abric 5onin'
There are two different &onin techni'ues that can %e used with SAN switches 4 hard &onin and
soft &onin) ;ard &onin is %ased on the (hysical (orts of the switchJ soft &onin is %ased on the
WW5N of the devices that are connected to the switch) In eneral$ soft &onin is more flexi%le
%ecause it allows devices to %e moved without re'uirin re4&onin) Soft &onin is recommended
for %oot from SAN setu( %ecause it reduces the (ossi%ility of a server loosin access to its %oot
dis! and %oot (artition)
Boot from SAN =&'rade 0e7uirements
It is im(ortant to note that durin Windows @(rades with systems that are %ootin from a SAN$
that it is necessary to disconnect all %ut one data (ath durin the u(rade$ as *5IO is not
availa%le durin Windows Setu()
The recommenced ste(s for an u(rade are as follows:
2) Disconnect all %ut one data (ath to the SAN that you are %ootin from)
,) 5erform the Windows u(rade)
/) Install the *ulti(ath I<O feature
=) 8econnect the additional (aths
>) Derify *5IO settins$ or reconfiure *5IO failover (olices as desired)
Windows Boot from 0i%re 1hannel SAN 2.
Troub*eshootin' Boot from $C SAN
A num%er of (ro%lems can arise durin confiuration that can result in a failure to load the
o(eratin system) It is im(ortant to distinuish %etween those (ro%lems that are shared %y all
ty(es of %oot and those that are s(ecific to %oot from 01 SAN) Because correct de(loyment of
%oot from 01 SAN de(ends on the user underta!in the exact vendor ste(s for ;BA and SAN
confiurations$ hardware vendors must %e the (rimary (oint of contact for issues related to
%ootin)
$ai*ure to .ocate the Boot Partition and Boot $i*es
The most common cause of %oot (ro%lems is a failure to locate the %oot (artition and %oot files)
This can ha((en for many reasons$ ranin from %oot sector viruses$ to hardware failure$ to
confiuration (ro%lems) While failure to locate the %oot device can occur in any %oot environment
"not sim(ly %oot from SAN#$ this issue is more (ro%lematic in com(lex storae confiurations
where new devices are added and removed fre'uently)
3ot S"a& of an 3BA "ith Boot from SAN Su&&ort
0or systems that su((ort hot swa($ it is (ossi%le to re(lace an ;BA that connects to the %oot
device while the Windows o(eratin system continues to run) If the hot swa( re(laced the only
;BA on the server with %oot ena%led$ %oot from SAN will need to %e re4confiured) Some ;BA
manaement tools allow %oot from SAN to %e confiured while the system is runnin as shown
%elow for the ;BAnyware manaement utility for Emulex ;BAs:
Windows Boot from 0i%re 1hannel SAN 2C
With online manaement$ %oot from SAN can %e confiured so the system will re%oot successfully
without intervention) If not$ the %oot (rocess will need to %e interru(ted in order to confiure the
new ;BA)
0or redundant failover$ each ;BA should %e confiured to %oot from the same %oot device) If a
hot swa( re(lacement ;BA is not confiured for %oot from SAN$ the system will re%oot usin the
first4enumerated ;BA that is confiured for %oot from SAN) ;owever$ care should %e ta!en to
confiure the re(lacement ;BA as soon as (ossi%le to maintain full redundancy) Aain$
manaement utilities that su((ort %oot confiuration with the system runnin allow %oot from SAN
confiuration without re'uirin a re%oot)
.=N : Assi'ned to the Array Contro**er
Some storae arrays assin B@N - to the array controller) 0or those arrays$ B@N - cannot %e
used as the %oot device)
3BA Confi'uration
The setu( routine of each ;BA %oot 8O* must %e individually confiured for %oot from SAN
solutions to wor!) 0or each ada(ter$ the correct dis!s must %e allocated and the %oot dis! or B@N
must %e correctly identified)
Too 2any Systems Bootin' $rom the Array
Windows Boot from 0i%re 1hannel SAN ,-
The num%er of servers that can relia%ly %oot from a sinle fa%ric connection is limited) If too many
servers attem(t to %oot at the same time$ such as with recovery from a (ower failure$ the lin! can
%ecome saturated$ delayin the %oot for a server that is attem(tin to %oot) If this condition
(ersists for too lon$ the re'uests will time out and the system can fail to %oot) In order to mitiate
this issue$ tarets can %e confiured so those %oots B@Ns are distri%uted across all of the
availa%le storae controllers)
The actual num%er of systems that can %oot from a sinle fa%ric connection is vendor s(ecific)
Windows Boot from 0i%re 1hannel SAN ,2
Current .imitations to /indo"s Boot from SAN
There are a num%er of advanced scenarios that are not currently (ossi%le in Windows %oot from
SAN environments)
No Shared Boot Ima'es
Windows servers cannot currently share a %oot imae) Each server re'uires its own dedicated
B@N to %oot)
2ass )e&*oyment of Boot Ima'es 0e7uires 2icrosoft )e&*oyment Too*6it
In enter(rise confiurations$ De(loyment Tool!it can hel( with mass de(loyment of %oot imaes)
Windows Boot from 0i%re 1hannel SAN ,,
Additiona* 0esources
Additional white (a(ers:
*icrosoft Storae Technoloies 4 *ulti(ath I<O
Inowlede Base Articles:
Su((ort for Bootin from a Storae Area Networ! "SAN#
Windows Boot from 0i%re 1hannel SAN ,/
Summary
This (a(er introduces %oot from SAN technoloy in the Windows environment) Boot from SAN
sim(lifies the ado(tion of dis!less server technoloies and sim(lifies storae manaement %y
facilitatin a centrali&ed a((roach to o(eratin system installation and %ootin (rocesses) This
(a(er descri%es a num%er of %oot from SAN scenarios su((orted in the Windows environment$
includin multi(athin and clusterin$ and offers trou%leshootin information to hel( ensure
successful de(loyment) The (a(er includes an a((endix with additional information on the SAN
%oot (rocess)
Windows Boot from 0i%re 1hannel SAN ,=