日本語は機械翻訳による参考訳です。内容に矛盾や不一致があった場合には、英語の内容が優先されます。

失われた可能性があるオブジェクトを検索してリストアします

寄稿者

Lost Objects ( LOST )アラームと * Object lost * アラートをトリガーした(失われた可能性があると特定した)オブジェクトを検索してリストアできる場合があります。

必要なもの
  • 「損失オブジェクトの調査」で特定した損失オブジェクトの UUID が必要です。

  • 「 passwords.txt 」ファイルが必要です。

この手順 を使用して、グリッド内の他の場所で損失オブジェクトのレプリケートコピーを検索できます。ほとんどの場合、損失オブジェクトは見つかりません。ただし、迅速に対処すれば、損失レプリケートオブジェクトを検索してリストアできる場合があります。

重要 この手順 のサポートについては、テクニカルサポートにお問い合わせください。
手順
  1. 管理ノードの監査ログで、オブジェクトが存在する可能性のある場所を検索します。

    1. グリッドノードにログインします。

      1. 次のコマンドを入力します。 ssh admin@grid_node_name

      2. 「 passwords.txt 」ファイルに記載されたパスワードを入力します。

      3. root に切り替えるには、次のコマンドを入力します

      4. 「 passwords.txt 」ファイルに記載されたパスワードを入力します。root としてログインすると、プロンプトは「 $` 」から「 #」 に変わります。

    2. 監査ログが保存されているディレクトリ (cd /var/local/audit/export/`) に変更します

    3. grep を使用して、失われた可能性があるオブジェクトに関連付けられている監査メッセージを抽出し、出力ファイルに送信します。「 grep uuid-valueaudit_file_name > output_file_name 」と入力します

      例:

      Admin: # grep 926026C4-00A4-449B-AC72-BCCA72DD1311 audit.log > messages_about_lost_object.txt
    4. grep を使用して、この出力ファイルから Location Lost ( LLST )監査メッセージを抽出します。「 grep LLST output_file_name 」と入力します

      例:

      Admin: # grep LLST messages_about_lost_objects.txt

      LLST 監査メッセージは次のサンプルメッセージのようになります。

      [AUDT:\[NOID\(UI32\):12448208\][CBIL(UI64):0x38186FE53E3C49A5]
      [UUID(CSTR):"926026C4-00A4-449B-AC72-BCCA72DD1311"][LTYP(FC32):CLDI]
      [PCLD\(CSTR\):"/var/local/rangedb/1/p/17/11/00rH0%DkRs&LgA%\#3tN6"\]
      [TSRC(FC32):SYST][RSLT(FC32):NONE][AVER(UI32):10][ATIM(UI64):
      1581535134379225][ATYP(FC32):LLST][ANID(UI32):12448208][AMID(FC32):CLSM]
      [ATID(UI64):7086871083190743409]]
    5. LLST メッセージで PCLD フィールドと NOID フィールドを検索します。

      PCLD の値は、欠落しているレプリケートオブジェクトコピーへのディスク上の完全なパスです。NOID の値は、オブジェクトのコピーが存在する可能性のある LDR のノード ID です。

      オブジェクトの場所が見つかった場合は、オブジェクトをリストアできる場合があります。

    6. この LDR ノード ID のストレージノードを探します。

      ノード ID を使用してストレージノードを特定する方法は 2 つあります。

      • Grid Manager で、 * support * > * Tools * > * Grid topology * を選択します。次に、「 * _ データセンター _ * > * _ ストレージノード _ * > * LDR * 」を選択します。LDR ノード ID は Node Information テーブルに含まれています。この LDR をホストしているストレージノードが見つかるまで、各ストレージノードの情報を確認します。

      • グリッドのリカバリパッケージをダウンロードして解凍します。SAID パッケージには _\docs_directory があります。index.html ファイルを開くと、 Servers Summary には、すべてのグリッドノードのすべてのノード ID が表示されます。

  2. 監査メッセージで指定されているストレージノードにオブジェクトが存在するかどうかを確認します。

    1. グリッドノードにログインします。

      1. 次のコマンドを入力します。 ssh admin@grid_node_name

      2. 「 passwords.txt 」ファイルに記載されたパスワードを入力します。

      3. root に切り替えるには、次のコマンドを入力します

      4. 「 passwords.txt 」ファイルに記載されたパスワードを入力します。

root としてログインすると、プロンプトは「 $` 」から「 #」 に変わります。

  1. オブジェクトのファイルパスが存在するかどうかを確認します。

オブジェクトのファイルパスには、 LLST 監査メッセージの PCLD の値を使用します。

たとえば、次のように入力します。

ls '/var/local/rangedb/1/p/17/11/00rH0%DkRs&LgA%#3tN6'
  • 注 * :オブジェクトファイルのパスは、特殊文字をエスケープするために、必ず一重引用符で囲んでください。

  • オブジェクトパスが見つからない場合はオブジェクトが失われるため、この手順 を使用してリストアすることはできません。テクニカルサポートにお問い合わせください。

  • オブジェクトパスが見つかった場合は、手順に進みます オブジェクトを StorageGRID にリストアします。見つかったオブジェクトを StorageGRID にリストアできます。

    1. [[restore_The _object_to _sStorageGRID 、 start=3]] オブジェクトパスが見つかった場合は、オブジェクトを StorageGRID にリストアします。

      1. 同じストレージノードから、オブジェクトファイルの所有権を変更して StorageGRID で管理できるようにします。「 chown ldr-user : bycast 」 file_path_of -object ' ' ' と入力します

      2. Telnet で localhost 1402 に接続して、 LDR コンソールにアクセスします。「 telnet 0 1402` 」と入力します

      3. 「 cd /proc/STOR` 」と入力します

      4. 「 Object_found 」 file_path of -object 」と入力します

        たとえば、次のように入力します。

      Object_Found '/var/local/rangedb/1/p/17/11/00rH0%DkRs&LgA%#3tN6'

      + 'Object\\_found' コマンドを発行すると ' グリッドにオブジェクトの場所が通知されますまた、アクティブな ILM ポリシーがトリガーされ、ポリシーの指定に従って追加のコピーが作成されます。

  • 注:オブジェクトが見つかったストレージノードがオフラインの場合は、オンラインの任意のストレージノードにオブジェクトをコピーできます。オンラインのストレージノードの /var/local/rangedb ディレクトリにオブジェクトを配置します。次に ' オブジェクトへのそのファイル・パスを使用して 'Object\\_found' コマンドを問題 します

    • オブジェクトをリストアできない場合 'Object\\_Found' コマンドは失敗しますテクニカルサポートにお問い合わせください。

    • オブジェクトが StorageGRID に正常にリストアされた場合は、成功を伝えるメッセージが表示されます。例:

      ade 12448208: /proc/STOR > Object_Found '/var/local/rangedb/1/p/17/11/00rH0%DkRs&LgA%#3tN6'
      
      ade 12448208: /proc/STOR > Object found succeeded.
      First packet of file was valid. Extracted key: 38186FE53E3C49A5
      Renamed '/var/local/rangedb/1/p/17/11/00rH0%DkRs&LgA%#3tN6' to '/var/local/rangedb/1/p/17/11/00rH0%DkRt78Ila#3udu'
      1. [[verify_new_locations_were _created 、 start=4] オブジェクトが StorageGRID に正常にリストアされた場合は、新しい場所が作成されたことを確認します。

        1. 「 cd /proc/OBRP 」と入力します

        2. 「 ObjectByUUID UUID_VALUE 」と入力します

次の例は、 UUID 926026C4-00A4-449B-AC72-BCCA72DD1311 のオブジェクトに 2 つの場所があることを示しています。

ade 12448208: /proc/OBRP > ObjectByUUID 926026C4-00A4-449B-AC72-BCCA72DD1311

{
    "TYPE(Object Type)": "Data object",
    "CHND(Content handle)": "926026C4-00A4-449B-AC72-BCCA72DD1311",
    "NAME": "cats",
    "CBID": "0x38186FE53E3C49A5",
    "PHND(Parent handle, UUID)": "221CABD0-4D9D-11EA-89C3-ACBB00BB82DD",
    "PPTH(Parent path)": "source",
    "META": {
        "BASE(Protocol metadata)": {
            "PAWS(S3 protocol version)": "2",
            "ACCT(S3 account ID)": "44084621669730638018",
            "*ctp(HTTP content MIME type)": "binary/octet-stream"
        },
        "BYCB(System metadata)": {
            "CSIZ(Plaintext object size)": "5242880",
            "SHSH(Supplementary Plaintext hash)": "MD5D 0xBAC2A2617C1DFF7E959A76731E6EAF5E",
            "BSIZ(Content block size)": "5252084",
            "CVER(Content block version)": "196612",
            "CTME(Object store begin timestamp)": "2020-02-12T19:16:10.983000",
            "MTME(Object store modified timestamp)": "2020-02-12T19:16:10.983000",
            "ITME": "1581534970983000"
        },
        "CMSM": {
            "LATM(Object last access time)": "2020-02-12T19:16:10.983000"
        },
        "AWS3": {
            "LOCC": "us-east-1"
        }
    },
    "CLCO\(Locations\)": \[
        \{
            "Location Type": "CLDI\(Location online\)",
            "NOID\(Node ID\)": "12448208",
            "VOLI\(Volume ID\)": "3222345473",
            "Object File Path": "/var/local/rangedb/1/p/17/11/00rH0%DkRt78Ila\#3udu",
            "LTIM\(Location timestamp\)": "2020-02-12T19:36:17.880569"
        \},
        \{
            "Location Type": "CLDI\(Location online\)",
            "NOID\(Node ID\)": "12288733",
            "VOLI\(Volume ID\)": "3222345984",
            "Object File Path": "/var/local/rangedb/0/p/19/11/00rH0%DkRt78Rrb\#3s;L",
            "LTIM\(Location timestamp\)": "2020-02-12T19:36:17.934425"
        }
    ]
}
  1. LDR コンソールからサインアウトします。「 exit 」と入力します

    1. 管理ノードから、監査ログを検索してこのオブジェクトを ORLM 監査メッセージで探し、必要に応じて情報ライフサイクル管理( ILM )によってコピーが配置されていることを確認します。

  2. グリッドノードにログインします。

    1. 次のコマンドを入力します。 ssh admin@grid_node_name

    2. 「 passwords.txt 」ファイルに記載されたパスワードを入力します。

    3. root に切り替えるには、次のコマンドを入力します

    4. 「 passwords.txt 」ファイルに記載されたパスワードを入力します。root としてログインすると、プロンプトは「 $` 」から「 #」 に変わります。

  3. 監査ログが保存されているディレクトリ (cd /var/local/audit/export/`) に変更します

  4. grep を使用して、オブジェクトに関連付けられている監査メッセージを出力ファイルに抽出します。「 grep uuid-valueaudit_file_name > output_file_name 」と入力します

    例:

    Admin: # grep 926026C4-00A4-449B-AC72-BCCA72DD1311 audit.log > messages_about_restored_object.txt
  5. grep を使用して、この出力ファイルから Object Rules Met ( ORLM )監査メッセージを抽出します。「 grep output_file_name 」と入力します

    例:

    Admin: # grep ORLM messages_about_restored_object.txt

    以下は、 ORLM 監査メッセージの例です。

    [AUDT:[CBID(UI64):0x38186FE53E3C49A5][RULE(CSTR):"Make 2 Copies"]
    [STAT(FC32):DONE][CSIZ(UI64):0][UUID(CSTR):"926026C4-00A4-449B-AC72-BCCA72DD1311"]
    [LOCS(CSTR):"**CLDI 12828634 2148730112**, CLDI 12745543 2147552014"]
    [RSLT(FC32):SUCS][AVER(UI32):10][ATYP(FC32):ORLM][ATIM(UI64):1563398230669]
    [ATID(UI64):15494889725796157557][ANID(UI32):13100453][AMID(FC32):BCMS]]
  6. 監査メッセージで LOCS フィールドを検索します。

    このフィールドの CLDI の値は、オブジェクトコピーが作成されたノード ID とボリューム ID です。このメッセージは、 ILM が適用され、 2 つのオブジェクトコピーがグリッド内の 2 つの場所に作成されたことを示しています。。Grid Manager で損失オブジェクトの数をリセットします。