RN214、OS6.10.3で未明にフリーズ発生

[さんどひる]

みなさんこんにちは、さんどひる(sandhill)と申します。

ひと月ほど前に入手したRN214で、今朝見たらフリーズしていました。

構成はこうです。

・本体8TB×4、X-RAID

・外付けUSB3 4TB×2　USBケーブル1本で2つドライブが入るユニットを接続

・OSは6.10.3

本体ストレージは長期保存用、外付けは処理前データを保存しているので、2週間～数か月のスパンで新しいデータが入っては処理されて消えていきます。

外付けが一時受けとはいえファイルが飛ぶと困るので、バックアップ機能でスケジュールを設定してUSB3の1台目から2台目に未明の朝方に同期させています。このバックアップは運用を始めてまだ3日程度です。

フリーズした時間は記録によると朝方バックアップ実行時間の最中ですが、この時同時にやっていたのは本体ボリューム(Data)のディスクテストとPC端末からの自動ファイル書き込みです。

この日にディスクテストを実施したのは、結構前からRN104で使っていたドライブ4台をそのまま214に移したのですが長いことチェックしていなかったので前の日に仕掛けておいた、というだけです。4台のドライブには元々特にSMARTエラーは出ていませんでした。

他にやっていることとすれば、SSHでOSに入ってdnsmasqを立ち上げ、同じLAN環境内にあるホスト類のDNS名前解決をさせています。

今朝フリーズしてdnsmasqがPCの名前解決をしなくなっていたので「ネットが止まっている」と朝いちから騒ぎになり、フリーズに気付きました。

確認したらdnsmasqやファイルサーバ機能だけでなくOSもNICインタフェイスもすっかり無応答でpingも応答しない状態でした。

本体インジケータは1～4のドライブLEDと電源LEDは点いていたものの電源ボタンをあれこれ操作しても無反応で、結局ACアダプタを抜いて挿し直したら復帰しました。

ここで怪しいのは、ディスクテストとバックアップが同時に走ったことかなと思っています。ただそれぞれがアクセスするディスクは、一方は本体でもう一方はUSB3デバイス2台間だけなので、デバイスレベルでの干渉がありません。まあOSレベルで何か起こったのだろうと思います。

とりあえず当面はこれらが並行で走らないように注意しますが、何か皆さんの方で経験的に、あるいはメーカーから得たことで何か関係しそうな情報はありますでしょうか。よろしくお願いします。

[さんどひる · Accepted solution]

その後の経過ですが、フリーズしていません。

一旦安定状態に入ったと判断します。

何が悪かったのかというところですが、フリーズが起こっていた時のバックアップ構成が以下で、

USBドライブ(共有フォルダ)⇒USBドライブ(localhostにrsync)

rsyncデーモンがローカルホストからファイルを受信してUSB外部HDDにファイルを書き込むと何か問題が起きる、ということかなあと思います。

ただしネット上ではrsyncでUSB外部HDDにバックアップを採る運用をしている人は他にもいるので釈然としません。

ちなみに今まで書いていませんでしたが、外部HDDのファイルシステムはNTFSです。

NASから外してPCに繋いでもすぐ参照できるためです。exFATでも良かったのですが。

とりあえず安定したということで一旦クローズします。

[jse]

当方ではRN31444E-100AJSにバッファロー製 HD-WH16TU3/R1-Cを接続し、週1回のスケジュールでNASに保存されたデータのバックアップを取っています。

ディスクテストについては週1回のスケジュールで実行しています。過剰だと思いますが、以前月１回としていた際にバックアップと重なってしまい、バックアップにかかる時間が通常に比べて大幅に伸びた経験からです。

同様にスクラブ中にバックアップが始まっても同じ状況になります。（当然ですが此方の方がより長い時間がかかります）

経験的にNASおよび外付けHDDに負荷のかかる作業は同時に実行するべきではないと考えています。

幸いフリーズは経験していませんが、恐らくハードウエアの能力的にこの辺りが限界なのではないでしょうか。

[さんどひる]

@jseさま

ありがとうございます。

ドライブに負荷のかかる処理の集中は私も通常避けています。

今回ディスクテストとバックアップが重なったのはたまたまというか、「前日にディスクテストを仕掛けた」というのは深夜未明に走らせるスケジュールを仕掛けたのではなく前日から処理を走らせていて、長時間かかるところに未明のバックアップ処理のスケジュールが重なったという感じです。
で、実は今朝も未明にフリーズしました。今回はディスクテストは走っていません。
日次の朝方バックアップ自体は完了ログが出ているのですが、夜中にNASにアクセスしてデータ処理しているPC側のログを見るとちょうどNASのバックアップ完了直後にNASへのアクセスが不能に陥っていました。つまりディスクテストとバックアップ処理が重なったことが問題ではないようです。
USBドライブ(共有)⇒USBドライブ(localhostにrsync)のバックアップが悪いのかもしれません。もう少し確認します。

[さんどひる]

その後の状況ですが、少し構成を変えて運用しています。
まだ構成を変えてから4日目ですが、今のところそれからはフリーズしていません。
変更点は以下です。

従来：　 未明にUSBドライブ(共有フォルダ)⇒USBドライブ(localhostにrsync)
変更後： 未明にUSBドライブ(localhostからrsync)⇒USBドライブ(共有フォルダ)

まだたまたま落ちてないだけかもしれないので、このまま様子を見ます。

[さんどひる · Accepted solution]

その後の経過ですが、フリーズしていません。

一旦安定状態に入ったと判断します。

何が悪かったのかというところですが、フリーズが起こっていた時のバックアップ構成が以下で、

USBドライブ(共有フォルダ)⇒USBドライブ(localhostにrsync)

rsyncデーモンがローカルホストからファイルを受信してUSB外部HDDにファイルを書き込むと何か問題が起きる、ということかなあと思います。

ただしネット上ではrsyncでUSB外部HDDにバックアップを採る運用をしている人は他にもいるので釈然としません。

ちなみに今まで書いていませんでしたが、外部HDDのファイルシステムはNTFSです。

NASから外してPCに繋いでもすぐ参照できるためです。exFATでも良かったのですが。

とりあえず安定したということで一旦クローズします。

[さんどひる]

OSの新しいアップデート(6.10.4)が出ましたが。

https://kb.netgear.com/000062588/ReadyNAS-OS-6-Software-Version-6-10-4

リリースノートBug Fixesの4番目にあるこれ。

• Back up to remote rsync share fails

今回の件に関係ありそうなような…

[さんどひる]

今朝未明、また久しぶりにフリーズしました。再発です。

しばらくちゃんと動作していましたが、それはたまたまで結果的にローカル共有とrsync間のバックアップ方向の違いは関係なかったようです。

アダプタ抜いて再起動したのを機にOSを最近出た6.10.4に更新してまた様子を見ます。

リリースノートのrsyncに関するバグフィックスが該当していればいいんですが…

[さんどひる]

OSを最近出た6.10.4に更新してから全くフリーズしなくなりました。

どうやらリリースノートに記載あった修正がビンゴだったようです。

[さんどひる]

残念。

今朝方フリーズ再発。

ダメだなこりゃ。