Virtualisation VMware vSphere 8

Concepts de virtualisation

La virtualisation consiste a abstraire les ressources physiques (CPU, RAM, stockage, reseau) pour creer des machines virtuelles (VMs) independantes sur un meme serveur. Cette technologie est au coeur de toute infrastructure d'entreprise moderne.

Pourquoi virtualiser ?

Sans virtualisation, chaque service necessite un serveur physique dedie. Avec la virtualisation, un seul serveur physique peut heberger dizaines de VMs, reduisant les couts materiels de 60 a 80% tout en ameliorant la flexibilite et la disponibilite.

Hyperviseur Type 1 vs Type 2

Critere Type 1 (bare-metal) Type 2 (hosted)
Installation Directement sur le materiel Sur un OS hote (Windows, Linux)
Performances Quasi-natives, acces direct au hardware Overhead lie a l'OS hote
Exemples VMware ESXi, Hyper-V Server, KVM VirtualBox, VMware Workstation
Usage Production, datacenters Developpement, tests locaux
Securite Surface d'attaque reduite Depend de la securite de l'OS hote

Dans notre infrastructure

Nous utilisons ESXi 8.0 U2, un hyperviseur de Type 1. Il s'installe directement sur le materiel serveur sans OS intermediaire, garantissant des performances maximales et une surface d'attaque minimale.

Fonctionnalites cles de vSphere

Fonctionnalite Description
vMotion Migration a chaud d'une VM d'un hote ESXi a un autre sans interruption de service. Le CPU state, la memoire et les connexions reseau sont transferes en temps reel.
High Availability (HA) Si un hote ESXi tombe en panne, vSphere HA redemarre automatiquement les VMs sur les hotes restants du cluster. Le temps de reprise est de l'ordre de 1 a 5 minutes.
DRS (Distributed Resource Scheduler) Equilibrage automatique de la charge entre les hotes. DRS surveille l'utilisation CPU/RAM et deplace les VMs via vMotion pour optimiser les performances.
vSAN Stockage distribue hyperconverge integre aux hotes ESXi (detaille ci-dessous).
Fault Tolerance (FT) VM dupliquee en temps reel sur un second hote : zero downtime meme en cas de panne materielle (usage critique uniquement, cout eleve en ressources).

Architecture vSphere 8 (Production)

L'architecture de production comprend 8 noeuds ESXi repartis sur deux sites geographiques (4+4), geres par un vCenter Server Appliance en haute disponibilite. vSAN Enterprise Plus assure le stockage distribue avec replication synchrone inter-sites.

graph TB
    subgraph VCENTER["vCenter Server 8.0 U2 - HA"]
        VC["vcenter.infra.indio<br/>10.15.100.10<br/>Gestion centralisee"]
    end

    subgraph SITE_A["Site Principal - 4 noeuds"]
        ESX1["ESXi-01<br/>512 GB RAM<br/>NVMe vSAN"]
        ESX2["ESXi-02<br/>512 GB RAM<br/>NVMe vSAN"]
        ESX3["ESXi-03<br/>512 GB RAM<br/>NVMe vSAN"]
        ESX4["ESXi-04<br/>512 GB RAM<br/>NVMe vSAN"]
    end

    subgraph SITE_B["Site Secondaire - 4 noeuds"]
        ESX5["ESXi-05<br/>512 GB RAM<br/>NVMe vSAN"]
        ESX6["ESXi-06<br/>512 GB RAM<br/>NVMe vSAN"]
        ESX7["ESXi-07<br/>512 GB RAM<br/>NVMe vSAN"]
        ESX8["ESXi-08<br/>512 GB RAM<br/>NVMe vSAN"]
    end

    subgraph MGMT["Management"]
        ARIA_A["Aria Automation<br/>Orchestration IaC"]
        ARIA_O["Aria Operations<br/>Monitoring + Capacity"]
    end

    VC --> SITE_A
    VC --> SITE_B
    VC --> MGMT
    SITE_A <-->|"vSAN Stretched Cluster<br/>Replication synchrone"| SITE_B

vCenter HA (High Availability)

Le vCenter est deploye en mode HA avec 3 noeuds : Active, Passive et Witness. Si le noeud actif tombe, le noeud passif prend le relais en moins de 5 minutes. Le witness arbitre le quorum pour eviter les split-brain.

Composants de la plateforme

Composant Version Configuration Role
vCenter Server 8.0 Update 2 (VCSA) HA Active/Passive/Witness Gestion centralisee des clusters, inventaire, permissions
ESXi 8.0 Update 2 8 hotes, 512 Go RAM chacun Hyperviseur bare-metal, execution des VMs
vSAN Enterprise Plus FTT=1, NVMe, Stretch Cluster Stockage distribue hyperconverge
Aria Automation 8.x (ex-vRealize) Blueprints IaC, self-service Orchestration, provisionnement automatise
Aria Operations 8.x (ex-vRealize) Dashboards, alertes, projections Monitoring, capacity planning, optimisation

Licences VMware

Depuis le rachat par Broadcom (2023), le modele de licences VMware a profondement change. vSAN Enterprise Plus est desormais inclus dans la licence VMware Cloud Foundation (VCF). Il est essentiel de bien dimensionner les licences par CPU socket.

Capacites de stockage

Type de stockage Technologie Capacite brute Capacite utilisable Perte overhead Usage principal
vSAN NVMe SSD 200 To ~140 To ~30% (FTT + metadata) VMs critiques, bases de donnees
Ceph HDD + SSD cache 500 To ~350 To ~30% (replication x3) Mail, fichiers, objets S3
Veeam HDD SATA 300 To ~250 To ~17% (filesystem) Sauvegardes, retention longue

vSAN en detail

vSAN transforme les disques locaux de chaque hote ESXi en un datastore distribue partage. Au lieu d'un SAN externe couteux, le stockage est integre directement dans les serveurs.

Fonctionnement des Disk Groups

Chaque hote contribue un ou plusieurs disk groups composes de :

  • Cache Tier : disque NVMe/SSD rapide servant de buffer en lecture (70%) et ecriture (30%)
  • Capacity Tier : disques NVMe/SSD/HDD stockant les donnees persistantes
graph LR
    subgraph HOST["Hote ESXi"]
        subgraph DG1["Disk Group 1"]
            CACHE1["NVMe Cache<br/>800 Go"]
            CAP1A["NVMe Capacity<br/>3.2 To"]
            CAP1B["NVMe Capacity<br/>3.2 To"]
        end
        subgraph DG2["Disk Group 2"]
            CACHE2["NVMe Cache<br/>800 Go"]
            CAP2A["NVMe Capacity<br/>3.2 To"]
            CAP2B["NVMe Capacity<br/>3.2 To"]
        end
    end

    CACHE1 --> CAP1A
    CACHE1 --> CAP1B
    CACHE2 --> CAP2A
    CACHE2 --> CAP2B

Politiques FTT et modes RAID

La politique Failures To Tolerate (FTT) definit combien de pannes le cluster peut supporter :

Politique Methode Copies/Parite Hotes minimum Overhead stockage Usage
FTT=0 Aucune 1 copie 1 0% Dev/Test uniquement
FTT=1 (RAID-1) Mirroring 2 copies 3 100% Notre choix - Production
FTT=1 (RAID-5) Erasure coding 3+1 parite 4 33% Bon compromis capacite/perf
FTT=2 (RAID-1) Mirroring 3 copies 5 200% Haute criticite
FTT=2 (RAID-6) Erasure coding 4+2 parite 6 50% Capacite + resilience

FTT=0 interdit en production

Avec FTT=0, la perte d'un seul disque ou hote entraine une perte de donnees. En production, FTT=1 minimum est obligatoire. Notre infrastructure utilise FTT=1 en RAID-1 (mirroring) pour des performances d'ecriture optimales.

Stretched Cluster

Le vSAN Stretched Cluster replique de maniere synchrone les donnees entre les deux sites. Un hote witness (heberge sur un troisieme site ou reseau isole) assure le quorum en cas de perte d'un site complet.

graph LR
    subgraph SA["Site A - 4 hotes"]
        DA["Donnees<br/>Copie 1"]
    end
    subgraph SB["Site B - 4 hotes"]
        DB["Donnees<br/>Copie 2"]
    end
    subgraph SW["Site Witness"]
        W["Witness<br/>Quorum metadata"]
    end

    DA <-->|"Replication synchrone<br/>RPO = 0"| DB
    DA --- W
    DB --- W

Lab de deploiement

Notre lab reproduit l'architecture de production a echelle reduite pour valider les concepts et les procedures.

Infrastructure du lab

Element Detail
Hotes ESXi 4 au total : 1 physique + 3 nested (ESXi dans ESXi)
Clusters 2 clusters vSphere (simulation multi-site)
vCenter vcenter.infra.indio - 10.15.100.10
VMs deployees 21 VMs Rocky Linux 9
Provisionnement Terraform (modules YAML-driven)
Configuration Ansible (playbooks idempotents)

Nested ESXi

Le nested ESXi consiste a installer un hyperviseur ESXi dans une VM. Cela permet de simuler un cluster multi-hotes avec un seul serveur physique. Les performances sont reduites mais suffisantes pour un lab de validation.

Pipeline de deploiement

graph LR
    TF["Terraform<br/>Infrastructure as Code"]
    VCENTER["vCenter API<br/>10.15.100.10"]
    VMS["21 VMs<br/>Rocky Linux 9"]
    ANS["Ansible<br/>Configuration"]
    PROD["VMs configurees<br/>et operationnelles"]

    TF -->|"Cree les VMs<br/>via provider vSphere"| VCENTER
    VCENTER -->|"Provisionne"| VMS
    VMS -->|"Inventaire dynamique"| ANS
    ANS -->|"Playbooks<br/>idempotents"| PROD

Les 21 VMs Rocky Linux 9 couvrent l'ensemble des services de l'infrastructure : DNS, LDAP, proxy, monitoring, stockage, bastion, et services applicatifs. Chaque VM est definie dans un fichier YAML Terraform, permettant un deploiement reproductible et versionne dans GitLab.