web-dev-qa-db-ja.com

bcacheおよび/またはdm-cacheは、2016年の本番環境で安定していると見なされますか？

Debian Jessie本番サーバーでLinuxSSDキャッシング（dm-cacheまたはbcache）を使用したいと思います。 （カーネル3.16）

私の質問：Linux 3.16でdm-cacheおよびbcacheモジュールは信頼できますか？カーネルをより新しいバージョンにアップグレードする必要がありますか？

また、bcacheに関するこの心配なメッセージを見つけました： https://lkml.org/lkml/2015/12/22/154

信頼性とデータ損失の観点から、キャッシュモードの選択（ライトバック/ライトスルー）の意味を完全に理解していることに注意してください。私の質問は、これらのモジュールのソフトウェアバグに関するものです

2018年2月、継続的インテグレーションサーバーでのbcacheの1年以上後のフォローアップ（jenkinsインスタンスは多くの集中的なジョブを実行しています！）

サーバーの構成（基本的にストレージスタック）

ハードウェア：

  • 2 x 480GB SSD（Samsung SM863エンタープライズグレードMLC）
  • 2 x 4TB HDD（Seagate Constellation ES.3 SATA）
  • DellR730-デュアルXeonE52670-128GB RAM
  • [〜＃〜] no [〜＃〜]ハードウェアRAID、バッテリー/フラッシュでバックアップされたハードウェア書き込みbacheなし、そこでbcacheのライトバック機能が興味深いものになります。

ソフトウェア：

  • 2016年9月に構成され、再起動されなかった
  • 4.6カーネルのDebianJessie（最後の更新時の公式jessie-backportから）
  • ソフトウェアMDRAID 10
    • 2つのSSD用の1つのraid10デバイス
    • 2台のHDDに1台のraid10デバイス
  • 2つのRAIDデバイスの上に2つのLVMVG
  • sSD_RAID10VGの論理ボリューム上に作成されたbcache「キャッシング」デバイス
  • hDD_RAID10VGの論理ボリューム上に作成されたbcache「バッキング」デバイス
  • writebackとして構成されたbcacheキャッシュ

ワークロード

  • 多くのジェンキンスの仕事（継続的インテグレーション）
  • i/O強度の期間と混合されたCPU集中型ジョブ
    • bcacheを使用する前に、I/O平均遅延が5秒を超えて定期的に上昇するような期間（!!!）
  • このサーバーの実際のワークロードはわずか1年前（2017年2月まで）に開始されました

/ proc/diskstatsに従ってbcacheデバイスで発行されたI/O量）

  • 350TBの書き込み
  • 6TBの読み取り（私はそれを再確認しました。大量のRAMはVFSレイヤーで読み取りをキャッシュするのに大いに役立つと思います）

結果

  • 安定した岩！マシンを再起動する必要はなく（稼働時間525日）、破損は検出されませんでした。
  • ヒット率が高い！すべての時間平均で78％、上昇：過去数か月で80％を超える
  • ライトバックは大いに役立ちます。ディスクの待ち時間が桁違いに低くなりました。残念ながら、正確な測定値はありませんが、書き込みバーストによって計算が停止することはありません。ダーティデータの量が5GBを超えると、ハードウェアRAID書き込みキャッシュのサイズは通常512MB〜1GBになります）

結論

  • bcacheは、この構成では非常に安定しています（ただし、1マシン、1構成、1マシン年、一般化するだけでは不十分ですが、良いスタートです！）
  • bcacheはこのワークロードで非常にパフォーマンスが高く、ライトバックモードはハードウェアRAID書き込みキャッシュを効率的に置き換えるようです（ただし、電力損失の信頼性はテストされていないことに注意してください）
  • 私の個人的な意見では、bcacheは過小評価されており、それを使用して興味深いソリューションをパッケージ化できますが、元の作成者がbcachefs（bcache作業に基づくファイルシステム）を開発し、bcacheを改善していないことにも注意してください。
storagelvmssddisk-cache
2
sligor

SSDストレージのコストの削減、容量と利用可能なオプションの範囲の拡大は、必要な場所でソリッドステートストレージを使用し、選択的（およびバグの可能性がある）キャッシュの概念を先取りして使用するのに適していると思います。

環境、容量のニーズなどについて詳細を入力すると、より適切な回答が得られる場合があります。

0
ewwhite

あなたのリンク を見て、すべてのパッチを調べ、それぞれがVanillaカーネル4.9.0にマージされ、最後のパッチが2016-10-2704：31にマージされたことを手動で確認しました。 17UTC。その最後のパッチは、2016-12-11 19：17：54UTCにリリースされた4.9.0に登場しました。そして、それらはすべて、16.04からバックポートされたUbuntu 14.04で利用可能な4.4カーネル、linux-lts-xenial_4.4.0-67.88にも表示されます。

また、HDDストレージのコストも下がるので、「SSDストレージのコストの下がる」にはあまり焦点を当てません。あなたはまだお金を節約するために両方を一緒に使うことができます。または、SSDの代わりに、NVMeを入手することもできます。これはさらに高速です。

また、バグによる破損の割合はまだゼロではない可能性がありますが、バグが残っている場合でも、その割合は十分に低いため、キャッシュを使用するかどうかに関係なく、バックアップがあるかどうかを心配する必要はありません。 RAID。

3
Peter