Hyper-V en SMB v3

[GlamSlam]

Bonjour à tous !

 

J'ai réussi à faire fonctionner mon Hyper-V 2019 en mettant les machines virtuelles en SMBv3 stocker sur un Synology, par contre depuis peu, le Failover ne fonctionne plus du tout, comme si l'autre serveur ne connaissait pas le stockage, qui est pourtant un lien SMB "\\blabla\blabla"

Avez vous une idée?

Merci à vous les amis :) 

[Aloyse57]

Il est p-ê juste compatible SMB v1 (qu'il faut activer dans W10 et +)

[r.chatigré]

On 21/02/2020 at 16:15, GlamSlam a écrit :

J'ai réussi à faire fonctionner mon Hyper-V 2019 en mettant les machines virtuelles en SMBv3 stocker sur un Synology, par contre depuis peu, le Failover ne fonctionne plus du tout, comme si l'autre serveur ne connaissait pas le stockage, qui est pourtant un lien SMB "\\blabla\blabla"

Tu as deux servers Hyper-V 2019, ou deux serveurs virtuels sous le même Hyper-V?

[GlamSlam]

Bonjour à vous,

J'ai deux serveurs physiques Hyper-V 2019 Core.

Le stockage de machines virtuelles n'est compatible qu'avec SMBv3.

Je pense surtout que c’est le V1 qui est désactivé par défaut dans Windows 10.

[r.chatigré]

J'ai du mal à comprendre: tu parles de Hyper-V 2019 et de Windows 10.

Si je résume:

• Tu as deux serveurs Hyper-V 2019
• Un stockage SMBv3 sur un NAS Synology
• Une VM qui devrait pouvoir migrer du serveur 1 sur le serveur 2
• Un système de failover qui ne fonctionne pas

Les questions:

• Quel type de failover ne fonctionne pas?
  • Deux VM en cluster failover une VM sur chaque serveur?
  • Une VM qui doit démarrer sur un serveur ou l'autre selon lequel est allumé?
• Qui est le témoin?

• Dans la doc, quand on implémente un Hyper-V sur SMBv3, il faut que le partage soit de profil "Applications" (à priori, cela désactive en particulier le cache)
  • Est-ce que le syno gère ces profils SMBv3?
• Pourquoi ne pas plutôt partager un iSCSI?

Les remarques:

• Normalement, quand on déploie ce genre de solution, on a une autorité d'authentification commune avec des tickets genre kerberos. Je ne sais pas comment cela se passe sans domaine (l'authentification auprès d'un serveur tiers est gérée différemment de l'authentification directe sur le serveur qui rend le service)
• Le stockage SMBv3 peut activer des fonctions très particulières. Je ne serais pas étonné que sur un NAS les fichiers soient très verrouillés si le serveur virtuel est démarré, ce qui empêcherait de voir le fichier sur un autre hyper-V --> faire la configuration des deux Hyper-V "à froid"

[GlamSlam]

Merci Brice pour ta réponse.

La solution du iSCSI s'est posé, mais par manque de connaissance (comment mettre en place un Multi-path) j'ai préféré mettre en place un SMB accessible depuis n'importe quel ordinateur.

En redémarrant l'Hyper-V1 tout s'est bien lancer dans l'Hyper-V 2 bizarrement, mais manuellement impossible de le faire.

Je n'ai pas configurer de disque témoin.

Les deux machines sont dans le même domaine et communique bien entre-elles.

[r.chatigré]

Il y a 2 heures, GlamSlam a écrit :

En redémarrant l'Hyper-V1 tout s'est bien lancer dans l'Hyper-V 2 bizarrement, mais manuellement impossible de le faire.

Je ne suis toujours pas sûr de comprendre ta config: tu as x VMs sur le serveur Hyper-V1 qui doivent démarrer sur le Hyper-V2 si Hyper-V1 ne fonctionne plus?

Dans ce cas:

• C'est une configuration de failover: quand tu pers un serveur, le second redémarre les machines (avec perte momentanée de service)
  • Pour qu'une VM reprenne son serveur d'origine, il faut l'arrêter et la redémarrer (la machine virtuelle)
    --> C'est normal

Je pense que tu souhaites en plus avoir du "live migration": la possibilité de déplacer une VM sur un autre hyperviseur sans l'arrêter

• C'est toute une autre config: les hyperviseurs doivent accepter la migration, il faut peut-être configurer un réseau dédié pour la migration
• Ce n'est pas du tout instantané: vu la vitesse à laquelle la RAM change par rapport à la vitesse de transfert réseau, on peut avoir besoin de déplacer 200Go par le réseau pour 8Go de RAM avant de pouvoir basculer la VM (et ça peut échouer indéfiniment si la mémoire change trop souvent)

Sinon ce qui se fait c'est du clustering:

• On démarre des VM jumelles sur chaque hyperviseur (souvent une active et l'autre en attente)
• Chaque VM est configurée en tant que partie d'un cluster
• Par dessus, on configure des rôles qui peuvent passer d'une machine à l'autre (serveur de fichier, adresse IP, IIS, SQL Serveur, ...)
  --> Là on touche à des mécanismes automatiques avec des VM "préférées" et des possibilités de mises à jour des VM et redémarrage sans arrêt du service
  --> C'est redoutable en terme de traçabilité de configuration (on sait que pour tel "rôle" on a besoin de telles fonctionnalités et point de configuration)
  --> C'est encore une autre config: Hyper-V fait peu ici, tout est dans la config de l'OS de la VM et de ses services. La cohérence est maintenue par la configuration des services
  --> Chaque VM est doublée sur le disque par sa jumelle (on peut toujours faire un master partagé et des disques de différences)

[GlamSlam]

C'est super clair, étant un peu seul dans mon poste d'admin, ça fait du bien de lire une autre vision de l'infra

Effectivement je ne vais peut être pas trop en demander. Le Live Migration refonctionne bien je ne comprend pas ce qui se passe.

Je vais privilégié des serveurs faisant des redondance de service, au cas où un de celui-ci redémarre pour MAJ par ex, j'ai fait ça super simplement pour mon Hyper-V, je pense pouvoir faire la même chose pour mes SMB etc.

Merci beaucoup Brice pour ton aide 🙂

 

[r.chatigré]

Il y a 1 heure, GlamSlam a écrit :

Effectivement je ne vais peut être pas trop en demander. Le Live Migration refonctionne bien je ne comprend pas ce qui se passe.

Je vais privilégié des serveurs faisant des redondance de service, au cas où un de celui-ci redémarre pour MAJ par ex, j'ai fait ça super simplement pour mon Hyper-V, je pense pouvoir faire la même chose pour mes SMB etc.

Pour le live migration, ça peut être très gourmand en ressources et très long selon ce qui se déroule sur ton serveur. Par exemple, un tomcat dont la ram est pleine et qui fait du garbage collection en permanence n'arrivera pas à migrer.

Pour les clusters en redondance, si tu as des licences Ms avec SA, tu as tout pour doubler ton infra. L'idée générale c'est deux serveurs capables d'absorber chacun 100% de la charge ponctuellement (c'est à dire sans rien faire planter mais peut-être en étant plus lent). N'oublie pas qu'une licence Windows Server en vaut deux: tu as le droit d'installer deux Windows server dans un hyper-V (gratuit). Donc si tu sépares en 2 serveurs (stockage et applis par exemple, ou infra et applis), chaque serveur peut être clusterisé en deux (infra1 et infra2, applis1 et applis2), et tu les répartis sur deux serveurs hypervisés. Tu clusterises applis1 et applis2 et infra1 et infra2. En termes de licences, tu as une licence Windows Server par serveur (enfin, maintenant, il faut multiplier par les coeurs), pour 4 OS et 2 hyperviseurs. 

[CryoGen]

Par contre, il me semble que le SMBv3 du Synology n'a pas toutes les fonctionnalités intéressantes pour la virtualisation. Tu aurais peut-être de meilleurs perf en ISCSI.