Avant tout, il convient de finaliser quelques configurations pour le cluster.
Je vais ajouter un nom à mon cluster ainsi qu’une adresse VIP. Cette adresse IP, en plus de toutes les adresses des CVM, permettra de joindre le cluster.
J’ajoute également une adresse pour la distribution du service iSCSI. Bien que cela ne soit pas indispensable pour l’instant, cela me sera utile ultérieurement.
Je vais maintenant déployer mon Prism Central.
Il est à noter qu’un “Small PC” est déjà considérable, il faudrait un PC “tiny” pour les environnements de lab.
Je choisis donc de créer un nouveau réseau avec une configuration minimale, sans activation du VLAN tagging ni gestion avancée des adresses IP.Je rajoute le masque de sous-réseau, la passerelle et mes DNS, et je laisse le conteneur par défaut.
Enfin, j’attribue un nom original “PrismCentral” à la VM et lui ajoute une adresse IP.
Grâce à ces quelques clics, une appliance va se déployer sur mon environnement.
Après une bonne demi-heure, le déploiement est terminé.
Je peux maintenant interconnecter Prism Element avec Prism Central que je viens d’installer.
Lors de la première connexion, il faudra entrer les informations demandées et accepter le contrat EULA.
Je conserve bien entendu Pulse activé.
Enfin, j’arrive sur le tableau de bord principal de Prism Central. Comme indiqué, j’ai accès à une version d’essai de 90 jours de Prism Ultimate. Nous explorerons cela plus en détail dans les prochains articles pour en optimiser l’utilisation.
Partager la publication "Nutanix CE 2.0, Part III"
Dans l’article précédent, j’ai résumé les étapes à suivre pour arriver à la page principale de votre Nutanix CE, que vous venez d’installer.
Nous allons voir pour régler les messages d’utilisation de mot de passe par défaut. Il faut savoir qu’il y a un ensemble de scripts qui s’exécute plus ou moins régulièrement en fonction de leur criticité sur le cluster. Nous les appelons Nutanix Cluster Check ou NCC.
En cliquant sur l’alerte, on arrive sur la page qui détaille celle-ci avec un résumé de la découverte, les causes possibles et une recommandation. Vous noterez que presque toutes les alertes sont sur ce format et renvoient à un lien vers la base de connaissances.
En suivant le lien, nous arrivons sur un article de la base de connaissances. Ceux qui concernent des tests NCC sont tous présentés sur le même format : une description du test en question, les lignes de commande pour exécuter ce test manuellement, des exemples de tous les types de sorties que peut produire ce test, puis des propositions de solutions.
Ici, la proposition de solution qui nous intéresse consiste en une petite ligne de commande à exécuter depuis notre CVM pour changer le mot de passe sur tous les nœuds du cluster. Bien que cela ne soit peut-être pas pertinent dans le contexte du lab où nous n’avons qu’un seul nœud, en production, vous serez heureux de ne pas avoir à parcourir manuellement 10 serveurs pour modifier chaque compte.
Depuis notre fenêtre Powershell et en étant connecté en SSH sur notre CVM avec le compte Nutanix (via la commande “ssh nutanix@192.168.0.111“), vous pouvez copier les lignes de commande complètes pour chaque compte, comme dans l’exemple pour le compte root :
“echo -e “CHANGING ALL AHV HOST ROOT PASSWORDS.\nPlease input new password: “; read -rs password1; echo “Confirm new password: “; read -rs password2; if [ “$password1” == “$password2” ]; then for host in $(hostips); do echo Host $host; echo $password1 | ssh root@$host “passwd –stdin root”; done; else echo “The passwords do not match”; fi“
Ces lignes de commande permettent de changer les mots de passe de tous les nœuds du cluster. Vous devrez entrer les mots de passe souhaités lorsque vous y êtes invité. Si les mots de passe saisis correspondent, la commande sera exécutée sur chaque hôte du cluster pour modifier le mot de passe du compte correspondant. Si les mots de passe saisis ne correspondent pas, un message d’erreur sera affiché.
Maintenant que vous avez changé le mot de passe de vos 3 comptes locaux AHV, vous pouvez marquer l’alerte comme résolue dans l’interface de Prism Element (PE).
Il vous reste à faire la même chose pour la dernière alerte restante. CVM using default password.
Si vous suivez le lien vers la KB, il vous conduira sur la même page web, dans la section Nutanix Controller VM (CVM). La solution indiquée est “sudo passwd nutanix“. Ici, il n’y a pas de boucle pour changer le compte sur tous les hyperviseurs car le compte nutanix est synchronisé entre toutes les CVMs du cluster lorsqu’il y en a plusieurs.
Comme pour l’autre alerte, vous pouvez maintenant la marquer comme résolue.
Ceci conclut donc cet article sur la résolution des alertes après l’installation. Dans le prochain article, je procéderai au déploiement du composant Prism Central.
L’installation reste des plus classique, on télécharge un ISO qu’on pousse sur une clé USB avec Rufus par exemple, puis on installe la solution sur son matériel sans avoir à respecter la matrice de compatibilité très stricte de la version commerciale. Dans mon cas, un simple Intel NUC 8, je n’ai pas encore réussi à la faire fonctionner sur mes NUC de génération précédente, mais on parle déjà de matériel sorti il y a 5 ans ou plus.
Je vais ici présenter ce que vous devez faire juste après l’installation. Pendant celle-ci, on vous a simplement demandé une adresse IP pour votre hyperviseur et une autre pour votre CVM. Si vous n’avez pas coché la case pour créer un cluster à un seul nœud, ce n’est pas gênant, voici comment le faire une fois l’installation terminée. Il est possible de créer un cluster avec un seul serveur, ou bien avec 3 jusqu’à un maximum de 4. Ici, je détaillerai l’option à un seul noeud.
(facultatif) Si vous n’avez pas coché la case pour créer un cluster à un seul nœud, vous pouvez vous connecter en SSH à l’adresse IP de la CVM avec le compte root. Dans mon lab, par exemple, l’adresse IP de mon AHV est 192.168.0.110 et l’adresse IP de ma CVM est 192.168.0.111. Le mot de passe par défaut est “nutanix/4u”. Si vous travaillez depuis un ordinateur sous Windows 11, vous pouvez lancer une fenêtre PowerShell et exécuter la commande suivante : “ssh nutanix@192.168.0.111“. Vous devez accepter le certificat, puis entrer le mot de passe par défaut. La commande pour créer le cluster sur un nœud est la suivante : “cluster -s 192.168.0.111 –redundancy_factor=1 create“ J’ai dû la refaire récemment et ce n’était pas du tout ça, mais plutôt… : “cluster -s 192.168.0.111 –cluster_function_list one_node_cluster create” cluster . Vous devez adapter cette commande en fonction de votre configuration IP en remplaçant l’adresse IP de ma CVM (192.168.0.111) par l’adresse IP de votre CVM.
Après quelques minutes et plusieurs opérations de démarrage des services, le cluster devrait être “UP and Running”. Un bon moyen de surveiller l’état du cluster est d’utiliser la commande “cluster status“.
On note bien tous les services UP.
Maintenant l’interface web sera disponible et vous n’avez plus qu’à naviguer sur l’adresse de votre CVM. Dans mon cas : https://192.168.0.111:9440
le mot de passe par défaut du compte admin sera Nutanix/4u attention à la majuscule.
Vous serez immédiatement invité à le modifier en respectant les exigences de sécurité.
Une fois le mot de passe modifié, vous pouvez vous authentifier à nouveau et accéder à la page d’enregistrement de votre compte Nutanix.
Renseigner ici votre compte Nutanix
Vous accédez à la page principale de votre cluster où vous constatez qu’il y a beaucoup de rouge, comme indiqué sur la capture d’écran ci-dessus. Avec un seul serveur au sein du cluster, la partie “Data Resiliency Status” ne peut être qu’en critique. Vous avez également des alertes critiques, car certains mots de passe sont encore ceux par défaut.
Ceci marque la fin de la première partie d’une série d’articles sur mon blog, qui portera sur la création de machines virtuelles, la résolution des erreurs et l’évolution de mon laboratoire.
D’aussi loin que je me souvienne, il y a toujours eu un mécanisme de gestion d’images sur Nutanix. On pouvait y ajouter des ISO, mais aussi des disques. On pouvait aussi préparer une VM pour s’en servir de template et la cloner.
J’ai souvent proposé cette méthode à mes clients pour maintenir à jour une VM qu’on considérait comme un template, et qu’on nommait comme tel pour l’identifier. Le détail de cette méthode est documenté dans la KB8814 – How to create VM template on AHV cluster.
Lors de la création de VM, on a aussi la section Custom Script qui permet la réalisation des opérations de customisations sur la machine avec un script :
Maintenant, ces options de personnalisations sont intégrées dans une fonctionnalité Template apparu avec Prism Central 2022.1.
Depuis la vue VM de Prism Central, sélectionner la VM qui vous intéresse, puis dans le menu du clic droit choisir Create VM Template :
Choisir un nom et une description. C’est la section Guest Customization qui ajoute des options intéressantes en fonction de l’OS :
Pour Windows ce sera Sysprep et pour Linux Cloud-init. Chaque type de script pourra soit être utilisé avec un script personnalisé, soit utiliser la configuration guidée pour choisir les informations de login – mot de passe ou clé SSH, les paramètres régionaux, le nom de l’hôte, la jonction au domaine et la clé de licence.
Exemple de Guide Script pour Windows :
Toujours pour Windows, je vous conseille le site Windows Answer File Generator qui permet de créer simplement un fichier unattend.xml que vous pourrez utiliser dans Custom Script :
Exemple Linux de Guided Script :
Pour Linux, de nombreux exemples sont disponibles sur cloudinit.readthedocs.io dans la section Exemples. Cela vous donnera une idée des énormes possibilités de personnalisation :Une fois les personnalisations définies, on arrive sur un résumé puis on peut sauvegarder le template.
Depuis le menu Templates de Prism Central, nous allons pouvoir déployer des VM depuis notre template récemment créé :
Je donne un nom à la ou les futures VM, je sélectionne le cluster de destination du déploiement, j’indique le nombre de machines à déployer et, le cas échant, l’index de numérotation initial pour l’incrémentation :
Pour l’exemple d’après, je sélectionne l’option Advanced Deploy :
Le menu propose maintenant de personnaliser les ressources CPU et Mémoire :
Puis de modifier l’emplacement réseau. Il est possible de fixer une IP statique si on ne crée qu’une VM à la fois :
Dans la 3e partie, on peut revoir les catégories associées (il faut que la VM qui a servi pour le template soit déjà dans une catégorie) et la timezone, si cela est permis, on peut modifier le script de customisation :
Apres avoir cliqué sur Deploy, une tâche est créé et le provisionnement des VM débute:
Dernier point intéressant : depuis le menu Templates, sélectionner le template à modifier, puis, dans le menu Actions deux options sont disponibles :
Update Guest OS permet de mettre à jour la VM, pour installer des mises à jour de sécurité, par exemple ou pour le déploiement de nouveaux programmes. L’option permet de déployer une machine, de l’éditer, puis d’apporter les modifications au template :
Je mets à jour la machine, puis je l’éteins.
Je retourne dans le menu Templates de Prism Central et, je sélectionne le template que je viens d’éditer. Il est facilement repérable car il a le statut Update Initiated …
Je choisis si je conserve les modifications en cliquant sur Complete Guest OS Update, ou si les annule avec Cancel Guest OS Update :
En choisissant Complete Guest OS Update, je donne un nouveau nom de version, une description claire de ce que j’ai réalisé dans la machine et j’active ce nouveau template:
La version active du template est mise à jour avec nos dernières modifications :
L’autre option du menu Actions consiste à changer les paramètres du template avec Update Configuration :
Ces nouveaux paramètres peuvent s’appliquer soit à la version active soit à n’importe quelle version précédente du template permettant leur réactivation. Ils concernent toutes les étapes, de 1 à 4, de création du template:
Voilà qui conclut notre tour d’horizon des templates à la sauce Nutanix, n’hésitez pas à partager l’article sur les réseaux s’il vous a aidé à y voir plus clair.
AOS 6.5.1 est disponible depuis quelques jours à peine, cette version introduit le support d’Hyper-V 2022 sur les plateformes NX.
La version d’AHV associée (AHV-20201105.30411) n’apporte qu’une correction de bug relative au Uncorrectable Error Correction Code (UECC).
Rien de très intéressant me direz-vous mais à partir de cette base vous pouvez upgrader en 20220304.242 soit la version AHV 8.0 dont voici quelques points :
support du vTPM pour les VMs AHV (enfin !)
support de Windows 11 dont 22H2: il faudra respecter les prérequis suivant mais l’ajout du vTPM était vraiment le point bloquant pour Windows 11 :
Secure boot activé
VirtIO 1.2.1
UEFI
vTPM
Support de Windows Sybsystem for Linux (WSL2)
En plus ce ça sous le capot, les performances de stockage ont été amélioré, les mesures par X-RAY indiquent une amélioration jusqu’à 15% pour les écritures aléatoires 8k et jusqu’à 3% pour la lecture-écriture en séquentielle pour des blocs de 1MB. Amélioration des performances spécialement en cas de forte densité de machines +22% sous VSIMax. Il semble y avoir pas mal d’autre points relatif à la récupération des performances perdu suite à la correction de problèmes de sécurité.
Les plus téméraires d’entre vous pourrons bénéficier dès maintenant de toutes ses améliorations, ou vous pouvez simplement attendre AOS 6.5.2 qui inclura AHV 8.0.
Partager la publication "AOS 6.5.1 – AHV 8 et Windows 11"
