Migration d'un cluster d'Hyper-V 2012 vers Hyper-V R2 – Serveur d’impression

J'ai obtenu une copie des versions d'aperçu de Windows Server 2012 R2 et de Hyper-V Server 2012 R2 et je voulais mettre à niveau mon cluster. Voici comment je l’ai fait. N'oubliez pas que ceci n'est pas conçu comme un guide pas à pas, mais comme une sorte de récit de ce qui m'est arrivé et de la façon dont j'ai géré le problème. Assurez-vous de lire tout le texte avant de le tenter vous-même pour ne pas être surpris par des surprises.

Au cas où vous auriez besoin d’un rappel, j’ai couvert les clusters Hyper-V dans cette série de messages. Comme je suis en train d’exécuter un cluster à deux nœuds, mon plan était de libérer le nœud 1, d’installer Windows Server sur celui-ci, de déplacer toutes les machines virtuelles vers le nœud 1, d’installer Hyper-V Server sur le nœud 2 et de reconstruire le cluster. Rappelez-vous que je m'en tire avec beaucoup de cascades car il s'agit d'un cluster de test. N'exécutez pas de systèmes d'exploitation d'aperçu en production et ne mélangez pas les systèmes d'exploitation de gestion dans votre cluster. Une fois R2 libéré, ces étapes seront utilisables.

Tout a bien fonctionné comme prévu – au début. Ensuite, les choses ont mal tourné. Lorsque j'ai séparé le nœud 1 de mon domaine Active Directory, il a simplement désactivé le compte de l'ordinateur (il s'agit d'un comportement normal). Après l'installation de R2, je lui ai donné le même nom que le nœud d'origine et je l'ai rejoint dans le domaine. Il a donc immédiatement immédiatement récupéré tous les paramètres de sécurité précédents. Donc, comme je l’ai déjà configuré pour une délégation contrainte, je n’ai pas besoin de le refaire. Cela signifie que j'ai pu utiliser immédiatement la migration SNLM (Shared Nothing Live Migration) pour déplacer les ordinateurs virtuels du nœud 2 (exécutant Hyper-V Server 2012) vers le nœud 1 (exécutant Windows Server 2012 R2 avec Hyper-V en tant que rôle). Je dois indiquer que, comme annoncé, les outils de gestionnaire de cluster de basculement et de gestionnaire de serveur Hyper-V de Windows Server 2012 R2 n'ont pas rencontré de difficultés pour gérer les ordinateurs virtuels et les opérations de cluster sur mon serveur Hyper-V Server 2012. Les applets de commande PowerShell ciblées à distance (à l'aide du paramètre -ComputerName, et non d'une session distante) ont également fonctionné comme prévu.

Ensuite, je me suis endormi. Je me suis levé le lendemain matin et je ne pouvais plus exécuter de SNLM. J'ai vérifié dans Active Directory et la délégation contrainte du noeud 1 au noeud 2 était toujours là, mais pas l'inverse. Pas de problème, je vais juste les rajouter. Pas de dé:

Impossible d'ajouter une délégation

Après quelques recherches, j'ai déterminé que cette erreur signifiait essentiellement: l'objet est cassé. J'ai donc commencé à charger ADSI Edit pour commencer un travail vraiment difficile. Ensuite, j'ai réalisé que je suis paresseux et que je n'aime pas vraiment travailler dur. Je suis donc retourné dans Utilisateurs et ordinateurs Active Directory sous l'onglet Délégation de l'hôte d'origine. Je l'ai remis à Ne faites pas confiance à cet ordinateur pour la délégation et cliqué Appliquer. Ensuite, j'ai remis toutes les délégations à la manière dont je les avais. Après le redémarrage de l'hôte source, SNLM a à nouveau fonctionné correctement. Notez que j’ai essayé de redémarrer Netlogon pour le faire actualiser d’abord ses paramètres de sécurité, mais cela ne suffisait pas. Peut-être que si j’avais redémarré VMMS, c’est possible.

SNLM s'est ensuite déroulé exactement comme prévu pour mes machines virtuelles non hautement disponibles. Les plus disponibles nécessitaient un peu plus de travail. La première chose que je devais faire était de les rendre non hautement disponibles. La méthode la plus simple consiste à cliquer dessus avec le bouton droit de la souris dans le Gestionnaire de cluster de basculement, puis à cliquer sur Retirer. Rien n’est réellement supprimé si ce n’est la connaissance et le contrôle du service de cluster sur la machine virtuelle. Maintenant, vous pouvez simplement lancer SNLM. Jusqu'à ce que j'effectue la réinitialisation de la délégation, j'avais des résultats mitigés avec cette méthode, alors je vous conseille de reconstruire vos délégations avant de poursuivre. Si, comme moi, vous ne disposez que de deux noeuds et que le redémarrage introduit un temps d'inactivité invité non souhaité, les modifications de délégation risquent de reprendre si vous attendez un moment. Les fichiers de mes ordinateurs virtuels hautement disponibles se trouvaient sur un fichier CSV, et celui-ci, bien entendu, ne peut être connecté qu'à un cluster à la fois. Le nouveau noeud n'avait aucune visibilité. Je voulais donc utiliser SNLM pour déplacer la machine virtuelle afin qu'elle s'exécute sur le nœud 1 mais qu'elle soit stockée sur un partage SMB 3.0. Utilisation du gestionnaire Hyper-V Bouge toi opération, je lui ai dit de Déplacer la machine virtuelle et Déplacer les données de la machine virtuelle vers un emplacement unique sur les écrans correspondants. J'ai configuré la destination comme suit:

SNLM de 2012 à R2, partie 1

Si vous ne reconfigurez pas d’abord les délégations, cela peut ne pas fonctionner. Ce que j’ai rencontré avant d’apporter ce changement, c’est que cela provoquerait des erreurs concernant l’emplacement du fichier CSV. Ce que j’ai fini par faire, c’était de définir l’option permettant de déplacer chacun des fichiers de la machine virtuelle vers des emplacements distincts, puis de définir la même destination pour tous. Lors des discussions avec d’autres personnes sur la migration croisée Shared Nothing Live, je n’avais pas fait très attention à la question et je ne savais pas que c’était à sens unique. Vous pouvez seulement aller de 2012 à 2012 R2, et non l'inverse. Comme je doute que je sois la seule personne à ne pas faire attention, j’ai répertorié les erreurs que vous allez rencontrer si vous essayez. Si vous essayez d'utiliser Hyper-V Manager en 2012 R2 pour SNLM une machine virtuelle de 2012 R2 à 2012, voici ce que vous obtiendrez:

Erreur lors de la tentative de SNLM de 2012 R2 à 2012

Si vous utilisez PowerShell pour démarrer la migration à partir de l'hôte R1, voici ce que vous obtiendrez:

SNLM de 2012 R2 à 2012 dans PowerShell

Lorsque vous essayez de SNLM de R2 à R1 à partir du gestionnaire Hyper-V sous Windows 8 ou Windows Server 2012, vous obtenez le même message de base que celui présenté dans la sortie PowerShell ci-dessus.

Ne perdez pas de vue le fait que j’ai effectué toutes mes migrations en utilisant SNLM et un partage SMB 3.0. Vous ne pourrez pas déplacer des machines virtuelles tout en les conservant sur un fichier CSV. Si vous n’avez pas un bon stockage pour SMB 3.0, vous avez d’autres options. L'une consiste simplement à créer de nouveaux LUN et à les attacher à votre hôte R2 par Fibre Channel ou iSCSI. Une fois que vous recréez le cluster, vous pouvez les ajouter en tant que disques de cluster, puis les convertir en fichiers CSV, bien que cela rompe le pointeur VHD sur toutes les machines virtuelles. Si votre configuration le permet, vous pouvez même les déplacer temporairement dans la mémoire interne du nœud R2. Si vous êtes vraiment en mauvais état, vous pouvez exporter les ordinateurs virtuels source et les placer sur un stockage externe, puis reconstruire le cluster et les importer. L'autre chose à retenir est que j'ai tout déplacé des CSV d'origine. Cela était positif car, lors de la reconnexion au stockage, l'un de mes nœuds ne voulait absolument pas communiquer avec l'un des disques iSCSI d'origine. Il le voyait comme «RAW» et rien ne changerait d'avis. Le deuxième nœud était capable de le gérer assez bien, mais je devais en fait supprimer et recréer le LUN pour que le premier nœud puisse fonctionner avec ce dernier. Aucun des deux nœuds n'a eu de problèmes avec les autres CSV, cependant. Cela signifie que vous ne pouvez pas compter sur le fait de pouvoir simplement réattacher vos LUN comme si de rien n'était. Peut-être que si j'avais pris le temps de les supprimer du stockage CSV et du stockage en cluster avant de détruire le cluster d'origine, cela n'aurait pas posé problème.

Après le drame de stockage, tout était assez simple. J'ai disjoint le deuxième noeud, mais je ne l'ai pas supprimé du cluster ni détruit le cluster. Je l'ai reconstruit (avec Hyper-V Server 2012 R2 Preview). Je l'ai configuré et l'a rajouté au domaine. J'ai reconfiguré la délégation contrainte. Ensuite, j’ai désactivé l’objet Nom du cluster du cluster d’origine (le compte de l’ordinateur qui le représentait dans Active Directory). Ensuite, j'ai reconstruit le cluster tel qu'il était auparavant, en utilisant le CNO d'origine, en suivant les mêmes étapes que pour R2. Dans mon cas, j’ai utilisé l’assistant de validation dans le gestionnaire de cluster de basculement, même si je sais qu’il va y avoir une erreur lorsqu’un système d’exploitation ne correspond pas. Comme il s’agit d’un cluster de test et que je ne me soucie pas du support, j’aurais tout aussi bien pu le créer directement sans validation. Une fois le cluster reconstruit, j'ai utilisé SNLM pour déplacer les machines virtuelles de mon choix sur le noeud 2. Je place toujours mes contrôleurs de domaine et les systèmes de surveillance Nagios sur la mémoire de stockage interne de ces unités. J'ai utilisé le gestionnaire de cluster de basculement pour rétablir les machines virtuelles sur le stockage SMB 3.0 en haute disponibilité. Tout ce que vous avez à faire est un clic droit Les rôles dans le volet de gauche et cliquez sur Configurer le rôle… Choisir Machine virtuelleet une liste de toutes les machines virtuelles qu’il peut voir sur n’importe quel nœud. Vérifiez ceux qui se trouvent sur le stockage à haute disponibilité et ils convertiront tous. N’oubliez pas de mettre à niveau Integration Services chez vos invités!