de VMware à Azure Local

La migration des machines virtuelles depuis VMware vers Azure Local via l’outil Azure Migrate a récemment été annoncée en préversion. Cette nouveauté chez Microsoft représente une avancée significative dans les migrations automatisées vers le cloud hybride. Cette nouvelle fonctionnalité d’Azure Migrate permet donc aux organisations de transférer leurs charges de travail sur site vers une infrastructure Azure Local tout en minimisant les interruptions.

Depuis quelques déjà, il existe sur le marché d’autres solutions externes qui proposent la migration de machines virtuelles hébergées sur VMware vers un cluster Azure Local :

Azure nous facilite donc la chose en l’intégrant dans Azure Migrate. En parlant d’Azure Migrate, un premier article sous forme d’exercice est disponible juste ici. Il vous permet de tester la migration de machines virtuelles Hyper-V vers Azure :

De façon générale, voici quelqu’un des principaux avantages à utiliser Azure Migrate :

  • Aucune préparation requise : La migration ne nécessite pas l’installation d’agents sur les machines virtuelles hébergés sous Hyper-V ou VMware.
  • Contrôle via le portail Azure : Les utilisateurs peuvent gérer et suivre toutes les étapes de leur migration directement depuis le portail Azure.
  • Flux de données local : Les données restent sur site pendant la migration, ce qui réduit les risques de latence.
  • Temps d’arrêt minimal : La solution permet de migrer les VMs avec un impact minimal sur les opérations en cours.

Aujourd’hui, nous sommes ravis d’annoncer l’avant-première publique de la fonctionnalité Azure Migrate permettant de migrer des machines virtuelles de VMware vers Azure Local, une amélioration significative de nos capacités de migration vers le cloud qui s’étend de manière transparente jusqu’à la périphérie, conformément à notre approche du cloud adaptatif.

Microsoft Tech Community

L’écran ci-dessous nous montre la section dédiée à la migration de ressources vers Azure Local :

Comment se passe la migration VMware -> Azure Local ?

Les grandes étapes d’une migration vers Azure Local sont très proches de celles vers Azure. Quelques étapes et composants nécessaires différent légèrement :

  • Un projet doit toujours être créé via Azure Migrate depuis le portail Azure
  • 2 appliances (VMware et Azure Local) doivent être créées et configurées
    • Une appliance virtuelle s’exécutant sur les serveurs VMware
    • Une seconde appliance virtuelle s’exécutant sur le cluster Azure Local

Voici les principales phases du processus de migration Azure Migrate :

Phase de migrationDescription
1. PréparationPréparez-vous à migrer en complétant les prérequis. Déployez et configurez votre cluster Azure Local. Créez un projet Azure Migrate et un compte de stockage Azure.
2. DécouverteCréez et configurez une appliance source Azure Migrate sur VMware pour découvrir vos serveurs.
3. RéplicationConfigurez l’appliance cible sur Azure Local et sélectionnez les VMs à répliquer.
4. Migration et vérificationMigrez les VMs vers Azure Local et vérifiez leur bon fonctionnement après la migration.

Quels sont les systèmes d’exploitation pris en charge ?

Pour que cette migration puisse fonctionner, seulement certaines versions d’OS sont actuellement prises en charge :

ComposantSystèmes d’exploitation pris en charge
Environnement VMware sourceVMware vCenter Server version 8.0
VMware vCenter Server version 7.0
VMware vCenter Server version 6.7

VMware vCenter Server version 6.5
Appliance VMware Windows Server 2022
Environnement Azure Local cibleAzure Local, version 23H2
Appliance Azure LocalWindows Server 2022
Machine virtuelle invitée (Windows)Windows Server 2022
Windows Server 2019
Windows Server 2016
Windows Server 2012 R2
Windows Server 2008 R2*
Machine virtuelle invitée (Linux)Red Hat Linux 6.x, 7.x
Ubuntu Server et Pro. 18.x
CentOS 7.x
SUSE Linux Enterprise 12.x
Debian 9.x

Microsoft liste toutes les conditions requises pour envisager cette migration juste ici.

Puis-je créer mon projet Azure Migrate dans toutes les géographies Azure ?

Pour le moment, les métadonnées de votre projet Azure Migrate peuvent être uniquement stockées dans une des géographies Azure suivantes pour les migrations vers Azure Local :

GéographiesRégions
Asie-PacifiqueAsie Sud-Est, Asie Est
EuropeEurope Nord – Europe Ouest
États-UnisUSA Centre, USA Ouest2

Maintenant, il nous reste plus qu’à tester tout cela 😎💪

Etape 0 – Rappel des prérequis :

Des prérequis sont nécessaires pour réaliser cet exercice dédié à la migration d’une machine virtuelle hébergée sur VMware vers Azure Local via Azure Migrate. Pour tout cela, il nous faut :

  • Un tenant Microsoft
  • Une souscription Azure active
  • Un environnement Azure Local opérationnel
  • Un environnement VMware opérationnel

Commençons par la création du projet sur Azure Migrate, puis la configuration de l’appliance sur l’environnement VMware.

Etape I – Configuration VMware :

Pour cela, recherchez le service Azure Migrate grâce à la barre de recherche présente dans votre portail Azure :

Sélectionnez le menu suivant, puis cliquez-ici pour créer votre projet de migration :

Renseignez les différentes informations de votre projet en prenant en compte les géographies supportant ce scénario de migration, puis cliquez sur Créer :

Une fois le projet créé, cliquez-ici afin d’installer une appliance sur l’environnement VMware :

Définissez la cible de migration comme étant sur Azure Local, puis la source comme étant VMware :

Nommez votre appliance VMware, puis cliquez ici pour générer une clef d’association (entre l’appliance et votre projet d’Azure Migrate) :

Une fois la clef générée, copiez la dans votre bloc-notes :

Lancez le téléchargement de votre appliance afin de pouvoir en disposer par la suite sur votre environnement VMware :

Afin d’y accéder plus facilement sur vSphere, vous pouvez créer un compte de stockage publique :

Dans ce compte de stockage, créez un conteneur blob :

Une fois l’image de l’appliance téléchargée localement, utilisez l’outil azcopy afin de déposer votre image OVA sur votre compte de stockage blob :

Vérifiez la présence de l’image OVA sur votre compte de stockage, puis cliquez dessus :

Récupérez l’URL blob de votre image OVA accessible publiquement :

Depuis votre console vSphere, cliquez-ici pour créer une nouvelle machine virtuelle via la fonction de template OVF :

Collez l’URL de votre image OVA, puis cliquez sur Suivant :

Confirmez votre confiance en cliquant sur Oui :

Nommez votre machine virtuelle appliance, ainsi que son dossier, puis cliquez sur Suivant :

Sélectionnez la ressource de calcul VMware adéquate, cochez la case de démarrage après création, puis cliquez sur Suivant :

Vérifiez toutes les informations dont l’OS utilisé par l’appliance VMware, puis cliquez sur Suivant :

Définissez la ressource de stockage VMware adéquate, puis cliquez sur Suivant :

Choisissez le réseau virtuel VMware adéquat, puis cliquez sur Suivant :

Vérifiez toutes les informations avant la création de la machine virtuelle, puis cliquez sur Finir :

Constatez la création de 2 tâches, puis attendez quelques minutes :

  • vSphere VMware rapatrie l’image OVA,
  • vSphere créé la machine virtuelle appliance

Une fois la VM créée, installez-y les outils VMware :

Cliquez sur Mettre à jour :

Une fois la VM démarrée, ouvrez la console web de celle-ci :

Attendez la finalisation de la préparation de Windows Server :

Acceptez les Termes et conditions :

Configurez le mot de passe du compte administrateur (clavier US), puis cliquez sur Finaliser :

Connectez-vous avec le mot de passe configuré juste avant :

Attendez quelques minutes pour voir automatiquement s’ouvrir le navigateur internet :

Acceptez les Termes et conditions d’Azure Migrate :

Laissez faire la connexion entre votre appliance VMware et Azure :

Collez la clef de votre projet Azure Migrate, puis cliquez sur Vérifier :

Une fois vérifiée, attendez quelques minutes pour constater d’éventuelles mises à jour de l’appliance VMware :

Rafraîchissez la page au besoin si le système vous le demande :

Authentifiez-vous avec votre compte Azure :

Cliquez ici pour utiliser le mécanisme d’authentification Azure PowerShell pour l’appliance VMware :

Collez le code donné précédemment, puis cliquez sur Suivant :

Choisissez le compte Azure aux droits RBAC adéquats :

Cliquez sur Continuer pour autoriser l’authentification Azure :

Fermez la fenêtre de navigation internet :

Attendez quelques minutes le temps de l’enrôlement de l’appliance VMware dans Azure Migrate :

Comme indiqué récupérez l’applicatif VMware Virtual Disk Developpement Kit depuis une source internet, copiez le dossier, puis cliquez sur Vérifier :

Afin que l’appliance VMware puisse découvrir les machines virtuelles en fonctionnement sur vCenter, cliquez-ici pour ajouter les informations d’identification :

Cliquez ici pour ajouter des informations sur les VMs hébergées sur VMware à analyser :

Vérifiez que la validation s’est effectuée avec succès :

Comme nous n’avons pas besoin d’effectuer d’analyse d’applications particulières, désactivez cette fonction :

Cliquez ici pour démarrer la découverte des machines virtuelles sur VMware :

Mais, avant de retourner sur Azure, n’oubliez pas de renseigner et de valider les informations d’identification de votre cluster Azure Local :

La découverte est terminée et les résultats sont disponibles sur Azure :

Retournez sur le portail Azure afin de rafraîchir la page de votre projet Azure Migrate :

Quelques rafraîchissements plus tard, les serveurs VMware commencent à faire leur apparition :

La configuration VMware est maintenant terminée, nous allons pouvoir nous concentrer sur la seconde partie de la configuration dédiée à Azure Local.

Etape II – Configuration Azure Local :

Toujours sur votre projet Azure Migrate, cliquez alors sur le bouton Répliquer :

Renseignez les informations suivantes, puis cliquez sur Continuer :

  • Sélectionnez le type de service : Serveurs ou machines virtuelles (VM)
  • Sélectionnez la destination : Azure Local
  • Sélectionnez la source : VMware vSphere
  • Pour l’appliance Azure Migrate : l’appliance créée sur votre vCenter

Renseignez les informations de votre cluster Azure Local, puis cliquez sur Suivant :

Indiquez un nom pour l’appliance Azure Local, générez la clé, puis copiez cette dernière dans un bloc note :

Télécharger le fichier ZIP de votre appliance Azure Local :

À l’aide d’Hyper-V Manager, créez une nouvelle VM sous Windows Server 2022, avec 80 Go (min) de stockage sur disque, 16 Go (min) de mémoire et 8 processeurs virtuels sur un de vos nœuds Azure Local, puis démarrez celle-ci :

Une fois authentifié en mode administrateur sur cette appliance Azure Local, copiez et collez le fichier zip téléchargé.

En tant qu’administrateur, exécutez le script PowerShell suivant à partir des fichiers extraits pour installer l’appliance Azure Local :

Set-ExecutionPolicy -ExecutionPolicy Unrestricted
.\AzureMigrateInstaller.ps1

Choisissez l’option 4 :

Choisissez l’option 1 :

Choisissez l’option 1 :

Confirmez votre action avec Y :

Attendez quelques minutes la fin du traitement :

Confirmez votre action avec l’option A :

Confirmez votre action avec N :

Redémarrez la VM, reconnectez-vous avec le même compte administrateur, ouvrez Azure Migrate Target Appliance Configuration Manager à partir du raccourci du bureau, puis collez la clef précédemment copiée :

Attendez quelques minutes le temps de l’enrôlement de l’appliance Azure Local dans votre projet Azure Migrate, puis authentifiez-vous via Azure PowerShell :

Une fois l’appliance Azure Local enregistrée, sous Gérer les informations du cluster Azure Local, sélectionnez Ajouter des informations de cluster, puis cliquez sur Configurer :

Attendez quelques minutes la fin de la configuration :

Retournez sur le projet Azure Migrate depuis le portail Azure, puis cliquez-ici :

Constatez l’apparition l’appliance Azure Local, puis cliquez sur Suivant :

Choisissez la machine virtuelle à migrer sur votre cluster Azure Local, puis cliquez sur Suivant :

Définissez la configuration réseau et stockage de votre machine virtuelle migrée, puis cliquez sur Suivant :

Configurez le nombre de vCPU et la RAM, puis cliquez sur Suivant :

Sélectionnez les disques que vous souhaitez répliquer, puis cliquez sur Suivant :

Dans ce dernier onglet, assurez-vous que toutes les valeurs sont correctes, puis sélectionnez Répliquer :

Restez sur cette page jusqu’à la fin du processus (cela peut prendre 5 à 10 minutes). Si vous quittez cette page, les objets liés à la réplication ne seront pas entièrement créés, ce qui entraînera un échec de la réplication et, par la suite, de la migration.

Les 2 notifications Azure suivantes devraient alors s’afficher :

De retour sur votre projet Azure Migrate, vous pouvez suivre votre réplication depuis le menu suivant :

Une section dédiée à Azure Local est disponibles et affiche les réplications, les opérations et les événements, cliquez-ici pour avoir plus de détail sur la réplication en cours :

Les différentes étapes de réplication se suivent :

La progression via un pourcentage est même visible :

La phase finale de synchronisation des données arrive par la suite :

La prochaine étape consistera justement à faire la migration pour basculer notre VM vers Azure Local.

Etape III – Migration VMware -> Azure Local :

Une fois la réplication terminée, la machine virtuelle répliquée sur Azure Local est visible en cliquant ici :

Cliquez alors sur le statut de la machine virtuelle vous indiquant que la migration est prête :

Déclenchez la migration vers Azure Local en cliquant ici :

La notification Azure suivante apparaît alors :

Le travail de bascule planifiée est visible dans le menu suivant :

Les différentes étapes de migration vers Azure Local se suivent :

Rafraîchissez cette fenêtre plusieurs fois afin de constater le succès du processus :

Constatez l’apparition de la machine virtuelle migrée sur la page Azure de votre cluster Azure Local, puis cliquez dessus :

Copiez l’adresse IP privée de cette nouvelle machine virtuelle créée sous Azure Local :

Etape IV – Actions post-migration :

Dans mon scénario, j’ai utilisé une connexion Azure Virtual Desktop hébergé sur mon cluster Azure Local :

Une fois sur le réseau de votre Azure Local, ouvrez une connexion RDP vers l’adresse IP de votre machine virtuelle migrée :

Rentrez les identifiants de l’administrateur local, puis cliquez sur OK :

Constatez la bonne ouverture de session Windows sur votre machine virtuelle migrée :

Si la migration vous semble réussie, retournez sur votre projet Azure Migrate afin de déclarer la migration vers Azure Local comme étant complète :

Confirmez votre choix d’arrêt de réplication en cliquant sur Oui :

La notification Azure suivante apparaît alors :

L’action de Terminer la migration ne fera que nettoyer la réplication en supprimant le travail de suppression de l’élément protégé – cela n’affectera pas votre VM migrée.

Une fois la ressource migrée supprimée, elle est également supprimée de la vue Réplications. Vous verrez également le travail de migration de la VM disparaître de la vue Réplications :

Retournez sur la machine virtuelle sous Azure Local afin de finaliser l’intégration de cette VM dans l’hyperviseur Azure Local :

Il nous faut donc activer la gestion des invités pour la machines virtuelle migrée en y attachant l’ISO.

Pour cela, connectez-vous à un serveur Azure Local, puis exécutez la commande CLI suivante dans une fenêtre PowerShell sur la VM migrée pour laquelle l’agent invité doit être activé :

az stack-hci-vm update --name $vmName --resource-group $rgName --enable-vm-config-agent true

Affichez les informations de l’installeur de l’agent :

Installez l’ISO de l’agent invité sur la VM migrée comme suit :

$d=Get-Volume -FileSystemLabel mocguestagentprov;$p=Join-Path ($d.DriveLetter+':\') 'install.ps1';powershell $p

Activez la gestion de l’invité après que l’agent de l’invité a été installé de la manière suivante :

az stack-hci-vm update --name $vmName --resource-group $rgName --enable-agent true

Cette dernière étape n’a malheureusement pas fonctionné chez moi, comme l’indique encore le statut du management invité :

Le sujet est encore en discussion sur le forum Tech Community de Microsoft :

Nul doute que le souci va être corrigé sous peu ! Une page de résolution des problèmes a aussi été créée par Microsoft juste ici, ainsi qu’une FAQ.

Conclusion

En choisissant de migrer de VMware vers Azure Local, les entreprises s’engagent dans une transformation stratégique qui allie flexibilité et modernité.

Cette transition permet non seulement de consolider les ressources locales avec la puissance d’Azure, mais aussi de réduire les coûts opérationnels et de simplifier la gestion des infrastructures hybrides.

Azure Virtual Desktop sur Azure Stack HCI

Bonne nouvelle ! Azure Stack HCI 23H2 est maintenant disponible en GA. La 23H2 simplifie grandement la configuration et le déploiement des clusters HCI. Autre bonne nouvelle, AVD est aussi en GA sur Azure Stack HCI ! Si tester Azure Virtual Desktop via une solution cloud hybride et sans acheter quoi que ce soit vous intéresse, cet article est fait pour vous !

Un premier article avait déjà été écrit sur ce blog à propos d’Azure Stack HCI. La solution proposée par Microsoft vous permet de disposer d’une infrastructure hyperconvergée basée sur les technologies Azure :

Peut-on tester Azure Stack HCI sans investir dans du matériel physique ?

La réponse est oui grâce à Azure Arc Jumpstart ! Vous pouvez recréer un cluster Azure Stack HCI directement dans Azure. L’article précédemment écrit proposait la même approche, mais Jumpstart simplifie grandement le processus.

Qu’est-ce qu’Azure Arc Jumpstart ?

Il s’agit de solutions de type bac à sable proposées par Microsoft :

L’univers de l’Arc Jumpstart. Vous souhaitez explorer plusieurs environnements et découvrir toute l’étendue de Jumpstart ? Obtenez des scénarios automatisés de zéro à héros pour les serveurs compatibles avec Arc, Kubernetes compatible avec Arc, et plus encore. Parcourez les scénarios. Explorez des scénarios du cloud à la périphérie conçus pour répondre à des besoins sectoriels spécifiques.

Azure Arc Jumpstart

Comme le montre la page suivante, beaucoup de scénarios y sont proposés :

Mais qu’est-ce qu’HCIBox ?

En quelques mots : il vous permet d’essayer Azure Stack HCI directement dans Azure :

HCIBox est une solution clé en main qui fournit un bac à sable complet pour explorer les capacités d’Azure Stack HCI et l’intégration du cloud hybride dans un environnement virtualisé. HCIBox est conçu pour être complètement autonome au sein d’un seul abonnement Azure et d’un seul groupe de ressources, ce qui permettra à un utilisateur de se familiariser facilement avec Azure Stack HCI et la technologie Azure Arc sans avoir besoin de matériel physique.

Azure Arc Jumpstart

Combien coûte le service HCIBox ?

Les ressources HCIBox entraînent des frais de consommation Azure, qui dépendent des ressources Azure sous-jacentes telles que le calcul central, le stockage, le réseau.

Voici une idée de ce que peut représenter une HCIBox fonctionnant en 24/7 pendant 31 jours et hébergée en Suisse :

Enfin, une FAQ de la HCIBox est disponible juste ici.

Pour vous faire une meilleure idée, je vous propose de réaliser ensemble un petit exercice Azure Virtual Desktop fonctionnant grâce à un Azure Stack HCI construit dans une HCIBox elle-même hébergée sur Azure :

Etape 0 – Rappel des prérequis :

Pour réaliser cet exercice, il vous faudra disposer de :

  • Un tenant Microsoft
  • Une souscription Azure valide

Etape I – Préparation de l’environnement Azure :

Afin de pouvoir déployer les ressources Azure liées à la HCIBox, il est nécessaire d’avoir un quota CPU suffisant pour une famille particulière de machines virtuelles.

Pour cela, ouvrez votre souscription Azure, puis rendez-vous sur le menu suivant afin de vérifier que le quota de la famille ESv5 est au minimum de 32 cœurs :

Note : Si cela n’est pas le cas, le stylo à droite vous permet de créer une demande de modification de quota. Cette demande sera traitée automatiquement ou génèrera un ticket de support chez Microsoft.

Ouvrez ensuite Azure Cloud Shell via le bouton situé dans la barre en haut de votre portail Azure :

Si l’ouverture d’Azure Cloud Shell est une première sur votre environnement Azure, il vous sera demandé de créer un compte de stockage comme le montre l’exemple ci-dessous :

Une fois Azure Cloud Shell ouvert en PowerShell, exécuter la commande suivante afin de recréer le référentiel Azure Arc Jumpstart sur votre compte de stockage :

git clone https://github.com/microsoft/azure_arc.git

Vérifiez la version installée d’Azure CLI avec la commande ci-dessous. Celle-ci doit être supérieure ou égale à la version 2.56.0 :

az --version

Dans le cas où plusieurs souscriptions Azure sont en place sur votre tenant, utilisez la commande suivante afin d’identifier la souscription actuellement sélectionnée :

az account list --query "[?isDefault]"

Utilisez la commande suivante et disponible ici pour changer au besoin la souscription :

az account set

Utilisez la commande suivante afin de vérifier le bon changement de sélection :

az account list --query "[?isDefault]"

Utilisez la commande suivante afin de vérifier que les quotas liés à la région Azure et à la famille de VMs soient suffisants :

az vm list-usage --location westeurope --output table

Créez un principal de service Azure (SP) disposant d’un contrôle d’accès (RBAC) de propriétaire sur la souscription Azure, prenez soin de sauvegarder les 3 valeurs en sortie :

az ad sp create-for-rbac -n "JumpstartHCIBox" --role "Owner" --scopes /subscriptions/$subscriptionId

Vérifiez cette création depuis la page des droits RBAC de votre souscription Azure :

Profitez-en pour Enregistrer le fournisseur de ressources suivant sur votre souscription Azure :

Le statut du fournisseur de ressources change durant cette phase :

Environ 30 secondes plus tard, le statut du fournisseur de ressources change encore une fois :

De retour sur Azure Cloud Shell, mettez à jour la dernière version de Bicep

az bicep upgrade

Récupérez l’identifiant d’objet du fournisseur de ressources Azure Stack HCI de votre tenant :

az ad sp list --display-name "Microsoft.AzureStackHCI Resource Provider"

Votre environnement est maintenant configuré pour commencer le déploiement des ressources Azure de votre HCIBox.

Etape II – Déploiement des ressources Azure :

Pour cela, récupérez le template au format JSON disponible à cette adresse afin de modifier les informations suivantes :

  • spnClientId : Votre identifiant de principal de service Azure
  • spnClientSecret : Votre secret de principal de service Azure
  • spnTenantId : Votre identifiant de tenant Azure
  • spnProviderId : Votre identifiant de fournisseur de ressources Azure Stack HCI
  • WindowsAdminUsername : Nom d’utilisateur de l’administrateur
  • windowsAdminPassword : Mot de passe de l’administrateur
  • logAnalyticsWorkspaceName : Nom unique pour l’espace de travail HCIBox Log Analytics
  • deployBastion : Option pour déployer ou non Azure Bastion

Téléversez le fichier template au format JSON modifié sur Azure :

Déplacez le fichier template dans le dossier Bicep :

mv ./main.parameters.json ./azure_arc/azure_jumpstart_hcibox/bicep/

Positionnez-vous également dans ce même dossier :

cd ./azure_arc/azure_jumpstart_hcibox/bicep/

Lancez la commande suivante afin de créer un groupe de ressources dans la région Azure de votre choix :

az group create --name "jlohci"  --location "westeurope"

Lancez la commande suivante afin de déployer les ressources Azure de votre HCIBox :

az deployment group create -g "jlohci" -f "main.bicep" -p "main.parameters.json"

Suivez le déploiement des ressources Azure depuis le nouveau groupe de ressources créé :

Environ 30 minutes plus tard, les ressources Azure de votre HCIBox sont enfin déployées :

Les ressources Azure servant à votre HCIBox sont maintenant en place :

L’étape suivante va consister à déployer différents serveurs nécessaires à votre Cluster Azure Stack HCI. Pour cela, nous utiliserons un script PowerShell déjà préparé.

Etape III – Déploiement des nœuds connectés via Azure Arc :

Pour lancer ce script, nous devrons ouvrir une session RDP sur la machine virtuelle hôte. Pour cela recherchez la machine virtuelle suivante, puis cliquez sur celle-ci :

Démarrez une session RDP via le service Azure Bastion en utilisant les identifiants renseignés dans le template JSON :

Une fois que vous vous êtes connecté en RDP, le script PowerShell s’ouvre automatiquement :

Ce script prendra au total entre 1 et 2 heures avec 10 différentes étapes.

Téléchargement des fichiers VHDX de l’OS Azure Stack HCI :

Configuration de la virtualisation :

Création de la VM de management sous Hyper-V :

Création des 2 VMs représentants les 2 nœuds Azure Stack HCI :

Démarrage des 3 machines virtuelles :

Configurations réseaux et stockages :

A l’intérieur même de la machine virtuelle de management, déploiement d’une autre VM dédiée au réseau :

Finalisation du déploiement de l’infrastructure Azure Stack HCI dont l’enrôlement de nos 2 serveurs sur Azure via Azure Arc:

Comme indiqué plus haut, le script PowerShell se ferme automatiquement à la fin :

Si le script vous affiche une ou plusieurs erreurs, différents journaux d’évènements sont disponibles dans le dossier suivant :

C:\HCIBox\Logs\

Il existe également une page officielle de Troubleshoot juste ici :

Log fileDescription
C:\HCIBox\Logs\Bootstrap.logOutput from the initial bootstrapping script that runs on HCIBox-Client.
C:\HCIBox\Logs\New-HCIBoxCluster.logOutput of New-HCIBoxCluster.ps1 which configures the Hyper-V host and builds the HCI cluster, management VMs, and other configurations.
C:\HCIBox\Logs\Generate-ARM-Template.logLog output of the script that builds the hci.json and hci.parameters.json file
C:\HCIBox\Logs\HCIBoxLogonScript.logLog output from the orchestrator script that manages the install
C:\HCIBox\Logs\Tools.logLog output from tools installation during bootstrap

Afin de bien vérifier la connexion à Azure, recherchez le service Azure Arc via la barre du portail Azure :

Vérifiez que les deux nœuds HCI sont présents dans Azure Arc :

Vérifiez que les deux nœuds ont correctement installé avec succès les trois extensions suivantes :

  • TelemetryAndDiagnostics
  • AzureEdgeLifecycleManager
  • AzureEdgeDeviceManagement

Vérifiez également sur le second nœud la présence de ces 3 extensions :

Enfin comme le montre l’image ci-dessous, votre Cluster Azure Stack HCI n’est pas encore déployé :

Azure Stack HCI utilise un processus en 2 étapes pour valider et déployer des clusters Azure Stack HCI dans Azure à l’aide d’un modèle ARM.

Etape IV – Déploiement du cluster Azure Stack HCI :

Avant cela, commencez par ajouter à votre compte Entra ID les 2 rôles Entra ID suivants :

  • Administrateur Key Vault
  • Contributeur au compte de stockage

Retournez sur la session RDP ouverte via Azure Bastion, ouvrez l’explorateur de fichiers, faites un clic droit sur le dossier HCIBox, puis ouvrez-le dans VSCode :

Cliquez-ici pour continuer :

Vérifiez que le fichier hci.parameters.json est correct et sans valeurs de paramètre -staging :

Toujours sur la machine virtuelle hôte, ouvrez le portail Azure avec votre identifiant Entra ID, puis rechercher le service suivant :

Sélectionnez Construire votre propre modèle dans l’éditeur :

Collez le contenu du fichier hci.json dans l’éditeur, puis cliquez sur Enregistrer :

Cliquez sur Editer les paramètres :

Collez le contenu de hci.parameters.json dans l’éditeur, puis cliquez sur Enregistrer :

Renseignez votre groupe de ressources, puis lancez la validation Azure :

Une fois la validation Azure réussie, exécutez le template ARM :

Attendez que ce dernier soit terminé :

Environ 15 minutes plus tard, cliquez-ici pour ouvrir à nouveau votre groupe de ressources :

Cliquez sur la nouvelle ressource Azure représentant votre cluster Azure Stack HCI :

Un bandeau vous indique que la validation est réussie mais que le déploiement n’est pas encore effectué. Cliquez-ici pour le lancer :

La mise en place du template ARM vous amène directement sur l’onglet suivant, lancez la validation Azure :

Une fois la validation Azure réussie, lancez le déploiement des ressources, puis attendez :

Suivez l’avancement du déploiement du cluster Azure Stack HCI via le menu suivant :

Environ 2 heures plus tard, cette même page vous indique la fin du déploiement du cluster Azure Stack HCI :

Retournez sur la page principale de votre cluster Azure Stack HCI afin de lancer au besoin les mises à jour disponibles (2402) :

Lancez la mise à jour 2402 comme ceci :

Cliquez sur Suivant :

Cliquez sur Suivant :

Lancez l’installation de la mise à jour :

Suivez l’avancement de la mise à jour de votre cluster via le menu suivant :

Environ 2 heures plus tard, cette même page doit vous indiquer la fin de la mise à jour sur de votre cluster Azure Stack HCI :

Votre cluster Azure Stack HCI est enfin installé et à jour. Nous allons maintenant pouvoir nous intéresser à son contenu, à savoir :

  • les images OS
  • les réseaux logiques

Etape V – Images OS et réseaux logiques d’Azure Stack HCI :

Avant de pouvoir créer des machines virtuelles sur votre cluster HCI à partir du portail Azure, vous devez créer des images de VM qui peuvent être utilisées comme base. Ces images peuvent être importées de la place de marché Azure ou fournies directement par l’utilisateur.

Azure Arc Jumpstart

Cliquez-ici pour importer une image à partir de la Marketplace d’Azure :

Dans mon exemple, j’importe les deux images OS suivantes :

  • Windows 11 Enterprise multisession + Microsoft 365 Apps, version 23H2
  • Windows Server 2022 Datacenter: Azure Edition

La première étape consiste à télécharger sur votre cluster les deux images OS :

Environ 2 heures plus tard, le téléchargement des 2 images est terminé :

Comme nous le rappelle Azure Arc Jumpstart, Le réseau de la HCIBox comprend un sous-réseau 192.168.200.0/24 étiqueté VLAN200 :

Network details
Subnet192.168.200.0/24
Gateway192.168.200.1
VLAN Id200
DNS Server192.168.1.254

Ce réseau est conçu pour être utilisé avec les VMs Arc sur HCIBox. Pour utiliser ce réseau préconfiguré, vous devez créer une ressource réseau logique qui correspond à ce sous-réseau.

Depuis la VM hôte ouverte en RDP, ouvrez le script PowerShell suivant afin de créer le réseau logique sur votre cluster Azure Stack HCI :

Une fois le script correctement exécuté, le réseau logique est visible sur le portail Azure juste ici :

Les information de sous-réseau, de passerelle et de serveur DNS sont bien reprises :

Tous les éléments de configuration sont maintenant en place pour commencer la création de machines virtuelles dans votre cluster Azure Stack HCI.

Avant de déployer un environnement Azure Virtual Desktop, je vous propose de créer une machine virtuelle fonctionnant sous Windows Server 2022.

Etape VI – Déploiement d’une machine virtuelle Windows Server 2022 :

Depuis la page de votre cluster Azure Stack HCI, cliquez-ici pour créer votre première machine virtuelle :

Choisissez un groupe de ressources, donnez un nom à votre VM, puis sélectionnez Standard pour le type de sécurité :

Sélectionnez l’image Windows Server que vous avez téléchargée précédemment, puis définissez sa taille et sa mémoire :

Cochez la case suivant, puis définissez un compte administrateur local :

Joignez la VM au domaine AD créé pour votre Azure Stack HCI, puis cliquez sur Suivant :

Inutile d’ajouter d’autres disques de données, cliquez sur Suivant :

Cliquez-ici pour ajouter une carte réseau :

Nommez la carte réseau, sélectionnez le réseau logique créé précédemment, choisissez la méthode d’allocation sur Automatique, puis cliquez sur Ajouter :

Cliquez sur Suivant :

Ajoutez au besoin des tags, puis cliquez sur Suivant :

Cliquez sur Créer :

Comme pour une ressource Azure classique, vous pouvez suivre toutes les étapes du déploiement :

Environ 20 minutes plus tard, cliquez-ici pour apercevoir les propriétés de votre VM :

Copiez l’adresse IP privée de votre nouvelle VM :

Depuis la session ouverte via Azure Bastion, ouvrez une session Hyper-V sur la machine virtuelle de management :

Utilisez le compte suivant :

Ouvrez une session RDP via l’adresse IP privée de votre nouvelle VM tout en utilisant un compte de domaine :

Constatez la bonne ouverture de session sur votre machine virtuelle Windows Server 2022 :

Le test d’une machine virtuelle individuelle fonctionne bien. Il ne nous reste plus qu’à tester le déploiement d’un environnement Azure Virtual Desktop sur votre cluster Azure Stack HCI.

Etape VII – Déploiement d’Azure Virtual Desktop :

Avant de pouvoir déployer votre environnement Azure Virtual Desktop. Il est conseillé de synchroniser les identités Active Directory avec Entra ID.

Pour cela, ouvrez une session Hyper-V à votre contrôleur de domaine de démonstration :

Utilisez le compte de domaine suivant :

Créez une nouvelle OU, des utilisateurs de test et un groupe dédié à Azure Virtual Desktop :

Téléchargez et installez Microsoft Entra Connect via ce lien direct :

Depuis la page des utilisateurs d’Entra ID, vérifiez la bonne synchronisation de vos utilisateurs et votre groupe AVD :

Retournez sur la page de votre cluster Azure Stack HCI, puis cliquez-ici pour déployer votre environnement Azure Virtual Desktop :

Renseignez les informations de base de votre pool d’hôtes Azure Virtual Desktop, puis cliquez sur Suivant :

Ajoutez un ou des VMs Azure Stack HCI à votre AVD en reprenant l’image Windows 11 Enterprise multisession :

Définissez sa taille, sa mémoire et son réseau logique :

Joignez-la au domaine Active Directory, renseignez le compte d’administrateur local, puis cliquez sur Suivant :

Créez un espace de travail AVD, puis lancez la validation Azure :

Une fois la validation Azure réussie, lancez la création des ressources :

Attendez environ 1 heure :

L’image ci-dessous vous montre l’apparition des VMs AVD :

Seulement, et contrairement au déploiement de la première VM sous Windows Server 2022, le management invité n’est pas automatiquement installée sur les VMs AVD :

Afin d’éviter un échec de votre déploiement AVD, actualiser la page de votre machine virtuelle AVD régulièrement afin d’activer le management invité dès que cela est possible :

Attendez environ 2 minutes le temps de la préparation :

Copiez le script suivant pour sa mise en place :

Récupérez l’adresse IP privée de votre VM AVD :

Depuis la VM de management, ouvrez une session RDP avec le compte administrateur local :

Collez le script sur la VM AVD :

Sur le portail Azure, activez le management invité de votre VM dès que cela est possible :

Suivez l’activation du management invité par le menu suivant :

Rafraichissez la page plusieurs fois si nécessaire :

Environ 30 minutes plus tard, le déploiement de votre AVD doit se terminer :

Consultez votre pool d’hôtes AVD depuis le portail Azure :

Vérifiez également la bonne apparition de vos VMs AVD dans votre Active Directory :

Ajoutez votre groupe Entra ID synchronisé à votre AVD en tant qu’utilisateurs AVD :

Démarrez votre client Remote Desktop, puis ouvrez une session AVD sur un utilisateur de test :

Renseignez à nouveau le mot de passe de votre utilisateur :

Attendez quelques secondes l’ouverture de votre session Azure Virtual Desktop :

Conclusion

Grâce à la HCIBox, nous avons rapidement et facilement pu se rendre compte de l’écosystème hybride proposé par Microsoft pour une de leurs solutions phares : Azure Virtual Desktop.

Important : Attention tout de même à ne pas trop dépenser de crédits pour votre HCIBox. pensez à supprimer ou éteindre vos ressources une fois vos tests terminés :

Ce rappel des coûts de la HCIBox m’amène à une autre question :

Est-il rentable de faire fonctionner Azure Virtual Desktop sur Azure Stack HCI quand d’autres solutions on-premise existent également ?

Les avis de la communauté sont partagés, comme l’article écrit par PureRDS :

Plusieurs coûts sont en effet présents pour un Azure Virtual Desktop hébergé sur Azure Stack HCI.

Coûts licences utilisateurs :

Coûts licences infra :

Enfin voici quelques vidéos pour vous faire votre propre opinion 😎 :

Azure Stack HCI est à votre porte !

Le Cloud est présent dans beaucoup d’infrastructures IT. Utilisé à 100% ou seulement de manière partielle pour certains services, il offre une flexibilité inégalée, aussi bien dans son financement que dans les besoins techniques disponibles et les évolutions possibles.

Mais alors, si le cloud est merveilleux, pourquoi les principaux fournisseurs de cloud cherchent aussi à proposer des solutions dites hybrides (on-premise + cloud) ?

Peut-être qu’il en faut pour tous les goûts 😁?

D’abord, faisons un rapides tour de plusieurs concepts avant tester ensemble une solution hybride via un exercice que propose justement Microsoft.

Qu’est-ce que le cloud hybride ?

Le cloud hybride combine généralement deux types de cloud : public et privé. Par privé est souvent entendu local.

Un cloud hybride est un peu comme une voiture hybride. Les voitures hybrides combinent deux technologies totalement distinctes : un moteur qui brûle de l’essence et un autre qui consomme de l’énergie électrique. Chaque technologie fonctionne de manière totalement différente, et chacune a ses avantages et ses inconvénients. Cependant, lorsque les deux sont combinées efficacement, le résultat est une voiture plus performante que la plupart des voitures uniquement à essence et pourtant plus puissante que la plupart des voitures entièrement électriques. De même, les cloud hybrides combinent les avantages de plusieurs types d’environnements cloud pour une efficacité et une fonctionnalité accrue.

Oracle

Qu’est-ce qu’Azure Stack HCI ?

Azure Stack HCI est une solution développée par Microsoft pour justement aider les entreprises à exploiter les avantages d’un environnement hybride, expliqué précédemment, via les interfaces connues d’Azure et de Windows Admin Center.

Il s’agit d’une solution d’infrastructure hyperconvergée basée sur les technologies Azure de Microsoft. Elle permet de :

  • d’intégrer de façon transparente leur environnement
  • De créer une expérience hybride cohérente à Azure.
  • D’apporter toujours plus de scalabilité et flexibilité.
  • De conserver un haut niveau de sécurité et de conformité.
  • De profiter d’une passerelle de modernisation de l’infrastructure existante.

Existe-t-il du matériel certifié Azure Stack HCI ?

Microsoft met à disposition un site web dédié à Azure Stack HCI dont voici le lien. Vous pourrez y planifier votre solution en fonction des charges de travail prévues :

Peut-on tester Azure Stack HCI sans forcément acheter du matériel ?

Cela est possible, grâce à … Azure ! En effet, les fournisseurs de cloud autorisent pratiquement toutes les créations de ressources, donc on peut simuler un Azure Stack HCI dans le cloud de Microsoft.

Cette approche permet donc de ne pas dépenser de grandes sommes d’argent pour tester la solution Azure Stack HCI avant de se laisser convaincre. Pour cela je vous laisse lire les différentes étapes ci-dessous pour y parvenir :

La version originale de l’exercice conçu par Microsoft est également disponible en anglais sur leur page GitHub juste ici.

Rappel des prérequis :

Pour réaliser cet exercice sur Azure Stack HCI, il vous faudra disposer de :

  • Un tenant Microsoft
  • Une souscription Azure valide

Afin de tester Azure Stack HCI, nous allons avoir besoin créer un environnement virtuel, dans lequel nous allons simuler la présence de nœuds HCI, mais aussi de Windows Admin Center.

Dans Azure, il est en effet possible d’imbriquer de la virtualisation. Cela demande malgré tout quelques exigences, comme le SKU de la machine virtuelle Hyper-V, mais aussi sa génération.

Important : Attention à ne pas laisser tourner l’environnement de démonstration Azure Stack HCI tourner un peu trop longtemps. Beaucoup de ressources Azure sont créées et le compteur des € défile assez vite 🤑.

Etape I – Déploiement de l’environnement virtuel sur Azure :

Commencez par cliquez sur le lien ci-dessous afin déployer les ressources nécessaires sur votre souscription Azure :

Renseignez les champs suivants, puis lancez la validation Azure :

Une fois la validation Azure réussie, cliquez-ici pour commencer la création :

Le déploiement dure environ 30 minutes, attendez que celui-ci se termine, puis cliquez-ici :

Constatez la présence de nombreuses ressources Azure créées pour cette démonstration, puis cliquez sur la machine virtuelle présente, appelée AzSHCIHost001 :

Rendez-vous dans le menu Bastion, puis cliquez-ici pour en déployer un :

Attendez environ 5 minutes que la création d’Azure Bastion se termine :

Modifier la règle NSG suivante créée dans le template Microsoft afin de débloquer l’accès RDP à votre machine Hyper-V :

Retournez sur votre machine virtuelle Hyper-V, puis lancez une session Bastion avec les identifiants renseignés lors de la création du template :

Sur la session RDP ouverte via Azure Bastion, cliquez-ici pour modifier le script de déploiement d’Azure Stack HCI :

Rendez-vous sur la ligne suivante pour modifier la ligne comme ceci :

AVANT :

Set-ExecutionPolicy Bypass -Scope Process -Force; iex ((New-Object System.Net.WebClient).DownloadString('https://chocolatey.org/install.ps1'))

APRES :

Set-ExecutionPolicy Bypass -Scope Process -Force; Invoke-WebRequest -Uri 'https://chocolatey.org/install.ps1' -OutFile 'install.ps1'; .\install.ps1 -ChocolateyDownloadUrl "https://community.chocolatey.org/api/v2/package/chocolatey/1.4.0"

Vous avez aussi la possibilité de récupérer celui-ci en version corrigée sur mon GitHub

Lancez le script, puis faites preuve d’un petit peu de patience, car celui dure environ … 2 heures 🤣

Si aucune erreur ne s’est manifestée durant le traitement, vous devriez apercevoir le message de succès suivant :

Si le script ne s’est pas correctement terminé, la commande PowerShell suivante permet d’effacer les ressources crées dans Hyper-V afin de pouvoir recommencer le lancement du script :

.\New-AzSHCISandbox.ps1 -Delete $true

Un tour rapide dans la console Hyper-V montre l’apparition de 3 machines virtuelles :

  • AzSHOST1 : nœud Azure Stack HCI 1
  • AzSHOST2 : nœud Azure Stack HCI 2
  • AzSMGMT : Console de management pour Windows Admin Center

Sur le bureau de votre machine virtuelle Hyper-V, une icône de type RDP vient de faire son apparition :

Notre environnement fictif de départ est maintenant terminé. Nous avons besoin d’enregistrer notre cluster Azure Stack HCI sur le portail Azure afin de commencer la facturation mais aussi tester le déploiement de services depuis le portail Azure.

Etape II – Enregistrement du Cluster Azure Stack HCI sur Azure :

Pour cela, cliquez sur l’icône RDP pour ouvrir une session sur la VM WAC puis renseignez les identifiants suivants (mot de passe : Password01) :

Notez la présence d’un domaine Active Directory nommé Contoso. Attendez quelques minutes que la session se charge entièrement :

Sur le bureau, ouvrez le raccourci menant à la page suivante et ayant un icône Google Chrome :

https://admincenter.contoso.com/

Renseignez les identifiants suivants (mot de passe : Password01) :

Attendez quelques secondes que se charge la console de Windows Admin Center :

Fermez la fenêtre de notification de Windows Admin Center :

Attendez environ 10 minutes que tous les modules présents dans Windows Admin Center soient bien mis à jour :

Une fois les mises à jour effectuées, les notifications suivantes devraient apparaître dans WAC :

Afin de pouvoir piloter votre Cluster de serveurs Azure Stack HCI, il est nécessaire de le rajouter dans la console WAC pour terminer la configuration.

Cliquez-ici pour ajouter votre cluster Azure Stack HCI à WAC :

Saisissez le nom AzStackCluster, attendez quelques secondes que WAC retrouve ce dernier, puis cliquez sur Ajouter :

Une fois l’ajout réussi, vérifiez la liste des connexions existantes avec WAC, puis cliquez sur votre cluster de serveurs :

Rendez-vous dans le menu appelé SDN Infrastructure :

Renseignez les identifiants suivants (mot de passe : Password01), puis cochez la case suivante :

Renseignez le contrôleur de réseau suivant, puis cliquez sur Continuer :

Constatez l’apparition des nouveaux menus suivants sous la section Réseau :

Afin de pouvoir utiliser pleinement le portail Azure pour piloter notre cluster Azure Stack HCI, il est nécessaire de passer par quelques étapes d’enregistrement.

Pour cela, rendez-vous toujours depuis WAC dans la section Azure Arc, puis cliquez sur le bouton suivant :

Cliquez-ici pour démarrer l’enregistrement de notre cluster sur Azure :

Utilisez le code Azure pour valider l’authentification Azure AD avec un compte disposant de suffisamment de droits sur la souscription Azure :

Une fois l’authentification Azure AD réussie, vous devriez recevoir l’information suivante, puis cliquez sur Authentifier :

Acceptez la demande de permission de Windows Admin Center avec le consentement global de l’organisation :

Vérifiez la disparition du message sur la page Azure Arc de votre WAC :

Avant d’aller plus loin, retournez sur votre portail Azure afin d’activer le fournisseur de ressources suivant sur votre souscription Azure :

Attendez environ deux minutes que le statut soit correctement changé sur le fournisseur de ressources :

Retournez sur Windows Admin Center, puis cliquez-ici :

Cliquez-ici pour démarrer le processus avec la connexion Azure Arc précédemment créée :

Renseignez les informations qui vous conviennent, puis cliquez sur Enregistrer :

La notification suivante devrait alors apparaître dans WAC :

Attendez environ 5 minutes pour confirmer le bon enregistrement :

Retournez sur le portail Azure afin de constater la présence de votre Azure Stack HCI, puis cliquez dessus :

Naviguez dans les différents menus pour mieux comprendre les informations remontées sur Azure.

Nous allons avoir maintenant besoin d’un autre composant, appelé Azure Resource Bridge. Si l’on souhaite gérer et déployer des ressources sur son cluster depuis Azure, celui-ci est indispensable.

Etape III – Configuration d’Azure Ressource Bridge :

Le pont de ressources Arc est une machine virtuelle empaquetée qui héberge un cluster Kubernetes de gestion nécessitant une gestion minimale des utilisateurs. La machine virtuelle est déployée sur l’infrastructure locale et une ressource ARM du pont de ressources Arc est créée dans Azure. Les deux ressources sont ensuite connectées, ce qui permet la gestion et l’utilisation en libre-service des machines virtuelles à partir d’Azure

Microsoft Learn

Ensuite, cliquez ici pour installer un second module, appelé Azure Resource Bridge :

Attention : certaines étapes sont à faire sur les 2 nœuds présents dans votre cluster Azure Stack HCI

Cliquez sur le lien suivant pour ouvrir le guide d’installation d’Arc Resource Bridge :

Retournez sur votre serveur Hyper-V, puis dans la console Hyper-V, cliquez sur le premier nœud de votre cluster Azure Stack HCI afin d’ouvrir une session :

Renseignez les identifiants suivants (mot de passe : Password01) :

Effectuez le choix 15 pour ouvrir une console PowerShell :

Profitez-en pour ouvrir Notepad depuis PowerShell afin de faciliter les copier / coller :

Saisissez la commande suivante pour installer les premiers modules nécessaires :

Install-PackageProvider -Name NuGet -Force 
Install-Module -Name PowershellGet -Force -Confirm:$false -SkipPublisherCheck

Continuez avec celles-ci pour installer d’autres modules :

Install-Module -Name Moc -Repository PSGallery -AcceptLicense -Force
Initialize-MocNode
Install-Module -Name ArcHci -Force -Confirm:$false -SkipPublisherCheck -AcceptLicense

Fermez la fenêtre PowerShell afin de revenir au menu principal, puis entrez le choix 13 pour redémarrer votre premier nœud :

Retournez sur votre serveur Hyper-V, puis dans la console Hyper-V, cliquez sur le second nœud de votre cluster Azure Stack HCI afin d’ouvrir une session :

Renseignez les identifiants suivants (mot de passe : Password01) :

Effectuez le choix 15 pour ouvrir une console PowerShell :

Profitez-en pour également ouvrir Notepad depuis PowerShell afin de faciliter les copier / coller :

Saisissez la commande suivante pour installer les même premiers modules nécessaires :

Install-PackageProvider -Name NuGet -Force 
Install-Module -Name PowershellGet -Force -Confirm:$false -SkipPublisherCheck

Continuez avec celles-ci pour installer les mêmes autres modules :

Install-Module -Name Moc -Repository PSGallery -AcceptLicense -Force
Initialize-MocNode
Install-Module -Name ArcHci -Force -Confirm:$false -SkipPublisherCheck -AcceptLicense

Fermez la fenêtre PowerShell afin de revenir au menu principal, puis entrez le choix 13 pour redémarrer votre second nœud :

Retournez sur votre serveur Hyper-V, puis dans la console Hyper-V, cliquez à nouveau sur le premier nœud de votre cluster Azure Stack HCI afin d’ouvrir une session :

Renseignez à nouveau les identifiants suivants (mot de passe : Password01) :

Effectuez à nouveau le choix 15 pour rouvrir une console PowerShell :

Saisissez la commande suivante pour installer le module CLI d’Azure, uniquement nécessaire sur le premier nœud :

$ProgressPreference = 'SilentlyContinue'; Invoke-WebRequest -Uri https://aka.ms/installazurecliwindows -OutFile .\AzureCLI.msi; Start-Process msiexec.exe -Wait -ArgumentList '/I AzureCLI.msi /quiet'; Remove-Item .\AzureCLI.msi

Fermez la fenêtre PowerShell afin de revenir au menu principal, puis entrez le choix 13 pour redémarrer à nouveau votre premier nœud :

Retournez sur votre serveur Hyper-V, puis dans la console Hyper-V, cliquez à nouveau sur le premier nœud de votre cluster Azure Stack HCI afin d’ouvrir une session :

Renseignez à nouveau les identifiants suivants (mot de passe : Password01) :

Effectuez à nouveau le choix 15 pour rouvrir une console PowerShell :

Rouvrez à nouveau Notepad depuis PowerShell afin de faciliter les copier / coller.

Préparer les variables suivantes puis lancez-les :

$VswitchName="sdnSwitch"
$ControlPlaneIP="192.168.1.200"
$csv_path="C:\ClusterStorage\S2D_vDISK1\"
$VMIP_1="192.168.1.201"   
$VMIP_2="192.168.1.202"
$DNSServers="192.168.1.254"
$IPAddressPrefix="192.168.1.0/24"
$Gateway="192.168.1.1"
$CloudServiceIP="192.168.1.203"

Lancez le script suivant pour préparer la configuration d’Azure Resource Bridge :

mkdir $csv_path\ResourceBridge

Set-MocConfig -workingDir $csv_path\ResourceBridge -imageDir $csv_path\imageStore -skipHostLimitChecks -cloudConfigLocation $csv_path\cloudStore -catalog aks-hci-stable-catalogs-ext -ring stable -CloudServiceIP $cloudServiceIP -createAutoConfigContainers $false

Install-Moc

Retirer les extensions du module PowerShell Az si jamais elles existaient déjà :

az extension remove --name arcappliance
az extension remove --name k8s-extension
az extension remove --name customlocation
az extension remove --name azurestackhci

Installer à nouveaux ces mêmes extensions Az :

az extension add --upgrade --name arcappliance
az extension add --upgrade --name k8s-extension
az extension add --upgrade --name customlocation
az extension add --upgrade --name azurestackhci

Renseignez les informations sur votre environnement Azure :

$subscription="d9b60b07-0ae9-4de3-bfdd-062268de474a"
$resource_group="azurestack-rg"
$location="westeurope"

Continuez avec le script suivant :

az login --use-device-code
az account set --subscription $subscription
az provider register --namespace Microsoft.Kubernetes --wait
az provider register --namespace Microsoft.KubernetesConfiguration --wait
az provider register --namespace Microsoft.ExtendedLocation --wait
az provider register --namespace Microsoft.ResourceConnector --wait
az provider register --namespace Microsoft.AzureStackHCI --wait
az provider register --namespace Microsoft.HybridConnectivity --wait
$hciClusterId= (Get-AzureStackHci).AzureResourceUri
$resource_name= ((Get-AzureStackHci).AzureResourceName) + "-arcbridge"
$customloc_name= ((Get-AzureStackHci).AzureResourceName) + "-CL"

Saisissez le code Azure donnée dans le log des commandes Power Shell :

Utilisez un compte disposant de suffisamment de droits sur la souscription Azure :

Lancez le script suivant pour commencer la configuration K8s :

New-ArcHciConfigFiles -subscriptionID $subscription -location $location -resourceGroup $resource_group -resourceName $resource_name -workDirectory $csv_path\ResourceBridge -controlPlaneIP $controlPlaneIP -vipPoolStart $controlPlaneIP -vipPoolEnd $controlPlaneIP -k8snodeippoolstart $VMIP_1 -k8snodeippoolend $VMIP_2 -gateway $Gateway -dnsservers $DNSServers -ipaddressprefix $IPAddressPrefix -vswitchName $vswitchName

Continuez avec le fichier YAML pour la configuration K8s :

az arcappliance validate hci --config-file $csv_path\ResourceBridge\hci-appliance.yaml

Préparez votre environnement K8s avec la préparation au déploiement de pods :

az arcappliance prepare hci --config-file $csv_path\ResourceBridge\hci-appliance.yaml

Déployez le contenaire K8s dédié à la communication du module Azure Arc Bridge :

az arcappliance deploy hci --config-file  $csv_path\ResourceBridge\hci-appliance.yaml --outfile "$csv_path\ResourceBridge\kubeconfig"

Continuez avec le script suivant :

az arcappliance create hci --config-file $csv_path\ResourceBridge\hci-appliance.yaml --kubeconfig "$csv_path\ResourceBridge\kubeconfig"

Vérifiez que les deux statuts soient bien sur Succeded et Connected, retentez quelques minutes plus tard si nécessaire :

az arcappliance show --resource-group $resource_group --name $resource_name --query '[provisioningState, status]'

Continuez avec le script suivant :

az k8s-extension create --cluster-type appliances --cluster-name $resource_name --resource-group $resource_group --name hci-vmoperator --extension-type Microsoft.AZStackHCI.Operator --scope cluster --release-namespace helm-operator2 --configuration-settings Microsoft.CustomLocation.ServiceAccount=hci-vmoperator --config-protected-file $csv_path\ResourceBridge\hci-config.json --configuration-settings HCIClusterID=$hciClusterId --auto-upgrade true

Vérifiez que le statut soit bien sur Succeded, retentez quelques minutes plus tard si nécessaire :

az k8s-extension show --cluster-type appliances --cluster-name $resource_name --resource-group $resource_group --name hci-vmoperator --out table --query '[provisioningState]'

Terminez par la commande de création d’un emplacement personnalisé sur Azure. Ce dernier va nous être utile pour indiquer lors de la création de ressources depuis le portail Azure que celle-ci doit-être créée sur Azure Stack HCI :

az customlocation create --resource-group $resource_group --name paris --cluster-extension-ids "/subscriptions/$subscription/resourceGroups/$resource_group/providers/Microsoft.ResourceConnector/appliances/$resource_name/providers/Microsoft.KubernetesConfiguration/extensions/hci-vmoperator" --namespace hci-vmoperator --host-resource-id "/subscriptions/$subscription/resourceGroups/$resource_group/providers/Microsoft.ResourceConnector/appliances/$resource_name" --location $location

Constatez la bonne création de ce dernier depuis le portail Azure :

Retournez sur la page Azure de votre cluster Azure Stack HCI afin de constater l’avancement des prérequis :

Azure Resource Bridge est maintenant correctement installé. Nous allons enfin pouvoir créer notre machine virtuelle depuis le portail Azure, et déployée directement sur un des 2 nœuds de notre cluster.

Etape IV – Création de la VM sur le Stack :

Cliquez comme ceci pour transférer vers votre cluster une image de VM provenant de la marketplace Microsoft d’Azure :

Renseignez les champs comme ceci, puis lancez la validation :

Une fois la validation réussie, cliquez-ici pour commencer le transfert de données de l’image de Windows Server vers votre cluster :

Ce processus est assez long, comptez environ une bonne heure avant que le transfert de l’image ne se termine :

En cas d’erreur lors du transfert, relancez celui-ci afin d’avoir une image complète sur votre cluster :

De retour sur votre premier nœud de votre cluster Azure Stack HCI, lancez la commande suivante pour initialiser le réseau virtuel :

$vnetName="vnetwork-paris3"
New-MocGroup -name "Default_Group" -location "MocLocation"
New-MocVirtualNetwork -name "$vnetName" -group "Default_Group" -tags @{'VSwitch-Name' = "$vswitchName"} 
az azurestackhci virtualnetwork create --subscription $subscription --resource-group $resource_group --extended-location name="/subscriptions/$subscription/resourceGroups/$resource_group/providers/Microsoft.ExtendedLocation/customLocations/paris" type="CustomLocation" --location $Location --network-type "Transparent" --name $vnetName 

Retournez sur le portail Azure afin de constater sa bonne création :

Cliquez ensuite ici pour créer votre première VM sur votre Stack HCI :

Renseignez les informations de base :

Définissez sa taille et son identifiant local, puis cliquez sur Suivant :

Ajoutez si besoin des disques de données, puis cliquez sur Suivant :

Ajoutez une carte réseau :

Utilisez le réseau virtuel créé précédemment :

Cliquez-ici pour lancer la validation :

Une fois la validation Azure réussie, cliquez sur Créer :

Le déploiement des ressources est en cours sur votre cluster, comptez environ 30 minutes pour que celui-ci se termine :

Au bout de quelques minutes Il est aussi possible de suivre la création de la VM depuis la console WAC :

Une fois la création de la machine virtuelle terminée, cliquez-ici pour y accéder :

Prenez le temps de vérifier la configuration de celle-ci :

Retournez sur la console WAC afin d’initialiser une connection directe :

Renseignez les identifiant votre compte admin chez Contoso (mot de passe : Password01) :

Cliquez-ici pour déverrouiller la session distante :

Renseignez les identifiants indiqués lors de la création de la VM depuis le portail Azure :

Vous voilà connecté sur votre VM hébergée sur un stack HCI virtuel, hosté sur un serveur Hyper-V, lui-même hosté sur Azure 😁😎💪 :

Conclusion

Après quelques jours de tests, l’intégration des outils Azure et WAC pour piloter le Cluster un véritable tour de force de Microsoft ! Nul doute que certains projets ou infrastructures ne peuvent être hébergées sur le Cloud pour un grand nombre de raisons. C’est pour cela que Microsoft et les autres fournisseurs de Cloud se doivent de proposer des solutions « à mi-chemin ».

Il faudra enfin voir ce que ça donne dans la version publique généralisée car encore beaucoup de scripts à faire dont beaucoup encore en préversion.