☰

専用のベアメタル サーバーを VM に転送するにはどうすればよいですか?

tag-icon • tag-icon backup replication tar file-transfer dd
専用のベアメタル サーバーを VM に転送するにはどうすればよいですか?

次のような問題があります。直接物理的にアクセスできない専用 (ベアメタル) ハードウェア サーバー (Debian 10) があります。このサーバー上にあるすべてのデータとアプリケーションを VM に転送し、KVM ホストで実行したいと考えています。

なぜアプリケーションを VM に直接インストールしないのでしょうか? このアプリケーション (Apache Web サーバーで Perl 関連の作業、約 10 年間同じサーバー上で実行) のインストールは非常に複雑なので、何かを壊したほうがましです。そのため、誰も敢えてインストールしようとしません。しかし、今は移行する必要があり、そのためには何らかのスマートな回避策が必要です。

ddPerl および Apache サービスをすべてオフにして、ネットワーク経由でハード ディスクを転送することも考えましたが、問題は、ターゲット KVM ホストの容量sdaがベア メタル サーバーよりも小さいことです (最終的には使用可能な容量よりも少ない容量を使用し、sdaサイズが大きすぎるだけです)。

2 番目のオプションは、KVM にまったく同じバージョン番号 ( に従ってdpkg --list) の同じパッケージをインストールし、ベアメタル サーバー上のすべてのサービスを無効にして (データの一貫性を保つため)、ベアメタルサーバーから/etc、、/var/および/usrその他重要なものすべてを tarball に入れて、KVM で解凍することです。もちろん、rsync 経由でこれを行うこともできますが、原理はほぼ同じです。

最後のアイデアについてどう思いますか?

他に何かアイデアはありますか？

そのような作業をどのように進めますか?

答え1

として不安私にそれをするように頼んだので、私は自分の質問に答えます:)私の解決策はそれほど洗練されていませんでした不安ですが、とにかく皆さんと共有したいと思います。

私が実際に行ったのは、まず両方のファイルシステムの Inode サイズとブロック サイズをチェックして、それらが互いに同一であることを確認することでした ( を使用tune2fs)。

次に、SSHd などの存在するサービスを除くすべてのサービスをオフにしました。

apt-cloneそれを行った後、パッケージとバイナリをあるマシンから別のマシンにコピーするのではなく、使用することにしました。

# on the physical machine:
apt-get install apt-clone
apt-clone clone packages
# on the virtual machine:
apt-get install apt-clone
apt-clone clone packages.apt-clone.tar.gz
# check on the VM:
vimdiff <(dpkg --list) physical_mchine_packages.txt

次に、 を使用してデータを同期しましたrsync。同期したディレクトリは次のとおりです。

  • /root
  • /etchostname( 、、fstabなどのファイルや/default/grub、/network/interfaceskernel/initram/lvm に関連する他の多くのディレクトリは除外しました)
  • /usr(すべてではありません。使用するソフトウェアによって異なります)
  • /var(すべてではありません。使用するソフトウェアによって異なります)

最後のステップは、古い物理マシンのホスト名または IP アドレスがいくつかの構成ファイルに設定されているかどうかを確認することでした。

find . ! \( -path "*proc*" -o -path "*sys*" -o -path "*var/mail*" -o -path "*var/spool/mqueue*" -o -path "*var/log*" \) -type f -exec grep -iH -- "x.x.x.x" {} \;

以上です。これで VM ですべてが動作するようになりました。どなたかのお役に立てれば幸いです :)

答え2

（この回答では、ブロックデバイスレベル代替案として、仮想への移行中にパーティションとブートマネージャの構成をそのまま維持したい場合に最適です。

あなたが説明した問題は、実際には必ずしも発生するわけではありません。偶然に最近これを回避しました:

しかし、問題は、ターゲットKVMホストの容量がベアメタルサーバーのSDAよりも少ないことです。

パーティションを作成、ループマウント、編集することは完全に有効です。まばらなファイル内のスキップされた領域に実際にデータを書き込まない限り、ホスト ファイル システムよりも (大幅に) 大きいファイルでも問題ありません。

私がやったことは、大体 ですfstrim / && systemctl stop appserver && mount -o remount,ro / && sync && dd bs=64k if=/dev/nvme0n1 | ssh vmhost dd bs=64k conv=sparse of=..。次に、vm ホストで をlosetup使ってイメージを で利用できるようにしfdisk、resize2fsその (仮想) サイズを変更しました。イメージの末尾のほとんどにはすでにゼロしか含まれていなかったので、それに対する操作によって実際のサイズが大幅に増加することはありませんでした。

この最も単純なアプローチで最悪の場合のスペース要件は、古いサーバーのデータ コンテンツの 3 倍になります。1 回目はスパース イメージをコピーし、2 回目はサイズを変更し (つまり、最後に新しい穴を開けずにすべてのコンテンツを先頭に移動します)、2 回目は生のディスク イメージを仮想マシン管理で使用される形式に変換します (または、当時のファイル ベースのイメージを独自の論理ボリュームに移動します)。

注意すべき点:

  • この操作を行う方法は、計画されている仮想化のソフトウェア/設定によって異なります（たとえば、現在のシステムがEFI経由で起動しているが、仮想化がそれを優先していない場合、ディスクコピーいずれにせよ、ブートローダー関連の作業をやり直す必要があるのでしょうか?
  • fstrim（特に不良SSDやRAIDと組み合わせた場合）は、データ損失レベルの危険を伴う可能性があります。お使いの環境で安全な操作かどうか確信が持てない場合は、ヌルバイトのみを含む巨大なファイルを書き出す代替案 - 未使用領域が検出可能かどうか（ゼロ化されているかどうか）のみを気にし、ディスクが認識しているかどうかは気にしません。
  • ルートを読み取り専用にするだけで作業は完了しますが、結果は仮想マシン上で再起動される前にサーバーがクラッシュしたかのようにアプリケーションを停止した後にイメージをコピーすると、十分だ: 結局のところ、サーバーがクラッシュしても継続できると期待しているのです。

関連情報