ZFSのdedup地獄から命からがら逃げ延びた話

はじめに
環境
dedup=onに気付くまで
dedup=offに出来ないか
頑張る
まとめ
脚注

はじめに

これはついうっかり大きなデータを書き込むようなZFS ファイルシステムにおいてdedup=onしてしまった挙げ句，気付かないでガンガン運用してすでに数TB書き込んでしまったという全国のドジっ子メイドさんが一人でも救われれば良いなと思って書いています．ちなみに最初に言っておくと今回も前回と同様*1救いはないです．

環境

サーバー構成

CPU: Core i3-3220 3.3GHz
メモリ: DDR3 24GB
システムドライブ: SSD128GB
Ubuntu Server 16.04 LTS
ZFS on Linux

$ cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=16.04
DISTRIB_CODENAME=xenial
DISTRIB_DESCRIPTION="Ubuntu 16.04.2 LTS"
$ sudo zfs upgrade
This system is currently running ZFS filesystem version 5.

All filesystems are formatted with the current version.
$ modinfo zfs
filename:       /lib/modules/4.4.0-70-generic/kernel/zfs/zfs/zfs.ko
version:        0.6.5.6-0ubuntu15
license:        CDDL
author:         OpenZFS on Linux
description:    ZFS
srcversion:     D82FFDF4C1394A435E2B38A
depends:        spl,znvpair,zunicode,zcommon,zavl
vermagic:       4.4.0-70-generic SMP mod_unload modversions
...
$ cat /etc/modprobe.d/zfs.conf
options zfs zfs_arc_max=10737418240

zpoolの構成は以下

$ sudo zpool status
  pool: data
 state: ONLINE
  scan: resilvered 33.8M in 0h0m with 0 errors on Tue Jun 27 21:38:30 2017
config:

        NAME                                           STATE     READ WRITE CKSUM
        data                                           ONLINE       0     0     0
          raidz1-0                                     ONLINE       0     0     0
            ata-WDC_WD30EFRX-68EUZN0_WD-WCC4N0YZ2854   ONLINE       0     0     0
            usb-I-O_DATA_HDCL-UT_000277B591400351-0:0  ONLINE       0     0     0
            ata-WDC_WD30EFRX-68AX9N0_WD-WMC1T0534235   ONLINE       0     0     0

errors: No known data errors

ここから以下の様に領域を切っています．（救われた後の様子です）

$ sudo zfs list
NAME               USED  AVAIL  REFER  MOUNTPOINT
data              1.66T  3.61T   139K  /data
data/tank         1.48T  3.61T  1.48T  /data/Nas
data/timemachine   167G   133G   167G  /data/timemachine

`dedup=on`に気付くまで

実はサーバを構築した当初からdedupというオプションは絶対onにしないようにしようと堅く心に誓っていました．少なくともそう思って構築して運用してきていたので，どうもファイル操作をするとサーバが不安定になるがこれはなぜだろう，メモリが足りない？でも1GBとかでも動かしている人はいるしなぁ…とずっと不思議に思っていました．

うちのサーバはprometheusでリソースの監視をしている*2のですが，数十GB単位のファイル削除を行ったり，ファイルを連続して数十GB書き込んでいくとloadの値がぐっと上がり，node-exporterのnode_cpuメトリクスを見るとiowaitの値が急激に上がり，メモリを食い潰し，大量のスワップが発生することが分かったのもつい最近のことです．監視始めて良かった．

救われる前のZFSの領域はdata/Nasとして領域を切って以下の用途で運用していました．

chinachuおよびmirakurunを使用した録画データの置き場
写真のバックアップ
iTunes Mediaのバックアップ
Windowsのバックアップ

だいたい3TBぶんほど消費していました．

実はこの運用の仕方をし始めてからずっと以下の症状に悩まされていました．

Windowsからの書き込み時に十数GBを超えた当たりから一気に速度が落ち，エラーが出て書き込みに失敗する
大量に書き込んだ後極端にsambaの共有領域が重くなり，開けない，検索が出来ない，などが頻発する
数十GB単位で削除すると同様にファイルが開けない，検索ができない，などが頻発する．

実際の所そんなに激しいデータの読み書きをすることは少なく，これまでもなんとなくで運用は出来ていました．が，残り領域が2TBを切ったあたりからどうもパフォーマンスが悪くなったような気がしてならず，重い腰を上げて調べ始めたのがこの春のことでした．

ARCに制限を加える

まず最初にわかったのはメモリがあまりにも大量に使用されることです．何の設定もしない状態ではARCキャッシュとして

搭載メモリーが 4G バイト未満のシステムでは、メモリーの 75%

搭載メモリーが 4G バイトを超えるシステムでは、physmem から 1G バイトを引いた値

が使用されることになっているようです*3．
うちのサーバではprometheus以外にもMinecraftサーバやGitlabサーバなどそれなりにメモリを消費するアプリケーションが複数あり，メモリが逼迫されることでレスポンスが異常に悪くなっていました．

とりあえず重くなっても動作はしてくれるようにZFSのARCサイズに制限を加えることとしました．これは/etc/modprobe.d以下に適切に配置することによって可能です．

$ sudo bash - c 'echo "options zfs zfs_arc_max=10737418240" > /etc/modprobe.d/zfs.conf'
$ sudo reboot

これでとりあえず10GBまでしかARCとして消費されなくなりました．

が，結果的に消費メモリが減ったおかげで書き込みや削除はより頻繁にフリーズするようになりました．

ZFS以外の領域に書き込んでみる

システムドライブに書き込んでみたところ全く問題なし．SSDなので速いだけかなぁ，やっぱりHDDは遅いしダメだな，とか思っていました．

sambaの設定を見直す

とくに悪さをしていそうな所は無し．実は一番最初はここを疑っていましたが，macからscpコマンドなどを使って書き込んでも再現したので疑うのを辞めました．

ZFSのパラメータを疑う

このあたりからだんだんと「あれ…？もしかしてdedup=onになってたりする？そんな馬鹿な」という疑惑が持ち上がってきていました．

$ sudo zfs get dedup data
NAME  PROPERTY  VALUE          SOURCE
data  dedup     off            default

ほら大丈夫じゃん！とここで放置してしまったのが運の尽きでした．当初このオプションは全体に適用されると思っていたため，ここを調べれば分かるだろうと思っていました．しばらく悩んだある日，なんとなくでdata/Nasのオプションを調べたところビンゴでした．

$ sudo zfs get dedup data/Nas
NAME  PROPERTY  VALUE          SOURCE
data  dedup     on            default

dedup=offに出来ないか

絶対先人がいるだろうと思ってググったらやっぱりおられました．

d.ballade.jp

ZFSを運用する者が知っておくべきこと（障害対策） – 日曜研究室

FreeBSD：zfsが調子悪いです(´Д｀;) | 猫鯖の部屋

とりあえず

zfs set dedup=off data/Nasしちゃいけない
zfs destroy data/Nasしちゃいけない

ということが分かりました．

頑張る

前回も新しいプールを作成してashift値を変更するとかそういう強引なことをしましたが，今回も強引に行きます．

dedup=offな領域data/tankを切る（/data/tankにマウント）
サーバ上にしかないなくなると困るデータを/data/tankにrsyncでコピー
data/Nasのマウントポイントを/data/Nas_oldに，data/tankのマウントポイントを/data/Nasに変更
どうにかしてdata/Nasを消す

1. 新しい領域の作成

$ sudo zfs create data/tank
# 念のため
$ sudo zfs set dedup=off data/tank
$ df -h | grep data/tank
data/tank         1.9T  0  1.9T  0% /data/tank

2. データのコピー

バカみたいに時間がかかるのでscreenを使いましょう．また，普段使いに極力影響しないように帯域制限をかけて負荷を抑えています．
容量に余裕がない場合，データの取捨選択をするか，少しずつデータをコピーし，その都度dedup=onな領域から少しずつ削除すると良いと思います．

$ screen -S rsync
$ rsync -ahvP -bwlimit=2048 \
    --exclude="hoge" \
    --exclude="fuga" \
    --exclude="piyo" \
    /data/Nas/* /data/tank

3. マウントポイントの変更

この操作の前にこれらの領域を使用するアプリケーションを全て止めましょう．

# アンマウントする
$ sudo zfs umount data/Nas
$ sudo zfs umount data/tank
# マウントポイント変更
$ sudo zfs set mountpoint=/data/Nas_old data/Nas
$ sudo zfs set mountpoint=/data/Nas data/tank
# 再びマウント
$ sudo zfs mount -a

4. dedup=onな領域を削除

ここで「意外とdestroyでいけるんじゃないか？」と思い，実行．

$ screen -S del
$ sudo zfs destroy data/Nas

最初は順調にいっているように思いましたが，途中からサーバが完全に応答しなくなり，強制的に落とすとディスクを一枚ちゃんと認識しなくなって焦り，ひどい目にあいましたので皆さん絶対に辞めておきましょう．

書き込み済みのデータが多すぎることが問題なので少しずつ消していくスクリプトを書きます．

$ vim delete.sh
#! /bin/bash

TOTAL_SIZE=0
TARGET_DIR=/data/Nas_old
LIMIT=2048
INTERVAL=120

find $TARGET_DIR -type f | while read FILE
do
  SIZE=`wc -c "$FILE" | awk '{print $1}'`
  TOTAL_SIZE=`expr $TOTAL_SIZE + $SIZE`
  echo "Found $FILE"
  echo -e "\tFile size: $SIZE"
  echo -e "\tTOTAL: $TOTAL_SIZE"
  echo -e -n "\tTry to delete $FILE ... "
  ionice -c 3 rm -f "$FILE" >& /dev/null 2>&1
  if [ $? -eq 0 ]; then
    echo "[SUCCESS]"
  else
    echo "[FAIL]"
  fi
  S=`expr $TOTAL_SIZE / 1048576`
  if [ $S -ge $LIMIT ]; then
    echo "TOTAL_SIZE is over than $LIMIT MB. Sleep $INTERVAL sec."
    sleep $INTERVAL
    TOTAL_SIZE=0
  fi
done