Conçu depuis les Premiers Principes

Aucun runtime. Aucun ramasse-miettes. Aucune surcharge de framework. Chaque ligne de Flashstor est écrite en C11 pour un contrôle maximal de la mémoire, des E/S et des ressources système.

Fondation Technologique

Quatre piliers d'excellence en ingénierie

C11 (ISO/IEC 9899:2011)
Standard C moderne avec types _Atomic, static_assert, structs anonymes. Conforme POSIX avec -Wall -Wextra -Wpedantic. Compilé avec -fstack-protector-strong, -D_FORTIFY_SOURCE=3 et RELRO complet.
Intel ISA-L & ISA-L Crypto
Erasure coding accéléré SIMD (Reed-Solomon sur GF(2^8)) avec AVX2/AVX-512 et chiffrement AES-256-GCM accéléré matériellement via AESNI. Jusqu'à 65x plus rapide que le C pur.
Boucle événementielle epoll / kqueue
E/S événementielles natives : epoll sous Linux, kqueue sous BSD/macOS, event ports sous SunOS. Pool de threads worker configurable (par défaut : cpu_count × 2) avec pool d'E/S dédié aux opérations sur les shards.
HTTP/2 via nghttp2
Support complet HTTP/2 sur TLS (h2 via ALPN) et en clair (h2c prior-knowledge). Keep-alive HTTP/1.1 avec nombre maximal de requêtes par connexion configurable (par défaut : 1 000).

Cycle de Vie d'une Requête

Chaque requête S3 suit un pipeline déterministe en quatre phases

1

Acceptation et Analyse

La boucle événementielle accepte la connexion via epoll/kqueue. Les en-têtes HTTP sont analysés dans des tampons arena pré-alloués. Délai anti-slowloris appliqué à la réception des en-têtes. La requête est routée vers le gestionnaire via la table de dispatch.

2

Authentification et Autorisation

Signature SigV4 vérifiée avec CRYPTO_memcmp timing-safe. Politique IAM évaluée dans le contexte de la requête avec cache epoch par thread (taux de succès proche de 100 % sur les connexions keep-alive). Jetons STS validés.

3

Exécution et Réponse

L'opération est distribuée au gestionnaire. Les données sont fragmentées via routage CRC32, encodées avec erasure coding ISA-L SIMD et écrites sur les disques en parallèle via le pool de threads d'E/S. La réponse est assemblée avec envoi zero-copy writev().

4

Nettoyage et Recyclage

L'allocateur arena libère en masse toute la mémoire par requête en une seule opération — zéro appel free() individuel. La connexion est retournée à la boucle événementielle pour réutilisation keep-alive. Entrée de journal d'audit asynchrone mise en file d'attente dans le ring buffer SPSC lock-free.

Mémoire

Allocation Arena : Zéro Fragmentation par Conception

Chaque connexion dispose d'un allocateur arena dédié avec des blocs réutilisables de 64 Kio. Toutes les allocations par requête se font dans l'arena. Lorsque la requête est terminée, l'arena entière est réinitialisée en O(1) — aucun appel free() par objet, aucune fragmentation, aucun GC.

  • Blocs arena de 64 Kio — réutilisés entre les requêtes, jamais rendus au SE
  • ~75 Kio de base par connexion (arena + tampons d'E/S)
  • Désallocation en masse à la fin de la requête — simple réinitialisation du pointeur
  • Mode debug : suivi par allocation avec détection de fuites
// Allocateur arena — simplifié
arena_t *a = arena_create(65536);
// Fast bump allocation
void *buf = arena_alloc(a, size);
void *hdr = arena_alloc(a, hdr_sz);
// Request complete — free everything
arena_reset(a); // O(1), no free()

Architecture de Cluster Distribuée

Ensembles d'erasure distribués sur les nœuds avec consensus basé sur le quorum

Nœud Passerelle

Accepte les requêtes S3 API, effectue l'authentification SigV4, route les opérations vers le bon ensemble d'erasure via hachage déterministe basé sur CRC32.

Nœud de Stockage

Gère les disques locaux avec l'implémentation vtable xl_storage. Gère l'erasure coding, la vérification bitrot et les E/S au niveau des shards avec des opérations disque parallèles.

Nœud Pair

Stockage distant accessible via vtable rest_storage sur HTTP. Participe au verrouillage distribué, au quorum de métadonnées et à la réplication inter-nœuds.

Canaux de Communication

Port 9000
S3 API
API REST S3 côté client avec support HTTP/1.1 et HTTP/2.
Port 9001
Admin API
API de gestion avec authentification par jeton porteur HMAC-SHA256 pour les opérations de cluster.
Port Internal
Peer RPC
Communication REST inter-nœuds pour le verrouillage distribué, la synchronisation des métadonnées et la réplication des données.
Sécurité

Modèle de Séparation des Privilèges

Flashstor suit le principe du moindre privilège avec un cycle de vie de sécurité en quatre phases qui minimise la surface d'attaque à l'exécution.

Phase 1

Initialisation en Root

  • • Liaison au port privilégié (ex. 443 pour HTTPS)
  • • Chargement des certificats TLS depuis --certs-dir
  • • Initialisation des tables de dispatch ISA-L SIMD
Phase 2

Abandon des Privilèges

  • • Basculement vers FLASHSTORE_RUN_USER / FLASHSTORE_RUN_GROUP
  • • Activation de PR_SET_NO_NEW_PRIVS sous Linux (empêche la ré-escalade)
  • • Utilisation du modèle de capabilities sous SunOS/illumos
Phase 3

Durcissement à l'Exécution

  • • RELRO complet — aucune entrée GOT inscriptible après le démarrage
  • • -fstack-protector-strong avec protection par canari de pile
  • • Intégrité du flux de contrôle (-fcf-protection sur x86_64)
  • • -D_FORTIFY_SOURCE=3 pour la détection de débordement de tampon
Phase 4

Audit et Surveillance

  • • Journaux d'audit JSON asynchrones via ring buffer SPSC lock-free
  • • Identifiants de trace par requête avec chronométrage des opérations
  • • Métriques Prometheus pour les événements liés à la sécurité

Questions Techniques ? Parlons Architecture.

Notre équipe d'ingénierie est disponible pour des discussions techniques approfondies sur la gestion mémoire, les modèles d'E/S, le durcissement de la sécurité et la conception de systèmes distribués.

Demander une Démo Voir les Performances