Von Grund auf Entwickelt

Keine Runtime. Kein Garbage Collector. Kein Framework-Overhead. Jede Zeile von Flashstor ist in C11 geschrieben für maximale Kontrolle über Speicher, I/O und Systemressourcen.

Technologische Grundlagen

Vier Säulen ingenieurstechnischer Exzellenz

C11 (ISO/IEC 9899:2011)
Moderner C-Standard mit _Atomic-Typen, static_assert, anonymen Structs. POSIX-konform mit -Wall -Wextra -Wpedantic. Kompiliert mit -fstack-protector-strong, -D_FORTIFY_SOURCE=3 und vollständigem RELRO.
Intel ISA-L & ISA-L Crypto
SIMD-beschleunigtes Erasure Coding (Reed-Solomon über GF(2^8)) mit AVX2/AVX-512 und hardwarebeschleunigte AES-256-GCM-Verschlüsselung via AESNI. Bis zu 65x schneller als reines C.
Event-Loop epoll / kqueue
Plattformnative ereignisgesteuerte E/A: epoll unter Linux, kqueue unter BSD/macOS, Event Ports unter SunOS. Konfigurierbarer Worker-Thread-Pool (Standard: cpu_count × 2) mit dediziertem I/O-Pool für Shard-Operationen.
HTTP/2 via nghttp2
Vollständige HTTP/2-Unterstützung über TLS (h2 via ALPN) und Klartext (h2c Prior-Knowledge). HTTP/1.1 Keep-Alive mit konfigurierbarer maximaler Anzahl von Anfragen pro Verbindung (Standard: 1.000).

Anfrage-Lebenszyklus

Jede S3-Anfrage durchläuft eine deterministische Vier-Phasen-Pipeline

1

Annahme und Parsing

Die Event-Loop akzeptiert die Verbindung über epoll/kqueue. HTTP-Header werden in vorab allozierte Arena-Puffer geparst. Anti-Slowloris-Timeout wird beim Header-Empfang erzwungen. Die Anfrage wird über die Dispatch-Tabelle an den Handler weitergeleitet.

2

Authentifizierung und Autorisierung

SigV4-Signatur mit timing-sicherem CRYPTO_memcmp verifiziert. IAM-Policy wird im Anfragekontext mit Epoch-Cache pro Thread ausgewertet (nahezu 100 % Trefferrate bei Keep-Alive-Verbindungen). STS-Token werden validiert.

3

Ausführung und Antwort

Die Operation wird an den Handler dispatcht. Daten werden über CRC32-Routing geshardet, mit ISA-L SIMD Erasure Coding kodiert und parallel über den I/O-Thread-Pool auf Festplatten geschrieben. Die Antwort wird mit Zero-Copy writev()-Versand zusammengestellt.

4

Bereinigung und Wiederverwendung

Der Arena-Allocator gibt den gesamten Anfrage-Speicher in einer einzigen Operation frei — null einzelne free()-Aufrufe. Die Verbindung wird für Keep-Alive-Wiederverwendung an die Event-Loop zurückgegeben. Asynchroner Audit-Log-Eintrag wird in den lock-freien SPSC-Ringpuffer eingereiht.

Speicher

Arena-Allokation: Null Fragmentierung durch Design

Jede Verbindung erhält einen dedizierten Arena-Allocator mit wiederverwendbaren 64-KiB-Blöcken. Alle Anfrage-bezogenen Allokationen erfolgen innerhalb der Arena. Nach Abschluss der Anfrage wird die gesamte Arena in O(1) zurückgesetzt — keine free()-Aufrufe pro Objekt, keine Fragmentierung, kein GC.

  • 64-KiB-Arena-Blöcke — über Anfragen hinweg wiederverwendet, nie an das Betriebssystem zurückgegeben
  • ~75 KiB Basisverbrauch pro Verbindung (Arena + I/O-Puffer)
  • Massen-Deallokation bei Abschluss der Anfrage — einfacher Pointer-Reset
  • Debug-Modus: Nachverfolgung pro Allokation mit Leck-Erkennung
// Arena-Allocator — vereinfacht
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()

Verteilte Cluster-Architektur

Erasure-Sets verteilt über Knoten mit quorumbasiertem Konsens

Gateway-Knoten

Akzeptiert S3-API-Anfragen, führt SigV4-Authentifizierung durch, leitet Operationen über deterministisches CRC32-basiertes Hashing an das korrekte Erasure-Set weiter.

Storage-Knoten

Verwaltet lokale Festplatten mit xl_storage-Vtable-Implementierung. Handhabt Erasure Coding, Bitrot-Verifizierung und Shard-Level-I/O mit parallelen Festplattenoperationen.

Peer-Knoten

Remote-Speicher zugänglich über rest_storage-Vtable über HTTP. Nimmt am verteilten Locking, Metadaten-Quorum und knotenübergreifender Replikation teil.

Kommunikationskanäle

Port 9000
S3 API
Client-seitige S3-REST-API mit HTTP/1.1- und HTTP/2-Unterstützung.
Port 9001
Admin API
Management-API mit HMAC-SHA256-Bearer-Token-Authentifizierung für Cluster-Operationen.
Port Internal
Peer RPC
Inter-Node-REST-Kommunikation für verteiltes Locking, Metadaten-Synchronisation und Datenreplikation.
Sicherheit

Modell der Privilegientrennung

Flashstor folgt dem Prinzip der geringsten Privilegien mit einem vierphasigen Sicherheitslebenszyklus, der die Angriffsfläche zur Laufzeit minimiert.

Phase 1

Initialisierung als Root

  • • Binden des privilegierten Ports (z. B. 443 für HTTPS)
  • • Laden der TLS-Zertifikate aus --certs-dir
  • • Initialisierung der ISA-L SIMD-Dispatch-Tabellen
Phase 2

Privilegien Abgeben

  • • Wechsel zu FLASHSTORE_RUN_USER / FLASHSTORE_RUN_GROUP
  • • Setzen von PR_SET_NO_NEW_PRIVS unter Linux (verhindert Re-Eskalation)
  • • Verwendung des Capabilities-Modells unter SunOS/illumos
Phase 3

Laufzeit-Härtung

  • • Vollständiges RELRO — keine beschreibbaren GOT-Einträge nach dem Start
  • • -fstack-protector-strong mit Stack-Canary-Schutz
  • • Control-Flow Integrity (-fcf-protection auf x86_64)
  • • -D_FORTIFY_SOURCE=3 zur Erkennung von Pufferüberläufen
Phase 4

Audit und Überwachung

  • • Asynchrone JSON-Audit-Logs über lock-freien SPSC-Ringpuffer
  • • Trace-IDs pro Anfrage mit Operationszeiterfassung
  • • Prometheus-Metriken für sicherheitsrelevante Ereignisse

Technische Fragen? Sprechen wir über Architektur.

Unser Engineering-Team steht für tiefgehende technische Diskussionen über Speicherverwaltung, I/O-Modelle, Sicherheitshärtung und Design verteilter Systeme zur Verfügung.

Demo Anfragen Leistung Ansehen