物理服务器迁移至虚拟机

roamin9 posted @ 2009年7月23日 23:03 in 运维实践 with tags fsarchiver P2V sysrescuecd 备份 , 1712 阅读

        这几天一直在做一件事,要把众多的物理服务器,迁移至虚拟机中。这样做的目的是用来备份当前系统,当物理服务器的系统发生故障时,可以使用虚拟机中的备份系统,快速的恢复应用。而且,也可以为以后服务器的完全虚拟化做些铺垫。

        闲话少叙,来讲讲我几天实践的经验 :)


        实验前提:

                          物理服务器:OS:   RedFlag   2.4.21-9.30AXsmp   i686

                       

#cat /etc/fstab
LABEL=/      /      ext3   defaults    1 1
LABEL=/boot  /boot  ext2   defaults    1 2
LABEL=/opt   /opt   ext3   defaults    1 2
/dev/sda3    swap   swap   defaults    0 0

 

# df -h
/dev/sda2              14G  2.5G   11G  19% /
/dev/sda1              99M   13M   82M  14% /boot
/dev/sda5             252G  774M  238G   1% /opt

                              虚拟机:VMware GSX Server for linux 3.0

                              宿主OS:CentOS (系统无关紧要)

        所用工具:sysrescuecd,同版本RedFlag的恢复光盘


        一,备份物理服务器中的分区

                话说备份有很多种方式,我只是粗浅知道个大概,就不举例了,等有机会再说。

                这里我使用的工具是fsarchiver(需翻墙)。之所以用它,是因为:

                         1,它备份的是分区上实际使用的文件,而并不是整个分区。而且备份时可以选择压缩级别,大大节省了迁移后在虚拟机中使用的磁盘空间。

                         2,可以识别众多文件系统。(与上面的理由冲突么?)

                         3,可对备份恢复内容进行校验。

                         4,命令简单 :)

                         5,还原时可改变原物理服务器中的文件系统,例如ext3-->reiserfs。

                         6,可把多个文件系统备份到一个文件中去。哇哦

                  此工具包含在sysrescuecd中。用sysrescuecd启动物理服务器自不必多说,要注意的是,在备份过程中,备份的内容是不应该发生改变的!因此,对要备份的分区应该umount,或者mount read-only。

                  fsarchiver其实可以对mount的分区进行备份,但官方并不推荐,应该是还不稳定。如果真能实现,那就太cool了。

 

挂载/opt分区,此次实验中不备份/opt分区,用它只是来存储备份文件。

# mount /dev/sda5 /mnt/backup

备份分区

# fsarchiver savefs /mnt/backup/redflag-bootfs-ext2.fsa /dev/sda1

# fsarchiver savefs /mnt/backup/redflag-rootfs-ext3.fsa /dev/sda2

          

        二,传送备份的文件到VMware Server上去

                就是用scp。可惜fsarchiver不能把备份文件直接保存在NFS分区上,提示有错误(或者是我没搞对?)。不知道还有没有更简便的方法?

 

# scp /mnt/backup/redflag-bootfs-ext2.fsa user@host:/opt/fsarchiver/

# scp /mnt/backup/redflag-rootfs-ext3.fsa user@host:/opt/fsarchiver/

 

        三,获取虚拟磁盘大小

                之前说过,在VMware Server上我们要尽量节省空间,这样才放的下更多的物理系统。因此,我们先看看原来的物理服务器中,实际使用的磁盘空间是多少:

 

# fsarchiver archinfo ./redflag-bootfs-ext2.fsa

# fsarchiver archinfo ./redflag-rootfs-ext3.fsa

                /boot  使用了十几M,/root  使用了3G多空间。知道这些后,我们就可以着手在虚拟机中规划分区,并进行恢复了。

 

给虚拟机划分一块5G的硬盘,进行分区

#fdisk -l /dev/sda
/dev/sda1  /boot  50M
/dev/sda2  swap   500M
/dev/sda3  /      4G

 

 

 

        四,在虚拟机中进行恢复

                用sysrescuecd启动虚拟机,进行恢复。

 

恢复/boot分区,文件系统为ext2
# fsarchiver restfs redflag-bootfs-ext2.fsa id=0,dest=/dev/sda1,mkfs=ext2

恢复/分区,文件系统为ext3
# fsarchiver restfs redflag-rootfs-ext3.fsa id=0,dest=/dev/sda3,mkfs=ext3

                需要重新安装grub。

                当在sysrescuecd中chroot进入系统后,使用应用程序总会发生段错误,应该是和kernel与gcc的版本有关吧。无奈之下,只好使用了同版本的RedFlag恢复光盘,重新启动系统。不过这也带来一个好处,后面会说。

 

进入虚拟机中的系统
# chroot /dev/sda3 /bin/bash

重新安装grub
# grub
>>> root (hd0,0)

>>> setup (hd0)

>>> quit

此时,grub已经重新装在了这块硬盘的MBR上。

 

 

                修改/etc/fstab,以适应新系统的需要。

                兴奋的重启虚拟机,grub正常启动 :) 可在加载内核时,出现了“kernel panic”的错误,显示找不到根分区。肯定是磁盘控制器的驱动没有加载上,该动动initrd了。

 

        五,修改initrd.img文件

                此文件的来历及发展也很有趣,在内核2.4与内核2.6版本中的处理方法也不相同,留到以后有空再聊。现在的目标是让系统中的initrd文件尽快的能用起来。

                我们现在正在RedFlag的恢复光盘中,它为什么可以正常启动系统?显然,它在启动时加载了必须的驱动。我们此时只需要寻找到磁盘控制器的驱动即可。BusLogic: SCSI storage controller。就是他!

 

查看原来initrd.img的内容
# cp /mnt/sda3/boot/initrd.img /mnt/sda3/tmp/initrd.gz
# cd /mnt/sda3/tmp
解压
# gunzip initrd.gz
挂载
# mount -o loop initrd /mnt/sda3/tmp/init
现在就可以看到initrd.img的内容了
# ls /mnt/sda3/tmp/init
bin/ dev/ etc/ lib/ linuxrc* loopfs/ proc/ sbin sysroot/

 

 

                 现在,只需要把驱动拷贝到lib/目录中,并修改linuxrc文件,通知内核加载此驱动即可。

 

# cp /lib/modules/`uname -r`/kernel/drivers/scsi/BusLogic.o /tmp/init/lib

# vi /tmp/init/lib/linuxrc
      #增加必须的模块,去除不需要的模块
      insmod /lib/BusLogic.o

               好了,重新生成initrd.img

 

卸载initrd
# umount /tmp/init

压缩
# gzip initrd

覆盖
# cp initrd.gz /boot/initrd.img
 

                OK,重启……

                问题解决,在启动过程中,RedFlag会启动一个检测程序,检查硬件的变化,并自动配置。

                至此,迁移过程结束,物理服务器中的系统已经在虚拟机中跑的欢畅

 


        遗留的问题:

                              1,自动化处理。只有达到自动化,才有大量迁移的可能。

                              2,网段,光纤存储等问题。

                              3,资源分配问题。

         这次迁移只是一次实验操作,东拼西凑,其中很多地方做得不漂亮,可改进的地方还有很多。但思路应该大致就是这样,您有什么好办法,也说来听听

      

 

 

 

 

 

 

 

       

 

 

 

 

 

 

 


登录 *


loading captcha image...
(输入验证码)
or Ctrl+Enter