NFS サーバーの移行 (Linux)

Question

iSCSI ディスク アレイにファイルを保存する NFS サーバー (Linux) があります。このサーバーは運用中です。サーバーとアレイは非常に古く、すぐに交換する必要があります (アレイにはすでに深刻な問題があります)。

交換用のサーバーとアレイは別のネットワークに用意してあります。

共有を rsync してからもう一度実行してデータを同期することを考えていました。それがデータの不整合を引き起こすかどうかはわかりません...共有は LVM 上にマウントされているので、最初にスナップショットを作成できるでしょうか?

質問：

すべてのデータを移行するための最善のアプローチは何ですか? 何かアドバイスはありますか?

Answer 1

2 回目の rsync の前にアレイへの書き込みを無効にする予定であれば、このアプローチは問題ありません。これにより、クリーンなコピーが作成されるはずです。

状況に応じて、ダウンタイムを最小限に抑えるために、トリプル rsync を実行します。

1. ソース サーバーが現状のまま実行されている間に、ファイルシステムを rsync します。これには時間がかかり、不整合が多数含まれる可能性のあるラフ コピーが取得されます。
2. (オプション) 1 に時間がかかり、その間に書き込みが大量に発生する場合は、ソース サーバーをそのまま実行したまま再度 rsync を実行します。この手順では時間が短縮されるため、はるかに優れたコピーが得られます (実行中に発生する書き込みが少なくなります)。
3. ソース ノードへの書き込みを停止します。最善の方法は、stoned が提案しているように、読み取り専用でマウントすることです。ただし、サービスをシャットダウンするか、シングル ユーザー モードを使用することもできます。
4. 最後に rsync を実行します。今回はかなり高速になるはずです。不整合はそれほど多くないはずです (ステップ 2 はステップ 1 よりもずっと短い) ので、同期するものはそれほど多くありません。
5. チェックを行い、古いサーバーの代わりに新しいサーバーを起動します。

ただし、注意すべき点がいくつかあります。

• 小さなファイルが多数（数百万）ある場合、いずれにしても rsync には時間がかかります。（回線速度が遅い場合やストレージが遅い/劣化している場合も同様です。）
• ソース ストレージにすでに問題がある場合 (ドライブの故障、またはボリュームが読み取り不能になる原因となるその他の問題)、#3 から開始してください。ダウンタイムは長くなりますが、転送中に障害が発生するリスクは最小限に抑えられます。
• ファイルシステムが存在するデバイス全体を rsync するという奇妙なアイデアを思いつきました。ターゲットがソースより大きい場合は機能する可能性があります。ただし、自分で試したことがないので、お勧めしません。

Answer 2

rsync+rsync または snapshot+rsync では、実際には大きな違いはありません。rsync の方が、追加のコマンドを使用する手間をかけずに転送中にデータを圧縮/暗号化できるため、おそらくより便利です。どちらの場合も、最後の rsync 以降にユーザーが共有にコピーした可能性のある内容 (転送中の部分的なファイルを含む) に追いつこうと永遠に試みることになります。正直なところ、私がお勧めするのは、使用率が低い期間に rsync を使用して最初のコピーを行うことです。次に、必要なメンテナンスのために短時間の停止が発生することをユーザーに警告します。ディスクへのサービス書き込みを停止します。古い共有を読み取り専用モードで再マウントし、最終的な rsync を実行してから、古い nfs 共有を新しいものに完全に置き換えます。必要に応じて、その期間中に顧客に読み取り専用アクセスを与えることができます。100% の可用性はまさに夢であり、データの損失/破損やアプリケーションのクラッシュに関する可能性のある無限の苦情を追いかけるよりも、顧客を 1 時間停止させる方がよいでしょう。