グリッドノードをホストにリストアします
障害グリッドノードを新しいLinuxホストにリストアするには、次の手順を実行してノード構成ファイルをリストアします。
-
ノードをリストアして検証 ノード構成ファイルをリストアする。新規インストールの場合は、ホストにインストールするグリッドノードごとにノード構成ファイルを作成します。交換ホストにグリッドノードをリストアするときは、障害グリッドノードのノード構成ファイルをリストアまたは交換します。
-
必要に応じて、 起動しないノードをリカバリ。
以前のホストのブロックストレージボリュームが保持されている場合は、追加のリカバリ手順の実行が必要になることがあります。このセクションのコマンドを使用して、必要な追加手順を特定できます。
グリッドノードをリストアして検証する
障害グリッドノードのグリッド構成ファイルをリストアして検証し、エラーをすべて解決する必要があります。
ホストに必要なグリッドノードは、すべてインポートできます /var/local
前のホストで障害が発生したためにボリュームが失われませんでした。たとえば、などです /var/local
使用しているLinuxオペレーティングシステムでのStorageGRID のインストール手順に従って、StorageGRID システムのデータボリュームに共有ストレージを使用していた場合は、ボリュームが残っている可能性があります。ノードをインポートすると、ノード構成ファイルがホストにリストアされます。
欠落しているノードをインポートできない場合は、ノードのグリッド構成ファイルを再作成する必要があります。
次に、 StorageGRID の再起動に進む前に、グリッド構成ファイルを検証し、予想されるネットワークまたはストレージの問題を解決する必要があります。ノードの構成ファイルを再作成する場合は、リカバリするノードに使用されていたのと同じ名前を交換用ノードに使用する必要があります。
の場所の詳細については、インストール手順を参照してください /var/local
ノードのボリューム。
-
リカバリしたホストのコマンドラインで、現在設定されているすべてのStorageGRID グリッドノードを表示します。
sudo storagegrid node list
グリッドノードが設定されていない場合、出力は表示されません。グリッドノードが設定されている場合は、次の形式で出力が表示されます。
Name Metadata-Volume ================================================================ dc1-adm1 /dev/mapper/sgws-adm1-var-local dc1-gw1 /dev/mapper/sgws-gw1-var-local dc1-sn1 /dev/mapper/sgws-sn1-var-local dc1-arc1 /dev/mapper/sgws-arc1-var-local
ホストで設定する必要があるグリッドノードの一部またはすべてが表示されない場合は、表示されないグリッドノードをリストアする必要があります。
-
を含むグリッドノードをインポートします
/var/local
ボリューム:-
インポートする各ノードに対して次のコマンドを実行します。
sudo storagegrid node import node-var-local-volume-path
。
storagegrid node import
コマンドが成功するのは、対象のノードが最後に実行されたホストでクリーンシャットダウンされている場合のみです。そうでない場合は、次のようなエラーが表示されます。This node (node-name) appears to be owned by another host (UUID host-uuid).
Use the --force flag if you are sure import is safe.
-
別のホストが所有しているノードに関するエラーが表示された場合は、を指定してもう一度コマンドを実行します
--force
インポートを完了するためのフラグ:sudo storagegrid --force node import node-var-local-volume-path
を使用してインポートされたノード --force
フラグを設定すると、グリッドに再参加できるようになるために追加のリカバリ手順が必要になります(を参照) "次の手順:必要に応じて追加のリカバリ手順を実行します"。
-
-
がないグリッドノードの場合
/var/local
ボリューム。ノードの構成ファイルを再作成してホストにリストアします。手順については、次を参照してください。-
"UbuntuまたはDebianのノード構成ファイルを作成します"
ノードの構成ファイルを再作成する場合は、リカバリするノードに使用されていたのと同じ名前を交換用ノードに使用する必要があります。Linux 環境の場合は、構成ファイルの名前にノード名が含まれていることを確認します。可能な場合は、同じネットワークインターフェイス、ブロックデバイスマッピング、および IP アドレスを使用してください。これにより、リカバリ時にノードにコピーしなければならないデータ量を最小限に抑えることができるため、リカバリにかかる時間を大幅に(場合によっては、数週間から数分に)短縮できます。
新しいブロックデバイス(StorageGRID ノードで以前に使用していなかったデバイス)を、で始まる設定変数の値として使用する場合 BLOCK_DEVICE_
ノードの構成ファイルを再作成する場合は、のガイドラインに従ってください ブロックデバイスが見つからないエラーを修正します。 -
リカバリしたホストで次のコマンドを実行して、すべての StorageGRID ノードを一覧表示します。
sudo storagegrid node list
-
StorageGRID のノードリストの出力に表示されている各グリッドノードのノード構成ファイルを検証します。
sudo storagegrid node validate node-name
StorageGRID ホストサービスを開始する前に、すべてのエラーまたは警告に対処する必要があります。以下のセクションでは、リカバリ時に特に問題となるエラーについて詳しく説明します。
ネットワークインターフェイスが見つからないエラーを修正
ホストネットワークが正しく設定されていない場合や名前のスペルが間違っている場合、StorageGRID がで指定されたマッピングを確認する際にエラーが発生します /etc/storagegrid/nodes/node-name.conf
ファイル。
次のエラーまたは警告が表示されることがあります。
Checking configuration file /etc/storagegrid/nodes/<node-name>.conf for node <node-name>... ERROR: <node-name>: GRID_NETWORK_TARGET = <host-interface-name> <node-name>: Interface <host-interface-name>' does not exist
エラーは、グリッドネットワーク、管理ネットワーク、またはクライアントネットワークについて報告される場合があります。このエラーは、を意味します /etc/storagegrid/nodes/node-name.conf
ファイルは、指定されたStorageGRID ネットワークをというホストインターフェイスにマッピングします `host-interface-name`とはいえ、現在のホストには、この名前のインターフェイスがありません。
このエラーが表示された場合は、の手順を実行したことを確認してください "新しい Linux ホストを導入する"。すべてのホストインターフェイスに、元のホストで使用されていた名前と同じ名前を使用します。
ノード構成ファイルに指定されている名前をホストインターフェイスに付けることができない場合は、ノード構成ファイルを編集して、 GRID_NETWORK_TARGET 、 ADMIN_NETWORK_TARGET 、または CLIENT_network_target の値を既存のホストインターフェイスに一致するように変更できます。
ホストインターフェイスが適切な物理ネットワークポートまたは VLAN へのアクセスを提供し、インターフェイスがボンドデバイスまたはブリッジデバイスを直接参照していないことを確認してください。ホストのボンドデバイスの上に VLAN (または他の仮想インターフェイス)を設定するか、ブリッジと仮想イーサネット( veth )のペアを使用する必要があります。
ブロックデバイスが見つからないエラーを修正します
システムは、リカバリされた各ノードが有効なブロックデバイススペシャルファイル、またはブロックデバイススペシャルファイルへの有効なソフトリンクにマッピングされていることを確認します。StorageGRID がで無効なマッピングを検出した場合 /etc/storagegrid/nodes/node-name.conf
ファイル。ブロックデバイスが見つからないことを示すエラーが表示されます。
次のエラーが発生することがあります。
Checking configuration file /etc/storagegrid/nodes/<node-name>.conf for node <node-name>... ERROR: <node-name>: BLOCK_DEVICE_PURPOSE = <path-name> <node-name>: <path-name> does not exist
これはそのことを意味します /etc/storagegrid/nodes/node-name.conf
node-name_forで使用されるブロックデバイスをマッピングします PURPOSE
Linuxファイルシステム内の指定されたパス名へのリンクですが、その場所に有効なブロックデバイススペシャルファイルまたはブロックデバイススペシャルファイルへのソフトリンクがありません。
の手順が完了していることを確認します "新しい Linux ホストを導入する"。すべてのブロックデバイスに、元のホストで使用されていたのと同じ永続的なデバイス名を使用します。
見つからないブロックデバイススペシャルファイルをリストアまたは再作成できない場合は、適切なサイズとストレージカテゴリの新しいブロックデバイスを割り当て、ノード構成ファイルを編集しての値を変更できます BLOCK_DEVICE_PURPOSE
をクリックして、新しいブロックデバイススペシャルファイルを指定します。
Linuxオペレーティングシステムに対応した表を使用して、適切なサイズとストレージカテゴリを決定します。
ブロックデバイスの交換に進む前に、ホストストレージの設定に関する推奨事項を確認してください。
で始まる構成ファイル変数に新しいブロックストレージデバイスを指定する必要がある場合 BLOCK_DEVICE_ 元のブロックデバイスは障害ホストとともに失われたため、リカバリ手順を進める前に新しいブロックデバイスがフォーマットされていないことを確認してください。共有ストレージを使用していて新しいボリュームを作成済みの場合、新しいブロックデバイスはアンフォーマットされます。状況がわからない場合は、新しいブロックストレージデバイスのスペシャルファイルに対して次のコマンドを実行します。
|
次のコマンドは、新しいブロックストレージデバイスに対してのみ実行してください。デバイス上のデータはすべて失われるため、リカバリ対象のノードの有効なデータがブロックストレージに残っていると思われる場合は、このコマンドを実行しないでください。
|
StorageGRID ホストサービスを開始する
StorageGRID ノードを起動し、ホストのリブート後もノードが再起動されるようにするには、 StorageGRID ホストサービスを有効にして開始する必要があります。
-
各ホストで次のコマンドを実行します。
sudo systemctl enable storagegrid sudo systemctl start storagegrid
-
次のコマンドを実行して、導入の進行状況を確認します。
sudo storagegrid node status node-name
-
いずれかのノードから「Not Running」または「`Stopped」のステータスが返された場合は、次のコマンドを実行します。
sudo storagegrid node start node-name
-
StorageGRID ホストサービスを以前に有効にして開始している場合(またはサービスを有効にして開始したかどうかがわからない場合)は、次のコマンドも実行します。
sudo systemctl reload-or-restart storagegrid
正常に開始しないノードをリカバリします
StorageGRID ノードがグリッドに正常に再参加できずリカバリ可能と表示されない場合は、ノードが破損している可能性があります。ノードを強制的にリカバリモードに設定することができます。
-
ノードのネットワーク設定が正しいことを確認します。
ネットワークインターフェイスのマッピングまたはグリッドネットワークのIPアドレス/ゲートウェイが正しくないため、ノードがグリッドに再参加できなかった可能性があります。
-
ネットワーク設定が正しい場合は、問題 を実行します
force-recovery
コマンドを実行しますsudo storagegrid node force-recovery node-name
-
ノードに対して追加のリカバリ手順を実行します。を参照してください "次の手順:必要に応じて追加のリカバリ手順を実行します"。