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

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

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

環境

NetApp E シリーズ製品

回答

  • 読み取り不能セクター管理(USM)機能は、通常のI/O処理中に検出された読み取り不能セクターを処理するコントローラベースの方法と、再構築などの長時間実行処理を提供します。
  • この機能は、主にエンドユーザに対して透過的に設計されているため、設定可能なオプションは使用できず、機能を無効にすることはできません。
  • USMが提供する5つの主な機能改善は次のとおりです。
    1. メジャーイベントログ(MEL)での読み取り不能セクター(およびUSM関連の条件)のレポートが改善されました。
    2. 読み取り不能セクターのレポートを継続します。
    3. メディアエラーが発生しても、再構築やその他の長時間処理が継続されます。
    4. パリティを生成できない場合でも、最適な RAID 5 ボリュームへの書き込みが正常に完了しました。
    5. RAID再設定処理(Dynamic Capacity Expansion(DCE;動的容量拡張)DVE)Dynamic Volume拡張機能によって、メディアエラー状態を永続化します。
  • ネットアップは1つのサブシステムでFC-SCSIディスクとSATAディスクの両方をサポートするため、この機能は物理ディスク機能に依存せず、コントローラファームウェア内で完全に処理されるように設計されています。
    • ただし、ネイティブでサポートされていないディスクの機能をエミュレートするためにコントローラファームウェアで実行されることはありません。
  • この資料では、「読み取り不能セクター」とは、物理ディスクメディア関連の二重障害状態または非冗長ボリューム(RAID 0)上の物理ディスクメディア関連の単一障害状態によって完全に読み取り不能とみなされるボリューム論理ブロックアドレス(LBA)と定義されています。
    • 読み取り不能セクターはリカバリ不能であり、その場所に格納されているデータは失われたとみなされ、その他の方法でリカバリする必要があります。

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

  • 読み取り不能セクターのデータベースは安定したストレージに保持され、検出された読み取り不能セクターごとのエントリが格納されます。
  • ボリューム中心の情報を使用して記録されます。これには次の情報が含まれます。
    • 固有のボリューム識別子(SSIDではない)
    • ボリューム LBA
    • ブロック数
  • データベースを安定したストレージに保持することの利点は、リブート、ボリュームの再構成、ファームウェアのアップグレード(USMをサポートするコードへのアップグレードの場合)、ボリュームの状態の変更、およびボリューム転送が維持されるため、読み取り不能セクターのレポートを永続的に保持できることです。

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

  • SANtricity (アレイ管理ウィンドウ)で 、 [Monitor] >[Reports] >[unreadableSectors Log] の順に選択します。
  • SANtricity CLI コマンド: show storageArray unreadableSectors
  • SANtricity Array Manager ( SAM )で、 Support >> Support Center >> Diagnostics タブ >> View / Clear Unreadable Sectors を選択します。

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

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

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

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

再構築:

  • 読み取りはRAID 5再構築中に処理されます。
  • 読み取り不能セクターデータベースに既存のエントリが見つかった場合は、再構築ドライブの対応するセクターが読み取り不能セクターデータベースに追加され、再構築ドライブで失われたデータに対して重大MELイベントが生成されます。
  • 再構築中のドライブのセクターは、既知のデータパターンで書き込まれます。
  • RAID 5の再構築の実行中にディスクから新しいメディアエラーが返される場合、次の2つの状況が考えられます。

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

  • 処理が実行されました。
    • 読み取り不能セクターデータベースには、データドライブの不良セクター用と、再構築ドライブで再生できなかったデータ用の2つ目の読み取り不能セクターが追加されます。
    • 両方の場所でユーザデータが失われるため、両方のセクターに対して重大なMELイベントが生成されます。
    • この処理により、読み取り不能セクターのエントリがパリティドライブのメモリ内テーブルに追加されます。

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

  • 処理が実行されました。
    • 再構築ドライブで再生できなかった場所の読み取り不能セクターデータベースに対するエントリが1つ作成されます。
    • 失われたユーザデータに対して1つのMELイベントがログに記録されます。
    • パリティ・ドライブ上の場所を示すエントリが、イン・メモリ・テーブルに追加されます。
  • 読み取りは、RAID 1の再構築中に処理されます。
    • 読み取り不能セクターデータベースに既存のエントリが見つかった場合は、再構築ドライブの対応するセクターが既知のデータパターンで書き込まれ、MELイベントは生成されません。
  • 再構築の実行中にソースディスクで新しいメディアエラーが発生した場合、障害が発生したセクターがデータベースに追加され、重大なMELイベントが生成されます。
    • 再構築中のドライブはデフォルトのパターンで書き込まれます。

コピーバック処理:

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

Immediate Availability Format(IAF)

  • IAFは、メディアエラーを検出すると、読み取り不能セクターのエントリや対応するパリティブロックを読み取り不能セクターのデータベースに格納します。
  • メディアエラーのサイトに対して重大MELイベントが生成されます。

ダイナミック・リコンフィグレーション

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

 

  • USMを実装しても、物理メディアエラーがユーザーのデータへのアクセスに影響しないことは保証されません。 
  • 読み取り不能セクター管理は、エンドユーザーにこれらのエラーが存在することを通知することで、この可能性を低減するように設計されています。
  • USMをメディアスキャンなどの機能と併用すれば、システム管理者は予防的な対策を講じ、ハードウェアの問題がデータアクセスに影響しないようにすることができます。
  • 読み取り不能セクターデータベースにすでに記録されているセクターと交差するホスト読み取りは、センスキー0x03(Medium Error)およびASC/ASCQ(0x11 / 0x00)を返します(回復不能な読み取りエラー)。
  • 読み取り不能セクターデータベースには、最大1000個のエントリのみを許可する制限要因があります。
    • この1、000個のエントリ制限は、すべてのボリュームグループ、ボリューム、およびディスクに適用されます。
    • データベースがフルになると、コントローラの動作は次のようになります。
      • 再構築中に読み取り不能セクターが新しく検出された場合、ドライブは再構築できませんが、読み取り不能セクターのデータベースへのエントリは作成されません。
      • ホストI/O中に読み取り不能セクターが新しく検出された場合、ホストI/Oは失敗し、エントリは作成されません。
      • データベースがフルになったあとに検出された新しい読み取り不能セクターについては、重大なMELイベントが生成されます。
        • この場所にアクセスしようとするたびに、重要なイベントが生成されます。これは、データベース内でエントリを作成できないためです。

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

  • ユーザーリクエスト: 
    • ユーザは、SANtricity GUIまたはSANtricity CLIスクリプトを使用して、指定されたボリューム、ボリュームグループ、またはサブシステム全体のデータベースエントリの消去を要求できます。
    • このタイプの要求は、指定したレベルで読み取り不能セクターをすべて消去し、次のような原因を引き起こします。
      • 対応するセクターに書き込まれる既知のデータパターン。
      • 読み取り不能セクターを含むストライプに対して、正しいパリティが生成されるようにします。
      • データベースから削除するエントリ
    • SANtricity では、読み取り不能セクターのエントリを表示し、[Monitor]>[Reports]>[unreadableSectors Log]の順に選択してクリアオプションを選択できます。
      • または、次のSANtricity CLIスクリプトを使用してエントリをクリアします。 clear allVolumes unreadableSectors;
    • コントローラSAMから、サポート>>サポートセンター>>診断タブ>>「読み取り不能セクターの表示/消去」の選択>>エントリの選択>>クリアの順に選択します。
  • 成功した書き込み:
    • USMデータベースに入力されたセクターへの書き込みが成功すると、そのエントリも削除されます。
    • 既知の読み取り不能セクターと交差する書き込みが発生した場合、その書き込みは書き込みに変換され、セクターが修復されて読み取り可能であることが確認されます。
    • 書き込みとVerifyが正常なステータスを返した場合、そのセクターはデータベースから削除されます。

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

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

 

追加情報

注:この記事のコンテンツ全体を参照できない場合は 、NetAppナレッジベースにログインしてください

 

NetApp provides no representations or warranties regarding the accuracy or reliability or serviceability of any information or recommendations provided in this publication or with respect to any results that may be obtained by the use of the information or observance of any recommendations provided herein. The information in this document is distributed AS IS and the use of this information or the implementation of any recommendations or techniques herein is a customer's responsibility and depends on the customer's ability to evaluate and integrate them into the customer's operational environment. This document and the information contained herein may be used solely in connection with the NetApp products discussed in this document.