locked
Problème de "communication perdue" sur Hyper-V en Failover Cluster RRS feed

  • Question

  • Bonjour,

    J'ai monté il y a 2 ans l'architecture suivante:

    - Serveur physique 1: Dell R515 (16Go RAM, 2x AMD4180 6 coeurs, 2x disques SAS 15k trs/min en RAID 1 sur controleur Dell PERC H700, 4x cartes réseau Broadcom Netxtrem II BC5709 avec iSCSI offload) - Windows 2K8 R2 Datacenter edition

    - Serveur physique 2: Idem

    - Baie de disques SAN iSCSI: Dell MD3220i avec 3 disques SAS 10k trs/min en RAID5 + 1 secours

    - Réseau: sur chaque serveur, 1 port réseau dédié pour la gestion vers le réseau extérieur, 1 port dédié pour machines virtuelles vers réseau extérieur, 2 ports dédiés pour le SAN iSCSI (connexion directe en RJ45 sur la baie de disque, pas de switch), et 3 ports dédiés pour le cluster (CSV, Cluster heartbeat, live migration) reliés en direct en RJ45 sur l'autre serveur. Voir schéma ci-dessous:

    J'ai suivi les recommandations de Microsoft et Dell pour monter cette architecture, qui inclue donc un FailoverCluster, configuré avec les Cluster Shared Volumes sur ma baie iSCSI, et des machines virtuelles en haute disponibilité (Linux Centos 5/6 et Windows 2K8 Datacenter).

    Cela fonctionne (presque) normalement, je dis presque car j'ai eu à plusieurs reprises de gros problèmes, notamment en cas de défaillance de l'un des deux noeuds (problèmes DNS, Active Directory, services pourtant sont bien configurés selon les best practices que j'ai pu lire...). Si au passage quelqu'un a rencontré et solutionné ce type de problème, je ne serais pas contre une discussion!

    Mais j'écris ce message pour un autre problème, cette fois beaucoup plus préoccupant car récurrent (quasi quotidien): j'ai depuis une ou deux semaines un "arrêt" de deux de mes machines virtuelles (l'une sous Linux Centos 5, l'autre sous windows 2K8). Lorsque ça se produit, je n'ai plus accès, ni en RDP, ni directement depuis la machine hôte à ces serveurs, et la seule indication donnée par la machine Hyper-V est la mention "communication perdue". Lorsque je relance les machines virtuelles, elles fonctionnent normalement de nouveau. J'ai essayé de basculer l'une de ces machines sur le noeud n°2, mais le résultat est le même! N'ayant pas accès au machines concernées lors des plantages, je ne peux pas voir l'état des logs pour voir ce qui se passe, et je ne trouve rien dans les logs après redémarrage pouvant expliquer cela...

    Quelqu'un aurait-il une idée?

    Merci d'avance!

    mercredi 12 juin 2013 16:39

Toutes les réponses

  • Bonsoir,

    A prioris  les ressources de la machine virtuelle n'est pas accessible.

    Dans le journal de la console du cluster y a-t-il des messages d'erreur enregistrés?

    Quel est le résultat fourni par le test de validation de cluster?

    Noter bien le fonctionnement du cluster et la disponibilité des données partagées (clustershare)dépend beaucoup du service active directory, pour cela il est recommandé d'avoir un DC physique


    Best regards Bourbita Thameur Microsoft Certified Technology Specialist: Windows Server 2008 R2,Server Virtualizaton

    mercredi 12 juin 2013 23:46
    Auteur de réponse
  • Bonjour,

    Justement je n'ai aucun message d'erreur, ni au niveau des logs du cluster, ni dans ceux d'Hyper-V...

    Je viens de refaire une validation de cluster, et voici les avertissements que j'ai:

    - Version des mises à jours différentes sur les 2 serveurs physiques -> effectivement, l'un des serveur a installé ses mises à jour, mais étant en environnement de production je n'ai pas encore pu le redémarrer.

    - Pas de disque disponible pour la validation  -> le test me liste bien mes 3 volumes partagés de clusters (CSV), ainsi que la grappe RAID 1 locale, mais indique qu'il ne peut pas les tester du fait qu'ils sont en ligne dans le cluster

    Voyez-vous d'autres pistes...? 

    Concernant le DC physique, ce n'était pas indiqué dans le guide Dell me semble-t-il, mais en effet j'ai eu par le passé des problèmes liés au service Active Directory. Faut-il configurer un serveur DC primaire physique (séparé de mes serveurs 1 et 2), et conserver le rôle DC en secondaire sur chaque serveur du cluster?

    Merci!

    jeudi 13 juin 2013 08:03
  • Bonjour,

    Essayer également d'installer les derniers firmware et pilote des cartes réseaux sur chaque serveur.

    Pour le service active directory il est toujours recommandé d'avoir au minimum un controleur de domaine installé sur une machine physique hors de l'environnement de virtualisation pour qu'il reste disponible même s'il y a des soucis sur l'un des noeud.

    Pour avoir plus des détails je vous invite à consulter ce lien :

    http://social.technet.microsoft.com/wiki/contents/articles/2155.hyper-v-and-failover-cluster-domain-requirements.aspx


    Best regards Bourbita Thameur Microsoft Certified Technology Specialist: Windows Server 2008 R2,Server Virtualizaton

    jeudi 13 juin 2013 08:53
    Auteur de réponse
  • Bonjour,

    Je "segmente" toujours mes réseaux, exemple

    Production 192.168.0.196/24
    iSCSI-1-MPIO 10.0.0.3/8
    iSCSI-2-MPIO 10.0.0.4/8
    Cluster-Hearbeat 172.10.10.1/16

    Regarde ici, j'ai crée un billet concernant l'implémentation d'un cluster de service de fichiers.


    -- Cédric GEORGEOT [MVP] Virtual Machine http://www.e-novatic.fr -- Auteur du livre "Bonnes pratiques, planification et dimensionnement des infrastructures de stockage et de serveur en environnement virtuel" -- N'oubliez pas de marquer comme réponse ;-)

    vendredi 14 juin 2013 04:57
  • Bonjour et merci pour vos réponses!

    Pour la mise à jour des drivers, j'ai vérifié et seules les cartes réseaux n'ont pas les dernières MAJ. J'ai cependant la même version de firmware depuis 2 ans, et le problème est visiblement récent...

    Concernant la segmentation des réseaux, j'ai également configuré chaque segment physique avec un adressage réseau différent:

    Liaisons entre serveur 1 et serveur 2 (un réseau par port physique, pas de vlans):

    - Cluster Hearbeat : 192.168.100.0/24

    - CSV: 192.168.110.0/24

    - Live Migration: 192.168.120.0/24

    Liaisons vers baie iSCSI:

    - Serveur 1, port 1 sur baie SAN, port 1: 192.168.130.0/24

    - Serveur 1, port 2 sur baie SAN, port 2: 192.168.131.0/24

    - Serveur 2, port 1 sur baie SAN, port 3: 192.168.132.0/24

    - Serveur 2, port 2 sur baie SAN, port 4: 192.168.133.0/24

    Mes cibles iSCSI sont bien configurés comme indiqué dans le billet, en utilisant MPIO:

    Enfin, pour les liaisons vers mon réseau:

     - un port réseau sur chaque serveur, utilisé pour les VM en direction de mon switch central (dans un vlan par port).

    - un port réseau sur chaque serveur pour le "management", arrivant également sur mon switch central (dans un autre vlan), utilisant notre  adressage IP interne

    Je ne sais pas si c'est lié, mais hier l'un des serveurs a redémarré tout seul, je n'y avait plus accès pendant près d'une heure, donc à deux doigts de partir au datacenter, puis d'un coup il est remonté dans le cluster et j'y avais de nouveau accès en RDP... Il était indiqué qu'une erreur de type "bluescreen" était à l'origine du reboot.... Rien de bien rassurant. Soit c'est une coïncidence, soit c'est lié à mon problème de communication perdue... Les logs ne donnent pas grand chose.

    Effectivement, je n'ai pas de DC séparé physiquement, chaque noeud du cluster est lui-même contrôleur de domaine. De mémoire j'avais suivi une documentation officielle (dell et/ou microsoft), qui validait cette configuration. Est-ce une erreur qui pourrait être à l'origine de mes différends problèmes?

    Encore merci!

    Julien


    • Modifié mrtur vendredi 14 juin 2013 13:21
    vendredi 14 juin 2013 13:14
  • De mémoire, j'ai déjà au des merdes avec les drivers Intel/Broadcom notamment pour le teaming, mais tu ne l'utilises pas, du fait du MPIO ?

    -- Cédric GEORGEOT [MVP] Virtual Machine http://www.e-novatic.fr -- Auteur du livre "Bonnes pratiques, planification et dimensionnement des infrastructures de stockage et de serveur en environnement virtuel" -- N'oubliez pas de marquer comme réponse ;-)

    vendredi 14 juin 2013 16:18
  • Oui je fais uniquement du MPIO. J'ai eu des problèmes de débit avec les Cluster Shared Volumes au début, et il me semble avoir justement mis à jour mes drivers et réglé quelques paramétrages de iSCSI offload, mais en dehors de ça pas de problème particulier au niveau réseau...
    lundi 17 juin 2013 07:42
  • Bonjour, un petit up pour ce sujet qui reste d'actualité .

    Depuis le temps, quelqu'un aurait-il trouvé une solution? Quelles sont les pistes à envisager?

    J'avoue être déconcerté par cette solution... Je l'avais mise en place pour bénéficier d'une haute disponibilité, mais me rend compte que mes machines sont moins disponibles que celles hébergées sur d'autres systèmes en mode simple serveur (vmware, pour ne pas le citer)!

    Une des solutions serait de migrer vers Hyperv2012 Server ou ESXI, quitte à laisser de côté la HA, mais j'ai une contrainte de licence: je possède deux licences 2008 R2 Datacenter et donc gratuité des licences Windows Server pour mes VM. 

    Pour rappel, le problème est toujours le même: tout fonctionne bien, puis d'un coup (ça peut être 1, 2 voire 3 fois par mois, pas de régularité), une de mes VM n'est plus joignable, et dans la console de gestion HyperV le champ "Pulsation" indique "Communication perdue". Il ne s'agit jamais des mêmes VM, toutefois il me semble que le problème n'est apparu que sur des VM Linux (Centos 5 et 6). A confirmer cependant, peut-être une piste à explorer..

    Aucune erreur dans les logs HyperV non plus.

    Merci d'avance pour votre aide!


    • Modifié mrtur vendredi 26 septembre 2014 08:09
    vendredi 26 septembre 2014 08:07