Sviluppatori di Cloudflare sullo svolgimento del lavoro per ottimizzare le prestazioni della crittografia del disco nel kernel Linux. Di conseguenza, erano preparati per sottosistema e Crypto API, che ha permesso di più che raddoppiare il throughput di lettura e scrittura nel test sintetico, oltre a dimezzare la latenza. Durante i test su hardware reale, il sovraccarico della crittografia è stato ridotto quasi al livello osservato quando si lavora con un disco senza crittografia dei dati.
Cloudflare utilizza dm-crypt per crittografare i dati sui dispositivi di archiviazione utilizzati per memorizzare nella cache i contenuti sulla CDN. Dm-crypt opera a livello del dispositivo a blocchi e crittografa le richieste I/O di scrittura e decrittografa le richieste di lettura, agendo come uno strato tra il dispositivo a blocchi e il driver del file system.
Per valutare le prestazioni di dm-crypt utilizzando il pacchetto Abbiamo misurato la velocità di lavoro con partizioni crittografate e non crittografate su un disco RAM situato nella RAM per eliminare le fluttuazioni nelle prestazioni del disco e concentrarci sulle prestazioni del codice. Per le partizioni non crittografate, le prestazioni di lettura e scrittura sono rimaste a 1126 MB/s, ma la velocità è diminuita quando è stata abilitata la crittografia 7 nel tempo e ammontava a 147 MB/s.
Inizialmente è sorto il sospetto sull'uso di algoritmi inefficienti nel sistema crittografico del kernel. Ma i test hanno utilizzato l’algoritmo più veloce, aes-xts, con 256 chiavi di crittografia, le cui prestazioni durante l’esecuzione del “benchmark cryptsetup” sono più del doppio del risultato ottenuto durante il test di un disco RAM. Gli esperimenti con i flag dm-crypt per l'ottimizzazione delle prestazioni non hanno prodotto risultati: quando si utilizza il flag "--perf-same_cpu_crypt", le prestazioni sono addirittura scese a 136 MB/s e quando si specifica il flag "--perf-submit_from_crypt_cpus" sono solo aumentate a 166MB/sec.
Un'analisi più approfondita della logica operativa ha mostrato che dm-crypt non è così semplice come sembra: quando arriva una richiesta di scrittura dal driver FS, dm-crypt non la elabora immediatamente, ma la inserisce nella coda "kcryptd", che non viene analizzato immediatamente, ma al momento opportuno. Dalla coda, la richiesta viene inviata all'API Linux Crypto per eseguire la crittografia. Ma poiché l'API Crypto utilizza un modello di esecuzione asincrono, anche la crittografia non viene eseguita immediatamente, ma bypassando un'altra coda. Una volta completata la crittografia, dm-crypt può tentare di ordinare le richieste di scrittura in sospeso utilizzando un albero di ricerca . Alla fine, ancora una volta un thread separato del kernel, con un certo ritardo, raccoglie le richieste I/O accumulate e le invia allo stack del dispositivo a blocchi.
Durante la lettura, dm-crypt aggiunge prima una richiesta alla coda "kcryptd_io" per ricevere dati dall'unità. Dopo un po' di tempo, i dati diventano disponibili e vengono inseriti nella coda “kcryptd” per la decrittazione.
Kcryptd invia una richiesta all'API Linux Crypto, che decrittografa le informazioni in modo asincrono. Non sempre le richieste attraversano tutte le code, ma nel peggiore dei casi, una richiesta di scrittura finisce in coda fino a 4 volte e una richiesta di lettura fino a 3 volte. Ogni colpo alla coda provoca ritardi, che sono la ragione principale del significativo calo delle prestazioni di dm-crypt.
L'utilizzo delle code è dovuto alla necessità di lavorare in condizioni in cui si verificano interruzioni. Nel 2005, quando fu implementato l'attuale modello operativo basato su code di dm-crypt, l'API Crypto non era ancora asincrona. Dopo che l'API Crypto è stata trasferita a un modello di esecuzione asincrona, è stata utilizzata essenzialmente una doppia protezione. Sono state introdotte anche le code per ridurre il consumo dello stack del kernel, ma dopo il suo aumento nel 2014, queste ottimizzazioni hanno perso la loro rilevanza. È stata introdotta una coda aggiuntiva "kcryptd_io" per superare il collo di bottiglia che comportava l'attesa dell'allocazione della memoria quando arrivava un numero elevato di richieste. Nel 2015 è stata introdotta un'ulteriore fase di smistamento, poiché le richieste di crittografia sui sistemi multiprocessore potevano essere completate fuori ordine (invece dell'accesso sequenziale al disco, l'accesso veniva effettuato in ordine casuale e lo scheduler CFQ non funzionava in modo efficiente). Attualmente, quando si utilizzano unità SSD, l'ordinamento ha perso il suo significato e lo scheduler CFQ non viene più utilizzato nel kernel.
Considerando che le unità moderne sono diventate più veloci e intelligenti, il sistema di distribuzione delle risorse nel kernel Linux è stato rivisto e alcuni sottosistemi sono stati riprogettati, gli ingegneri di Cloudflare dm-crypt ha una nuova modalità operativa che elimina l'uso di code non necessarie e chiamate asincrone. La modalità è abilitata da un flag separato “force_inline” e porta dm-crypt sotto forma di un semplice proxy che crittografa e decrittografa le richieste in arrivo. L'interazione con l'API Crypto è stata ottimizzata scegliendo esplicitamente algoritmi di crittografia che operano in modalità sincrona e non utilizzano code di richieste. Per lavorare in modo sincrono con la Crypto API c'era un modulo che consente di utilizzare FPU/AES-NI per l'accelerazione e inoltra direttamente le richieste di crittografia e decrittografia.
Di conseguenza, durante il test di un disco RAM, è stato possibile più che raddoppiare le prestazioni di dm-crypt: le prestazioni sono aumentate da 294 MB/s (2 x 147 MB/s) a 640 MB/s, che è molto vicino a le prestazioni della semplice crittografia (696 MB / s).
Durante il test del carico sui server reali, la nuova implementazione ha mostrato prestazioni molto vicine alla configurazione eseguita senza crittografia e l'attivazione della crittografia sui server con cache Cloudflare non ha avuto alcun effetto sulla velocità di risposta. In futuro, Cloudflare prevede di trasferire le patch preparate al kernel Linux principale, ma prima dovranno essere rielaborate, poiché sono ottimizzate per un carico specifico e non coprono tutte le aree di applicazione, ad esempio la crittografia a basso livello -dispositivi embedded di potenza.
Fonte: opennet.ru