Étiquette : Vm

Jouez avec des conteneurs Azure

Continuons à nous intéresser à un autre service disponible sur Azure : le conteneur, aussi appelé virtualisation en micro-service. La conteneurisation est une méthode populaire pour le déploiement et la mise à l’échelle des applications depuis déjà plusieurs années. Peu importe l’hébergeur de Cloud public choisi, le conteneur reste un modèle très plébiscité par son fonctionnement, ses coûts et sa rapidité de mise en œuvre.

Avant de partir dans un exercice sur Azure, je vous propose de parcourir ensemble quelques notions importantes.

Qu’est-ce qu’un conteneur ?

Les conteneurs sont des environnements virtualisés, dont le but est d’exécuter généralement un micro-service. A la différence des machines virtuelles IaaS, les conteneurs sont dépourvus du système d’exploitation, car cette gestion OS est réalisée à un niveau supérieur. Cela rend leur création plus facile et ils sont beaucoup plus légers.

Un orchestrateur de conteneurs est utile pour gérer les conteneurs, mais également aussi pour manager les ressources exécutants ces conteneurs.

Conteneur ou machines virtuelles ?

Les machines virtuelles s’exécutent dans un hyperviseur (hôte) dans lequel chacune d’entre elles doit inclure son propre système d’exploitation invité (guest). En revanche, chaque conteneur partage le même système d’exploitation hôte ou noyau système. Donc l’un s’appuie sur l’autre :

Par contre, construire une application dans des conteneurs apportent plusieurs avantages non négligeables :

  • Moins lourd : Les conteneurs requièrent moins de ressources que les environnements de machines virtuelles, car ils n’incluent pas les images du système d’exploitation.
  • Plus rapide : Le démarrage d’un conteneur ne prend donc généralement que quelques secondes, contre plusieurs minutes pour une machine virtuelle.
  • Amélioration de la portabilité : Les applications qui s’exécutent dans des conteneurs peuvent être facilement déployées sur différents types de systèmes d’exploitation et de plateformes matérielles.
  • Efficacité accrue : Les conteneurs permettent de déployer, de corriger ou de faire évoluer les applications beaucoup plus rapidement.
  • Optimisation du développement d’applications : Les conteneurs accélèrent les cycles de développement, de test et de production grâce à la méthodologie agile et DevOps.

ACI vs AKS (K8s) ?

AKS et ACI sont deux plateformes populaires d’orchestration de conteneurs proposées par Microsoft Azure.

  • AKS est un service Kubernetes entièrement géré qui fournit une plateforme d’orchestration de conteneurs hautement disponible, évolutive et sécurisée.
  • ACI est une plateforme de conteneurs sans serveur qui vous permet d’exécuter des conteneurs sans avoir à gérer l’infrastructure sous-jacente.

Nodes vs Pods ?

  • Node : Un nœud correspond à une machine virtuelle. Cependant, vous pourriez créer un nœud à partir de presque n’importe quoi. Considérons un node comme un ensemble de ressources CPU et RAM qui peuvent être utilisées.
  • Pods : Kubernetes n’exécute pas les conteneurs directement ; ces derniers sont contenus dans une structure intermédiaire appelée Pod. Tous les conteneurs d’un même pod partagent les mêmes ressources et le même réseau local. Les conteneurs peuvent facilement communiquer avec d’autres conteneurs dans le même pod, comme s’ils étaient sur la même machine, tout en maintenant un certain degré d’isolation par rapport aux autres.

Kubernetes vs. Docker ?

Docker est une plateforme de conteneurisation et un moteur d’exécution, tandis que Kubernetes est une plateforme permettant d’exécuter et de gérer des conteneurs à partir de nombreux moteurs d’exécution de conteneurs. Kubernetes prend en charge de nombreux moteurs d’exécution de conteneurs, y compris Docker.

En résumé, Docker et Kubernetes ne poursuivent pas le même objectif : Docker vous permet de développer, déployer et donc itérer plus vite sur votre produit, tandis que Kubernetes est la solution pour le “runner” en production.

Padok

Afin de vous familiariser les conteneurs disponibles sur Azure sous différentes formes, je vous propose de suivre cet exercice dédié à ACI et AKS. La version originale de l’exercice conçu par Microsoft est également disponible en anglais sur la page GitHub juste ici.

Voici la liste des tâches modifiées que nous allons réaliser :

Comme je le répète régulièrement, une ressource déployée entraîne un début de facturation de la part de Microsoft. Il est donc important de correctement dimensionner les ressources, et de les supprimer quand elles ne sont plus utilisées.

Rappel des prérequis :

Pour réaliser cet exercice sur ASK / ACI, il vous faudra disposer de :

  • Un tenant Microsoft
  • Une souscription Azure valide

Mon environnement Azure de départ ne contient aucune autre ressource, commençons par Azure Container Instances.

Etape I – Test d’Azure Container Instances :

Connectez-vous sur le portail Azure, puis authentifiez-vous :

Commencez par rechercher le service Container instances depuis la barre, en haut de votre portail Azure :

Cliquez-ici pour créer votre service Azure Container Instance :

Remplissez tous les champs comme ceci, puis cliquez sur Suivant :

Dans l’onglet Réseau, nommez votre ACI. Celui-ci doit être valide et unique, puis cliquez sur Suivant :

Lancez la validation Azure :

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

Attendez environ une minute que le processus de création se termine, puis cliquez ici :

Reprenez le FQDN de votre instance ACI :

Ouvrez un nouvel onglet de navigateur, puis collez l’URL correspondante :

Retournez sur votre portail afin de consulter le log de votre instance.

Vérifiez l’entrée représentant la requête HTTP GET générée par l’affichage de l’application dans le navigateur :

Cette première étape très rapide sur ACI est maintenant terminé. Intéressons-nous maintenant à Azure Kubernetes Service (AKS), un orchestrateur managé de conteneurs disponible sur Azure.

Etape II – Enregistrement les fournisseurs de ressources AKS :

Pour cela, ouvrez Azure Cloud Shell depuis la barre bleue en haut de votre portail Azure :

Si besoin, créez un compte de stockage si celui-ci vous le demande :

Saisissez les deux commandes suivantes pour enregistrer les fournisseurs de ressources suivants :

  • Microsoft.Kubernetes
  • Microsoft.KubernetesConfiguration
Register-AzResourceProvider -ProviderNamespace Microsoft.Kubernetes

Register-AzResourceProvider -ProviderNamespace Microsoft.KubernetesConfiguration

Vérifiez l’avancement de l’enregistrement de ces 2 fournisseurs au niveau de votre souscription Azure :

Quelques minutes plus tard, constatez le changement de statut :

Nous environnement est maintenant prêt pour AKS. Nous allons maintenant créer notre premier cluster AKS composé d’un seul worker node.

Etape III – Déploiement d’un cluster Azure Kubernetes Service :

Depuis la barre de recherche, trouvez le service Kubernetes :

Cliquez-ici pour créer votre cluster Kubernetes sur Azure :

Renseignez les champs suivants :

Prenez soin de désactiver la mise à l’échelle automatique, puis cliquez sur Suivant :

Cochez la case suivante pour activer les nœuds virtuels ACI, puis cliquez sur Suivant :

Conservez l’option Kubernetes RBAC, puis cliquez sur Suivant :

Azure CNI est grisé à cause de l’ajout de nœuds virtuels ACI, cliquez sur Suivant :

Décochez la case des alertes, puis lancez la validation Azure :

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

Attendez environ trois minutes que le processus de création se termine :

Constatez la bonne disponibilité du nœud ASK déployé :

Notre environnement AKS est prêt à recevoir des conteneurs. Passons à l’étape suivante pour réaliser cela.

Etape IV – Déploiement des pods dans le cluster AKS :

Ouvrez à nouveau Azure Cloud Shell :

Basculez de PowerShell à Bash, puis confirmez :

Exécutez la procédure suivante pour récupérer les informations d’identification permettant d’accéder au cluster AKS :

RESOURCE_GROUP='az104-09c-rg1'

AKS_CLUSTER='az104-9c-aks1'

az aks get-credentials --resource-group $RESOURCE_GROUP --name $AKS_CLUSTER

Exécutez la commande suivante pour obtenir la liste des nœuds actifs sur AKS :

 kubectl get nodes

Notez la présence d’un nœud virtuel représenté par ACI :

Exécutez la commande suivante afin de déployer l’image nginx depuis le Docker Hub :

 kubectl create deployment nginx-deployment --image=nginx

Exécutez la commande suivante pour obtenir la liste des pods actifs sur AKS :

 kubectl get pods

Exécutez la commande suivante pour obtenir les statuts et le nombre de la conteneurs actifs sur AKS :

 kubectl get deployment

Retrouvez cette même information sur le portail Azure :

Exécutez la commande suivante pour exposer, donc rendre le pod accessible depuis Internet :

 kubectl expose deployment nginx-deployment --port=80 --type=LoadBalancer

Exécutez la commande suivante afin d’obtenir l’adresse IP publique de l’équilibreur de charge dédié à votre application :

 kubectl get service

Retrouvez cette même information sur le portail Azure, puis ouvrez un nouvel onglet de navigateur en collant l’adresse IP correspondante :

Vérifiez que la page du navigateur affiche bien le message suivant :

Afin de comprendre la force des conteneurs, jouons un peu avec le nombre de pods dans l’étape suivante.

Etape V – Variation du nombre de Pods :

Nous allons faire évoluer les charges de travail conteneurisées dans votre cluster Azure Kubernetes.

Exécutez la commande suivante pour mettre à l’échelle le déploiement en augmentant le nombre de pods à 2 :

 kubectl scale --replicas=2 deployment/nginx-deployment

Contrôler la mise à l’échelle du déploiement via la commande suivante :

 kubectl get pods

Retrouvez cette même information sur le portail Azure :

Il est également possible d’augmenter le nombre de worker nodes dans notre environnement AKS. Pour cela, l’étape suivante nous le montre.

Etape VI – Variation du nombre de Nodes :

Exécutez la procédure suivante pour mettre à l’échelle le cluster en augmentant le nombre de nœuds à 2 :

RESOURCE_GROUP='az104-09c-rg1'

AKS_CLUSTER='az104-9c-aks1'

az aks scale --resource-group $RESOURCE_GROUP --name $AKS_CLUSTER --node-count 2

Attendez plusieurs minutes que le traitement de création du nœud se termine :

Retrouvez ce nombre actualisé sur le portail Azure :

Exécutez la commande suivante pour vérifier le résultat de la mise à l’échelle du cluster :

 kubectl get nodes

Retrouvez cette même information sur le portail Azure :

Exécutez la commande suivante pour mettre le déploiement à l’échelle sur 10 répliques :

 kubectl scale --replicas=10 deployment/nginx-deployment

Exécutez la commande suivante pour vérifier le résultat :

 kubectl get pods

Retrouvez cette même information sur le portail Azure :

Exécutez la commande suivante pour vérifier la répartition des pods sur les nœuds du cluster :

kubectl get pod -o=custom-columns=NODE:.spec.nodeName,POD:.metadata.name

Retrouvez cette même information sur le portail Azure :

Exécutez la procédure suivante pour remettre à l’échelle le cluster à 1 nœud :

 az aks scale --resource-group $RESOURCE_GROUP --name $AKS_CLUSTER --node-count 1

Quelques minutes plus tard, retrouvez cette même information sur le portail Azure :

 kubectl get pod -o=custom-columns=NODE:.spec.nodeName,POD:.metadata.name

Exécutez la commande suivante pour vérifier la répartition des pods sur le seul nœud restant du cluster :

AKS supporte très bien l’ajout de conteneurs managés ACI. Testons un peu cela.

Etape VII – Mix entre AKS et ACI :

Vérifiez l’état de l’enregistrement du fournisseur ACI à l’aide de la commande suivante :

az provider list --query "[?contains(namespace,'Microsoft.ContainerInstance')]" -o table

L’exemple suivant montre que le fournisseur Microsoft.ContainerInstance est enregistré :

Si le fournisseur n’est pas enregistré, il faut l’enregistrer à l’aide de la commande suivante :

az provider register --namespace Microsoft.ContainerInstance

Exécutez la commande suivante pour obtenir la liste des noeux actifs sur AKS :

kubectl get nodes

Créez un fichier nommé virtual-node.yaml en y copiant le contenu YAML suivant, ou récupérez son contenu juste ici :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: aci-helloworld
spec:
  replicas: 1
  selector:
    matchLabels:
      app: aci-helloworld
  template:
    metadata:
      labels:
        app: aci-helloworld
    spec:
      containers:
      - name: aci-helloworld
        image: mcr.microsoft.com/azuredocs/aci-helloworld
        ports:
        - containerPort: 80
      nodeSelector:
        kubernetes.io/role: agent
        beta.kubernetes.io/os: linux
        type: virtual-kubelet
      tolerations:
      - key: virtual-kubelet.io/provider
        operator: Exists

Cliquez sur Téléverser pour lancer l’opération de transfert vers Azure :

Choisissez le fichier précédemment généré :

Exécutez l’application à l’aide de la commande suivante :

kubectl apply -f virtual-node.yaml

Constatez l’apparition de l’application sur votre portail Azure, puis attendez :

Exécutez la commande suivante pour exposer, donc rendre le pod disponible depuis Internet :

kubectl expose deployment aci-helloworld --port=80 --type=LoadBalancer

Ouvrez un nouvel onglet de navigateur, puis collez l’adresse IP correspondante.

Vérifiez que la page du navigateur affiche bien le message Welcome to Azure Container Instances! :

Exécutez la commande suivante pour mettre à l’échelle le déploiement en augmentant le nombre de pods à 5 :

kubectl scale --replicas=5 deployment/aci-helloworld

Retrouvez cette même information sur le portail Azure :

Cliquez sur votre nœud ACI :

Constatez la bonne présence de votre application et de ses répliques :

Un dernier test pour mieux comprendre le découplage d’une application dans plusieurs conteneurs.

Etape VIII – Test d’une application multi-conteneurs :

Créer un fichier nommé azure-vote-v2.yaml en y copiant le contenu YAML suivant, ou récupérez son contenu juste ici :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: azure-vote-back
spec:
  replicas: 1
  selector:
    matchLabels:
      app: azure-vote-back
  template:
    metadata:
      labels:
        app: azure-vote-back
    spec:
      nodeSelector:
        kubernetes.io/role: agent
        beta.kubernetes.io/os: linux
        type: virtual-kubelet
      tolerations:
      - key: virtual-kubelet.io/provider
        operator: Exists
      containers:
      - name: azure-vote-back
        image: mcr.microsoft.com/oss/bitnami/redis:6.0.8
        env:
        - name: ALLOW_EMPTY_PASSWORD
          value: "yes"
        ports:
        - containerPort: 6379
          name: redis
---
apiVersion: v1
kind: Service
metadata:
  name: azure-vote-back
spec:
  ports:
  - port: 6379
  selector:
    app: azure-vote-back
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: azure-vote-front
spec:
  replicas: 1
  selector:
    matchLabels:
      app: azure-vote-front
  template:
    metadata:
      labels:
        app: azure-vote-front
    spec:
      nodeSelector:
        kubernetes.io/role: agent
        beta.kubernetes.io/os: linux
        type: virtual-kubelet
      tolerations:
      - key: virtual-kubelet.io/provider
        operator: Exists
      containers:
      - name: azure-vote-front
        image: mcr.microsoft.com/azuredocs/azure-vote-front:v1
        ports:
        - containerPort: 80
        env:
        - name: REDIS
          value: "azure-vote-back"
---
apiVersion: v1
kind: Service
metadata:
  name: azure-vote-front
spec:
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: azure-vote-front

Cliquez sur Téléverser pour lancer l’opération de transfert vers Azure :

Exécutez l’application à l’aide de la commande suivante :

kubectl apply -f azure-vote-v2.yaml

Constatez l’apparition de l’application sur votre portail Azure, puis attendez :

Environ 2 minutes plus, constatez le changement de statut en vert :

Vérifiez la bonne affectation de votre application sur le nœud ACI :

Cette information avait été renseigné dans le fichier YAML :

Ouvrez un nouvel onglet de navigateur en collant l’adresse IP correspondante :

Vérifiez que la page du navigateur affiche bien l’application de vote :

Testez l’application en votant pour Chiens ou Chats :

Ouvrez un nouvel onglet en navigation privée :

Vérifiez la persistance des votes précédemment réalisés :

Effacez votre résultat, puis fermez l’onglet de navigation privé :

Rafraichissez la page de test, puis constatez le même effacement des précédents votes :

Conclusion

Grâce à ce petit exercice, nous avons bien compris que le conteneur n’est qu’un moyen parmi d’autres pour faire tourner une application, avec de nombreux avantages.

Mais, quelle que soit la plateforme choisie, il est toujours primordial de suivre les bonnes pratiques pour concevoir, mettre en œuvre et gérer vos applications : à savoir la surveillance, optimisations, sécurité, confirmé et coûts 😎.

Azure Bastion est votre ami !

Par moment, les machines virtuelles ont besoin de passer entre les mains de l’IT pour différentes tâches : mises à jour OS, installation d’applications, résolution de problème, etc … A l’inverse des accès utilisateurs, les connexions réalisées par les équipes IT, dont les privilèges sont potentiellement plus élevés, sont souvent occasionnelles et externes.

Ce besoin de connexion irrégulier ne doit pas pourtant donner lieu à abaissement de la sécurité, car des risques pour vos VMs Azure sont toujours présents :

  • Risques d’attaque plus élevés si la sécurité de l’accès IT est dégradée
  • Risques de dégâts plus importants compte tenu des privilèges IT élevés

Comme pour n’importe quel accès, des mesures de sécurité en couche sont nécessaires, même pour les équipes IT. Voici des liens vers des articles précédemment écrits de blog :

Qu’est-ce qu’Azure Bastion ?

Voici la définition d’Azure Bastion donnée par Microsoft

Azure Bastion est un service complètement managé qui offre un accès RDP (Remote Desktop Protocol) et SSH (Secure Shell) plus sécurisé et transparent pour les machines virtuelles sans aucune exposition via des adresses IP publiques. Approvisionnez le service directement dans votre réseau virtuel local ou appairé pour prendre en charge toutes les machines virtuelles qu’il contient.

Documentation Azure

Azure Bastion est donc un service de jump pour accéder aux machines virtuelles sur Azure, que celles-ci soient Windows ou Linux.

Le schéma ci-dessous nous montre le tunnel d’accès créé entre Azure Bastion et l’utilisateur initiateur (via une connexion inversée) grâce au protocole TLS :

J’ai également trouvé une vidéo dédiée à Azure Bastion en français, dont voici le lien :

Quel est son point fort ?

Un seul mot doit vous venir en tête :

La sécurité

Comme tout service de jump, Azure Bastion devient de facto la ressource exposée de votre infrastructure Cloud. Dans les faits, ce dernier intègre des fonctions de pare-feu et des mesures périmétriques de sécurité.

De plus, l’accès au service depuis le portail Azure apporte la couche de pré-authentification d’Azure AD. Celui-ci profite alors de toutes ses mesures de sécurité, comme l’Accès conditionnel, la gestion des droits RBAC, etc …

L’approche d’une connexion sécurisée via TLS permet de s’affranchir de règles sécurités lourdes.

Enfin, Azure Bastion mettra tout le monde d’accord grâce au retrait des adresses IP publiques sur vos VMs Azure, car la connexion RDP/SSH entre Bastion et votre machine virtuelle se fera via le réseau virtuel privé Azure, donc grâce et uniquement par son adresse IP privée.

Combien coûte Azure Bastion ?

Disons-le tout de suite, Azure Bastion n’est pas un service gratuit 🤣. La documentation Azure nous donne toutes les informations tarifaires. Voici la copie d’écran du service dans la région Azure Suisse Nord :

Voici ces mêmes données tarifaires pour un mois complet, dans le cas où le service reste actif :

  • Azure Bastion Basic : 125 CHF environ
  • Azure Bastion Standard : 192 CHF environ

Gardez à l’esprit que ce service ne nécessite pas systématiquement un déploiement aussi long. Dans beaucoup d’infrastructures IT, il est possible d’envisager son déploiement à la demande.

Cinq petites minutes vous suffiront pour déployer Azure Bastion !

Comment choisir son SKU Bastion ?

Choisir le SKU d’Azure Bastion adapté à vos besoins doit reposer sur les fonctionnalités voulues. Quelques fonctionnalités diffèrent entre les versions Basic et Standard :

A noter qu’il est possible de migrer du SKU Basic au SKU Standard après le déploiement de Bastion, mais pas le chemin inverse n’est plus possible.

Comment mettre en place Azure Bastion ?

Rien de plus simple ! Quelques clics suffisent pour déployer Azure Bastion.

Dans cet article, nous allons déployer Azure Bastion, puis tester quelques fonctionnalités de connexion. Bref, ne perdons pas de temps :

Etape 0 – Rappel des prérequis :

Pour réaliser cet exercice sur Azure Bastion, dont certaines fonctionnalités sont encore en préversion, il vous faudra disposer de :

  • Un tenant Microsoft
  • Une souscription Azure valide

Mon environnement Azure de départ ne contient aucune autre ressource, commençons par la préparation d’un nouvel environnement Azure :

Etape I – Préparation de votre environnement Azure :

Commencez par rechercher le service Réseau Virtuel dans la barre de recherche tout en haut :

Cliquez ici pour créer votre premier réseau virtuel Azure :

Créez un premier groupe de ressources, donnez un nom à votre réseau virtuel, puis lancez la validation Azure :

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

Attendez environ une minute que le processus de création se termine :

Une fois terminé, recherchez le service des Machines Virtuelles Azure :

Cliquez-ici pour créer une première machine virtuelle Azure :

Renseignez les informations de base relatives à votre VM :

Pensez à désactiver les règles publiques de port entrant, puis cliquez sur Suivant :

Aucune option n’est à modifier sur l’onglet des disques, cliquez sur Suivant :

Dans l’onglet réseau, effectuez les modifications suivantes :

  • Retirez l’adresse IP publique proposée par Azure
  • Vérifiez que les règles publiques du NSG lié à la carte réseau de la VM sont bien désactivées

Puis, cliquez-ici pour lancer la validation :

Une fois la validation réussie, cliquez-ici pour démarrer le processus de création :

Environ deux minutes plus tard, cliquez-ici pour accéder à votre machine virtuelle Azure :

Cliquez sur Connecter pour démarrer une session de bureau à distance :

Azure commence par effectuer contrôles d’accès. Deux points sur trois sont déjà considérés comme des blocages potentiels :

  • Port RDP fermé : L’accès publique au port RDP a été volontairement fermé lors de la création de la machine virtuelle.
  • Absence d’adresse IP publique : celle-ci a volontairement été retirée lors de la création de la machine virtuelle.

Cliquez-ici pour télécharger le fichier RDP préconfiguré pour vous connecter à votre VM :

Exécutez le fichier RDP téléchargé précédemment, puis attendez :

Environ vingt secondes plus tard, un message d’échec de connexion doit apparaître :

Pas d’adresse IP publique et pas de port RDP ouvert en public sont bien les explications logiques du blocage de l’accès distant.

Retrouvez la configuration de ces deux points justes ici :

L’accès RDP à notre machine virtuelle est bien sécurisé. Mais du coup … personne en dehors d’Azure peut s’y connecter ! Il nous faut trouver une solution sans exposer la machine virtuelle.

C’est ici qu’Azure Bastion rentre en scène.

Etape II – Déploiement d’Azure Bastion :

Comme l’indique le schéma ci-dessous, Azure Bastion s’installe sur un sous-réseau dédié dont son nom est normé : AzureBastionSubnet.

Sur votre Portail Azure, recherchez le réseau virtuel créé précédemment :

Dans la section des sous-réseaux, ajoutez-en un :

Le sous-réseau doit avoir la configuration suivante :

  • Le nom du sous-réseau doit être AzureBastionSubnet.
  • La taille du sous-réseau doit être /26 ou plus grand
  • Le sous-réseau ne pourra pas contenir d’autres ressources Azure

Renseignez les champs, puis sauvegardez-le :

Recherchez ensuite le service Bastion dans la barre de recherche du portail Azure :

Cliquez-ici pour créer votre Azure Bastion :

Renseignez les champs nécessaires, en prenant soin de sélectionner un SKU de type Basic, puis lancez la validation Azure :

Une fois la validation réussie, lancez la création de votre Azure Bastion :

Attendez environ 5 minutes pour que le service soit entièrement déployé sur votre environnement :

Selon la charge présente sur la région Azure sélectionnée, il arrive que le processus de création soit un peu plus long.

Retournez sur votre machine virtuelle de test, puis lancez une connexion comme ceci :

Renseignez les identifiants de l’administrateur local renseignés lors de la création de votre VM, puis cliquez sur Connecter :

Un nouvel onglet dans votre navigateur interne s’ouvre et ouvre une session Windows sur votre machine virtuelle :

Si rien ne se passe, vérifiez si ce dernier ne bloque pas les pop-ups Azure.

Gardez ouverte la session de bureau à distance via Azure Bastion.

Sur la partie gauche de votre session, notez la présence de deux flèches, cliquez dessus, puis constatez le presse-papier de base :

Retournez sur le portail Azure, le menu Session affiche une liste des utilisateurs connectés à Azure Bastion.

Note : Il est en effet possible d’ouvrir plusieurs sessions Bastions vers différentes machines virtuelles.

Votre service Bastion fonctionne bien, l’accès RDP à votre machine virtuelle Windows est sécurisé. Continuons un peu en testant une autre méthode de connexion grâce à Azure Bastion.

Etape III – Azure Bastion via un appairage entre réseaux virtuels Azure :

Bien souvent, les infrastructures Azure contiennent plusieurs réseaux virtuels. Cela fait sens dans le cadre d’architecture multi-régions. Ici, nul besoin de créer et de payer plusieurs Bastion !

Afin de tester le bon fonctionnement d’un seul service Azure Bastion sur un autre réseau virtuel, j’ai créé les ressources Azure suivantes :

  • Second réseau virtuel Azure
  • Seconde machine virtuelle Azure
  • Appairage entre les 2 réseaux virtuels

Voici l’appairage et son statut Connecté sur un des 2 réseaux virtuels :

Sur la seconde machine virtuelle, cliquez sur le service Azure Bastion pour m’y connecter :

  • Azure recherche si un service Bastion est déployé sur le même réseau virtuel
  • Si non, Azure recherche un Bastion sur un réseau virtuel appairé à celui-ci

Renseignez les identifiants de l’administrateur local de ma seconde VM, puis cliquez sur Connecter :

Constatez la bonne connexion RDP à ma seconde machine virtuelle :

Azure Bastion fonctionne donc de manière étendue à plusieurs réseaux virtuels. Cette fonction est accessible dès le SKU Basic. Aucun doute que cela est fortement apprécié car il simplifie les méthodes de connexion, mais réduit aussi les coûts !

D’autres méthodes de connexion sont disponibles via Azure Bastion, mais elles nécessitent de changer le SKU de notre service.

Etape IV – Upgrade d’Azure Bastion vers le SKU Standard :

Pour tester les autres méthodes de connexion, il nous est nécessaire de changer le SKU d’Azure Bastion de Basic vers Standard :

Attention, la migration du SKU en Standard n’est pas réversible !

Attendez quelques minutes qu’Azure applique votre upgrade :

Le changement de SKU d’Azure Bastion entraine d’ailleurs une fermeture des sessions ouvertes via Azure Bastion :

Quelques minutes plus tard, le traitement d’upgrade est terminé :

Notre Azure Bastion est maintenant Standard. Nous allons pouvoir tester d’autres moyens de connexion, comme par exemple via le client natif.

Etape V – Support du client natif d’Azure Bastion :

La fonctionnalité de client natif vous permet de vous connecter à vos machines virtuelles cibles par le biais de Bastion en utilisant Azure CLI

Microsoft Learn

En quelques mots, cette méthode est utile quand on souhaite se passer du portail Azure. Pour utiliser ce moyen de connexion, il est nécessaire d’activer ce service sur Bastion.

Comme les options supplémentaires de Bastion sont maintenant dégrisées, cochez la case Support du client natif, puis cliquez sur Appliquer :

Attendez quelques minutes qu’Azure applique votre modification :

Sur votre poste local, ouvrez une session Terminal :

Commencez par mettre à jour le sous-module réseau d’Azure, utilisé par Azure Bastion :

Update-Module Az.Network -Force

Attendez quelques minutes que le téléchargement, puis l’installation du module se termine :

Copiez l’ID de la souscription contenant votre service Azure Bastion :

Dans votre fenêtre Terminal, lancez le processus d’authentification à Azure :

az login

Microsoft Edge doit alors s’ouvrir pour vous proposer de réutiliser un compte Azure déjà authentifié. Cliquez sur celui-ci si cela est votre cas :

Le message suivant apparaît alors dans votre navigateur :

De retour sur Terminal, saisissez la commande pour vous positionner sur la souscription Azure de votre Bastion :

az account set --subscription "<subscription ID>"

Sur le portail Azure, récupérez l’ID de ressource de votre première machine virtuelle :

Dans votre fenêtre Terminal, saisissez la commande suivante en prenant soin de modifier les 3 variables suivantes :

  • Nom de votre ressource Azure Bastion
  • Groupe de ressources votre service Azure Bastion
  • ID de ressource de votre machine virtuelle
az network bastion rdp --name "<BastionName>" --resource-group "<ResourceGroupName>" --target-resource-id "<VMResourceId>"

Un pop-up RDP s’ouvre alors, cliquez sur Connecter :

Renseignez les identifiants de l’administrateur local renseignés lors de la création de votre VM :

Acceptez le risque en cliquant sur Oui :

Une connexion RDP s’ouvre sur le bureau de votre VM :

Fermez la session de bureau à distance.

Comme Microsoft et d’autres le rappellent, la sécurité de la connexion native peut être renforcée en limitant l’accès uniquement aux ports 22/3389 :

Continuons en testant une autre méthode de connexion à Azure Bastion: les liens partageables.

Etape VI – Utilisation de liens partageables Azure Bastion :

La fonctionnalité lien partageable Bastion permet aux utilisateurs de se connecter à une ressource cible (machine virtuelle ou groupe de machines virtuelles identiques) à l’aide d’Azure Bastion sans accéder au Portail Azure.

Microsoft Learn

Là encore, l’accès au portail Azure n’est peut-être pas possible ou voulue. Le lien partageable peut être communiqué à un tier afin que celui-ci puisse se connecter à la machine virtuelle et y effectuer des opérations IT.

Dans l’écran de configuration d’Azure Bastion, cochez la case suivante, puis cliquez sur Appliquer :

Attendez quelques minutes afin qu’Azure applique votre modification :

Un nouveau menu dédié aux liens partagés fait son apparition dans les paramètres votre Azure Bastion. Cliquez-ici pour créer votre premier lien partagé :

Cochez la ou les machines virtuelles accessibles grâce à ce lien, puis cliquer sur Appliquer :

Le nouveau lien partagé s’ajoute aux liens déjà générés, copiez votre lien dans le presse-papier :

Ouvrez un navigateur privé :

Collez votre lien partageable dans la barre d’adresse, renseignez les identifiants de l’administrateur local renseignés lors de la création de votre VM, puis cliquez-ici pour ouvrir la session :

Attendez quelques secondes, puis constatez l’ouverture du bureau à distance :

Avant de fermer la session ouverte grâce au lien partagé, supprimez le lien généré :

Constatez l’absence de fermeture de session, malgré la suppression du lien.

Fermez la session puis retentez l’ouverture par la même URL précédemment copiée :

L’utilisateur est bien bloqué dans sa seconde tentative de connexion.

Ces liens partagés sont donc intéressant si les utilisateurs sont externes au service IT doivent intervenir très ponctuellement sur une machine virtuelle.

Continuons nos tests sur une autre méthode de connexion : les adresses IP privées.

Etape VII – Utilisations des adresses IP privées :

Une connexion basée sur IP vous permet de vous connecter à vos machines virtuelles Azure et non Azure locales via Azure Bastion sur ExpressRoute ou une connexion VPN site à site en utilisant une adresse IP privée spécifiée.

Microsoft Learn

Grâce à cette fonctionnalité, les équipes IT peuvent se connecter à presque tous les VMS grâce à Azure Bastion ! Peu importe où la ressource se trouve : dans ou en dehors d’Azure.

Pour tester cette fonctionnalité, j’ai modifié quelques peu mon infrastructure Azure déjà en place. J’ai simulé une connexion site à site entre mes 2 réseaux virtuels comme ceci :

  • J’ai supprimé l’appairage entre mes deux réseaux virtuels
  • Sur chacun de mes deux réseaux virtuels Azure, j’ai déployé les ressources suivantes :
    • Passerelle VPN Basic
    • Passerelle de réseau local reprenant l’IP publique du VPN opposé
    • Connexion VPN IP Sec

Une des 2 passerelles VPNs configurées :

x2.

Une des 2 passerelles de réseau local configurées :

x2.

Une des 2 connexions VPN configurées :

x2.

Une fois l’infrastructure réseau en place, cochez la case suivante dans la configuration d’Azure Bastion, puis cliquez sur Appliquer :

Attendez quelques minutes qu’Azure applique votre modification :

Un nouveau menu dédié aux adresses IP privées fait son apparition sur votre configuration Azure Bastion. Cliquez-ici pour créer établir une connexion directe :

Attendez quelques secondes, puis constatez l’ouverture du bureau à distance :

Sur une des 2 connexions VPNs, modifiez la clef partagée afin de briser la connexion entre les 2 réseaux virtuels, et de ce fait, couper la session de bureau à distance :

Attendez quelques secondes :

La session d’Azure Bastion fini bien par s’interrompre :

Restaurez la bonne clef partagée, puis sauvegardez :

La connexion du bureau à distance transitant par Bastion est alors automatiquement rétablie :

Conclusion

Bastion rejoint la liste des services managés Azure très utile et très facile à mettre en oeuvre. La non-maîtrise des réseaux rend l’outil encore plus accessible aux débutants, et apporte une première couche de sécurité.

Il ne faut jamais douter des capacités d’attaque de pirates quand des ressources se retrouvent exposées sur internet, Cloud ou pas.

Bodybuildez votre AVD !

Azure Virtual Desktop n’en finit plus d’évoluer ! Aujourd’hui est une grande journée pour l’automatisation des environnements AVD. Jusqu’à présent, Azure proposait peu de solutions adéquates pour AVD pour faciliter le processus de gestion des images des VMs. Pour enfoncer le clou(d), d’autres solutions tierces faisaient déjà mieux et rendaient le travail IT beaucoup plus léger.

Microsoft vient donc de sortir une nouvelle fonctionnalité à son produit AVD, encore en préversion à ce jour, mais attendue depuis fort longtemps : Custom image templates, ou Modèles d’images personnalisés pour les francophones.

Aucun doute que les administrateurs d’AVD vont aimer !

Pourquoi doit-on gérer des images avec Azure Virtual Desktop ?

La gestion des applications et des mises à jour d’un environnement AVD reste très proche d’un environnement RDS traditionnel. De temps à autre, il vous faut penser à :

  • Les applications doivent être mises à jour
  • Les mises à jour correctives ou sécuritaires doivent être appliquées
  • Les besoins logiciels des utilisateurs évoluent
  • De nouvelles optimisations sont disponibles

Toutes ces raisons et encore d’autres font que les machines virtuelles d’un environnement Azure Virtual Desktop doivent être mises à jour régulièrement, et si possible, avec un mode opératoire le plus automatisé.

Que proposait Azure Virtual Desktop avant cette fonctionnalité ?

En cherchant un peu, on retrouvait déjà plusieurs méthodes qui avaient déjà fait leurs preuves :

  • Gestion 100% manuelle via Golden Image / Sysprep / Snapshot :
  • Gestion 50% manuelle via l’utilisation d’un Template d’Azure Image Builder :
  • Solutions tierces, comme par exemple la très connue Nerdio :

Sur quoi repose la fonction Custom image templates d’AVD ?

Disons-le tout de suite, Custom image templates fonctionne toujours avec Azure Image Builder.

Mais tout est maintenant intégré dans la console Azure Virtual Desktop. Et le meilleur dans tout ça :

l’intégration d’optimisations est gérée dans le template, qu’elles soient préconstruites par Microsoft ou créées par vos soins !

C’est tout le processus de préparation qui peut alors s’intégrer dans la seule étape de création du template. Fini les aller et retours !

Bref, ne perdons pas de temps, et testons ensemble cette fonctionnalité.

Etape 0 – Rappel des prérequis :

Pour réaliser cet exercice sur les templates d’Azure Virtual Desktop, encore en préversion, il vous faudra disposer de :

  • Un tenant Microsoft
  • Une souscription Azure valide

Afin de ne pas rendre cet article trop long, j’ai déjà préparé un environnement Azure. Je vous liste dans l’étape suivante tous les composants déjà mis en place sur mon environnement avant de démarrer le test.

Etape I – Préparation de votre environnement Azure Virtual Desktop :

J’ai créé un premier groupe de ressources Azure, dans lequel j’ai déployé 2 VMs :

  • Une première machine virtuelle Windows Server avec des rôles AD DS / DNS
  • Une seconde machine virtuelle Windows Server avec Azure AD Connect

J’ai également déployé dans un second groupe de ressources pour :

  • Un réseau virtuel pour l’ensemble de mon infrastructure AD DS / AVD :
  • Un service Azure Bastion pour me connecter aux différentes machines de mon domaine

Dans ce réseau virtuel Azure, nous retrouvons les sous-réseaux suivants :

  • Sous-réseau pour la partie domaine / Azure AD Connect
  • Sous-réseau pour les machines virtuelles AVD
  • Sous-réseau dédié au service Azure Bastion

Je n’ai pas oublié non plus de renseigner l’adresse IP locale de mon AD en tant que DNS de premier niveau sur mon réseau virtuel :

J’ai également déployé une Azure Compute Gallery, dans laquelle se trouvent une définition de base d’une image pour mon environnement AVD :

Grâce à la mise en place du domaine Active Directory et d’Azure AD Connect, j’ai pu synchroniser deux utilisateurs AD vers Azure AD :

J’ai également créé un compte de stockage Azure. Grâce à la tâche 6 de cet article, j’ai configuré ce compte de stockage pour être joint à mon Active Directory.

J’ai également créé un partage de fichier pour la gestion des profiles en itinérance via FSLogix :

Je n’ai pas oublié de rajouter les rôles Azure RBAC spécifiques au partage SMB FSLogix :

J’ai également transposé ces droits Azure RBAC en droits NTFS sur ce même partage FSLogix :

J’ai enfin vérifié, au niveau de ma souscription Azure, le bon enregistrement des fournisseurs de ressources suivants :

  • Microsoft.VirtualMachineImages
  • Microsoft.KeyVault

Si cela n’est pas fait, voici la procédure qui vous prendra à peine deux minutes :

Votre environnement de départ est enfin prêt pour commencer la mise en place de Modèles d’images personnalisés pour AVD.

L’étape suivante est donc consacré à la mise en place d’une identité managée pour Azure VM Image Builder.

Etape II – Azure VM Image Builder :

VM Image Builder est un service Azure complètement managé qui est accessible aux fournisseurs de ressources Azure. Les fournisseurs de ressources le configurent en spécifiant une image source, une personnalisation à effectuer et l’emplacement où la nouvelle image doit être distribuée.

Microsoft Learn

Pour que Azure VM Image Builder gère des images AVD, il est nécessaire de lui créer une identité managée Azure. Celle-ci disposera des autorisations nécessaires pour lire et écrire des images :

Microsoft.Compute/images/write
Microsoft.Compute/images/read
Microsoft.Compute/images/delete
Microsoft.Compute/galleries/read
Microsoft.Compute/galleries/images/read
Microsoft.Compute/galleries/images/versions/read
Microsoft.Compute/galleries/images/versions/write

Au niveau de votre souscription Azure, rendez-vous dans le menu suivant pour commencer la création d’un rôle personnalisé :

Donnez-lui un nom, puis cliquez sur Suivant :

Parcourez la liste des permissions disponibles afin d’ajouter celles ci-dessous :

Dean met aussi à disposition sur son GitHub un template JSON contenant ces permissions.

Définissez le périmètre de la souscription Azure pour ce nouveau rôle :

Lancez la création en cliquant sur Créer :

Sur votre portail, recherchez dans la barre du haut le services des Identités Managées :

Cliquez-ici pour créer votre Identité Managée dédiée à Azure VM Image Builder :

Nommez celle-ci, puis lancez la validation :

Une fois la validation passée, cliquez sur Créer :

Retournez au niveau de la souscription Azure pour assigner le rôle personnalisé à votre nouvelle identité managée :

Recherchez le rôle personnalisé en utilisant le filtre :

Cliquez ici pour rechercher dans Azure AD votre nouvelle identité managée :

Lancez la validation de votre affectation :

Une fois la validation passée, cliquez sur Assigner :

Toutes les étapes préparatoires à la création d’un modèle d’image personnalisé sont maintenant terminées. Nous allons pouvoir maintenant commencer la création de notre template AVD.

Comme le rappelle Dean durant sa vidéo, d’autres options seront prochainement rajoutées par la suite.

Etape III – Création d’un modèle d’image personnalisé :

Recherchez le service Azure Virtual Desktop en utilisant la barre du haut :

Dans le menu Modèle d’image personnalisés, cliquez-ici pour ajouter votre premier template :

Nommez votre template, choisissez sa localisation, reprenez l’identité managée créée et affectée précédemment, puis cliquez sur Suivant :

Comme il s’agit de votre premier template, cliquez sur Non à la question d’importation :

Sélectionnez votre image source, en utilisant par exemple la Marketplace Microsoft :

Attention à la génération rattachée à votre Image.
Celle-ci devra également utiliser des tailles de VM compatibles.

Concernant le stockage de votre template AVD, deux destinations sont possibles avec Azure VM Image Builder :

  • Image managée : utilisable pour AVD ou Windows 365
  • Azure Compute Gallery : utilisable pour AVD

Cochez la cible Azure Compute Gallery, renseignez les informations nécessaires, puis cliquez sur Suivant :

L’option Latest sera un choix intéressant pour positionner l’image en dernière version à déployer.

Azure VM Image Builder a besoin de quelques informations durant le processus de fabrication :

  • Timeout : à définir si besoin. Si vide, alors 240 minutes
  • Taille de la VM : taille sans rapport direct avec les futures VMs AVD
  • Taille du disque OS : taille avec rapport direct sur celui des futures VMs AVD
  • Groupe de ressources temporaire : Si laissé vide, le groupe sera créé par Azure
  • Réseau Virtuel : champs facultatifs

Puis cliquez sur Suivant :

Azure VM Image Builder vous propose d’exécuter à votre place des traitements post-déploiement. Vous pouvez lancer vos propres scripts, ou piochez dans la longue liste mise à disposition par Microsoft.

Cliquez-ici pour ajouter votre propre script, si besoin :

Cliquez-ici pour consulter la liste des scripts dédiés à AVD et construits par Microsoft :

Choix dans la liste les options voulues, puis sauvegardez :

Vérifier une dernière fois les options choisies, puis cliquez sur Suivant :

Ajoutez les étiquettes pour une meilleure classification de vos ressources Azure, puis cliquez sur Suivant :

Lancez la création de votre template en cliquant sur Créer :

Environ quelques secondes plus tard, le processus de création du template se lance, le statut passe alors en Création :

La création d’un template est assez rapide, le statut doit alors changer en Succès et le nom du groupe de ressources temporaire doit apparaître.

Cliquez dessus pour voir la première ressource créée :

Seul un compte de stockage est pour l’instant créé, cliquez dessus :

Un premier conteneur Blob est créé, dans lequel se trouvent les optimisations de votre template AVD :

Retournez sur les Modèles d’images personnalisés, puis cliquez sur le groupe de ressources de votre template :

Constatez la présence de votre template :

Le template, ou la recette de votre VM AVD, est maintenant prêt. Un second processus doit être lancé pour créer l’image AVD en elle-même. Azure VM Image Builder va réaliser les actions suivantes :

  • Créer une machine virtuelle à partir de la marketplace
  • Lui appliquer votre configuration personnalisée
  • La capturer et la stocker dans votre Azure Compute Gallery

Etape IV – Préparation de l’image AVD :

Ce processus peut prendre beaucoup de temp. Celui-ci dépendra également des personnalisations choisies à appliquer.

Cliquez-ici pour démarrer le processus de construction de votre image :

Le statut de construction change comme ceci :

Deux nouveaux conteneurs sont créés sur votre compte de stockage temporaire :

  • packerlogs : Journal d’évènements d’Azure VM Image Builder
  • vhds : fichier VHD de votre image créé par Azure VM Image Builder

Cliquez sur le premier conteneur afin de consulter, si besoin, le journal de log d’Azure VM Image Builder :

Rafraichissez cette page afin de voir le changement de statut :

Rafraichissez également cette seconde page afin de voir les changements de date de modification du journal d’évènements :

Environ 2 heures plus tard, le statut est enfin passé à Succès :

Vérifiez que la définition de votre image est bien stockée dans votre Azure Compute Gallery :

La version de l’image est également visible dans le groupe de ressources cible :

Notre image est enfin prête à intégrer un environnement Azure Virtual Desktop.

L’étape suivante consiste donc à créer un premier pool AVD en choisissant comme source cette nouvelle image personnalisée.

Etape V – Création de l’environnement AVD :

Sur la page Azure Virtual Desktop, commencez la création de votre environnement Azure Virtual Desktop comme ceci :

Définissez les options de base de votre pool d’hôtes :

Ajoutez une ou plusieurs machines virtuelles en prenant le soin de choisir l’image créée et stockée dans votre Azure Compute Gallery :

Renseignez les informations réseaux pour que votre VMs AVD se trouve sur le même réseau virtuel que votre AD :

Renseignez les informations liées à votre AD et les identifiants pour disposer d’un compte administrateur local, puis cliquez sur Suivant :

Créez un nouvel Espace de travail, puis lancez la validation :

Une fois la validation terminée, cliquez sur Créer :

Attendez environ 5 à 10 minutes, le temps que la création de votre environnement AVD se termine, puis cliquez ici :

Changez l’option d’authentification d’Azure AD, puis sauvegardez :

Cliquez sur le groupe d’applications AVD :

Ajoutez vos utilisateurs ou votre groupe d’utilisateurs de test :

C’est enfin fini ! Toutes les configurations sont faites ! Il ne vous reste plus qu’à tester votre nouvel environnement Azure Virtual Desktop.

Etape VI – Test de connexion à votre environnement AVD :

Pour cela, utilisez le client Remote Desktop disponible ici, ou l’URL suivante pour une connexion en HTLML5 via le navigateur internet.

Ouvrez votre application, souscrivez à un nouvel espace de travail, puis authentifiez-vous avec un compte utilisateur de test :

Réauthentifiez-vous une seconde fois, localement :

Attendez que la session de bureau à distance s’ouvre :

Vérifiez quelques paramétrages personnalisés, comme la langue ou les applications installées :

Les choses semblent pas mal pour moi sauf le pays et encore l’heure de la VM :

Vérifiez également sur votre compte de stockage dédié à FSLogix que l’ouverture de session AVD génère bien la création d’un profil itinérant :

On peut dire qu’on est pas mal, non ? 😎

Conclusion :

L’intégration Azure VM Image Builder dans la console Azure Virtual Desktop, mais aussi l’ajout direct de personnalisations, proposées par Microsoft, est un véritable pas en avant concernant la simplification !

Azure Virtual Desktop conserve malgré tout la caractéristique de pouvoir être personnalisé manuellement, mais apporte en parallèle une couche d’automatisme pour les petits environnements.

Nul doute que tout cela sera très fortement apprécié !

Checkez la disponibilité de vos VMs Azure

Beaucoup de projets d’infrastructure Cloud contiennent des services Cloud de type IaaS. Entièrement configurable, une machine virtuelle en est un bon exemple chez tous les principaux fournisseurs de Cloud. Le IaaS apporte des avantages par une grande flexibilité, mais aussi des inconvénients, comme par exemple sa gestion des mises à jour.

Dans le cadre d’un hébergement d’un service web, la machine virtuelle n’est d’ailleurs pas le premier choix proposé par les fournisseurs Cloud. Néanmoins, il arrive qu’une machine virtuelle soit le seul choix technique possible.

Dans cet article, nous n’allons pas nous intéresser au choix VM / App Service. Mais à la mise en place d’une alerte de disponibilité HTTP, dans le but vérifier le bon fonctionnement de l’accès externe.

Que sont les alertes d’Azure Monitor ?

Les alertes vous permettre de détecter et de résoudre des problèmes avant que les utilisateurs ne les remarquent en vous informant de manière proactive quand les données Azure Monitor indiquent qu’il peut y avoir un problème avec votre infrastructure ou votre application.

Vous pouvez définir une alerte sur n’importe quelle source de données de métrique ou de journal dans la plateforme de données Azure Monitor.

Microsoft Learn

Il est très facile de créer une alerte sur un Web App. Mais il est aussi possible d’en créer sur d’autres services, comme sur un service IIS hébergé sur une machine virtuelle.

Afin des tester ce scénario, nous allons créer une machine virtuelle avec un rôle IIS afin de créer une alerte HTTP pour vérifier sa bonne disponibilité à travers le globe :

Etape 0 – Rappel des prérequis :

Pour réaliser cet exercice sur les alertes d’Azure Monitor, il vous faudra disposer de :

  • Un tenant Microsoft
  • Une souscription Azure valide

Si vous ne disposez pas de machine virtuelle Azure sur votre environnement, commencez par l’étape I afin de préparer l’environnement nécessaire à la mise en place de l’alerte.

Etape I – Création de la machine virtuelle Azure :

Commencez par créer une Machine Virtuelle Azure en utilisant la barre de recherche en haut du portail :

Sélectionnez le premier choix pour créer votre machine virtuelle :

Sur le premier onglet, renseignez les champs relatifs aux principales caractéristiques de votre VM :

Définissez un compte d’administrateur local, ouvrez le port HTTP pour le traffic entrant, puis cliquez sur Suivant :

Cliquez sur Suivant pour continuer la configuration :

Vérifiez sur cet onglet que le port HTTP est toujours listé, puis cliquez-ici pour lancer la validation de la configuration :

Une fois la validation correctement terminée, cliquez sur Créer :

Environ 3 minutes plus tard, votre machine virtuelle est créée et est accessible.

Cliquez-ici pour rentrer dans la configuration de votre VM :

Copiez l’adresse IP publique de votre machine virtuelle :

Ouvrez un nouvel onglet dans votre navigateur, puis collez l’adresse IP publique précédemment copiée :

Le message d’erreur affiché s’explique par l’absence d’écoute sur le port 80 (HTTP) de votre machine virtuelle.

Pour y remédier, nous allons installer le rôle IIS (Internet Information Services) sur votre machine virtuelle.

Etape II – Installer un rôle IIS sur votre machine virtuelle :

Comme aucun port RDP n’est ouvert sur la machine virtuelle, utilisez le menu suivant pour lancer le script d’installation de IIS depuis le portail Azure :

Collez la commande ci-dessous :

Install-WindowsFeature -name Web-Server -IncludeManagementTools

Lancez le script, puis attendez que celui-ci se termine :

Environ 2 minutes plus tard, constatez la bonne exécution du script :

Dans l’onglet précédemment ouvert avec l’adresse IP publique de votre machine virtuelle, rafraichissez la page web, puis constatez l’apparition de la page d’accueil de IIS :

Notre environnement est maintenant en place, il ne nous reste qu’à installer le mécanisme d’alerte. Avant cela, il est nécessaire d’ajouter d’autres composants Azure.

Etape III – Configuration du test de disponibilité HTTP :

Sur votre portail Azure, commencez par rechercher le service Application Insights :

Créez votre premier application Insights :

Renseignez tous les champs, également ceux concernant la création d’un Log Analytics Workspace, puis lancez la validation :

Une fois validation terminée, lancez le processus de création des ressources :

Environ 3 minutes plus tard, cliquez-ici pour configurer votre Application insights :

Cliquez-ici pour ajouter votre test HTTP :

Renseignez les informations demandées, ainsi que l’adresse IP publique de votre VM au format HTTP://, puis choisissez la fréquence et les régions Azure dont le signal de test doit provenir :

Le test est maintenant en place

Etape IV – Vérification du test de disponibilité HTTP :

Attendez environ 2 minutes, puis cliquez sur Rafraichir :

Les premiers succès de réponse apparaissent :

  • A droite se trouvent des compteurs de succès et d’échecs
  • Le détail par région source est affiché en bas
  • Un graphique avec un taux de disponibilité est présent en haut à gauche

Un tour dans les logs de notre Application Insights affiche bien toutes les informations stockées par chaque test :

Toutes ces informations bien pratiques, mais les administrateurs IT doivent aussi être alertés quand le service HTTP est en panne. Il est donc nécessaire de mettre en place une règle d’alerte pour les avertir au plus tôt.

Un mail sur une messagerie surveillée est une bonne pratique.

Etape V – Configuration des alertes de disponibilité :

Toujours dans votre Application Insights, rendez-vous dans la section des alertes pour modifier la règle d’alerte déjà en place :

Cliquez sur la règle d’alerte portant le nom combo « alerte »-« Application Insight » :

Cliquez ensuite sur Editer :

Sous la section Actions, cliquez-ci dessous :

Cliquez-ici pour créer un groupe d’actions :

Nommez-le, puis passer sur l’onglet suivant :

Dans l’onglet Notifications, définissez un type de notification Email, puis nommez-le également :

Renseignez une adresse email à cibler :

Cliquez sur Créer votre groupe d’actions :

Sauvegardez votre règle d’alerte :

Attendez quelques secondes, puis constatez la bonne modification de celle-ci :

Quelques secondes après, le destinataire du groupe d’actions reçoit un email lui informant son intégration dans un système de règle d’alerte Azure :

Il ne nous reste plus qu’à tester la notification par email. Pour cela, rien de plus simple, un arrêt de la machine virtuelle Azure devrait suffire.

Etape VI – Test de la notification d’alerte :

Avant d’arrêter votre machine virtuelle, vérifier la bonne santé du test de disponibilité de votre HTTP :

Retournez sur la page des machines virtuelles, puis déclenchez un arrêt de celle-ci :

Confirmez la procédure d’arrêt :

Retournez sur l’onglet internet ouvert sur l’adresse IP publique de votre machine virtuelle, puis constatez l’apparition d’un message d’indisponibilité :

Retournez sur le test d’alerte de votre Application Insights, les premiers échecs devraient apparaître.

Notez que la notion de 5 minutes entre deux tests ne s’applique que pour chaque région Azure. C’est donc pour cela que les tests sont très fréquents, car le test de disponibilité repose ici sur 5 régions :

Une fois que 2 localisations sur 5 constatent des échecs, l’alerte est déclenchée et le mail est envoyé sur l’adresse de message renseignée sur le groupe d’actions :

Consultez le détail de cette alerte :

Retournez sur la page des machines virtuelles, puis redémarrez la VM précédemment éteinte :

Quelques minutes plus tard, un autre email arrive sur la boite de messagerie. Celui-ci indique une bonne reprise de la disponibilité sur les régions concernées :

De retour sur la page des alertes de notre Applications Insights, l’alerte n’y figure plus car elle a été automatiquement levée :

Il est malgré tout possible de retrouver l’historique de cette alerte en retirant un filtre :

Conclusion :

L’architecture Cloud n’est pas infaillible et la mise en place d’alerte permet de gérer au plus tôt un incident. Ce type de règle alerte ne coûte pas cher et permet de centraliser l’information sur un seul point. Un autre test intéressant serait de créer une alerte sur la charge d’une machine virtuelle ou d’un autre service de calcul.

Créez vos premières machines virtuelles

Cet article est dans la continuité de l’article dédié à Azure Migrate publié la semaine dernière. Dans celui-ci, je vous propose un second exercice, à pratiquer par vous-même, sur 2 services de calcul Azure : machines virtuelles indépendantes et groupes de machines virtuelles identiques.

Cet atelier va vous aider à comprendre la création de ces deux composants. Dans cet article, l’explicatif n’est pas très détaillé car plusieurs articles sur ce blog en parlent déjà :

Cet exercice est disponible sur la page GitHub de Microsoft juste ici. Voici la liste des tâches que nous allons réaliser :

  • Machine virtuelle :
    • Tâche 1 : Déployer des machines virtuelles (Portail / Template)
    • Tâche 2 : Configurez un rôle IIS (Portail / Script)
    • Tâche 3 : Modifiez la taille et le stockage d’une machine virtuelle
  • Groupe de machines virtuelles identiques :
    • Tâche 4 : Déployez un groupe de machines virtuelles identiques
    • Tâche 5 : Configurez un rôle IIS
    • Tâche 6 : Modifiez la taille de VMs du groupe
    • Tâche 7 : Mise en place d’un plan d’autoscalling

Le schéma ci-dessous correspond aux ressources Azure que nous allons déployer.

Bien souvent, une ressource déployée entraîne un début de tarification par Microsoft. Il est donc important de correctement dimensionner les ressources, et de les supprimer si ces dernières ne sont plus utilisées.

Rappel des prérequis :

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

  • Un tenant Microsoft
  • Une souscription Azure active
  • Compte de stockage pour les scripts

Des scripts en PowerShell seront exécutés durant cet atelier. Commencez par télécharger et extraire les fichiers scripts disponibles sur le GitHub de Microsoft juste ici.

Retournez sur votre portail Azure, puis recherchez le service Compte de stockage Azure :

Commencez la création en remplissant tous les champs nécessaires comme ceci.

Notez que le nom du compte de stockage est unique à travers tout Azure, choisissez un nom au hasard et encore disponible.

Cliquez sur Créer pour commencer le processus de création des ressources :

Attendez que la création du compte de stockage se termine, puis cliquez ici pour le consulter :

Cliquez ici pour ajouter un premier container blob dans votre compte de stockage, puis nommez le Script :

Cliquez sur Téléverser pour ajouter votre premier blob, qui sera un script PowerShell :

Choisissez le fichier script nommé az104-08-install_IIS.ps1, issue de l’archive téléchargée depuis GitHub :

Cliquez sur Téléverser pour lancer l’opération de transfert vers Azure :

La tâche de préparation est maintenant terminée, nous allons pouvoir commencer la création de notre première machine virtuelle Azure.

Tâche I – Déployer des machines virtuelles (Portail / Template) :

Les machines Virtuelles Azure constituent l’un des types de ressources informatiques scalables et à la demande proposées par Azure. En règle générale, une machine virtuelle convient bien si vous avez besoin de davantage de contrôle de votre environnement informatique

Microsoft Learn

Toujours sur votre portail Azure, recherchez le composant Machine Virtuelle :

Remplissez les champs suivants, puis passez sur l’onglet Disques :

Sur cet onglet, laissez les valeurs par défaut et passez directement à l’onglet Réseau :

Modifiez la configuration réseau proposée en cliquant ici :

Remplacez les valeurs par défaut avec les masques de réseau et sous-réseau suivants, puis cliquez sur OK :

Ouvrez le port 80 utilisé pour le protocole HTTP, puis cliquez sur Suivant :

Retirer la case cochée pour éteindre automatiquement la machine virtuelle, changez les mises à jour Windows sur Manuel, puis cliquez sur Suivant :

Choisissez le compte de stockage créé précédemment pour sauvegarder le diagnostic de démarrage de votre machine virtuelle :

Une fois la validation passée, cliquez sur Créer :

Environ 2 minutes plus tard, la première machine virtuelle est créée.

Cliquez sur Template pour comprendre un peu mieux la configuration établie par vous-même :

Cliquez sur Déployer pour réutiliser ce template sur une seconde machine virtuelle :

Changez certaines variables du template afin que la nouvelle machine virtuelle soit créée indépendamment de la première :

  • Nom de l’interface réseau
  • Nom de l’adresse IP publique
  • Nom de la machine virtuelle,
  • Nom de la machine virtuelle1
  • Nom de l’ordinateur de la machine virtuelle
  • Mot de passe administrateur
  • Zone de disponibilité

Attendez que la validation se termine, puis lancez la création de la seconde machine virtuelle en cliquant sur Créer :

Environ deux minutes plus tard, le déploiement est terminé lorsque le message suivant apparaît :

Vos deux machines virtuelles sont maintenant déployées, les tâches suivantes de modification de la configuration seront effectuées directement sur celles-ci.

Tâche II – Configurez un rôle IIS (Portail / Script) :

Toujours sur votre portail Azure, recherchez le composant Machine Virtuelle :

Sélectionner la première machine virtuelle appelée az104-08-vm0 :

Cliquez comme ceci pour ajouter une extension :

Choisissez le type d’extension Script personnalisé, puis cliquez sur Suivant :

Cliquez-ici pour parcourir les fichiers disponibles sur votre compte de stockage :

Choisissez le compte de stockage créé dans l’étape 0, puis reprenez le fichier de script PowerShell téléversé précédemment :

Cliquez-ici pour importer le script en tant qu’extension sur la machine virtuelle :

Validez la configuration de l’extension :

Cliquez ici pour mettre en place l’extension sur la machine virtuelle az104-08-vm0 :

Retournez sur la page principale de la machine virtuelle, puis copiez l’adresse IP publique de celle-ci :

Ouvrez un onglet de votre navigateur, collez l’adresse IP dans la barre d’adresse, puis constatez le court message généré par IIS :

Toujours sur votre portail Azure, retournez sur la liste des machines virtuelles, puis sélectionnez la seconde VM appelée az104-08-vm1.

Dans le menu Exporter le template, cliquez sur la fonction Déployer :

Cliquez ici pour modifier le template précédemment généré :

Recherchez la ligne de 20 du template, puis positionnez votre curseur avant la parenthèse ouvrante :

Collez les lignes de codes ci-dessous

     {
         "type": "Microsoft.Compute/virtualMachines/extensions",
         "name": "az104-08-vm1/customScriptExtension",
         "apiVersion": "2018-06-01",
         "location": "[resourceGroup().location]",
         "dependsOn": [
             "az104-08-vm1"
         ],
         "properties": {
             "publisher": "Microsoft.Compute",
             "type": "CustomScriptExtension",
             "typeHandlerVersion": "1.7",
             "autoUpgradeMinorVersion": true,
             "settings": {
                 "commandToExecute": "powershell.exe Install-WindowsFeature -name Web-Server -IncludeManagementTools && powershell.exe remove-item 'C:\\inetpub\\wwwroot\\iisstart.htm' && powershell.exe Add-Content -Path 'C:\\inetpub\\wwwroot\\iisstart.htm' -Value $('Hello World from ' + $env:computername)"
           }
         }
     },

Une fois les lignes ajoutées, constatez la mise en forme comme l’image ci-dessous, puis cliquez sur Sauvegarder :

Cliquez-ici pour lancer la validation de votre template modifié :

Une fois la validation passée, cliquez sur Créer pour lancer la création des ressources modifiées :

Assez rapidement, le déploiement se termine :

Note : un template peut contenir des ressources Azure déjà existantes. La mise à jour de celles-ci n’intervient que sur les parties modifiées.

Retournez sur la page principale de la machine virtuelle, puis copiez l’adresse IP publique de celle-ci :

Ouvrez un onglet de votre navigateur, collez l’adresse IP dans la barre d’adresse, puis constatez le court message généré par IIS :

Vos deux machines virtuelles sont maintenant en place.

Dans la tâche 3, nous allons voir que d’autres modification de la configuration sont possibles sur les objets rattachés à celles-ci, comme ses disques, ou encore la puissance de la VM.

Tâche III – Modifiez la taille et le stockage d’une machine virtuelle :

Commençons par modifier la taille de la machine virtuelle. Pour cela, retournez sur la machine virtuelle, puis modifiez le SKU comme ceci :

Le redimensionnement occasionne un redémarrage de la machine virtuelle, comptez une minute environ pour retrouver le service opérationnel.

Continuez les modifications en ajoutant deux disques de données de 1024 GiB avec les noms suivants :

  • az104-08-vm0-datadisk-0
  • az104-08-vm0-datadisk-1

L’ajout ou la suppression de disque de données n’occasionne pas de redémarrage de la machine virtuelle.

Terminez les modifications en exécutant un script PowerShell directement sur la machine virtuelle via le portail Azure comme ceci :


New-StoragePool -FriendlyName storagepool1 -StorageSubsystemFriendlyName "Windows Storage*" -PhysicalDisks (Get-PhysicalDisk -CanPool $true)

New-VirtualDisk -StoragePoolFriendlyName storagepool1 -FriendlyName virtualdisk1 -Size 2046GB -ResiliencySettingName Simple -ProvisioningType Fixed

Initialize-Disk -VirtualDisk (Get-VirtualDisk -FriendlyName virtualdisk1)

New-Partition -DiskNumber 4 -UseMaximumSize -DriveLetter Z

Cette commande créée un lecteur Z : composé des deux disques nouvellement attachés :

Le résultat du script correctement exécuté doit ressembler à cela :

Toujours sur votre portail Azure, retournez sur la liste des machines virtuelles, puis sélectionnez la seconde appelée az104-08-vm1.

Dans le menu Exporter le template, cliquez sur la fonction Déployer :

Cliquez ici pour modifier le template précédemment généré :

Recherchez la ligne de 30 du template, puis modifier la valeur correspondante à la taille de la machine virtuelle par celle-ci :

"vmSize": "Standard_DS1_v2"

Recherchez la ligne de 51 du template, puis sélectionnez celle-ci pour la remplacer :

                 "dataDisks": [
                   {
                     "lun": 0,
                     "name": "az104-08-vm1-datadisk0",
                     "diskSizeGB": "1024",
                     "caching": "ReadOnly",
                     "createOption": "Empty"
                   },
                   {
                     "lun": 1,
                     "name": "az104-08-vm1-datadisk1",
                     "diskSizeGB": "1024",
                     "caching": "ReadOnly",
                     "createOption": "Empty"
                   }
                 ]

Une fois les lignes ajoutées, constatez la mise en forme comme l’image ci-dessous, puis cliquez sur Sauvegarder :

Cliquez-ici pour lancer la validation de votre template modifié :

Une fois la validation passée, cliquez sur Créer pour lancer la création des ressources modifiées :

Assez rapidement, le déploiement se termine :

Terminez les modifications en exécutant un script PowerShell directement sur la machine virtuelle via le portail Azure comme ceci :

New-StoragePool -FriendlyName storagepool1 -StorageSubsystemFriendlyName "Windows Storage*" -PhysicalDisks (Get-PhysicalDisk -CanPool $true)

New-VirtualDisk -StoragePoolFriendlyName storagepool1 -FriendlyName virtualdisk1 -Size 2046GB -ResiliencySettingName Simple -ProvisioningType Fixed

Initialize-Disk -VirtualDisk (Get-VirtualDisk -FriendlyName virtualdisk1)

New-Partition -DiskNumber 4 -UseMaximumSize -DriveLetter Z

Cette commande créée un lecteur Z : composé des deux disques nouvellement attachés :

Le résultat du script correctement exécuté doit ressembler à cela :

La première partie de cet atelier nous a permis de tester le déploiement de machines virtuelles via l’interface graphique du portail Azure, mais aussi par l’utilisation de scripts et de templates.

Cette seconde approche est intéressante pour l’automatisation des déploiements et évite des erreurs humaines dans la configuration manuelle de chaque composant.

Tâche IV – Déployez un groupe de machines virtuelles identiques :

Les groupes de machines virtuelles identiques Azure (ou Virtual Machine Scale Sets) vous permettent de créer et de gérer un groupe de machines virtuelles à charge équilibrée. Le nombre d’instances de machine virtuelle peut augmenter ou diminuer automatiquement en fonction d’une demande ou d’un calendrier défini.

Microsoft Doc

Sur votre portail Azure, recherchez le composant Groupe de machines virtuelles identiques :

Cliquez sur Créer :

Utilisez le même groupe de ressources que pour les tâches précédentes, puis nommez le groupe de machines virtuelles identique az10408vmss0 :

Remplissez les champs suivants, puis passez sur l’onglet Disques :

Sur l’onglet Disques, laissez les valeurs par défaut et passez directement à l’onglet Réseau.

Modifiez la configuration réseau proposée par défaut en cliquant ici :

Remplacez les valeurs par défaut avec les masques de réseau et sous-réseau suivants, puis cliquez sur OK :

Cliquez ici pour créer et personnaliser le Groupe de sécurité réseau (NSG) :

Ajoutez une seconde règle de traffic entrant :

Choisissez le service HTTP et nommez là custom-allow-http, puis cliquez sur Ajouter :

Cliquez sur OK pour valider la configuration de votre futur NSG :

Activez la création d’une adresse IP publique :

Cochez la case pour mettre en place un équilibreur de charge, puis passer à l’onglet Mise à l’échelle :

Indiquez à 2 le nombre initial d’instances puis passer à l’onglet suivant :

Choisissez le compte de stockage créé précédemment pour sauvegarder le diagnostic de votre groupe de machines virtuelles identiques, puis passez à l’onglet suivant :

Sur cet onglet, laissez les valeurs par défaut, puis passez directement à l’onglet Avancé:

Modifiez l’algorithme de diffusion utilisé, puis lancez la validation :

Une fois la validation passée, cliquez sur Créer :

Environ 2 minutes plus tard, le groupe de machines virtuelles identiques est créé :

Tâche V – Configurez un rôle IIS :

Comme pour les machines virtuelles indépendantes, cliquez comme ceci pour ajouter une extension :

Choisissez le type d’extension Script personnalisé, puis cliquez sur Suivant :

Choisissez le compte de stockage créé, puis reprenez le fichier de script PowerShell téléversé précédemment :

Retournez sur la page principale du groupe de machines virtuelles identiques, puis copiez l’adresse IP publique de celui-ci :

Ouvrez un onglet de votre navigateur, collez l’adresse IP dans la barre d’adresse puis constater le message d’erreur :

Pour remédier à cela, il est nécessaire de mettre à jour les machines virtuelles en place :

Attendez quelques minutes, puis rafraichissez la page de votre navigateur internet :

Tâche VI : Modifiez la taille de VMs du groupe :

Toujours sur votre groupe de machines virtuelles identiques, modifiez le SKU comme ceci :

Là encore, il est nécessaire de mettre à jour les machines virtuelles déjà en place :

Un clic sur une machine affiche bien la nouvelle taille :

Tâche VII – Mise en place d’un plan d’autoscalling :

Dans cette tâche, vous allez configurer un plan de mise à l’échelle du groupe de machines virtuelles identiques.

Pour cela, rendez-vous dans le menu suivant pour le mettre en place selon vos propres règles, puis ajoutez une première règle de mise à l’échelle :

Dans celle-ci, définissez la métrique utilisée pour votre mise à l’échelle, indiquez la valeur limite, puis cliquez sur OK :

Ajoutez une seconde règle de mise à l’échelle avec la même métrique utilisée, indiquez la même valeur limite, puis cliquez sur OK :

Indiquez les limites basses et hautes du nombre d’instances, puis sauvegardez votre plan de mise à l’échelle :

Constatez la suppression de la seconde instance créée précédemment :

Sur votre poste local, copiez le script ci-dessous en adaptant l’adresse IP publique nom du groupe de machines virtuelles :

$url = "http://20.203.242.169"
while ($true) {
try {
[net.httpWebRequest]
$req = [net.webRequest]::create($url)
$req.method = "GET"
$req.ContentType = "application/x-www-form-urlencoded"
$req.TimeOut = 60000

$start = get-date
[net.httpWebResponse] $res = $req.getResponse()
$timetaken = ((get-date) - $start).TotalMilliseconds

Write-Output $res.Content
Write-Output ("{0} {1} {2}" -f (get-date), $res.StatusCode.value__, $timetaken)
$req = $null
$res.Close()
$res = $null
} catch [Exception] {
Write-Output ("{0} {1}" -f (get-date), $_.ToString())
}
$req = $null

# uncomment the line below and change the wait time to add a pause between requests
#Start-Sleep -Seconds 1
}

Lancez le script PowerShell (une bonne dizaine de fois) sur votre poste et laissez-les tourner :

Constatez la création d’une seconde instance, voire d’une troisième :

Conclusion :

Dans cet atelier, vous avez :

  • Déployé des machines virtuelles en zone en utilisant le portail Azure et un template ARM
  • Configuré des machines virtuelles Azure en utilisant des extensions de machine virtuelle
  • Modifié la taille et le stockage pour les machines virtuelles Azure
  • Déployé un groupe de machines virtuelles Azure
  • Configuré le groupe de machines virtuelles en utilisant des extensions
  • Testé le plan de mise à l’échelle

J’espère que toutes opérations vous auront montré la facilité de déploiement à travers Azure. Enfin, pensez à supprimer les ressources une fois cet atelier terminé afin d’éviter les surcoûts :

Suppression des ressources Azure :

Machine Virtuelle Azure en IPv6

Il arrive par moment que l’on ait besoin de travailler en IPv6. Pourquoi faire ? Par exemple : tester le bon accès d’un autre composant en IPv6 ???? Ceci est effectivement mon cas : ce blog dédié à Azure est hébergé sur Azure via un App Service, fonctionnant en 2023 encore et toujours … en IPv4. Comme certains fournisseurs d’accès internet ont entièrement basculé sur le protocole IPv6, il est nécessaire de trouver une parade pour rendre le site accessible à tous.

Pourquoi faire un article dédié à l’IPv6 sur Azure ?

Comme il arrive que le blog par moment ne soit plus accessible en IPv6, il peut s’écouler pas mal de temps avant que je m’en rende compte. Cet écueil serait sans doute identifié plus rapidement si le site croulait sous l’audience ????.

Pour m’aider, il existe certains sites spécialisés dans l’affichage en IPv4 / IPv6, mais le résultat n’est pas toujours garantie.

Comment rendre un site hébergé sur Azure Web App compatible IPv6 ?

Plusieurs auteurs ont déjà trouvé une parade avant moi, comme Patrickob Blog, ou via un article rédigé sur la Tech Community de Microsoft : l’ajout du service Azure Front Door permet de disposer d’une adresse IPv6 frontale, cela redirige le flux de requêtes vers l’App Service :

Tout cela est possible grâce à l’ajout d’un enregistrement DNS de type CNAME pointant vers le nom d’hôte de votre service Azure Front Door : xxxxxx.azurefd.net.

Il est aussi possible d’utiliser uniquement un enregistrement DNS de type AAAA, pointant vers l’IPv6 de votre service Azure Front Door :

La configuration entre Azure Front Door et Azure App Service est par la suite assez facile :

Dans cet article, nous allons créer une machine virtuelle Azure afin de se connecter à l’App Service, par le biais d’Azure Front Door, et tout cela en IPv6.

Comme le rappelle Microsoft :

  • L’IPv6 apporte une sécurisation par défaut dans la mesure où la connectivité IPv6 à Internet n’est établie que lorsque vous le demandez explicitement dans votre déploiement.
  • L’utilisation d’adresses IPv6 publiques ou de préfixes IPv6 publics n’est pas facturée.
  • La bande passante associées sont facturées au même tarif que le protocole IPv4.

Avant de commencer notre démonstration, quelques rappels sont importants :

  • Les machines virtuelles uniquement IPv6 ne sont pas pris en charge, chaque carte réseau doit inclure au moins une configuration IPv4.
  • Il en est de même pour les réseaux virtuels Azure et ses sous-réseaux. Ils ne peuvent disposer d’une IPv6 uniquement, mais bien d’un double adressage IPv4 / IPv6.

Etape 0 – Rappel des prérequis :

Des prérequis sont nécessaires pour réaliser ce test sur un environnement Azure :

  • Un tenant Microsoft
  • Une souscription Azure valide

Etape I – Déploiement du Réseau Virtuel Azure :

Commencez par créer un réseau virtuel :

Cochez la case suivante dédiée à l’IPv6, puis ajoutez un plan d0adressage en IPv6 à votre sous-réseau :

Lancez la validation, puis la création :

Attendez la création de votre réseau virtuel pour passer à l’étape suivante :

Un fois le réseau virtuel IPv4 / IPv6 correctement déployé, l’étape suivante consistera à créer une machine virtuelle avec une seule carte réseau sur ce réseau virtuel hybride.

Etape II – Création de la Machine Virtuelle Azure :

Commencez la création de votre machine virtuelle :

Dans l’onglet Réseau, choisissez le sous-réseau comprenant le double adressage IPv4 / IPv6, mais retirez la création de l’IP publique, par défaut prévue en IPv4 :

Lancez la validation, puis la création de votre machine virtuelle :

Attendez la fin de la création de votre machine virtuelle pour passer à l’étape suivante :

L’étape suivante consistera à ajouter une IP publique, mais uniquement sous format IPv6.

Etape III – Déploiement de l’IP publique en IPv6 :

Retournez sur la carte réseau de votre machine virtuelle :

Ajoutez une seconde configuration suivante :

Cliquez sur OK et attendez que la configuration se termine :

Retournez sur la page principale de votre machine virtuelle et constatez l’apparition d’une adresse IPv6 publique seule :

Etape IV – Connexion à la machine virtuelle IPv6 :

Connectez-vous à votre machine virtuelle via le protocole RDP :

Si comme moi vous rencontrez le message d’erreur suivant :

Déployez le service Azure Bastion comme ceci :

Renseignez les champs suivants :

Lancez sa validation, puis sa création :

Attendez la fin de la création d’Azure Bastion :

Connectez-vous à votre machine virtuelle via Azure Bastion nouvellement déployé :

Etape V – Tests IPv6 :

Une fois connecté, ouvrez la configuration IP et constatez la présence d’adresse IP locales en IPv4 et IPv6 :

Ouvrez également Edge et tester les informations réseaux internet depuis un des sites suivants :

Constatez la présence unique de l’IPv6 :

Testez le bon fonctionnement de l’IPv6 du site internet hébergé par l’App Service Azure via le nom de domaine :

Mais aussi via le nom de votre Azure Front Door :

Etape VI – Tests IPv6 d’Azure Front Door :

Afin de vérifier que la connexion entre la machine virtuelle et Azure Front Door s’opère bien uniquement sous le protocole IPv6, il est très facile de désactiver la route de ce dernier comme ceci :

Quelques secondes et un rafraîchissement web plus tard, le status de la route vers l’App Service change de couleur :

Réactualisez la page de votre site de test depuis votre machine virtuelle de test pour constater l’erreur :

Pensez à réactiver la route de votre service Azure Front Door.

Conclusion

Azure a encore du chemin à faire concernant l’implémentation générale de l’IPv6 au sein de l’ensemble de ses services. Nul doute que cela va arriver, mais on peut raisonnablement se demander exactement quand, car l’attente commence à se faire longueeeeeeeeeeeee ????.

Endormez vos VMs AVD inutilisées

Azure Virtual Desktop propose deux types d’environnement virtualisé en fonction des usages attendus. Voici une méthode simple de les différencier :

  • Environnement partagé : plusieurs utilisateurs sur une machine virtuelle
  • Environnement individuel : un utilisateur par machine virtuelle

Seulement ces types d’environnement ne conviennent pas à tous les usages. Par exemple, des besoins variés entre les utilisateurs, des droits d’administrateurs ou encore une fréquence d’utilisation ponctuelle d’Azure Virtual Desktop correspondent plus à un environnement AVD individuel.

Dans cet article, nous allons justement nous intéresser aux environnements AVD individuels. La configuration de ces machines mono-utilisateur permet de diminuer les coûts quand ces dernières sont uniquement démarrées si leur utilisateur a en réellement besoin.

Justement, que propose Azure pour allumer et éteindre les machines AVD ?

Pour les environnements AVD partagés, le démarrage et l’arrêt des machines virtuelles est configurable dynamiquement grâce à la nouvelle fonction d’autoscalling : un article est déjà disponible sur ce blog juste ici.

En quelques mots, la fonction de mise à l’échelle automatique (autoscalling) vous permet de démarrer des machines virtuelles Azure Virtual Desktop, en modulant à la hausse ou à la baisse leur nombre selon les besoins à l’instant T.

Est-ce aussi compatible pour les environnements AVD individuels ?

Oui pour le démarrage des machines virtuelle. Appelé démarrage à la demande, sa mise en place est très simple. Un autre article de ce blog en parle juste ici.

En quelques mots, l’utilisateur se connecte et attend quelques minutes, si la machine est éteinte, le temps qu’Azure démarre sa machine virtuelle AVD. Voici également une vidéo de Dean qui en parle très bien :

Quand s’éteindra alors sa machine individuelle AVD ?

Concernant l’arrêt de sa machine virtuelle individuelle AVD, il n’existe pas encore d’option native qui agit dynamiquement. Par défaut, l’arrêt d’une machine virtuelle Azure est :

  • Manuel : réalisé par script ou depuis le portail Azure.
  • Programmé : via la fonction auto-shutdown, configurable individuellement sur chaque VM.

Cette seconde option pose un souci dans un environnement AVD : l’absence de corrélation entre un auto-shutdown à heure fixe durant l’utilisation d’AVD risque de déconnecter à tort des utilisateurs.

Est-il envisageable de laisser l’utilisateur éteindre sa propre machine virtuelle ?

Cela vous oblige à lui donner des droits sur une ressource Azure : sa machine virtuelle.

Que peut-on faire pour gérer dynamiquement l’arrêt des machines virtuelles individuelles AVD ?

Azure est une chose flexible ! Une combinaison de services est possible pour arriver à cet objectif. Soyons clair, je n’ai rien trouvé n’y inventé, mais je me suis appuyé sur cette excellente documentation Microsoft.

Comme le montre le schéma ci-dessous, différentes étapes sont présents pour arriver à l’arrêt complet du service Azure :

  • Premier déclencheur = déconnecte l’utilisateur inactif
  • Second déclencheur = éteint l’OS de la machine virtuelle
  • Troisième déclencheur = désalloue la ressource Azure
Un mécanisme anticipe le retour de l’utilisateur avant l’arrêt de l’OS.

Différents composants sont nécessaires pour réaliser toutes ces étapes :

  • Ressources Azure :
    • Automation Account / Runbook / Identité managé
    • Alertes journalisées / Groupe d’action
  • Ressources Windows :
    • GPOs ou Polices locales
    • Tâches planifiées
    • Scripts

Etape 0 – Rappel des prérequis :

Des prérequis sont nécessaires pour réaliser ce test sur un environnement individuel AVD :

  • Un tenant Microsoft
  • Une souscription Azure valide

Etape I – Déploiement de l’environnement AVD :

Pour déployer rapidement un environnement AVD joint à Azure AD, déployez un réseau virtuel Azure :

Continuez en déployant un environnement individuel AVD :

Ajoutez une ou plusieurs machines virtuelles pour les tests :

Renseignez les informations de réseau et un identifiant / mot de passe pour l’administrateur local :

Créez votre espace de travail AVD :

Une fois validation terminée, lancez la création des ressources Azure Virtual Desktop :

Attendez que le déploiement de votre AVD se termine :

Etape III – Finalisation de la configuration initiale :

Quelques opérations sont nécessaires pour finaliser l’installation de l’environnement AVD.

Ajoutez les 3 rôles Azure RBAC suivants sur votre groupe de ressources AVD :

  • Contributeur à la mise en route de la virtualisation des postes de travail : permet à l’application AVD de démarrer une machine virtuelle éteinte.
  • Utilisateur de la virtualisation du poste de travail : assigne l’utilisateur au groupe d’applications AVD.
  • Connexion de l’administrateur de la machine virtuelle : autorise l’utilisateur à se connecter à distance sur sa machine virtuelle avec les droits d’administrateur local.

Activez cette option pour mettre en route la fonction d’authentification SSO entre Azure AD la machine virtuelle AVD (expliquée juste ici) :

Activez la fonction de démarrage à la demande (expliquée juste ici et documentée officiellement là) :

Assignez votre utilisateur AVD de test à une des machines virtuelles :

Etape IV – Test de l’environnement AVD :

Avant de déployer la solution de configuration d’arrêt dynamique, testez le bon fonctionnement de l’accès à votre environnement AVD avec votre utilisateur de test.

Depuis votre poste local, connectez-vous à l’URL suivante, puis renseignez vos identifiants :

Ouvrez la session de bureau à distance AVD :

Acceptez la fin de la configuration SSO :

Attendez que la session Windows s’ouvre :

Une fois connecté, fermez la session utilisateur :

Depuis votre portail Azure, éteignez la machine virtuelle AVD :

Relancez la même connexion AVD depuis la page web de votre utilisateur de test :

Constatez la présence du message du démarrage de la machine virtuelle, vous invitant à patienter :

Attendez quelques minutes et constatez l’ouverture de la session Windows AVD :

Si tout fonctionne correctement pour vous, continuez la suite de cet article pour configurer l’arrêt dynamique AVD.

Etape V – Configuration des composants Azure

Pour cela, créez un compte Azure Automation :

Une fois la validation terminée, lancez sa création :

Une fois la ressource créée, allez dans le service appelé Azure Monitor :

Ajoutez une Règle d’alerte d’état de santé comme ceci :

Cochez uniquement les 4 conditions suivantes de cette façon :

Créez un nouveau Groupe d’action :

Rattachez le Groupe d’action à votre compte Azure Automation précédemment créé :

Lancez la création de votre Groupe d’action :

Nommez votre Règle d’alerte :

Lancez la création de votre Règle d’alerte :

L’étape suivante concerne maintenant la configuration Windows des machines virtuelles AVD. Il est possible de l’établir cela par :

  • des Polices locales sur chaque VM AVD
  • des GPOs créées sur un Active Directory

N’ayant pas d’Active Directory dans mon environnement de test, nous allons créer des polices locales sur la machine AVD de test. C’est aussi votre cas si les machines virtuelles AVD sont jointes à Azure AD.

Etape VI – Configuration des composants Windows

Comme votre utilisateur de test est considéré comme un administrateur local, ouvrez le Planificateur de tâche Windows depuis le menu Démarrer :

Créez une nouvelle Tâche planifiée :

Nommez la Tâche planifiée, puis cochez les cases suivantes :

Ajoutez un déclencheur sur le second onglet :

Choisissez le motif de déconnexion avec un délai de 30 minutes :

Sur l’onglet des actions, ajoutez le lancement du programme Shutdown avec les arguments suivants:

/f /s /t 0

Validez la création de la Tâche planifiée, puis lancez la création d’une seconde Tâche planifiée :

Choisissez le démarrage de la Tâche planifiée avec l’ouverture d’une session utilisateur :

Sur la VM AVD, créez un nouveau fichier texte avec les lignes ci-dessous :

@echo off
schtasks /change /tn  Deconnexion /disable
schtasks /change /tn  Deconnexion /enable
exit

Enregistrez-le sous le nom reset.cmd dans le dossier C:\Windows\System32 :

Appelez-le dans l’action de la Tâche planifiée :

Validez la création de la Tâche planifiée :

Ouvrez le Gestionnaire de police locale :

Naviguez dans l’arborescence suivante :

  • Configuration utilisateur
    • Paramètres Windows
      • Scripts (Logon/Logoff)

Cliquez sur le script suivant :

Cliquez sur Ajouter :

Ajoutez le nom de script suivant :

C:\Windows\System32\tsdiscon.exe

Validez ce script en cliquant sur OK :

Toujours dans le Gestionnaire de police locale, naviguez dans la seconde arborescence suivante :

  • Configuration utilisateur
    • Modèle administratif
      • Composants Windows
        • Services de bureau à distance
          • Hôte de session de bureau à distance
            • Limite de temp de session

Cliquez sur la configuration suivante :

Configurez comme ceci, puis validez vos modifications :

Etape VII – Test de la configuration

Il ne reste qu’à tester tout ça. Voici un rappel des temps de phase configurés :

Avant la première authentification de mon utilisateur AVD, la VM qui lui est attitrée est désallouée, comme le montre le portail Azure ci-dessous :

Je connecte mon utilisateur de test au bureau AVD. Comme sa machine virtuelle est en statut désalloué, je dois attendre quelques minutes pour accéder à son bureau Windows :

Quelques minutes plus tard, la session Windows s’ouvre sans autre action de sa part ni de la mienne :

Le statut de la machine virtuelle AVD a lui aussi changé dans Azure :

Son horloge Windows indique 19:31, j’attends donc les 30 minutes nécessaires, sans effectuer aucune activité sur la session AVD. Environ 30 minutes plus tard, le message suivant apparaît sur sa session AVD :

Si rien n’est fait pendant ces deux minutes, la suite logique est la déconnexion de cet utilisateur :

A ce moment-là, Le portail Azure nous affiche que la machine virtuelle est toujours bien fonctionnelle :

Par contre, AVD reconnait bien que sa session AVD est bien en statut déconnecté :

Environ 30 minutes après la déconnexion de l’utilisateur de test, sa machine virtuelle AVD passe en statut arrêté :

La machine virtuelle devient alors indisponible pour le service AVD :

Environ 5 minutes plus tard , la machine virtuelle passe en statut désalloué :

Une nouvelle tentative d’ouverture AVD depuis le portail utilisateur relancera le démarrage de sa machine virtuelle :

Conclusion

La mise en place de la configuration de déconnexion des sessions inactives fonctionne très bien dans les environnements individuels d’Azure Virtual Desktop. Cette approche va sans nul doute diminuer les coûts liés au Cloud pour des besoins spécifiques et/ou périodiques, sans avoir à se soucier du démarrage et de l’arrêt des machines virtuelles individuelles.

Il sera même intéressant de combiner cette approche avec des instances réservées. Le nombre d’instances réservées approprié dépendra du plancher constant d’utilisateurs AVD connectés.

Que valent les disques Azure ?

Microsoft vient d’annoncer il y quelques jours la disponibilité générale des disques Ultra dans plusieurs régions Azure, dont Suisse Nord. Depuis quelques mois déjà, un nouveau type de disque, appelé Premium SSD v2, a également fait son apparition sur Azure.

Au total, 5 types de disque managé sont disponibles pour les machines virtuelles Azure. SLA, IOPS, débit, taille, région ou encore sauvegarde sont quelques-uns des paramètres à prendre en compte lors de ce choix.

Dans cet article, nous allons aborder quelques points définissant les différents types de disque Azure, et nous ferons également quelques tests de performances IOPS et Débit. Durant mes tests, j’ai relevé des valeurs de latence très hautes. Je ne pense pas qu’elles représentent la réalité, et c’est pour cela qu’elles vous seront affichées mais pas commentées.

Compte-tenu de mes possibilités, à l’heure où ces lignes sont écrites, les tests ne porteront que sur les 4 types de disque suivants :

  • Premium SSD
  • Standard SSD
  • Standard HDD
  • Ultra disk

A quoi correspondent les IOPS d’un disque ?

IOPS (input/output operations per second en anglais, opérations d’entrée-sortie par seconde) est une unité de mesure commune en informatique. Elle est utilisée dans les tests de performance de supports de stockage tels les disques durs (HDD), solid-state drives (SSD) et réseaux de stockage SAN.

Wikipédia

Une courte vidéo de John vaut mieux qu’un long discours ???? :

A quoi correspond le débit d’un disque ?

Taux de transfert (ou débit) : quantité de données pouvant être lues ou écrites sur le disque par unité de temps. Il s’exprime en bits par seconde.

CommentCaMarche.net

Merci encore une fois à John pour ses vidéos :

Quelles sont les tailles disponibles pour un disque Azure ?

Azure vous propose de créer des disques très petits ou très grands. La plupart des types de disque peuvent aller jusqu’à 64 Tio :

Quels sont les coûts d’un disque Azure ?

Il existe deux principaux coûts aux disques managés d’Azure. La taille du disque et les transactions influent sur le montant mensuel :

  • Taille du disque : Un disque managé Azure est facturé toutes les heures au niveau supérieur le plus proche de sa taille. Autrement dit, un disque de 120 Go coûte autant qu’un disque de 128 Go, que la machine virtuelle soit allumée ou non.
  • Transaction : Sont appelées transaction, les lectures, les écritures, … effectuées par le disque, elles sont facturées par paquet de 10 000 transactions. Certains types de disque, comme les disques Premium ou Ultra, incluent le coût des transactions dans leur tarification les coûts sont alors plus prévisibles et mieux maîtrisés.

Voici une brève comparaison tarifaire pour un disque de 128 Go en Europe de l’Ouest, selon Azure Pricing Calculator :

  • Premium SSD : 20.13 CHF / mois
  • Premium SSD v2 : 11.49 CHF / mois
  • Standard SSD : 12.63 CHF / mois
  • Standard HDD : 6.39 CHF / mois
  • Ultra disk : 88.73 CHF / mois

Pourquoi le type de disque influe sur la SLA d’une machine virtuelle Azure ?

Azure est découpé en centaines de services. Chaque service dispose de sa propre SLA, elle-même calculée selon des paramètres précis.

Certains services proposent différents niveaux de performances et de fonctionnalités. Ces changement influent souvent sur l’architecture ou les composants physiques. Cela joue naturellement sur la SLA. Microsoft met à disposition une liste des SLA par service, régulièrement mise à jour.

Derrière chaque disque d’Azure se trouve une technologie de stockage. Microsoft se base donc sur cette SLA pour calculer la SLA de la machine virtuelle :

Quel scénario pour quel type de disque ?

Le coût du disque reste un facteur important pour une machine virtuelle. Néanmoins, Microsoft conseille un ou plusieurs types de disque, selon le rôle que celle-ci doit jouer :

Pourquoi les machines virtuelles Azure ont-elles un maximum d’IOPS ?

Quand vous sélectionnez une taille de machine virtuelle lors de sa création, une colonne concerne la performance des disques et doit attirer votre attention :

Les machines virtuelles d’Azure ont donc elles aussi un plafond IOPS :

Ce nombre maximal d’IOPS ne garantit en rien la performance de vos disques rattachés, mais agira en goulet d’étranglement si la puissance demandée par vos disques est supérieure à cette limite :

Etape 0 – Rappel des prérequis :

Peu de prérequis sont nécessaires pour réaliser les tests de performances des disques Azure :

  • Un tenant Microsoft
  • Une souscription Azure valide

Dans cet article, nous allons déployer une machine virtuelle Azure, avec différents types de disque. Cela nous permettra de comparer leurs performances.

Etape I : Enregistrement de la souscription Azure :

Tous les types de disque sont accessibles, à l’exception du nouveau type de disque Premium SSD v2. A l’heure où ces lignes sont écrites, un enrôlement de votre souscription Azure est encore nécessaire pour déployer ces derniers.

Cliquez-ici pour accéder au formulaire Microsoft :

Une fois le formulaire rempli, il ne vous restera qu’à attendre un retour de la part de Microsoft pour tester ce nouveau type de disque.

En attendant, rien ne vous empêche de continuer les étapes de cet article pour tester les autres types.

Etape II : Déploiement de la machine virtuelle Azure

Afin de tester différents types de disque, j’ai déployé une seule machine virtuelle sur Windows Server. J’ai choisi une machine virtuelle de type D8s v5 pour disposer de :

  • Une puissance de calcul CPU suffisante
  • Un nombre maximal d’IOPS élevé
  • Une limitation haute pour le nombre maximal de disques de données

Dans l’onglet des disques :

  • Pensez à cocher la case de comptabilité Ultra disque.
  • Pour les tests, tous les disques ont une taille proche pour comparer des performances de même tranche.
  • Quelques gigas seulement les séparent pour les identifier plus facilement par leur taille.
  • J’ai ajouté un second disque type Premium SSD, de plus grande capacité que les autres, pour mesurer l’impact sur les performances selon la taille.
J’ai aussi retiré le cache d’hôte pour ne pas avoir de variation de résultats.

Retirez l’adresse IP publique si vous utilisez comme moi le service Azure Bastion :

Quand la validation est réussie, lancez le déploiement de votre machine virtuelle de test :

Une fois le déploiement terminé, cliquez ici pour consulter votre machine virtuelle :

Configurez au besoin les performances de votre Ultra disk :

J’ai configuré ces valeurs pour tester les limites liées à ma machine virtuelles. Attention à la consommation Azure qui peut s’envoler très vite ???????? :

Déployez également le service Azure Bastion pour vous y connecter plus facilement :

Attendez quelques minutes la fin du déploiement d’Azure Bastion, puis connectez-vous à votre machine virtuelle de test avec le compte d’un administrateur local :

Etape III – Configurations des disques de données :

Une fois connecté à votre session à distance, ouvrez le gestionnaire de disque Windows :

Le gestionnaire de disque Windows vous propose automatiquement de lancer l’initialisation des disques de données ajoutés, cliquez sur OK :


Ajoutez un volume simple sur chacun des disques ajoutés :

Conservez toutes les options de bases pour chaque volume créé :

Contrôlez la présence des 5 partitions dans l’explorateur de fichier, renommez-les au besoin :

Etape IV – Installation de l’outil de mesure Diskspd :

DISKSPD est un outil que vous pouvez personnaliser pour créer vos propres charges de travail synthétiques. Nous utiliserons la même configuration que celle décrite ci-dessus pour exécuter des tests d’évaluation. Vous pouvez modifier les spécifications pour tester différentes charges de travail.

Microsoft Learn

Microsoft recommande d’utiliser l’utilitaire DiskSpd (https://aka.ms/diskspd) pour générer une charge sur un système de disques (stockage) et … pour mesurer les performances du stockage et obtenir la vitesse maximale disponible en lecture/écriture et les IOPS du serveur spécifique.

Windows OS Hub

Sur votre machine virtuelle de test, téléchargez l’exécutable via ce lien Microsoft, puis ouvrez l’archive ZIP téléchargée :

Copiez le contenu de l’archive dans un nouveau dossier créé sur le disque C :

L’exécutable se trouve dans le sous-dossier amd64 :

Les 2 étapes suivantes sont dédiées aux tests de performances des disques via l’application Diskspd. Microsoft met d’ailleurs à disposition un protocole similaire de tests juste ici :

  • Deux séries de tests sont conseillées pour exploiter le meilleur des deux caractéristiques :
    • IOPS
    • Débit
  • Le changement entre ces deux séries se fera au niveau de la taille des blocs.

Etape V – Tests des IOPS des disques Azure :

Commencez une première salve de tests pour déterminer les IOPS maximums sur chacun des disques.

Ouvrez le programme de ligne de commande, puis positionnez-vous dans le dossier de l’exécutable Diskspd :

Lancez les commandes des test suivantes, une à une ou à la chaîne, en modifiant les paramètres si besoin :

diskspd.exe –c50G -d120 -r -w100 -F4 -o128 -b8K -Sh -L E:\diskpsdtmp.dat > IOPS-PremiumSSD.txt
diskspd.exe –c50G -d120 -r -w100 -F4 -o128 -b8K -Sh -L F:\diskpsdtmp.dat > IOPS-StandardSSD.txt
diskspd.exe –c50G -d120 -r -w100 -F4 -o128 -b8K -Sh -L G:\diskpsdtmp.dat > IOPS-StandardHDD.txt
diskspd.exe –c50G -d120 -r -w100 -F4 -o128 -b8K -Sh -L H:\diskpsdtmp.dat > IOPS-PremiumSSD1024.txt
diskspd.exe –c50G -d120 -r -w100 -F4 -o128 -b8K -Sh -L I:\diskpsdtmp.dat > IOPS-UltraDisk.txt

Les arguments utilisés pour diskspd.exe sont les suivants :

  • -c50G : taille du fichier 50 GB (il est préférable d’utiliser une taille de fichier importante pour qu’il ne parte pas dans le cache du contrôleur de stockage)
  • -d120 : durée du test en secondes
  • -r : opérations de lecture/écriture aléatoires
  • -w100 : rapport entre les opérations d’écriture et de lecture 100%/0%
  • -F4 : nombre de threads max
  • -o128 : longueur de la file d’attente
  • -b8K : taille du bloc
  • -Sh : ne pas utiliser le cache
  • -L : mesure de la latence
  • E:\diskpsdtmp.dat : chemin du fichier généré pour le test
  • > IOPS-PremiumSSD.txt : fichier de sortie des résultats

En attendant la fin du traitement, ouvrez Resource Monitor et constatez la charge maximale du disque :

Une fois tous les tests terminés, retrouvez les fichiers des résultats dans le même dossier que l’exécutable :

Ouvrez chacun des fichiers de résultats, puis descendez au paragraphe suivant :

Pour plus de clarté, j’ai synthétisé tous mes résultats IOPS dans le tableau ci-dessous :

Etape VI – Tests débits des disques :

Continuez avec une seconde salve de tests pour mesurer les débits maximums des types de disque Azure.

Ouvrez le programme de ligne de commande si vous l’aviez fermé, puis repositionnez-vous dans le dossier de l’exécutable Diskspd :

Lancez les commandes de tests suivantes, une à une ou à la chaîne, en modifiant leurs paramètres si besoin :

diskspd.exe –c50G -d120 -r -w100 -F4 -o128 -b64K -Sh -L E:\diskpsdtmp.dat > Throughput-PremiumSSD.txt
diskspd.exe –c50G -d120 -r -w100 -F4 -o128 -b64K -Sh -L F:\diskpsdtmp.dat > Throughput-StandardSSD.txt
diskspd.exe –c50G -d120 -r -w100 -F4 -o128 -b64K -Sh -L G:\diskpsdtmp.dat > Throughput-StandardHDD.txt
diskspd.exe –c50G -d120 -r -w100 -F4 -o128 -b64K -Sh -L H:\diskpsdtmp.dat > Throughput-PremiumSSD1024.txt
diskspd.exe –c50G -d120 -r -w100 -F4 -o128 -b64K -Sh -L I:\diskpsdtmp.dat > Throughput-UltraDisk.txt

Les deux paramètres ayant changés rapport aux commandes de test IOPS sont :

  • -b8K : taille du bloc
  • > Throughput-PremiumSSD.txt : fichier de sortie des résultats

Une fois les tests débits terminés, retrouvez les fichiers dans le même dossier que les IOPS :

Ouvrez chacun des fichiers de résultats de débits et compilez-les dans un tableau :

Etape VII – Analyse des résultats IOPS / Débits :

Après analyse des résultats de chaque type de disque, comparez-les à la documentation Microsoft : on retrouve bien des valeurs approchantes pour les IOPS et les débits. Voici quelques explications :

Premium SSD :

  • Premium SSD P10 : 3548 IOPS – 162 Mio/sec
  • Premium SSD P30 : 5099 IOPS – 194 Mio/sec

Le nombre d’IOPS et le débit garantit augmentent par parlier, en rapport avec la taille du disque.

  • A partir de 4 Gio et jusqu’à 512 Gio, le mode Burst est disponible et s’active automatiquement selon la charge, comme le montre le test réalisé.
  • A partir de 1024 Gio, les performances de base sont bien meilleures, mais le mode Burst s’active uniquement sur demande.

Voici d’ailleurs l’excellente vidéo de John sur le fonctionnement du mode Burst dans le temps :

Durant le premier test, le disque Premium SSD d’1 Tio n’a pas utilisé le mode Burst et est resté aux alentours de 5000 IOPS et 200 Mio/sec, soit les valeurs provisionnées sur un disque P30.

L’activation du burst à la demande doit se faire sur le disque, uniquement lorsque ce dernier est détaché ou quand la machine virtuelle est désallouée, donc éteinte.

Pour effectuer un test de burst sur le disque P30, éteignez votre machine virtuelle et cochez la case suivante sur le disque, puis rallumez-là :

Voici les résultats IOPS / débits du disque Premium SSD d’un 1 Tio avec le mode burst à la demande :

  • Premium SSD P30 + Burst : 19321 IOPS – 967 Mio/sec

Le test de débit est bon, mais la valeur IOPS aurait dû se rapprocher des 30 000 IOPS. L’écart s’explique à cause de la machine d8s_v5, qui vient limiter les performances du mode burst du disque.

Cela n’empêche pas d’avoir de performances très honorables. Passons maintenant au disques Standard SSD.

Standard SSD :

Je trouve le test de débit un peu faible comparé au tableau Microsoft :

  • Standard SSD E10 : 600 IOPS – 38 Mio/sec

Standard HDD :

Pour celui-ci, les résultats des tests sont cohérents avec la documentation Microsoft :

  • Standard HDD S10 : 543 IOPS – 35 Mio/sec

Rappel important : Pour les disques de type standard HDD, chaque opération a un impact sur la facturation.

Ultra disk :

Ce type de disque apporte le plus de flexibilité car ils sont disponibles à partir de 4 Gio et jusqu’à 64 Tio. De plus, la SLA qui les couvre est très élevée : 99.99 %.

Comme le montre l’écran de paramétrage de notre test, nous pouvons jouer avec les limites débit et IOPS selon des besoins très précis, et cela sans aucun redémarrage de la machine virtuelle.

Les limites maximales des IOPS et des débits sont très hautes, comme le montre le tableau ci-dessous :

Rappel important : Pour les disques Ultra, ces options ont un lourd impact sur la facturation.

Le test d’IOPS sur le disque ultra a plafonné à 20 000 IOPS car nous avons là encore été bridé par la limite d’IOPS de la machine virtuelle d8s_v5. Le tableau ci-dessous nous affiche cette limite et le mode burst possible :

Les machines virtuelles les plus puissantes acceptent jusqu’à 80 000 IOPS, ce qui reste en dessous de la limite maximale des IOPS des plus puissants disques ultra. C’est pour cela que ces derniers peuvent être utilisés en tant que disques partagés, pour prendre en charge plusieurs machines virtuelles.

Conclusion :

Je peux déjà commencer par vous dire que j’aurais bien aimé tester un disque Premium SSD v2 ????. Cela devrait arriver sous peu, je vous ferai alors une mise à jour de cet article.

Cela dit, je pense que les performances et les usages de ces derniers sont proches des disques Ultra. A ce titre, je pense que la stratégie de Microsoft est bien de démocratiser la performance et la customisation des disques selon les besoins, avec un prix bien plus attractif ✌️????

Edit :

Seulement quelques jours après la publication de mon article, j’ai reçu un avis favorable de la part d’un Product Manager de chez Microsoft pour tester les disques Premium SSD v2, sur une souscription Azure de mon tenant, en disponibilité générale depuis octobre 2022.

Je suis parti donc sur un disque Premium SSD v2 avec les caractéristiques suivantes :

Pour rappel, voici quelques caractéristiques maximales pour un disque Premium SDD v2 :

  • Taille maximale : 65 536 Gio
  • IOPS provisionnées : 80 000 IOPS
  • Débit provisionné : 1200 Mio / Sec

Afin d’atteindre les performances maximales de mon disque, j’ai créé une machine virtuelle D32s v5, qui dispose des limites suivantes :

Grâce à Diskspd et aux commandes suivantes :

diskspd.exe –c50G -d120 -r -w100 -F4 -o128 -b8K -Sh -L E:\diskpsdtmp.dat > IOPS-PremiumSSDv2.txt
diskspd.exe –c50G -d120 -r -w100 -F4 -o128 -b64K -Sh -L E:\diskpsdtmp.dat > Throughput-PremiumSSDv2.txt

Cela m’a permis de compléter mes tableaux de performances :

Il s’agit sans aucun doute d’un type de disque flexible aux performances incroyables. Voici un rappel du prix bien moins chère qu’un Ultra disk ????

Attention aux limitations encore présentes sur le disques Premium SSD v2.

Configurer l’autorisation multi-utilisateur pour Azure Backup

J’avais déjà écrit un article sur comment sauvegarder de machine virtuelle via Runbook/Snapshot. Cette option est intéressante dans le cas où la sauvegarde native d’Azure ne supporte pas l’OS de la machine virtuelle. Microsoft continue d’apporter des mesures de sécurité sur son service sauvegarde Azure Backup.

Dans cet article, nous allons parler et tester l’autorisation multi-utilisateur (MUA), annoncée il y a seulement quelques jours en disponibilité générale. Dans quel but ? Accroître la protection des sauvegardes de vos ressources Azure.

Mais avant cela, nous allons faire un rappel de quelques mesures de protection de sauvegardes de machines virtuelles disponibles sur Azure.

Par défaut, quelles mesures de protection existent sur mes sauvegardes de VMs ?

Quand vous sauvegardez des machines virtuelles au travers de la sauvegarde native d’Azure, vous utilisez et déployez un coffre de sauvegarde. Ce dernier est directement géré par le service Azure Backup :

Ce schéma nous montre la création de snapshots et le transfert différé vers le coffre de sauvegarde.

La création de snapshots et la rétention de vos sauvegardes sont alors configurées selon une police de sauvegarde, créée dans ce coffre de sauvegarde :

Il est possible de créer plusieurs polices de sauvegardes.
Azure propose maintenant plusieurs sauvegardes par jour.

D’autre part, le nombre et la répartition des copies de vos sauvegardes vont dépendre des propriétés de ce coffre :

La création d’un Recovery Service Vault est paramétré en Geo-redondant par défaut.
Cette option reste modifiable tant qu’aucune sauvegarde n’est paramétrée.

Pour rappel, voici quelques notions de réplication à connaitre, tant elles sont très utilisées sur un grand nombre de ressources Azure :

  • Redondance locale (LRS) : La donnée est présente en triple exemplaires dans le même datacenter (Zone) de la région Azure.
  • Redondance zonale (ZRS) : La donnée est présente en triple exemplaires, chacun réparti dans les 3 datacenters (Zones) de la même région Azure, si celle-ci le propose.
  • Géo-redondance (GRS) : La donnée est présente en triple exemplaires dans le même datacenter (Zone) de la région Azure, et 3 autres exemplaires dans la région paire Azure de la première.

Note : il existe également d’autres scénarios de réplication Azure : RA-GRS, GZRS, … ????

Enfin, la suppression d’une sauvegarde stockée dans un coffre conserve encore celle-ci pendant 14 jours. Cette fonctionnalité est activée par défaut et est appelée Soft-delete :

Pour information, la donnée maintenue dans cet état de soft-delete ne coûte rien.

Un coffre de sauvegarde contenant encore des sauvegardes en état de soft-delete ne peut être supprimé.

Envi d’en savoir plus sur la sauvegarde de machine virtuelle ?

Voici l’excellente vidéo de Travis Roberts expliquant le service Azure Backup et les étapes de sa mise en place sur différentes ressources Azure :

Pourquoi mettre en place l’autorisation multi-utilisateur sur les sauvegardes Azure ?

L’autorisation multi-utilisateur (MUA) pour la sauvegarde Azure vous permet d’ajouter une couche supplémentaire de protection aux opérations critiques sur vos coffres Recovery Services. Pour MUA, Sauvegarde Azure utilise une autre ressource Azure appelée protection des ressources pour garantir que les opérations critiques sont effectuées uniquement avec l’autorisation applicable.

Microsoft Doc

En y réfléchissant, un scénario apparait effectivement comme non protégé : comment sécuriser les sauvegardes contre un compte administrateur compromis ou contre une suppression accidentelle ?

En effet, un compte utilisateur Azure AD, configuré comme propriétaire ou contributeur de ressources Azure, dispose des droits pour la mise en en place de sauvegardes, mais également de ceux pour les démettre ! Les mesures listées précédemment renforcent la sécurité mais sont toutes réversibles par cet utilisateur.

Est-ce ici qu’entre en scène Azure Resource Guard ?

L’idée générale d’Azure Resource Guard est de faire reposer la répartition des tâches (donc des droits Azure) sur différents utilisateurs. Il s’agit d’un dispositif (SOD) mis en place dans tout processus de contrôle interne : acteur et contrôleur.

Comme le montre le schéma ci-dessous, deux roles sont alors nécessaires pour sécuriser les actions liées aux sauvegardes avec MUA :

  • Administrateur sauvegarde : Propriétaire ou contributeur du coffre de sauvegarde. Ce dernier met en place et gère les sauvegardes de ressources Azure. L’administrateur sauvegarde ne doit pas avoir de droits élevés et permanent sur l’Azure Resource Guard.
  • Administrateur sécurité : Propriétaire du Azure Resource Guard et gardien des opérations critiques sur le coffre de sauvegarde. Par conséquent, l’administrateur sécurité contrôle les permissions dont l’Administrateur sauvegarde a besoin pour effectuer les opérations critiques.

Quelles sont les actions restreintes grâce à Azure Resource Guard ?

L’installation du contrôle d’Azure Resource Guard sur un coffre de sauvegarde bloquera certaines actions si les droits de l’Administrateur sauvegarde sont insuffisants :

Les opérations marquées comme obligatoires ne peuvent pas être exclues de la protection par Azure Resource Guard. Enfin, cette configuration s’appliquera à tous les coffres de sauvegarde associés à celui-ci.

Où doit se trouver Azure Resource Guard ?

Le service Azure Resource Guard doit obligatoirement être sur la même région Azure que le coffre de sauvegarde qu’il protège. De plus, l’Administrateur sauvegarde ne doit pas avoir de droits de contributeur permanent sur Azure Resource Guard. Dans le cas contraire, il n’est jamais bloqué pour aucune action critique sur le coffre de sauvegarde.

Il est alors possible d’envisager différents scénarios :

  • Le coffre de sauvegarde et Azure Resource Guard sont dans la même souscription. Mais l’Administrateur sauvegarde n’a pas accès à Azure Resource Guard.
  • Le coffre de sauvegarde et Azure Resource Guard sont dans des souscriptions différentes du même tenant. Mais l’Administrateur sauvegarde n’a pas accès à Azure Resource Guard ou à sa souscription.
  • Le coffre de sauvegarde et Azure Resource Guard sont dans des tenants différents. Mais l’Administrateur de sauvegarde n’a pas accès à Azure Resource Guard, à la souscription ou tenant correspondant.

Etape 0 : Rappel des prérequis

Comme pour beaucoup d’articles sur ce blog, nous allons créer différentes ressources sur Azure pour y parvenir. Comme à chaque fois, des prérequis sont nécessaires pour réaliser cette démonstration :

  • Un tenant Microsoft. Comme indiqué plus haut, il est possible de faire interagir un Azure Resource Guard avec un coffre de sauvegarde hébergés sur différents tenants.
  • Une ou plusieurs souscriptions Azure. Comme indiqué plus haut, il est possible de faire interagir un Azure Resource Guard avec un coffre de sauvegarde sur différentes souscriptions Azure.
  • Une machine virtuelle déjà déployée sur un tenant accessible à l’Administrateur de sauvegarde .

Dans mon cas, j’ai utilisé deux tenants différents, différenciés dans cet article par la couleur du portail Azure pour plus de simplicité :

  • Le tenant A, noir pour l’Administrateur de sauvegarde, contient la machine virtuelle à sauvegarder et le coffre de sauvegarde.
  • Le tenant B, blanc pour l’Administrateur sécurité, contient Azure Ressource Guard.

Nous avons donc les deux environnements Azure suivants :

Tenant A.

Etape I : Création d’Azure Resource Guard

Sur le tenant B, commencez la création du service Azure Resource Guard :

Renseignez les différents champs, puis cliquez sur Suivant :

Si l’erreur suivante apparaît, retournez sur la page de la souscription Azure concernée :

Cliquez comme ceci pour constater le statut du resource provider Microsoft.DataProtection :

Cliquez alors sur celui-ci puis sur Enregistrer :

Attendez quelques minutes que le traitement se termine :

Contrôler le nouveau statut du resource provider :

Retournez dans la création de votre Azure Resource Guard pour constater la disparition du message d’erreur sur le second onglet.

Sélectionnez les opérations dont vous avez besoin de protéger et cliquez comme ceci pour les valider :

Vous pourrez toujours modifier cette liste après la création dans les propriétés d’Azure Resource Guard.

Lancez la création de votre Azure Resource Guard :

Etape I : Assignation du rôle de lecteur pour l’administrateur de sauvegarde

Afin de pouvoir interroger le service Azure Resource Guard, l’Administrateur sauvegarde doit disposer d’un rôle de lecteur sur ce dernier.

Sur le tenant B, retournez sur l’Azure Resource Guard et cliquez comme-ci pour rajouter le rôle de lecteur à l’administrateur sauvegarde :

Choisissez le rôle de lecteur puis cliquez sur Suivant :

Ajoutez votre Administrateur sauvegarde :

Cliquez pour valider :

Etape II : Création du coffre de sauvegarde

De retour sur le tenant A, recherchez le service Recovery Service Vault pour le créer :

Renseignez les champs et lancez la création du coffre de sauvegarde :

Etape III : Protégez votre coffre de sauvegarder

Retournez sur le tenant B, puis copiez la valeur suivante de votre Azure Resource Guard :

Sur le tenant A, retournez sur votre coffre de sauvegarde et cliquez ici pour mettre en place la MUA :

Effectuez les opérations suivantes et collez votre Resource Guard ID dans le champ suivant :

Contrôlez la cohérence des informations de votre Azure Resource Guard :

Sauvegardez la configuration MUA de votre coffre de sauvegarde :

Votre coffre de sauvegarde est maintenant protégé, continuez sur l’étape suivante pour vérifier le blocage des opérations pour l’Administrateur sauvegarde.

Etape IV : Contrôlez le blocage pour l’administrateur sauvegarde

Restez dans les propriétés de votre coffre de sauvegarde et cliquez sur les options de sécurité :

Vous êtes immédiatement averti de la couche de protection supplémentaire grâce au service Azure Resource Guard :

Essayez de désactiver la fonctionnalité Soft Delete et sauvegardez la nouvelle configuration :

L’action de sauvegarde échoue bien et affiche la notification d’erreur suivante :

La même opération, avec un autre compte, disposant lui de droits de contributeur sur Azure Resource Guard, dans mon exemple grâce à Azure Lighthouse, ne pose aucun souci :

Etape IV : Sauvegardez votre la machine virtuelle avec MUA

La mise en place de MUA ne bloque pas l’Administrateur sauvegarde de mettre en place de nouvelles protections pour des ressources Azure.

Pour cela, retournez sur la page principale de votre coffre de sauvegarde et cliquez comme-ceci :

Continuez la configuration avec la famille de ressources Machine virtuelle :

Ajoutez votre machine virtuelle à sauvegarder :

Cochez la case correspondante pour prendre la machine virtuelle désirée et cliquez sur OK

Activez la mise en place de la sauvegarde :

Une fois le traitement terminé, retournez sur le coffre de sauvegarde comme-ci :

Cliquez ici pour afficher les détails :

Lancez une sauvegarde immédiate :

La mise en place de la sauvegarde et la première sauvegarde n’ont pas provoqué d’erreur MUA pour l’Administrateur sauvegarde.

Contrôler l’avancement des travaux de la première sauvegarde et affichez les détails pour vérifier quand celui-ci est entièrement terminé :

Après quelques minutes et plusieurs rafraichissements, la sauvegarde est complète et correctement envoyée dans le coffre de sauvegarde.

Que peut-on encore mettre en place ?

Dans certains cas, vous devrez peut-être effectuer des opérations critiques sur vos sauvegardes et MUA peut vous aider à vous assurer qu’elles sont exécutées uniquement lorsque les approbations ou les autorisations appropriées existent. Comme nous l’avons vu précédemment, l’administrateur de sauvegarde doit avoir un rôle Collaborateur sur le service de protection des ressources pour effectuer des opérations critiques qui se trouvent dans l’étendue de la protection des ressources. L’une des façons d’autoriser l’exécution juste-à-temps pour ces opérations consiste à utiliser Azure Active Directory (Azure AD) Privileged Identity Management.

Microsoft Doc

Les étapes suivantes de cet article sont facultatives, mais peuvent simplifier le processus d’élévations des droits grâce à la combinaison de plusieurs services Azure :

  • Azure Gestion des identités privilégiées (PIM)
  • Azure Resource Guard

La Gestion des identités privilégiées Azure AD, présente dans la licence Azure AD Premium P2, apporte de la souplesse dans les autorisations de droits temporaires sur des ressources Azure.

Dans le cadre de PIM et d’Azure Resource Guard, nous aurions la cinématique suivante :

  • Etape 0 : Demande d’élévation des droits par l’Administrateur sauvegarde
  • Etape I : Validation de la demande par Administrateur sécurité pour une durée donnée
  • Etape 2 : Intervention sur les sauvegardes par l’Administrateur sauvegarde
  • Etape 3 : Fin de l’élévation des privilèges d‘Administrateur sauvegarde
Le schéma ci-dessus est un exemple de scénario possible grâce à PIM.

Etape V : Intégration de PIM sur Azure Resource Guard

Sur le tenant B, recherchez le service Azure suivant :

Cliquez sur Ressources Azure puis sur la souscription ou le groupe de ressources contenant Azure Resource Guard :

Si aucune souscription n’apparait, cliquer « Découvrir les ressources » et laissez-vous guider.

Ajoutez un nouvel assignement :

Choisissez le rôle Contributeur et reprenez l’utilisateur Administrateur sauvegarde et cliquez sur Suivant :

Conservez bien la notion d’éligibilité et cliquez sur Assigner :

Etape VI : Mise en place du processus de validation

Notre utilisateur Administrateur sauvegarde est maintenant éligible pour devenir Contributeur sur Azure Resource Guard. Seulement, il est nécessaire de mettre en place un processus de validation pour l’élévation de ses droits. Sans cela et par défaut, toutes ses demandes seront automatiquement approuvées.

Sur le tenant B et au même niveau que précédemment, cliquez comme ceci dans Azure AD PIM pour modifier les paramétrages de validation :

Cliquez sur le rôle Contributeur :

Cliquez sur Modifier :

Modifiez vos paramétrages pour intégrer l’Administrateur sécurité dans l’activation et cliquez sur Mettre à jour :

Etape VII : Test de la fonctionnalité PIM sur Azure Resource Guard

Avant d’activer le rôle Contributeur sur Azure Resource Guard via Azure AD PIM, nous allons vérifier que l’action sur la sauvegarde de la machine virtuelle n’est pas autorisée dans les conditions de base.

Sur le tenant A, retourner sur le coffre de sauvegarde et cliquez comme ceci :

Cliquez ici pour arrêter le mécanisme de sauvegarde :

Arrêtez complètement le backup et supprimer les données :

Le message d’erreur suivant devrait alors apparaître :

Il est donc bien nécessaire de faire une élévation temporaire des droits sur Azure Resource Guard. Positionnez-vous sur le tenant contenant Azure Resource Guard et lancez Azure AD PIM :

Cliquez sur Mes Rôles :

Cliquez sur Ressources Azure puis sur Activer :

Entrez une justification et une période puis cliquez sur Activer :

La notification Azure suivante doit apparaître :

Sur le tenant B, cliquez sur Approuver les demandes dans Azure AD PIM :

Cliquez sur Ressources Azure et approuvez la demande :

Confirmez la demande d’approbation :

Sur le tenant A, un contrôle sur Azure AD PIM nous montre que le rôle de Contributeur est bien actif :

Retentez alors l’opération de suppression de la sauvegarde de la machine virtuelle :

Si l’erreur suivante arrive en notification, refaite un test dans quelques minutes :

Conclusion

L’ajout de cette fonctionnalité sur un coffre de sauvegarde est un vrai plus en termes de protection des ressources Azure. Il est vrai que la situation antérieure, avec des propriétaires et des contributeurs au plein pouvoirs pouvaient inquiéter en cas de scénarios d’attaque.

Il parait indispensable de sécuriser les opérations critiques liées aux sauvegardes, bien prises en compte avec Azure Resource Guard :

MUA apporte une vraie réponse pour protéger encore plus les sauvegardes et sans surcoût, sauf si Azure AD PIM est présent dans votre architecture. Nul doute qu’Azure Resource Guard va apporter encore plus de protection sur d’autres services au fil de ses évolutions.

Machine virtuelle : changez de taille !

Il arrive qu’une machine virtuelle ne corresponde plus aux besoins initialement définis avec sa taille. Pas de panique ! Un changement est toujours possible après coup. L’un des grands avantages d’Azure est la possibilité de modifier la taille des machines virtuelles, à la volée, des besoins en termes de performances du processeur, du réseau ou de disques.

Dans cet article, nous allons démontrer ensemble la simplicité de changer la taille d’une machine virtuelle, mais également les étapes additionnelles pour un changement particulier.

Dans quel cas redimensionner ?

Lorsque l’on examine le redimensionnement de machines virtuelles sous Azure, trois axes définissent ce processus de changement de taille :

  • Localisation : votre région Azure ne contient pas le matériel nécessaire pour prendre en charge la taille de machine virtuelle souhaitée.
  • Interruption : vous devrez dans certains cas désallouer la machine virtuelle. Cela peut se produire si la nouvelle taille n’est pas disponible sur le cluster matériel qui l’héberge actuellement.
  • Restriction : Si votre machine virtuelle utilise le stockage Premium, assurez-vous que vous choisissez une version s de la taille pour obtenir le support du stockage Premium.

Tailles des machines virtuelles dans Azure

Avant de basculer sur le portail Azure pour effectuer les étapes de modification de taille, voici un rappel de l’offre des machines virtuelles Azure. Afin d’y voir plus clair, Microsoft a segmenté son offre de machines virtuelles par famille, correspondant à des scénarios de besoin utilisateur :

En exemple, voici la définition donnée par Microsoft pour des besoins GPU :

Les tailles de machine virtuelle au GPU optimisé sont des machines virtuelles spécialisées disponibles avec des GPU uniques, multiples ou fractionnaires. Ces tailles sont conçues pour des charges de travail de visualisation, mais également de calcul et d’affichage graphique intensifs.

Microsoft Doc

Les familles sont généralement couvertes par plusieurs séries. Une série est une combinaison CPU + RAM + Autre critères. Les séries sont régulièrement mis à jour par Microsoft via des versions. Voici en exemple le détail de la composition pour la série NCv3 :

Les machines virtuelles de série NCv3 sont optimisées par les GPU NVIDIA Tesla V100. Ces GPU peuvent fournir des performances de calcul une fois et demie supérieure à celles de la série NCv2… les machines virtuelles de la série NCv3 sont également pilotées par des processeurs Intel Xeon E5-2690 v4 (Broadwell).

Microsoft Doc

Enfin, chaque série dispose plusieurs SKUs pour proposer différentes puissances. Toujours en exemple, la série graphique NCv3 :

La taille de la machine virtuelle influe également sur le prix de celle-ci. Toujours en exemple, la série graphique NCv3 :

Les instances réservées, d’un ou trois ans, diminuent fortement le prix des machines virtuelles.

Codification Azure

Cette large découpe propose aux utilisateurs un très grand nombre de machines virtuelles possibles. Dans cette jungle de SKUs, Microsoft a mis en place une codification précise dans la dénomination.

[Famille] + [Sous-famille]* + [nombre de processeurs virtuels] + [Processeurs virtuels avec contraintes]* + [Fonctionnalités supplémentaires] + [Type d’accélérateur]* + [Version]
ValeurExplication
FamilleIndique la série de la famille de machines virtuelles
*Sous-familleUtilisé uniquement pour différencier des machines virtuelles spécialisées
Nombre de processeurs virtuelsIndique le nombre de processeurs virtuels de la machine virtuelle
*Processeurs virtuels avec contraintesUtilisé pour certaines tailles de machine virtuelle uniquement. Indique le nombre de processeurs virtuels pour la taille des processeurs virtuels avec contraintes
Fonctionnalités supplémentairesUne ou plusieurs lettres minuscules indiquent des fonctionnalités supplémentaires, telles que :
a = processeur basé sur AMD
b = bloquer les performances de stockage
d = diskfull (c.-à-d., un disque temporaire local présent) ; ceci concerne les nouvelles machines virtuelles Azure, consultez Séries Ddv4 et Ddsv4
i = taille isolée
l = mémoire insuffisante ; une quantité de mémoire inférieure à la taille d’utilisation intensive de la mémoire
m = utilisation intensive de la mémoire ; la plus grande quantité de mémoire dans une taille particulière
t = très petite mémoire ; la plus petite quantité de mémoire dans une taille particulière
s = capacité de stockage Premium, y compris l’utilisation possible de SSD Ultra (Remarque : certaines tailles plus récentes sans l’attribut de s peuvent toujours prendre en charge le stockage Premium, par exemple M128, M64, etc.)
*Type d’accélérateurIndique le type d’accélérateur matériel dans les références (SKU) spécialisées/GPU. Seules les nouvelles références (SKU) spécialisées/GPU lancées à partir du troisième trimestre 2020 auront l’accélérateur matériel dans leur nom.
VersionIndique la version de la série de machines virtuelles

Voici un exemple de dénomination pour la machine virtuelle graphique NC4as_T4_v3 :

ValeurExplication
FamilleN
Sous-familleC
Nombre de processeurs virtuels4
Fonctionnalités supplémentairesa = processeur basé sur AMD
s = capacité de stockage Premium
Type d’accélérateurT4
Versionv3

Avec toutes ces informations, nous allons pouvoir nous intéresser au changement de SKU sur une machine virtuelle existante.

Etape 0 : Rappel des prérequis

Pour cela, nous allons créer différentes ressources sur Azure pour y parvenir. Comme toujours, des prérequis sont nécessaires pour réaliser cette démonstration :

  • Un tenant Microsoft
  • Une souscription Azure valide
  • Une machine virtuelle déployée et démarrée

Comme le montre la copie d’écran ci-dessous, ma machine virtuelle dispose actuellement de la taille D4ds v4

Afin de mesurer les impacts d’un changement de taille sur une machine virtuelle démarrée, j’ai également ouvert une connexion RDP à celle-ci

Test I : Changement d’une taille dans la même série

Le changement de taille de la machine virtuelle s’effectue depuis le portail Azure via la section Taille.

Azure y regroupe différentes tailles, accessibles ou non :

  • Tailles de machine virtuelle les plus populaires
  • Autres séries disponibles
  • Anciennes séries toujours disponibles
  • Tailles indisponibles car problème de quota
  • Tailles indisponibles car disque incompatible
  • Tailles indisponibles car image incompatible

Jouez avec les filtres suivants pour trouver la taille adaptée

Certaines tailles ne sont même pas visibles.

Sélectionnez la taille et cliquez sur redimensionner

Une fois déclenché, une notification de traitement apparait dans votre portail Azure

La session RDP est-elle aussi coupée

Après traitement (30 secondes environ), la machine virtuelle retrouve son status démarré. La nouvelle taille se retrouve alors sur la page principale de la machine virtuelle Azure

La réouverture manuelle de la session RDP montre bien la nouvelle puissance

Test II : Changement d’une taille dans une série disponible

Continuez vos tests en effectuant un changement de taille vers une autre famille de machine virtuelle

Là encore, la session RDP se ferme et la notification de changement apparaît sur le portail Azure. Moins d’une minute plus tard, la machine virtuelle repart avec sa dernière taille

Test III : Changement d’une taille dans une série disponible

Dans certains cas, il est nécessaire de partir sur une taille de machine virtuelle ayant des propriétés différentes. Ma machine virtuelle, actuellement en Standard F8s v2, dispose d’un stockage temporaire.

Le disque temporaire est très utile pour les données qui, vous l’aurez deviné, sont de nature temporaire. Un excellent exemple de ce type de données pour Windows est le pagefile. Lorsqu’une nouvelle machine virtuelle Windows est provisionnée à partir d’une image dans Azure, le pagefile est configuré si cela est possible pour qu’il soit situé sur ce disque temporaire.

Ce stockage temporaire se retrouve alors sur le disque D

Pour la plupart des machines virtuelles Windows, le volume sur le disque temporaire à la lettre de lecteur D:.
Il a également l’étiquette de lecteur « Temporary Storage ».

Les clients ne doivent pas utiliser le disque temporaire pour des données qui doivent être persistantes.

Un retour dans la liste des tailles disponibles pour ma machine virtuelle vm001 ne permet pas de choisir une machine virtuelle dépourvue de disque temporaire.

Dans ce cas, pas le choix, la recréation d’une nouvelle machine virtuelle est un passage obligatoire.

Etape I : Créer une sauvegarde du ou des disques présents

Allez sur la page des disques de la machine virtuelle et cliquez sur chacun d’eux

Créez une sauvegarde de chaque disque (OS et Data)

Vérifiez les champs et lancez la création

Une fois terminé, cliquez ici pour accéder au snapshot

Etape II : Créez un ou des disques depuis la ou les sauvegardes

Lancez la création du ou des nouveaux disques depuis le ou les snapshots créés

Une fois terminé, cliquez ici pour accéder au disque créé

Etape III : Création de la nouvelle machine virtuelle

Il ne reste plus qu’à rattacher ce ou ces disques à une nouvelle machine virtuelle

Renseignez tous les champs nécessaires et la nouvelle taille de machine désirée

Lancez la création de la machine virtuelle

Cliquez ici pour retrouver les propriétés de votre nouvelle machine virtuelle

Constatez la bonne taille de votre machine virtuelle Standard D4s v4

Rouvrez une session RDP sur cette nouvelle machine virtuelle pour finaliser les réglages de pagefile. Un message d’avertissement apparaît à l’ouverture de la session

Sélectionnez les paramétrages automatiques Windows

Redémarrez la machine virtuelle pour appliquer les modifications pagefile

Et vous voilà avec la nouvelle taille ????

Conclusion

Azure apporte beaucoup de flexibilité avec le changement de taille pour les machines virtuelles. Il est même possible de scripter le changement de taille selon les besoins ou les pics de charges.

Comme toujours John nous propose une vidéo pour aller plus loin sur ce sujet ????