Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
Availability:
Manageability:
Server clusters allow administrators to quickly inspect the status of all cluster
resources and move workloads around onto different servers within the cluster. This
is useful for manual load balancing, and to perform "rolling updates" on the servers
without taking important data and applications offline.
Scalability:
Applications that can be partitioned can be spread across the servers of a cluster
allowing additional CPU and memory to be applied to a problem. As the problem
size increases, additional servers can be added to the cluster. A partitioned
application is one where the data (or function) can be split up into independent
units. For example, a customer database could be split into two units, one covering
customers with names beginning A thru L and the other for customers with names
beginning M thru Z.
A. Server clusters provide a highly available platform for mission critical, line of
business applications. These typically include database servers (such as Microsoft
SQL Server), mail and collaboration servers (such as Exchange Server) and
infrastructure servers such as file servers and print servers.
Q. How do Server clusters fit into the larger Windows high availability
story?
A. Server clusters are part of a much larger story for highly available applications
running on Microsoft products. Windows has two cluster technologies, server
clusters and Network Load Balancing (NLB). Server clusters are used to ensure that
stateful applications such as a database (e.g., SQL Server) can be kept highly
available by failing over the application from one server to another in the event of a
failure. NLB is used to distribute client requests across a set of identical servers.
NLB is particularly useful for ensuring that stateless applications such as a web
server (e.g., IIS) are highly available and can be scaled-out by adding additional
servers as the load increases.
The Windows platform also uses other technologies to ensure high availability and
scalability. For example, Active Directory is made highly available through
replication of the directory contents across a set of domain controllers.
Scale-out is a term used to describe the idea that an application can be scaled by
partitioning the workload and spreading it across a set of cooperating servers. If the
load increases, additional servers can be added to the set to provide additional
processing power and memory.
Server clusters are particularly useful for enhancing the availability of applications
that can be scaled out across a set of nodes by allowing the individual pieces or
partitions of a scale-out solution to be made highly available via failover.
A. Server clusters are not available in all Windows operating system products.
Server clusters are available in:
Server clusters are also available as part of the Server Appliance Kit, available to
OEMs for building embedded solutions based on the Windows operating system.
The complete cluster solution must be listed on the Cluster HCL list. The complete
solution includes the servers, the storage adapters, the interconnect type, the
storage controllers firmware and driver versions. All of the components must match
exactly, including any software, driver or firmware versions for the solution to be
qualified.
The HCL contains a set of qualified cluster components. A solution built from
qualified components does NOT imply that the solution is qualified.
The cluster component lists have been a source of confusion in the past and we will
be removing the cluster component lists (such as Cluster/RAID) from the HCL for
Windows Server 2003.
A. All qualified solutions appear on the Microsoft Hardware Compatibility list (HCL)
(http://go.microsoft.com/fwlink/?LinkID=67738). Only cluster solutions listed on the
HCL are supported by Microsoft.
· http://go.microsoft.com/fwlink/?LinkID=67742
· http://go.microsoft.com/fwlink/?LinkID=67740
· http://go.microsoft.com/fwlink/?LinkID=67741
Availability
A.
· No. Server clusters can dramatically reduce planned and unplanned downtime.
However, even with Server clusters, a server could still experience downtime from
the following events:
· Failures from which Server clusters can not recover: There are types of
failure that Server clusters do not protect against, such as loss of a disk not
protected by RAID, loss of power when a UPS is not used, or loss of a site when
there is no fast-recovery disaster recovery plan. Most of these can be survived with
minimal downtime if precautions are taken in advance.
A. There are three types of server applications that will benefit from Server clusters:
1. "In the box" services provided by the Windows platform: For example: File shares,
print queues, Microsoft Message Queue Server (MSMQ) services, and Component
Services (formerly known as Transaction Server) services.
2. Generic applications: Server clusters include a point-and-click wizard for setting
up any well-behaved server application for basic error detection, automatic
recovery, and operator-initiated management (e.g., move from one server to the
other). A "well behaved" server application is one which keeps a recoverable state
on cluster disk(s), and whose client can gracefully handle a pause in service as the
application is automatically re-started.
· setup new applications, file shares, print queues, etc. for high availability
· take applications offline, bring them back online, and move them from one server
to another
The ability to graphically move workload from one server to another with only a
momentary pause in service (typically less than a minute), means administrators
can easily unload servers for planned maintenance without taking important data
and applications offline for long periods of time.
A. Yes, an authorized cluster administrator can run Cluster Administrator from any
Windows NT or Windows 2000 Workstation or Server, any Windows XP machine or
any Windows Server 2003 on the network. The cluster.exe command line tool can
be run remotely from any Windows 2000 Workstation or Server, any Windows XP
machine or any Windows Server 2003 on the network.
A. Yes, with Windows Server 2003, Cluster administrator and the cluster.exe
command line tool can also be used to remotely setup and configure a Server
cluster (e.g., create a new cluster, add a new server to an existing cluster or remove
servers from a cluster).
Q. Is the server cluster software installed by default?
A. On Windows NT and Windows 2000, the Server cluster software is not installed by
default. On Windows NT you must install the Enterprise Edition CD. With Windows
2000, you must install the Server cluster software using the optional component
management tool.
With Windows Server 2003, the Server cluster software is installed by default on
Enterprise Edition and Datacenter Edition. The cluster software is NOT configured by
default and will not start until the server is either used to create a new cluster or
the server is added to an existing cluster. In Windows Server 2003, you must use
Cluster Administrator or the Cluster.exe command line tool to configure a cluster.
A. It depends on the application. Each application that can be failed over between
servers in a cluster must be available on all servers in the cluster. Historically,
application setup has not been cluster-aware and therefore the application must be
installed separately on each server.
With more recent versions of some applications, for example SQL Server 2000, the
application setup is aware of Server clusters. In the case of Microsoft SQL Server
2000 setup, the appropriate files are copied to all servers and registry settings and
other SQL Server configuration is done just once.
· In Windows 2000 and Windows Server 2003, there is a scriptable COM interface to
the Server cluster APIs. This allows VBScript or any other scripting language
supported by Windows to call the cluster APIs. These APIs provide a way to change
the state of the cluster as well as return data about the resources or applications in
a cluster. For more information about the cluster server APIs, see the Platform SDK,
it has comprehensive documentation for the cluster APIs and the COM (automation
server) APIs.
· In Windows Server 2003, there is a WMI provider for Server clusters that allows
WMI scripts to manage the cluster. For more information about the cluster server
WMI schema, see the Platform SDK.
A. Yes, Server clusters have a command line tool cluster.exe that can be used to
manage the cluster. With Windows Server 2003, this command line tool can also be
used to create new clusters, add servers to existing clusters and remove servers
from clusters. Almost all of the functionality provided by Cluster Administrator is
available through cluster.exe in Windows Server 2003.
A. Yes, in Windows Server 2003, there is a WMI provider that allows a Server cluster
to be managed. In addition, all the Server cluster events (such as server up and
server down, resource online, offline, failed etc.) are available through WMI events.
A. Yes, in Windows Server 2003, all of the Server cluster events (such as server up
and server down, resource online, offline, failed etc.) are available through WMI
events.
A. You can apply Group Policy to cluster servers. There are a few things to
remember. Applications failover from one server to another in a cluster and will
typically expect the same policies to be in effect no matter where they are hosted.
You should ensure that all cluster servers have the same set of group policies
applied to them.
With Windows Server 2003 and Windows 2000 SP3 onwards, virtual servers can be
published in active directory. You should NOT apply group policies to a virtual server
computer object. The policy will only be applied to the server that is currently
hosting the virtual server and all policy settings may be lost if the application fails
over.
A. No, at this time, SMS is not supported for deploying applications across a cluster.
A. No, Application Center 2000 provides a set of features that are intended for
managing servers hosting web server front-end and middle-tier business logic.
Server clusters are typically deployed to ensure high availability of the back-end
database engine.
Server clusters allows rolling upgrades for a new release and the previous version.
A. Server clusters allow rolling upgrades for a new release and the previous version.
The following rolling upgrades are supported:
A. Yes, the Server cluster tools allow a mixed version cluster to be managed from a
single point. During a rolling upgrade, a cluster may contain different versions of
the operating system. As an example Windows 2000 and Windows Server 2003 can
co-exist in the same cluster. The administration tools provided with Windows Server
2003 allow such a mixed-version cluster to be managed.
A. Server clusters allow administrators to quickly inspect the status of all cluster
resources, and move workload around onto different servers within the cluster. This
is useful for manual load balancing, and to perform "rolling updates" on the servers
without taking important data and applications offline.
Scalability (Server Clusters: Frequently Asked Questions for Windows 2000 and
Windows Server 2003)
A. The primary goal of Server clusters is to provide a highly available platform for
applications.
There are some types of applications which can be scaled-out to take advantage of
a set of machines. More machines can be added to the set to increase the CPU or
memory available to the application. Applications of this type are typically scaled by
partitioning the data set. For example, a SQL Server database may be scaled out by
partitioning the database into pieces and then using database views to give the
client applications the illusion of a single database.
There are no automated tools provided with the operating system to automatically
load balance applications and no enhanced failover policies that use load to
determine the best placement for an application.
Server cluster Concepts (Server Clusters: Frequently Asked Questions for Windows
2000 and Windows Server 2003)
Q. What hardware do you need to build a Server cluster?
A. The most important criteria for Server cluster hardware is that it be included in a
validated Cluster configuration on the Microsoft Hardware Compatibility List (HCL),
indicating it has passed the Microsoft Cluster Hardware Compatibility Test. All
qualified solutions appear on the Microsoft HCL (http://go.microsoft.com/fwlink/?
linkid=67738). Only cluster solutions listed on the HCL are supported by Microsoft.
In general, the criteria for building a server cluster include the following:
· Servers: Two or more PCI-based machines running one of the operating system
releases that support Server clusters (see below). Server clusters can run on all
hardware architectures supported by the base Windows operating system, however,
you cannot mix 32-bit and 64-bit architectures in the same cluster.
SCSI is supported for 2-node cluster configurations only. Fibre channel arbitrated
loop is supported for 2-node clusters only. Microsoft recommends using fibre
channel switched fabrics for clusters of more than two nodes.
· Network: Each server needs at least two network cards. Typically, one is the public
network and the other is a private network between the two nodes. A static IP
address is needed for each group of applications that move as a unit between
nodes. Server clusters can project the identity of multiple servers from a single
cluster by using multiple IP addresses and computer names: this is known as a
virtual server.
Server clusters provides some generic plug-ins that can be used to make existing
applications cluster-aware very quickly, known as Generic Service and Generic
Application. With Windows Server 2003, a Generic Script resource plug-in was
added that allows the resource dll to be written in any scripting language supported
by the Windows operating system.
A. A resource group is a collection of one or more resources that are managed and
monitored as a single unit. A resource group can be started or stopped. If a resource
group is started, each resource in the group is started (taking into account any start
order defined by the dependencies between resources in the group). If a resource
group is stopped, all of the resources in the group are stopped. Dependencies
between resources cannot span a group. In other words, the set of resources within
a group is an autonomous unit that can be started and stopped independently from
any other group. A group is a single, indivisible unit that is hosted on one server in a
Server cluster at any point in time and it is the unit of failover.
Q. What is failover?
A. Server clusters monitor the health of the nodes in the cluster and the resources
in the cluster. In the event of a server failure, the cluster software re-starts the
failed server's workload on one or more of the remaining servers. If an individual
resource or application fails (but the server does not), Server clusters will typically
try to re-start the application on the same server; if that fails, it moves the
application's resources and re-starts it on the other server. The process of detecting
failures and restarting the application on another server in the cluster is known as
failover.
The cluster administrator can set various recovery policies such as whether or not
to re-start an application on the same server, and whether or not to automatically
"failback" (re-balance) workloads when a failed server comes back online.
A. Server clusters do not require any special software on client computers, so the
user experience during failover depends on the nature of the client side of their
client-server application. Client reconnection can be made transparent, because the
Server clusters software has restarted the applications, file shares, etc. at exactly
the same IP address.
Q. What is failback?
A. In the event of the failure of a server in a cluster, the applications and resources
are failed over to another node in the cluster. When the failed node rejoins the
cluster (after reboot for example), that node now is free to be used by applications.
A cluster administrator can set policies on resources and resource groups that allow
an application to automatically move back to a node if it becomes available, thus
automatically taking advantage of a node rejoining the cluster. These policies are
known as failback policies. You should take care when defining automatic failback
policies since depending on the application, automatically moving the application
(which was working just fine) may have undesirable consequences on the clients
using the applications.
Q. When an application restarts after failover, does it restore the application state at
the time of failure?
A. No, Server clusters provide a fast crash restart mechanism. When an application
is failed over and restarted, the application is restarted from scratch. Any persistent
data written out to a database or to files is available to the application, but any in-
memory state that the application had before the failover is lost.
Q. What is a Quorum Resource and how does it help Server clusters provide high
availability?
A. Server clusters require a quorum resource to function. The quorum resource, like
any other resource, is a resource which can only be owned by one server at a time,
and for which servers can negotiate for ownership. Negotiating for the quorum
resource allows Server clusters to avoid "split-brain" situations where the servers
are active and think the other servers are down. This can happen when, for
example, the cluster interconnect is lost and network response time is problematic.
The quorum resource is used to store the definitive copy of the cluster configuration
so that regardless of any sequence of failures, the cluster configuration will always
remain consistent.
A. Active/Active and Active/Passive are terms used to describe how applications are
deployed in a cluster. Unfortunately, they mean different things to different people
and so the terms tend to cause confusion.
From the perspective of a single application or database:
· Active/Active means that the same application or pieces of the same service can
be run concurrently on different nodes in the cluster. For example SQL Server 2000
can be configured such that the database is partitioned and each node can be
running a single instance of the database. SQL Server provides the notion of views
to provide a single image of the entire database.
· Active/Passive means that only one node in the cluster can be hosting the given
application. For example, a single file share is active/passive. Any given file share
can only be hosted on one node at a time.
· Active/Passive means that only one instance of a service can be running anywhere
in the cluster. For example, there must only be a single instance of the DHCP
service running in the cluster at any point in time.
· Active/Active means that all nodes in the cluster are running applications. These
may be multiple instances of the same application or different applications (for
example, in a 2-node cluster, WINS may be running on one node and DHCP may be
running on the other node).
· Active/Passive means that one of the cluster nodes is spare and not being used to
host applications.
Server clusters support all of these different combinations; the terms are really
about how specific applications or sets of applications are deployed.
With the advent of more than two servers in a cluster, starting with Windows 2000
Datacenter, the term active/active is confusing because there may be four servers.
When there are multiple servers, the set of options available for deployment
becomes more flexible, allowing different configurations such as N+I.
A. Failover is the mechanism that instance applications and the individual partitions
of a partitioned application typically employ for high availability (the term Pack has
been coined to describe a highly available, single instance application or partition).
In a 2-node cluster, defining failover policies is trivial. If one node fails, the only
option is to failover to the remaining node. As the size of a cluster increases,
different failover policies are possible and each one has different characteristics.
Failover Pairs
In a large cluster, failover policies can be defined such that each application is set
to failover between two nodes. The simple example below shows two applications
App1 and App2 in a 4-node cluster.
Pro
Pro
Very easy to plan capacity. Each node is sized based on the application that it will
need to host (just like a 2-node cluster hosting one application).
Pro
Effect of a node failure on availability and performance of the system is very easy to
determine.
Pro
Get the flexibility of a larger cluster. In the event that a node is taken out for
maintenance, the buddy for a given application can be changed dynamically (may
end up with standby policy below).
Con
In simple configurations such as the one above, only 50% of the capacity of the
cluster is in use.
Con
Hot-Standby Server
To reduce the overhead of failover pairs, the spare node for each pair may be
consolidated into a single node, providing a hot standby server that is capable of
picking up the work in the event of a failure.
Pro
Good for clusters that are supporting heavy-weight applications such as databases.
This configuration ensures that in the event of a single failure, two applications will
not be hosted on the same node.
Pro
Very easy to plan capacity. Each node is sized based on the application that it will
need to host, the spare is sized to be the maximum of the other nodes.
Pro
Effect of a node failure on availability and performance of the system is very easy to
determine.
Con
Con
Does not really handle multiple failures well. This may be an issue during scheduled
maintenance where the spare may be in use.
Server clusters support standby servers today using a combination of the possible
owners list and the preferred owners list. The preferred node should be set to the
node that the application will run on by default and the possible owners for a given
resource should be set to the preferred node and the spare node.
N+I
Standby server works well for 4-node clusters in some configurations, however, its
ability to handle multiple failures is limited. N+I configurations are an extension of
the standby server concept where there are N nodes hosting applications and I
nodes spare.
Pro
Good for clusters that are supporting heavy-weight applications such as databases
or Exchange. This configuration ensures that in the event of a failure, an application
instance will failover to a spare node, not one that is already in use.
Pro
Very easy to plan capacity. Each node is sized based on the application that it will
need to host.
Pro
Effect of a node failure on availability and performance of the system is very easy to
determine.
Pro
Con
Does not really handle multiple applications running in the same cluster well. This
policy is best suited to applications running on a dedicated cluster.
Server cluster supports N+I scenarios in the Windows Server 2003 release using a
cluster group public property AntiAffinityClassNames. This property can contain an
arbitrary string of characters. In the event of a failover, if a group being failed over
has a non-empty string in the AntiAffinityClassNames property, the failover
manager will check all other nodes. If there are any nodes in the possible owners
list for the resource that are NOT hosting a group with the same value in
AntiAffinityClassNames, then those nodes are considered a good target for failover.
If all nodes in the cluster are hosting groups that contain the same value in the
AntiAffinityClassNames property, then the preferred node list is used to select a
failover target.
Failover Ring
Failover rings allow each node in the cluster to run an application instance. In the
event of a failure, the application on the failed node is moved to the next node in
sequence.
Pro
Good for clusters that are supporting several small application instances where the
capacity of any node is large enough to support several at the same time.
Pro
Pro
Con
Configuration does not work well for all cases of multiple failures. If one Node 1 fails,
Node 2 will host two application instances and Nodes 3 and 4 will host one
application instance. If Node 2 then fails, Node 3 will be hosting three application
instances and Node 4 will be hosting one instance
Con
Not well suited to heavy-weight applications since multiple instances may end up
being hosted on the same node even if there are lightly-loaded nodes.
Failover rings are supported by server clusters on the Windows Server 2003 release.
This is done by defining the order of failover for a given group using the preferred
owner list. A node order should be chosen and then the preferred node list should
be set up with each group starting at a different node.
Random
In large clusters or even 4-node clusters that are running several applications,
defining specific failover targets or policies for each application instance can be
extremely cumbersome and error prone. The best policy in some cases is to allow
the target to be chosen at random, with a statistical probability that this will spread
the load around the cluster in the event of a failure.
Pro
Good for clusters that are supporting several small application instances where the
capacity of any node is large enough to support several at the same time.
Pro
Does not require an administrator to decide where any given application should
failover to.
Pro
Provided that there are sufficient applications or the applications are partitioned
finely enough, this provides a good mechanism to statistically load balance the
applications across the cluster in the event of a failure.
Pro
Pro
Very well tuned to handling multiple applications or many instances of the same
application running in the same cluster well.
Con
Can be difficult to plan capacity. There is no real guarantee that the load will be
balanced across the cluster.
Con
Effect on performance of a node failure is not easy to predict.
Con
Not well suited to heavy-weight applications since multiple instances may end up
being hosted on the same node even if there are lightly-loaded nodes.
The Windows Server 2003 release of server clusters randomizes the failover target
in the event of node failure. Each resource group that has an empty preferred
owners list will be failed over to a random node in the cluster in the event that the
node currently hosting it fails.
Customized control
There are some cases where specific nodes may be preferred for a given application
instance.
Pro
Administrator has full control over what happens when a failure occurs.
Pro
Con
With many applications running in a cluster, defining a good policy for failures can
be extremely complex.
Con
Server clusters provide full control over the order of failover using the preferred
node list feature. The full semantics of the preferred node list can be defined as:
Group is moved to highest node in preferred node list that is up and running in the
cluster.
Group is moved to highest node in preferred node list that is up and running in the
cluster.
If no nodes in the preferred node list are up and running, the group is moved to a
random node.
If the node that was hosting the group is the last on the list or was not in the
preferred node list, the group is moved to a random node.
Empty
A. The theoretical limit for the number of resources in a cluster is 1,674; however,
you should be aware that the cluster service periodically polls the resources to
ensure they are alive. As the number of resources increases, the overhead of this
polling also increases.
Server Requirements
A. The cluster hardware compatibility test does not require that all the servers in a
qualified cluster be identical. As cluster sizes increase and therefore the investment
in hardware increases, it is likely that different types of servers will appear in a
single cluster.
The qualification process and the listing process are being improved to allow
heterogeneous solutions to be more easily defined and qualified. This is particularly
important to OEMs where server families change relatively often and therefore the
additional qualification passes required increases dramatically with the current
process. The server itself has never been an issue during qualification, it is typically
the HBA or other piece of the storage subsystem, and therefore there is no real
reason to mandate exact servers in a given qualified solution.
Q. Can 32-bit servers and 64-bit servers be mixed in the same Server cluster?
A. No, a single Server cluster must contain all 32-bit servers or all 64-bit servers.
A. All qualified solutions appear on the Microsoft Hardware Compatibility list (HCL)
(http://go.microsoft.com/fwlink/?linkid=67738). Only cluster solutions listed on the
HCL are supported by Microsoft. You can use any servers that are listed as part of a
configuration to build a complete solution.
Interconnects
Q. What types of networks are required for cluster interconnects?
A. The network interface controllers along with any other components used in
certified cluster configurations must have the Windows logo and appear on the
Microsoft Hardware Compatibility List. The interconnect itself must support TCP/IP
and UDP traffic and must appear as a single, non-routed LAN segment or subnet.
A. The Server cluster code itself does not use WinSock direct path for intra-cluster
communication. All communication between cluster nodes is over TCP/IP or UDP.
Server clusters can use, but may not take advantage of any high-bandwidth, low
latency connection between nodes that looks like a standard NDIS network adapter.
· You can create different IP address resources that can be associated with different
adapters; however, there is no way to make a resource or application dependent on
the two networks so that if one fails, the application will continue to be available. In
Server clusters, the dependencies must all be online for the dependent application
to be online.
For future versions of the cluster technology, we are working on a feature to allow
more flexible dependencies such as: a resource can depend on A OR B for it to be
online.
A. Yes.
You should configure the private network as Internal Cluster Communication Only
and the public network as All Communications.
A. The cluster service uses the cluster network for the following intra-cluster traffic:
A. Cluster-aware applications must use protocols based on top of TCP/IP. The cluster
software only supports the TCP/IP protocols for failover out-of -the-box.
A. Yes, in Windows 2000 and above, additional heartbeats are sent across the public
networks to detect public network and/or network adapter failures and to cause
applications to failover if the node they are currently hosted on cannot
communicate with the other nodes.
A. Yes, however there are caveats. The use of network adapter teaming on all
cluster networks concurrently is not supported. At least one of the cluster networks
that are enabled for internal communication between cluster nodes must not be
teamed. Typically, the un-teamed network is a private interconnect dedicated to
this type of communication. The use of network adapter teaming on other cluster
networks is acceptable; however, if communication problems occur on a teamed
network, Microsoft Product Support Services may require that teaming be disabled.
If this action resolves the problem or issue, then you must seek further assistance
from the manufacturer of the teaming solution.
A. Yes, addresses may be assigned to the physical nodes dynamically by DHCP, but
manual configuration with static addresses is recommended.
In Windows Server 2003, the cluster service does not require NetBIOS. A basic
principle of server security is to disable unneeded services. To determine whether
to disable NetBIOS, consider the following:
· Some services and applications other than the cluster service use NetBIOS. Review
all the ways a clustered server functions before disabling NetBIOS on it.
· With NetBIOS disabled, you will not be able to use the Browse function in Cluster
Administrator when opening a connection to a cluster. Cluster Administrator uses
NetBIOS to enumerate all clusters in a domain.
· With NetBIOS disabled, Cluster Administrator does not work if a cluster name is
specified.
You can control the NetBIOS setting for the cluster through the Cluster IP Address
resource property sheet (parameters).
A. As part of its automatic recovery procedures, the cluster service will issue IETF
standard ARP "flush" commands to routers to flush the machine addresses related
to IP addresses that are being moved to a different server.
Q. How does the Address Resolution Protocol (ARP) cause systems on a LAN to
update their tables that translate IP addresses to physical machine (MAC)
addresses?
A. The ARP specification states that all systems receiving an ARP request must
update their physical address mapping for the source of the request. The source IP
address and physical network address are contained in the request. As part of the IP
address registration process, the Windows TCP/IP driver broadcasts an ARP request
on the appropriate LAN several times. This request asks the owner of the specified
IP address to respond with its physical network address. By issuing a request for the
IP address being registered, Windows can detect IP address conflicts; if a response
is received, the address cannot be safely used. When it issues this request, though,
Windows specifies the IP address being registered as the source of the request.
Thus, all systems on the network will update their ARP cache entries for the
specified address, and the registering system becomes the new owner of the
address.
Note that if an address conflict does occur, the responding system can send out
another ARP request for the same address, forcing the other systems on the subnet
to update their caches again. Windows does this when it detects a conflict with an
address that it has successfully registered.
Q. Server clusters use ARP broadcasts to re-set MAC addresses, but ARP broadcasts
don't pass routers. So what about clients behind the routers?
A. If the clients were behind routers, they would be using the router(s) to access the
subnet where the cluster servers were located. Accordingly, the clients would use
their router (gateway) to pass the packets to the routers through whatever route
(OSPF, RIP, etc) is designated. The end result is that their packet is forwarded to a
router on the same subnet as the cluster. This router's ARP cache is consistent with
the MAC address(es) that have been modified during a failover. Packets thereby get
to the correct Virtual server, without the remote clients ever having seen the
original ARP broadcast.
Storage (Server Clusters: Frequently Asked Questions for Windows 2000 and
Windows Server 2003)
There are many storage questions, these questions are categorized as general
questions, questions about deploying Server clusters on a storage area network
(SAN) and network attached storage (NAS) questions.
A. Cluster Server does not limit the type of storage interconnects supported;
however, there are some requirements of the storage subsystem that limit the
types from a practical perspective. For example, all of the cluster nodes should be
able to access the storage device. This typically impacts the interconnect since only
interconnects that allow multiple initiators (i.e. nodes) can be used. The set of
interconnects that are currently part of qualified configurations on the HCL include:
SCSI (of various flavors), Fibre channel arbitrated loop and fibre channel switched
fabrics.
Remember that only clusters where the full configuration appears on the Cluster
HCL are supported by Microsoft.
A. You must make sure that all of the devices on the SCSI bus have different SCSI
Ids. By default, SCSI adapters tend to have Id 7. You should make sure that the
adapters in each node have different Ids. Likewise, the disks should be given unique
SCSI Ids on the bus.
For a SCSI bus to work correctly it must be terminated. There are many ways to
terminate the bus, both internally (at the host adapter) and externally (using Y
cables). To ensure that the cluster can survive different types of failures
(specifically being able to power down one of the nodes), the SCSI bus should be
terminated using passive components such as a Y cable. Internal termination, which
requires the adapter to be powered up, is not recommended.
Note
Microsoft only allows 2-node clusters to be built using SCSI storage interconnects.
A. Yes, Microsoft only allows 2-node clusters to be built using FC-AL storage
interconnects. Multiple clusters on a single fibre channel loop are NOT supported.
A. Yes, there is a special device qualification test for storage controllers that
ensures they respond correctly if multiple clusters are attached to the same
controller. For multiple clusters to be connected to the same controller the storage
controller MUST appear on the Multi-cluster device Hardware Compatibility List
(HCL) AND each of the individual end-to-end cluster solutions must appear on the
Cluster Hardware Compatibility List. For example: EMC Symmetrix 5.0 is on the
multi-cluster device HCL list. Multiple clusters (say a Dell PowerEdge cluster and a
Compaq Proliant cluster) can be connected to the EMC Symmetrix storage controller
as long as Dell PowerEdge + EMC Symmetrix AND Compaq Proliant + EMC
Symmetrix as both on the cluster HCL.
Q. Will failover occur if the storage cable is pulled from the host bus adapter (HBA)?
A. If the storage cable is pulled from the host bus adapter (HBA), there may be a
pause before the adapter reacts to losing the connection, however, once the HBA
has detected the communication failure, the disk resources within the cluster using
the specific HBA will fail. This will trigger a failover to occur and the resource will be
brought back on line on another node in the cluster.
If the storage cable is reconnected, the Windows operating system may not rescan
for new hardware automatically (this depends on the driver used for the adapter).
You may need to manually initiate a rescan for new devices. Once the rescan is
done, the node can host any of the physical disk resources. If failback policies are
set, any resources that failed over when the cable was removed will failback to the
node when the cable is replaced.
Note
An HBA) is the storage interface that is deployed in the server. Typically this is a PCI
card that connects the server to the storage fabric.
A. No, Cluster server protects against server failure, operating system or application
failure and planned downtime due to maintenance. Microsoft strongly suggests that
application and user data is protected against disk failure using redundancy
techniques such as mirroring, RAID or replication either in hardware or in software.
A. Yes, Microsoft strongly suggests that application and user data is protected
against disk failure using redundancy techniques such as mirroring, RAID or
replication either in hardware or in software.
A. Windows server products shipped from Microsoft do not provide support for
dynamic disks in a server cluster environment. The Volume Manager for Windows
2000 add-on product from Veritas can be used to add the dynamic disk features to
a server cluster. When the Veritas Volume Manager product is installed on a cluster,
Veritas should be the first point of support for cluster issues.
A. Yes, cluster disks can be extended without rebooting if the storage controller
supports dynamic expansion of the underlying physical disk. Many new storage
controllers virtualize the Logical Units (LUNs) presented to the operating system and
these controllers allow LUNs to be grown online from the storage controller
management console. Microsoft provides a tool called DiskPart that allows volumes
or partitions to be grown online to take advantage of the newly created space on
the disk without disruption to applications or users using the disk. There are
separate versions of DiskPart for Windows 2000 and Windows Server 2003. The
Windows 2000 version is available as a free download on the web and the Windows
Server 2003 version is shipped on the distribution media.
Note
A. Yes, you can insert a new disk or create a new LUN and make that visible to the
cluster nodes. You should only make the disk visible to one node in the cluster and
then create a cluster resource to protect that disk. Once the disk is protected, you
can make the LUN visible to other nodes in the cluster. In some cases you may need
to do a rescan in device manager to find the new disk. In other cases (especially
with fibre channel) the disk may be automatically detected.
A. Yes
A. Microsoft recommends that all partitions on the cluster disks be formatted with
the NTFS file system. This is for two reasons. Firstly, NTFS provides access controls
that can be used to secure the data on the disk. Secondly, NTFS can recover from
volumes that have been forcibly dismounted; other file systems may become
corrupt if they are forcibly dismounted.
Server clusters only support Master Boot Record (MBR) format disks. Cluster disks
cannot be GPT format.
Q. Can tape devices or other non-disk devices be attached to the same storage bus
as the Cluster Disks?
A. It depends on the storage interconnect. Server clusters use SCSI reserve and
reset to arbitrate for cluster disks. In Windows NT and Windows 2000 cluster server
performs an untargeted bus reset. In Windows Server 2003 it is possible to target
the reset, however, it may fallback to an untargeted reset. If a tape device receives
a reset, this will typically trigger the tape to rewind.
Server cluster does not provide any arbitration mechanism for tape devices that are
visible from multiple servers, therefore tape devices are not protected against
concurrent access from multiple servers.
Microsoft does NOT support attaching a tape device to the SCSI bus containing the
cluster disks in the case of a SCSI cluster or the loop in and fibre channel arbitrated
loop.
Tape devices can be attached to a switched fabric as long as they are not visible
through the same adapters as the cluster disks. This can be achieved by either
putting the tape drive in a different zone to the cluster disks or by LUN masking
techniques.
A. Windows server products shipped from Microsoft do not provide support for
software RAID or mirroring, however, there are 3rd party products that provide this
functionality in a clustered environment.
A. Yes, the Virtual Snapshot Service is new with Windows Server 2003 and provides
basic snapshot capabilities that are used by backup applications to create
consistent, single point in time backups. The cluster service has a VSS provider that
allows the cluster service configuration to be snapshoted and stored as part of the
system state by these backup applications.
A. No, Timewarp is a new feature in Windows Server 2003 that allows persistent
snapshot to be created and exposed to clients. TImewarp makes use of features
that are not cluster-aware and it is not supported in a cluster at this time.
A. Yes, you can use facilities in the latest storage controllers to create snapshots of
existing volumes. Note, however, when you create a snapshot of a disk you should
NOT expose the snapshot back to the same cluster as the original disk. The cluster
service uses the disk signature to uniquely identify a disk. With a snapshot, the disk
and the snapshot have the same disk signature.
A. Modern storage controllers provide a virtual view of the storage itself. A physical
RAID set can be carved into multiple logical units that are exposed to the operating
system as individual disks or LUNs. If you intend to carve up physical disks in this
way and expose them as independent LUNs to the hosts, you should think carefully
about the IO characteristics and the failure characteristics remember underneath,
there is only a finite bandwidth to each spindle.
Microsoft recommends that you do not create a LUN for use as the quorum disk
from the same underlying physical disks that you will be using for applications. The
availability of the cluster is directly related to the availability of the quorum disk. If
I/Os to the quorum disk take too long, the cluster server will assume that the
quorum disk has failed and initiate a failover of the quorum device. At that point, all
other cluster related activity is suspended until the quorum device is brought back
online.
· FTEdit tool along with some manipulate of the registry. This is covered in article
243195 in the Microsoft Knowledge Base (http://go.microsoft.com/fwlink/?
linkid=67761).
· Windows 2000
· DumpCfg.
A. Yes, Microsoft fully supports storage area networks both as part of the base
Windows platform and as part of a complete Windows Clustering high availability
solution.
A. One or more Server clusters can be deployed in a single SAN environment along
with standalone Windows servers and/or with other non-Windows platforms.
A.
· The cluster disks for each cluster on a SAN MUST be deployed in their own zone.
All host bus adapters (HBAs) in a single cluster must be the same type and at the
same firmware revision level. Many storage and switch vendors require that ALL
HBAs on the same zone, and in some cases the same fabric, are the same type and
have the same firmware revision number.
· All storage device drivers and HBA device drivers in a cluster must be at the same
software version.
· When adding a new server to a SAN, ensure that the HBA is appropriate for the
topology. In some configurations, adding an arbitrated loop HBA to a switched fibre
fabric can result in widespread failures of the storage fabric. There have been real-
world examples of this causing serious downtime.
Note
An HBA is the storage interface that is deployed in the server. Typically this is a PCI
card that connects the server to the storage fabric.
A. The cluster uses mechanisms to protect access to the disks that can have an
adverse effect on other clusters that are in the same zone. By using zoning to
separate the cluster traffic from other cluster or non-cluster traffic, there is no
chance of interference.
The diagram shows two clusters sharing a single storage controller. Each cluster is
in its own zone. The LUNs presented by the storage controller must be allocated to
individual clusters using fine-grained security provided by the storage controller
itself. LUNs must be setup so that every LUN for a specific cluster is visible and
accessible from all nodes of the cluster. A LUN should only be visible to one cluster
at a time. The cluster software itself takes care of ensuring that although LUNs are
visible to all cluster nodes, only one node in the cluster accesses and mounts the
disk at any point in time.
The multi-cluster device test used to qualify storage configurations for the multi-
cluster HCL list tests the isolation guarantees when multiple clusters are connected
to a single storage controller in this way.
Server clusters require that the startup disk, page file disk and system disk be on a
different storage bus to the cluster server disks. To boot from a SAN, you must have
a separate HBA for the boot, system and pagefile disks than the cluster disks. You
MUST ensure that the cluster disks are isolated from the boot, system and pagefile
disks by zoning the cluster disks into their own zone.
A. Microsoft does not provide a generic driver that allows multiple paths to the
storage infrastructure for high availability; however, several vendors have built their
own proprietary drivers that allow multiple HBAs and SAN fabrics to be used as a
highly available storage infrastructure. For a Server cluster that has multi-path
drivers to be considered supported, the multipath driver MUST appear as part of the
complete cluster solution on the Cluster Hardware Compatibility List (HCL). NOTE:
The driver version is VERY important and it MUST match the qualified version on the
HCL.
Q. Can the startup disk, pagefile disks and the cluster disks be on the same SAN
fabric?
A. No, in Windows Server 2003, there is a registry key that allows the startup disk,
pagefile disks, and cluster disks to be on the same bus. This feature is enabled by a
registry key, which helps ensure that it is not accidentally enabled by customers
who do not understand the implications of this configuration. It is intended for OEMs
to ship qualified and tested configurations and not for a typical end-user or
administrator to set up in an ad hoc manner.
In the original release of Windows Server 2003, the registry key is:
HKLM\SYSTEM\CurrentControlSet\Services\ClusSvc\Parameters\ManageDisksOnSyst
emBuses 0x01
In Windows Server 2003 with Service Pack 1 (SP1), the registry key is:
HKLM\SYSTEM\CurrentControlSet\Services\ClusDisk\Parameters\ManageDisksOnSyst
emBuses 0x01
In Windows Server 2003 SP1, the key path was changed to use “Clusdisk” as a
subkey instead of “ClusSvc.” This change was made to avoid issues during setup.
However, the change is backward compatible, and systems that use the old key
locations do not need to be modified.
A. No, the cluster disk arbitration mechanism uses SCSI reserve and release
operations. Once a server arbitrates for a cluster disk, that disk cannot be accessed
by any other server on the storage network.
A. Yes, providing the applications can store data on file shares and the file shares
are accessible to the applications as they failover across the cluster, there is no
reason why NAS cannot be used as the storage solution in a cluster.
In Windows Server 2003, we are providing a new quorum resource Majority Node
Set that can be used to remove the need for a shared disk for the quorum resource.
If you combine NAS storage with Majority Node Set quorum, you can build a failover
cluster that does not require shared disks in the traditional sense of SCSI or SAN.
A. The Windows 2000 resource kit contains a tool ClusTool that can be used to
migrate file share settings from a single node to a cluster environment.
A. No, the file replication service (FRS) provided by Windows cannot be used to
replicate a clustered file share. This means that clustered file shares cannot be the
source or target for redundant links in a DFS tree. See the online documentation for
DFS for more details.
A. Yes, in Windows Server 2003, you can select client-side caching (also know as
offline folders) for clustered file shares.
A. With Windows Server 2003, the encrypting file system (EFS) is supported on
clustered file shares. To enable EFS on a clustered file share, you must perform a
number of tasks to configure the environment correctly:
· EFS can only be enabled on file shares when the virtual server has Kerberos
enabled. By default, Kerberos is not enabled on a virtual server. To enable Kerberos
you must check the Enable Kerberos Authentication check box on the network name
resource that will be used to connect to the clustered file share. NOTE: Enabling
Kerberos on a network name has a number of implications that you should ensure
you fully understand before checking the box.
· All cluster node computer accounts, as well as the virtual server computer
account, must be trusted for delegation. See online help for how to do this.
· To ensure that the users private keys are available to all nodes in the cluster, you
must enable roaming profiles for users who want to store data using EFS. See online
help for how to enable roaming profiles.
Once the cluster file shares have been created and the configuration steps above
carried out, users data can be stored in encrypted files for added security.
A. The number of file shares in a cluster depends on the number of nodes in the
cluster and the failure scenarios that you are trying to protect against. A single
server has a limit for the number of file shares it can support so you need to take
that into account when planning your cluster.
In a 2-node cluster, if one node fails, the remaining node must pick up all of the file
shares. Therefore, to ensure the highest availability, the cluster should host the
maximum number of shares that can be hosted by a single node.
Note
2-node Server clusters are focused on high availability, not scale-out, therefore you
should not expect to hold more shares on a 2-node cluster than a single node.
In a 4-node cluster, you have other options that may be more appropriate,
depending on the failure scenarios that you wish to protect against. For example, if
you wish to survive one node failing at any point in time, you can configure the
shares so that if one node fails, its work is spread across the remaining three nodes.
This means that each node could be loaded to 66% of the maximum number of
shares and still be within the maximum limit of a single node in the event of a single
failure. In this case, the cluster can host three times the number of shares that a
single server can host. If you wish to survive two nodes failing, then a 4-node
cluster can hold twice as many shares (since if two nodes fail, the remaining two
nodes need to pick up the load from the two failed servers) and so on.
In general, as the number of nodes in a cluster increases, the more options you
have and the more you can use server clusters to scale-out a highly available
infrastructure.
A. Server cluster does not impose any restrictions on the size of a volume
supported.
Note
Applications can access disks with no drive letters in one of two ways a) directly
using the object name associated with the disk or more likely b) by using mount
points to link multiple disks together that can be accessed using a single drive
letter.
Q. How can a cluster support more disks than there are drive letters?
A. Using file system mount points. For more information about using mount points
with clustered disks see the online help for Windows Server 2003.
A. File shares are not scoped by the virtual server name that is hosting them. If you
use a browsing tool (e.g. the NET VIEW command) you will see all the shares that
are currently hosted on the physical node.
A. Printers can be clustered using the Print Spooler cluster resource. The Windows
2000 and the Windows Server 2003 online help both give specific examples and the
steps necessary to create a highly available print server.
A. Yes, it is possible to host multiple print spoolers on a single Server cluster. The
spoolers can be failed over independently and can run concurrently on multiple
nodes in the cluster.
A. Microsoft provides a tool (Print Migrator) as part of the ResKit that can be used to
migrate printer settings from one node to another or from one node to a Server
cluster.
A. The cluster service itself relies on being able to authenticate and sign
communications traffic between the cluster nodes. It uses the domain infrastructure
to authenticate using the cluster service account. In an environment with Server
clusters installed, you must ensure that the domain infrastructure is highly
available; any disruption to the infrastructure can result in the clusters becoming
unavailable.
· Disk failures you should use RAID or mirroring to protect against disk failures
· Hardware failures multiple hot swap fans in the server, redundant power supplies
etc.
· Network failures redundant networks that do not have any shared components
A. Yes, in Windows 2000 SP3 and above and Windows Server 2003, the cluster
service publishes a computer object in Active Directory. This provides the
infrastructure with sufficient state to allow Kerberos authentication against
applications and services hosted in a virtual server.
For more information about Kerberos and how it works, see the TechNet web site
(http://go.microsoft.com/fwlink/?linkid=67842).
Q. Can cluster servers also be domain controllers?
A. Yes, however, there are several caveats that you should fully understand before
taking this approach. We recommend that Server cluster nodes are not domain
controllers and that you co-locate a domain controller on the same subnet as the
Server cluster public.
If you must make the cluster nodes into domain controllers, consider the following
important points:
· If one cluster node in a 2-node cluster is a domain controller, all nodes must be
domain controllers. It is recommended that you configure at least two of the nodes
in a 4-node Datacenter cluster as domain controllers.
· If the cluster nodes are the only domain controllers, they each have to be DNS
servers as well, and they should point to each other for primary DNS resolution, and
to themselves for secondary DNS resolution. You have to address the problem of
the ability to not register the private interface in DNS, especially if it is connected
by way of a crossover cable (2-node only). For information about how to configure
the heartbeat interface refer to article 258750 in the Microsoft Knowledge Base
(http://go.microsoft.com/fwlink/?LinkID=46549). However, before you can
accomplish step 12 in KB article 258750, you must first modify other configuration
settings, which are outlined in article 275554 (http://go.microsoft.com/fwlink/?
LinkID=67844).
If the cluster nodes are the only domain controllers, they must each be Global
Catalog servers, or you must implement domainlets.
· The first domain controller in the forest takes on all flexible single master
operation roles (refer to article 197132 at http://go.microsoft.com/fwlink/?
LinkID=67847). You can redistribute these roles to each node. However, if a node
fails over, the flexible single master operation roles that the node has taken on are
no longer available. You can use Ntdsutil to forcibly take away the roles and assign
them to the node that is still running (refer to article 223787 at
http://go.microsoft.com/fwlink/?LinkID=67851). Review article 223346 at
http://go.microsoft.com/fwlink/?LinkID=19807) for information about placement of
flexible, single master operation roles throughout the domain.
· If a domain controller is so busy that the Cluster service is unable to gain access to
the Quorum drive as needed, the Cluster service may interpret this as a resource
failure and cause the cluster group to fail over to the other node. If the Quorum
drive is in another group (although it should not be), and it is configured to affect
the group, a failure may move all group resources to the other node, which may not
be desirable. For more information regarding Quorum configuration, please refer to
the article 280345 listed in the "Reference" section (http://go.microsoft.com/fwlink/?
LinkID=67855).
· You may want to consider making cluster nodes domain controllers (refer to KB
article 171390 at http://go.microsoft.com/fwlink/?LinkID=67857 for more
information), but if a domain controller is already local, or there is a reliable high-
speed connectivity to a domain controller available, Microsoft does not recommend
implementing them on cluster nodes.
Note
You must promote a cluster node to a domain controller by using the Dcpromo tool
prior to installing Windows Clustering.
· You must be extremely careful when demoting a domain controller that is also a
cluster node. When a node is demoted from a domain controller, the security
settings and the user accounts are radically changed (user accounts are demoted to
local accounts for example).
A. Yes, in Windows 2000 SP3 and above and in Windows Server 2003, each virtual
server has the option of being published in active directory.
Although the network name server cluster resource publishes a computer object in
active directory, that computer object should NOT be used for administration tasks
such as applying Group Policy. The ONLY role for the virtual server computer object
in Windows 2000 and Windows Server 2003 is to allow Kerberos authentication and
delegation and for cluster-aware, active directory-aware services (such as MSMQ) to
publish service provider information.
A. No, at this time there is no cluster information other than the computer objects
for virtual servers published in Active directory.
Q. Do Server clusters make domain controllers highly available?
A. No, domain controllers use replication across a set of servers to achieve high
availability.
A. The cluster service account needs to be able to publish records. In a secure, DNS
backed zone, the DNS administrator can chose to restrict the access rights for
users. The cluster service account must be granted permission to create records or
alternatively, the records can be pre-created. If the records are pre-created, you
should not set the zone to dynamic update.
A. The cluster service account on ALL nodes in the cluster must match to ensure
that the intra-cluster communication can be successfully authenticated. The cluster
service itself sends messages between cluster nodes under a variety of conditions
and if any of those communications fail, the cluster node will be removed from the
cluster (i.e. the cluster service will be stopped). It is not possible to determine when
the cluster service will establish communication and therefore there is no clear
window that allows the cluster service account to be changed in a reliable way while
ensuring that the cluster remains running.
Windows 2000
On Windows 2000, the cluster account password can only be reliably changed using
the following steps:
2. Change the password of the cluster service account at the domain controller
The cluster.exe command on Windows Server 2003 has the ability to change the
cluster account password dynamically without shutting down the cluster service on
any of the nodes. The cluster.exe command changes the domain account password
and updates the service control manager account information about all nodes in the
cluster.
Cluster
/cluster:cluster_name1[,cluster_name2,]/changepassword[:new_password[,old_pass
word]] [/skipdc] [/force] [/options]
For more information refer to the online help for Windows Server 2003.
Q. What other security considerations and best practices do I need to worry about
for Server clusters?
A. For security best practices, see the online help for Windows Server 2003.
In-the-box HA Services
Q. What highly available operating system services are provided on the Windows
release?
· MSMQ triggers: Highly available MSMQ trigger service (new for Windows Server
2003)
*In Windows Server 2003, IIS is made cluster-aware using the generic script
resource and the scripts provided. There is no specific IIS resource type.
A. Yes, in Windows Server 2003, the MSMQ trigger service can be made highly
available using Server clusters.
Q. Is IIS cluster-aware?
A. Yes, in Windows 2000, IIS web sites and FTP services can be made highly
available using the IIS Server Instance resource type. In Windows Server 2003, the
IIS Server Instance resource type was replaced with a set of generic scripts provided
in the Windows Server 2003 release (see the online help for more information about
converting IIS web servers and FTP servers from Windows 2000 to Windows Server
2003).
Although IIS web servers can be made highly available by failover using Server
clustering, Microsoft recommends that you use a load balancing cluster such as
provided by Network Load Balancing (NLB), another cluster mechanism provided by
the Windows operating system to make IIS highly available and to scale-out a web
service or web farm.
Depending on the access characteristics, you may choose either Server clusters or
Network Load Balancing clusters to provide highly available FTP servers. Server
clustering is good for FTP sites with high update rates or where you want to have a
single copy of the FTP content. Network Load Balancing is good for mainly read-only
FTP Servers.
A. The Windows operating system comes with a tool (IISSync) that allows the IIS
metabase to be kept in sync across the nodes in the cluster. For more details see
the online help.
A. Yes, Server clusters support a single cluster spanning multiple sites. This is
known as a geographically dispersed cluster. All qualified geographically dispersed
cluster solutions appear on the Microsoft Hardware Compatibility list (HCL)
(http://go.microsoft.com/fwlink/?LinkID=67738). Only cluster solutions listed on the
HCL are supported by Microsoft.
1. Has multiple storage arrays, at least one deployed at each site. This ensures that
in the event of failure of any one site, the other site(s) will have local copies of the
data that they can use to continue to provide the services and applications.
2. Nodes are connected to storage in such a way that in the event of a failure of
either a site or the communication links between sites, the nodes on a given site
can access the storage on that site. In other words, in a two-site configuration, the
nodes in site A are connected to the storage in site A directly and the nodes in site
B are connected to the storage in site B directly. The nodes in site A con continue
without accessing the storage on site B and vice-versa.
A. The goal of multi-site Server cluster configurations is to ensure that loss of one
site in the solution does not cause a loss of the complete application for business
continuance and disaster recovery purposes. Sites are typically up to a few hundred
miles apart so that they have completely different power, different communications
infrastructure providers, and are placed so that natural disasters (e.g., earthquakes)
are extremely unlikely to take out more than one site.
· The quorum data must be synchronously replicated between the sites. To ensure
that the Server cluster guarantees of consistency are met, the cluster database
must be kept consistent across all nodes. If the quorum disk is replicated across the
sites, it MUST be replicated synchronously.
In Windows Server 2003, a new quorum resource Majority Node Set can be used in
these configurations as an alternative to replicating the quorum disk.
· If data is replicated at the block level, the replication must preserve the order of
writes to the secondary site. Failure to ensure this will lead to data corruption.
Q. Does Microsoft provide a complete end-to-end geographically dispersed cluster
solution?
A. No, Microsoft does not provide a software mechanism for replicating application
data from one site to another in a geographically dispersed cluster. Microsoft works
with hardware and software vendors to provide a complete solution. All qualified
geographically dispersed cluster solutions appear on the Microsoft Hardware
Compatibility list (HCL) (http://go.microsoft.com/fwlink/?LinkID=67738). Only cluster
solutions listed on the HCL are supported by Microsoft.
A. The Microsoft server clustering software itself is unaware of the extended nature
of geographically dispersed clusters. There are no special features in Server cluster
in Windows 2000 or Windows Server 2003 that are specific to these kinds of
configuration. The network and storage architectures used to build geographically
dispersed clusters must preserve the semantics that the server cluster technology
expects. Fundamentally, the network and storage architecture of geographically
dispersed server clusters must meet the following requirements:
1. The private and public network connections between cluster nodes must appear
as a single, non-routed LAN (e.g., using technologies such as VLANs to ensure that
all nodes in the cluster appear on the same IP subnets).
3. Windows 2000 requires that a cluster have a single shared disk known as the
quorum disk. The storage infrastructure can provide mirroring across the sites to
make a set of disks appear to the cluster service like a single disk, however, it must
preserve the fundamental semantics that are required by the physical disk
resource:
· Cluster service uses SCSI reserve commands and bus reset to arbitrate for and
protect the shared disks. The semantics of these commands must be preserved
across the sites even in the face of complete communication failures between sites.
If a node on site A reserves a disk, nodes on site B should not be able to access the
contents of the disk. These semantics are essential to avoid data corruption of
cluster data and application data.
· The quorum disk must be replicated in real-time, synchronous mode across all
sites. The different members of a mirrored quorum disk MUST contain the same
data.
In Windows Server 2003, you can use either a mirrored/replicated quorum disk or a
new resource Majority Node Set for a multi-site cluster.
A. As with the Server cluster itself, applications are unaware of the extended nature
of geographically dispersed clusters. There is no topology or configuration
information provided to applications to make them aware of the different sites.
Quorum
A. Server clusters require a quorum resource to function. The quorum resource, like
any other resource, is a resource which can only be owned by one server at a time,
and for which servers can negotiate for ownership. Negotiating for the quorum
resource allows Server clusters to avoid "split-brain" situations where the servers
are active and think the other servers are down. This can happen when, for
example, the cluster interconnect is lost and network response time is problematic.
The quorum resource is used to store the definitive copy of the cluster configuration
so that regardless of any sequence of failures, the cluster configuration will always
remain consistent.
This allows a disk on the shared cluster storage bus to be used as the quorum
resource. The cluster code uses SCSI commands to arbitrate for the quorum disk
ensuring only one node owns the quorum disk at any point in time. This is the
standard quorum resource that Microsoft recommends for all production Windows
2000 clusters.
Note
Some storage vendors provide their own quorum capable resources for specific
hardware solutions (e.g., IBM Shark Storage) or software solutions (such as Veritas
Volume Manager). You should use these if they are required for your environment.
· Local Quorum
In Windows Server 2003 we have introduced another quorum capable resource type
A majority node set is a single quorum resource from a Server cluster perspective;
however, all of the quorum data is actually stored on multiple disks across the
cluster. The majority node set resource takes care to ensure that the cluster
configuration data stored on the majority node set is kept consistent across the
different disks.
A. Microsoft recommends that you do NOT use the quorum disk for other
applications in the cluster and that the quorum disk is restricted to use by the
cluster service itself. If you use the quorum disk for other applications you should be
aware of the following:
· The quorum disk health determines the health of the entire cluster. If the quorum
disk fails, the cluster service will become unavailable on all cluster nodes. The
cluster service checks the health of the quorum disk and arbitrates for exclusive
access to the physical drive using standard I/O operations. These operations are
queued to the device along with any other I/Os to that device. If the cluster service
I/O operations are delayed by extremely heavy traffic, the cluster service will
declare the quorum disk as failed and force a regroup to bring the quorum back
online somewhere else in the cluster. To protect against malicious applications
flooding the quorum disk with I/Os, the quorum disk should be protected. Access to
the quorum disk should be restricted to the local administrator group and the
cluster service account.
· If the quorum disk fills up, the cluster service may be unable to log required data.
In this case, the cluster service will fail, potentially on all cluster nodes. To protect
against malicious applications filling up the quorum disk, access should be
restricted to the local administrator group and the cluster service account.
· The cluster service itself will always try to bring the quorum disk back online. In
doing so, it may violate the failover and failback policies assigned to applications in
the same group.
A. No, out-of-the-box, the cluster service supports physical disks on the shared
cluster bus or in Windows Server 2003 Majority Node Set quorum resources.
The disks that make up the majority node set could, in principle be local disks
physically attached to the nodes themselves or disks on a shared storage fabric. In
the majority node set implementation that is provided as part of Server clusters in
Windows Server 2003, every node in the cluster uses a directory on its own local
system disk to store the quorum data. If the configuration of the cluster changes,
that change is reflected across the different disks. The change is only considered to
have been committed (i.e. made persistent), if that change is made to:
(/2) + 1
This ensures that a majority of the nodes have an up-to-date copy of the data. The
cluster service itself will only start up, and therefore bring resources on line, if a
majority of the nodes configured as part of the cluster are up and running the
cluster service. If there are fewer nodes, the cluster is said not to have quorum and
therefore the cluster service waits (trying to restart) until more nodes try to join.
Only when a majority or quorum of nodes, are available, will the cluster service start
up the resources be brought online. This way, since the up-to-date configuration is
written to a majority of the nodes, regardless of node failures, the cluster will
always guarantee that it starts up with the latest and most up-to-date configuration.
Cluster-Aware Applications
Can applications that were not written for a cluster be made highly available?
Yes, Server clusters provide a plug-in environment that allows resource dlls to
provide the necessary control and health monitoring functions to make existing
applications highly available.
Server clusters provide a set of generic resource types that can be used to make
existing applications failover in a cluster. In Windows 2000 there are two generic
resource types:
Generic application
allows any application to be started, stopped and monitored by the cluster service
Generic Service
These generic services provide very rudimentary health monitoring (for example, is
the process that was started still a valid process on the system). It does not check
that the application is servicing requests since this requires specific knowledge of
the application. The generic resources can be used to make applications failover
relatively quickly; however, to provide a more appropriate health check, Microsoft
recommends that you build an application-specific resource dll.
A. Server clusters provides a rich API set that allows applications to recognize and
utilize the cluster environment. These APIs are fully documented in the Platform
SDK.
Q. Should I use the Generic Service or Generic Application resource to make my
application highly available?
A. The generic services provide very rudimentary health monitoring (for example, is
the process that was started still a valid process on the system). It does not check
that the application is servicing requests since this requires specific knowledge of
the application. The generic resources can be used to make applications failover
relatively quickly; however, to provide a more appropriate health check, Microsoft
recommends that you build an application-specific resource dll.
Q. Does Microsoft validate or logo software products that work with Server clusters?
A. The following services shipped as part of the Windows operating system are
cluster-aware:
· MSMQ triggers Highly available MSMQ trigger service (new for Windows Server
2003)
A. The cluster concepts and APIs are fully documented in the Platform SDK. In
addition, there are several examples in the Platform SDK that can be used to
demonstrate Server cluster integration.
A. Yes, Services for Unix supports highly available NFS shares in SFU 3.0.
Miscellaneous Topics
Q. Can Server clusters and Network Load Balancing be used on the same set of
servers?
A. No, Microsoft Server clusters (MSCS) and Network Load Balancing (NLB) are not
supported on the same set of nodes. Both Server clusters and Network Load
Balancing clusters control and configure network adapters. Since they are not
aware of each other, configuring one can interfere with the other.
A. Yes, you should make sure that the vendor has tested their solution in a Server
cluster environment. Antivirus software typically layers into the storage stack as a
disk driver. This can have an impact on the clusters ability to failover a disk if the
driver does not support the required features.
A. No, at this time, Microsoft has no plans to release a distributed lock manager,
however, that may change if there is sufficient customer demand for a DLM service.
Note
Do not confuse a distributed lock manager with a cluster file system. A cluster file
system can be built in a number of ways, using a lock manager is one of them.
However, just providing a lock manager does not solve the cluster file system
problem.
· A single file system namespace visible to all applications on all nodes in the cluster
· Hardware failures
· Application failures
· Site failures
Fault tolerant servers provide an extremely reliable server platform that addresses
hardware failures by providing redundancy at the hardware level. In some cases,
fault tolerant servers can be used to address site failures.
In summary, Server clusters are about providing high availability, fault tolerant
servers provide high reliability. By combining highly reliable, fault tolerant servers
with Server clusters, you get the best of both worlds; a set of reliable servers that
can provide high availability in the face of operating system and application failures
and upgrades.