Linux での ZFS 読み取り専用マウント + Solaris での同時読み取り書き込みマウント

Linux での ZFS 読み取り専用マウント + Solaris での同時読み取り書き込みマウント

Solaris から Linux に非常に大きなファイルを定期的にコピーする必要があります (ネットワークを使用)。現在、1 つのファイルにほぼ半日かかります。Solaris のファイルは ZFS ファイルシステム上にあります。

そこで、一体どうしたんだ、ZFS を Linux にマウントできるかもしれない、と考えました。

しかし、ZFS はクラスター化された (またはクラスター化可能な) ファイルシステムではありません。

仮説: Solaris からコピーしているだけなので、同じ ZFS ファイルシステムを読み取り専用でマウントできるので、この場合はクラスター化する必要はないと考えました。書き込みは Solaris 側でのみ行われるため (そこではアンマウントできません)。

Solaris ボックスは非常にビジーで、ネットワーク NIC もほぼ常に非常にビジーです。そのため、ファイル コピーを FC に移動すると、はるかに高速になるはずです。

その Linux ボックスは VMWare ホスト上の仮想ゲストです。したがって、同じ FC ファブリックをその Linux ゲストに提供することは可能です。

ご意見は? 仮説の部分については、フィードバックを求めるのが最も適切だと思います。Linux で ZFS 読み取り専用マウントを行い、Solaris で同時に読み取り/書き込みマウントを行うことが可能かどうかはわかりません。

答え1

それはまったく不可能です。ZFS では、読み取り/正しい権限に関係なく、2 つのホストに同時にマウントすることはできません。Solaris にマウントされているときに Linux にマウントしようとすると、強制的にマウントする必要があります。そうすると、Solaris はカーネル パニックでクラッシュします。2 台の Solaris で、最初のボックスにマウントされているときに 2 番目の Solaris ボックスにインポートを強制すると、この現象が発生しました。さらに、ZFS のバージョンも、Linux に zpool をインポートできるかどうかに影響します。試してみたい場合は、次の方法をお勧めします。

  1. ストレージ上のLUNをクローンする
  2. クローンしたLUNをLinuxボックスにマップする
  3. Linuxでzpoolをマウントしてみる

答え2

これを防ぐのは、ZFS がディスク状態を変更するのは自分だけであると想定してメタデータをメモリにキャッシュするという事実です。読み取り/書き込みでマウントされているホストであれば、問題ありません。読み取り専用でマウントされている別のホストでは、メタデータがその下から変更され、ある時点で (かなり速く)、有効なメタデータがあると考えられていたが、他のシステムによって上書きされた場所のディスクからブロックが読み取られます。

BitsOfNix が概説した lun クローン作成方法を試すか、定期的にスナップショット/送信/受信スクリプトを設定して最新の状態に保つことができます。または、Solaris ホストからデータセットを共有し、それを Linux ホストの NFS 経由でマウントすることもできます。

関連情報