Machines virtuelles Azure

Une machine virtuelle Azure (VM) est une offre IaaS qui fournit à la demande des ressources de calcul évolutives dans le cloud. Elle émule un ordinateur physique — avec son propre CPU, sa RAM, son stockage et son interface réseau — exécuté sur l’hyperviseur de Microsoft (Hyper-V), sur des serveurs physiques installés dans un centre de données Azure. Vous installez et gérez le système d’exploitation invité (Windows ou Linux), les intergiciels et les applications, tandis qu’Azure prend en charge le matériel sous-jacent, le système d’exploitation hôte et la couche d’hyperviseur.

La création d’une VM nécessite de définir plusieurs paramètres essentiels : Image — le système d’exploitation et les logiciels préinstallés (par exemple, Windows Server 2022, Ubuntu 22.04 ou SQL Server on Windows). Taille — le nombre de vCPU, la RAM et le stockage temporaire de la VM (présentés ensuite). Région — l’emplacement d’exécution de la VM. Authentification — une paire de clés SSH pour Linux, ou un nom d’utilisateur et un mot de passe pour Windows. Le portail vous guide dans ces paramètres à l’aide d’assistants, et Azure CLI vous permet d’automatiser la même configuration pour effectuer des déploiements reproductibles.

Azure organise les tailles de VM en familles (séries) optimisées pour différentes charges de travail : série B (à capacité variable, économique pour une utilisation moyenne faible du CPU), série D (usage général — équilibre entre CPU et mémoire), série E (optimisée pour la mémoire, les bases de données et l’analyse), série F (optimisée pour le calcul), série N (accélérée par GPU pour l’IA, l’apprentissage automatique et les graphiques) et série L (optimisée pour le stockage). La convention de nommage encode la série, le nombre de vCPU et la variante — par exemple, Standard_D4s_v5 est une VM de série D avec 4 vCPUs utilisant un stockage Premium.

Azure propose trois modèles de tarification pour les VM : Paiement à l’utilisation — facturation à la seconde de calcul, sans engagement, avec le tarif horaire le plus élevé. Instances réservées — engagement d’un ou trois ans permettant d’économiser jusqu’à 72 % par rapport au paiement à l’utilisation, avec paiement initial ou mensuel. Instances Spot — exécution sur la capacité Azure inutilisée avec des remises pouvant atteindre 90 %, mais possibilité d’expulsion avec un préavis de seulement 30 secondes lorsque Azure récupère cette capacité. Les instances Spot sont idéales pour le traitement par lots, les simulations et les charges tolérantes aux pannes pouvant reprendre depuis des points de contrôle.

Toutes les VM Azure possèdent au moins deux disques : le disque du système d’exploitation (où le système d’exploitation est installé, avec un disque géré comme support) et un disque temporaire (SSD local rapide destiné aux fichiers d’échange et aux données temporaires, mais dont les données sont LOST lorsque la VM est arrêtée ou désallouée). Vous pouvez attacher des disques de données supplémentaires pour les données des applications ; il s’agit de disques gérés durables qui persistent après les redémarrages de la VM. Les disques gérés existent en quatre types : Standard HDD, Standard SSD, Premium SSD et Ultra Disk, avec des performances et un prix croissants.

Chaque VM Azure est connectée à un réseau virtuel (VNet) par l’intermédiaire d’une carte d’interface réseau virtuelle (vNIC). La VM reçoit une adresse IP privée au sein du sous-réseau du VNet, ce qui lui permet de communiquer avec les autres ressources du même VNet. Pour rendre la VM accessible depuis Internet, vous devez lui associer une adresse IP publique et ouvrir les règles appropriées du groupe de sécurité réseau (NSG). Par défaut, Azure bloque tout le trafic Internet entrant vers une nouvelle VM : vous devez explicitement ouvrir les ports dont vous avez besoin, comme le port 22 pour SSH ou le port 3389 pour RDP.

Pour améliorer la disponibilité des VM, Azure propose deux options : les groupes de disponibilité répartissent les VM entre des domaines d’erreur (des racks distincts) et des domaines de mise à jour au sein d’un même centre de données, ce qui offre un SLA de 99,95 %. Les zones de disponibilité répartissent les VM entre des centres de données physiquement distincts au sein d’une région, ce qui offre un SLA de 99,99 %. Pour les nouvelles architectures, Microsoft recommande les zones de disponibilité plutôt que les groupes de disponibilité partout où la prise en charge des zones existe, car les zones assurent une isolation plus forte contre les défaillances matérielles et les incidents touchant un centre de données entier.

Les Extensions de VM Azure sont de petites applications qui automatisent les tâches de configuration et de gestion après le déploiement sur les VM. L’extension de script personnalisé télécharge et exécute un script sur une VM immédiatement après sa création — ce qui est utile pour installer des logiciels ou configurer des paramètres sans connexion SSH/RDP manuelle. Parmi les autres extensions figurent l’agent Azure Monitor (pour la collecte des journaux), la configuration d’invité Azure Policy (pour vérifier la conformité) et l’extension Antimalware (pour configurer Windows Defender). Les extensions s’exécutent avec le compte système et sont installées depuis le portail Azure ou des modèles ARM.

Il est important de faire la distinction entre l’arrêt et la désallocation d’une VM Azure. L’arrêt d’une VM depuis son système d’exploitation invité (par exemple, shutdown -h now) éteint le système d’exploitation, mais conserve la VM allouée sur l’hôte : vous continuez à être facturé pour le calcul. La désallocation depuis le portail Azure ou la CLI libère les ressources de calcul sous-jacentes et interrompt la facturation du calcul (vous payez toujours les disques gérés). Utilisez toujours az vm deallocate ou le bouton « Stop » du portail afin d’éviter une facturation inutile lorsqu’une VM n’est pas utilisée.

Azure effectue régulièrement une maintenance planifiée du matériel hôte afin d’appliquer des correctifs de sécurité et des mises à jour du microprogramme. Dans la plupart des cas, Azure utilise la migration à chaud pour déplacer votre VM vers du matériel mis à jour sans la redémarrer, ce qui entraîne une pause réseau inférieure à 10 ms. Lorsque la migration à chaud n’est pas possible, Azure planifie un redémarrage pendant une fenêtre de maintenance et vous en informe à l’avance par l’intermédiaire du portail Azure et par e-mail. Vous pouvez également planifier vous-même la fenêtre de maintenance de vos propres VM depuis le portail afin de réduire au minimum les perturbations de votre charge de travail.

Les VM sont le bon choix lorsque vous avez besoin d’un contrôle complet au niveau du système d’exploitation — pour installer des versions spécifiques du système d’exploitation, des pilotes ou des logiciels qui ne peuvent pas s’exécuter sur des plateformes PaaS. Parmi les cas d’utilisation courants figurent les migrations par transfert direct d’applications locales, les logiciels personnalisés qui nécessitent des configurations spécifiques du système d’exploitation, les environnements de développement et de test et les applications héritées qui ne peuvent pas être conteneurisées ou remaniées. Lorsque le contrôle complet du système d’exploitation n’est pas nécessaire, envisagez des options PaaS telles qu’App Service ou Azure Container Instances, qui réduisent considérablement la charge de gestion.

Évaluez votre compréhension des concepts de Microsoft Azure Fundamentals (AZ-900) présentés dans cette leçon.

Dans cette leçon, vous avez appris que : les VM Azure sont des ressources IaaS pour lesquelles vous gérez le système d’exploitation invité et les couches supérieures, tandis qu’Azure prend en charge l’hyperviseur et le matériel, que les tailles de VM sont regroupées en familles optimisées pour les charges de travail à usage général, de calcul, de mémoire, de stockage et de GPU, et que les zones de disponibilité offrent un SLA de 99,99 % en répartissant les VM entre des centres de données physiquement distincts. Nous allons maintenant découvrir les groupes identiques de mise à l’échelle des machines virtuelles pour la mise à l’échelle automatique des VM.