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

グリッドノードのリカバリに関する警告と考慮事項

共同作成者

グリッドノードに障害が発生した場合は、できるだけ早くリカバリする必要があります。ノードのリカバリを開始する前に、ノードのリカバリに関する警告と考慮事項をすべて確認しておく必要があります。

注意 StorageGRID は、複数のノードが相互に連携する分散システムです。グリッドノードのリストアにディスクSnapshotを使用しないでください。各タイプのノードのリカバリとメンテナンスの手順を参照してください。
メモ StorageGRID サイト全体で障害が発生した場合は、テクニカルサポートにお問い合わせください。テクニカルサポートは、お客様と協力して、リカバリされるデータ量を最大化し、ビジネス目標を達成するサイトリカバリ計画を策定、実行します。を参照して "テクニカルサポートによるサイトのリカバリ方法"

障害グリッドノードをできるだけ早くリカバリする理由には、次のものがあります。

  • グリッドノードで障害が発生すると、システムデータとオブジェクトデータの冗長性が低下して、別のノードで障害が発生した場合にデータが永続的に失われるリスクが高まります。

  • グリッドノードで障害が発生すると、日常業務の効率に影響する可能性があります。

  • グリッドノードで障害が発生すると、システム処理の監視を減らすことができます。

  • 厳格な ILM ルールが適用されている場合、障害が発生したグリッドノードで原因 500 Internal Server エラーが発生する可能性があります。

  • グリッドノードがすぐにリカバリされないと、リカバリ時間が長くなる可能性があります。たとえば、リカバリが完了する前にキューをクリアする必要が生じる場合があります。

リカバリするグリッドノードのタイプに応じて、必ずリカバリ手順 に従ってください。リカバリ手順は、プライマリまたは非プライマリ管理ノード、ゲートウェイノード、アプライアンスノード、およびストレージノードで異なります。

グリッドノードをリカバリするための前提条件

グリッドノードをリカバリする際の前提条件は次のとおりです。

  • 障害が発生した物理または仮想ハードウェアの交換と設定が完了している。

  • 交換用アプライアンスのStorageGRIDアプライアンスインストーラのバージョンは、StorageGRIDシステムのソフトウェアバージョンと同じです(を参照) "StorageGRID アプライアンスインストーラのバージョンを確認してアップグレードします"

  • プライマリ管理ノード以外のグリッドノードをリカバリする場合は、リカバリするグリッドノードとプライマリ管理ノードが接続されています。

  • アプライアンスストレージノードをリカバリする場合は、アプライアンスのインストール時に元のアプライアンスと同じストレージタイプ(Combined、Metadata-only、またはData-only)を指定する必要があります。別のストレージタイプを指定するとリカバリが失敗し、正しいストレージタイプを指定したアプライアンスの再インストールが必要になります。

複数のグリッドノードをホストしているサーバで障害が発生した場合のノードリカバリの順序

複数のグリッドノードをホストしているサーバで障害が発生した場合、ノードは任意の順序でリカバリできます。ただし、障害サーバがプライマリ管理ノードをホストしている場合は、最初にそのノードをリカバリする必要があります。プライマリ管理ノードを最初にリカバリすると、プライマリ管理ノードへの接続を待機するために他のノードのリカバリが停止するのを防ぐことができます。

リカバリしたノードの IP アドレス

現在他のノードに割り当てられているIPアドレスを使用してノードをリカバリしないでください。新しいノードを導入するときは、障害が発生したノードの現在の IP アドレスまたは未使用の IP アドレスを使用します。

新しい IP アドレスを使用して新しいノードを導入し、そのノードをリカバリする場合は、リカバリしたノードでも新しい IP アドレスが使用されます。元の IP アドレスに戻す場合は、リカバリ完了後に IP 変更ツールを使用します。