ターミナルエミュレータを使って QNAP の状態を確認する

先日の QNAP の不具合でわかったことですが、QNAP 本体にトラブルが発生すると、Web ブラウザによる管理ツールで使えない部分が出てくることがあります。

たとえば、RAID 構成を表示させるページや、ISCSI の構成を表示させるページ等は読み込み中のまま、まともに動かなくなってしまったりします。

そういった場合に、エラーの発生したディスクカートリッジを交換したり修理に出したりする前に、直接 QNAP の OS にアクセスして状態の確認やログ参照を行うことにより、原因を特定しやすくなるかもしれません。

ここでは、PuTTY というターミナルエミュレータを使うことによって、QNAP にログインし、基本的なステータス確認コマンドを走らせる方法について説明します。

1. PuTTY のダウンロード

以下のページにアクセスし、適切なバージョンの PuTTY をダウンロードします。

PuTTY Download Page

PuTTY は実行ファイル単体で動作しますので、Windows ユーザの方は putty.exe をダウンロードすればまず問題ないでしょう。

2. PuTTY の起動

putty.exe を起動すると、PuTTY Configuration という画面が表示されます。

上図の青囲みのように Host Name に QNAP の IP アドレス、ポートに 22 (SSH) を指定してから、“Open”ボタンをクリックします。

3. QNAP へのログイン

接続に成功すると、以下のようなPuTTY のターミナル画面が開きます。

 ログインを求められますので、admin を指定し、正しいパスワードを入力して Enter キーを押します。

4. mdstat でメディアの状態をチェック

以下のコマンド入力して Enter キーを押すと、現在のメディアの状態を確認できます。

cat /proc/mdstat 

上記の黄色囲みに注目してください。

UUU_ と文字が並んでいますが、4 文字目がアンダースコア _ になってしまっています。

これは、4 番目のメディアに何らかの障害が発生しているため、mdstat では読み取り不能であることを示しています。

つまり、QNAP の 4 番目のディスクカートリッジに障害が起こっていることがこれでわかります。

6. klogd.sh dump でさらに状態を詳しくチェック

以下のコマンド入力して Enter キーを押すと、カーネルログデーモンで発生しているイベントのログを照会できます。

/etc/init.d/klogd.sh dump 

しかし、これではすべてのログが表示されてしまいますので、後尾に grep を付けてキーワードの絞り込みをすると場所の特定が容易になるでしょう。

たとえば、入出力のエラーを確認したいときは以下のように入力します。

/etc/init.d/klogd.sh dump | grep "I/O error"

I/O error ログのみが抽出されます。

上記の黄色囲みの部分を確認すると、sdd デバイスに入出力エラーが発生していることがわかりますね。

【補足】

メディア名をコマンドでチェックするには、以下のコマンドを入力します。

ls /dev/sdd*

sdd、sdd1、sdd2、sdd3、sdd4 とメディア名が定義されており、最初から順に QNAP のカートリッジと対応しています。上記 4. の mdstat で説明したとおり、今回は4 番目のデバイス sdd3 (QNAP 本体では物理的に 4 番目のカートリッジ)に障害が起こっています。

また、sdd4 は物理的には存在していないデバイスとして定義されているようですが、この部分は当方は未確認です。

その他、QNAP の不具合に関して具体的なサポートを受けたい方は、以下にお問い合わせください。

QNAP HELP DESK　（問い合わせは英語）

http://helpdesk.qnap.com

関連記事：
QNAPで恐怖のエラーがぁぁぁぁああああ

QNAPで恐怖のエラーがぁぁぁぁああああ

知人のQNAPはiSCSIを構成しており、Hyper-Vの仮想マシンと物理マシンがそのiSCSIボリュームを使用している。　ある朝突然、それらのiSCSIボリュームにアクセスできなくなったと言う。「Hyper-Vマネージャー」を起動してみてみると、「仮想マシン」の一覧に表示されるマシンのいくつかに「一時停止 - 重大」と表示されている。　これらのマシンはみなiSCSIボリュームを使用しているものだ。
ブラウザでQNAPのシステムログを見ようとしても「Loading data. Please wait...」と出てくきて、先へ進めない。　仕方がないのでブラウザからQNAPを再起動しようと試みるもいつまでたってもシャットダウンしない。　またまた仕方がないので、QNAP本体の“POWER”ボタンを長押しして無理やり電源を落とす。次に再度“POWER”ボタンを押して起動を試みるも、

「SYSTEM BOOTING」

が本体ディスプレーに表示されたまま、10分ほど経っても起動してこない。「qnap system booting」や「qnap system booting forever」でググってみると、「ハードの故障だ」とか「PSU（Power Supply Unit）だ」とか面倒そうなことが一杯書いてあり、気分が悪くなってくる。　さらに仕方がないので、“POWER”ボタンを2回押して再起動。やはり、「SYSTEM BOOTING」が出てきて、起動してきそうもない。　上記の記事を丹念に読み始める。　どうみても簡単に直りそうもない、と絶望的な気分に陥りそうになったところで、チラっと本体のディスプレーを見ると、なんと！「SYSTEM STARTING...」（だっけな？）みたいなのが表示されており、狂喜する。　しばらくすると、ディスプレーからメッセージが消え、PINGも返るようになる、ブラウザからもアクセスでき、最後にiSCSIボリュームも復活して、Hyper-VのクライアントOSからもそれらを利用できるようになった。

それでログを見てみると、「[RAID6 Disk Volume: Drive 1 2 3 4] The file system is not clean. It is suggested that you run "check disk".」と表示されている。さらに「RAID MANAGEMENT」をクリックしてみると、「Synchronizing (0%)」と表示されている。　ところがこのSynchronizingが遅々として進まず。15時間が経過した午前2時過ぎに97%と表示され、この時点でiSCSIボリュームが再度使用不能になっていることに気づく。　この期に及んで、いくら待ってもSynchronizingは成功しそうにないことにやっと気づくが、とりあえず、朝までSynchronizeを走らせることにして就寝。　翌朝見てみるとやはりSynchronizingは97％のままで終わっていない。　24時間が経過しようとしてもまだ終わらない。


諦め気分でふとQNAP本体を見ると、4つの目のHDDのLEDが緑点滅から赤点灯に変わっている。
「RAID Management」の 「Current Disk Volume Configuration」 は、"RAID 6 Disk Volume: Drive 1 2 3"を示し、第4ドライブが表示されていない。24時間かかって、「やっぱりハードディスクか」とかなり確信を持つ。 念のため、今回の現象をQNAPのサポートにメールしてみると、「問題のハードディスクを取り外して、もう一度入れてみろ」というので、その通りにする。すると、本体のSTATUSが赤く点滅し、第4ドライブのLEDは緑に点灯。　以下のようなログが表示された。

	2012-07-10	16:13:11	System	127.0.0.1	localhost	[RAID6 Disk Volume: Drive 1 2 3 4] RAID device in degraded mode.
	2012-07-10	16:13:09	System	127.0.0.1	localhost	[RAID6 Disk Volume: Drive 1 2 3 4] Drive 4 removed.
	2012-07-10	16:12:59	System	127.0.0.1	localhost	Drive 4 plugged out.

Drive 1 2 3 のSynchronizing　が無事終了するまでにさらに10時間程が経過。以下のような状態になった。

Current Disk Volume Configuration : Physical Disks

Disk	Model	Capacity	Status	Bad Blocks Scan	SMART Information
Drive 1	Hitachi HDS722020ALA330 JKAO	1863.02 GB	Ready	SCAN NOW	GOOD
Drive 2	Hitachi HDS722020ALA330 JKAO	1863.02 GB	Ready	SCAN NOW	GOOD
Drive 3	Hitachi HDS722020ALA330 JKAO	1863.02 GB	Ready	SCAN NOW	GOOD
Drive 4	Hitachi HDS722020ALA330 JKAO	1863.02 GB	Disk Read/Write Error	SCAN NOW	GOOD

Note that if you are going to install a hard drive (new or used) which has never been installed on the NAS before, the hard drive will be formatted and partitioned automatically and all the disk data will be cleared.

Current Disk Volume Configuration : Logical Volumes

Disk/ Volume	File System	Total Size	Free Size	Status
RAID 6 Disk Volume: Drive 1 2 3	EXT4	3664.62 GB	3023.18 GB	In degraded mode
FORMAT NOWCHECK NOWREMOVE NOW

かくしてディスク交換の止む無きに至り、Amazonから Segate ST2000VX000 を注文、待つこと2日でブツが到着。　いそいそとDirve 4を抜く。

Drive4を抜いた状態

調達した新ドライブをいれると、Rebuildが始まった。

15時間後、Rebuild無事終了。


【メモ】

1. ディスクが中途半端に壊れると、その壊れかかったディスクを使用して、Synchronizeを行おうとする。　このSynchronizeはQNAPが完全にそのディスクが壊れていると認識できるまで、続行する。　問題は、この Synchronizeの過程で、iSCSIほかのサービスが異常中断し、ブラウザのQNAP管理画面からも、アクセスできない機能があること。
2. 今回は原因特定に時間がかかり過ぎた。次回、HDDの障害が疑われる場合（の一案）→　cat /proc/mdstat　を実行して障害HDDを特定→QNAPの電源を落とし障害HDDを抜き再起動→Synchronizingが実行される（十数時間）→新HDDを入れてRebuildする。
3. SSHによるRAID状態チェック→こちら
4. QNAPが完全にそのディスクが壊れていると認識した時点でSynchronizeは中断し、当該HDDのLEDには赤が点灯とする。このディスクが少ない状態（今回は4→3に減った状態）で、再度Synchronizeが実行される。
5. HDD交換時は→ QNAP互換HDDリスト
6. コンパクトで省エネ、比較的お手軽に導入できるQNAPのiSCSI。　が、一旦障害が発生すると復旧はかなり面倒になることも。　ググると、障害対応で苦労しているユーザが一杯いる。ただ、ここ（本社）のサポートはかなり秀逸だったりする。　 Danny、謝謝。　

土屋

MySQL Workbench の EER モデリングツールでリレーションシップ検証 3 （リレーションシップアイコンの種類と使い方）

前回、前々回の記事で、外部キーの設定と制約の定義方法について説明してきましたが、今回は EER モデリングツールのリレーションシップアイコンの種類と使い方について説明します。

EER モデリングでリレーションシップの設定を行う場合は、画面の左下に並ぶ 6 種類のアイコンを使います。

 既存のテーブル列を使ってリレーションシップを設定する

大抵の場合は、先に基本的なテーブルを予め定義しておき、後でリレーションシップを設定する作業手順となるでしょう。そのような場合は、上記赤囲みの一番下のアイコンを使用します。

このアイコンを使って作成されたリレーションは、たとえば次のようになります。

青囲みの列に注目してください。ブランドテーブルの [ブランドID]、および取扱商品テーブルの [ブランドID] は共に既存の列にが使われています。

 外部キー専用の列を子テーブルに新規追加し、1対1 の非依存型（non identifying）リレーションシップを設定する

子テーブルに外部キー用の列が作成されていない場合に、親テーブルと 1対1 の非依存型のリレーションシップを設定する場合は、一番上のアイコンをクリックします。

非依存型（non identifying）リレーションシップについては、こちらの記事をご覧ください。

このアイコンを使って作成されたリレーションは、たとえば次のようになります。

青囲みの列に注目してください。ブランドテーブルの [ブランドID]はそのままですが、取扱商品テーブルには、 [ブランド_ブランドID] という専用の列が新たに追加されています。

また、ブランドテーブル側、および取扱商品テーブル側の支線は枝分かれしていないため、このリレーションシップが 1対1 の関係となっていることがわかります。

非依存型リレーションシップの場合、コネクタは破線で表現されます。

 外部キー専用の列を子テーブルに新規追加し、1対多の非依存型（non identifying）リレーションシップを設定する

子テーブルに外部キー用の列が作成されていない場合に、親テーブルと 1対多の非依存型リレーションシップを設定する場合は、上から二番目のアイコンをクリックします。

非依存型（non identifying）リレーションシップについては、こちらの記事をご覧ください。

このアイコンを使って作成されたリレーションは、たとえば次のようになります。

青囲みの列に注目してください。ブランドテーブルの [ブランドID]はそのままですが、取扱商品テーブルには、 [ブランド_ブランドID] という専用の列が新たに追加されています。

また、ブランドテーブル側の支線が枝分かれしていないのに対し、取扱商品テーブル側の支線が三つに枝分かれしているため、ブランド 1 に対し、取扱商品が多の関係になっていることがわかります。

非依存型リレーションシップの場合、コネクタは破線で表現されます。

 外部キー専用の列を子テーブルに新規追加し、1対1 の依存型（identifying）リレーションシップを設定する

子テーブルに外部キー用の列が作成されていない場合に、親テーブルと 1対1 の依存型のリレーションシップを設定する場合は、上から三番目のアイコンをクリックします。

依存型（identifying）リレーションシップについては、こちらの記事をご覧ください。

このアイコンを使って作成されたリレーションは、たとえば次のようになります。

青囲みの列に注目してください。ブランドテーブルの [ブランドID]はそのままですが、取扱商品テーブルには、 [ブランド_ブランドID] という専用の列が新たに追加されています。

また、ブランドテーブル側、および取扱商品テーブル側の支線は枝分かれしていないため、このリレーションシップが 1対1 の関係となっていることがわかります。

依存型リレーションシップの場合、コネクタは実線で表現されます。

 外部キー専用の列を子テーブルに新規追加し、1対多の依存型（identifying）リレーションシップを設定する

子テーブルに外部キー用の列が作成されていない場合に、親テーブルと 1対多の依存型リレーションシップを設定する場合は、上から四番目のアイコンをクリックします。

依存型（identifying）リレーションシップについては、こちらの記事をご覧ください。

このアイコンを使って作成されたリレーションは、たとえば次のようになります。

青囲みの列に注目してください。ブランドテーブルの [ブランドID]はそのままですが、取扱商品テーブルには、 [ブランド_ブランドID] という専用の列が新たに追加されています。

また、ブランドテーブル側の支線が枝分かれしていないのに対し、取扱商品テーブル側の支線が三つに枝分かれしているため、ブランド 1 に対し、取扱商品が多の関係になっていることがわかります。

依存型リレーションシップの場合、コネクタは実線で表現されます。

 多対多のリレーションシップを設定する

子テーブルに外部キー用の列が作成されていない場合に、親テーブルと多対多のリレーションシップを設定する場合は、下から二番目のアイコンをクリックします。

このアイコンを使って作成されたリレーションは、たとえば次のようになります。

多対多の場合は、子テーブルの外部キーと親テーブルの主キーを結び付けると、テーブル名_has_テーブル名 という名前のテーブルが新たに作成されます。
このテーブルは、子テーブルに対する外部キーおよび親テーブルに対する外部キーをそれぞれ持っている点に注目してください。

上図の場合では、ブランド_has_取扱商品 というテーブルに、取扱商品テーブルの主キーに対する外部キー、およびブランドテーブルの主キーに対する外部キーが作成されることを示しています。


外部キーを確認すると、以下のようになっています。


○ブランドテーブルに対する外部キー

ブランドテーブルの主キー[ブランドID]に対する外部キーが作成されています。



○取扱商品テーブルに対する外部キー

取扱商品テーブルの主キー[商品ID]に対する外部キーが作成されています。



【関連リンク】
MySQL Workbench 基礎講習コース