> For the complete documentation index, see [llms.txt](https://docs.verge.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.verge.io/learn-the-platform/fr/module-5-stockage/01-vsan-architecture.md).
# Architecture vSAN et VergeFS
## VergeFS : service de stockage intégré
Le module 1 a présenté les concepts de vSAN à un niveau général. Cette page va plus loin dans l’architecture interne — comment les blocs sont hachés et distribués, comment les lectures et écritures circulent dans le système, et comment des fonctionnalités comme la déduplication, le chiffrement et les instantanés sont implémentées au niveau des blocs.
## Architecture au niveau des blocs
Au cœur de VergeFS se trouve un **moteur de stockage au niveau des blocs**. Chaque fragment de données écrit dans le vSAN — qu’il s’agisse d’un disque de VM, d’un instantané, d’une image ISO ou de métadonnées système — est divisé en **blocs de données**. Chaque bloc reçoit un **hachage de contenu SHA-1** qui sert d’identifiant unique dans l’ensemble du système. SHA-1 est utilisé ici pour l’adressage par contenu et la distribution, et non pour la sécurité cryptographique.
Ce hachage est la base de presque toutes les fonctionnalités du vSAN :
* **Distribution** — Le hachage détermine quels nœuds stockent les copies principale et redondante du bloc
* **Déduplication** — Des blocs identiques produisent des hachages identiques, donc une seule copie est stockée
* **Intégrité** — Le hachage valide le contenu du bloc, ce qui permet une détection continue de la dégradation des bits
* **Dérivation de l’emplacement** — Le hachage, combiné aux cartes de périphériques par niveau stockées sur le Tier 0, dérive de manière déterministe l’emplacement physique de chaque bloc
### La carte de hachage et le Tier 0
Le placement des blocs dans vSAN est **dérivé du hachage de contenu SHA-1** combiné aux cartes de périphériques par niveau stockées sur **Niveau 0** les disques (SSD NVMe à haute endurance) :
* Chaque niveau conserve une `0.map` (carte des périphériques de copie principale) et `1.map` (carte des périphériques de copie secondaire)
* Le hachage SHA-1 est utilisé comme entrée pour un calcul de placement déterministe appliqué à ces cartes — il n’existe pas de table centrale enregistrant « le bloc X se trouve sur le nœud Y, le disque Z »
* Les comptages de références sont **pas** stockés de façon persistante dans une table de hachage — ils sont reconstruits par le parcours différentiel **vSAN Walk** lorsqu’il parcourt les hachages actifs
* L’index du système de fichiers du Tier 0 et les cartes de périphériques par niveau sont ce que le Tier 0 contient réellement, en plus des métadonnées vSAN
**Le Tier 0 est exclusivement un niveau de métadonnées.** Il stocke l’index du système de fichiers vSAN et les cartes de périphériques par niveau. C’est **pas** un cache de performance, et il ne **pas** stocke pas les données de charge de travail. Comme les opérations de métadonnées vSAN dépendent du Tier 0, les performances de vos disques Tier 0 ont un impact direct sur la réactivité globale du système.
{% hint style="warning" %}
**Le Tier 0 est uniquement destiné aux métadonnées**
Le Tier 0 ne **pas** fonctionne pas comme un cache de performance ni comme un niveau de données chaudes. Il stocke uniquement l’index du système de fichiers vSAN et les cartes de périphériques par niveau. Les données de charge de travail résident sur les Tiers 1 à 5. Utilisez toujours des disques NVMe d’entreprise évalués pour 3 DWPD ou l’équivalent pour le Tier 0, et conservez au moins 30 % d’espace libre.
{% endhint %}
### Comment fonctionne la carte de hachage
Le schéma suivant illustre comment les données des VM circulent dans l’architecture vSAN au niveau des blocs :
Le processus fonctionne comme suit :
1. Une VM écrit des données sur son disque virtuel
2. VergeFS divise l’écriture en blocs de données
3. Chaque bloc reçoit un hachage de contenu SHA-1
4. Le calcul de placement appliqué aux cartes de périphériques par niveau (stockées sur le Tier 0) sélectionne un emplacement principal et un emplacement redondant
5. Le bloc est écrit à la fois sur un nœud principal et sur un nœud redondant
6. Les mises à jour de métadonnées du Tier 0 sont regroupées par lots et appliquées de manière asynchrone
## Distribution des données basée sur le hachage
vSAN distribue les blocs de données sur tous les nœuds participant au stockage à l’aide d’une **algorithme de distribution basé sur le hachage**. Cela garantit une charge d’E/S équilibrée, une tolérance aux pannes et une mise à l’échelle efficace.
### Chemin d’écriture
Lorsqu’une VM écrit des données :
1. VergeFS divise les données en blocs et calcule un hachage de contenu SHA-1 pour chacun
2. Le calcul de placement appliqué aux cartes de périphériques par niveau détermine un **nœud principal** et un **nœud redondant** — le contrôleur se trouve **pas** dans le chemin d’écriture des données
3. Si un hachage identique existe déjà, l’écriture est **dédupliquée** (aucun nouveau bloc de données n’est écrit ; la déduplication est une conséquence naturelle de l’adressage par contenu)
4. Pour les nouveaux blocs, les deux copies sont écrites **simultanément** sur le réseau Core Fabric directement vers les nœuds cibles
5. L’écriture est **confirmée uniquement après validation des deux copies** — garantissant la durabilité des données avant que la VM ne reçoive un signal de fin d’écriture
6. Les mises à jour de métadonnées sur le Tier 0 sont **regroupées par lots** et appliquées de manière asynchrone plutôt que de sérialiser le chemin des données à travers un index central
### Chemin de lecture
Lorsqu’une VM lit des données :
1. L’emplacement du bloc est dérivé de son hachage de contenu et des cartes de périphériques par niveau
2. Le système **privilégie la lecture à partir de la copie principale**
3. Si une copie redondante existe sur le **même nœud que la VM demandeuse**, VergeFS lit la **copie locale** pour minimiser le trafic réseau (read-local-prefer)
4. Si la copie principale est lente ou ne répond pas, VergeFS **bascule automatiquement vers la copie redondante** — de manière transparente, sans interruption pour la VM
```mermaid
flowchart TB
VM["Demande de lecture VM"] --> LOOKUP["Déduire l’emplacement
à partir du hachage de contenu"]
LOOKUP --> LOCAL{"Copie locale
disponible ?"}
LOCAL -->|Oui| READLOCAL["Lire la copie redondante
locale"]
LOCAL -->|Non| PRIMARY["Lire à partir du
nœud principal"]
PRIMARY --> HEALTHY{"Le nœud principal
répond-il ?"}
HEALTHY -->|Oui| RETURN["Retourner les données
à la VM"]
HEALTHY -->|Non| FAILOVER["Basculement vers
la copie redondante"]
READLOCAL --> RETURN
FAILOVER --> RETURN
style VM fill:#e3f2fd,stroke:#1565c0
style LOOKUP fill:#fff3e0,stroke:#e65100
style RETURN fill:#e8f5e9,stroke:#2e7d32
```
### Distribution entre nœuds
Les blocs de données sont distribués sur **tous les nœuds participant au stockage** au sein de chaque niveau. Cette conception offre :
* **Performances équilibrées** — La charge d’E/S est répartie sur tous les nœuds, évitant les points chauds
* **Tolérance aux pannes** — Aucun nœud unique ne détient toutes les copies d’un ensemble de données
* **Montée en charge efficace** — L’ajout d’un nœud étend automatiquement le pool de stockage et déclenche un rééquilibrage
* **E/S parallèles** — Plusieurs nœuds servent les données simultanément, augmentant le débit global
## Déduplication globale en ligne
VergeOS vSAN effectue **une déduplication globale en ligne** qui est toujours activée et ne nécessite aucune configuration. Comme chaque bloc de données est identifié par son hachage de contenu, la déduplication est une conséquence naturelle de l’architecture :
1. Lorsqu’un nouveau bloc est écrit, son hachage est calculé
2. Si un hachage identique existe déjà, le bloc est un doublon — la déduplication est une conséquence naturelle de l’adressage par contenu
3. Pour les blocs en double, aucun espace de stockage supplémentaire n’est consommé — le bloc existant est simplement référencé à nouveau
4. Cela fonctionne **en ligne** (pendant le chemin d’écriture), et non comme une tâche en arrière-plan
La déduplication fonctionne **sur toutes les VM, tous les niveaux et tous les types de données** dans le système. Les cas courants où la déduplication apporte des économies d’espace significatives incluent :
* Plusieurs VM exécutant le même système d’exploitation (blocs OS partagés)
* Déploiements de VM basés sur des modèles (images de base clonées)
* Environnements de développement avec des configurations similaires
* Instantanés de sauvegarde avec peu de changements de données entre les itérations
Les taux de déduplication sont visibles dans le tableau de bord de stockage VergeOS, montrant généralement les économies de capacité effectives sur chaque niveau.
{% hint style="info" %}
**Pont VMware**
Vous venez de VMware vSAN ? La déduplication VergeOS est toujours activée, en ligne et globale sur tous les types de niveaux (NVMe, SSD, HDD) — il n’y a pas de bascule à activer ni d’étape d’activation séparée.
{% endhint %}
## Compression
VergeOS vSAN ne **pas** compresse pas les données au repos. Contrairement aux plateformes qui appliquent une compression en ligne aux blocs stockés, VergeFS stocke les données sur disque dans leur forme d’origine.
**La compression n’est appliquée que lors de la réplication site-sync** — lorsque les données sont transmises entre les sites VergeOS via le réseau. Dans ce contexte, la compression réduit la consommation de bande passante pendant les transferts WAN sans affecter les performances du stockage local.
Ce choix de conception garde le chemin d’E/S local simple et rapide. La déduplication (décrite ci-dessus) fournit le principal avantage d’efficacité d’espace pour les données stockées.
## Chiffrement AES-256 au repos
vSAN prend en charge **le chiffrement AES-256 au repos**, configuré lors de l’installation initiale de VergeOS. Points clés :
| Aspect | Détail |
| ---------------------------------- | ------------------------------------------------------------------------------ |
| **Algorithme** | AES-256 |
| **Moment de configuration** | Uniquement lors de l’installation initiale |
| **Réversibilité** | Non réversible après l’installation |
| **Portée** | Toutes les données sur tous les niveaux sont chiffrées de manière transparente |
| **Option de stockage de la clé 1** | Clés USB branchées sur les deux premiers nœuds de contrôleur |
| **Option de stockage de la clé 2** | Saisie manuelle du mot de passe à chaque démarrage du système |
Le chiffrement est transparent pour les VM et les applications — elles lisent et écrivent les données normalement tandis que VergeFS gère le chiffrement et le déchiffrement au niveau des blocs. La configuration du chiffrement s’applique à l’échelle du système ; vous ne pouvez pas chiffrer certains niveaux et laisser les autres non chiffrés.
Pour vérifier l’état du chiffrement : accédez à **Nœuds > Nœud 1 > Disques**, double-cliquez sur le premier disque et vérifiez la case **Chiffré** .
## Modèles de redondance
vSAN conserve plusieurs copies de chaque bloc de données pour se protéger contre les pannes matérielles. La redondance est configurée au **niveau système** et s’applique **par niveau** — et non par VM ou par conteneur de stockage.
| Fonctionnalité | N+1 (RF2) — Par défaut | N+2 (RF3) |
| ----------------------------------------------- | ---------------------- | --------- |
| **Copies des données** | 2 | 3 |
| **Pannes simultanées tolérées** | 1 nœud | 2 nœuds |
| **Nœuds contrôleurs minimum** | 2 | 3 |
| **Nœuds recommandés** | 3 | 5 |
| **Surcharge de stockage** (avant déduplication) | \~2x | \~3x |
**N+1 (RF2)** est la valeur par défaut et convient à la plupart des environnements de production. Elle conserve deux copies de chaque bloc sur différents nœuds, en tolérant une panne de nœud simultanée.
**N+2 (RF3)** conserve trois copies sur trois nœuds ou plus, en tolérant deux pannes simultanées. Cette option est conçue pour les charges de travail ultra-critiques ou les sites distants/de périphérie où le matériel de remplacement ne peut pas arriver rapidement.
Une panne n’affecte que le **niveau où se trouvent les disques défaillants** — les autres niveaux restent pleinement opérationnels. Par exemple, dans un système N+2, si les disques du Tier 1 tombent en panne sur deux nœuds et qu’un disque du Tier 4 tombe en panne sur un troisième nœud, le cluster reste opérationnel sans perte de données.
{% hint style="success" %}
**Serveur de réparation**
Pour une protection supplémentaire au-delà du niveau de redondance configuré, un **Serveur de réparation** peut être configuré pour récupérer automatiquement les blocs de données manquants depuis une destination de synchronisation si les pannes dépassent le niveau de redondance configuré — ce qui peut éviter un retour complet à un instantané.
{% endhint %}
## Auto-réparation
Lorsqu’un nœud ou un disque tombe en panne, vSAN détecte automatiquement la défaillance et commence la récupération sans intervention manuelle :
```mermaid
flowchart LR
A["Panne de disque ou de nœud
détectée"] --> B["Lectures/écritures redirigées
vers les copies redondantes"]
B --> C["Les VM continuent
de fonctionner — zéro interruption"]
B --> D["La reconstruction automatique
commence immédiatement"]
D --> E["Les blocs manquants sont
répliqués à nouveau vers
les nœuds sains"]
E --> F["Redondance complète
restaurée"]
style A fill:#fce4ec,stroke:#c62828
style C fill:#e8f5e9,stroke:#2e7d32
style F fill:#e8f5e9,stroke:#2e7d32
```
Le processus d’auto-réparation :
1. **Détection** — vSAN surveille en continu l’état des disques et des nœuds. Les pannes sont détectées automatiquement.
2. **Basculement** — Les lectures et écritures sont immédiatement redirigées vers les copies redondantes. Les VM ne subissent aucune interruption.
3. **Reconstruction** — Les blocs de données manquants sont répliqués à nouveau depuis les copies survivantes vers les nœuds sains restants. Cela se fait en arrière-plan pendant que les charges de travail continuent de s’exécuter.
4. **Restauration** — Une fois tous les blocs répliqués à nouveau, le niveau revient à sa redondance configurée.
### Intégrité des données
Au-delà de la récupération après panne, vSAN effectue **une détection continue de la dégradation des bits** à l’aide de la validation par hachage. Le hachage stocké de chaque bloc est vérifié périodiquement par rapport à son contenu. Si une corruption est détectée, le bloc est automatiquement réparé à partir d’une copie redondante valide.
## Instantanés et clones économes en espace
L’architecture au niveau bloc de vSAN permet **des instantanés économes en espace** qui consomment très peu de stockage supplémentaire :
* Un instantané enregistre l’état **de l’index du système de fichiers à un instant donné** — il ne copie pas les blocs de données
* Les blocs référencés par un instantané sont conservés même si la VM d’origine les supprime (comptage de références)
* Les clones fonctionnent de manière similaire — ils référencent les mêmes blocs sous-jacents, ne consommant de l’espace supplémentaire que lorsque les données divergent (copy-on-write)
* Les instantanés peuvent être rendus **immuables via un indicateur facultatif** avec les états Déverrouillé/Verrouillé/Déverrouillage et un délai de déverrouillage de sept jours une fois verrouillé ; les instantanés par défaut peuvent être supprimés. Verrouillez les instantanés lorsque vous avez besoin d’une protection contre les rançongiciels ou de garanties de rétention.
### Suppression et collecte des déchets
Lorsqu’une VM, un disque ou un instantané est supprimé :
1. Les hachages du fichier sont supprimés de l’arborescence du répertoire vSAN
2. Le **vSAN Walk** le parcours différentiel redérive les comptages de références à partir des hachages actifs restants — les comptages ne sont pas stockés, ils sont reconstruits au fur et à mesure que le parcours avance
3. Les blocs qui atteignent zéro référence attendent environ **10 parcours (\~70 secondes)** avant d’être éligibles à la récupération, offrant une fenêtre de sécurité contre les changements rapides
4. L’espace de stockage physique est libéré de manière asynchrone lorsque le parcours récupère ces blocs
C’est pourquoi l’espace de stockage peut ne pas diminuer immédiatement après une suppression — la récupération se fait de manière asynchrone pendant les opérations d’arrière-plan vSAN Walk.
## Points clés
| Concept | Résumé |
| -------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **VergeFS** | Stockage distribué intégré — pas de SAN/NAS externe, pas de surcharge CVM |
| **Architecture des blocs** | Toutes les données sont divisées en blocs, chacun identifié par un hachage de contenu SHA-1 |
| **Niveau 0** | Uniquement des métadonnées (index du système de fichiers + cartes de périphériques par niveau). Pas de cache. Requis sur les nœuds de contrôleur (nœuds 1 à 2 pour N+1, 1 à 3 pour N+2). |
| **Distribution** | Basé sur le hachage, réparti sur tous les nœuds participant au stockage par niveau |
| **Déduplication** | En ligne, toujours activé, global sur tous les niveaux — aucune configuration |
| **Compression** | Pas au repos — uniquement pendant la réplication de synchronisation de site |
| **Chiffrement** | AES-256 au repos, configuré à l’installation, non réversible |
| **Redondance** | N+1 (2 copies, par défaut) ou N+2 (3 copies) — à l’échelle du système par niveau |
| **Auto-réparation** | Basculement et reconstruction automatiques en cas de panne, détection continue de la dégradation des bits |
| **Instantanés** | Références de hachage à un instant donné, économes en espace ; l’immuabilité est facultative (Déverrouillé/Verrouillé/Déverrouillage, délai de déverrouillage de 7 jours) |
## Étapes suivantes
Maintenant que vous comprenez l’architecture interne de vSAN, le sujet suivant explique le fonctionnement du système de niveaux en pratique — configuration des niveaux, attribution des disques, planification de la capacité et mise à l’échelle du stockage : [**Niveaux de stockage**](/learn-the-platform/fr/module-5-stockage/02-storage-tiers.md)
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://docs.verge.io/learn-the-platform/fr/module-5-stockage/01-vsan-architecture.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.