こんにちは、辻村です。今回はお仕事の中で見つけた珍しいエラーについてお話しします。自分自身の備忘録でもあります。

はじめに

今回は、私が出会っためずらしい SCSI のエラーをご紹介します。まず、 iSCSI とはなにかを簡単におさらいし、その後、エンタープライズストレージ特有の機能を2つご紹介します。そして、私の出会ったSCSIエラーについて説明します。最後に、なぜそんなエラーが発生するのかについてご説明します。修正方法については思うところはありますが、大人の事情があるので書かずにおきます。

iSCSIとは

SCSI（スカジーと発音する）はコンピュータ本体とストレージをつなぐ割と古い技術です。電気を送るためには、プラスとマイナスが必要ですが、同時いくつもの信号を送るために、現在の技術からすると、随分とケーブルも太い感じがします。時代がすすんで順番に（シリアルに）信号を送るようになったのでいつの頃からかこの古い方のSCSIは区別のためにパラレルSCSIと呼ばれるようになりました。パラレルSCSIで検索してみると、例えば、ITMediaさんにケーブルの写真があります。

では、シリアルに信号を送る SCSI の規格はなんでしょうか?名前に Serial と入っているのは、SASの略称で呼ばれている Serial Attached SCSIです。確かに、これもシリアルなSCSIの例です。しかしながら、先に実用化された「シリアルな」SCSIは Fibre Channel（ファイバーチャネル）でした。よく、FCと略して呼ばれています。

ファイバーチャネルは、スピードも速くエラーも少なくて、パラレルSCSIで悩まされていた電気信号を送るための様々な問題や制限を解消してくれました。しかし、専用のカードや機材、ケーブルが必要なため、決して安くはありませんでした。また、ネットワークを管理するのと似ているところが多い一方で、異なるところも多く、ネットワークとストレージの管理者を別々に置く必要がありました。

こういった事情で、「ストレージとIPのネットワークを一緒にできないか?」という試みは数多くあります。IP上にFCを流そうとした FC over IP や IPをFC上に流そうとした IP over FCなどという技術もあります。iSCSIは従来のイーサネット上の IP にSCSIを直接乗せることができないかと言うことで実現された技術です。IPなので、ネットワーク管理者が喜ぶかどうかは別として、経路さえあれば、たとえ地球の裏側でもつなぐことができます。

ストレージの集約とLUマスキング

パラレルSCSIからFCに変わった頃に起こったもう一つの変化として、エンタープライズ向けのストレージでは、ストレージを一カ所に集めておくことができるようになりました。様々な要因がありますが主に以下の3つです。

・接続コネクタが小さくなった。
・光通信になったため、ケーブルの距離を稼げるようになった。
・ストレージコントローラが多数のリクエストをさばけるようになった。

集約はできるようになりましたが、どのサーバーがストレージのどの部分にアクセスしていいかという問題が出てきました。FCのRAID装置は、SANであり、OSには LU（論理ユニット）の形でデバイスを見せています。アクセス制御ができずに、他のノードにあるOSから同じ LUにゴリゴリ書かれては困るわけです。

これを解決するには LUのアクセスを制御する必要があります。LUのアクセス制御の仕組みを LUマスキングと言います。LUマスキング機能がある RAID装置は、アクセスできないイニシエーターからのリクエストには、エラーを返します。

ストレージパスの冗長化

重要なシステムは様々なところで冗長化されます。ストレージも同じです。エンタープライズ向けのストレージでは、データ保護のために冗長化するだけでなく、ストレージにデータを書き込んだり、読み出したりする経路自身を冗長化することができます。データが流れるそれぞれの経路をデータパス(data path)といいます。また、どの様にパスを使うかをコントロールすることをパス制御と言います。

どのパスからSCSIコマンドを流すかと言うことは、各ノードの OS上にあるパス制御ソフトが制御しています。

ここまでの例は FC で説明しましたが、iSCSIでも同様な話は成り立ちます。

SCSIでエラーが見つかるまで

SCSIの世界ではデータを依頼する方をイニシエーター(initiator)と言います。これは物事を始める （initiate）という言葉が由来です。逆に依頼を受ける方をターゲット（target）と言います。

通常はイニシエーターがコマンドとして要求を送り、ターゲットがそれに対して返事となるデータを返すという形で物事がすすみます。しかしながら、イニシエーターに何とかしてもらいたい例外がでたときに、ターゲットは、CHECK CONDITIONというメッセージを返します。「ターゲットの状態を確かめてください」と言う意味です。

イニシエーターは、Request Sense（センス情報をください）とコマンドを流し、ターゲットから、3つの情報をもらいます。

・Sense Key
・Additional Sense Code (ASC)
・Additional Sense Code Qualifier (ASCQ)

この組み合わせで問題のコマンドに対してのエラーが伝えられます。

私の出会ったエラー

私の出会ったエラーは、以下の通りです。

・イニシエーターが LU 0に対し Test Unit Ready を流す。
・ターゲットが Sense Key = 0x5, ASC/ASCQ = 0x2500 を返す。

Test Unit Ready (TUR)はSCSIではデバイスや LU の死活監視によく使われるコマンドで、何もなければターゲットは Good を返すことが期待されています。

Sense Key = 0x5 は Illegal Request です。つまり、送ってこられたコマンドは、有効なコマンドでないことを示します。0x25 0x00 (Logical Unit Not Supported) は指定された LU番号がサポートされていないことを示します。

RAIDの定義を見てみると、TURに指定されている LU 0は存在します。LUが存在するのに Illegal Requestとはどういうわけでしょう?

どうしてこんなことになったのか?

どうしてこんなことになったのでしょうか?RAIDの動きがおかしいのでしょうか?

ちょっと思い出してみてください。LUマスキングという仕組みがあります。これによって、LUはアクセスが制御されているのでした。アクセスが禁止されているイニシエーターに対しては何を返すでしょうか?

Sense key/ASC/ASCQ = 0x5/0x25/0x00です。

また、アクセス禁止以外にも、現在有効でないパスに対しても同様の振る舞いをします。（例えばストレージ内部の処理で、他のパスにLUが接続されていて、該当のパスには接続されていないような状態がこれに当たります。）私の出会ったケースでは、有効でないパスからのアクセスであるだけではなく、さらにイニシエーターがLUマスキングに登録されていなかったのでした。

おまけ：イニシエーターはずっと再試行中

イニシエーターはずっと再試行中です。イニシエーター側のドライバーは0x5/0x25/0x00はずっと再試行していれば何とかなると思っているようです。上位層のアプリもずっと待ち続けているので、永遠に終わらないことでしょう。

今回は、珍しい SCSIのエラーについてご紹介しました。そして、設定は大事ですが、エラーの処理も大事だよねというお話でした。

最後まで読んでいただいてありがとうございました！