web-dev-qa-db-ja.com

ZFS:ARCとZILとしての1x NVMe、および仮想化のためのzvols用の4x SSDの構成アドバイス

そのため、最近ZoLシステムをテストしたところ、SSDでのランダムおよびシーケンシャル読み取りのパフォーマンスの低下とランダム書き込みのパフォーマンスの低下を発見しました。

私たちのシステムは、ZFSパフォーマンスをテストするための2x Samsung 1TB 850Evo SSDのストライプであり、LVMと比較してひどいものでした。読み取りはHDDよりも遅く、書き込みは、LVMで得られる予想される1.7GBに達していません。 FreeBSDバックアップサーバーは低速のHDDと古いタイプのSSDを備えており、同じテストでより優れたパフォーマンスを発揮するため、これは奇妙です。

システムは、RAMですが(zfsは弧に対して4GBを取得し、他のすべてはVMによって取得されます)がある程度奪われていますが、キャッシュも同期もないため、パフォーマンスはまだ何にも近くありません。

そのため、AMD Epycに基づく新しいシステムを購入し、フルNVMeまたはSSDを備えたNVMeのいずれかを設定して、RAMをZFSから少なくとも少し解放する(すべてに最大10GBを使用したい)ことを検討しています。 ZFS以外のチェックサムのセキュリティ機能のすべてが実際に必要なわけではありません(ただし、SSDの場合、SSDは内部のチェックサムシステムを実行するため、冗長であると思われます)。SSDはvdevのストライプになります。

シンプロビジョニングされたzvol上のzleにはZFSを、リモートシステム(ZFSも実行する)へのスナップショットと増分バックアップの容易さを優先します。

しかし、パフォーマンスのための戦いは難しいです...

アドバイスをいただければ幸いです

2
Ajay

誰かが疑問に思う場合。主な問題はRAMです(ARCは4GBに制限されているため、他のすべてはシステムによって消費されます)。現時点でのZFSとの取り引き-SSDおよび/またはNVMe。それはHDDのために作られており、その愚かなヘッド、メカニズム、予測可能な問題のために遅くてかさばります。

SSDとNVMe ZFSを使用すると、彼らが必要としない愚かなことを実行し、実際に必要なことを実行しません。 ZFSが発明された当時、キャッシュは不揮発性RAMとは考えられていませんでした。

これで、4 TBのスペースを持つシステムに4x pcie SSDを配置できます。

このような場合、これを処理するには2つの方法があります。十分なメモリを割り当てて、SSDが提供するオーバーヘッドでSSDで適切に実行できるようにします。またはZFSを使用しません。

その構造上の利点はかなり良いので、それは残念です。しかし、より多くのRAM HDDを使用するよりも使用量が少ないと、SSDを適切に処理できません。すべての設定と構成が、「基礎となるシステムは低速で、キャッシュが必要であり、小さいサイズで読み取り、大きいサイズでシーケンシャルに書き込みます」 SSDが高速の場合、キャッシュは不要で、大きな読み取りと大きな書き込みが可能で、ランダムに適切に処理できます。Optaneを使用すると、このような問題は明白になります。

多かれ少なかれ必要とされていないのは、大規模なキャッシング、レコードレベルでの各ファイルのチェックサムです(SSDレベルでビットロートがある場合、ドライブ全体を破棄する必要があるため、意味がありません。このようなシステムは、コントローラ全体が壊れてデータ全体を台無しにする可能性があるため、不良RAMに似ています)。 SILはまったく必要ありません。 ARCは、特にOptaneドライブでは特に役に立ちません(CPUとRAMにオーバーヘッドを追加します)。レコードサイズは、ドライブが理解できるトランザクションでの書き込みに完全に制限する必要があります。

または、単にKVM=システムでのプロビジョニングにLVMを使用します。シンプロビジョニングはそこで完璧ではありませんが、少なくとも非常に貴重なRAMを作成することで無駄にする必要はありません。 SSDは本来のレベルで動作します。

1
Ajay

まず、ZFSチェックサムはnot冗長です。これはエンドツーエンド(RAMから物理メディア)のチェックサムですが、HDD/SSDチェックサムは「内部メディア」エラー制御として使用されます。古典的なファイルシステムと同様のものを使用するには、SATAデバイスにはないT10/DIF互換のディスクとコントローラーを使用する必要があります(使用を強制される= SAS SSD、はるかに高価です)。

つまり、ZVOLの書き込みパフォーマンスが低いのは、デフォルトの8Kブロックサイズが非常に小さいためです。これは、メタデータオーバーヘッドを大幅に増やすには十分小さいが、4K書き込みの読み取り-変更-書き込みサイクルを防ぐには十分ではありません。

(Samsung 850 EVOとしての)コンシューマーSATA SSDディスクのもう1つの問題は、Powerlossで保護されたキャッシュがないため、ZFSがメタデータの書き込みおよび同期データ書き込み。

とにかく、正確な答えを得るには、実際の予測ワークロードの終了時にベンチマーク手法の詳細を実際に提供する必要があります。

3
shodanshok

ZFSのデフォルトは、実行している作業に理想的ではないため、パフォーマンスは低下します。 /etc/modprobe.d/zfs.confに何かありますか?そうでない場合は チューニングが必要 です。

  • VMはZFSインストールと同じサーバーで実行されますか?
  • その場合、ZILは必要ありません。これは、NFSをVMwareや一部のデータベースに提示するなど、同期書き込みアクティビティでのみ役立ちます。
  • ネイティブディスク上のZFSストレージには128Kブロックサイズを使用します。
  • Linuxの場合、zvolsはvolblocksize=128Kである必要があります
  • すべてのSSD ZFS zpoolにはashift = 13を使用し、それ以外のすべてにはashift = 12を使用します。
  • ARCを無効にしないでください。必要に応じて制限しますが、RAMが不足しているようです。
  • チェックサムを無効にしないでください。
  • LZ4圧縮を有効にしてください!しない理由はありません。
  • NVMe + 4xSSDで何をするつもりですか?
2
ewwhite

特に、誰かがdocker(iのように)を使用している場合、定期的にビルドするか、多数のコンテナーとボリュームがある場合(iのように)UFSは実際の本番ソリューションではありません。

DockerはZFSバックエンドを使用できるため、ZFSを実行しているシステムでSSDとOptaneを使用したいという人もいます。

@Andrew私はあなたがしたのと同じ問題のいくつかに出くわしました、そして大規模なRAM(ARCの32G)で私の問題を修正する必要がありました。)サーバー全体は128GBのRAMですが、驚くべきパフォーマンスを実現できるシステムはほとんどありません。

別の人々のセットは、burstIOを回避するためにAWSでZFSストライプを実行している人々です-本質的にすべてのEBS SSDボリュームは、バーストバランスが低下するとすぐにSATA 5.4Kのようなパフォーマンスの表示を開始するのを待っています。この種の状況では、ZFSが突然、大きなシーケンシャルIOに追いつくために切り替わるのがわかります。アプリケーションがバーストバランスを監視してIOを減らす限り、ZFSは正常な状態を維持しようとします。

マルチウェアの超仮想化を超えた健全性ストレージアレイが重いIO&レイテンシの急増時にパフォーマンスを動的に管理しようとするとき、VMWareの人々は非常によく似たものを経験することを期待します

本質的に大きなRAMキャッシュが書き込みプールとして使用されるストレージシステムの設計を知っています。これは、基本的にストレージがすべての書き込みをキャッシュヒットと報告し、ディスクへのステージングが後で発生することを意味します

少なくともZFSがあれば、実際のプログラマーがそれを作ったことを知っています。

したがって、SSD上のZFSにはまだ価値があります。それは、発生した問題の種類によって異なります。

1
demorphica