Le versioni recenti di Podman, Buildah e CRI-O hanno iniziato a sfruttare una nuova funzionalità del kernel, i montaggi di sovrapposizione volatili. Questa funzione ti consente di montare un file system overlay con un flag che gli dice di non sincronizzarsi con il disco.
Se hai bisogno di un promemoria sull'uso e sui vantaggi dei supporti sovrapposti, dai un'occhiata al mio articolo della scorsa estate.
Che cos'è la sincronizzazione e perché è importante?
In Linux, quando si scrive su un file o una directory, il kernel non scrive istantaneamente i dati su disco. Invece, esegue il buffering di un sacco di scritture e quindi salva periodicamente i dati su disco per aumentare le prestazioni. Questa è chiamata sincronizzazione . Il problema è che un processo pensa i dati sono stati salvati al termine della scrittura, ma in realtà non lo è fino a quando il kernel non sincronizza quei dati. Ciò significa che se hai scritto dei dati e il kernel si è bloccato, c'è la possibilità che i dati non siano mai stati salvati.
Per questo motivo, molti file system vengono sincronizzati regolarmente e gli strumenti possono richiedere che la sincronizzazione avvenga spesso. Quando si verifica una sincronizzazione, il kernel interrompe l'elaborazione dei dati con un blocco e sincronizza tutti i dati sul disco. Naturalmente, questo causa prestazioni peggiori. Se hai un processo che causa frequenti sincronizzazioni, le prestazioni del tuo lavoro possono essere davvero danneggiate. Alcuni strumenti come RPM richiedono una sincronizzazione dopo che ogni file è stato scritto sul disco, provocando lo svuotamento di tutte le pagine sporche di quel file e si tratta di un sovraccarico considerevole.
[ Iniziare con i container? Dai un'occhiata a questo corso gratuito. Distribuzione di applicazioni containerizzate:una panoramica tecnica. ]
Potrebbe non essere necessario sincronizzare i contenitori
Nel mondo dei container, abbiamo molti casi d'uso in cui non ci interessa se i dati vengono salvati. Se il kernel si arrestasse in modo anomalo, non useremmo comunque i dati scritti.
Quando si esegue un buildah bud o podman build , l'immagine del contenitore viene scritta su un punto di montaggio overlay, spesso utilizzando DNF o YUM. Se il kernel si arrestasse in modo anomalo durante la creazione di un'immagine, il contenuto scritto sul livello di sovrapposizione sarebbe inutile e dovrà essere ripulito dall'utente. Tutto ciò che non è riuscito a scrivere verrebbe semplicemente cancellato. Al termine della build, tuttavia, il livello di sovrapposizione viene tarato in un bundle di immagini che può quindi essere sincronizzato con il disco.
Un altro caso d'uso per i mount overlay volatili è l'esecuzione di Podman con --rm bandiera. Il --rm flag dice a Podman di distruggere il container e il punto di montaggio overlay al termine del container. Un arresto anomalo del contenitore lascerebbe il contenuto che l'utente ha già indicato di non utilizzare, quindi non c'è motivo di preoccuparsi se una scrittura è andata a buon fine.
Nel mondo Kubernetes, CRI-O è il motore dei container. Kubernetes è quasi sempre impostato per rimuovere tutti i contenitori all'avvio. Fondamentalmente, vuole iniziare con uno stato pulito. Ciò significa che se il kernel si arrestasse in modo anomalo durante la scrittura dei dati sull'overlay mount, questi dati verrebbero distrutti non appena il sistema si avvia. È anche sicuro utilizzare tali configurazioni con contenitori con stato perché i dati vengono generalmente scritti su volumi esterni che non saranno interessati dal flag "volatile" in fase di esecuzione.
Aggiunta di un'opzione volatile
L'ingegnere del team di container Giuseppe Scrivano ha notato questi casi d'uso e ha pensato che avremmo potuto migliorare le prestazioni aggiungendo un'opzione volatile al file system overlay del kernel Linux e ha implementato questo comportamento. Di conseguenza, le versioni più recenti di Buildah, Podman e CRI-O utilizzeranno per impostazione predefinita il flag volatile in questi casi d'uso e si spera di ottenere prestazioni migliori.
Tieni presente che tutti i volumi montati nel contenitore continueranno ad avere il comportamento di sincronizzazione predefinito dei file system tipici, quindi non devi preoccuparti di perdere i dati scritti nella memoria permanente.
Il grafico seguente mostra come il numero di IOPS in scrittura viene ridotto in un contenitore che esegue yum install -y texlive su una macchina con 16 GB di RAM. Inoltre, quando il container viene eseguito con il flag volatile attivato, anche l'ora del suo orologio da parete viene influenzata e termina più rapidamente.
Le pagine sporche verranno infine scritte nella memoria una volta scaduto il rapporto sporco o il timeout dell'inode, poiché queste impostazioni non sono influenzate dal flag di montaggio volatile.
Concludi
Con la tecnologia dei container, spingiamo costantemente i limiti di ciò che il sistema Linux può gestire e sperimentiamo nuovi casi d'uso. L'aggiunta di un'opzione volatile al file system overlay del kernel aiuta ad aumentare le prestazioni, consentendo ai contenitori di continuare a evolversi e fornire maggiori vantaggi.
[ Download gratuito:cheat sheet dei comandi avanzati di Linux. ]