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

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

寄稿者

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

重要 StorageGRID は、複数のノードが相互に連携する分散システムです。グリッドノードのリストアにディスクの Snapshot を使用しないでください。各タイプのノードのリカバリとメンテナンスの手順を参照してください。

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

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

  • グリッドノードに障害が発生すると、日常処理の効率が低下する可能性があります。

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

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

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

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

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

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

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

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

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

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

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