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

Linux の StorageGRID ノードコンテナ移行要件

PDF

ノード移行機能を使用すると、ノードをあるホストから別のホストに手動で移動できます。通常、両方のホストは同じ物理データセンターに設置されています。

メモ 「Linux」とは、RHEL、Ubuntu、またはDebianのいずれかの環境を指します。サポートされているバージョンの一覧については、 "NetApp Interoperability Matrix Tool（IMT）"を参照してください。

ノード移行により、グリッド運用を中断することなく、物理ホストのメンテナンスを実行できます。物理ホストをオフラインにする前に、すべての StorageGRID ノードを1つずつ別のホストに移動します。ノードの移行には各ノードで短時間のダウンタイムしか必要とせず、グリッドサービスの運用や可用性に影響を与えることはありません。

StorageGRID ノード移行機能を使用する場合は、デプロイメントが追加の要件を満たす必要があります：

  • 単一の物理データセンター内のホスト間で一貫したネットワークインターフェイス名

  • 単一の物理データセンター内のすべてのホストからアクセス可能な、StorageGRID メタデータおよびオブジェクト リポジトリ ボリューム用の共有ストレージ。たとえば、NetApp E シリーズ ストレージ アレイを使用できます。

仮想ホストを使用しており、基盤となるハイパーバイザー層が VM 移行をサポートしている場合は、StorageGRID のノード移行機能の代わりにこの機能を使用することを検討してください。この場合は、これらの追加要件は無視して構いません。

移行またはハイパーバイザーのメンテナンスを実行する前に、ノードを正常にシャットダウンしてください。"グリッドノードをシャットダウンする"の手順を参照してください。

VMware Live Migrationはサポートされていません

VMware VM でベアメタルインストールを実行する場合、OpenStack Live Migration および VMware Live vMotion は仮想マシンのクロック時刻をジャンプさせる原因となるため、どのタイプのグリッドノードでもサポートされていません。まれではありますが、クロック時刻が正しくない場合、データの損失や設定の更新エラーが発生する可能性があります。

コールドマイグレーションがサポートされています。コールドマイグレーションでは、ホスト間でノードを移行する前に StorageGRID ノードをシャットダウンします。"グリッドノードをシャットダウンする"の手順を参照してください。

一貫性のあるネットワークインターフェース名

ノードをあるホストから別のホストに移動するには、StorageGRID ホストサービスは、ノードが現在の場所で持つ外部ネットワーク接続が新しい場所でも再現できるという確信を持つ必要があります。ホスト間で一貫したネットワークインターフェイス名を使用することで、この信頼性を確保しています。

例えば、Host1上で稼働する StorageGRID NodeA は、以下のインターフェイスマッピングで設定されているとします：

この図には説明が付随しています。

矢印の左側は、StorageGRID コンテナ内部から見た従来のインターフェース（つまり、それぞれグリッド、管理、およびクライアントネットワークのインターフェース）に対応しています。矢印の右側は、これらのネットワークを提供する実際のホストインターフェースに対応しており、これらは同一の物理インターフェースボンドに属する 3 つの VLAN インターフェースです。

さて、NodeAをHost2に移行したいとしましょう。Host2にもbond0.1001、bond0.1002、bond0.1003という名前のインターフェイスがある場合、システムは、同じ名前のインターフェイスがHost1と同様にHost2でも同じ接続性を提供すると想定して、移動を許可します。Host2に同じ名前のインターフェイスが存在しない場合、移動は許可されません。

複数のホスト間で一貫したネットワークインターフェイス命名を実現する方法は多数あります。いくつかの例については、"ホストネットワークの設定"を参照してください。

共有ストレージ

迅速な低オーバーヘッドのノード移行を実現するために、StorageGRID ノード移行機能はノードデータを物理的に移動させるものではありません。代わりに、ノードの移行は、以下のようにエクスポートとインポートの操作のペアとして実行されます。

  • 「ノードエクスポート」操作中、HostA上で実行されているノードコンテナから少量の永続状態データが抽出され、そのノードのシステムデータボリュームにキャッシュされます。次に、HostA上のノードコンテナがデインスタンス化されます。

  • 「ノードインポート」操作中に、HostA で有効だったものと同じネットワークインターフェースとブロックストレージマッピングを使用する HostB 上のノードコンテナがインスタンス化されます。次に、キャッシュされた永続状態データが新しいインスタンスに挿入されます。

この動作モードを踏まえると、移行が許可され、正常に機能するためには、ノードのすべてのシステムデータおよびオブジェクトストレージボリュームが、HostA と HostB の両方からアクセスできる必要があります。さらに、それらは HostA と HostB 上の同じ LUN を参照することが保証された名前を使用して、ノードにマッピングされている必要があります。

次の例は、StorageGRID ストレージノードのブロックデバイスマッピングの1つのソリューションを示しています。ホスト上で DM マルチパスが使用されており、 `/etc/multipath.conf`のエイリアスフィールドを使用して、すべてのホストで利用可能な一貫性のある分かりやすいブロックデバイス名を提供しています。

ブロックデバイスマッピング