%2Fcrypt(luks)%2Flvm%20%E3%81%AE%E6%9B%B8%E3%81%8D%E8%BE%BC%E3%81%BF%E6%80%A7%E8%83%BD%E3%81%AB%E6%AF%94%E3%81%B9%E3%81%A6%E8%AA%AD%E3%81%BF%E5%8F%96%E3%82%8A%E6%80%A7%E8%83%BD%E3%81%8C%E9%9D%9E%E5%B8%B8%E3%81%AB%E4%BD%8E%E3%81%84%E3%81%A7%E3%81%99%E3%80%82.png)
私の経験はひどかったです。読むパフォーマンスはraid1/crypt/lvmよりも優れています。同時に、同じ設定で書き込み速度は約2倍高速です。同じシステムの他のraid1設定は通常の読み取り速度を取得します(おそらくcryptsetupを使用していないため)。
オペレーティングシステム関連ディスク:sda + sdb。 2つのディスクを持つraid1構成があり、両方のディスクが所定の位置にあります。 RAIDでLVMを使用しています。暗号化はありません。どちらのディスクもWD Green、5400rpmです。
このraid1のIOテスト結果:
dd if=/dev/zero of=/tmp/output.img3 bs=8k count=256k conv=fsync
- 2147483648 bytes (2.1 GB) copied, 22.3392 s, 96.1 MB/s
sync
echo 3 > /proc/sys/vm/drop_caches
dd if=/tmp/output.img3 of=/dev/null bs=8k
- 2147483648 bytes (2.1 GB) copied, 15.9 s, 135 MB/s
これは(同じコンピュータで)問題の設定です。現在、ソフトウェアraid1 + crypt(luks、serpent-xts-plain)+ lvmで構成される1つのsdc(WD Green、5400rpm)しかありません。明日別のディスク(sdd)を接続して、これら2つのディスクraid1の設定を完了します。
今回のraid1のIOテスト結果は次のとおりです。
dd if=/dev/zero of=output.img3 bs=8k count=256k conv=fsync
2147483648 bytes (2.1 GB) copied, 17.7235 s, 121 MB/s
sync
echo 3 > /proc/sys/vm/drop_caches
dd if=output.img3 of=/dev/null bs=8k
2147483648 bytes (2.1 GB) copied, 36.2454 s, 59.2 MB/s
読み取りパフォーマンスが非常に悪いことがわかります(暗号化されていない場合は135 MB / sと比較して59 MB / s)。ベンチマーク中にディスクを使用したことはありません。これはiostatとdstatを確認してみたので確認できます。
ハードウェアの詳細:
- ディスク:フルWDグリーン、5400rpm、64mbキャッシュ。
- CPU:FX-8350、基本速度
- メモリ: 4x4GB、1066Mhz。
このソフトウェアの詳細:
- オペレーティングシステム:Debian Wheezy 7、amd64
- mdadm: v3.2.5 - 2012 年 5 月 18 日
- LVMバージョン:2.02.95(2)(2012-03-06)
- LVMライブラリバージョン:1.02.74(2012-03-06)
- LVMドライババージョン:4.22.0
- パスワード設定:1.4.3
遅いraid1 + crypt + lvm設定を構成する方法は次のとおりです。
別の/dev/sdc
- MKタグGPT
- タイプ: ext4
- 開始時間:2048秒
- 終わり: -1
raid、crypt、lvmの設定は次のようになります。
- mdadm --create /dev/md1 --level=1 --raid-disks=2 /dev/sdc 不足
- cryptsetup --cipher serpent-xts-plain luksFormat /dev/md1
- cryptsetup luksOpen /dev/md1 md1_crypt
- vgcreate vg_sql /dev/mapper/md1_crypt
- lvcreate -l 100%VG vg_sql -n lv_sql
- mkfs.ext4 /dev/mapper/vg_sql-lv-sql
- マウント /dev/mapper/vg_sql-lv_sql /sql
それでは、原因を見つけて解決するのに役立ちますか?暗号化のない他の設定(sda + sdb)では読み取り速度の低下がないため、cryptsetupに関連する必要があります。しかし、どうすればいいのかわかりません。
ありがとうございます!
答え1
明らかに、暗号化はかなりのオーバーヘッドを追加しますが、それを無視してください。
また、AESではなく暗号化を使用します。つまり、プロセッサから加速(AESハードウェアアクセラレーション)を取得できません。また、デスクトップ品質のプロセッサを使用しています。そして消費者ドライブは非常に遅いです。
これがまさにパフォーマンスが悪い理由です。サーバー品質プロセッサー(これはサーバーですか?)とまともなドライブを追加し、LUKSにAESを使用します。
答え2
テストが正しく完了しないことがよくあります。 8k読み取り操作でLinuxソフトウェアRAIDをロードすることは、パフォーマンスの低下を必要とする方法です。もっと大きなものを試してみてくださいbs
。
cryptsetup benchmark
以下のコメントにfor pplの出力も追加しました。
# Algorithm | Key | Encryption | Decryption
aes-cbc 128b 476.6 MiB/s 1891.3 MiB/s
serpent-cbc 128b 79.1 MiB/s 222.6 MiB/s
twofish-cbc 128b 135.0 MiB/s 158.7 MiB/s
aes-cbc 256b 194.7 MiB/s 892.5 MiB/s
serpent-cbc 256b 46.2 MiB/s 211.4 MiB/s
twofish-cbc 256b 144.6 MiB/s 93.3 MiB/s
aes-xts 256b 1542.0 MiB/s 1727.0 MiB/s
serpent-xts 256b 114.0 MiB/s 200.2 MiB/s
twofish-xts 256b 111.4 MiB/s 131.7 MiB/s
aes-xts 512b 573.6 MiB/s 829.3 MiB/s
serpent-xts 512b 199.8 MiB/s 191.1 MiB/s
twofish-xts 512b 81.8 MiB/s 107.3 MiB/s
- (常にそうではありませんが、頻繁に)解毒がより速いことがはっきりとわかります。