中古NAS本体に新品HDDで再構築する
今更ながら中古でIO DATA LANDISKを購入したことについて
中古（ジャンク）のRAIDなNASをヤフオクで購入し、新品HDDをバルクで購入して構成に成功したことを先日記しました。
私が購入したのは「HDL-GTR2.0」という型番の2TB（500GB✕4本）モデルですが、ハードディスクが無い状態のジャンクでした。但し欠品はハードディスクで肝心要の「システム（OS）領域」もありません。
新品のハードディスクを購入することにしましたが、1TB✕4本で行くことにしました。2TB✕4本にチャレンジしようかとも思ったのですが、このモデルの発売時のラインナップからすると4TB（HDL-GTR4.0）が最上位だったと見受けられるので、これが上限かも知れないと安全策を取りました。
システムの種は同じ機種を持っている知人からCOPYさせて貰いました。新しく買った1TBのハードディスクを仲間に加えてもらって種をもらいます。別に難しいことはしていません。RAID再構築は時間だけが解決してくれます。
カスタマイズが必要なのか？
問題は容量が違う環境の種（知人の環境は1TBだった）をもらった場合、ハードディスクの一部分しか使わないので空いた容量の部分が無駄になると言う話がリサーチ段階で分かっていました。
ネットでこの辺りのことについて検索したところ、Linux等にマウントしてパッチを当てるとかしなきゃならない感じだったのですが、結果的にはファームウェアを現行の新しいもの（Ver1.37）にしているせいか、システムファイルをカスタマイズしたりする必要はありませんでした。ディスクカートリッジを適切に差し替えて管理画面から操作するだけです。
手順の概要を簡単にメモしておく
RAID崩壊モードで起動（IPアドレスが192.168.0.200）して、メンテナンスを実行して種システムの入ったハードディスクから残りの3本にシステムをコピーさせます。知人の環境はRAID0+1になっていたのでその状態にウチの環境も構成された感じです。
ただ、約12時間に渡る再構築の後（一晩中再構築が動いていた）、DISK#1～#4のLEDが揃って青く点滅して全く先に進まなくなりました。丸一日放置したのですが変化が無いので、電源スイッチを長押ししたり、リセットボタン（裏にある）を棒で押したりしたのですが変化がありません。
シャットダウン出来ないので強制的に電源を切るしかなくなりました。マジカルファインダーで検索してもPCから見つけられないし、192.168.0.200でも応答が無いのでどうしようもありません。やりたくは無いですが強制的にコンセントを抜きました。
しばらくしてから電源を入れると、青いLEDが非同期な感じで点滅してシステムを読み込んでいる感じです。そして最後に「ピーピーピー」と3回ブザーが鳴ってディスクのLEDは赤く点灯したまま止まりました。PCからマジカルファインダーで検索したら見つかりブラウザで管理画面を表示出来ました。
RAIDが崩壊しているうんぬんと書かれていましたが、管理画面が表示される様になったのでここでボリュームの操作を行うことにしました。元々知人宅で動いていたRAID0+1の構成だったのを、まずはRAID0にして1TB✕4をフルに認識させてみようと思いました。結果的にこれは正解だったらしく、4TBのストライピングに成功しました。（これは10分位で終わりました）
いよいよRAID5
次に、私が使おうと思っているRAID5に変更します。「sambaの共有情報が消えます」みたいな警告が表示されましたが、私はまだ何も設定してないので消えても問題ありません。知人が使っている環境の痕跡が残っているのでしょう。気にせず進めると60分位でRAID5に変更できました。
RAID0+1（->）RAID0（->）RAID5
ログを見てみると、やはりRAID崩壊で起動し、DHCPでIPアドレスを取得し、Web管理画面にログイン出来る様になってからRAID0に変更できています。その後にRAID5への変更を行ったので設定内容に変更を生じているらしく、最終的にRAID5で動作する様になりました。
かかった時間は、システムの種を手に入れてから、
- RAID崩壊モードより復元RAID0+1（12時間）
- 青LED点滅様子見（8時間）
- 初期化（オールゼロ消去）（5時間位？）
- RAID0へ変更（10分）
- RAID崩壊モードより復元RAID0（10分）
- RAID崩壊モードより復元RAID0（10分）
- RAID5へ変更（24時間）
程度かかりました。
RAID崩壊モードからの復元を2回やっているのは、元々1TB(250GB✕4本)なので一度ではハードディスク容量をフルに認識してくれなかった為です。ハッキリ記録していないのですが、1.7TB、3.4TB、4.0TBという感じでRAID0の容量が増えていく仕組みでした。
青LED点滅についての様子見（8時間）は結果的に無意味だったので、手順さえわかって段取り良く進めれば2日あればRAID5の構築待ちまで出来そうです。RAID5化は4TBの場合24時間以上とやたら時間がかかる様です。システムだけでデータは空のディスクなのに構築で丸々24時間以上かかるのは全ての領域をくまなくRAID5に変換しているということでしょう。
この動作から想像すると、RAID5で使用していてディスクが1本故障した場合、その故障したものを良品と入れ替えて再構築になったら丸一日動きっぱなしになるということが分かります。RAID5という冗長性をもたせた方式でも、ハードディスクは立て続けに壊れるというリスクがある訳です。RAID5は2本目のHDDが立て続けに壊れるとデータを失います。やっぱりRAID5は危うい冗長化方式ですね・・
ログをコピペして置きます。上に記した（6-7）の手順のところです。
| 12月15日 00:33:05 | ログ記録 | 開始 |
| 12月15日 00:33:07 | 共有サービス設定 | 設定変更 |
| 12月15日 00:33:07 | 共有サービス設定 | 設定変更 |
| 12月15日 00:33:07 | デバイス管理 | RAID崩壊モードへ移行． |
| 12月15日 00:33:14 | DHCPクライアント | DHCP失敗: AutoIPアドレス: 169.254.247.3 |
| 12月15日 00:33:14 | ディスク | 致命的エラー: 内蔵ハードディスクをマウントできません． |
| 12月15日 00:34:26 | WEB設定画面 | 管理者ログイン成功 : (169.254.12.182) |
| 12月15日 00:35:20 | デバイス管理 | sata2: 開始 |
| 12月15日 00:35:55 | デバイス管理 | sata2: 開始処理正常終了 |
| 12月15日 00:35:56 | デバイス管理 | sata4: 開始 |
| 12月15日 00:36:29 | デバイス管理 | sata4: 開始処理正常終了 |
| 12月15日 00:36:31 | デバイス管理 | sata3: 開始 |
| 12月15日 00:37:03 | デバイス管理 | sata3: 開始処理正常終了 |
| 12月15日 00:39:13 | 共有設定 | disk1: 共有削除 |
| 12月15日 00:39:15 | 共有サービス設定 | 設定変更 |
| 12月15日 00:40:15 | 共有設定 | disk1: 共有追加 |
| 12月15日 00:40:15 | 共有設定 | disk1: 所有者変更 |
| 12月15日 00:40:15 | 共有設定 | disk1: netatalk の属性変更 |
| 12月15日 00:40:15 | 共有設定 | disk1: comment の属性変更 |
| 12月15日 00:40:16 | 共有設定 | disk1: 所有者変更 |
| 12月15日 00:40:16 | 共有設定 | disk1: samba の属性変更 |
| 12月15日 00:40:18 | 共有サービス設定 | 設定変更 |
| 12月15日 00:40:26 | 共有サービス設定 | 設定変更 |
| 12月15日 00:40:29 | RAID監視 | 監視プログラム開始 |
| 12月15日 00:40:50 | デバイス管理 | RAID構成変更完了: => raid0 |
| 12月15日 00:45:16 | 共有設定 | disk1: 共有削除 |
| 12月15日 00:45:18 | 共有サービス設定 | 設定変更 |
| 12月15日 00:45:34 | 共有サービス設定 | 設定変更 |
| 12月15日 00:45:34 | RAID監視 | 監視プログラム停止 |
| 12月15日 00:46:11 | 共有設定 | disk1: 共有追加 |
| 12月15日 00:46:11 | 共有設定 | disk1: 所有者変更 |
| 12月15日 00:46:11 | 共有設定 | disk1: netatalk の属性変更 |
| 12月15日 00:46:12 | 共有設定 | disk1: comment の属性変更 |
| 12月15日 00:46:12 | 共有設定 | disk1: 所有者変更 |
| 12月15日 00:46:12 | 共有設定 | disk1: samba の属性変更 |
| 12月15日 00:46:15 | 共有サービス設定 | 設定変更 |
| 12月15日 00:46:23 | 共有サービス設定 | 設定変更 |
| 12月15日 00:46:26 | RAID監視 | 監視プログラム開始 |
| 12月15日 00:46:45 | デバイス管理 | RAID構成変更完了: => raid5 |
| 12月15日 05:32:09 | RAID監視 | /dev/md10: 再構築 20 % 完了 |
| 12月15日 10:16:35 | RAID監視 | /dev/md10: 再構築 40 % 完了 |
| 12月15日 14:59:41 | RAID監視 | /dev/md10: 再構築 60 % 完了 |
| 12月15日 19:45:47 | RAID監視 | /dev/md10: 再構築 80 % 完了 |
| 12月16日 00:32:22 | RAID監視 | /dev/md10: 再構築終了 |
| 12月16日 00:56:19 | ログ記録 | 終了 |
管理画面のレスポンスが異常に遅い
ただ、全般的にこの機種もそうですし、HDL-XVとかHDL-XRとか、I-O DATAのLandiskシリーズは管理画面の動きが非常に遅いです。操作に対してのレスポンスが緩慢で業務用にはとても使えない代物です。アクセスしている人数が多い環境では苦行になると思います。この製品は明らかにコンシューマ向け、もしくは少人数（5人以内）の小さなグループ向けと言えそうです。
更に致命的なのは設定を変更して反映させると、そのタイミングでファイル共有が瞬断する症状が多発します。ネットで調べたところこの製品はこういう仕様らしく、瞬断するのは仕方がないというメーカーの見解が返ってくるというレベルの様です。
あくまでも家庭用、もしくはSOHOレベル（数人）でファイル共有する用途にとどめるべきでしょうね。とてもじゃないですが業務用のWindows ServerやLinuxサーバーとは比較出来ないレベルのファイル共有です。
個人用の大切なデータを保護する意味ではRAID5も有効ですし、数名で時々使用するレベルであれば瞬断も許容出来る範囲でしょうから用途しだいだと思います。道具は適材適所で割り切って使うことも必要ですね。資金が有り余っているなんて人はそうそう居ないと思うのでコストは無視出来ませんし。
LANケーブル（クロスケーブル）でPCと直接続
私の使っている環境では、今のところデスクトップPC 1台だけでこのNASを使えれば事足りるので、LANケーブルのピンアサインをクロスにしてクロスケーブルを作りました。これでスイッチングハブも使わずに直で接続できます。
デスクトップPC側は、自宅のネット環境の都合上、Wi-Fiアダプターを使った無線LAN接続にしているので、HDL-GTRはデスクトップPCのイーサネットポートに繋げば、自動的にIPアドレスを設定してくれて169.256.x.xという感じのアドレスでPC側もHDL-GTR側も設定されます。リンクローカルアドレスとか呼ばれる範囲で、APIPA（Automatic Private IP Addressing）という機能によって実現される仕組みです。単にクロスケーブルで接続するだけでネットワーク設定は意識する必要も無いので手軽です。
せっかくなので、HDL-GTR側とPC側で「ジャンボフレーム」を有効にして使います。たまに動画ファイルを転送したりするので、なるだけ速い方が良いですし、他のネットワーク機器を接続しないので気にする必要もありません。クロスケーブルで直接続の手軽さです。
追記（ジャンボフレームの弊害）
トラブルに遭遇したので追記しておきます。
その後、ずいぶん期間が経過しましたが、家庭内でファイル共有するために、HDL-GTRを使いたいというニーズが出てきたので、デスクトップPCとHDL-GTRを直接クロスケーブルで接続する方法はやめました。HDL-GTRはWi-FiルーターのLANポートに接続することにしました。
ここで問題が発生しました。I-O DATAが配布している設定補助アプリ「MagicalFinder」を使ってネットワーク内を検索すると、HDL-GTRは正常に見つかっており、IPアドレスも期待通りにDHCPから192.168.0.Xという感じで割り当てられています。
しかし、PCのWebブラウザからhttp://192.168.0.X/という感じでアクセスしても、HDL-GTRの設定画面が表示されません。Webブラウザの読み込みアイコンがくるくる回っていていつまで待っても何も表示されず真っ白なのです。肝心のファイル共有も出来ません。
PINGコマンドで疎通確認を行ったところ正常です。とりあえず双方向の通信は出来ている様です。
これは困ったぞ・・と途方に暮れそうになりましたが、確実にネットワーク関係の不具合だと思われるので、一旦クロスケーブルで元通りの接続にしてみました。するとキチンと動作していて設定画面にアクセスすることも出来ます。機器の故障ではなさそうです。とりあえずネットワーク設定（久しぶりに見た）を再確認します。
ここでふと思い出しました。クロスケーブルで直接続だから「ジャンボフレーム」を使っておけ、と設定しておいたことを思い出しました。とりあえず特異な設定は止めにして標準的な設定に戻しておくことにしました。デスクトップPC側のLANポートも「ジャンボフレーム」は無効にしました。
これで、再びHDL-GTRをWi-FiルーターのLANポートに接続すると、キチンと動作する様になり無事に家庭内のネットワークでHDL-GTRの共有フォルダにアクセス出来る様になりました。
おそらく、うちで使っているWi-FiルーターのLANポートは「ジャンボフレーム」に対応していないと思われます（設定項目もないし）。ジャンボフレームを使うには、相互の機器と、中間に接続するネットワーク機器もジャンボフレームに対応している必要があります。今回、ジャンボフレームの使用を全て無効にすることで、HDL-GTRの設定画面が真っ白になる症状（障害）を解決出来ました。PINGでの確認にはジャンボフレームは影響しない様ですね。
最後に
RAIDによる冗長性（可用性）の確保は、これだけ大容量データが当たり前になった時代では必須の機能だと思っています。個人でも家族の写真データや、PC等で作成したデータは取り返しが付かないものもあります。
通常の外付けハードディスクや、シングルディスクのNASは手軽ですが、冗長性の確保が出来ていません。最低限定期的なバックアップは欠かせないと実体験で苦い思いをして学習しています。
個人用でも、ハードディスクが2本実装されたRAID1（ミラーリング）タイプか、シングルディスク＋バックアップディスクを備えておきたいものです。データは失ってから取り返そうとしても途方もない手間と時間、時には修復費用が必要になります。
完全に取り返せるならまだそれもありかも知れませんが、いつか必ず壊れる（データを失う）のは間違いないので、必要経費だと割り切ってデータの冗長性は確保して置きたいものです。個人用なら可用性は割り切っても良いかも知れませんね。
コメント