none
Win Server 2019 : erreur disques sur VM RRS feed

  • Discussion générale

  • Bonjour,
    Présentation rapide du SI afin que vous puissiez m'aider à trouver une solution :
    2 serveurs Sequana sous Win Server 2019 en cluster Hyper-V.
    7 VM sous Win Server 2019 également.
    Les VM sont toutes stockées sur un SAN relié via des fibres aux deux serveurs physiques.
    Les VM sont constituées d'un disque OS et un disque Data.
    Le SAN ne fait remonter aucune erreur hardware ou software, les fibres ont été changées.
    Mes users sont en profils itinérants de telle sorte qu'aucun fichier ne soit stocké dans c:\users\%nom_user%
    Sur mes hosts, j'ai donc les accès aux dossiers Quorum et aux trois LUN créés (1 Lun pour les disques OS, 1 Lun pour les disques data, 1 lun pour le disque Exchange).
    Problème : mes VM freezent, donc plantage méchant pour mes utilisateurs vu que les profils ne sont pas en local.
    Sur mes VM, notamment celle qui stocke les profils et les fichiers, je vois l'event "ID 129, Storvsc Reset to device, \Device\RaidPort0, was issued".
    De plus, dans Microsoft-Windows-Storage-Storport/Operational, j'ai des events 549, 557 et 550 qui apparaissent lors des freezes, ces events faisant penser à un timeout lors de l'accès au disque.
    J'ai vu que sous Win Server 2012 ce problème existait déjà mais a été corrigé :
    https://social.technet.microsoft.com/Forums/windowsserver/en-US/e95631c6-c6b0-4dc8-a003-af4adbf113e9/windows-server-2012-can-occasionally-not-access-second-virtual-hard-drive-inside-a-vm?forum=winserverhyperv
    Auriez-vous une idée ?
    Malgré mes recherches depuis plusieurs mois, je sèche complètement.
    Je vous en remercie.

    vendredi 19 juin 2020 08:32

Toutes les réponses

  • Bonjour,

    Après recherches, je pense que les VM reproduisent un problème que je trouve sur les deux hôtes, à savoir que dans Microsoft-Windows-Storage-Storport/Operational j'ai des erreurs de timeout sur les accès aux LUNs.

    Est-ce qu'un problème est connu avec la carte EMULEX LPe31002-M6 ?

    Je pense exclure la fibre défectueuse, les deux hôtes ayant le problème et ayant deux paires par hôte par sécurité.

    Y-a-t'il un retex, un bug connu ?

    Je vous en remercie.

    mercredi 24 juin 2020 07:58
  • En faisant des recherches de "problem sequana problem EMULEX LPe31002-M6" aussi bien dans BING que dans GOOGLE, il n'apparait pas de problématique connue et traitée pour ta carte.

    Quel pilote as tu utilisé pour ta carte sur tes serveurs ?

    mercredi 24 juin 2020 10:38
  • Un autre paramètre ultra-important dans un cluster hyper-v est la configuration réseau dédiée au cluster.

    Peux tu me dire combien de port réseau affecté au cluster ? et le type de tes cartes réseaux ?

    jeudi 25 juin 2020 07:39
  • En faisant des recherches de "problem sequana problem EMULEX LPe31002-M6" aussi bien dans BING que dans GOOGLE, il n'apparait pas de problématique connue et traitée pour ta carte.

    Quel pilote as tu utilisé pour ta carte sur tes serveurs ?

    Bonjour,

    Je vous prie de bien vouloir m'excuser pour les réponses tardives, j'ai dû m'absenter du service quelques jours.

    Les pilotes sont ceux de Broadcom, nous avons fait plusieurs montées de versions depuis l'installation du matériel. Au début nous avions les pilotes fournis dans le DVD du fabriquant (BULL Sequana), puis nous avons testé ceux de Broadcom via leur site pour tenter de régler le problème, en vain.

    Actuellement, nous avons la version du 7/12/2019, à savoir la 12.6.165.0.

    Je pense monter encore en version sur un hyperviseur et mettre à jour le firmware pour essayer de stabiliser le système.

    Un copain m'a suggéré également de rajouter un "switch" pour fibres entre les appareils afin d'atténuer les pertes et lisser le signal, vous en pensez quoi ?

    Merci encore pour votre aide.

    lundi 29 juin 2020 13:21
  • Un autre paramètre ultra-important dans un cluster hyper-v est la configuration réseau dédiée au cluster.

    Peux tu me dire combien de port réseau affecté au cluster ? et le type de tes cartes réseaux ?

    Sur chaque serveur j'ai une carte réseau 4 ports.

    1 port est dédié à la partie administration, les trois autres sont regroupés au sein du vSwitch.

    Dans les deux serveurs, il s'agit d'une carte Intel Ethernet Connexion x722 10GBASE-T.

    lundi 29 juin 2020 13:33
  • Tu dispose donc d'un seul port pour la communication du cluster de ce que je comprend. Lorsque tu utilise un disque partagé en cluster, un seul des 2 hosts dispose d'un accès lecture/écriture. Le second host envoie les demandes d'écriture d'I/O via la carte réseau dédiée au cluster.

    Il serait bon que le serveur qui héberge les profils itinérants soit sur le serveur qui détient l'accès disque en direct. Regarde au niveau du propriétaire du disque.

    A te lire.

    mardi 30 juin 2020 11:57
  • Tu dispose donc d'un seul port pour la communication du cluster de ce que je comprend. Lorsque tu utilise un disque partagé en cluster, un seul des 2 hosts dispose d'un accès lecture/écriture. Le second host envoie les demandes d'écriture d'I/O via la carte réseau dédiée au cluster.

    Il serait bon que le serveur qui héberge les profils itinérants soit sur le serveur qui détient l'accès disque en direct. Regarde au niveau du propriétaire du disque.

    A te lire.

    J'ai essayé en plaçant les VM sur les deux hosts, donc le propriétaire et l'autre.

    J'ai eu le phénomène sur l'host propriétaire de l'accès hier et sur l'autre ce matin.

    La seule manière que je trouve pour stopper l'erreur est de migrer les VM d'un host à l'autre sinon je pars pour 10-15 minutes d’inaccessibilité avant que ça ne reparte sans intervention.

    Un switch sera installé entre les hosts et le SAN dans deux semaines afin de récolter des logs à son niveau. Je pense également changer les fibres au cas où je serai sur une mauvaise série.

    jeudi 2 juillet 2020 11:47
  • Tu peux vérifier déjà en lançant le moniteur de ressources sur chacun des hosts (s'ils ne sont pas en core) et en regardant dans la partie stockage tout en bas la valeur de "longueur de file d'attente" sur chacun des disques connectés.
    jeudi 2 juillet 2020 13:59
  • J'essaye d'être présent lors des dysfonctionnements, pour l'instant en vain.

    J'ai tout de même regardé le monitoring.

    J'ai le lecteur C: correspondant au lecteur physique de l'hôte, la longueur de file d'attente est de 0.00.

    J'ai un lecteur Q: correspondant à mon quorum, me permettant d'accéder aux différentes VM. Pour le moment, je ne le vois qu'à 0.00 également. Il faudrait que je sois présent lors d'un dysfonctionnement pour observer s'il y a une modification de cette valeurs.
    Je reviens vers vous dès que j'ai pu observer la (non)variation de cette valeurs lors des plantages.

    Cordialement

    mercredi 8 juillet 2020 13:42