hack のためのネタ帳, etc,,,

IO-DATA 製 NAS

参考になるページ

rsyncd

rsync 873/tcp が open している。
これは、LANDISKの共有フォルダにおけるネットワークバックアップ用。
rsync LANDISK::
とすれば、ネットワークバックアップを有効にしているフォルダが見える。
rsync username@LANDISK::disk1
などとすれば、そのフォルダの中をアクセス出来るはずだが、
現時点では username の生成規則が不明であるためアクセス出来ない。

username 各共有フォルダ毎にホスト名と共有フォルダ名から生成される模様。

ここの生成規則が分かると、
UNIX側でrsyncをdaemonモードで起動しといて
LANDISKからネットワークバックアップさせるなんて運用が可能になるはず。

とりあえずUNIX系OSと使う場合にはrsync/sshが使えないのはかなり痛い。

感想など

まず、内蔵HDDの素性。
手元のHDL-XR4.0は
Hitachi HDS721010CLA332 1000 GB
の4機構成だった。
付属の管理マニュアルp26では
Seagate ST3500820AS 500 GB
の4機構成になっている。
モデルは通常PC用の容量コストパフォーマンス重視品を適宜選んでいるものの
コストを最優先とはしておらず、
メーカーには若干こだわりを持って選定してそうな雰囲気。

管理はweb経由で行う。
レスポンスは前モデルよりはかなり改善されているとのことだが、決して速くはない。
どちらかというと普通に遅い。
ページにもよるが、ページ遷移におよそ1〜8秒くらい待たされる感じ。
決してキビキビとう印象ではない。
分かる人には分かるだろう表現としては、
ades(Windows Mobile 6)みたいなもっさり感という表現がぴったり。

10分放置で強制ログアウト。
放置許容時間の設定変更は見当たらない。

管理画面のよく言えばシンプル、悪く言えば自由度が低いと言える。
サーバー自前で構築出来ない人にはシンプルで悪くないのかもしれないが、
サーバーを自前で構築できる人だとちょっとストレスがたまるだろう。

ADを導入してない環境で大人数で使う場合アカウントと共有フォルダを1つ1つ作らないといけないので管理が面倒と言うか著しく手間がかかると思う。
アカウントと共有フォルダの登録はCSVによる一括登録が出来るのでまだマシだと思うが、抹消は一括では出来ないので辛そう。

アクセス許可は管理画面(web)からのみ設定可能で共有フォルダ単位で行う模様。
これはACL的にLANDISKが認識するユーザ、グループ単位でr/wの許可が可能ではあるものの、
要するにLANDISKの管理者以外は設定できない。
Windowsのexplorerからファイルを右クリック「プロパティ」>「セキュリティ」からアクセス許可する場合、
chmod的にuser/group/other単位のフラグ設定はファイル、フォルダ単位で出来てる。
アクセス許可するユーザーやグループの追加削除は出来ない。
なので、ファイルの所有者がファイル、フォルダー単位でアクセス許可を管理することはできない。

バックアップ機能は世代を残せるので便利かも。
内部的にはハードリンクを利用して差分更新による世代バックアップをすることで消費容量を節約している模様。
ファイル数が増えると、当然のように処理時間が必要となるため、
キューに溜まったバックアップジョブを順次消化する仕組みになっているようだ。

パフォーマンスは
数MB単位のファイルが数GBあるフォルダをGbE経由でコピーすると
タスクマネージャーの表示では通信帯域を160Mbpsくらい消費。
つまり実用上は20MB/sくらいは出てる計算。
ただし数KBくらいのファイルが数MBあるフォルダを100Base経由でコピーした場合だと5Mbpsくらいに落ち込む。

HDDが4機も搭載されているため消費電力はそれなりにあるはず。
しかし省電力をONにすると時間を置いて再アクセスした場合spinupのためか10秒近く待たされる感じ。

騒音に関しては、HDD用の中型FANは極めて静粛。
制御基盤用(?)の小型FANは結構頻繁に回っては止まる。
こちらが回り始めると、結構ノイジー。
ちょっと昔の液晶プロジェクターと同程度と言えば良いだろうか。
2〜3m以内で遮蔽物が無いと結構気になるかもしれない。

難しいことは考えずにRAID6の安心感を得たいなら悪くない選択肢ではあるものの、
価格がちょっと高いのが難点。
自前でZFSのRAIDを構築できるなら、
SATAx4port以上あるM/Bにリムーバブルベイぶら下げても十分におつりが得られる価格なので
利便性、柔軟性、静粛性という面では悩ましいところ。

2013-04-17:
そう言えばと言うか、今さら気が付いたんだが S.M.A.R.T を見るための入口がない。
トラブル時、凄いストレスだな。これ。

RAID6 再構築中の web 管理画面のレスポンス
とりあえず 3 回づつ測ってみた。
  • 情報表示
    • お知らせ : 5s, 11s, 11s
    • システム情報 : 39s, 44s, 20s
    • ネットワーク情報 : 28s, 13s, 13s
    • ボリューム情報 : 29s, 42s, 15s
    • ログ情報 : 8s, 7s, 49s
    • アクセスログ : 16s, 14s, 13s
我慢できないくらい遅い。と言うか我慢できない。本当に遅い。

2015-01-05:
LANDISK 上のファイルを開いて lock された状態で、ファイルを開いた PC がフリーズとかすると、ファイルの lock が解除出来なくなる。
一応サーバー上で設定いじったりコマンド叩ければ以下の方法で何とかできるんだけど LANDISK はそういうの一切駄目なので LANDISK を再起動する以外に lock を解除する方法がない。 極めて使い辛い

2012-05-23: 構成等

disk4 が死んだと警告が出たので取り出して parted でパーティションテーブルを確認して見たところ以下のようになっていた。
(parted) print                                                         
モデル: Hitachi HDS721010CLA332 (scsi)
ディスク /dev/sdg: 1000204886016B
セクタサイズ (論理/物理): 512B/512B
パーティションテーブル: gpt

番号  開始         終了            サイズ         ファイルシステム  名前     フラグ
 1    17408B       512000511B      511983104B     fat32                      msftres
 2    512000512B   1536000511B     1024000000B    ext3              primary
 3    1536000512B  3584000511B     2048000000B    linux-swap(v1)    primary
 4    3584000512B  3712000511B     128000000B     ext2              primary
 5    3712000512B  4224000511B     512000000B     ext3              primary
 6    4224000512B  1000204869119B  995980868608B                    primary
partition 2 は Linux のルートディレクトリが入ってて、以下のようなファイルが発見できる。

/etc/fstab

partition3 は swap に決め打ち。
片っ端から mount してるので、最大10ディスク構成まで想定しているらしい。

/etc/mdadm/mdadm.conf

ファームウェア周りは 6 ディスクで raid1 ミラー構成にしているようだ。
10 ディスク構成の場合残り 4 つをどうするのかは謎。

多目にミラーリングしてる設定は、保険のためなんだろう。
とりあえず各パーティションは以下のように raid で構成されていて以下の場所にマウントされる模様。
partitionmodemdadmmount point
1raid1md1/boot
2raid1md2/
5raid1md5/mnt/hda5
partition6 は実際には raid6 で設定してあるので、raid5 のパラメータ変更すると raid6 になるみたい。
raid6 に設定するという情報は partition4/disklabel/ 以下や、partition5/conf/raid/ 以下にそれらしい情報が格納されている。partition4 は partition5/bin/disklabel から参照して partition5/bin/raidctrl や partition5/bin/mdadm_handler で使っており、これで md6 の raid level を決めているようだ。
partition5 は管理画面用関連がまとめられているっぽい。partition2/etc/ から symbolic link で参照しているファイルが多数置かれているので、設定を本体から切り分けているということだろう。
partition5/conf/rsync_secrets/ 以下を見ると rsyncd 用の user:password があるので、これを使えば rsync 出来るのかも?

ディストリビューションは Debian 使っている模様。
DropBox 対応する直前のファームの場合
partition2/etc/debian_version 見ると 5.0.2
apt-line は以下。

partition2/etc/apt/sources.list

コマンド関連は file かけてみると以下のようになっていた。
ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.14, stripped

正常時の起動ログは以下

partition5/log/kern.log.1

翌日、disk4 が死んだ時のログ。

partition5/log/kern.log.0

debian_version に対してカーネル古くないか?

さて、問題の HDD の故障具合なのだが、
udisks --show-info で調べて見たところ S.M.A.R.T が以下のような状態だった。

$ udisks --show-info /dev/sdg

reallocated-sector-count が 13 出てるがこれは間接的な原因(?)で raw-read-error-rate が腐ってたのが直接の原因だったのではないかと?
ところが、上記の解析を行うため、しばらく Ubuntu にぶら下げてたら、以下のように raw-read-error-rate の FAIL が解消されてしまった。

$ udisks --show-info /dev/sdg

う〜ん、これはどうしたものか?
確かに bad sector が 13 sector 出ているのは気持ち悪いし、Deskstar 7K1000.C の仕様を見ると、Error rate (non-recoverable, bits read) は 1 in 1014 なので、13 / 1953525168 = 0.0000000067 = 6.7e-9 は桁違いに大きい error rate なんだけど、このくらいの bad sector は年単位で使ってると普通に出るし、まだ慌てる数字じゃないんだよね。
むしろ仕様がサバ読み過ぎと言うか、1e-14のレベルでしかエラー出ない HDD なんて稀だろ?
もちろん reallocated された sector はデータが欠損してるので、このまま raid に戻して異常なしとされた場合、一見正常に動いているように見えても、実際にはサイレントクラッシュしてるはずなのでそれはそれで困るんだけど。いっそ、パーティション情報消去して、リビルドさせちまうとか?
こういうとき ZFS だと checksum 見て自己修復してくれるから、多少 bad sector 出ても安心なんだけどなぁ。

2012-05-25:
bad sector の欠損データに関してはアクティブリペアーかけとけと言うことらしい。
アクティブリペアーかけとくと不良セクターが発見された場合、他の正常なディスクからデータを読み込んで、異常のあるディスクに書き込む事により、ディスク不良によるデータ損失を未然に防止出来るとのこと。詳細は「画面で見るマニュアル」参照。

2012-05-25: RAID の再構築

2012-05-25 現在の価格だと純正カートリッジとベアドライブとでは下手すると価格が倍近く違う。 昨日、パーティション覗いた結果と、容量増やした人の作業手順見る限り、少なくとも1ドライブ正常なら、あとは適当に作り直してくれるのは間違いなさそうなので、とりあえずカートリッジの中身だけ入れ替えることにした。
幸運にも新品の HGST HDS721010CLA332 が地元で調達出来たのだが、純正カートリッジの中身はドライブが何使われているか分からないので、他のドライブと同じ機種が入手可能なら、むしろ純正カートリッジを使うメリットとは一体何なのだろうと、しばらく考え込んでしまった。ベアドライブ売っても利益は出るので、回路とか一切含まない単なるプラスチック製のカートリッジ代のためだけに \4,000 以上上乗せして売っているのはちょっとあこぎなのでは?とも思うのだが、純正品じゃないと動かないような変な仕掛けをしてないだけまだ良心的なのかもしれない。

不良が発生したカートリッジの中身を新品と交換する以外、特に下準備等は不要。
カートリッジを本体に挿入し、スライドスイッチを ON にすると、自動的に RAID の再構築が始まった。
2012-05-25 12:47 再構築開始のメール受信
2012-05-26 02:42 再構築完了のメール受信
結局14時間弱かかった模様。
1,000,204,886,016B / 50,100s = 19,964,169B/s
お世辞にも速いとは言い難いし、
RAID6 構成とは言え再構築時間がここまで長いのは精神衛生上あまりよろしくない。

2013-04-17: HDD の接続不良?

起動したらアラーム音が鳴ったので確認してみると、disk4 のインジケーターランプが消灯していた。
そのままの状態で disk4 のエンクロージャーを外から押してみたところ、インジケーターランプが消灯しアラーム音が消えた。
とそこまでは良いのだが、飛んできたメール確認してみると、
2013-04-17 09:50
[LANDISK] ディスクエラー警告
RAIDの構成異常が発生しました。(2310-8113)
2013-04-17 09:51
[LANDISK] RAID
RAIDが正常状態に復帰しました。
2013-04-17 09:53
[LANDISK] RAID
内蔵ボリューム-再構築を開始しました。
とか、をぃをぃ、って状態。
ログ見ても
2013/04/17 	09:53:15 	イベント通知: RAIDメールを送信しました。
2013/04/17 	09:53:14 	RAID: 内蔵ボリューム-再構築を開始しました。
2013/04/17 	09:51:59 	イベント通知: RAIDメールを送信しました。
2013/04/17 	09:51:58 	RAID: RAIDが正常状態に復帰しました。
2013/04/17 	09:51:53 	ディスク: 内蔵ディスク4が接続されました。
2013/04/17 	09:50:35 	イベント通知: ディスクエラー警告メールを送信しました。
2013/04/17 	09:50:32 	RAID: RAIDの構成異常が発生しました。(2310-8113)
としか出て来ない。
症状から見ると、SATA の信号または電源コネクタの接触不良なんだけど、これは上記にあるように前回交換したディスクであり、約11ヶ月間、問題らしい問題は起きてなかったのになぜこのタイミングでいきなり接触不良を起こすんだ?っていう。差し込み方が甘かったの???
しかも、単なる接触不良で、起動直後に復旧して、他のディスクとほとんど差異が生じてない状態なのに、接続が復旧したタイミングでまるごとリビルドされるとか、それはちょっとそれはどうなの?って動作してくれるのは、今後の安定運用考えるうえでちと厳しい。
再度接触不良が生じないとも限らないし、それでいちいちリビルドかけられたんじゃ、いくらなんでも辛すぎるでしょ。

つぅことで、冗長性落ちた状態で14時間辛抱せねばなりませんよと。
うちは RAID6 だからまだ良いようなもんだけど、これでもともと冗長性 1 しかない構成だったりすると死ねるわ。
しかも、うちの職場、退室すると空調切れるので、夏場にこれやられると本当に死ねる。

2013-10-10: RAID の構成異常

disk3 が腐った模様、、、
2013/10/10 	22:13:13 	イベント通知: ディスクエラー警告メールを送信しました。
2013/10/10 	22:13:08 	ディスク: 内蔵ディスク3が取り外されました。
2013/10/10 	22:13:07 	RAID: RAIDの構成異常が発生しました。(2310-8113)
忙しい時に限っての法則発動。orz
どうせ、極少数、せいぜい2桁程度の reallocation sector が発生してるだけなんだろうけど、なんでセルフリペアしないのか?
いくらなんでも弱過ぎ。

2013-10-16: DISK4 の接続不良?

気付いたら、disk4 のインジケーターが青色点滅してる(- -;;;)。
ボリューム情報確認してみたところ、以下の状態。
内蔵ボリューム
動作モードRAID6
状態使用中:構成異常
ボリューム情報全容量1991 GB ( 1991827193856 byte )
使用容量950 GB ( 950027251712 byte ) 47.6%
フォーマット形式専用
構成ディスク内蔵ディスク1接続済 Hitachi HDS721010CLA332 1000 GB
内蔵ディスク2接続済 Hitachi HDS721010CLA332 1000 GB
内蔵ディスク3故障 Hitachi HDS721010CLA332 1000 GB
内蔵ディスク4未接続
お前、また接続不良なの?
よりにもよって、代替 HDD の手配がままならないこのタイミングで???

ログとメールは、以下の項目しか出てない。
2013/10/16 	09:44:56 	イベント通知: ディスクエラー警告メールを送信しました。
2013/10/16 	09:44:52 	RAID: RAIDの構成異常が発生しました。(2310-8113)
2013-10-16 09:44:56
[LANDISK] ディスクエラー警告
RAIDの構成異常が発生しました。(2310-8113)
これ、異常個所がきちんと書かれておらず、ちょっと不親切過ぎ。
故障中に故障が起こると気付かんだろ、これ?

これまでの、傾向からすると、
新たに sector 欠損見つけた時点で、多分 disk 1 か 2 を切り離なしにかかることは間違いないので、
そうなる RAID 崩壊するから完全に詰むね。これは。

とりあえず Ubuntu に cifs で mount して zfs-fuse に GbE 経由で、以下のような感じで退避を図る。
sudo mount -t cifs -o user=myname //LANDISK/hoge /media/LANDISK
rsync -auSv -progress /media/LANDISK ./
読み出しが 10MB/s 前後で、ピークでも 20MB/s 強が限界くらいの感じ。
ZFS が悪いのか RAID6 が悪いのか。
2013-10-16 14:00 に開始して、2013-10-17 14:00 現在、415GB 退避。もう1昼夜かかる???

2015-10-13: DISK1 の異常

「RAIDの構成異常が発生しました。」が飛んできた。
DISK1 が死んだようなのだが、
「情報表示」→「ボリューム情報」で構成ディスクの項目の表示が以下のようにおかしいのも気になる。
内蔵ディスク1故障 Hitachi HDS721010CLA332 1000 GB
内蔵ディスク2接続済 Hitachi HDS721010CLA332 GB
内蔵ディスク3接続済 GB
内蔵ディスク4接続済 GB
「ログ情報」は以下の状況
2015/10/1316:22:49イベント通知: ディスクエラー警告メールを送信しました。
2015/10/1316:22:45RAID: RAIDの構成異常が発生しました。(2310-8113)
2015/10/1316:22:39イベント通知: ディスクエラー警告メールを送信しました。
2015/10/1316:22:37ディスク: 内蔵ディスク1が故障しました。交換してください。(...
2015/10/1316:19:44ディスク: 内蔵ディスク1は故障しています。(2110-107)
とりあえず HDD の入手待ち

警告音は、「お知らせ」で「お知らせをクリアする」すると消える。

Tips

rsync

Ubuntu 10.04 LTS から gvfs で mount した HDL-XR へ rsync を用いてファイルを転送する際 -a オプションで転送すると以下のようなエラーが出て転送に失敗する。
rsync: failed to set permissions on "...": Operation not supported (95)
rsync: mkstemp "..." failed: Operation not supported (95)
-a オプションは -rlptgoD オプションに等しいが、上記の状況では -p オプションによる permission の維持に失敗している。
同様に -l オプションによる symbolic link の維持、-o による owner の維持、-g オプションによる group の維持、-D オプションによる device file, special file の維持も機能しない模様。
-r オプションのディレクトリの再起的走査、-t オプションのタイムスタンプの維持は機能するので、-a オプションの代わりに -rt オプションを用いるのが良いようだ。

コメントをかく


「http://」を含む投稿は禁止されています。

利用規約をご確認のうえご記入下さい

Wiki内検索

フリーエリア

管理人/副管理人のみ編集できます