Ontwikkelaars van Cloudflare over het uitvoeren van werkzaamheden om de prestaties van schijfversleuteling in de Linux-kernel te optimaliseren. Het resultaat was dat ze voorbereid waren voor subsysteem en Crypto API, die het mogelijk maakte om de lees- en schrijfdoorvoer in de synthetische test meer dan te verdubbelen en de latentie te halveren. Bij tests op echte hardware werd de overhead van de encryptie teruggebracht tot bijna het niveau dat werd waargenomen bij het werken met een schijf zonder gegevensencryptie.
Cloudflare gebruikt dm-crypt om gegevens te versleutelen op opslagapparaten die worden gebruikt om inhoud op het CDN te cachen. Dm-crypt werkt op blokapparaatniveau en codeert schrijf-I/O-verzoeken en decodeert leesverzoeken, en fungeert als een laag tussen het blokapparaat en het bestandssysteemstuurprogramma.
Om de prestaties van dm-crypt te evalueren met behulp van het pakket We hebben de snelheid gemeten van het werken met gecodeerde en niet-gecodeerde partities op een RAM-schijf in het RAM-geheugen om schommelingen in de schijfprestaties te elimineren en ons te concentreren op de codeprestaties. Voor niet-gecodeerde partities bleven de lees- en schrijfprestaties 1126 MB/s, maar de snelheid nam af wanneer codering was ingeschakeld 7 in de tijd en bedroeg 147 MB/s.
In eerste instantie ontstond er argwaan over het gebruik van inefficiënte algoritmen in het kernelcryptosysteem. Maar de tests gebruikten het snelste algoritme, aes-xts, met 256 encryptiesleutels, waarvan de prestaties bij het uitvoeren van de “cryptsetup benchmark” meer dan twee keer zo hoog zijn als het resultaat verkregen bij het testen van een RAM-schijf. Experimenten met dm-crypt-vlaggen voor het afstemmen van de prestaties leverden geen resultaten op: bij gebruik van de vlag “--perf-same_cpu_crypt” daalde de prestatie zelfs tot 136 MB/s, en bij het specificeren van de vlag “--perf-submit_from_crypt_cpus” nam deze alleen maar toe tot 166 MB/s.
Een diepere analyse van de werkingslogica toonde aan dat dm-crypt niet zo eenvoudig is als het lijkt: wanneer een schrijfverzoek binnenkomt van de FS-driver, verwerkt dm-crypt dit niet onmiddellijk, maar plaatst het in de “kcryptd”-wachtrij, die wordt niet onmiddellijk geparseerd, maar op een geschikt moment. Vanuit de wachtrij wordt het verzoek naar de Linux Crypto API gestuurd om codering uit te voeren. Maar omdat de Crypto API gebruik maakt van een asynchroon uitvoeringsmodel, wordt de encryptie ook niet onmiddellijk uitgevoerd, maar wordt een andere wachtrij omzeild. Nadat de codering is voltooid, kan dm-crypt proberen lopende schrijfverzoeken te sorteren met behulp van een zoekboom . Aan het einde pikt een afzonderlijke kernelthread opnieuw, met een bepaalde vertraging, de verzamelde I/O-verzoeken op en stuurt deze naar de blokapparaatstack.
Bij het lezen voegt dm-crypt eerst een verzoek toe aan de wachtrij “kcryptd_io” om gegevens van de schijf te ontvangen. Na enige tijd komen de gegevens beschikbaar en worden ze in de “kcryptd”-wachtrij geplaatst voor decodering.
Kcryptd stuurt een verzoek naar de Linux Crypto API, die de informatie asynchroon decodeert. Verzoeken gaan niet altijd door alle wachtrijen, maar in het ergste geval komt een schrijfverzoek maximaal 4 keer in wachtrijen terecht, en een leesverzoek maximaal 3 keer. Elke treffer in de wachtrij veroorzaakt vertragingen, wat de belangrijkste reden is voor de aanzienlijke afname van de dm-crypt-prestaties.
Het gebruik van wachtrijen is te wijten aan de noodzaak om te werken in omstandigheden waarin onderbrekingen optreden. In 2005, toen het huidige, op wachtrijen gebaseerde besturingsmodel van dm-crypt werd geïmplementeerd, was de Crypto API nog niet asynchroon. Nadat de Crypto API was overgezet naar een asynchroon uitvoeringsmodel, begon er in wezen dubbele bescherming te worden gebruikt. Er werden ook wachtrijen geïntroduceerd om het verbruik van de kernelstack te besparen, maar na de verhoging in 2014 verloren deze optimalisaties hun relevantie. Er is een extra wachtrij "kcryptd_io" geïntroduceerd om het knelpunt te overwinnen dat resulteert in het wachten op geheugentoewijzing wanneer een groot aantal verzoeken binnenkomt. In 2015 werd een extra sorteerfase geïntroduceerd, omdat coderingsverzoeken op systemen met meerdere processors buiten de juiste volgorde konden worden voltooid (in plaats van sequentiële toegang tot de schijf werd de toegang in willekeurige volgorde uitgevoerd en werkte de CFQ-planner niet efficiënt). Momenteel heeft sorteren bij het gebruik van SSD-schijven zijn betekenis verloren en wordt de CFQ-planner niet langer in de kernel gebruikt.
Gezien het feit dat moderne schijven sneller en slimmer zijn geworden, is het bronnendistributiesysteem in de Linux-kernel herzien en zijn sommige subsystemen opnieuw ontworpen, zeggen Cloudflare-ingenieurs dm-crypt heeft een nieuwe bedieningsmodus die het gebruik van onnodige wachtrijen en asynchrone oproepen elimineert. De modus wordt mogelijk gemaakt door een aparte vlag “force_inline” en brengt dm-crypt in de vorm van een eenvoudige proxy die inkomende verzoeken codeert en decodeert. De interactie met de Crypto API is geoptimaliseerd door expliciet te kiezen voor versleutelingsalgoritmen die in synchrone modus werken en geen gebruik maken van wachtrijen voor verzoeken. Om synchroon te werken met de Crypto API was er een module waarmee u FPU/AES-NI kunt gebruiken voor versnelling en verzoeken om versleuteling en decodering direct doorstuurt.
Als gevolg hiervan was het bij het testen van een RAM-schijf mogelijk om de prestaties van dm-crypt meer dan te verdubbelen - de prestaties namen toe van 294 MB/s (2 x 147 MB/s) naar 640 MB/s, wat zeer dicht in de buurt komt van de prestaties van kale encryptie (696 MB /s).
Bij het testen van de belasting op echte servers toonde de nieuwe implementatie prestaties die heel dicht bij de configuratie lagen die zonder versleuteling draaide, en het inschakelen van versleuteling op servers met Cloudflare-cache had geen effect op de reactiesnelheid. In de toekomst is Cloudflare van plan de voorbereide patches over te dragen naar de belangrijkste Linux-kernel, maar daarvoor zullen ze moeten worden herwerkt, omdat ze zijn geoptimaliseerd voor een specifieke belasting en niet alle toepassingsgebieden bestrijken, bijvoorbeeld encryptie op laag niveau. -Geïntegreerde apparaten van stroom voorzien.
Bron: opennet.ru