🏢 Storage Systems — Chapitres 9 & 10 : SAN et Stockage Objet

• Centraliser du stockage bloc hautement disponible.
• Fournir datastores partagés aux hyperviseurs.
• Servir bases de données enterprise à faible latence.
• Permettre snapshots/clones/réplication baie.
• Découpler capacité stockage et serveurs compute.

FC est historiquement le cœur du SAN enterprise. Il utilise des HBAs, switches FC, zoning par WWPN et fabrics généralement séparés A/B. La stabilité vient de l'isolation et du contrôle strict des chemins.

iSCSI encapsule SCSI dans TCP/IP. Il peut fonctionner sur Ethernet standard mais demande une discipline réseau : VLAN dédié, MTU cohérent, flow control si nécessaire, multipath, CHAP, séparation du trafic production.

# Linux discovery/login examples
iscsiadm -m discovery -t sendtargets -p 10.10.10.10
iscsiadm -m node --login
multipath -ll

NVMe/FC réduit l'héritage SCSI et exploite mieux les files NVMe. Il est pertinent avec baies all-flash et hosts récents. Le gain réel dépend du chemin complet : application, kernel, HBA, fabric, baie.

Le zoning contrôle qui peut parler à qui dans la fabric FC. Bonne pratique : single initiator zoning, c'est-à-dire une zone par initiator host avec les targets nécessaires.

Le LUN masking est côté baie : même si la fabric permet la communication, la baie ne présente la LUN qu'aux hosts ou groupes autorisés. Zoning et masking sont complémentaires.

1. Créer volume/LUN sur baie.
2. Créer ou identifier host avec WWPN/IQN.
3. Configurer zoning fabric A et B.
4. Mapper LUN au host group.
5. Rescan host.
6. Vérifier multipath.
7. Créer filesystem/datastore côté host.

multipath -ll
lsblk
lsscsi
cat /etc/multipath.conf
systemctl status multipathd
rescan-scsi-bus.sh

• Activer MPIO Feature.
• Ajouter support iSCSI/FC selon vendor DSM.
• Vérifier nombre de chemins dans Disk Management / mpclaim.
• Utiliser recommandations constructeur baie.

mpclaim -s -d
mpclaim -s -m

• Un seul chemin actif en production.
• Deux fabrics branchées sur le même switch physique.
• Zoning asymétrique A/B.
• Policy multipath non recommandée par constructeur.
• Timeouts OS incompatibles avec failover baie.

• Windows Failover Cluster avec disques partagés.
• Oracle RAC si architecture validée.
• Filesystems cluster uniquement si supportés.

• Créer trop de petites LUN sans gouvernance.
• Présenter une LUN à deux hosts non cluster-aware.
• Mélanger trafic iSCSI et LAN saturé.

• Latence garantie et QoS.
• Snapshots/clones/réplication inclus ou licences.
• Support NVMe/FC, FC, iSCSI.
• Compression/déduplication réelle selon workload.
• Intégrations VMware/Oracle/SQL Server/Kubernetes.

En SAN, la matrice de compatibilité est critique : firmware baie, switch, HBA, driver, OS, hyperviseur et multipathing doivent être cohérents.

• Deux fabrics indépendantes, pas juste deux VLANs sur le même switch.
• Zoning maintenu symétriquement.
• Firmware switches compatible.
• Monitoring erreurs ports, CRC, flaps.

• Réseau management séparé.
• RBAC baie.
• Syslog/SNMP/API monitoring.
• Exports configuration réguliers.

# Linux
multipath -ll
iostat -x 1
lsscsi
systool -c fc_host -v

# VMware concepts
esxtop storage views
adapter/device latency
queue depth

• Suivre recommandations vendor pour HBA driver/firmware.
• Équilibrer LUN ownership et chemins optimisés ALUA.
• Ne pas augmenter queue depth globalement sans comprendre baie.
• Mesurer depuis host et baie.

• VLAN dédié ou réseau physique dédié.
• CHAP mutuel si possible.
• Pas de routage large vers initiators.
• ACL firewall strictes.

• Comptes nominatifs admin baie.
• MFA si disponible.
• Journaliser création/suppression LUN, mapping, snapshot.
• Exporter logs vers SIEM.

Le secure erase ou crypto-erase doit être prévu pour LUN décommissionnées, notamment en environnement multi-tenant ou données sensibles.

• Snapshots rapides pour rollback technique.
• Clones pour dev/test.
• Attention cohérence applicative.
• Surveiller réserve snapshot/capacité.

• Lire matrice compatibilité.
• Planifier fenêtre.
• Vérifier redondance paths avant update.
• Exporter configuration avant changement.

• Besoin block partagé pour hyperviseurs.
• Applications enterprise certifiées SAN.
• Faible latence et haute disponibilité.
• Snapshots/clones/réplication baie nécessaires.

• Simple partage fichiers : NAS suffit.
• Archive massive API : object storage préférable.
• Budget/compétence insuffisants pour double fabric.

• Ports fabric erreurs CRC/flap.
• Paths MPIO perdus.
• Latence host et baie.
• Capacité pool et snapshots.
• Réplication en retard.

• WWPN/IQN par host.
• LUN ID, volume name, owner app.
• Zones A/B.
• Policy multipath.
• Procédure restore et rollback.

• Scalabilité massive.
• API standard cloud-native.
• Durabilité élevée via réplication/erasure coding.
• Lifecycle chaud/froid/archive.
• Metadata et événements.

Le versioning protège contre écrasement et suppression accidentelle, mais augmente fortement la capacité consommée si non gouverné.

Rule examples:
- transition logs/* to infrequent access after 30 days
- transition archives/* to archive after 90 days
- delete incomplete multipart uploads after 7 days
- expire non-current versions after 180 days

• Bucket policy pour règles globales.
• IAM policy pour identités.
• Presigned URL pour accès temporaire.
• Block public access par défaut.

• Bloc : l'application/OS gère filesystem.
• Fichier : le serveur NAS gère arborescence et locks.
• Objet : l'application gère clés, metadata, idempotence, retries.

• Classes de stockage par température.
• Hardware commodity pour solutions privées.
• Lifecycle automatique.
• Attention aux coûts cachés : requêtes, egress, versions, réplication.

• API HTTP simple.
• Intégration IAM/KMS/events.
• Traitements serverless/data pipelines.
• CDN origin naturel.

Des milliards de petits objets peuvent saturer metadata, coût de requêtes, listings et lifecycle. Il faut packager, partitionner les clés ou utiliser formats adaptés comme Parquet pour analytics.

Les modèles de cohérence ont évolué selon fournisseurs, mais l'application doit rester robuste : retries idempotents, gestion concurrence, pagination, erreurs réseau.

• Egress réseau.
• Opérations PUT/GET/LIST.
• Non-current versions.
• Multipart uploads incomplets.
• Restauration archive payante/lente.

• Compatibilité S3 réelle.
• Durabilité et failure domains.
• IAM/KMS/Object Lock.
• Lifecycle et classes froides.
• Coût egress et requêtes.
• Support SDK et outils backup.

• Cible backup économique.
• Object Lock/WORM pour immutabilité.
• Lifecycle vers cold/archive.
• Réplication cross-region/site.

• Images produits et assets web.
• Vidéos et transcodage.
• Origin CDN.
• Presigned URLs pour accès temporaire.

• Datasets d'entraînement.
• Checkpoints modèles.
• Logs applicatifs massifs.
• Exports analytics.

Object Lock/WORM empêche modification ou suppression pendant une période. C'est un pilier anti-ransomware pour backups et archives réglementaires.

• Log des accès objets sensibles.
• Détection bucket public.
• Alertes mass delete.
• Inventaire objets et chiffrement.
• Analyse permissions effectives.

• Multiplier connexions et workers.
• Éviter listings globaux.
• Partitionner clés par date/projet/tenant.
• Utiliser CDN/cache pour reads publics.

• Egress inter-région/Internet.
• Requêtes LIST/GET/PUT.
• Versions anciennes.
• Replication double stockage.
• Restore archive.
• Multipart incomplets.

Policies:
- Abort incomplete multipart uploads after 7 days
- Move logs to IA after 30 days
- Move archives to cold after 90 days
- Expire non-current versions after 180 days
- Delete temporary prefixes after 14 days

L'EC découpe les objets en fragments data + parity pour améliorer rendement capacité tout en tolérant des pannes de disques/nœuds/racks.

• Disque.
• Nœud.
• Rack.
• Salle.
• Zone/région.

Le service metadata est souvent le point critique : listings, versioning, policies, tags, ACL. Une architecture objet performante protège et scale aussi cette couche.

• Block public access par défaut.
• Encryption at rest et TLS.
• Object Lock pour backups critiques.
• Audit logs activés.
• Rotation clés et secrets.

• Alertes coût/budget.
• Alertes erreurs 4xx/5xx.
• Monitoring egress.
• Inventaire objets sensibles.
• Tests restore depuis archive.