タグ: サーバ移設

こんにちは。
dd コマンドでディスクのデータを丸ごと吸い出して、GCP にサーバ移設を行う方法について検証してみたので備忘録を残しておきます。

前提として、AWS に構築した WEB / DB の仮想サーバ( EC2 )を、GCP に移設してみます。

1. 移設元

事前にデータを吸い出すディスクよりも大きなボリュームを EC2 にアタッチ / マウントしておきます。
あとは dd コマンドで吸い出すだけで OK です。
吸い出したデータは tar.gz で固めておきます。
※ デバイスファイル名は適宜変更してください。

fdisk /dev/xvdf
mkfs -t xfs /dev/xvdf1
mkdir -p /tmp/mnt
mount -t xfs /dev/xvdf1 /tmp/mnt
dd if=/dev/xvda of=/tmp/mnt/disk.raw bs=4M conv=sparse
cd /tmp/mnt
tar --format=oldgnu -Sczf /tmp/mnt/sanuki-source-wd01-compressed-image.tar.gz disk.raw

固めたデータは GCS ( Cloud Storage )にアップロードします。
方法はなんでも大丈夫ですが、gsutil を使うのが一番手っ取り早いかと考えます。
※ バケット名は適宜変更してください。

cd ~
curl https://sdk.cloud.google.com > install.sh
bash install.sh --disable-prompts
./google-cloud-sdk/bin/gcloud init
./google-cloud-sdk/bin/gsutil mb gs://sanuki-v2v-test-bucket01
./google-cloud-sdk/bin/gsutil ls
./google-cloud-sdk/bin/gsutil cp /tmp/mnt/sanuki-source-wd01-compressed-image.tar.gz gs://sanuki-v2v-test-bucket01/

2. 移設先

・Cloud Storage にアップロードしたファイルを元にイメージを作成しておきます。

イメージ > イメージを作成 > ソース : Cloud Storage ファイル > 作成

・作成したイメージから VM を起動します。
※ VM は sanuki-dest-wd01 という名称にしておきます。

VM インスタンス > インスタンスの作成 > ブートディスク : カスタムイメージ から 作成したイメージを選択 > 作成

…が、VM は正常に起動しません。

シリアルコンソールから VM に接続するとレスキューモードになっており、ログを漁ったところ、どうも File System が壊れているようです。

Feb 15 08:41:23 localhost kernel: XFS (sda1): Unmount and run xfs_repair
Feb 15 08:41:23 localhost kernel: XFS (sda1): First 64 bytes of corrupted metada
Feb 15 08:41:23 localhost kernel: ffff96cdf565fe00: 58 41 47 46 00 00 00 01 00 0
Feb 15 08:41:23 localhost kernel: ffff96cdf565fe10: 00 00 00 01 00 00 00 02 00 0
Feb 15 08:41:23 localhost kernel: ffff96cdf565fe20: 00 00 00 01 00 00 00 00 00 0
Feb 15 08:41:23 localhost kernel: ffff96cdf565fe30: 00 00 00 04 00 07 bf 6b 00 0
Feb 15 08:41:23 localhost kernel: XFS (sda1): metadata I/O error: block 0x1bff20
Feb 15 08:41:23 localhost mount[343]: mount: mount /dev/sda1 on /sysroot failed:
Feb 15 08:41:23 localhost systemd[1]: sysroot.mount mount process exited, code=e
Feb 15 08:41:23 localhost systemd[1]: Failed to mount /sysroot.
Feb 15 08:41:23 localhost systemd[1]: Dependency failed for Initrd Root File Sys
Feb 15 08:41:23 localhost systemd[1]: Dependency failed for Reload Configuration
Feb 15 08:41:23 localhost systemd[1]: Job initrd-parse-etc.service/start failed 
Feb 15 08:41:23 localhost systemd[1]: Triggering OnFailure= dependencies of init
Feb 15 08:41:23 localhost systemd[1]: Job initrd-root-fs.target/start failed wit
Feb 15 08:41:23 localhost systemd[1]: Triggering OnFailure= dependencies of init
Feb 15 08:41:23 localhost systemd[1]: Unit sysroot.mount entered failed state

3. 復旧

復旧用 VM を用意して、壊れたブートディスクをセカンダリとしてアタッチしリペアを試みます。

・ディスクだけ残し VM を削除します。

VM インスタンス > sanuki-dest-wd01 > 編集 > ブートディスク : 削除ルール : ディスクを維持 > 保存 > 削除

・リカバリ用の VM を作成して、壊れたディスクをアタッチします。
※ VM は sanuki-recover01 という名称にしておきます。

VM インスタンス > インスタンスの作成 > ブートディスク : 公開イメージ : CentOS7 > 作成

VM インスタンス > sanuki-recover01 > 編集 > 追加ディスク : 既存のディスクを接続 > sanuki-dest-wd01 : 保存 > 保存

・リカバリ用の VM に接続し、File System のリペアを試みます。
先に復旧対象のデバイスファイルを確認しておきます。
今回は /dev/sdb1 が対象になります。

[root@sanuki-recover01 ~]# lsblk
NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda      8:0    0   20G  0 disk
tqsda1   8:1    0  200M  0 part /boot/efi
mqsda2   8:2    0 19.8G  0 part /
sdb      8:16   0   30G  0 disk
mqsdb1   8:17   0   30G  0 part
[root@sanuki-recover01 ~]# ls -l /dev/disk/by-id/ | grep "sanuki-dest-wd01"
lrwxrwxrwx. 1 root root  9 Feb 15 11:40 google-sanuki-dest-wd01 -> ../../sdb
lrwxrwxrwx. 1 root root 10 Feb 15 11:40 google-sanuki-dest-wd01-part1 -> ../../sdb1
lrwxrwxrwx. 1 root root  9 Feb 15 11:40 scsi-0Google_PersistentDisk_sanuki-dest-wd01 -> ../../sdb
lrwxrwxrwx. 1 root root 10 Feb 15 11:40 scsi-0Google_PersistentDisk_sanuki-dest-wd01-part1 -> ../../sdb1

いきなり xfs_repair を行うと怒られました。
一度 マウント / アンマウント する必要があるようです。

[root@sanuki-recover01 ~]# xfs_repair /dev/sdb1
Phase 1 - find and verify superblock...
        - reporting progress in intervals of 15 minutes
Phase 2 - using internal log
        - zero log...
ERROR: The filesystem has valuable metadata changes in a log which needs to
be replayed.  Mount the filesystem to replay the log, and unmount it before
re-running xfs_repair.  If you are unable to mount the filesystem, then use
the -L option to destroy the log and attempt a repair.
Note that destroying the log may cause corruption -- please attempt a mount
of the filesystem before doing this.

適当にディレクトリを切ってから マウント → アンマウント → xfs_repair を行います。

mkdir /tmp/mnt
mount /dev/sdb1 /tmp/mnt
umount /dev/sdb1
xfs_repair /dev/sdb1

…正常にリペアできました。

[root@sanuki-recover01 ~]# xfs_repair /dev/sdb1
Phase 1 - find and verify superblock...
        - reporting progress in intervals of 15 minutes
Phase 2 - using internal log
        - zero log...
        - scan filesystem freespace and inode maps...
agi unlinked bucket 29 is 23389 in ag 13 (inode=54549341)
        - 11:45:46: scanning filesystem freespace - 16 of 16 allocation groups done
        - found root inode chunk
Phase 3 - for each AG...
        - scan and clear agi unlinked lists...
        - 11:45:46: scanning agi unlinked lists - 16 of 16 allocation groups done
        - process known inodes and perform inode discovery...
        - agno = 15
        - agno = 0
        - agno = 1
        - agno = 2
        - agno = 3
        - agno = 4
        - agno = 5
        - agno = 6
        - agno = 7
        - agno = 8
        - agno = 9
        - agno = 10
        - agno = 11
        - agno = 12
data fork in ino 50509395 claims free block 6314488
data fork in ino 50509395 claims free block 6314489
        - agno = 13
data fork in ino 54549341 claims free block 6818903
data fork in ino 54549341 claims free block 6818904
data fork in ino 54549341 claims free block 6818937
data fork in ino 54549341 claims free block 6818938
        - agno = 14
        - 11:45:47: process known inodes and inode discovery - 103104 of 103104 inodes done
        - process newly discovered inodes...
        - 11:45:47: process newly discovered inodes - 16 of 16 allocation groups done
Phase 4 - check for duplicate blocks...
        - setting up duplicate extent list...
        - 11:45:47: setting up duplicate extent list - 16 of 16 allocation groups done
        - check for inodes claiming duplicate blocks...
        - agno = 0
        - agno = 1
        - agno = 2
        - agno = 3
        - agno = 4
        - agno = 5
        - agno = 6
        - agno = 7
        - agno = 8
        - agno = 9
        - agno = 10
        - agno = 11
        - agno = 12
        - agno = 13
        - agno = 14
        - agno = 15
        - 11:45:47: check for inodes claiming duplicate blocks - 103104 of 103104 inodes done
Phase 5 - rebuild AG headers and trees...
        - 11:45:47: rebuild AG headers and trees - 16 of 16 allocation groups done
        - reset superblock...
Phase 6 - check inode connectivity...
        - resetting contents of realtime bitmap and summary inodes
        - traversing filesystem ...
        - traversal finished ...
        - moving disconnected inodes to lost+found ...
disconnected inode 54549341, moving to lost+found
Phase 7 - verify and correct link counts...
        - 11:45:47: verify and correct link counts - 16 of 16 allocation groups done
done

・リカバリ用 VM からディスクをデタッチします。

VM インスタンス > sanuki-recover01 > 編集 > 追加ディスク : 既存のディスク > sanuki-dest-wd01 : デタッチ > 保存

・リペアしたディスクからもう一度 VM を起動します。

VM インスタンス > インスタンスの作成 > ブートディスク : 既存のディスク : sanuki-dest-wd01 : 選択 > 作成

コンソールに接続します。
…接続できました。

serialport: Connected to fleet-acumen-286514.asia-northeast1-b.sanuki-dest-wd01 
port 1 (session ID: 99e0fefe92785865dd201bdc6865a89ae461aa77, active connections
: 1).
[   31.822303] APL|18307:18410:transport.c:1112:transport_device_release| INFO: 
detaching interceptors
[   31.838278] APL|18307:18410:tracepoints.c:99:tracepoints_detach| INFO: tracep
oints detached
[   31.847363] APL|18307:18410:syscall_common.c:149:detach_hooks| INFO: detachin
g syscall hooks...
[   31.856628] APL|18307:18410:syscall_common.c:186:detach_hooks| INFO: syscall 
hooks detached
[   31.865252] APL|18307:18410:syscall_common.c:213:syscall_hooks_detach| INFO: 
module_refcount()=1
[   31.874511] APL|18307:18410:transport.c:1117:transport_device_release| INFO: 
interceptors detached
[   32.305021] snapapi_init(modprobe,18440): Snapapi(v.0.8.8) init OK. Session s
ize 13784. Em size 990. Ctl major 245
[   32.351295] device-mapper: uevent: version 1.0.3
[   32.356843] device-mapper: ioctl: 4.37.1-ioctl (2018-04-03) initialised: dm-d
evel@redhat.com
[   32.390383] BIOS EDD facility v0.16 2004-Jun-25, 1 devices found
CentOS Linux 7 (Core)
Kernel 3.10.0-1062.12.1.el7.x86_64 on an x86_64

sanuki-dest-wd01 login: root
Password: 
Last login: Tue Feb 15 07:57:24 on pts/0
[root@sanuki-dest-wd01 ~]#

4. 終わりに

色々と躓きましたが、サーバの移設自体は可能なようです。
移設元が稼働していてデータの差分等が発生するのであれば、適宜 rsync 等でデータを同期してあげればよいですね。
一から移設先のサーバを作ってデータを同期するよりもお手軽かもしれません。