web-dev-qa-db-ja.com

ESXiで特大の暗号化サーバーを移行する方法

それで、私は特定の窮地に陥り、私の問題を解決するためのいくつかの方法を見てきましたが、その間にいくつかの部分が欠けています。

私の問題の根本は、いくつかの重要なDebian VMを備えた古いESXi管理対象サーバーと、これらのVMをホストしたい新しいESXiサーバーがあることです。サーバーは別々のデータセンターにあり、VMの実際の使用サイズはわずか数Gbsですが、それぞれが暗号化されたLVMとしてセットアップされているため、ESXiはそれらを完全に満たされた3TBドライブと見なします。理想的には、これらのVMの重要でない部分のコピーを作成し、ある時点でダウンタイムをアナウンスしてフリーズし、重要な部分を転送したいと思います。ディスクが暗号化されていない場合は、ドライブを縮小するだけで済みますが、ドライブを縮小するには、サーバーをシャットダウンする必要があり、理想的とは言えません。そういうものとして、私がとることができると私が見る道。

  1. 各3TB VMDKファイルを手動で転送します（非常に遅い）
  2. 転送を改善するためにダウンタイムとサイズ変更を行います（ダウンタイムは理想的ではありません）
  3. DD、sfdisk、LVMツール、およびダンプのいくつかの組み合わせを使用して、新しいVMにデータを転送します

3を使用したいのですが、正直なところ、これをどのように行うのか、またはLVMと暗号化されたセットアップを保持するための最善の方法がわかりません。

debianvmware-esxilive-migration
5
Whinis

したがって、これはP2Vが失敗した後の最良のシナリオでした。

  1. LVM暗号化が機能している宛先にVM）コピーを作成します。

  2. 2番目のVMを作成し、暗号化されたLVMを/ mntにマウントします

    Important so that the server itself is not running
  3. アクセスの問題を防ぐために、rootユーザーのサーバー間でキーをコピーします

  4. 次のコマンドを実行します

    rsync -aHxvK --numeric-ids --progress --exclude=/etc/fstab --exclude=/etc/crypttab --exclude=/etc/initramfs-tools/conf.d/* --exclude=/etc/network/* --exclude=/mnt/* --exclude=/dev/* --exclude=/proc/* --exclude=/sys/* --exclude=/tmp/* --exclude=/boot/* --exclude=/root/*   [email protected]:/* /mnt/

これにより、変更されていないファイルのほとんどがコピーされ、サーバーの機能する「コピー」が提供されます。このrsyncのほとんどはオンラインのいくつかのガイドに示されていますが、暗号化されたボリュームには/ etc/crypttabが必要であるか、起動せず、initramfsが必要であるか、起動時にスパムをコンソールします。

これが完了したら、短いダウンタイムをスケジュールし、データベースやWebサーバーなどの主要なサービスをシャットダウンし、エンドポイントを起動して新しいサーバーに転送する前に、これらのディレクトリの最終的な転送を行います。

1
Whinis

暗号化のため、ディスクの「有用な」部分の移行は、「外部」からVM）を確認するツールでのみ実行できません。これには、vMotion、Veeam B＆Rなどが含まれます。

私の頭に浮かぶのは、無料のVMwareコンバーターを使用して実行される移行だけです。これにより、「内部」からVM）を確認することで、「P2V」ライブ移行を実行できます。

VMとESXiホストの両方に到達できるWindows VMにインストールし、「パワーオン」Linuxマシンの移行を選択してルートを提供しますVMとESXiホストの両方の資格情報。マシンにログインして「内部」から移行を実行し、ディスクが数GBいっぱいであることを確認して、これらのみを転送します。I 「インフラストラクチャ」を選択した場合、コンバータはVMがすでにインフラストラクチャにあるという事実を利用しようとしますが、これは特定のケースでは悪いことです。

自宅でも暗号化ディスクを使用した本番環境でもこれを試したことはありませんが、物理ホストからESXiホストへの1TBディスクを使用したP2Vライブマイグレーションを実行しました。1GBeを介したマイグレーションには約40mしかかかりませんでしたが、 GBリンクを介した1TBの​​データ全体は約3時間であるため、ファイルごとのタイプのコピーのようなものを実行しました。

3
xmas79

考えられる解決策の1つ：

ターゲットホスト上に新しい空のVMを構築します。

シンプルなヘルパーVMを構築または再利用します。

ターゲットVMのディスクをヘルパーVMに接続し、それらにパーティションとファイルシステムを構築してマウントします。古い（0.xx）grubバージョンを使用する場合は、-I128を使用します。ファイルシステムを作成します！

ヘルパーVMから、実行中のシステム（/ procと/ sys !!を除く）をrsync経由でターゲットVMファイルシステムにコピーします。--numeric-idsが必要になる場合があります、-H、および--sparse /-inplace。-deleteを慎重に使用してください。

余裕があるときはいつでも、短いダウンタイムでソースシステムを静止し（できるだけ多くのサービス、特にデータベースサーバーをシャットダウンしてください！）、最後のrsyncを実行します。

コピーにchrootします。/procおよび/ sysマウントポイント、/ dev（MAKEDEVジェネリックは通常、賢明なudevに依存しないセットを提供します）、およびブートローダー（単純なgrub-installを実行するのが最も簡単です-デバイスファイルが指している場所に注意してください！-および後で最初の起動時に手動オプションを使用し、実行中のシステム内から適切に修正します）。

Unchroot、Unmount、およびディスクを切断します。コピーを起動します（最初はネットワークが切断されています。ブートローダーオプションを手動で微調整する必要があります）。

0
rackandboneman