たくさん Cloudflare開発者がリリースしました Linuxカーネルでディスク暗号化のパフォーマンスを最適化するために行っている作業に関する情報。 dm-cryptおよびCryptoAPIサブシステムのパッチ。
これで、 合成テストでは、読み取りと書き込みの帯域幅をXNUMX倍にすることができました。 と同様に レイテンシーを半分。 実際のマシンでテストする場合、暗号化のオーバーヘッドは、データ暗号化を使用せずにディスクを操作するときに見られるレベルにほぼ削減されました。
暗号化の改善への関心 ディスク上のデータ Cloudflareがdm-cryptを使用しているためです CDNにコンテンツをキャッシュするために使用されるドライブ上のデータを暗号化するため。 Dm-cryptはブロックデバイスレベルで機能し、I / O要求を暗号化して読み取り要求を書き込みおよび復号化し、ブロックデバイスとファイルシステムドライバーの間のレイヤーとして機能します。
パフォーマンスを評価するには 柔軟なI / Oテストパッケージを使用したdm-crypt、seは暗号化されたパーティションでの作業速度を測定しました ディスクパフォーマンスの変動を排除するために、RAMにあるRAMディスクでは暗号化されません。
暗号化されていないパーティションの場合、読み取りと書き込みのパフォーマンスは1126MB /秒のままでしたが、暗号化をオンにすると、速度は7倍低下して147MB /秒になりました。
はじめに 非効率的なアルゴリズムの使用が疑われた カーネル暗号化システムで。 ただし、テストでは256個の暗号化キーを使用したより高速なaes-xtsアルゴリズムを使用しました。このアルゴリズムの「cryptsetupベンチマーク」の実行時のパフォーマンスは、RAMディスクのテスト時に得られた結果のXNUMX倍以上です。
実験 dm-cryptフラグ付き パフォーマンスを調整することができませんでした：–perf-same_cpu_cryptフラグを使用すると、パフォーマンスは136MB /秒にまで低下し、–perf-submit_from_crypt_cpusフラグを使用すると、166MB /秒にしか増加しませんでした。
より深い分析 仕事の論理の dm-cryptはそれほど単純ではないことを示しました それが思われるよう。
書き込み要求がFSコントローラーから受信されると、dm-cryptはそれをすぐには処理しませんが、すぐには理解されない「kcryptd」キューに入れますが、適切なタイミングが発生します。 キューから、要求は暗号化のためにLinux CryptoAPIに送信されます。
最初に読み取るとき、dm-cryptは「kcryptd_io」をキューに入れます ユニットからデータを受信する要求。 後に しばらくの間、データは利用可能であり、 それらは復号化のために「kcryptd」キューに入れられます。
KcryptdはLinux暗号化APIにリクエストを送信し、Linux暗号化APIは情報を非同期で復号化します。 リクエストは常にすべてのキューを通過するとは限りません、しかし最悪の場合、 書き込み要求は最大4回キューに設定されます 読み取り要求は最大3回です。 尾を打つたびに遅延が発生しますが、 これが、dm-cryptのパフォーマンスが大幅に低下する主な理由です。
最新のドライブがより高速かつスマートになったことを考慮して、Linuxカーネルのリソース割り当てシステムが改訂され、 一部のサブシステムが再設計されました、Cloudflareのエンジニアは、dm-cryptに新しい動作モードを追加し、追加のキューや非同期呼び出しの使用を排除しました。
このモードは、個別の「force_inline」フラグによって有効になり、dm-cryptを、着信要求を暗号化および復号化する単純なプロキシの形式にします。 Crypto APIとの相互作用は、暗号化アルゴリズムを明示的に選択することで最適化されています これらは同期モードで動作し、要求キューを使用しません。
実サーバーの負荷をテストしたとき、新しい実装は暗号化なしで機能する構成に非常に近いパフォーマンスを示し、Cloudflareキャッシュを備えたサーバーに暗号化を含めても応答速度に影響しませんでした。
将来的には、Cloudflareは準備されたパッチをメインのLinuxカーネルに転送することを計画しています、ただし、特定の負荷に最適化されており、すべてのアプリケーション領域をカバーしているわけではないため、その前に変更する必要があります。
出典 https://blog.cloudflare.com