Systèmes de fichiers et synchronisation

Résumé succinct

Un système de fichiers est un équilibre entre l'intégrité, les performances et les opérations. La synchronisation parle du modèle de cohérence et de résolution des conflits, pas seulement de « copier les fichiers ». Nous commençons par les exigences (p95 latency, RPO/RTO, type de charge), sélectionnez FS et protocole, configurez le journal et les verrous, définissez SLO, automatisez les snapshots/versioning et utilisez des outils de synchronisation corrects.

Sélection d'un système de fichiers sous la charge

Universal Linux FS

ext4 est un « cheval de travail » stable. Options : 'noatime, nodiratime, discard (avec soin), data = ordered'. Bon pour les disques VM, les catalogues partagés, les artefacts CI.
XFS - Fort sur les grands fichiers/parallélisme (contenu multimédia, logs, DWH). Options : 'noatime, inode64' ; pour les fichiers volumineux, il faut configurer 'reflink = 1' (clone).
ZFS - CoW, test d'intégrité, snapshots/réplique 'send/recv', ARC/L2ARC, ZIL/SLOG pour sync. Excellent pour les backups, NAS, pools de base avec exigence d'intégrité.
Btrfs - CoW, snapshots/compression/RAID dans userspace ; bien sous dev/test et edge, attention aux OLTP sans tuning.

Windows/crossplatform

NTFS - ACL, ADS, est fiable pour SMB ; 'DisableLastAccess' pour les performances.
exFAT - médias amovibles, sans droits et sans journal (pas pour la prod).

Paramètres affectant la fiabilité et la vitesse

Journal et barrières : 'data = ordered' (ext4 par défaut) est l'équilibre ; 'data = journal' est plus sûr, mais plus lent ; assurez-vous que les barreaux d'écriture sont activés (ou le contrôleur avec BBU/PLP).
fsync/sync : les flux critiques (journaux/transactions) doivent appeler explicitement 'fsync ()' ; sinon, une perte dans un accident est possible.
atime : 'relatime '/' noatime' réduit la pression d'écriture.
xattr/ACL : activez si vous avez besoin d'ACL POSIX et d'étiquettes de sécurité.
Taille des blocs/recordsize : ZFS 'recordsize = 16K' pour la base de données ; « 1M » pour les grands médias.

Exemples de montage :

bash ext4 for CI artifacts
UUID=... /var/lib/ci ext4 noatime,nodev,nosuid,data=ordered 0 2
XFS for Media Directories
UUID=... /srv/media xfs noatime,attr2,inode64 0 0
ZFS for backups and snapshots (creation)
zpool create tank mirror nvme0n1 nvme1n1 zfs set compression=lz4 atime=off tank/backups

Systèmes de fichiers réseau et distribués

NFS/SMB (approche NAS)

NFSv3/v4 : simple et rapide ; v4 donne les verrous et Kerberos ('sec = krb5p'). Ne comptez pas sur NFS pour le « deep » fsync haute fréquence - meilleur disque local + déchargement asynchrone.
SMB 3. x : multichannel, cryptage, intégration avec AD. Activez la signature/cryptage sur les données sensibles.

Exportation NFS (minimum) :


/pool/projects 10. 0. 0. 0/16(rw,no_root_squash,sec=krb5p,async)

SMB (fragment) :


[reports]
path = /pool/reports read only = no vfs objects = acl_xattr, recycle smb encrypt = required

FS distribués

CephFS - POSIX sur Ceph ; bon pour l'échelle horizontale, snapshots, quouts, métadonnées distribuées.
GlusterFS - facile à démarrer, réplique/sharding, mais soigneusement avec de petits fichiers et p99.
Lustre/IBM Spectrum Scale - PMA/fichiers volumineux, exigeants pour le réseau/les opérations.
9P (Virtuo-fs) : Pour le shering VM, pas pour les charges pro avec SLO rigide.

Recommandation : Pour OLTP/portefeuille - pas réseau FS ; utilisez des volumes de blocs. Pour le contenu statique/les artefacts partagés - NFS/SMB/objet + CDN.

Verrouillages, mise en cache et cohérence

Advisory vs mandatory locks: Linux обычно advisory; SMB prend en charge les oplocks/leases, NFSv4 - stateful locks.
Mise en cache du client : les cachets agressifs accélèrent la lecture, mais avec les multi-clients, ils augmentent le risque de conflit.

Cohérence :

Strong (FS locaux, ZFS).
Close-to-open (NFS) : les modifications sont visibles à 'close ()/open ()'.
Eventual (certains scripts distribués/objets).
Horloge : NTP/PTP ; la dérive du temps brise le conflit-résolve et la TTL.

Synchronisation : modèles et outils

Modèles

One-way (push/pull) : publication d'artefacts, déchargement de rapports, backup offsite.
Two-way (bi-dir) : collaboration ; le conflit-résolver et le versioning sont nécessaires.
Hub-and-spoke : étoile via le nœud central/cluster (MinIO/S3 + agents).
Near-real-time vs batch : inotify/logs de changement vs fenêtres périodiques.

Outils

rsync est de facto la norme one-way ; '--delete', '--partial', '---inplace' (attention).
rclone - S3/cloud, hachage, serveur-side copy.
Unison - vrai bi-directif, résolution des conflits.
Syncthing - p2p, versioning, pratique pour les dossiers de travail.
lsyncd est le déclencheur rsync par inotify ; near-real-time.
ZFS send/recv est le « sink » parfait des snapshots/incréments (byte efficace).

rsync (one-way, publication d'un catalogue statique) :

bash rsync -az --delete --numeric-ids --partial --inplace \
/srv/builds/ user@edge:/var/www/builds/

Unison (bi-dir, profil) :


root =/srv/shared root = ssh ://user @ peer//srv/shared prefer =/srv/shared # in case of conflict - local side repeat = watch # inotify ignore = Name. tmp

lsyncd (near-real-time top rsync) :

lua settings { logfile="/var/log/lsyncd. log", statusFile="/var/run/lsyncd. status" }
sync {
default. rsync,
source="/srv/outbox",
target="user@remote:/srv/inbox",
rsync={ archive=true, compress=true, delete=true }
}

Réplique ZFS (incrément) :

bash zfs snapshot tank/data@now zfs send -i tank/data@prev tank/data@now      ssh backup zfs recv -F backup/data

Versioning, snapshots et « paniers »

Snapshots CoW (ZFS/Btrfs/CephFS) : points de repli rapides, min. lettres de voiture.
Versioning au niveau de l'application (Nextcloud/Syncthing/objet) : convivial.
Paniers/recycles sur SMB/NFS : évitent le retrait accidentel, mais ne remplacent pas le backup.

Sécurité et accès

ACL et xattr : POSIX ACL, SID/ACE pour SMB, mapping uid/gid.
Lecture/écriture via les passerelles : SFTP/HTTPS/WebBOU - lorsque vous ne pouvez pas ouvrir SMB/NFS vers l'extérieur.
Cryptage : LUKS/ZFS native ; en vol - Kerberos (NFSv4), SMB encryption, TLS pour les passerelles.
PII/conformité : segmentation des boules, masques stricts de droits, audits d'accès, WORM là où il faut être immuable.

Observabilité, SLO et alertes

Метрики ФС: p95/p99 latency (read/write/open), IOPS, qdepth, cache hit, inode usage, fill-level, errors (EIO/ENOSPC).
Mesures réseau (NFS/SMB) : retransmits/drops, RPC RTT, oplock breaks, queue length.

SLO (exemples) :

Boule NFS CI : p95 'open '/' read' ≤ 3-5 ms, disponibilité ≥ 99. 95%.
Rapports SMB : p95 liste du catalogue ≤ 100 ms à la ≤ de 10k fichiers/dir.
ZFS pool backup : p99 record ≤ 10 ms, succès des snapshots 100 %, RPO ≤ 15 min (incréments).

Alert :

Remplissage du pool> 80/90/95 %, croissance de 'EIO', snapshots, chute de hit-ratio, fréquents oplock-break.

Modèles de produit (iGaming/fintech)

Statique (icônes/aperçu/catalogues des fournisseurs) : publication via rsync → CDN ; stocker la source primaire dans l'objet avec le versioning.
Logs et événements « bruts » : écrivez localement (XFS/ext4) → déchargez-les (rclone → S3/MinIO).
Reporting et PII : SMB avec cryptage et ACL stricte ; Export hors site périodique (ZFS send/recv) avec WORM sur le côté réception.
Environnements Dev et fixation d'artefacts : NFS/SMB pour le chariot ; pour les bases lourdes - volume bloc + snapshots.
Collaboration de contenu : Syncthing/Nextcloud avec versioning et quotas.

Chèque d'implémentation

Les classes de données (chaud/froid/PII), RPO/RTO et SLO ont été définies.
Sélectionné par FS : ext4/XFS/ZFS avec des options correctes (noatime, barriers, recordsize).
Si NAS : NFSv4/SMB avec cryptage/signatures, ACL, Kerberos/AD.
Snapshots/versioning/paniers - personnalisés et validés par la restauration.
Outil de sync sous la tâche : rsync (one-way), Unison/Syncthing (bi-dir), rclone (cloud), ZFS send/recv (backap/DR).
Surveillance des SF/réseaux/opérations, SLO à taux fort, alerte ENOSPC/EIO/oplock.
Documentation : Runbook of Conflict, règlement fsync, politique de noms/longueurs de chemin/codage.
Tests : profils de charge (petits/grands fichiers), scénarios de kat (rupture de communication, conflit d'édition).

Erreurs typiques

Une boule réseau commune pour les transactions critiques (OLTP) au lieu d'un volume de blocs local.
Barriers désactivés/pas de fsync dans l'application → perte de données en cas d'échec.
Deux voies bleu sans versioning et un seul temps → les changements « mangés ».
En ligne - « discard » sur le pool chaud → les queues de latence.
Des millions de petits fichiers dans le même répertoire → une liste/sauvegarde catastrophique.
Mélange de droits/propriétaires entre SMB et NFS sans mapping explicite.

Mini-playbooks

Publication one-way d'un billet → serveurs edge

1. Assemblage en '/srv/builds '(local FS). 2) `rsync -az --delete` на edge. 3) Handicap CDN.

Dossier de travail bi-dir des analystes

1. Syncthing/Unison, « versioning N days », conflit - enregistrer les deux versions. 2) Quotas par utilisateur. 3) Hors site-backap périodique.

Répertoire de rapports DR (WORM)

1. ZFS snapshots programmés. 2) 'send/recv' dans un hôte isolé avec Object Lock/WORM. 3) Test de récupération mensuel.

Total

Un sous-système de fichiers fiable est le bon FS + les modes de journal/barrières corrects + un modèle de verrouillage compréhensible, et la synchronisation efficace est la bonne topologie (one-way/bi-dir), le versioning et les outils éprouvés. Capturez les solutions dans runbook, automatisez les snapshots/réplication, mesurez les SLO et testez les scénarios de défaillance - de sorte que les données restent entières et que les processus d'exploitation sont prévisibles même sous des charges de pointe.