Meilleur auteur de réponses
Failover Cluster Manager - Cluster network interface for cluster node on network is unreachable

Question
-
Bonjour,
Je rencontre divers problèmes avec un DAG sur un serveur Exchange 2010.
==> Quand je regarde la configuration du DAG (Dag01) dans la console d'Exchange 2010, tout semble normal. Mes bases de données Mailbox répliquées sont Healty.
==> Mais dans la console de gestion du serveur, Features, Failover Cluster Manager, Dag01, Nodes : l'un des deux nœuds est DOWN
En analysant les journaux d'événement (il y a beaucoup d'erreurs, difficile de trouver le problème de base), il me semble que le problème principal est le suivant :
<<Event ID 1126 — Cluster Network Connectivity : Cluster network interface '%1' for cluster node '%2' on network '%3' is unreachable by at least one other cluster node attached to the network. The failover cluster was not able to determine the location of the failure. Run the Validate a Configuration wizard to check your network configuration. If the condition persists, check for hardware or software errors related to the network adapter. Also check for failures in any other network components to which the node is connected such as hubs, switches, or bridges.
>>
J'ai suivi les indications trouvées sur le site de Microsoft (http://technet.microsoft.com/en-us/library/dd354065%28v=ws.10%29.aspx) :
1) Run the Validate a Configuration Wizard, selecting only the network tests.
==> le test n'indique aucun problème ...2) Check the system event log for hardware or software errors related to the network adapters on this node.
==> je ne constate pas de problème hardware, la config réseau semble OK...3) Check the network adapter, cables, and network configuration for the networks that connect the nodes
==> là encore tout semble OK, mais je ne sais pas comment m'en assurer à 100%4) Check hubs, switches, or bridges in the networks that connect the nodes
==> là encore tout semble OK, mais je ne sais pas comment m'en assurer à 100%Est-ce que quelqu'un pourrais m'aider à mieux comprendre le problème ?
Merci pour votre aide !
Réponses
-
Bonsoir,
le reboot aurait probablement suffit!
Concrètement, il y a souvent des erreurs d'accès au partage témoin. Lors des installations que je réalise, je modifie la sécurité sur le partage et le dossier accueillant le témoin, afin d'ajouter chaque membre du DAG, le groupe "Exchange Enterprise Servers", "Exchange Trusted servers", en plus du DAG lui même et du groupe "administrateurs" qui doivent y apparaître de manière naturelle.
A bientôt,
Thierry DEMAN. Exchange MVP. https://mvp.support.microsoft.com/profile=CE2B565B-B13D-4C24-B04D-F0D5766D14A1 http://www.faqexchange.info
- Marqué comme réponse Florin Ciuca mercredi 5 septembre 2012 08:36
Toutes les réponses
-
Bonjour,
Il faut tout d'abord comprendre que la mise en DAG s'appuit sur les services Cluster, mais il ne s'agit pas d'un Failover Cluster au sens Microsoft.
Vous pouvez lire la partie Network Requierments de cet article : http://technet.microsoft.com/en-us/library/dd638104.aspx et vérifier en particulier les points suivants :
- Each network in each DAG member server must be on its own network subnet. Each server in the DAG can be on a different subnet, but the MAPI and Replication networks must be routable and provide connectivity, such that:
- Each network in each DAG member server is on its own network subnet that's separate from the subnet used by each other network in the server.
- Each DAG member server's MAPI network can communicate with each other DAG member's MAPI network.
- Each DAG member server's Replication network can communicate with each other DAG member's Replication network.
- There is no direct routing that allows heartbeat traffic from the Replication network on one DAG member server to the MAPI network on another DAG member server, or vice versa, or between multiple Replication networks in the DAG.
- Regardless of their geographic location relative to other DAG members, each member of the DAG must have round trip network latency no greater than 500 milliseconds (ms) between each other member.
- DAG networks support Internet Protocol Version 4 (IPv4) and IPv6. IPv6 is supported only when IPv4 is also used; a pure IPv6 environment isn't supported. Using IPv6 addresses and IP address ranges is supported only when both IPv6 and IPv4 are enabled on that computer, and the network supports both IP address versions. If Exchange 2010 is deployed in this configuration, all server roles can send data to and receive data from devices, servers, and clients that use IPv6 addresses.
- Automatic Private IP Addressing (APIPA) is a feature of Microsoft Windows that automatically assigns IP addresses when no Dynamic Host Configuration Protocol (DHCP) server is available on the network. APIPA addresses (including manually assigned addresses from the APIPA address range) aren't supported for use by DAGs or by Exchange 2010.
- Each network in each DAG member server must be on its own network subnet. Each server in the DAG can be on a different subnet, but the MAPI and Replication networks must be routable and provide connectivity, such that:
-
Bonsoir,
Exchange 2010 n'utilise quasiment pas le cluster Microsoft dans son fonctionnement normal et sa réplication.
Le cluster MS ne sert qu'à déterminer quel est le nœud actif (ou à utiliser) à un moment donné et si le quorum est atteint pour mettre le fonctionnement.
Classiquement, lorsqu'un nœud est "down", c'est que l'adresse ip ou la carte réseau ne peut pas être atteinte par l'autre nœud...
=> Assez souvent, il suffit de changer l'adresse IP du nœud fautif ou de l'adresse IP du cluster pour repartir normalement.
Pour le reste, il est très important de désactiver toutes les cartes réseaux non utilisées, et de vérifier l'ordre d'utilisation des cartes réseau afin de mettre en 1er la carte principale.
Si un réseau et des cartes spécifiques existent pour la réplication et le DAG, vérifier que ces adresses ne s'enregistrent pas dans le DNS.
A bientôt,
Thierry DEMAN. Exchange MVP. https://mvp.support.microsoft.com/profile=CE2B565B-B13D-4C24-B04D-F0D5766D14A1 http://www.faqexchange.info
-
Bonjour,
Merci pour vos réponses ! J'ai entrepris des recherches et des tests durant des heurs et finalement la réponse à mon problème m'est tombée du ciel !
Je suis tombé sur quelqu'un qui avait déjà rencontré le même problème. Selon lui, il s'agit du Witness Serveur qui comportait un grand nombre de mises à jour Windows à installer. Je n'y croyait pas trop car presque*(1) rien ne laissait penser que le problème provenait du Witness Serveur, mais après avoir effectué les opérations ci-après tout c'est remis à fonctionner :
- installation des Windows update sur le Witness Serveur
- redémarrage du Witness Serveur
- redémarrage du serveur DOWN dans le cluster==> le serveur à bien mis 30 minutes à redémarrer mais ensuite bonne surprise, le cluster et OK et plus d'erreur de réplication !
Pensez-vous que ce soit les mises à jour en attente et/ou le redémarrage du Witness Serveur qui ait résolu le problème ?
*(1) sur le serveur concerné, il y avait des erreurs Event ID 1564 [(File share witness resource 'File Share Witness (\\WitnessServer\DagName)' failed to arbitrate for the file share. Please ensure that file share exists and is accessible by the cluster.)] mais cette erreur ne se retrouvait pas sur l'autre serveur ...
Bonne journée.
-
-
Bonsoir,
le reboot aurait probablement suffit!
Concrètement, il y a souvent des erreurs d'accès au partage témoin. Lors des installations que je réalise, je modifie la sécurité sur le partage et le dossier accueillant le témoin, afin d'ajouter chaque membre du DAG, le groupe "Exchange Enterprise Servers", "Exchange Trusted servers", en plus du DAG lui même et du groupe "administrateurs" qui doivent y apparaître de manière naturelle.
A bientôt,
Thierry DEMAN. Exchange MVP. https://mvp.support.microsoft.com/profile=CE2B565B-B13D-4C24-B04D-F0D5766D14A1 http://www.faqexchange.info
- Marqué comme réponse Florin Ciuca mercredi 5 septembre 2012 08:36
-
Bonjour,
Votre souci est-il résolu après le redémarrage?
Merci de nous tenir au courant.
Cordialement,
Florin
Florin CIUCA, MSFT Votez! Appel à la contribution
Nous vous prions de considérer que dans le cadre de ce forum on n’offre pas de support technique et aucune garantie de la part de Microsoft ne peut être offerte. -