Äéáôßèåôáé ìéá åíçìåñùìÝíç Ýêäïóç ðïõ ðñïóèÝôåé ìéá äõíáôüôçôá witness êïéíÞò ÷ñÞóçò áñ÷åßùí êáé äõíáôüôçôá ðáëìþí ìå äõíáôüôçôá ñýèìéóçò ðáñáìÝôñùí óõìðëÝãìáôïò ãéá óõìðëÝãìáôá äéáêïìéóôþí ðïõ âáóßæïíôáé óå Windows Server 2003 Service Pack 1

Áõôü ôï Üñèñï ðåñéãñÜöåé ìéá åíçìåñùìÝíç Ýêäïóç ðïõ ìðïñåßôå íá åöáñìüóåôå ãéá íá ðñïóèÝóåôå ôéò áêüëïõèåò äýï íÝåò äõíáôüôçôåò óå Microsoft Windows Server 2003 Service Pack 1 (SP1) - ðïõ âáóßæïíôáé óå óýìðëåãìá äéáêïìéóôþí Þ óå Ýíá óýìðëåãìá äéáêïìéóôÞ ðïõ âáóßæåôáé óå Windows Server 2003 R2:

• Witness êïéíÞò ÷ñÞóçò áñ÷åßùí
• Ìå äõíáôüôçôá ñýèìéóçò ðáñáìÝôñùí óõìðëÝãìáôïò ðáëìþí

Ðáñüëï ðïõ áõôÝò ïé äýï äõíáôüôçôåò ðåñéÝ÷ïíôáé óôï ßäéï ðáêÝôï åíçìåñùìÝíçò Ýêäïóçò, áõôÝò ïé äýï äõíáôüôçôåò åßíáé îå÷ùñéóôÝò êáé áíåîÜñôçôåò ìåôáîý ôïõò.

Witness êïéíÞò ÷ñÞóçò áñ÷åßùí

Ç äõíáôüôçôá witness êïéíÞò ÷ñÞóçò áñ÷åßùí åßíáé ìéá âåëôßùóç ôïõ ôñÝ÷ïíôïò ìïíôÝëïõ áðáñôßáò ðëåéïøçößá êüìâïò óõíüëïõ (MNS). ÁõôÞ ç äõíáôüôçôá óáò åðéôñÝðåé íá ÷ñçóéìïðïéÞóåôå Ýíá êïéíü÷ñçóôï áñ÷åßï ðïõ âñßóêåôáé åêôüò ôïõ óõìðëÝãìáôïò ùò Ýíá åðéðëÝïí "åêëïãÞò" ãéá íá ðñïóäéïñßóåôå ôçí êáôÜóôáóç ôïõ óõìðëÝãìáôïò óå ìéá áíÜðôõîç óõìðëÝãìáôïò ôïõ êüìâïõ äýï MNS áðáñôßáò.

Óêåöôåßôå äýï êüìâùí MNS áðáñôßáò óõìðëÝãìáôïò. ÅðåéäÞ Ýíá óýìðëåãìá áðáñôßáò MNS ìðïñåß íá åêôåëåóôåß ìüíï üôáí ç ðëåéïøçößá ôùí êüìâùí óõìðëÝãìáôïò åßíáé äéáèÝóéìåò, äýï êüìâùí MNS áðáñôßáò óõìðëÝãìáôïò äåí åßíáé äõíáôü íá äéáôçñïýí ôçí áðïôõ÷ßá ôïõ ïðïéïíäÞðïôå êüìâï ôïõ óõìðëÝãìáôïò. Áõôü óõìâáßíåé åðåéäÞ ç ðëåéïøçößá ôùí äýï êüìâùí óõìðëÝãìáôïò äýï. Ãéá íá äéáôçñïýí ôçí áðïôõ÷ßá ôïõ êÜèå Ýíáí êüìâï åíüò óõìðëÝãìáôïò áðáñôßáò MNS, ðñÝðåé íá Ý÷åôå ôïõëÜ÷éóôïí ôñåéò óõóêåõÝò, ïé ïðïßåò ìðïñåß íá èåùñçèåß ùò äéáèÝóéìï. Ç äõíáôüôçôá witness êïéíÞò ÷ñÞóçò áñ÷åßùí óáò åðéôñÝðåé íá ÷ñçóéìïðïéÞóåôå Ýíá êïéíü÷ñçóôï áñ÷åßï åîùôåñéêÞò ðñïÝëåõóçò ùò ìéá witness. This witness acts as the third available device in a two-node MNS quorum cluster. Therefore, with this feature enabled, a two-node MNS quorum cluster can sustain the failure of a single cluster node. Additionally, the file share witness feature provides the following two functionalities:

• It helps protect the cluster against a problem that is known as asplit brain. This problem occurs if the two nodes in a MNS quorum cluster cannot communicate with each other. In this situation, each cluster node is unable to determine whether the loss of communication occurred because the other cluster node failed, or whether the loss of communication occurred because of a problem with the network. The file share witness can designate one of the cluster nodes as the surviving cluster node. That cluster node can then determine that it should continue to run the cluster. In this scenario, the surviving cluster node can determine that the other cluster node failed, or that the other cluster node was not sanctioned by the file share witness.
• It helps protect the cluster against a problem that is known as apartition in time. Áõôü ôï æÞôçìá ðñïêýðôåé, åöüóïí éó÷ýïõí ïé áêüëïõèåò óõíèÞêåò:
  • Cluster node A is running, but cluster node B is not running.
  • Cluster node A stops running.
  • Cluster node B tries to run the cluster.
  In this situation, cluster node B may not have cluster state information that was updated on cluster node A. Therefore, cluster node B may run the cluster by using incorrect state information. The file share witness feature helps prevent this problem by detecting that the cluster state has changed. The file share witness feature prevents the cluster node that contains outdated cluster state information from running the cluster. When this action occurs, an Error event that contains the followingÐåñéãñáöÞinformation is logged in the System event log:

  Majority Node Set resource has failed to come online. The resource has detected that it does not have the latest copy of server cluster database. If this is a two node cluster, try starting Cluster service on the other node, and let this node join the cluster. If that does not work, use the/forcequorumstartup option to start the Cluster service.

For more information about Cluster service startup options, click the following article number to view the article in the Microsoft Knowledge Base:

File share witness properties

The file share witness feature adds the following new private MNS resource configuration properties.

MNSFileShare

Ìðïñåßôå íá ÷ñçóéìïðïéÞóåôå ôïMNSFileShareproperty to set a file share that is external to the cluster as the file share witness. The following list contains the requirements forMNSFileShareproperty together with the requirements for the external file share:

• Ãéá íáMNSFileShareproperty is ignored if the number of cluster nodes is anything other than two. ÁõôÞ ç óõìðåñéöïñÜ ðáñïõóéÜæåôáé áêüìá êáé áí ôïMNSFileShareproperty is set. If the number of cluster nodes is a number other than two, the MNS resource behaves as if it is in a typical MNS quorum. Therefore, you cannot use the file share witness feature to affect an MNS quorum cluster that has other than two cluster nodes.
• After you modify theMNSFileShareproperty, or after you modify either of the other new private MNS resource configuration properties that this update provides, the changes do not take effect until you next bring the MNS resource online. When the MNS resource is set as a quorum resource, it does not allow for offline and online operations. Therefore, you must move the group that contains the MNS resource to the other cluster node. This action brings the resource online on the destination cluster node. Then, the modifications that you made to theMNSFileShareproperty, or to the other two properties that this update provides, take effect.
• The Cluster service on each cluster node runs under the context of a domain user account that is known as the Cluster service account. Because the MNS resource creates a file on the external file share, the Cluster service account must have write permission to the external file share. Therefore, you must grant Change share permissions or Full Control share permissions for the Cluster service account on this share.
• Ãéá íáMNSFileShareproperty must be set to a string value that contains the Universal Naming Convention (UNC) path of a file share that is external to the cluster. For example, this property must be set to\\¼íïìá_ÄéáêïìéóôÞ\¼íïìá_êïéíü÷ñçóôïõ_óôïé÷åßïõ. The external share is used to store only a small amount of data. Therefore, a share that has between 2 megabytes (MB) and 5 MB of available hard disk space is sufficient.
  
  ÓçìáíôéêüThe external share does not store the full state of the cluster configuration. Instead, the external share only contains data that is sufficient to help prevent split-brain behavior and to help detect a partition in time behavior.
• Each server cluster must be configured to use its own external file share. We do not support the use of the same external file share for multiple server clusters. However, you can use a single external server that is configured to have one share for each server cluster.
• For a geographically-dispersed two-node cluster that has each node located in a different site, you can co-locate the external file share with any one of the cluster nodes. Alternatively, you can configure the external share in a separate third site.

MNSFileShareCheckInterval

Ãéá íáMNSFileShareCheckIntervalproperty is used to set the interval to verify the health of the external file share. The default interval is four minutes. This property value is set in seconds and has a range that is specified in the following table.The external file share that acts as a witness for the MNS quorum cluster is checked at set intervals to make sure that the MNS resource can write to it. If this verification fails, a Warning event that has the followingÐåñéãñáöÞinformation is logged in the System event log:

Majority Node Set resource has failed a status check for file share '\\¼íïìá_ÄéáêïìéóôÞ\¼íïìá_êïéíü÷ñçóôïõ_óôïé÷åßïõ. The error code was '67'. Please ensure that the file share is configured properly and that the Cluster service account has write permission on the file share

This Warning event is logged one time for every verification failure that occurs until the verification operation succeeds.

MNSFileShareDelay

Ãéá íáMNSFileShareDelayproperty specifies a delay time for the cluster node that does not currently own the MNS quorum resource. If the cluster nodes lose communication with each other, each cluster node tries to obtain the "vote" of the file share witness. Ç ôéìÞ ôïõMNSFileShareDelayproperty specifies the number of seconds to delay the cluster node that does not currently own the MNS quorum resource. This behavior gives the cluster node that currently owns the MNS quorum resource preference in winning the vote of the file share witness. This property value is set in seconds and has a range that is specified in the following table.

Ñýèìéóç ðáñáìÝôñùí ìéáò witness êïéíÞò ÷ñÞóçò áñ÷åßùí

Ãéá íá ñõèìßóåôå ôï witness êïéíÞò ÷ñÞóçò áñ÷åßùí, áêïëïõèÞóôå ôá åîÞò âÞìáôá:

1. Ïñéóìüò ôïõMNSFileShareç éäéüôçôá ôïõ ðüñïõ áðáñôßáò MNS óôï êïéíü÷ñçóôï óôïé÷åßï ôïõ åîùôåñéêïý áñ÷åßïõ ðïõ èá ëåéôïõñãÞóåé ùò ôï witness êïéíÞò ÷ñÞóçò áñ÷åßùí. Ãéá íá ãßíåé áõôü, åêôåëÝóôå ôçí áêüëïõèç åíôïëÞ óå ìéá ãñáììÞ åíôïëþí:
   óýìðëåãìácluster_nameðüñïòmns_resource_name/Priv MNSFileShare = \\¼íïìá_ÄéáêïìéóôÞ\¼íïìá_êïéíü÷ñçóôïõ_óôïé÷åßïõ
2. Ìåôáêßíçóç óôçí ïìÜäá ðïõ ðåñéÝ÷åé ôïí ðüñï MNS. Ãéá íá ãßíåé áõôü, åêôåëÝóôå ôçí áêüëïõèç åíôïëÞ óå ìéá ãñáììÞ åíôïëþí:
   óýìðëåãìácluster_name¼ìéëïòmns_resource_group_name/Move

Åðßóçò ìðïñåßôå íá áðïêôÞóåôå ðñüóâáóç óå áõôÝò ôéò éäéùôéêÝò éäéüôçôåò ðáñáìÝôñùí ðüñï MNS ìå ôç ÷ñÞóç ìßáò Þ ðåñéóóüôåñùí áðü ôéò áêüëïõèåò äéáóõíäÝóåéò óõìðëÝãìáôïò:

• The cluster API
• The cluster Windows Management Interface (WMI) provider
• The Cluster Automation Server

ÓÇÌÅÉÙÓÇYou cannot use the Cluster Administrator tool to set these properties. This is because the Cluster Administrator tool does not expose these private MNS resource configuration properties.

Ìå äõíáôüôçôá ñýèìéóçò ðáñáìÝôñùí óõìðëÝãìáôïò ðáëìþí

The configurable cluster heartbeats feature enables you to configure cluster heartbeat parameters. This may help avoid unnecessary cluster failovers. These failovers occur because of a temporary network problem that may cause packets to be dropped or delayed. The configurable cluster heartbeats feature may help in an environment where cluster nodes are geographically dispersed.

The current cluster heartbeat algorithm sends a heartbeat message every 1.2 seconds from each interface on each cluster node. This message is sent to each interface on the same cluster network. Therefore, each cluster node both sends a heartbeat message every 1.2 seconds and expects to receive a heartbeat message every 1.2 seconds. If two consecutive heartbeats from the same interface are missed, the Cluster service suspects that an interface failure may have occurred. If six consecutive heartbeats are missed from all the interfaces on a node, the Cluster service suspects that a node failure may have occurred.

If the Cluster service suspects that a failure has occurred, the Cluster service runs a distributed consensus algorithm to identify whether a failure has occurred. An interface failure causes the failure of IP address resources. An IP address resource failure may cause a resource group failover to another cluster node. A node failure forces the node to be removed from active membership of the cluster. Therefore, all the resource groups on the affected node fail over to another cluster node.

The configurable cluster heartbeats feature exposes the lost-interface heartbeat periods and the lost-node heartbeat periods as new private cluster configuration properties. This feature does not affect heartbeat timing. Heartbeats are still sent every 1.2 seconds. However, this feature lets you configure the cluster to be more tolerant of heartbeat failures. These failures may occur for one or more of the following reasons:

• Dropped packets
• Excessive network latency
• Network interface failure
• Cluster node failure

The property values are configured in units of missed heartbeats, not by the elapsed time. Therefore, by using this feature, you cannot configure the cluster to suspect a node failure after 5 seconds. However, you can configure the cluster to suspect a node failure after five missed heartbeats.

ÓÇÌÅÉÙÓÇDepending on when in the heartbeat period the failure occurs, five missed heartbeats correspond to approximately 5 or 6 seconds.

Because of the way in which the verification for heartbeats is timed, the interface threshold is calculated differently from the node threshold. Therefore, you must set the interface threshold to the number of missed heartbeats plus one. For example, to configure an interface failure after two missed heartbeats, you must set the interface threshold to a value of 3.

All the cluster nodes must have a status ofUpto receive the property change. Also, you must restart the Cluster service on each node for the property change to take effect.

ÓÇÌÅÉÙÓÇYou can restart the Cluster service on one node at a time.

This property value has a range that is specified in the following tables.

Äéáóýíäåóç

Ï êüìâïò

Configuring cluster heartbeats

To configure the cluster heartbeats feature, follow these steps.

ÓÇÌÅÉÙÓÇThese steps change the heartbeat configuration for interfaces to four missed heartbeats. This corresponds to approximately 5 seconds. Additionally, these steps change the heartbeat configuration for nodes to 10 missed heartbeats. This corresponds to approximately 12 seconds.

1. Make sure that all the cluster nodes are up. To do this, run the following command:
   clustercluster_namenode
   After you run this command, verify that the status value for each cluster node isUp.
2. Set the number of heartbeat misses for interfaces and for nodes. To do this, run the following commands:
   • clustercluster_name/priv HeartBeatLostInterfaceTicks=5:DWORD
   • clustercluster_name/priv HeartBeatLostNodeTicks=10:DWORD
   ÓÇÌÅÉÙÓÇYou must specify the DWORD string when you set private properties by using a command-line command.
3. Stop and then restart the Cluster service on each cluster node. To do this, run the following commands on each cluster node:
   • net stop clussvc
   • net start clussvc

You can also access these private cluster configuration properties by using any one or more of the following cluster interfaces:

• The cluster API
• The cluster WMI provider
• The Cluster Automation Server

When you use these interfaces to set one or both of these cluster heartbeat private properties, the following status code is returned:ÓÇÌÅÉÙÓÇYou cannot use the Cluster Administrator tool to set these properties. This is because the Cluster Administrator tool does not expose private cluster configuration properties.

ÓÇÌÅÉÙÓÇThere is a known regression in update 903650. This regression prevents you from creating a quorum by using Majority Node Set (MNS). For example, when you convert from shared quorum resource to MNS, an error 1 (invalid function) occurs. Additionally, if the cluster is already using MNS for a quorum and the 903650 update is applied, the MNS resource is unable to come online. In such a scenario, the cluster administrator displays the following error message:

Ðëçñïöïñßåò ãéá ôï Service Pack

These features are included in Microsoft Windows Server 2003 Service Pack 2.Ãéá ðåñéóóüôåñåò ðëçñïöïñßåò ó÷åôéêÜ ìå ôï ðéï ðñüóöáôï Service Pack ôïõ Windows Server 2003, êÜíôå êëéê óôïí áñéèìü ôïõ Üñèñïõ ðáñáêÜôù, ãéá íá ðñïâÜëåôå ôï Üñèñï ôçò ÃíùóéáêÞò ÂÜóçò ôçò Microsoft (Knowledge Base):

Ðëçñïöïñßåò åíçìÝñùóçò

Ôá áêüëïõèá áñ÷åßá åßíáé äéáèÝóéìá ãéá ëÞøç áðü ôï ÊÝíôñï ëÞøçò áñ÷åßùí ôçò Microsoft:

Update for Windows Server 2003

Download the 921181 package now.

Update for Windows Server 2003 x64 Edition

Download the 921181 package now.

Update for Windows Server 2003 for Itanium-based Systems

Download the 921181 package now.

Release Date: July 5, 2006

Ãéá ðåñéóóüôåñåò ðëçñïöïñßåò ó÷åôéêÜ ìå ôïí ôñüðï ëÞøçò áñ÷åßùí õðïóôÞñéîçò ôçò Microsoft, êÜíôå êëéê óôïí áñéèìü ôïõ Üñèñïõ ðáñáêÜôù, ãéá íá ðñïâÜëåôå ôï Üñèñï ôçò ÃíùóéáêÞò âÜóçò ôçò Microsoft:Ç Microsoft åîÝôáóå ôï áñ÷åßï áõôü ãéá éïýò. Ç Microsoft ÷ñçóéìïðïßçóå ôï ðéï ðñüóöáôï ëïãéóìéêü åíôïðéóìïý éþí ðïõ Þôáí äéáèÝóéìï êáôÜ ôçí çìåñïìçíßá äçìïóßåõóçò ôïõ áñ÷åßïõ. Ôï áñ÷åßï åßíáé áðïèçêåõìÝíï óå äéáêïìéóôÝò ìå åíéó÷õìÝíç áóöÜëåéá, ïé ïðïßïé óõìâÜëëïõí óôçí áðïôñïðÞ ìç åîïõóéïäïôçìÝíùí áëëáãþí óôï áñ÷åßï.

ÐÑÏÛÐÏÈÅÓÅÉÓ

ÐñÝðåé íá ÷ñçóéìïðïéåßôå Ýíá áðü ôá áêüëïõèá ëåéôïõñãéêÜ óõóôÞìáôá ãéá ôçí åöáñìïãÞ áõôÞò ôçò åíçìåñùìÝíçò Ýêäïóçò:

• Windows Server 2003 SP1
• Ôá Windows Server 2003 R2

ÁðáéôÞóåéò åðáíåêêßíçóçò

ÐñÝðåé íá êÜíåôå åðáíåêêßíçóç ôïõ õðïëïãéóôÞ, áöïý åöáñìüóåôå áõôÞí ôçí åíçìÝñùóç.

Ðëçñïöïñßåò áíôéêáôÜóôáóçò åíçìÝñùóçò

ÁõôÞ ç åíçìåñùìÝíç Ýêäïóç äåí áíôéêáèéóôÜ Üëëåò åíçìåñùìÝíåò åêäüóåéò.

ÐËÇÑÏÖÏÑÉÅÓ ÁÑ×ÅÉÏÕ

Ç áããëéêÞ Ýêäïóç áõôÞò ôçò åíçìÝñùóçò Ý÷åé ôá ÷áñáêôçñéóôéêÜ áñ÷åßïõ (Þ íåüôåñá ÷áñáêôçñéóôéêÜ áñ÷åßïõ) ðïõ ðáñáôßèåíôáé óôïí ðáñáêÜôù ðßíáêá. Ïé çìåñïìçíßåò êáé ïé þñåò ãéá ôá áñ÷åßá áõôÜ áíáöÝñïíôáé óå óõíôïíéóìÝíç ðáãêüóìéá þñá (UTC). ¼ôáí ðñïâÜëëåôå ôéò ðëçñïöïñßåò ôïõ áñ÷åßïõ, áõôÝò ìåôáôñÝðïíôáé óôçí ôïðéêÞ þñá. Ãéá íá âñåßôå ôç äéáöïñÜ ìåôáîý ôçò þñáò UTC êáé ôçò ôïðéêÞò þñáò, ÷ñçóéìïðïéÞóôå ôçíÆþíç þñáòóôçí êáñôÝëá ìå ôï óôïé÷åßï "çìåñïìçíßá êáé þñá" óôïí ðßíáêá åëÝã÷ïõ.

Ôá Windows Server 2003, 32-bit x 86 åêäüóåéò

Ôá Windows Server 2003, 64 bit 64 åêäüóåéò x

Ôá Windows Server 2003, åêäüóåéò 64-bit IA-64

Ç Microsoft Ý÷åé åðéâåâáéþóåé üôé ðñüêåéôáé ãéá Ýíá èÝìá ôï ïðïßï ðáñïõóéÜæåôáé óôá ðñïúüíôá ôçò ðïõ áíáöÝñïíôáé óôçí åíüôçôá "Éó÷ýåé ãéá". Ôï æÞôçìá áõôü äéïñèþèçêå áñ÷éêÜ óôï Microsoft Windows Server 2003 Service Pack 2.

Ãéá ðåñéóóüôåñåò ðëçñïöïñßåò, êÜíôå êëéê óôïí áñéèìü ôïõ Üñèñïõ ðáñáêÜôù, ãéá íá ðñïâÜëåôå ôï Üñèñï ôçò ÃíùóéáêÞò ÂÜóçò ôçò Microsoft (Knowledge Base):