Stockage : vSAN et Ceph¶

Concepts de stockage¶

Le stockage est un pilier fondamental de toute infrastructure. Comprendre les differentes approches permet de choisir la solution adaptee a chaque besoin.

DAS vs NAS vs SAN vs HCI¶

Type	Signification	Protocole	Avantage principal	Inconvenient
DAS	Direct Attached Storage	SATA, SAS, NVMe	Simple, performant, pas de reseau	Isole, non partage entre serveurs
NAS	Network Attached Storage	NFS, SMB/CIFS	Partage de fichiers facile	Performances limitees par le reseau
SAN	Storage Area Network	iSCSI, FC, NVMe-oF	Hautes performances, dedie	Couteux, complexe a administrer
HCI	HyperConverged Infrastructure	vSAN, Nutanix	Stockage + compute integres	Scalabilite liee aux hotes

Niveaux RAID¶

Le RAID (Redundant Array of Independent Disks) protege les donnees contre les pannes de disques :

Niveau	Principe	Disques min.	Overhead	Tolerance	Usage
RAID 0	Striping (pas de redondance)	2	0%	0 panne	Jamais en production
RAID 1	Mirroring (copie exacte)	2	50%	1 panne	OS, boot, logs critiques
RAID 5	Striping + 1 parite distribuee	3	33%	1 panne	Usage general
RAID 6	Striping + 2 parites	4	50%	2 pannes	Stockage critique
RAID 10	Mirror + Stripe	4	50%	1 par paire	Bases de donnees haute perf

Replication¶

La replication copie les donnees entre sites ou entre systemes pour assurer la continuite d'activite :

• Synchrone : chaque ecriture est confirmee sur les deux sites avant validation (RPO=0, latence ajoutee)
• Asynchrone : les ecritures sont envoyees en arriere-plan (RPO > 0, meilleures performances)

---

vSAN Enterprise Plus¶

vSAN transforme les disques locaux des hotes ESXi en un datastore distribue unique. C'est le socle de notre architecture hyperconvergee (HCI).

Distribution des donnees¶

Lorsqu'une VM ecrit des donnees, vSAN les decompose en composants distribues sur plusieurs hotes selon la politique FTT :

graph TB
    VM["VM critique<br/>ecrit un bloc"]

    subgraph CLUSTER["Cluster vSAN - FTT=1 RAID-1"]
        subgraph H1["Hote 1"]
            C1["Composant<br/>Copie 1"]
            W1["Witness"]
        end
        subgraph H2["Hote 2"]
            C2["Composant<br/>Copie 2"]
        end
        subgraph H3["Hote 3"]
            C3["Composant<br/>Temoin"]
        end
    end

    VM -->|"Ecriture"| C1
    C1 -->|"Replication<br/>synchrone"| C2
    C1 -.->|"Metadata"| W1

Optimisations vSAN¶

Fonctionnalite	Description	Impact
Compression	Reduire la taille des blocs avant ecriture	Gain de 30-50% d'espace
Deduplication	Eliminer les blocs dupliques dans un disk group	Gain de 20-40% supplementaire
Erasure Coding	Alternative au mirroring (RAID-5/6)	Meilleur ratio capacite/protection
Chiffrement at rest	AES-256 sur tous les disques	Conformite securite, impact perf < 5%

Stretched Cluster : replication synchrone inter-sites¶

Le vSAN Stretched Cluster maintient une copie synchrone des donnees sur chaque site. Un witness sur un troisieme site assure le quorum.

graph LR
    subgraph SITE_A["Site A - Actif"]
        DA["Donnees Copie 1<br/>4 hotes ESXi<br/>NVMe vSAN"]
    end

    subgraph SITE_B["Site B - Actif"]
        DB["Donnees Copie 2<br/>4 hotes ESXi<br/>NVMe vSAN"]
    end

    subgraph WITNESS["Site Witness"]
        W["Witness VM<br/>Quorum seulement"]
    end

    DA <-->|"Replication synchrone<br/>RPO = 0 | latence < 5ms"| DB
    DA ---|"Heartbeat"| W
    DB ---|"Heartbeat"| W

Chiffrement au repos¶

vSAN chiffre toutes les donnees sur disque avec AES-256 via un serveur de gestion de cles (KMS). Le chiffrement est transparent pour les VMs et n'impacte les performances que de 3 a 5%.

---

Ceph : stockage distribue¶

Ceph est un systeme de stockage distribue open-source capable de fournir simultanement du stockage bloc, fichier et objet sur une meme infrastructure.

Architecture RADOS¶

RADOS (Reliable Autonomic Distributed Object Store) est le coeur de Ceph. Il se compose de trois types de daemons :

graph TB
    CLIENT["Clients<br/>VMs / Applications"]

    subgraph CEPH["Cluster Ceph RADOS"]
        subgraph MONS["Monitors - MON"]
            MON1["MON 1<br/>Cluster map"]
            MON2["MON 2<br/>Cluster map"]
            MON3["MON 3<br/>Quorum"]
        end

        subgraph OSDS["Object Storage Daemons - OSD"]
            OSD1["OSD 1<br/>Disque 1"]
            OSD2["OSD 2<br/>Disque 2"]
            OSD3["OSD 3<br/>Disque 3"]
            OSD4["OSD 4<br/>Disque 4"]
        end

        subgraph MDS_G["Metadata Server - MDS"]
            MDS1["MDS<br/>CephFS metadata"]
        end
    end

    CLIENT --> MONS
    CLIENT --> OSDS
    MONS --> OSDS
    MDS_G --> OSDS

Daemon	Role	Quantite recommandee
MON (Monitor)	Maintient la carte du cluster (OSD map, PG map, CRUSH map). Les MON forment un quorum Paxos pour la coherence.	Nombre impair : 3 ou 5
OSD (Object Storage Daemon)	Un daemon par disque physique. Gere le stockage, la replication et la recuperation des donnees.	1 par disque (dizaines a milliers)
MDS (Metadata Server)	Gere les metadonnees du systeme de fichiers CephFS (arborescence, permissions). Necessaire uniquement pour CephFS.	1 actif + 1 standby

Algorithme CRUSH¶

CRUSH (Controlled Replication Under Scalable Hashing) est l'algorithme qui determine ou placer chaque objet dans le cluster :

1. Le client calcule un hash de l'objet pour determiner son Placement Group (PG)
2. CRUSH mappe le PG vers un ensemble d'OSDs en respectant les regles de placement (site, rack, hote)
3. Pas de table de correspondance centralisee : chaque client peut calculer l'emplacement directement

Pools et Placement Groups (PG)¶

• Pool : conteneur logique avec ses propres regles de replication (taille, type CRUSH)
• Placement Group (PG) : sous-ensemble d'objets assignes a un meme ensemble d'OSDs. Les PGs permettent de gerer efficacement des millions d'objets sans correspondance individuelle

Protocoles d'acces Ceph¶

Protocole	Type	Usage	Equivalent
RBD (RADOS Block Device)	Bloc	Disques virtuels pour VMs, volumes Kubernetes	iSCSI, FC LUN
CephFS	Fichier	Systeme de fichiers distribue POSIX, partages	NFS, SMB
RGW (RADOS Gateway)	Objet	API compatible S3 et Swift	AWS S3, MinIO

---

Recapitulatif des capacites¶

Type	Technologie	Brut	Utilisable	Perte	Usage principal
vSAN	NVMe SSD	200 To	~140 To	~30% (FTT=1 + meta)	VMs critiques, BDD
Ceph	HDD + SSD cache	500 To	~350 To	~30% (replication x3)	Mail, fichiers, objets S3
Veeam	HDD SATA	300 To	~250 To	~17% (FS overhead)	Sauvegardes, retention

---

Lab : Cluster Ceph¶

Le cluster Ceph du lab est deploye sur 3 VMs dans le VLAN 102 (stockage), avec un troisieme noeud en mode arbiter pour economiser les ressources tout en maintenant le quorum.

VM	IP	VLAN	Role	CPU	RAM
INF-KSTO60A	10.15.100.193	102	MON + OSD	4 vCPU	16 Go
INF-KSTO60B	10.15.100.194	102	MON + OSD	4 vCPU	16 Go
INF-KSTO60C	10.15.100.195	102	Arbiter (MON only)	2 vCPU	8 Go

graph TB
    subgraph CEPH["Cluster Ceph - VLAN 102 (10.15.100.192/28)"]
        subgraph N1["INF-KSTO60A (.193)"]
            MON1["MON"]
            OSD1["OSD x2<br/>Disques virtuels"]
        end
        subgraph N2["INF-KSTO60B (.194)"]
            MON2["MON"]
            OSD2["OSD x2<br/>Disques virtuels"]
        end
        subgraph N3["INF-KSTO60C (.195)"]
            MON3["MON Arbiter<br/>Quorum seulement"]
        end
    end

    N1 <-->|"Replication<br/>donnees"| N2
    N1 ---|"Heartbeat"| N3
    N2 ---|"Heartbeat"| N3

    subgraph CLIENTS["Clients"]
        RBD["RBD<br/>Blocs VMs"]
        FS["CephFS<br/>Partages"]
        S3["RGW<br/>Objet S3"]
    end

    CLIENTS --> CEPH

Usages du Ceph dans notre lab¶

• RBD : volumes bloc pour les VMs OpenStack et les services non-VMware
• CephFS : partages de fichiers pour les repositories Nexus et les donnees applicatives
• RGW : stockage objet compatible S3 pour l'archivage et les sauvegardes applicatives