Stockage vSAN¶

Rôle¶

VMware vSAN agrège les disques locaux des deux hôtes esxi-node01/esxi-node02 (voir vcenter-esxi.md) en un unique datastore partagé, vsanDatastore — sans baie SAN/NAS dédiée. C'est la fondation de stockage sur laquelle repose toute la plateforme Indio : c'est ce datastore que consomme le module Terraform /root/vmware pour placer chaque VM de la flotte, et c'est lui qui rend possibles HA/vMotion entre les deux hôtes malgré une topologie à seulement 2 nœuds de calcul. Il porte également le vSAN File Service, extension NFS traitée dans une page dédiée.

Architecture¶

vsanDatastore¶

Configuration du cluster vSAN¶

Constaté via govc vsan.info (API VsanClusterConfigInfo) :

Topologie 2 nœuds + witness¶

Un cluster vSAN classique (3 nœuds ou plus) répartit les composants de données ET le quorum sur les mêmes hôtes. Avec seulement 2 nœuds de données, un troisième arbitre est indispensable pour trancher en cas de coupure réseau entre les deux — c'est le rôle du witness (witness.infra.indio) : il ne stocke aucune donnée applicative, uniquement les composants "witness" (métadonnées de quorum) de chaque objet vSAN. Voir vcenter-esxi.md pour le détail de l'appliance.

flowchart TD
    subgraph Cluster["Cluster vSAN (2 nœuds)"]
        N1["esxi-node01<br/>disk groups (cache + capacity)"]
        N2["esxi-node02<br/>disk groups (cache + capacity)"]
    end
    N1 -->|composants de données| DS[("vsanDatastore<br/>16,6 To / 13,5 To libres")]
    N2 -->|composants de données| DS
    WIT["witness.infra.indio<br/>(hors cluster de calcul)"] -.composants witness<br/>(quorum uniquement).-> DS
    DS --> FS["vSAN File Service<br/>(voir page dédiée)"]
    DS --> VMS["VM de la flotte<br/>(placées par /root/vmware)"]

    style WIT stroke-dasharray: 5 5

Politiques de stockage (SPBM)¶

Le catalogue de politiques de stockage basées sur les profils (SPBM) du vCenter contient, entre autres, vSAN Default Storage Policy (politique par défaut vSAN, RAID-1/FTT=1 typique pour une topologie non stretched) et FSVM_Profile_DO_NOT_MODIFY — cette dernière est la politique interne réservée aux VM système du vSAN File Service (voir vsan-file-service.md), son nom est explicite : ne pas y toucher. Le catalogue contient aussi plusieurs politiques Stretched/ESA propres à des topologies non utilisées ici (pas de cluster stretched, vsanEsaEnabled = false) — présentes par défaut dans tout vCenter 8.x, pas spécifiques à un choix Indio.

Provisioning Terraform¶

Non applicable. Aucun projet dans /root ne crée ou ne configure le cluster vSAN lui-même — le seul rapport avec Terraform est indirect et à sens unique : le module /root/vmware consomme vsanDatastore via une data source (vsphere_datastore) pour y placer des VM (voir vcenter-esxi.md), sans jamais le créer ni le modifier.

Configuration Ansible¶

Non applicable. vSAN est une fonctionnalité du noyau ESXi (couche hyperviseur), sans surface OS/ agent sur laquelle un rôle Ansible pourrait agir.

Procédure manuelle¶

Comme pour le cluster ESXi lui-même, la construction initiale de vSAN n'a pas de journal détaillé conservé. La séquence ci-dessous est la procédure standard VMware, reproductible en cas de reconstruction, cohérente avec la configuration observée dans cette page :

1. Depuis Cluster > Configure > vSAN > Services, activer vSAN sur le cluster en topologie 2 nœuds (pas "stretched cluster", pas de fault domains custom).
2. Désigner l'appliance witness déjà déployée (voir vcenter-esxi.md) comme arbitre du cluster.
3. Sur chaque hôte, réclamer les disques locaux en disk groups (au moins un tier cache + un tier capacity par groupe).
4. Dans vSAN > Services, régler la déduplication/compression (compression seule activée ici, dédup désactivée) et le chiffrement au repos (désactivé ici).
5. Assigner (ou laisser par défaut) une politique de stockage SPBM aux VM du cluster.
6. Vérifier Skyline Health avant de considérer le datastore prêt à recevoir des charges de travail.

Procédure de déploiement¶

Non applicable — aucun code ne permet de redéployer ce cluster depuis zéro ; seule la procédure manuelle ci-dessus permet de le (re)construire à la main.

Contrôle de santé / Vérification¶

export GOVC_URL=https://vcenter.infra.indio GOVC_USERNAME=administrator@infra.indio \
       GOVC_PASSWORD='...' GOVC_INSECURE=1

govc datastore.info vsanDatastore     # capacité / espace libre
govc vsan.info /Datacenter/host/Cluster   # config cluster (dedup/compression/chiffrement/FileService)

Complément UI : Cluster > Monitor > vSAN > Skyline Health pour un contrôle de santé complet (réseau, disques, objets, capacité) — non reproductible en ligne de commande via govc.

Au moment de la vérification (2026-07-19) : vsanDatastore à 13 899,2 Go libres sur 16 990,9 Go (~82 % libre), aucune alerte de capacité.

Points d'attention¶

• Aucun Terraform, aucune trace de version pour la configuration du cluster vSAN elle-même — toute dérive (dédup/compression/chiffrement modifiés à la main) ne laisserait aucune trace Git, contrairement au reste de l'IaC Indio.
• Chiffrement au repos désactivé (DataEncryptionConfig.EncryptionEnabled = false) : les données stockées sur vsanDatastore ne sont pas chiffrées au niveau du datastore — à mettre en regard de la posture de sécurité appliquée ailleurs dans l'infra (Vault PKI, durcissement AD, etc.). Dette technique potentielle si une exigence de chiffrement au repos existe.
• Le witness est un point de défaillance de quorum : la perte simultanée du witness et d'un des deux hôtes de données ferait perdre le quorum du cluster (accès aux données interrompu même si l'hôte restant est parfaitement sain) — limitation structurelle de toute topologie vSAN à 2 nœuds, pas un défaut de configuration.
• Déduplication désactivée, compression activée : compromis assumé plutôt qu'un oubli (compression moins coûteuse en CPU que dédup) — à revalider si la pression sur l'espace libre augmente significativement.
• Toute maintenance d'un des deux hôtes (mode maintenance complet) peut avoir des effets de bord sur des services dépendants d'agents VM système (vu en pratique sur le vSAN File Service, voir vsan-file-service.md) — vSAN lui-même tolère la perte d'un nœud, mais les VM/agents qui y tournaient doivent être réévacués proprement.