メインコンテンツまでスキップ

NetApp_Insight_2020.png 

読み取り不能セクター管理とは

Views:
14
Visibility:
Public
Votes:
0
Category:
e-series-systems
Specialty:
esg
Last Updated:

に適用されます

NetApp E シリーズ製品

回答

Unreadable Sector Management ( USM )機能は、通常の I/O 処理中に検出された読み取り不能セクターや、再構築などの長時間実行中の処理を処理するためのコントローラベースの方法を提供します。この機能は、ほとんどがエンドユーザに対して透過的に設計されているため、設定可能なオプションは使用できず、機能を無効にすることもできません。USM では、主に次の 5 つの機能が改善されています。

  • メジャーイベントログ( MEL )の読み取り不能セクター(および USM 関連の状態)のレポートが改善されました。
  • 読み取り不能セクターのレポートを継続します。
  • メディアエラーが発生しても、再構築やその他の長時間処理が継続されます。
  • パリティを生成できない場合でも、最適な RAID 5 ボリュームへの書き込みが正常に完了しました。
  • RAID 再構成処理( DVE 、 DCE )によってメディアエラー状態が解消されます。

ネットアップは、 FC-SCSI ディスクと SATA ディスクの両方を 1 つのサブシステムでサポートしているため、この機能は物理ディスクの機能に依存せず、コントローラファームウェアで完全に処理されるように設計されています。ただし、コントローラファームウェアでは、ネイティブにサポートされていないディスクの機能をエミュレートする試みはありません。

この資料では、「読み取り不能セクター」とは、物理ディスクメディア関連の二重障害状態または非冗長ボリューム( RAID 0 )上の物理ディスクメディア関連の単一障害状態が原因で、完全に読み取り不能とみなされるボリューム論理ブロックアドレス( LBA )を意味します。読み取り不能セクターは回復不能であり、その場所に格納されているデータは失われたとみなされ、他の手段でリカバリする必要があります。

読み取り不能セクターデータベースはどのように機能し、どのようにログに記録されますか。

読み取り不能セクターデータベースは安定したストレージに保持され、検出された読み取り不能セクターごとにエントリが含まれます。ボリューム中心の情報を使用して記録されます。次の情報が含まれます。

  • 一意のボリューム識別子( SSID ではない)
  • ボリューム LBA
  • ブロック数

データベースを安定したストレージに保持する利点は、読み取り不能セクターのレポートを永続的に保持できることです。これは、再起動、ボリュームの再構成、ファームウェアのアップグレード(アップグレードが USM をサポートするコードに含まれる場合)、ボリュームの状態の変更、ボリュームの転送が行われた場合にも有効です。

USM データベースを表示するには、次の手順を実行

  • SANtricity ( Array Management ウィンドウ)で、 Monitor >> Reports >> Unreadable Sectors Log を選択します。
  • SANtricity CLI コマンド: show storageArray unreadableSectors
  • SANtricity Array Manager ( SAM )で、 Support >> Support Center >> Diagnostics タブ >> View / Clear Unreadable Sectors を選択します。

データベースに読み取り不能セクターを入力する方法と理由を教えてください。

読み取り処理では、読み取り不能セクターデータベースにエントリを作成できます。これには、ホスト I/O または物理メディアからの読み取りが必要な内部処理が含まれます。冗長構成の場合、データとパリティ(またはミラー)の両方の場所で読み取り不能セクターデータベースへのエントリが生成される可能性があります。ホストの読み取り I/O 中に、物理ディスクからメディアエラーが返された場合、コントローラは最初にデータの再構築を試みます(最適な冗長構成)。そのデータの再構築に失敗すると、読み取り不能セクターデータベースへのエントリが作成され、ハードウェアエラーの検出キー( 0x04 )でホスト I/O が失敗します。

冗長性チェックを使用したメディアスキャン:

スキャン中に、すべてのデータとパリティ情報が読み取られ、比較されます。メディアエラーが発生した場合は、新しいメディアエラーであるか、すでにデータベースに記録されているメディアエラーであるかにかかわらず、次の処理が実行されます。データをその場所で再構築しようとすると、ディスクへのライトバックが行われます。読み取り不能セクターデータベースに書き込み場所のエントリが存在する場合、そのエントリは削除されます。データを再構築できない場合は、関係するすべての読み取り不能セクターのエントリがデータベースに作成されます。

再構築:

読み取りは RAID 5 の再構築中に処理されます。読み取り不能セクターデータベースに既存のエントリがある場合、再構築ドライブ上の対応するセクターが読み取り不能セクターデータベースに追加され、再構築ドライブ上で失われたデータに対して重大な MEL イベントが生成されます。再構築ドライブ上のセクターは、既知のデータパターンで書き込まれます。

RAID 5 の再構築中に新しいメディアエラーがディスクから返された場合は、次の 2 つのシナリオがあります。

データセグメントで読み取りエラーが発生しました

実行されたアクション:読み取り不能セクターデータベースに 2 つの読み取り不能セクターが追加されます。 1 つはデータドライブ上の不良セクター用で、もう 1 つは再構築ドライブ上で再生できなかったデータ用です。両方のセクターでユーザデータが失われると、重要な MEL イベントが生成されます。この処理の結果、読み取り不能セクターエントリがパリティドライブのメモリ内テーブルに追加されます。

パリティセグメントで読み取りエラーが発生しました

実行されたアクション:再構築ドライブで再生成できなかった場所の読み取り不能セクターデータベースに 1 つのエントリが作成されます。損失したユーザデータについて、 1 つの MEL イベントがログに記録されます。パリティドライブ上の場所については、メモリ内のテーブルに追加のエントリが作成されます。

読み取りは RAID 1 の再構築中に処理されます。読み取り不能セクターデータベースに既存のエントリがある場合、再構築ドライブ上の対応するセクターは既知のデータパターンで書き込まれ、 MEL イベントは生成されません。

再構築の進行中にソースディスクから新しいメディアエラーが発生した場合は、障害が発生したセクタがデータベースに追加され、重要な MEL イベントが生成されます。再構築するドライブは、デフォルトのパターンで書き込まれます。

コピーバック処理:コピーバック処理中に、ホットスペアドライブが読み取られ、交換用ドライブにコピーされます。データベース内に既存の読み取り不能セクターが見つかった場合、新しいエントリは作成されず、論理から物理へのマッピングが更新されます。新しい読み取り不能セクターが検出されると、データの再構築が試行されます。データをリカバリできない場合は、ターゲットセクタに新しい読み取り不能セクターエントリが追加され、重要な MEL イベントが生成されます。ターゲットセクターは既知のデータパターンで書き込まれ、コピーバック操作は完了します。

即時可用性フォーマット( <:iaf ):メディアエラーが検出されると、読み取り不能セクターと対応するパリティブロックのエントリーが読み取り不能セクターデータベースに格納されます。メディアエラーのサイトに対して重大な MEL イベントが生成されます。

動的再構成:ボリュームの再構成の実行時に、ボリュームグループ内のドライブ数、 RAID レベル、ストライプサイズが変更されることがあります。この処理中にソースで検出された読み取り不能セクターは、既存のエントリがデータベースに存在しない場合にのみログに記録されます。これらの読み取り不能ブロックは、ターゲット構成内の新しい場所に移行され、論理ブロックの読み取り不能セクターデータベース内の物理的な場所が更新され、 MEL イベントが生成されます。

USM を実装しても、物理メディアエラーがユーザのデータへのアクセスに影響しないことは保証されません。読み取り不能セクター管理は、これらのエラーが存在することをエンドユーザに通知することで、この可能性を軽減するように設計されています。USM をメディアスキャンなどの機能と組み合わせて使用すると、システム管理者は、予防的な対策を講じ、ハードウェアの問題がデータアクセスに影響を与えないようにすることができます。

読み取り不能セクターデータベースにすでに記録されているセクターと交差するホスト読み取りでは、センスキー 0x03 (中程度のエラー)と 0x11/0x00 (回復不能な読み取りエラー)が返されます。

読み取り不能セクターデータベースへの最大エントリ数を 1000 に制限する要因があります。この 1000 エントリの制限は、すべてのボリュームグループ、ボリューム、およびディスクに適用されます。データベースが一杯になると、コントローラの動作は次のようになります。

  • 再構築中に新しい読み取り不能セクターが検出された場合、再構築中のドライブに障害が発生しますが、読み取り不能セクターデータベースへのエントリは作成されません。
  • ホスト I/O 中に新しい読み取り不能セクターが検出された場合、ホスト I/O は失敗し、エントリは作成されません。
  • データベースが一杯になった後に検出されたすべての読み取り不能セクターについて、重要な MEL イベントが生成されます。この場所にアクセスしようとするたびに、データベースにエントリを作成できないため、重要なイベントが生成されます。

読み取り不能セクターデータベースのクリア:

次のいずれかの方法で、読み取り不能セクターデータベースからエントリを削除できます

  • ユーザーの要求:ユーザーは、 SANtricity GUI または SANtricity CLI スクリプトを使用して、指定したボリューム、ボリュームグループ、またはサブシステム全体のデータベースエントリをクリアするように要求できます。このタイプの要求では、指定したレベルの読み取り不能セクターがすべてクリアされ、次のようになります。
    • 対応するセクターに書き込まれる既知のデータパターン。
    • 読み取り不能セクターを含むストライプに対して生成される正しいパリティ。
    • データベースから削除するエントリ。

SANtricity では、読み取り不能セクターのエントリを表示し、 [ Monitor (監視) ] > [ Reports (レポート) ] > [ Unreadable Sector Log (読み取り不能セクターログ) ] の順に選択して [ Clear (クリア) ] オプションを選択できます。または、次の SANtricity CLI スクリプトを使用してエントリをクリアします。

clear allVolumes unreadableSectors;

コントローラ SAM から、 Support >> Support Center >> Diagnostics タブ >> View/Clear Unreadable Sectors を選択 >> エントリを選択 >> Clear をクリックします。

  • 正常な書き込み: USM データベースに入力されたセクタへの書き込みが成功すると、そのエントリも削除されます。読み取り不能な既知のセクターと交差する書き込みが発生すると、その書き込みは書き込みに変換され、セクターが修復されて読み取り可能であることが確認されます。Write and Verify が Good ステータスを返した場合、セクタはデータベースから削除されます。

USM による制約事項:ボリュームグループまたはボリュームのデータベースに読み取り不能セクターが存在する場合、特定の機能が無効になります。

  • RVM (リモートボリュームミラーリング)コントローラファームウェアは、プライマリボリュームに読み取り不能セクターエントリが存在する場合、ミラー関係の作成を拒否します。同期中に読み取り不能なセクタが検出された場合、同期とミラー関係の両方で障害が発生します。
  • Snapshots :コントローラファームウェアは、ボリュームのエントリが USM データベースに存在する場合は、スナップショットの作成を拒否します。これは、ソースボリュームと関連するリポジトリボリュームの両方に適用されます。
  • ボリュームコピー:ソースボリュームに USM データベース内の読み取り不能セクターエントリが含まれている場合、コントローラファームウェアはボリュームコピー要求を拒否します。
  • 再構成処理:コントローラファームウェアは、 USM データベースに読み取り不能なセクターエントリがあるボリュームに対して行われたボリューム再構成要求を拒否します。
  • ボリュームのインポート:読み取り不能セクターのデータベースがオーバーフローする原因となるボリュームグループがインポートされると、インポートは失敗し、新しいボリュームはオフライン状態のままになります。MEL イベントが生成され、 Recovery Guru アクションがログに記録され、インポートを実行する前に読み取り不能セクターデータベースのエントリ数を減らす必要があることが説明されます。

 

追加情報

注意:この記事の内容全体を表示できない場合は、 kb.netapp.com にログインしてください