Microsoft AZ-801: Hyper-V, virtualisation et stockage — Guide d'étude

By Laurynas Brazys · 7 August 2026 · #microsoft #az-801 #certification #exam-prep #study-guide

Fait partie du Microsoft Windows Server Hybrid Administrator Associate AZ-801 — Guide d’étude. Entraînez-vous avec des réponses vérifiées dans le centre d’examens Microsoft, ou passez des tests chronométrés sur ExamRoll.io.

Vue d’ensemble

Hyper-V et le stockage défini par logiciel de Windows Server forment une plateforme cohésive pour les charges de travail sécurisées, isolées et hautement disponibles. La maîtrise de ces technologies exige de comprendre comment les structures protégées (guarded fabrics) protègent les machines virtuelles des locataires contre les administrateurs de la structure, comment la sécurité basée sur la virtualisation (VBS) renforce le système d’exploitation avec une isolation ancrée dans le matériel, comment le réseau Hyper-V applique l’isolation, et comment la réplication, les points de contrôle et le clustering se comportent en charge et en cas de défaillance. Cette section explique le modèle de sécurité pour les machines virtuelles protégées (shielded VMs) et le renforcement des hôtes, explore en détail les constructions d’isolation réseau, couvre la durabilité via Hyper-V Replica et les mécanismes de points de contrôle, et se termine par Storage Spaces Direct (S2D), les volumes partagés de cluster (CSV) et la conception du quorum dans le clustering de basculement (Failover Clustering).

Virtualisation sécurisée et protection des charges de travail

Les machines virtuelles protégées (Shielded VMs) protègent les ressources des locataires contre l’accès par la structure (fabric). Le service Host Guardian Service (HGS) fonctionne comme l’ancre de confiance, fournissant deux services : l’attestation (qui valide la santé de l’hôte) et la protection des clés (qui libère les clés pour déverrouiller le TPM virtuel de la machine virtuelle). HGS est déployé dans une forêt ou un domaine dédié et verrouillé pour minimiser le risque de compromission. Deux modes d’attestation existent :

Attestation basée sur la confiance TPM : l’assurance la plus forte. Les hôtes Hyper-V nécessitent un TPM 2.0, le Secure Boot, l’application d’une politique d’intégrité du code et un démarrage mesuré (measured boot). HGS vérifie les journaux de démarrage mesuré et l’identité de l’hôte avant de libérer le protecteur de clé au vTPM de la machine virtuelle.
Attestation basée sur l’administrateur (Active Directory) : une assurance plus légère. Les hôtes prouvent leur fiabilité par leur appartenance à un groupe AD et par des métadonnées d’hôte publiées. Aucune preuve de démarrage mesuré n’est évaluée, ce qui facilite l’amorçage mais le rend moins résistant à la falsification.

Les rôles de la structure (fabric) et du locataire sont délibérément séparés. Les administrateurs de la structure gèrent les hôtes, les clusters, le stockage et le réseau, mais ne peuvent pas inspecter les disques des machines virtuelles protégées, attacher des débogueurs ou utiliser la console/PowerShell Direct. Les administrateurs du locataire construisent la machine virtuelle, possèdent les informations d’identification du système d’exploitation et créent les données de protection (shielding data) (un paquet scellé contenant un fichier de réponses unattend, un certificat RDP et des clés de protection) pour contrôler où la machine virtuelle peut s’exécuter. Les machines virtuelles protégées utilisent BitLocker à l’intérieur de l’invité, ancré dans un vTPM, et seuls les hôtes protégés (guarded hosts) attestés par HGS reçoivent les secrets nécessaires au démarrage.

La sécurité basée sur la virtualisation (Virtualization-Based Security, VBS) élève la frontière de sécurité au-dessus du noyau en créant le mode sécurisé virtuel (Virtual Secure Mode, VSM). Avec VBS, l’hyperviseur applique des niveaux de confiance virtuels (Virtual Trust Levels, VTL), isolant les composants sensibles dans VTL1 aux côtés d’un noyau sécurisé. Les fonctionnalités incluent :

Credential Guard : les secrets de LSASS résident dans un processus isolé (LSAISO) en mode VSM ; le système d’exploitation normal (VTL0) ne peut pas lire directement la mémoire.
Intégrité du code appliquée par l’hyperviseur (Hypervisor-Enforced Code Integrity, HVCI) : seul le code noyau qui répond aux exigences modernes de signature et d’intégrité s’exécute ; les attaques DMA sont atténuées avec l’IOMMU. Les prérequis incluent l’UEFI avec Secure Boot, la virtualisation CPU avec SLAT (Intel EPT/AMD NPT) et l’IOMMU (Intel VT-d/AMD-Vi). La configuration se fait par stratégie de groupe (Group Policy) : activez la sécurité basée sur la virtualisation (Turn On Virtualization Based Security), puis activez Credential Guard et HVCI ; verrouillez la configuration avec Secure Boot pour empêcher toute restauration. Associés aux machines virtuelles de génération 2, au Secure Boot et au vTPM, VBS/VSM fournissent un renforcement de sécurité robuste tant pour les hôtes que pour les invités.

Isolation réseau, réplication et points de contrôle Hyper-V

Les commutateurs virtuels Hyper-V appliquent une isolation de Couche 2/L3 :

Les commutateurs externes se lient à une carte réseau physique (ou à une équipe SET) pour atteindre le LAN. Utilisez des adaptateurs distincts pour le trafic de gestion et le trafic des locataires afin d’éviter les débordements.
Les commutateurs internes connectent les VM uniquement à l’hôte ; aucune liaison montante externe.
Les commutateurs privés connectent les VM uniquement entre elles ; il n’y a de connectivité ni avec l’hôte ni avec le LAN. Les VLAN segmentent les domaines L2. Attribuez un VLAN d’accès par carte réseau de VM pour une isolation simple ou activez le mode trunk pour transporter plusieurs VLAN vers une appliance invitée prenant en charge les VLAN. Les ACL de port sur un adaptateur réseau de VM ajoutent un filtrage sans état à 5 tuples (IP source/destination, protocole, port) avec des directions (entrant/sortant/les deux) et des actions (autoriser/refuser/mesurer). Les ACL de port sont appliquées par l’hôte et utiles pour l’isolation locale et le contrôle de sortie rudimentaire, mais elles ne remplacent pas un pare-feu complet.

Hyper-V Replica fournit une réplication asynchrone par VM sans nécessiter de stockage partagé. Un serveur est le principal (envoyant les journaux de modifications) et un autre est le réplica (recevant les deltas basés sur AVHDX). Les intervalles de réplication sont de 30 secondes, 5 minutes ou 15 minutes. Options d’authentification :

Kerberos (HTTP 80) : simple pour les serveurs membres d’un domaine ; le trafic n’est pas chiffré. Utilisez IPsec si le chiffrement en transit est requis.
Basée sur les certificats (HTTPS 443) : chiffrée par TLS, fonctionne sur des réseaux non approuvés et des groupes de travail. Planifiez les ouvertures de pare-feu en conséquence, configurez l’autorisation sur le réplica et sélectionnez le stockage du réplica. Types de basculement :
Basculement de test : démarre une VM de test isolée sur le réplica sans impacter la protection.
Basculement planifié : basculement orchestré ; le serveur principal est arrêté, les journaux restants sont envoyés, ce qui donne un RPO de zéro perte de données en cas de connectivité saine. Prend en charge la réplication inversée pour rétablir la protection.
Basculement non planifié : invoqué lorsque le serveur principal n’est pas disponible ; le RPO est égal au dernier journal reçu. La réplication étendue peut transférer les modifications du réplica vers un site tertiaire, augmentant ainsi la redondance.

Les points de contrôle (checkpoints) capturent un état à un instant T pour la récupération et le dev/test. Les points de contrôle standard enregistrent la mémoire de la VM et l’état des périphériques, permettant des restaurations instantanées mais pouvant perturber la cohérence des applications. Les points de contrôle de production utilisent VSS dans l’invité (Windows) ou le vidage du système de fichiers (Linux) pour créer une image cohérente au niveau applicatif sans état de la mémoire ; ils sont appropriés pour les flux de sauvegarde et les points de restauration à longue durée de vie. Le stockage est implémenté sous forme de disques de différenciation AVHDX chaînés au VHDX de base. L’application ou la suppression d’un point de contrôle fusionne la chaîne de différenciation dans son parent en ligne ; les fusions importantes créent une pression sur les E/S, il faut donc maintenir une marge de manœuvre adéquate et éviter les arborescences profondes. Pour les contrôleurs de domaine et les applications distribuées, les points de contrôle de production atténuent la restauration USN (USN rollback) et les problèmes associés ; les points de contrôle standard sont mieux adaptés aux travaux de dev/test de courte durée.

Capacités de l’hôte, virtualisation imbriquée et sécurité des générations de VM

Les VM de Génération 2 démarrent via UEFI, prenant en charge le Secure Boot et le vTPM. Le Secure Boot vérifie les chargeurs de démarrage par rapport à une base de données de confiance (utilisez le modèle Windows ou le modèle Linux approprié). Le vTPM apporte la sémantique TPM 2.0 à l’invité, permettant l’utilisation de BitLocker, le provisionnement de Windows Hello for Business et les scénarios de VM protégées (shielded VM). Lorsque des invités plus anciens nécessitent un BIOS ou des périphériques hérités, les VM de Génération 1 restent disponibles mais ne disposent ni du Secure Boot ni du vTPM.

La virtualisation imbriquée permet d’exécuter Hyper-V à l’intérieur d’une VM. Les prérequis incluent un processeur compatible (Intel VT-x/EPT ou AMD-V/NPT), Windows Server 2016 ou une version ultérieure sur l’hôte et l’invité, et une VM configurée avec :

Mémoire statique (désactiver la mémoire dynamique).
Extensions de virtualisation exposées (Set-VMProcessor -ExposeVirtualizationExtensions $true).
Usurpation d’adresse MAC (MAC address spoofing) pour les scénarios où les hôtes internes fournissent un réseau NAT ou en pont. Les cas d’usage incluent l’exécution de conteneurs isolés Hyper-V, la création de clusters de laboratoire, le test de basculement et les pipelines CI qui nécessitent des hyperviseurs. Azure prend en charge la virtualisation imbriquée sur des séries de VM spécifiques ; assurez-vous que la taille sélectionnée correspond au besoin d’extensions de virtualisation.

Stockage défini par logiciel, comportement des CSV et quorum

Storage Spaces Direct agrège les lecteurs locaux en un pool à l’échelle du cluster en utilisant SMB3, RDMA et la pile de clustering. Les prérequis pour le cluster incluent l’édition Windows Server Datacenter, des nœuds membres d’un domaine avec des cartes réseau homogènes, un réseau à haute bande passante et faible latence (10/25/40 GbE ; RDMA via iWARP ou RoCEv2 recommandé) et du matériel validé. Les domaines de panne peuvent représenter des nœuds, des châssis et des racks ; leur configuration améliore le placement et le comportement de réparation, et atténue les défaillances corrélées. Les types de résilience incluent :

Miroir bidirectionnel (min 2 domaines de panne) : orienté performance, tolère une défaillance.
Miroir tridirectionnel (min 3 domaines de panne) : durabilité supérieure, tolère deux défaillances.
Double parité et parité accélérée par miroir : efficace en capacité avec des compromis sur la latence en écriture ; adapté à l’archivage ou aux charges de travail mixtes avec un cache en écriture différée. Les niveaux de cache lient les médias plus rapides (NVMe/SSD) en tant que cache de lecture/écriture aux lecteurs de capacité (SSD/HDD). Le cache en écriture différée absorbe les écritures aléatoires et les fusionne ; le réglage se fait par volume. Utilisez ReFS pour l’allocation accélérée, le clonage de blocs et les flux d’intégrité ; il s’associe bien avec les sémantiques de performance et de réparation de S2D. Un témoin (disque, partage de fichiers ou cloud) est obligatoire pour un S2D à deux nœuds afin de supporter la défaillance d’un seul nœud.

Les Volumes partagés de cluster (CSV) exposent un espace de noms cohérent (C:\ClusterStorage...) à tous les nœuds, permettant un accès concurrent aux volumes NTFS/ReFS via CSVFS. Les opérations normales utilisent l’I/O direct, où la coordination des métadonnées se fait via SMB, mais les lectures/écritures atteignent directement les chemins de stockage. L’I/O redirigé s’active dans certaines conditions : maintenance, défaillance du chemin de stockage, opérations de snapshot/sauvegarde, ou lorsqu’un volume est mis en pause. Deux modes de redirection existent :

I/O redirigé par le système de fichiers : le trafic transite par SMB vers le coordinateur.
I/O redirigé par bloc : plus efficace pour les charges de travail lourdes en blocs lorsque nécessaire. Le cache CSV est un cache de lecture en mémoire vive de l’hôte qui bénéficie aux charges de travail à dominante de lecture, telles que les disques parents VHDX et les chaînes de différenciation. Configurez le cache au niveau du cluster en l’activant et en définissant une taille de cache de bloc appropriée à la RAM disponible, en laissant une marge pour l’hôte et les charges de travail. Surveillez les taux de réussite du cache et ajustez de manière conservatrice pour éviter d’épuiser la mémoire système.

Le quorum du cluster de basculement détermine la vitalité du cluster. Les modes incluent :

Majorité de nœuds : nombre impair de nœuds ; survit à floor((N‑1)/2) défaillances.
Majorité de nœuds et de disque : ajoute un disque témoin qui participe au vote ; bon lorsque du stockage partagé est présent.
Majorité de nœuds et de partage de fichiers : utilise un partage de fichiers témoin hébergé en dehors du domaine de panne du cluster.
Témoin cloud : s’appuie sur un compte Azure Storage pour un témoin léger et hautement disponible, idéal pour les déploiements multi-sites et en périphérie (edge). Les clusters modernes utilisent le quorum dynamique et le témoin dynamique : les votes sont ajustés en temps réel pour maximiser la tolérance aux pannes, et le témoin gagne ou perd automatiquement un vote pour éviter les égalités. Appliquez des poids de nœud pour exclure les nœuds peu fiables du vote si nécessaire. Pour les clusters à deux nœuds, configurez toujours un témoin (partage de fichiers ou cloud) pour permettre la survie à la défaillance d’un seul nœud.

Scénario de problème pratique

Chez Siemens, l’équipe OT/IT doit moderniser un petit site en périphérie (edge) hébergeant trois VM Windows Server qui exécutent de la télémétrie de fabrication. Ils doivent isoler le trafic entre les réseaux OT et d’entreprise, protéger les informations d’identification sur les hôtes et atteindre une résilience au niveau du site sans stockage partagé.

Créer un cluster de basculement Hyper-V à deux nœuds avec Storage Spaces Direct

Pourquoi : S2D élimine le besoin d’un SAN, fournit une mise en miroir entre les nœuds pour la durabilité et s’intègre avec le Failover Clustering pour un basculement automatique. Un témoin de partage de fichiers ou cloud est ajouté pour que le cluster à deux nœuds puisse supporter la défaillance d’un seul nœud.

Activer VBS avec Credential Guard et HVCI sur les deux hôtes

Pourquoi : VBS/VSM isole les informations d’identification de LSASS et applique l’intégrité du code du noyau, réduisant le risque de mouvement latéral des logiciels malveillants dans un environnement avec des appareils OT mixtes.

Utiliser des VM de génération 2 avec Secure Boot et vTPM

Pourquoi : L’UEFI Secure Boot résiste à la falsification par des boot-kits ; le vTPM permet d’utiliser BitLocker dans le système d’exploitation invité pour les données au repos. Cela correspond à l’exigence de Siemens de protéger les configurations de télémétrie sensibles contre le vol sur des sites distants.

Créer un commutateur Hyper-V externe pour chaque liaison montante physique et segmenter avec des VLAN et des ACL de port

Pourquoi : Les VLAN séparent le trafic OT et d’entreprise sur la même structure physique, tandis que les ACL de port fournissent des filtres granulaires, appliqués par l’hôte, pour empêcher le trafic est-ouest entre les niveaux sans déployer d’appliances virtuelles complètes en périphérie.

Configurer Hyper-V Replica depuis le site en périphérie vers un serveur de réplica dans un datacenter central via HTTPS

Pourquoi : L’authentification basée sur les certificats chiffre la réplication de bout en bout sur les liaisons WAN non fiables. Le basculement planifié prend en charge les fenêtres de maintenance ; le basculement non planifié offre une reprise après sinistre (DR) lorsque le site en périphérie est hors ligne. La réplication inverse reprotège après le retour arrière (failback).

Standardiser sur l’utilisation unique des points de contrôle de production

Pourquoi : Les points de contrôle de production génèrent des points de restauration cohérents avec l’application sans état de la mémoire, ce qui est approprié pour la pile de télémétrie et plus sûr dans le temps que les points de contrôle standard qui capturent la mémoire volatile.

Activer le cache CSV avec un dimensionnement conservateur

Pourquoi : Les tableaux de bord de télémétrie principalement en lecture bénéficient des blocs parents mis en cache, améliorant la réactivité sans consommer une RAM excessive sur les nœuds en périphérie aux ressources limitées.

Cette conception utilise S2D pour la haute disponibilité, VBS/vTPM/Secure Boot pour une confiance renforcée, les VLAN et les ACL de port pour une isolation déterministe, et Hyper-V Replica pour la résilience du site — équilibrant la sécurité, la performance et l’opérabilité dans un environnement en périphérie aux ressources limitées.

← Mise à jour et gestion des correctifs de Windows Server · Tous les domaines · Reprise après sinistre et continuité des activités →

Entraînez-vous sur ces questions → · Tests chronométrés sur ExamRoll.io →