web-dev-qa-db-ja.com

LAN経由でrawディスクイメージを移行する

これが私の状況です：

  • 同じデータセンター内の2つの専用サーバーで、その間にギガビットイーサネットがあります。
  • 両方の専用サーバーは、追加のツールとユーティリティが追加されたDebianSqueezeに基づくレスキュー環境で起動しました。また、ソフトウェアのダウンロード、パッケージのインストール、および/または必要に応じたコンパイルのための十分なtmpスペース（両方のボックスに32GBのRAM））。
  • 両方の専用サーバーには、約3TBの使用可能スペースがあります。
  • 「ソース」サーバーには、Adaptec4ポートコントローラーを備えたハードウェアRAID-10に4x1.5TBディスクがあります。
  • 「宛先」サーバーには、Adaptec2ポートコントローラーを備えたハードウェアRAID-1に2x 3TBディスクがあります。他のサーバーと同じ世代ですが、ポートの数が異なります。
  • /dev/sdaで使用可能なブロックの数の違いは10MB未満ですが、宛先サーバーの配列は何らかの理由で数メガバイト小さくなっています。
  • 両方のRAIDアレイは、構成するすべてのディスクのディスク表面全体を使用して、1つの単一のRAIDボリュームを作成するように構成されています。
  • オペレーティングシステムはMBRモードで起動します。 UEFIブートは使用されません。

私がしたいこと：

  • ブロックレイヤーで、OSイメージ全体（これは、GPTパーティションテーブルのGRUB2ブートローダー、/ bootパーティション、および/パーティションのみで構成されます）を「ソース」サーバーから「宛先」サーバーにコピーします。
  • 可能であれば、コピーは「ライブ」で実行する必要があります。これは、ディスクイメージを解凍しない限り、宛先側にディスクイメージの適切なファイルを保存するための十分なスペースがないことを意味します。コピーが行われているときにハードディスクに。サーバー間のギガビットイーサネット接続は十分に信頼できるので、私はこれに満足しています。もちろん、転送の前後にファイルシステムに問題がないことを確認するために、両端（送信元と宛先）でfsckを実行します。
  • 可能であれば、各パーティションの構成ファイルシステムで使用されていないブロックをネットワーク経由で転送しないでください（すべてのパーティションはext4としてフォーマットされています）。これは、「ソース」ディスクの50％以上が/パーティションの空き領域であるためです。
  • /パーティションのサイズを調整して、コピー時に、宛先ディスクのほんのわずかに小さいサイズに収まるようにサイズが変更されるようにします。
  • コピーが成功したら、各ボリュームをマウントし、静的IPへの参照を修正して、新しいサーバーのIPを反映させます。 （これ以上の助けがなくても問題なく実行できます）

私の質問：

  • 最初各サーバーの/dev/sdaのサイズの差（バイト単位）を計算してから、e2resizeを使用して/パーティションのサイズを非破壊的に縮小する必要がありますソース側宛先側のスペースに収まるように？
  • Rawブロックデバイスでddを実行する必要があります。ソースから宛先まで（sshを介して）/dev/sda、またはで同等のパーティションレイアウトを作成する必要があります。宛先と各でddを実行しますpartition？一度にパーティションを処理するとブートローダーの問題が発生しますが、一度にパーティションを処理しない場合、宛先が可能な限り多くのバイトを書き込んだら、ddはデータの転送を停止することを知る必要がありますhold（ソースのパーティションレイアウト内の他のすべてのパーティションの論理的に「右側」にある最後のブロックの/パーティションの最後を「閉じる」ことを願っています）。

いくつかのその他。詳細：

  • ソースボックスのホストOSは、複数のOpenVZゲストを実行しているUbuntu Server12.04です。
  • 両方のボックスがレスキューで起動されるため、実行中のオペレーティングシステムによる基になるデータへの変更を予期せずに、直接ディスクアクセスが可能です。
linuxraidmigrationlocal-area-network
8
allquixotic

これは厄介ですが、実行可能です。

ここでは、/が/dev/sda3にあり、/bootが/dev/sda1にあると仮定します。

  1. 古いサーバー上のファイルシステムを可能な最小サイズに縮小します。

    oldserver # resize2fs -M /dev/sda3

  2. 新しいサーバーのディスクを、同じサイズの/boot、スワップスペース、および新しい/パーティション（およびその他必要なもの）でパーティション化します。

    newserver # parted /dev/sda

  3. /および/bootファイルシステムをコピーします。

    oldserver # dd if=/dev/sda1 | ssh root@newserver "dd of=/dev/sda1"
oldserver # dd if=/dev/sda3 | ssh root@newserver "dd of=/dev/sda3"

    新しいサーバーのパーティションは古いサーバーのパーティションよりもわずかに小さいため、この最後に偽のNo space left on deviceメッセージが表示されます。ただし、手順1でファイルシステムを縮小したので、これは問題ではありません。

  4. 新しいサーバー上のファイルシステムのサイズをパーティションのサイズに変更します。

    newserver # resize2fs /dev/sda3

  5. GRUBを新しいディスクにインストールします。

    newserver # mount /dev/sda3 /mnt
newserver # mount /dev/sda1 /mnt/boot
newserver # mount -o bind /dev /mnt/dev
newserver # mount -o proc proc /mnt/proc
newserver # chroot /mnt /bin/bash

newserver(chroot) # grub-install /dev/sda
newserver(chroot) # exit

  6. 残りの修正（IPアドレスなど）を終了します。

パーティションの空き領域をコピーしないようにする方法はおそらく見つかりますが、すべてをコピーするよりも調査に時間がかかる可能性があります...

6
Michael Hampton

新しいサーバーで新しいファイルシステムをmkfsしてから、古いサーバーからrsyncします。これは再起動可能で一貫性があり、各ファイルは簡単に個別に検証できます。ファイルシステムの未使用のセクション（フォレンジックコピーではない）を破棄する場合、この方法を使用しない理由はわかりません。 GRUBを再実行する必要がありますが、それは難しいことではありません。

ファイルシステムに対応した生のコピーを説明するには時間がかかるので、rsyncソリューションが機能しない理由についてコメントしない限り、入力する必要はありません。

5
Jeff Ferland

本当にブロックデバイスレベルでデータを転送したい場合は、ダウンタイムが最小限のサーバーを移行するために使用していた非常に便利なトリックを1つ考えることができます。

重要なのは、データパーティションがミラーの唯一のアクティブな半分であるソースサーバー上に劣化したミラーを作成し、 [〜＃〜] aoe [〜＃〜を介して2番目のサーバーから宛先パーティションをエクスポートすることです。 ] （両方のサーバーが同じブロードキャストドメインにあると思います）。次に、ソースサーバーで、ネットワークブロックデバイスを劣化したミラーに接続して、再構築を開始します。再構築が完了するまで待ち、ミラーを停止し、AOEエクスポートされたデバイスを削除して問題ありません。

もう少し詳細が続きます（簡潔にしようと思います）。

コンポーネント：

  • mdadmbuildモード（メタデータなしのアドホックミラー）;
  • vbladeブロックデバイスをAOEネットワークデバイスとしてエクスポートする場合。
  • aoe-toolsAOEネットワークブロックデバイスをインポートします。

宛先サーバーにパーティションテーブルを作成してから、宛先に合うようにソースパーティションを縮小する必要があります。 GRUBを新しいMBRに簡単にインストールできます。新しく作成されたパーティションテーブル上でパーティションだけを同期すると、エラーが発生しにくくなります。

受信側では、vbladeツールを使用してパーティションをエクスポートする必要があります。ソースサーバーでは、aoe-toolsをインストールした後にエクスポートされたデバイスを確認できます（aoe-discoverを実行してから/dev/ether/を確認してください。デバイス）。

次に、sourceドライブを使用してソースサーバー上にraid1デバイスを構築する必要があります。

mdadm --build /dev/md0 -n2 -l1 --force /dev/sda

この後、新しく構築されたミラーを調べることができます。

mdadm --detail /dev/md0
cat /proc/mdstat

この時点で、エクスポートされた宛先パーティションをこのミラーに安全にアタッチできます。

mdadm /dev/md0 --add /dev/ether/eX.Y

次に、同期の進行状況を監視します。

watch -n5 cat /proc/mdstat

同期が完了したら、ミラーを停止します。ソースサーバーでmdadm --stop /dev/md0、宛先サーバーでvbladeプロセスを終了し、2番目のサーバーでGRUB）をインストールし、IPアドレスを変更します。 、など。

実際、このトリックを使用すると、同期されたボックスを再起動するだけでダウンタイムが発生し、ほぼライブのボックス間でサーバーを移動できます。

パフォーマンス上の理由から、リンクのMTUを増やすこともお勧めします（または、可能であれば、ジャンボフレームを有効にして別のVLAN）を設定します）。

AOEの代わりにnbd-server/nbd-client（またはラフにしたい場合はiSCSI）のようなものを使用することもできますが、AOE（vblade + aoe-tools）非常にシンプルなインターフェイスと優れたパフォーマンス（TCP/IPオーバーヘッドなし）を備えています。

1
artyom