====== Effects of ZFS Fragmentation on Underlying Storageの翻訳 ====== ZFSの断片化を調べていたら、英国ケント大学の[[http://blogs.kent.ac.uk/unseenit/|ITインフラチームのblog]]に事例が載っていた。原文へのリンクを張る事を条件に翻訳の許可を貰ったので訳してみた。

@DecomoZ sure, but please refer to the original post

— Unseen IT at Unikent (@UnikentUnseenIT) 2014, 11月 2
翻訳には細心の注意を払っていますが、誤訳や変な箇所があればご指摘下さい。例によって、本記事を利用した事で生じた如何なる結果について、翻訳者は責を負いかねます。また本翻訳について原著者への問い合わせはご遠慮願います。 ===== ZFSの断片化が及ぼす下層ストレージへの影響 ===== //Original post [[http://blogs.kent.ac.uk/unseenit/2013/10/02/effects-of-zfs-fragmentation-on-underlying-storage/|Effects of ZFS Fragmentation on Underlying Storage | Kent IT Infrastructure]]// 以前よりZFSの断片化の影響は知られていますが、それは典型的にプールの使用率が80%を超えると問題化します。こうした事実にも関わらず、我々は断片化の影響が、負荷量によって使用率70～90%のどこでも出始める事例を見てきました。 大抵は、性能の低下および空き領域の小さな塊の探索、ならびに結合で必要となるディスク書き込みが引き起こすIO負荷の増大を目にする事になります。 [[https://espix.net/~wildcat/txt/zfs-fragmentation.txt|ここ]]に目を覆いたくならんばかりの技術的詳細の良い要約があります。 本問題への適切な対処は独立のZFSインテントログ(ZIL)デバイスを持つ事ですが、我々が持つZFSルートディスクを利用する物理・仮想サーバの数的に現実的ではありません。 また残念ながら、それは問題のある既存プールの修復にはなりませんし、そしてZFSのデフラグツールは存在しません。 問題を解決するためには、あなたはデータを削除するか、追加ストレージをプレゼントする必要があります。 次のグラフはこの問題を簡潔に示しています。 下記のボリュームは競合する2つの仕事をしていました──1つが大量の読み込み(緑)で、もう1つが少量の書き込みI/O(青、マイナス軸)です。 12:00に新しいボリュームがプールに追加されました。 [{{ :blog:2014:lu_518.rrd-10800.png |新規ストレージ追加前のZFS IO}}] この時点で、既存の断片化したディスクへの書き込みは止まり、そして読み込みジョブのために2～300 IOPSを開放しました（今やCPUバウンドに達しています。） 下のグラフで、あなたは新しい断片化されていないボリュームに対する劇的に削減された書き込みオペレーションを見る事ができます: [{{ :blog:2014:lu_531.rrd-10800.png |新規ストレージ追加後のZFS IO}}] ～200 IOPSが～4 IOPSに下がった訳ですが、書き込みオペレーションが50倍に増幅されていたのです。 さらに、RAID-6の書き込みによって余分なI/Oが発生し、下層のTier-3のSATAディスクは極めて激しく動かされていました。 [{{ :blog:2014:drivebusy-unit_4-hdu_0.rrd-10800.png | デバイスビジー率}}] 当然、このファイルシステム(および本RAIDグループを共有している他の物)の性能は著しく向上しています。