情報技術の最近のブログ記事を表示しています。
過去のブログ記事については下部のリンクより参照ください。
Tera Station復活の備忘録、第2弾です。
TS5400のバックアップ用として、TS-XHLシリーズを使っています。
機種的にはこちらの方が古く、扱いづらい点があるのも事実です。
その分、より安く入手できる点がメリットかなと思います。

この機種はUSBブートで復活させたり、VGA出力があるわけではないので、少しだけ難易度があがります。
BUFFALOから提供されているアップデーターを使い、インストールする必要があります。
これについても少しだけコツがいるので、それについて記載したいと思います。

この機種はSMBv2が有効になっていないので、Win10からは使えません。
賢い人が使えるようにする方法を出してくれていますので、是非調べてみましょう。

用意するもの

  • Tera Station TS-XHL本体(この記事はTS-XH2.0TLで試しています。)
  • ハードディスクをスロット数分全て(TS-XH2.0TLの場合は4本)
  • リカバリ用ファームウェア(tsx-v176.exe)
  • TSUpdater.exe(TSX156.zip同梱のもの)
  • 作業用PC
  • LANケーブル

復旧手順

(1)作業用PCにてファームウェアアップデータを準備
まずは作業用PCにリカバリ用ファームウェアを展開します。
その後、展開したリカバリ用ファームウェアに含まれるTSUpdater.exeをTSX156.zipに含まれるものに置き換えます。
復活作業ではディスクのフォーマットが必要になりますが、tsx-v176.exe同梱のものはフォーマットができません。
色々と試した結果、TSX156.zip同梱のTSUpdater.exeはフォーマットオプションが使えるようです。

その後、TSUpdater.iniのFlagsを以下の通りに書き換えます。
[Flags]
VersionCheck = 0
NoFormatting = 0

(2)作業用PCとTera Station本体をLANケーブルで接続
作業用PCとTera Station本体をLANケーブルで接続します。
当たり前のようにAuto MDI-Xが働くので、クロスケーブルとか気にしなくても大丈夫です。
また、IPアドレスもAPIPAを使えばよいので、設定する必要はありません。

(3)TeraStationをEMモードで起動
空のハードディスクをセットして起動した場合、EMモードで起動します。
Nas Navigatorを使えば、EMモードで起動したか確認できます。
ts-xhl_pic1.png

(4)TSUpdater.exeを起動し、Updateを実行
作業用PCでTSUpdater.exeを起動します。
Tera Stationが自動で検索され、アップデート対象があればUpdateができます。
(くれぐれも別のTera Stationに対して実行しないように注意してください...。)

アップデートが始まると、ハードディスクのフォーマットとファームウェアインストールが実行されます。
ts-xhl_pic2.png

アップデートが終わると、インストールされたファームウェアにて起動されます。
と、実は意外と簡単なのです。
私はフォーマットできるTSUpdater.exeを探し出すのに非常に苦労しましたが...。
企業で使われていて、保守切れとなったハードウェアをヤフオクなどで安く買うことができます。
もちろん型落ちですので、性能や機能は最新のものより劣ります。
ただ、ビジネス向けのものですので、よほどのことでなければ家庭では十分だと思います。

他のNASと比べ、Tera Stationは1,000円~で手に入れることができ、流通量が多いのがよい点かなと思っています。
(最悪ハード故障しても、同型機種を手に入れやすいはず。)
また、内部的にはLinuxのソフトウェアRAIDですので、OS領域が破損したとしても、Linuxマシンに接続すればデータは復旧できます。

TS5400をオススメする理由はIntelプロセッサであり、D-Sub端子があってディスプレイ出力ができ、SMBv2が使える点です。
古い機種だとSMBv1だけしか使えない状態となっており、少しカスタマイズしないと、Win10から使えません。

中古として販売されるときにはセキュリティの関係もあり、ハードディスクは取り外されていることが多いです。
したがって、OSをインストールして復活させる必要があります。

用意するもの

  • Tera Station TS5400本体
  • ハードディスクを少なくとも1本
  • 2GB以上のUSBメモリ
  • リカバリ用ファームウェア(TS5k_recovery_260.zip)

復旧手順

(1)リカバリ用USBの作成
リカバリ用ファームウェア(TS5k_recovery_260.zip)を入手し、解凍します。
同梱されているDDWin.exeを使い、USBメモリにTS5000V2.6bootUSB.ddiを書き込みます。

(2)リカバリ用USBからの起動
本体背面のブートスイッチをUSBに切り替え、USBポートにリカバリ用USBを差し込みます。
その後、本体の電源ボタンを押下します。

(3)リカバリの実施
起動後、「I41 Push Func to Start Recovery」と表示されたら、ファンクションボタンを押下します。
システムが再起動された後に「I38 Recovery Finished」、「I39 Change Boot Switch Back」と表示されます。
USBメモリを取り外し、ブートスイッチをHDDに切り替えて電源ボタンを押下します。

ということでこれだけでリカバリすることができます。
あとはNAS Navigatorで接続すれば、初期設定を行うことができます。
その後、残りのベイにハードディスクを組み込み、アレイを組めば快適NAS生活が開始できます。

このモデルはUSBメモリで簡単にリカバリができるので、個人的にオススメできる機種です。
ふと思い立ち、家の仮想環境用のストレージの性能測定をしてみたが、妙に遅い。
MarvellのSATAコントローラーでHyperDuoを構成したものをFreeNASでミラーを組んでいる構成。
直接サーバで計測するとWRITEは約90MB/secほど。
root@sto01[/mnt/pool0]# dd if=/dev/random of=test bs=1M count=500
500+0 records in
500+0 records out
524288000 bytes transferred in 5.689354 secs (92152470 bytes/sec)

一方READはキャッシュから読まれているのか早い。
ディスクの性能測定にはならないが、iSCSIで接続した場合にはNICの性能がネックになるだろう。
root@sto01[/mnt/pool0]# dd if=test of=/dev/null bs=1M count=500
500+0 records in
500+0 records out
524288000 bytes transferred in 0.418108 secs (1253954697 bytes/sec)

ではiSCSIで接続したESXi上から実行してみると、妙に遅く、WRITEで約17MB/secほど。
[root@esx01:/vmfs/volumes/634f9750-3747bd9a-1559-0010181b5821] time dd if=/dev/zero of=test bs=1M count=500
500+0 records in
500+0 records out
real    0m 29.43s
user    0m 0.42s
sys     0m 0.00s

READの方は比較的マシで約48MB/secほどのスピードが出ている。
[root@esx01:/vmfs/volumes/634f9750-3747bd9a-1559-0010181b5821] time dd if=test of=/dev/null bs=1M count=500
500+0 records in
500+0 records out
real    0m 10.35s
user    0m 1.83s
sys     0m 0.00s

流石に遅すぎるということで、sysctlパラメータを弄ってみた。
dev.vge.%d.int_holdoffを1100(デフォルト150)
dev.vge.%d.rx_coal_pktを16(デフォルト64)
dev.vge.%d.tx_coal_pktを32(デフォルト128)

そしたら、WRITEは約34MB/secほどで少しマシになった。
[root@esx01:/vmfs/volumes/634f9750-3747bd9a-1559-0010181b5821] time dd if=/dev/zero of=test bs=1M count=500
500+0 records in
500+0 records out
real    0m 14.56s
user    0m 0.42s
sys     0m 0.00s

一方、READは約43MB/secで若干遅くなったが、バランス的にはこれぐらいか。
[root@esx01:/vmfs/volumes/634f9750-3747bd9a-1559-0010181b5821] time dd if=test of=/dev/null bs=1M count=500
500+0 records in
500+0 records out
real    0m 11.63s
user    0m 2.00s
sys     0m 0.00s

ついでに仮想マシン(今となっては古くて塩漬けなWindows Home Server)上でCrystal Disk Markを実行してみた。
チューニング前は以下のような感じ。
freenas-block-sync_standard.PNG

チューニング後はシーケンシャルWRITEはよくなったが、割り込み減速の影響かランダム性能が悪くなった。
tuned_freenas-block-sync_standard.PNG

バランス的には後者かなと思いつつ、安物チップの限界を感じる結果となった。

ちなみに、BroadcomのNICだとWRITEが約80MB/sec、READが約75MB/secと結構な差となった。
[root@esx01:/vmfs/volumes/634f9750-3747bd9a-1559-0010181b5821] time dd if=/dev/zero of=test bs=1M count=500
500+0 records in
500+0 records out
real    0m 6.23s
user    0m 0.41s
sys     0m 0.00s

[root@esx01:/vmfs/volumes/634f9750-3747bd9a-1559-0010181b5821] time dd if=test of=/dev/null bs=1M count=500
500+0 records in
500+0 records out
real    0m 6.67s
user    0m 0.91s
sys     0m 0.00s

2.5GbEも流行ってきているので換装の機運は高まっているが、内部性能的にはGbEで十分そうだ。
と思ったが、900Mbpsぐらいでていそうなので、2.5GbEとかにするのも面白そう。
broadcom_freenas-block-sync_standard.PNG

GbEのカードでも性能差が結構あるので、2.5GbEとかを導入するにしてもまともなチップを選んだ方がよさそうだ。

情報技術の過去のブログ記事