MedSearch — infrastructure Microsoft hautement disponible

Objectif

Concevoir l’infrastructure Microsoft d’une entreprise fictive répartie sur deux sites, administrée par une seule personne : simple à exploiter, hautement disponible et prête à accueillir de futurs services. Le cahier des charges couvrait la haute disponibilité, l’hébergement de sites IIS, la supervision, l’administration à distance et la communication entre les sites.

Une contrainte : Hyper-V sur une base Proxmox

Le sujet imposait Hyper-V, alors que le matériel disponible — des machines de mon homelab — tournait déjà sous Proxmox. Plutôt que de le réinstaller, j’ai choisi la virtualisation imbriquée : Proxmox fournit des machines virtuelles Windows Server 2022 auxquelles il expose la virtualisation matérielle, et Hyper-V tourne à l’intérieur. Proxmox reste une simple couche porteuse ; le cluster, les machines virtuelles de service et la haute disponibilité sont entièrement construits avec les outils Microsoft. La double virtualisation réduit les performances : c’est une architecture de laboratoire, présentée comme telle, pas une cible de production.

Architecture

Le socle compte trois serveurs Windows Server 2022 : un serveur d’infrastructure, qui porte notamment l’annuaire et le stockage partagé, et deux hôtes Hyper-V membres d’un même cluster de basculement. Active Directory, DNS et DHCP fournissent l’annuaire, la résolution de noms et l’adressage du domaine. Les flux d’administration, de stockage et des machines virtuelles circulent sur des réseaux séparés.

Cluster Hyper-V et stockage partagé

Le serveur d’infrastructure expose un disque en iSCSI aux deux hôtes ; ce disque est converti en Cluster Shared Volume, sur lequel sont stockées les machines virtuelles, accessibles depuis les deux nœuds. Le quorum s’appuie sur un témoin de partage de fichiers, qui départage les deux nœuds si l’un d’eux disparaît. La configuration a été validée avec Test-Cluster avant la création du cluster.

Les machines virtuelles de service sont hébergées sur ce volume et déclarées hautement disponibles. Deux scénarios ont été testés : la Live Migration d’une machine en fonctionnement d’un hôte à l’autre, et la bascule réelle d’une machine virtuelle entre les deux hôtes.

Services

• Serveur de fichiers : partages SMB pour les utilisateurs du domaine.
• IIS : une machine modèle, préparée avec IIS puis généralisée avec Sysprep, permet de déployer un nouveau site sans réinstallation complète. Un poste client du domaine a servi à vérifier le site publié.
• Administration à distance : Bureau à distance (RDS) et VPN (RRAS), qui assure aussi la liaison entre les sites.
• Supervision : collecte centralisée des journaux d’événements (WEC / WEF).

Automatisation

Les étapes principales sont scriptées en PowerShell : installation d’Active Directory, cible iSCSI, validation et création du cluster, volume partagé, création des machines virtuelles et activation de leur haute disponibilité, installation du VPN, vérification de l’infrastructure.

Une fragilité identifiée

Le stockage partagé dépend d’un seul serveur iSCSI : s’il redémarre, le volume partagé passe hors ligne et les machines virtuelles s’arrêtent. J’ai documenté la procédure de reprise — reconnexion des initiateurs, remise en ligne du volume et du témoin, redémarrage des machines. En production, ce point unique de défaillance appellerait un stockage redondant.

Ce qui n’est pas publié

Les noms de machines, l’adressage, le découpage réseau et le matériel du homelab ne sont pas détaillés ici.