1  
Part  1  
 
Providing  high  availability  for  applications  and  services  is  one  of  the  most  critical  
responsibilities  that  IT  administrators  have  in  today’s  data  centers.  Planned  or  
unplanned  downtime  may  cause  businesses  to  lose  money,  customers,  and  
reputation.  
 
Highly  available  systems  demand  the  implementation  of  fault-­‐tolerant  processes  
and  operations  that  minimize  interruptions  by  eliminating  single  point  of  failures  
and  detecting  failures  as  they  happen.  This  is  what  failover  clustering  is  all  about.  
Our  first  section  dedicated  to  Windows  Server  2012  R2  failover  clustering  describes  
the  main  components  of  a  failover  cluster  implementation,  the  quorum  
configuration  options  and  the  shared  storage  preparation.  
 
Main  Components  of  a  Failover  Cluster  
 
When  configuring  a  Windows  Server  2012  R2  failover  cluster,  it  is  essential  to  
carefully  consider  the  main  components  that  will  integrate  the  cluster  configuration.  
Let’s  review  the  most  important  ones:  
 
• Nodes.  These  are  the  member  servers  of  a  failover  cluster.  This  collection  of  
servers  communicate  with  each  other  and  run  cluster  services,  resources,  
and  applications  associated  with  a  cluster.  
• Networks.  Refers  to  the  networks  that  cluster  nodes  use  to  communicate  
with  one  another,  the  clients,  and  the  storage.  Three  different  networks  can  
be  configured  to  provide  enhanced  functionality  to  the  cluster:  
• Private  network:  Dedicated  to  internal  cluster  communication.  It  is  used  by  
the  nodes  to  exchange  heartbeats  and  interact  with  other  nodes  in  the  
cluster.  The  failover  cluster  authenticates  all  internal  communication.  
• Public  network:  This  network  allows  network  clients  access  to  cluster  
applications  and  services.  It  is  possible  to  have  a  mixed  public  and  private  
network,  although  it  is  not  recommended  as  bottleneck  and  contention  
issues  may  strain  the  network  connections.  
• Storage  network:  These  are  dedicated  channels  to  shared  storage.  iSCSI  
storage  requires  special  attention  because  it  uses  the  same  IP  protocol  and  
Ethernet  devices  available  to  the  other  networks.  However,  the  storage  
network  should  be  completely  isolated  from  any  other  network  in  the  
cluster.  Configuring  redundant  connections  on  all  these  networks  increases  
cluster  resilience.  
• Storage.  This  is  the  cluster  storage  system  that  is  typically  shared  between  
cluster  nodes.  The  failover  cluster  storage  options  on  Windows  Server  2012  
R2  are:  
• iSCSI:  The  iSCSI  protocol  encapsulates  SCSI  commands  into  data  packetsthat  
are  transmitted  using  Ethernet  and  IP  protocols.  Packets  are  sent  over  
the  network  using  a  point-­‐to-­‐point  connection.  Windows  Server  2012  
 supports  implementing  iSCSI  target  software  as  a  feature.  Once  the  iSCSI  
target  is  configured,  the  cluster  nodes  can  connect  to  the  shared  storage  
using  the  iSCSI  initiator  software  that  is  also  part  of  the  Windows  Server  
2012  operating  system.  Keep  in  mind  that,  in  most  production  networks  with  
high  loads,  system  administrators  will  opt  for  hardware  iSCSI  host  bus  
adapters  (HBA)  over  software  iSCSI.  
• Fiber  channel:  
Fiber  channel  SANs  typically  have  better  performance  than  iSCSI  SANs,  but  
are  much  more  expensive.  Specialized  hardware  and  cabling  are  needed,  
with  options  to  connect  point-­‐to-­‐point,  switched,  and  loop  interfaces.  
• Shared  serial  attached  SCSI:  Implementing  shared  serial  attached  SCSI  
requires  that  two  cluster  nodes  be  physically  close  to  each  other.  You  may  be  
limited  by  the  number  of  connections  for  cluster  nodes  on  the  shared  storage  
devices.  
• Shared  .vhdx:  Use  with  virtual  machine  guest  clustering.  A  shared  virtual  
hard  drive  should  be  located  on  a  clustered  shared  volume  (CSV)  or  scale-­‐out  
file  server  cluster.  From  there,  it  can  be  added  to  virtual  machines  
participating  in  a  guest  cluster  by  connecting  to  the  SCSI  interface.  Vhd  drives  
are  not  supported.  
• Services  and  applications.  These  represent  the  components  that  the  
failover  cluster  protects  by  providing  high  availability.  Clients  access  services  
and  applications  and  expect  them  to  be  available  when  needed.  When  a  node  
fails,  failover  moves  services  and  applications  to  another  node  to  ensure  that  
those  clustered  services  and  applications  continue  to  be  available  to  network  
clients.  
 
Server  2012  R2  Failover  Clustering  Quorum  
 
Quorum  defines  the  minimum  number  of  nodes  that  must  participate  concurrently  
on  the  cluster  to  provide  failover  protection.  Each  node  casts  a  vote  and  if  there  are  
enough  votes,  the  quorum  can  start  or  continue  running.  When  there  is  an  even  
number  of  nodes,  the  cluster  can  be  configured  to  allow  an  additional  witness  vote  
from  a  disk  or  a  file  share.  Each  node  contains  an  updated  copy  of  the  cluster  
configuration  that  includes  the  number  of  votes  that  are  required  for  the  cluster  to  
function  properly.  
 
There  are  four  quorum  modes  in  Windows  Server  2012:  
 
Node  majority  
 
Each  node  that  is  online  and  connected  to  the  network  represents  a  vote.  The  cluster  
operates  only  with  a  majority,  or  more  than  half  of  the  votes.  Node  majority  is  
recommended  for  clusters  with  an  odd  number  of  servers.  
 
Node  and  disk  majority  
 

  3  
Each  node  that  is  online  and  connected  to  the  network  represents  a  vote,  but  there  
is  also  a  disk  witness  that  is  allowed  to  vote.  The  cluster  runs  successfully  only  with  
a  majority,  that  means,  when  it  has  more  than  half  of  the  votes.  This  configuration  
relies  on  the  nodes  being  able  to  communicate  with  one  another  in  the  cluster,  and  
with  the  disk  witness.  It  is  recommended  for  clusters  with  an  even  number  of  nodes.  
 
Node  and  file  share  majority  
 
Each  node  that  is  online  and  connected  to  the  network  represents  a  vote,  but  there  
is  also  a  file  share  that  is  allowed  to  vote.  As  in  previous  modes,  the  cluster  operates  
only  with  a  majority  of  the  votes.  This  mode  works  in  a  similar  way  to  node  and  disk  
majority  but,  instead  of  a  disk  witness,  the  cluster  uses  a  file  share  witness.  
 
No  majority:  disk  only  
 
The  cluster  has  quorum  if  one  node  is  available  and  in  communication  with  a  
specific  disk  in  the  cluster  storage.  Only  the  nodes  that  are  also  in  communication  
with  that  disk  can  join  the  cluster.  This  represents  a  single  point  of  failure  and  it  is  
the  least  desirable  option.  
 
On  Windows  Server  2012,  the  installation  wizard  by  default  automatically  selects  
the  quorum  mode  during  the  installation  process.  Once  the  failover  cluster  
installation  completes,  you  will  have  either  one  of  these  two  modes:  
 
• Node  majority:  if  there  is  an  odd  number  of  nodes  in  the  cluster.  
• Node  and  disk  majority:  if  there  is  an  even  number  of  nodes  in  the  cluster.  
 
At  any  time  you  can  switch  to  a  different  mode  to  accommodate  changes  in  your  
network  and  cluster  arrangement.  
 
Windows  Server  2012  R2  Dynamic  Quorum  
 
Windows  Server  2012  R2  introduces  significant  changes  to  the  way  cluster  quorum  
functions.  When  you  install  a  Windows  Server  2012  R2  failover  cluster,  dynamic  
quorum  is  selected  by  default.  This  process  defines  the  quorum  majority  based  on  
the  number  of  nodes  in  the  cluster  and  configures  the  disk  witness  vote  dynamically  
as  nodes  are  added  or  remove  from  the  cluster.  If  a  cluster  has  an  odd  number  of  
votes,  a  disk  witness  will  not  have  a  vote  in  the  cluster;  with  an  even  number,  a  disk  
witness  will  have  a  vote.  In  other  words,  the  cluster  automatically  decides  whether  
to  use  the  witness  vote  based  on  the  number  of  voting  nodes  that  are  available  in  
the  cluster.  Dynamic  quorum  allows  a  cluster  to  recalculate  quorum  when  a  node  
fails  in  order  to  keep  the  cluster  running  successfully,  even  when  the  number  of  
nodes  remaining  in  the  cluster  drops  below  50  percent  of  the  initial  configuration.  
Another  benefit  of  the  dynamic  quorum  is  that,  when  you  add  or  evict  nodes  from  
the  cluster,  there  is  no  need  to  change  the  quorum  settings  manually.  The  previous  

  4  
quorum  modes  that  require  manual  configuration  are  still  available,  in  case  you  feel  
some  nostalgia  for  the  old  methodology.  
 
Windows  Server  2012  R2  also  allows  you  to  start  cluster  nodes  that  do  not  have  a  
majority  by  using  the  “force  quorum  resilience”  feature.  This  can  be  used  when  a  
cluster  breaks  into  subsets  of  cluster  nodes  that  are  not  aware  of  each  other,  a  
situation  that  is  also  known  as  split  brain  syndrome  cluster  scenario.  
 
Using  Windows  Server  2012  R2  iSCSI  Target  
 
For  shared  storage,  our  demonstration  lab  uses  the  iSCSI  Target  feature  on  
Windows  Server  2012  R2.  To  verify  the  status  of  the  iSCSI  feature  on  a  Windows  
Server  2012,  from  Windows  PowerShell  run  the  following  command:  
 
• Get-­‐WindowsFeature  FS-­‐iSCSITarget-­‐Server  
 

 
 
The  above  figure  shows  that  the  iSCSI  Target  has  not  been  installed  on  the  server  
yet.  To  install  the  iSCSI  target  feature,  run  the  following  Windows  PowerShell  
command:  
 
• Install-­‐WindowsFeature  FS-­‐iSCSITarget-­‐Server  
 

 
 
Configuring  the  iSCSI  targets  
 
After  the  iSCSI  has  been  installed,  you  can  go  to  Server  Manager  to  complete  the  
configuration.  Here  are  the  steps:  
 
1. In  the  Server  Manager,  in  the  navigation  pane,  click  File  and  Storage  
Services.  

  5  
  
2. In  the  File  and  Storage  Services  pane,  click  iSCSI.  

 
3. In  the  iSCSI  VIRTUAL  DISKS  pane,  click  TASKS,  and  then  in  the  TASKS  drop-­‐
down  list  box,  click  New  iSCSI  Virtual  Disk.  

 
4. In  the  New  iSCSI  Virtual  Disk  Wizard,  on  the  Select  iSCSI  virtual  disk  
location  page,  under  Storage  location,  click  drive  E,  and  then  click  Next.  

  6  
  
5. On  the  Specify  iSCSI  virtual  disk  name  page,  in  the  Name  text  box,  
type  iLUN0,  and  then  click  Next.  

  7  
  
6. On  the  Specify  iSCSI  virtual  disk  size  page,  in  the  Size  text  box,  type  500;  in  
the  drop-­‐down  list  box,  if  necessary  switch  to  GB,  select  Dynamically  
expanding  and  then  click  Next.  

  8  
  
7. On  the  Assign  iSCSI  target  page,  click  New  iSCSI  target,  and  then  click  Next.  

  9  
  
8. On  the  Specify  target  name  page,  in  the  Name  box,  type  iSAN,  and  then  
click  Next.  

  10  
  
9. On  the  Specify  access  servers  page,  click  Add.  

  11  
  
10. In  the  Select  a  method  to  identify  the  initiator  dialog  box,  click  Enter  a  
value  for  the  selected  type,  in  the  Type  drop-­‐down  list  box,  click  IP  
Address,  in  the  Value  text  box,  type  192.168.1.200,  and  then  click  OK.  

  12  
  
11. On  the  Specify  access  servers  page,  click  Add.  

  13  
  
12. In  the  Select  a  method  to  identify  the  initiator  dialog  box,  click  Enter  a  
value  for  the  selected  type;  in  the  Type  drop-­‐down  list  box,  click  IP  
Address;  in  the  Value  text  box,  type  192.168.1.201,  and  then  click  OK.  

  14  
  
13. On  the  Specify  access  servers  page,  confirm  that  you  have  two  IP  addresses.  
These  correspond  to  the  two  cluster  nodes  that  will  be  using  their  iSCSI  
initiators  to  connect  to  the  shared  storage.  Click  Next.  

  15  
  
14. On  the  Enable  Authentication  page,  click  Next.  

  16  
  
15. On  the  Confirm  selections  page,  click  Create.  

  17  
  
16. On  the  View  results  page,  wait  until  creation  completes,  and  then  
click  Close.  

  18  
  
17. In  the  iSCSI  VIRTUAL  DISKS  pane,  click  TASKS,  and  then  in  the  TASKS  drop-­‐
down  list  box,  click  New  iSCSI  Virtual  Disk.  

 
18. In  the  New  iSCSI  Virtual  Disk  Wizard,  on  the  Select  iSCSI  virtual  disk  
location  page;  under  Storage  location,  click  drive  E,  and  then  click  Next.  

  19  
  
19. On  the  Specify  iSCSI  virtual  disk  name  page,  in  the  Name  box,  type  iLUN1,  
and  then  click  Next.  

  20  
  
20. On  the  Specify  iSCSI  virtual  disk  size  page,  in  the  Size  box,  type  300;  in  the  
drop-­‐down  list  box,  if  necessary,  switch  to  GB,  select  Dynamically  
expanding,  and  then  click  Next.  

  21  
  
21. On  the  Assign  iSCSI  target  page,  click  iSAN,  and  then  click  Next.  

  22  
  
22. On  the  Confirm  selection  page,  click  Create.  

  23  
  
23. On  the  View  results  page,  wait  until  the  new  iSCSI  virtual  disk  is  created,  and  
then  click  Close.  

  24  
  
Repeating  steps  17  through  23,  another  1GB  iSCSI  virtual  hard  disk  has  been  created  
to  be  used  as  the  disk  witness  in  the  failover  cluster.  The  three  drives  are  shown  in  
the  figure  below.  

 
Closing  Remarks  

  25  
Failover  clustering  is  a  critical  technology  to  provide  high  availability  of  services  and  
applications.  This  chapter  introduced  the  Windows  Server  2012  R2  failover  
clustering  components  and  the  quorum  configuration  modes.  It  also  illustrated  the  
implementation  of  the  iSCSI  Target  feature  to  provide  the  shared  storage  for  a  
failover  cluster.  Our  next  section  will  demonstrate  step  by  step  how  to  connect  the  
servers  to  the  shared  storage  and  how  to  install  and  configure  Windows  Server  
2012  R2  failover  clustering.  
 

Part  2  
 
Our  previous  section  in  this  ebook  explained  the  main  components  of  a  Windows  
Server  2012  R2  failover  cluster,  the  quorum  configuration  options  and  the  shared  
storage  preparation.  This  section  expands  on  the  requirements  to  implement  
failover  clustering  on  Windows  Server  2012  R2,  describes  the  step-­‐by-­‐step  process  
to  connect  the  servers  to  shared  storage,  and  the  installation  of  a  Windows  Server  
2012  R2  failover  cluster.  After  the  cluster  is  created,  Windows  PowerShell  is  used  to  
demonstrate  a  generic  application  role  configuration.  
 
Requirements  and  Recommendations  for  a  Successful  Failover  Cluster  
Implementation  
 
A  Windows  Server  2012  R2  failover  cluster  can  have  from  two  to  64  servers,  also  
known  as  nodes.  Once  configured,  these  computers  work  together  to  increase  the  
availability  of  applications  and  services.  However,  the  requirements  for  a  failover  
cluster  configuration  are  more  stringent  than  any  other  Windows  Server  network  
service  that  you  may  manage.  
 
Let’s  review  some  of  the  most  important  limitations:  
 
• It  is  recommended  to  install  similar  hardware  on  each  node.  
• You  must  run  the  same  edition  of  Windows  Server  2012  or  Windows  Server  
2012  R2.  The  edition  can  be  Standard  or  Datacenter,  but  they  cannot  be  
mixed  in  the  same  cluster.  
• Equally  important  is  to  configure  the  cluster  with  all  nodes  as  Server  Core  or  
Full  installation  but  not  both.  
• Every  node  in  the  cluster  should  also  have  similar  software  updates  and  
service  packs.  
• You  must  include  matching  processor  architecture  on  each  cluster  node.  This  
means  that  you  cannot  mix  Intel  and  AMD  processors  families  on  the  same  
cluster.  
• When  using  serial  attached  SCSI  or  Fibre  Channel  storage,  the  controllers  or  
host  bus  adapters  (HBA)  should  be  identical  in  all  nodes.  The  controllers  
should  also  run  the  same  firmware  version.  
• If  Internet  SCSI  (iSCSI)  is  used  for  storage,  each  node  should  have  at  least  one  
network  adapter  or  host  bus  adapter  committed  exclusively  to  the  cluster  

  26  
 storage.  The  network  dedicated  to  iSCSI  storage  connections  should  not  carry  
any  other  network  communication  traffic.  It  is  recommended  to  use  a  
minimum  of  2  network  adapters  per  node.  Gigabit  Ethernet  (GigE)  or  higher  
is  strongly  suggested  for  better  performance.  
• Each  node  should  have  installed  identical  network  adapters  that  support  the  
same  IP  protocol  version,  speed,  duplex,  and  flow  control  options.  
• The  network  adapters  in  each  node  must  obtain  their  IP  addresses  using  the  
same  consistent  method,  either  they  are  all  configured  with  static  IP  
addresses  or  they  all  use  dynamic  IP  addresses  from  a  DHCP  server.  
• Each  server  in  the  cluster  must  be  a  member  of  the  same  Active  Directory  
domain  and  use  the  same  DNS  server  for  name  resolution.  
• The  networks  and  hardware  equipment  use  to  connect  the  servers  in  the  
cluster  should  be  redundant,  so  that  the  nodes  will  maintain  communication  
with  one  another  after  a  single  link  fails,  a  node  crashes,  or  a  network  device  
malfunctions.  
• In  order  to  access  Microsoft  support,  all  the  hardware  components  in  your  
cluster  should  bear  the  “Certified  for  Windows  Server  2012”  logo  and  they  
must  pass  the  “Validate  a  Configuration”  Wizard  test.  More  on  this  later  in  the  
sections.  
 
Connecting  the  Servers  to  Shared  Storage  
 
Our  lab  for  this  demonstration  uses  two  physical  Windows  Server  2012  R2  nodes  
nameServerA1,  and  ServerA2.  Before  installing  the  failover  clustering  feature,  let’s  
connect  the  servers  to  the  iSCSI  target  which  contains  the  shared  storage  that  was  
created  in  the  first  chapter  of  this  series.  Starting  with  ServerA1,  here  are  the  
steps:  
 
1. In  the  Server  Manager,  click  Tools,  and  then  click  the  iSCSI  Initiator.  If  
prompted,  click  Yes  in  the  Microsoft  iSCSI  dialog  box.  

  27  
  
2. In  the  iSCSI  Initiator  Properties,  click  the  Discovery  tab  and  then  
click  Discover  Portal.  

  28  
   29  
 
 3. In  the  Discover  target  Portal  page,  In  the  IP  address  or  DNS  name  box,  
type192.168.1.100,  and  then  click  OK.  This  is  the  IP  address  of  the  iSCSI  
Target  server.  

 
4. Click  the  Targets  tab,  click  Refresh,  select  iqn.1991-­‐
05.com.microsoft:dc1-­‐isan-­‐target,  and  then  click  Connect.  

  30  
   31  
 
 5. In  the  Connect  to  Target  box,  make  sure  that  Add  this  connection  to  the  list  
of  Favorite  Targets  is  selected,  click  OK.  

 
6. In  the  iSCSI  Initiator  Properties,  verify  that  the  Status  is  Connected  and  
click  OK.  

  32  
   33  
 
Steps  1  through  6  must  also  be  executed  on  ServerA2  so  that  both  servers  can  have  
access  to  the  shared  storage  available  from  the  iSCSI  Target  Server.  
 
Next,  let’s  configure  the  volumes  using  Disk  Management  on  ServerA1.  
 
1. In  the  Server  Manager,  click  Tools,  and  then  click  Computer  Management.  

 
2. Expand  Storage,  then  click  Disk  Management  and  verify  that  you  have  three  
new  disks  that  need  to  be  configured.  These  are  the  iSCSI  Target  disks.  

  34  
  
3. Right-­‐click  Disk  9,  and  then  click  Online.  

  35  
  
4. Right-­‐click  Disk  9,  and  then  click  Initialize  disk.  In  the  Initialize  Disk  dialog  
box,  click  OK.  

  36  
  
5. Right-­‐click  the  unallocated  space  next  to  Disk  9,  and  then  click  New  Simple  
Volume.  

  37  
  
6. On  the  Welcome  page,  click  Next.  

  38  
  
7. On  the  Specify  Volume  Size  page,  click  Next.  

  39  
  
8. On  the  Assign  Drive  Letter  or  Path  page,  click  Next.  

  40  
  
9. On  the  Format  Partition  page,  in  the  Volume  Label  box,  type  CSV.  Select  
thePerform  a  quick  format  check  box,  and  then  click  Next.  

  41  
  
10. Click  Finish.  

  42  
  
 
Repeat  steps  1  through  10  for  Disks  10  and  11.  For  disk  10  change  the  label  
to  Data  and  for  Disk  11  change  the  label  to  Witness.  If  you  run  your  own  lab,  the  
disks  numbers  are  likely  to  be  different,  but  the  steps  are  identical.  Once  all  the  
steps  are  completed  onServerA1,  you  need  to  go  to  ServerA2  and  from  Disk  
Management  right  click  on  each  disk  and  bring  them  online.  
 
Both  servers  should  show  the  disks  configured  as  the  figure  below.  
 

  43  
  
 
Installing  the  Windows  Server  2012  R2  Failover  Clustering  Feature  
 
Now  that  both  servers  are  connected  to  the  shared  storage,  the  next  phase  is  to  
install  the  failover  clustering  feature  on  ServerA1  and  ServerA2  using  either  
Windows  PowerShell  or  Server  manager.  
 
The  process  is  exactly  the  same  on  both  servers,  so  let’s  demonstrate  it  
on  ServerA1.  
 
1. Using  Windows  PowerShell  verify  that  the  Failover  clustering  feature  is  not  
installed  on  the  server  by  running  the  following  command:  
• Get-­‐WindowsFeature  Failover-­‐Clustering  |  FT  –Autosize  

 
1. To  install  the  Failover  clustering  feature,  from  PowerShell  run  this  command:  
• Install-­‐WindowsFeature  Failover-­‐Clustering  –IncludeManagementTools  

 
 
Validating  the  Servers  for  Failover  Clustering  
 

  44  
Once  the  failover  clustering  feature  is  installed  on  both  servers,  running  the  wizard  
to  validate  the  servers  for  failover  clustering  allows  you  to  generate  a  detailed  
report  indicating  possible  areas  that  may  need  to  be  fixed  before  creating  the  
cluster.  Let’s  run  the  Validate  a  Configuration  Wizard  from  ServerA1.  
 
1. In  the  Server  Manager,  click  Tools,  and  then  click  Failover  Cluster  
Manager.  

  45  
  

  46  
 2. In  the  Actions  pane  of  the  Failover  Cluster  Manager,  click  Validate  
Configuration.  

 
3. In  the  Validate  a  Configuration  Wizard,  click  Next.  

  47  
  
4. In  the  Select  Servers  or  a  Cluster,  next  to  the  Enter  Name  box,  
type  ServerA1,  and  then  click  Add.  

  48  
  
5. In  the  Enter  Name  box,  type  ServerA2  and  then  click  Add,  

  49  
  
6. Verify  that  ServerA1  and  ServerA2  are  shown  in  the  Selected  servers  box  
and  clickNext.  

  50  
  
7. Verify  that  Run  all  tests  (recommended)  is  selected,  and  then  click  Next.  

  51  
  
8. On  the  Confirmation  page,  click  Next.  

  52  
  
9. Wait  for  the  validation  tests  to  finish.  This  may  take  several  minutes.  On  the  
Summary  page,  click  View  Report.  It  is  recommended  that  you  keep  this  
report  for  future  references.  

  53  
  
10. Verify  that  all  tests  are  completed  without  errors.  You  can  click  on  areas  of  
the  report  to  find  out  more  details  on  the  configurations  that  show  warnings.  

  54  
  
11. On  the  Summary  page,  click  to  remove  the  checkmark  next  to  Create  the  
cluster  now  using  the  validated  nodes,  and  click  Finish.  

  55  
  
 
Creating  the  Failover  cluster  
 
Even  though  there  were  some  warnings,  the  servers  did  pass  the  validation  test,  so  
we  can  proceed  to  create  our  cluster  now.  The  following  steps  will  be  executed  using  
Failover  Cluster  manager  on  ServerA1,  but  either  node  would  be  fine  to  complete  
this  process.  
 
1. In  the  Failover  Cluster  Manager,  in  the  center  pane,  under  Management,  
clickCreate  Cluster.  

  56  
  
2. On  the  Before  You  Begin  page  of  the  Create  Cluster  Wizard,  read  the  
information  and  click  Next.  

  57  
  
3. In  the  Enter  server  name  box,  type  ServerA1,  ServerA2  and  then  click  Add.  

  58  
  
4. Verify  the  entries,  and  then  click  Next.  

  59  
  
5. In  Access  Point  for  Administering  the  Cluster,  in  the  Cluster  Name  box,  
typeClusterA.  Under  Address,  type  192.168.1.210,  and  then  click  Next.  

  60  
  
6. In  the  Confirmation  dialog  box,  verify  the  information,  and  then  click  Next.  

  61  
  
7. On  the  Summary  page,  confirm  that  the  cluster  was  successfully  created  and  
clickFinish  to  return  to  the  Failover  Cluster  Manager.  

  62  
  
After  the  Create  Cluster  Wizard  is  done,  you  can  verify  that  a  computer  object  with  
the  cluster’s  name  has  been  created  in  Active  Directory.  See  figure  below.  

  63  
  
 
Also,  a  host  name  is  automatically  registered  in  DNS  for  the  new  cluster.  See  figure    
below.  

  64  
The  failover  cluster  feature  predefines  specific  roles  that  can  be  configured  for  
failover  protection,  including  DFS  Namespace  server,  DHCP  Server,  File  Server,  iSCSI  
Target  Server,  WINS  Server,  Hyper-­‐V  Replica  Broker  and  Virtual  Machines.  It  is  
possible  to  cluster  applications  and  services  that  are  not  clustered  aware  by  using  
the  available  Generic  application  or  Generic  Service  role  respectively.  The  figure  
below  shows  the  roles  representing  services  and  applications  that  can  be  configured  
for  high  availability.  
 

 
 
Either  the  Failover  Cluster  Manager  or  Windows  PowerShell  can  be  used  to  
configure  these  roles.  The  following  code  provides  an  example  of  applying  the  
Generic  Application  role  using  Windows  PowerShell.  
 
Add-­‐ClusterGenericApplicationRole  
-­‐CommandLine  
notepad.exe  `  
-­‐Name  
notepad  

  65  
-­‐StaticAddress  
192.168.1.225  
 

 
 
The  following  command  can  be  used  to  verify  that  the  generic  application  is  online:  
Get-­‐ClusterResource  “notepad  application”  |  fl  
 

 
 
Failover  Cluster  Manager  also  shows  that  the  generic  application  is  up  and  running.    
 
See  the  figure  below.  

 
 
Failover  Clustered  File  Server  Options  

  66  
Windows  server  2012  R2  supports  two  different  clustered  file  servers’  
implementations:  Scale-­‐Out  File  Server  for  application  data  and  File  Server  for  
general  use.  
 
Scale-­‐Out  File  Server  for  Application  Data  
 
It  is  also  known  as  an  active-­‐active  cluster;  this  feature  was  introduced  in  Windows  
Server  2012  and  it  is  the  recommended  clustered  file  server  option  to  deploy  Hyper-­‐
V  nodes  and  Microsoft  SQL  servers  over  Server  Message  Block  (SMB).  This  high  
performance  solution  allows  you  to  store  server  application  data  on  file  shares  that  
are  concurrently  available  online  on  all  nodes.  Because  the  aggregated  bandwidth  
from  all  the  nodes  is  now  the  maximum  cluster  bandwidth,  the  performance  boost  
can  be  very  significant.  You  can  increase  the  total  bandwidth  by  bringing  additional  
nodes  into  the  cluster.  These  scale-­‐out  files  shares  require  SMB  3.0  or  higher  and  
they  are  not  available  in  any  version  of  Windows  Server  previous  to  Windows  
Server  2012.  
 
File  Server  for  General  Use  
 
This  is  the  traditional  failover  clustering  solution  that  has  been  available  on  
previous  versions  of  Windows  Server  in  which  only  one  node  is  available  at  a  time  in  
an  active-­‐passive  configuration.  It  supports  some  important  features  that  cannot  be  
implemented  on  Scale-­‐Out  File  Servers  like  data  deduplication,  DFS  replication,  
dynamic  access  control,  work  folders,  NFS  shares,  branchcache  and  File  Server  
Resource  Manager  screen  and  quota  management.  
 
Closing  Remarks  
 
Installing  the  Windows  Server  2012  R2  failover  clustering  feature  has  some  strict  
hardware  and  software  requirements.  This  chapter  demonstrates  how  to  connect  
the  cluster  nodes  to  shared  storage,  how  to  create  a  cluster  and  configure  a  generic  
application  role  using  Windows  PowerShell.  There  is  more  to  do  now  that  the  
cluster  is  up  and  running  as  we  can  configure  additional  services  and  applications  
for  failover  protection.  After  all,  that  is  the  whole  idea  of  setting  up  the  cluster.  
Our  next  and  final  chapter  in  this  series  will  walk  through  the  configuration  of  a  
highly  available  file  server.  And  saving  the  best  for  last,  you  will  see  the  
implementation  of  cluster  shared  volumes  (CSV)  and  how  they  are  used  on  a  Hyper-­‐
V  cluster  to  provide  failover  protection  in  a  virtualized  environment.  Live  migration  
will  be  tested  to  validate  the  functionality  of  the  Hyper-­‐V  cluster.  
 

Part  3  
 
The  previous  section  in  this  book  covered  the  steps  to  connect  cluster  nodes  to  
shared  storage,  the  installation  of  the  Windows  Server  2012  failover  clustering  
feature,  and  the  configuration  of  a  cluster  role  using  Windows  PowerShell.  This  

  67  
chapter  demonstrates  the  process  of  deploying  and  configuring  a  highly  available  
file  server,  the  implementation  of  cluster  shared  volumes  (CSV),  and  how  to  manage  
a  Hyper-­‐V  cluster  to  provide  failover  protection  to  virtual  machines.  
 
Deploying  and  Configuring  a  Highly  Available  File  Server  
 
Our  lab  uses  a  cluster  name,  ClusterA.abc.com,  which  consists  of  two  nodes  that  
are  identified  as  ServerA1  and  ServerA2.  
 
You  must  install  the  file  server  role  service  on  every  cluster  node  before  a  highly  
available  file  server  can  be  configured  on  the  cluster.  For  our  lab,  
both  ServerA1  and  ServerA2  have  the  file  server  role  service  already  installed.  
There  are  also  three  disks  that  have  been  added  to  the  cluster;  one  of  the  disks  is  the  
witness  quorum  and  the  other  two  are  used  for  data  storage.  To  deploy  the  
clustered  file  server,  let’s  complete  the  following  steps:  
 
1. In  the  Failover  Cluster  Manager,  expand  ClusterA.abc.com.  Expand  Storage,  
and  click  Disks.  Make  sure  that  Cluster  Disk  1,  Cluster  Disk  2,  and  Cluster  
Disk  3  are  present  and  online.  

 
2. Right-­‐click  Roles,  and  then  select  Configure  Role.  

  68  
  
3. On  the  Before  You  Begin  page,  click  Next.  

 
4. On  the  Select  Role  page,  select  File  Server,  and  then  click  Next.  

  69  
  
5. On  the  File  Server  Type  page,  click  File  Server  for  general  use,  and  then  
click  Next.  

  70  
  
6. On  the  Client  Access  Point  page,  in  the  Name  box,  type  GeneralFS;  in  
the  Addressbox,  type  192.168.1.215;  and  then  click  Next.  GeneralFS  will  
join  the  Active  Directory  as  a  computer  object  that  can  be  seen  in  the  
Computers  container  of  Active  Directory  Users  or  the  Active  Directory  
Administrative  Center.  Also,  the  same  name  will  register  on  the  DNS  server  
with  its  corresponding  IP  address.  

  71  
  
7. On  the  Select  Storage  page,  select  the  Cluster  Disk  2  check  box,  and  then  
clickNext.  

  72  
  
8. On  the  Confirmation  page  notice  the  network  name  and  the  name  for  the  
organizational  unit  (OU)  where  the  cluster  account  will  be  created,  then  
click  Next.  

  73  
  
9. On  the  Summary  page,  click  Finish.  

  74  
  
10. Under  ClusterA.abc.com,  click  on  Roles  to  confirm  that  the  GeneralFS  file  
server  role  is  up  and  running.  Note  that  ServerA1  is  
the  GeneralFS  role’s  Owner  Node.However,  it  is  important  to  test  failover  
protection  in  order  to  verify  that  ServerA2can  also  hold  the  ownership  
of  GeneralFS  in  case  ServerA1  becomes  unavailable.  

  75  
  
11. To  test  failover  protection,  right-­‐click  on  GeneralFS,  and  then  click  on  Move  
–  Select  Node.  

 
12. On  the  Move  Clustered  Role  box,  select  ServerA2  and  click  OK.  

  76  
  
13. Verify  that  the  role  failed  over  to  ServerA2,  which  is  now  the  owner  
of  GeneralFS.  

  77  
  
 
Add  a  Shared  Folder  to  a  Highly  Available  File  Server  
 
Now  that  the  clustered  file  server  has  been  created,  it’s  time  to  add  shared  folders  to  
further  assess  the  functionality  of  this  highly  available  solution.  
 
1. In  Failover  Cluster  Manager,  expand  ClusterA.abc.com,  and  then  
click  Roles.  

 
2. Right-­‐click  GeneralFS,  and  then  select  Add  File  Share.  

  78  
  
3. In  the  New  Share  Wizard,  on  the  Select  the  profile  for  this  share  page,  
click  SMB  Share  –  Quick,  and  then  click  Next.  

  79  
  
4. On  the  Select  the  server  and  the  path  for  this  share  page,  under  Server,  
make  sure  that  GeneralFS  is  selected  and  click  Next.  

  80  
  
5. On  the  Specify  share  name  page,  in  the  Share  name  box,  type  Reports,  and  
then  click  Next.  

  81  
  
6. On  the  Configure  share  settings  page,  review  the  available  settings,  note  
that  theEnable  
Branchcache  on  the  file  share  option  is  not  available  because  
the  Branchcache  for  Network  Files  role  service  is  not  installed  on  the  
server.  Click  Next.  

  82  
  
7. On  the  Specify  permissions  to  control  access  page,  click  Next.  

  83  
  
8. On  the  Confirm  selections  page,  verify  the  settings  assigned  to  the  file  share  
and  click  Create.  

  84  
  
9. On  the  View  results  page,  confirm  that  the  share  was  successfully  created  
and  clickClose.  

  85  
  
 
Failover  and  Failback  
 
Failover  hands  over  the  authority  and  responsibility  of  providing  access  to  
resources  from  one  node  to  another  in  a  cluster.  This  may  happen  when  a  system  
admin  consciously  relocates  resources  to  another  node  to  realign  loads  for  
maintenance  purposes.  An  unexpected,  unplanned  downtime  could  also  affect  one  
node  due  to  hardware  failure  or  a  network  breakdown.  Furthermore,  service  failure  
on  an  active  node  can  initiate  failover  to  another  node.  
 
The  failover  process  takes  all  the  resources  in  the  instance  offline  in  an  order  that  is  
defined  by  the  instance’s  dependency  levels.  It  always  tries  dependent  resources  
first,  followed  by  the  resources  on  which  they  rely  on.  Let’s  say  that  a  service  
depends  on  a  cluster  disk  resource,  the  cluster  service  takes  the  service  offline  first  
to  allow  the  service  to  write  changes  to  the  disk  before  the  disk  is  taken  offline.  After  
all  the  resources  have  been  taken  offline,  the  cluster  service  seeks  to  resettle  the  
instance  to  another  node,  according  with  the  preferred  owner’s  order  listed  for  that  
cluster  role.  
 

  86  
After  all  the  resources  are  offline,  the  Cluster  service  attempts  to  transfer  the  
clustered  role  to  the  node  that  is  listed  next  on  the  clustered  role’s  list  of  preferred  
owners.  (See  the  screen  shot  for  Step  #  3  on  the  Configure  failover  and  failback  
settings  lab  below).  Once  the  cluster  service  moves  the  cluster  role  to  another  node,  
it  attempts  to  bring  all  the  resources  online  in  reverse  order  from  that  in  which  they  
were  taken  offline.  In  our  cluster  disk  and  service  example,  the  disk  comes  online  
first  and  then  the  service.  That  way,  the  service  will  not  try  to  write  to  a  cluster  disk  
that  is  not  available  yet.  Let’s  review  the  failover  and  failback  settings  in  the  next  
phase  of  our  lab.  
 
Configure  Failover  and  Failback  Settings  
 
1. In  the  Failover  Cluster  Manager,  click  Roles,  right-­‐click  GeneralFS,  and  then  
clickProperties.  

 
2. Click  the  Failover  tab  to  configure  the  number  of  times  that  the  cluster  
service  should  attempt  to  restart  or  failover  a  service  or  application  in  a  
given  time  period,  click  the  Failover  tab  and  specify  values  under  Failover.  
By  default,  a  maximum  of  one  failure  is  allow  in  a  6-­‐hour  period.  

  87  
  
3. Click  the  General  tab.  Select  both  ServerA1  and  ServerA2  as  preferred  
owners.  Notice  that  you  can  move  the  nodes  up  or  down  to  indicate  your  
level  of  preference.  

  88  
  
4. On  the  Failover  tab,  click  Allow  failback.  Click  Failback  between,  and  set  
values  to17  and  7  hours  to  allow  failback  to  occur  between  5:00  PM  and  
7:00  AM,  then  clickOK.  Keep  in  mind  that  you  must  configure  at  least  one  
preferred  owner  if  you  want  failback  to  take  place.  

  89  
  
Validate  the  Deployment  of  the  Highly  Available  File  Server  
To  validate  the  clustered  configuration,  let’s  access  the  file  share  to  create  data  and  
then  make  the  node  that  owns  the  clustered  file  server  role  unavailable.  
1. From  a  client  computer  in  the  network,  open  File  Explorer,  and  in  the  
Address  bar,  type  \\GeneralFS  and  press  Enter.  

  90  
  
1. Verify  that  you  can  access  the  Reports  folder.  

 
2. Create  a  text  document  inside  the  Reports  folder.  

  91  
  
3. On  ServerA1,  open  the  Failover  Cluster  Manager.  
Expand  ClusterA.abc.com  and  then  click  Roles.  Note  that  the  current  owner  
of  GeneralFS  is  ServerA2.  

 
4. Click  on  Nodes,  right-­‐click  ServerA2,  click  More  Actions,  and  then  
click  Stop  Cluster  Service.  

 
5. Click  on  Roles  to  confirm  that  GeneralFS  failed  over  to  ServerA1.  

  92  
  
6. Switch  to  the  network  client  computer  and  verify  that  you  can  still  access  
\\GeneralFS\  and  the  Reports  folder  data.  

 
 
Cluster  Shared  Volume  (CSV)  
 
In  a  traditional  Windows  failover  cluster  implementation,  multiple  nodes  cannot  
access  a  LUN  or  a  volume  on  the  shared  storage  simultaneously.  CSV  enables  

  93  
multiple  nodes  to  share  a  single  LUN  at  the  same  time.  Each  node  gains  exclusive  
access  to  individual  files  on  the  LUN  instead  of  the  whole  LUN.  CSVs  run  as  a  
distributed  file  access  solution  that  allow  multiple  nodes  in  the  cluster  
simultaneously  access  the  same  file  system  on  a  disk.  Only  NTFS  is  supported  on  
Windows  Server  2012,  but  Windows  Server  2012  R2  added  support  for  the  resilient  
file  system  (ReFS).  CSVs  can  only  be  configured  within  a  failover  cluster,  after  the  
disks  from  the  shared  storage  have  been  added  to  the  cluster.  The  following  steps  
show  how  to  create  a  clustered  shared  volume.  
 
1. From  Cluster  Manager,  select  Disks,  right-­‐click  on  Cluster  Disk  1,  and  
select  Add  to  Cluster  Shared  Volumes.  

 
2. Verify  that  Cluster  Disk  1  is  now  assigned  to  Cluster  Shared  Volume.  

 
 
Once  the  CSV  has  been  created,  it  can  be  used  to  store  the  highly  available  virtual  
machines  that  will  be  hosted  on  the  Hyper-­‐V  cluster.  
 
Hyper-­‐V  Clustering  

  94  
  
Hyper-­‐V  clustering  requires  that  the  cluster  nodes  be  physical  computers,  this  is  
known  as  host  clustering.  In  other  words,  it  is  not  possible  to  create  a  Hyper-­‐V  
cluster  using  virtual  machines  as  cluster  nodes,  also  referred  to  as  guest  clustering.  
Implementing  host  clustering  for  Hyper-­‐V  allows  you  to  configure  virtual  machines  
as  highly  available  resources.  In  this  case,  the  failover  protection  is  set  at  the  host-­‐
server  level.  In  consequence,  the  guest  operating  system  and  applications  that  are  
running  within  the  virtual  machines  do  not  have  to  be  cluster-­‐aware.  Nevertheless,  
the  virtual  machines  are  still  highly  available.  
 
Configuring  a  Highly  Available  Virtual  Machine  
 
For  our  lab,  the  Hyper-­‐V  role  has  already  been  installed  
on  ServerA1  and  ServerA2.  For  details  on  installing  and  configuring  the  Hyper-­‐V  
role,  see  this  article.  
 
1. In  the  Failover  Cluster  Manager  console,  right-­‐click  Roles,  
click  Virtual  Machinesand  select  New  Virtual  Machines.  

 
2. Select  ServerA1  as  the  cluster  node,  and  click  OK.  

  95  
  
3. In  the  New  Virtual  Machine  Wizard,  click  Next.  

  96  
  
4. On  the  Specify  Name  and  Location  page,  type  Score1  for  the  Name,  click  
Store  the  virtual  machine  in  a  different  location,  and  then  click  Browse.  

  97  
  
5. Browse  to  and  select  C:\ClusterStorage\Volume1\  and  then  click  Select  
Folder.  

  98  
  
6. On  the  Specify  Generation  page,  click  Next  

  99  
  
7. On  the  Assign  Memory  page,  type  2048,  make  sure  that  Use  Dynamic  
Memory  for  this  virtual  machine  is  checked  and  then  click  Next.  For  details  
on  Hyper-­‐V  memory  management,  see  this  article.  

  100  
  
8. On  the  Configure  Networking  page,  click  External,  and  then  click  Next.  

  101  
  
9. On  the  Connect  Virtual  Hard  Disk  page,  leave  the  default  settings  and  click  
Next.  

  102  
  
10. On  the  Installation  Options,  select  Install  an  operating  system  from  a  
bootable  CD/DVD-­‐ROM,  click  on  image  file  (.iso),  click  browse  and  load  a  
Windows  Server  2012  R2  ISO  file.  Click  Next.  

  103  
  
11. On  the  Completing  the  New  Virtual  Machine  Wizard  page,  click  Finish.  

  104  
  
12. On  the  Summary  page,  confirm  that  high  availability  was  successfully  
configured  for  the  role.  Click  Finish.  

  105  
  
13. In  the  Failover  Cluster  Manager  console,  click  Roles,  right-­‐click  Score1  and  
click  Start.  

  106  
  
14. In  the  Failover  Cluster  Manager  console,  click  Roles,  right-­‐click  Score1  and  
click  Connect  to  complete  the  guest  operating  system  installation.  

  107  
  
15. Once  the  installation  completes,  verify  that  you  can  access  the  Score1  virtual  
machine.  

  108  
  
Perform  a  Live  Migration  for  the  Virtual  Machine  
1. From  a  client  computer  in  the  network,  send  a  continuous  ping  to  Score1  by  
typing  the  following  from  a  command  prompt:  
Ping  –t  Score1  

 
2. In  the  Failover  Cluster  Manager,  expand  ClusterA.abc.com,  and  
click  Roles.  Then  right-­‐click  Score1,  select  Move,  select  Live  Migration,  and  
then  click  Select  Node.  

  109  
  
3. Click  ServerA2  and  click  OK.  

  110  
  
4. Get  back  to  the  client  computer  to  monitor  the  pings  to  Score1.  In  our  labs  
only  one  packet  was  lost,  but  the  ping  continued  as  the  Score1  virtual  
machine  failed  over  toServerA2.  

  111  
  
5. In  the  Failover  Cluster  Manager,  click  Roles  to  confirm  that  ServerA2  owns  
theScore1  virtual  machine  now.  

 
 
Closing  Remarks  
 
High  availability  is  one  of  the  top  priorities  in  many  data  centers  and  IT  
departments.  Windows  Server  2012  R2  provides  a  robust  clustering  solution  that  
can  be  used  with  many  applications  and  services.  File  servers  and  Hyper-­‐V  servers  
are  among  the  most  common  implementations  of  Windows  Failover  clustering.  
This  book  provides  a  hands-­‐on  approach  to  the  deployment  and  configuration  of  
highly  available  file  servers  and  host  clustering  with  Hyper-­‐V.  In  both  scenarios,  the  
aim  is  the  same:  Minimize  a  single  point  of  failure  and  detect  failures  as  they  
happen.  
 
 

  112