vSAN File Service¶

Rôle¶

Extension de vSAN qui expose des partages fichiers NFS directement depuis le cluster vSAN, sans NAS dédié : deux VM système ("File Service VM", FSVM) auto-déployées par vSAN servent des exports NFSv3/NFSv4.1 aux clients autorisés de l'infra. Dans Indio, ce service a eu une histoire mouvementée — panne réseau initiale, fix, désactivation par effet de bord, réactivation — et sert aujourd'hui de cible pour au moins un usage confirmé (export /veeam, probablement le repository de sauvegarde Veeam) ; son usage documenté comme cible d'archivage froid des logs (/Log, voir syslogng.md) n'a en revanche pas pu être reconfirmé lors de la vérification en direct du 2026-07-19 — voir la section dédiée plus bas.

Ni Terraform ni Ansible ne peuvent piloter ce service : les FSVM sont des appliances système déployées automatiquement par vim.eam (ESX Agent Manager), pas des VM Rocky avec accès SSH, et il n'existe pas d'endpoint REST vSphere fonctionnel pour l'automatiser. Toute action passe par l'UI vCenter.

Architecture¶

Les deux nœuds FSVM¶

Contrairement à ce qu'un premier examen laisserait penser (un seul hostname mentionné dans les usages courants), le vSAN File Service de ce cluster déploie deux VM système, une par hôte ESXi, visibles dans /Datacenter/vm/ESX Agents/ :

Configuration du domaine (constatée via govc vsan.info, champ FileServiceConfig) :

Les deux adresses IP sont statiques (dhcp: false), attribuées hors du pool DHCP habituel de seg-storage (10.100.3.2-10.100.3.13, voir nsx.md) bien que .2 s'y trouve numériquement inclus — aucun conflit constaté, l'assignation statique prévaut.

Schéma — architecture réseau et dépendances¶

flowchart TD
    subgraph Storage["seg-storage (10.100.3.14/28)"]
        F1["file-node01.infra.indio<br/>10.100.3.1 (primaire)"]
        F2["file-node02.infra.indio<br/>10.100.3.2 (secondaire)"]
    end
    VSAN[("vsanDatastore")] --> F1
    VSAN --> F2
    F1 & F2 -->|DNS| AD["DC AD<br/>10.100.2.241 / .242"]

    SAUV["seg-sauvegarde<br/>(Veeam)"] -->|NFS, svc_nfs_full<br/>règle sauvegarde-to-storage| F1
    SOC["seg-soc<br/>(syslog-ng INDSOC001)"] -.NFS, svc_nfs_full<br/>règle soc-to-storage-nfs<br/>usage non reconfirmé.-> F1

    F1 -->|export confirmé| SHARE1["/veeam"]
    F1 -.export documenté 07-17,<br/>non revu 07-19.-> SHARE2["/Log"]

    style SHARE2 stroke-dasharray: 5 5

Prérequis réseau NSX (propriété d'un autre dépôt, référencé ici)¶

Deux briques NSX, gérées dans /root/nsx (voir nsx.md), conditionnent l'accessibilité du service :

• Un profil MAC discovery dédié sur seg-storage (nsxt_policy_mac_discovery_profile.mac_learning_vsanfs, MAC learning activé) — sans lui, les FSVM sont injoignables malgré une gateway qui répond (root cause de la panne du 2026-07-05, détaillée plus bas).
• Un service NSX personnalisé svc_nfs_full couvrant les 5 ports/protocoles nécessaires à un montage NFSv3 complet (2049 TCP+UDP, 111 TCP+UDP, 20048 mountd, 32803 nlockmgr, 27689 statd) — les services NFS prédéfinis de NSX ne couvrent que 2049 (TCP/UDP) et 111/TCP, insuffisant.

Ce document ne duplique pas le détail Terraform de ces ressources — voir nsx.md.

Provisioning Terraform¶

Non applicable. Les FSVM sont des appliances système auto-déployées par vSAN/EAM (/Datacenter/vm/ESX Agents/), jamais créées par une ressource Terraform. Seuls les prérequis réseau qui les rendent joignables (profil MAC discovery, service NSX) sont en Terraform — dans le dépôt /root/nsx, pas ici.

Configuration Ansible¶

Non applicable. Ce ne sont pas des VM Rocky : port 22 fermé (vérifié en direct, voir plus bas), aucun agent ne peut y être déployé. Toute configuration passe exclusivement par l'UI vCenter (ou l'API vSphere privée sous-jacente, non exposée publiquement pour ce sous-système).

Procédure manuelle¶

Configuration du service et création d'un export, telle que faisable depuis l'UI vCenter (les valeurs listées sont les valeurs réelles actuellement en place, confirmées en direct) :

1. Prérequis réseau (fait au préalable côté NSX, voir plus haut) : profil MAC discovery avec MAC learning activé sur seg-storage, service svc_nfs_full et règles DFW correspondantes déjà en place.
2. Cluster > Configure > vSAN > Services > File Service > Enable.
3. Choisir le réseau de service : port group seg-storage (dvportgroup-2002), plage IP statique — 10.100.3.1 (primaire) et 10.100.3.2 (secondaire), masque /28, passerelle 10.100.3.14.
4. Configurer le domaine : nom interne (vsan-fs-indio), suffixe DNS infra.indio, serveurs DNS 10.100.2.241/10.100.2.242 — impératif d'utiliser ces IP (les vrais contrôleurs de domaine) et non 10.15.100.2 (résolveur par défaut côté ESXi, qui n'a pas la zone inversée nécessaire) : c'est l'erreur qui a précédé la panne initiale.
5. File Shares > Add : créer un partage (ex. /veeam ou /Log), choisir le(s) protocole(s) (NFSv3 et/ou NFSv4.1), un quota si souhaité, et la liste des réseaux clients autorisés.
6. Vérifier côté NSX que le segment source du client (ex. seg-sauvegarde ou seg-soc) a bien une règle DFW l'autorisant vers seg-storage sur svc_nfs_full (voir nsx.md) — sans cette règle, le montage échoue même avec le partage correctement configuré côté vSAN.
7. Côté client : mount -t nfs -o vers=3,soft,timeo=30,retrans=3 file-node01.infra.indio:/<partage> <point-de-montage> — toujours soft, jamais hard, vu l'instabilité documentée ci-dessous.

Procédure de déploiement¶

Non applicable — il n'existe pas de commande de "déploiement" pour ce service au-delà de la procédure manuelle ci-dessus (activation UI + création d'export). Aucun mécanisme ne permet de le recréer par du code.

Étude de cas : cycle de vie complet du service sur ce cluster¶

stateDiagram-v2
    [*] --> Initial: Service activé (config UI, historique non détaillé)
    Initial --> Panne: 2026-07-05<br/>MAC learning manquant sur seg-storage
    Panne --> Fixe: Fix NSX (nsx_policy_mac_discovery_profile<br/>mac_learning_vsanfs)
    Fixe --> Desactive: 2026-07-11<br/>Effet de bord maintenance esxi-node02<br/>(EAM désactive + détruit les 2 FSVM)
    Desactive --> Reactive: Constaté indirectement 07-16/07-17<br/>(pas une action explicite documentée)
    Reactive --> UtiliseLog: 07-16/07-17<br/>Export /Log créé et peuplé<br/>(archivage froid syslog-ng, .gz uniquement)
    UtiliseLog --> EtatIncertain: 07-19<br/>showmount ne liste plus que /veeam,<br/>mount de /Log bloque (timeout)
    EtatIncertain --> [*]

    note right of Panne
        no route to host malgré gateway
        joignable ; alarme "File Server"
        + reboot HA en boucle
    end note
    note right of Desactive
        Maintenance mode sur esxi-node02
        (pour un tout autre motif : prep
        transport node NSX) a fait évacuer
        des VM agents critiques -> EAM a
        désactivé le File Service sur TOUT
        le cluster et détruit les 2 FSVM
    end note
    note right of EtatIncertain
        Découvert lors de la rédaction de
        cette page (2026-07-19) - écart non
        expliqué, à investiguer
    end note

La panne initiale (2026-07-05) — MAC learning manquant¶

Les deux VM système "vSAN File Service Node" étaient injoignables (no route to host depuis le nœud de contrôle) malgré une gateway seg-storage qui répondait normalement — alarme "File Server" active avec redémarrage HA en boucle depuis la veille.

Root cause : mac_learning_enabled = false sur le profil MAC discovery par défaut appliqué à seg-storage. Les FSVM émettent/reçoivent avec des MAC non enregistrées auprès du segment (fonctionnement interne du cluster File Service) — sans MAC learning, NSX ne résout jamais leur adresse, d'où l'injoignabilité malgré une gateway fonctionnelle. Fixé côté NSX (nsxt_policy_mac_discovery_profile.mac_learning_vsanfs, voir nsx.md) — ce document ne duplique pas le détail Terraform de ce fix, seul son effet est pertinent ici.

Fausses pistes écartées pendant le diagnostic (utile si un incident similaire se reproduit) : pas un problème DFW (aucune règle deny, Default Layer3 Rule = ALLOW), pas le DHCP absent sur seg-storage (le service utilise des IP statiques, pas DHCP), pas un problème de routage ESXi→overlay (le shell ESXi joignait normalement les DC AD), et les erreurs Skyline Health affichées pendant le diagnostic étaient des résultats mis en cache d'une session de configuration précédente, pas un état live.

L'incident du 2026-07-11 : effet de bord d'une maintenance NSX¶

Le 2026-07-11, lors d'une opération de préparation NSX sans rapport direct (résoudre le fait qu'esxi-node02 n'avait jamais été préparé comme transport node NSX, voir vcenter-esxi.md et nsx.md), esxi-node02 a dû être placé en mode maintenance complet pour permettre à des VM système critiques (dont vCenter Server et nsx-manager, qui tournaient sur cet hôte) d'être évacuées proprement.

Effet de bord non anticipé : pour libérer l'agent VM du File Service qui bloquait l'opération, vim.eam (ESX Agent Manager) a désinstallé les agents des deux hôtes et désactivé le vSAN File Service sur tout le cluster, détruisant au passage les deux VM vSAN File Service Node. Le service est resté désactivé après coup — aucune réactivation explicite n'a été effectuée dans la session qui a traité cet incident.

Réactivation et usage comme cible d'archivage froid (07-16/07-17)¶

Aucune action de réactivation explicite du File Service n'est documentée entre le 07-11 et le 07-16. Le service a été constaté de nouveau actif en préparant l'archivage des logs (file-node01.infra.indio:/Log), et peuplé de dossiers d'applications réelles (vault, haproxy, netbox*, artefacts liés à kafka...) — preuve indirecte à l'époque que la réactivation avait bien eu lieu et que le service fonctionnait.

L'usage prévu : syslog-ng (INDSOC001) écrit ses logs en local sur un disque dédié de 2 To, puis un script de rétention transfère par rsync, périodiquement, uniquement les fichiers déjà compressés et clos (.log.gz) vers file-node01.infra.indio:/Log — jamais d'écriture continue directe sur ce NFS. Voir syslogng.md pour le détail du pipeline côté syslog-ng ; ce choix de conception est directement une conséquence de l'instabilité NFS documentée ci-dessous (découverte sur ce même service, pas une précaution générique).

Vérification en direct (2026-07-19) et écart constaté¶

Lors de la rédaction de cette page, une vérification en direct (lecture seule) a été faite plutôt que de se fier uniquement à l'historique ci-dessus :

# Confirme le service actif et les 2 FSVM déclarées
govc vsan.info /Datacenter/host/Cluster
#  -> FileServiceConfig.Enabled: true, 2 entrées FileServerIpConfig (10.100.3.1 primaire, 10.100.3.2)

govc ls "/Datacenter/vm/ESX Agents"
#  -> vSAN File Service Node (1), vSAN File Service Node (2)  [confirmé présentes]

# Ports réseau de file-node01 (10.100.3.1)
#  22   -> refusé (pas de SSH, cohérent avec le reste de cette page)
#  111  -> ouvert (portmapper)
#  2049 -> ouvert (NFS)
rpcinfo -p 10.100.3.1
#  -> portmapper, nfs (v3+v4), mountd (20048), nlockmgr (32803), status (27689)
#     exactement les ports couverts par svc_nfs_full côté NSX

# Ports réseau de file-node02 (10.100.3.2, secondaire) : les 3 (22/111/2049) refusés/filtrés
# depuis le nœud de contrôle — pas d'explication établie (voir Points d'attention)

showmount -e file-node01.infra.indio
#  -> Export list for file-node01.infra.indio:
#     /veeam *
#  (AUCUNE mention de /Log)

# Tentative de montage direct, en lecture seule, bornée dans le temps
timeout 15 mount -t nfs -o vers=3,soft,timeo=20,retrans=1,ro \
  file-node01.infra.indio:/Log /point-de-montage-local
#  -> timeout (code 124) : la commande n'a JAMAIS répondu, ni succès ni rejet propre,
#     jusqu'à être tuée par le timeout de sécurité. Pas de process bloqué en D-state
#     constaté après coup (nettoyage vérifié propre).

L'export **/veeam** (seul actuellement confirmé) n'est documenté dans aucun souvenir connu de cette page — son nom, le segment seg-sauvegarde dédié dans NSX et le dossier vCenter veeam/ (VM veeam, veeam-proxy01/02, veea-repo, hors IaC) suggèrent fortement qu'il s'agit du repository de sauvegarde Veeam, mais ce point relève de services/veeam.md, hors périmètre de cette page.

Points d'attention¶

• Aucune automatisation possible côté serveur. Pas de module Ansible, pas d'accès SSH, pas d'endpoint REST vSphere public fonctionnel pour piloter ce service (constaté, pas supposé) — toute action (création/suppression d'export, changement réseau) passe par l'UI vCenter.
• Instabilité NFS sous écriture continue, découverte et documentée en marge de cette page (contexte syslogng.md) : écrire en continu et directement sur un montage de ce service a provoqué un blocage D-state non interruptible (NFSv4.1) ou un échec silencieux sans erreur (NFSv3, plus aucune écriture n'aboutit sans message). Root cause jamais pleinement identifiée. Conception retenue en conséquence : écriture locale uniquement + rsync différé de fichiers déjà clos, avec timeout dur sur chaque cycle et vérification du point de montage avant d'écrire. Ne jamais faire écrire une application en continu directement sur un montage de ce service sans revalider ce comportement au préalable. Note : la tentative de montage read-only bornée effectuée le 07-19 pour cette page a reproduit la même classe de symptôme (absence de réponse plutôt qu'échec ou succès net), même sans écriture — l'instabilité ne semble donc pas limitée aux scénarios d'écriture continue.
• Micro-coupures réseau récurrentes observées (dmesg : "server file-node01.infra.indio not responding, timed out", plusieurs fois par heure) sur le flux /veeam-équivalent de 07-17 — non bloquantes uniquement grâce à la conception défensive (montage soft, mountpoint -q avant chaque cycle, timeout dur sur le rsync).
• Toute mise en maintenance d'un hôte du cluster peut désactiver ce service (précédent réel du 2026-07-11, voir postmortem ci-dessus) — vérifier systématiquement quelles VM agents/système tournent sur l'hôte concerné avant toute opération de maintenance (vcenter-esxi.md).
• file-node02 (nœud secondaire) ne répond sur aucun des 3 ports testés (22/111/2049) depuis le nœud de contrôle, contrairement à file-node01 — comportement non expliqué dans cette session (pourrait être normal pour un nœud non-primaire selon le design du File Service, ou révéler une restriction réseau/DFW distincte ; à investiguer si un besoin de bascule vers ce nœud se présente).
• L'export /Log documenté comme cible d'archivage froid n'a pas pu être reconfirmé le 2026-07-19 (voir section dédiée ci-dessus) — traiter l'usage "archivage syslog-ng" comme à revérifier, pas comme un fait acquis, tant qu'un humain n'a pas investigué plus en profondeur (le service NFS lui-même a montré, une fois de plus, un comportement instable plutôt qu'une réponse nette).
• Domaine interne du File Service (vsan-fs-indio) à ne pas confondre avec le domaine AD infra.indio — seuls le suffixe DNS et les serveurs DNS pointent réellement vers l'AD.