Skip to main content
本製品の最新リリースがご利用いただけます。
日本語は機械翻訳による参考訳です。内容に矛盾や不一致があった場合には、英語の内容が優先されます。

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

共同作成者

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

作業を開始する前に
このタスクについて

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

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

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

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

      2. に記載されているパスワードを入力します Passwords.txt ファイル。

      3. 次のコマンドを入力してrootに切り替えます。 su -

      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 です。

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

    1. このLDRノードIDに関連付けられているストレージノードを探します。Grid Manager で、 * support * > * Tools * > * Grid topology * を選択します。次に、「 * _ データセンター _ * > * _ ストレージノード _ * > * LDR * 」を選択します。

      LDRサービスのノードIDは、[Node Information]テーブルに表示されます。この LDR をホストしているストレージノードが見つかるまで、各ストレージノードの情報を確認します。

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

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

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

      2. に記載されているパスワードを入力します Passwords.txt ファイル。

      3. 次のコマンドを入力してrootに切り替えます。 su -

      4. に記載されているパスワードを入力します Passwords.txt ファイル。

        rootとしてログインすると、プロンプトがから変わります $ 終了: #

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

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

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

      ls '/var/local/rangedb/1/p/17/11/00rH0%DkRs&LgA%#3tN6'
      メモ コマンドでは、オブジェクトファイルパスを常に一重引用符で囲み、特殊文字をエスケープします。
      • オブジェクトのパスが見つからない場合、オブジェクトは失われ、この手順 を使用してリストアすることはできません。テクニカルサポートにお問い合わせください。

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

  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'

        次の手順に進みます。

  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

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

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

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

      2. に記載されているパスワードを入力します Passwords.txt ファイル。

      3. 次のコマンドを入力してrootに切り替えます。 su -

      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_restored_object.txt
    4. grep を使用して、この出力ファイルから Object Rules Met ( ORLM )監査メッセージを抽出します。入力するコマンド grep ORLM 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]]
    1. 監査メッセージで LOCS フィールドを検索します。

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

  6. "損失オブジェクトと欠落オブジェクトのカウントをリセットします" をクリックします。