本帖最后由 Byte 于 2021-8-24 18:37 编辑
1.项目概况
接到一个需求,客户的业务部署在青云的云平台上,现在需要把青云上的业务迁移到深信服的acloud上。迁移过程中需要保证业务连段性不受太大影响。按照深信服的常规迁移方式,可以通过以下几种方式进行迁移
通过跟青云平台维护的沟通得知, 青云平台上无法直接导出虚拟机,所以第1种方式扑街
接下来准备尝试利用迁移工具进行迁移,由于客户的虚拟机都为Centos,需要挂载ISO镜像,重启进入ISO镜像后再使用迁移工具。但是 青云平台上面不允许用户直接挂载ISO镜像,所以第二种方法半扑街状态,后续想说把ISO文件下载到虚拟机本机里面,通过修改grub去直接引导ISO文件,奈何对grub不熟悉,尝试几次后,最终第二种方式全扑街。
最后第三种方式, 没钱,扑街。
那现在这个迁移就没办法做了?不,还是可以做的。深信服的acloud支持在创建虚拟机的时候,导入qcow2,VHD,VHDX格式的虚拟硬盘来创建虚拟机,这个时候我们只要把虚拟机导成qcow2等格式就能实现从青云平台迁移到acloud
但是青云平台侧没办法直接导出虚拟机,这个时候我们只能自给自足丰衣足食了,平台侧没办法导出,我们就从云主机侧进行操作,这个时候我们可以在虚拟机的系统里面 利用qemu-img这个工具把虚拟机的硬盘直接导成qcow2格式。然后再导入到acloud中即可。确定好方案后,下面就开始实操了。
2.迁移步骤 2.1 克隆虚拟机(青云) 首先为了保证在迁移过程中不影响现有业务运行,我们先把业务的虚拟机先克隆出来,后续所有操作都在虚拟机中进行
2.2 给克隆主机新加一块硬盘 给克隆出来的虚拟机每天添加一块硬盘,用于转换后的qcow2文件存放。
2.3 查看硬盘信息,确认需要转换的硬盘
通过上面命令可以看到硬盘vda挂载到/目录,vdb为swap分区,vdc挂载到对应的数据文件,也就是青云平台上的数据盘。所以我们现在需要把vda和vdc转换成qcow2文件,vdb后续直接在aCloud中创建。
2.4 修改青云虚拟机挂载信息修改/etc/fstab文件,剔除掉除系统所在盘的挂载信息(后续3.1节说明原因)如下图,我们把除系统盘外的盘的挂载信息给注释掉
2.5 安装qemu-img工具
2.6 格式化和挂载新增的硬盘
- fdisk -l # 通过命令可以看出 /dev/vdd 2T的硬盘是刚才新加的
- mkfs.xfs /dev/vdd # 格式化硬盘
- mount /dev/vdd /mnt #挂在到mnt目录
复制代码
2.7 转换硬盘- nohup qemu-img convert -f raw -O qcow2 /dev/vda /mnt/10.38.100.2.qcow2 &
复制代码
2.8 利用ssh端口转发上传qcow2文件到aCloud 由于aCloud配置在内部网络,没办法直接上传文件,正常情况下我们需要先把青云上的qcow2文件上传到内网的一台主机上,再通过内网上传到aCloud上,这样的话就需要2次的传输,那有没有办法说直接从青云上传到内网的aCloud中?
办法还是有的,我们先创建一台跳板机,使得跳板机可以连通aCloud内网和青云的网络,然后通过跳板机的SSH端口转发,实现从青云上连接跳板机然后将数据直接转发到aCloud上,这样就只要1次传输了。
1.在青云主机虚拟机上运行 - ssh -L 2222:10.210.X.X:22 root@112.X.X.X
- #格式 ssh -L 本地主机端口:远程主机:远程主机端口 跳板机账号@跳板机IP
- #相当于把本地主机的端口与远程主机的端口映射在一起,连接本地主机的端口相当于连接到远程主机的端口
复制代码
2.然后直接scp 就能把qcow2传到内网的acloud上
- scp -P 2222 /mnt/xxx.qcow2 root@127.0.0.1://sf/data/虚拟存储卷2/iso/xxx-qcow2/
复制代码
2.9 利用qcow2创建虚拟机
进入aCloud,点击新建虚拟机,点选磁盘1,选中右边的【已有磁盘】,然后选中刚才上传上去的qcow2文件。最后点击【确定】,然后等待平台创建完虚拟机,创建完成后即可开机。
新建虚拟机的过程根据qcow2的文件大小时间可能会比较漫长
2.10 迁移后的虚拟机调整按照上面方式迁移到acloud后,如果开机正常的话,后续还需要做几个操作
1.首先需要安装性能优化工具
- mount /dev/sr1 /mnt
- sudo sh /mnt/install.sh
复制代码
2.挂载数据盘,修改/etc/fstab文件
把系统盘挂载上去后,部分虚拟机还有其他数据盘,一同迁移过来后,用上面同样的方式添加给虚拟机后,还需要重新在虚拟机里面重新挂载下
- vi /etc/fstab
- #由于第二块添加的是数据盘,所以磁盘的路径是/dev/vdb
- #我们把之前取消前面注销掉的挂载条目,然后把/dev/vdc改成/dev/vdb
- #后续重启后就能自动挂载目录上去了
复制代码
3.修改IP与配置网络启动
迁移完成后,虚拟机需要配置成现网络IP,重启的时候 发现网络服务没有自动启动,导致IP没起来,所以我们配置下网络服务开机自启
3.遇到的问题
3.1 迁移完成后虚拟机开机黑屏
通过查看报错信息,发现系统启动卡在数据盘和缓存盘挂载上面,因为前期测试的时候没有只先导入系统盘,没有导入数据盘和缓存盘,所以虚拟机启动的时候,找不到这2个盘挂载,所以导致启动的时候卡住了。
后续我们在转换硬盘前,就可以先修改/etc/fstab文件,先把数据盘和缓存盘的挂载条目给注释掉,再去转换,转换完成后导入后开机就不会卡住了。(文章里第2.6节中的操作解释)
3.2 通过加载qcow2文件创建虚拟机,进度跑满后创建失败
在创建虚拟机的过程中,发现一个问题, 创建虚拟机进度到百分90多的时候,最后提示失败。任务描述是说:虚拟机磁盘镜像损坏或未知的磁盘镜像。
对比了上传到acloud的和青云虚拟机转换的qcow2文件的md5,md5是一样的,所以也不可能是上传的时候出现问题,而且同一个qcow2文件,有可能出现创建成功和不成功的情况,且都是进度跑完后才提示失败的。
所以如果遇到进度跑完后提示失败的话,可以多次尝试下,或者重新转换下硬盘再导入试试。
通过qcow2文件创建虚拟机的时候,平台会将qcow2转换成平台自己的虚拟机磁盘文件,存放的路径为虚拟机所在的目录:/所有存储/存储卷名称/images/cluster/xxx/xxx/xxxx.vm/
这里面的vm-diskN-qcow2文件就是aCloud平台使用的磁盘文件。
而如果我们通过上面方式迁移过来的时候,进度跑到100%后提示失败,这个时候 目录中会多了一个diskN.qcow2文件,但是这个文件又不能使用,虚拟机添加硬盘的时候,选中这个文件,也是无法使用。
假如我们通过青云转换后的qcow2文件在aCloud平台中创建虚拟机,失败了5次,成功了1次,那么aCloud虚拟机的配置中硬盘只会显示一个,但是这个目录下面会多了5个vm-diskN.qcow2(N=1到5)文件,只有vm-disk-6.qcow2是被使用的。
我不清楚平台对于这种失败导入的文件,没有被虚拟机使用的磁盘文件会不会自动删除,发现这个问题后,就 手动删除了这些冗余的磁盘文件,毕竟存储空间有限,不能过度浪费。
4.操作小技巧
4.1 利用nohup和&把进程放入后台运行
我们正常使用ssh客户端执行转换硬盘命令的时候,有时候硬盘的容量较大,转换的时间较长,期间如果不小心按照ctrl+c,进程就会收到一个SIGINT信号,从而中断程序运行。
或者说因为网络问题导致我们的ssh连接不小心中断了,这个时候中断就会向进程发送SIGHUP信号,从而中断我们这个seesion的各个作业。
以上2个情况都会导致我们转换的进度中断,然后又要重头开头。(当你经历过开十几个终端在转换硬盘的时候,因为办公网络突然中断,导致所有进度全部终止的时候,你就知道这个痛了。。。)
为了避免这种情况出现,我们在转换硬盘的时候 可以使用nohup 配合& 来使用,把进程放入后台执行
后续我们可以通过下面命令查看后台运行的进程状态
使用fg命令,又可以把后台进程调到前台执行
- fg 1 # 数字1 为执行jobs命令 看到的命令编号
复制代码
使用ctrl+z 可以把前台进程放到后台,并且处于暂停状态使用bg命令 可以把后台暂停的进程变成后后台继续执行
- bg 1 # 数字1 为执行jobs命令 看到的命令编号
复制代码
4.2 克隆虚拟机统一格式
为了不影响现网的业务运行,我们将所运行的虚拟机都克隆一份出来,所有操作都在克隆出来的虚拟机里面操作。
因为本次迁移的虚拟机数量较多,为此克隆完成后我们将虚拟机重置为同样的密码,所有克隆的虚拟机放置在同一个vpc里面,通过端口映射,按顺序把22端口映射出来。
这样我们在xshell里面就只要新建一个会话,然后复制出N份会话,最后只要修改端口信息即可,后续可以全选所有会话直接打开
4.3 利用xshell的撰写栏功能批量执行命令
由于上面迁移步骤,很多操作在每台虚拟机中都是一样的操作,这个时候我们把之前添加的所有ssh会话打开后,利用xshell撰写栏功能把需要执行的命令统一发送给所有ssh会话。
1.首先打开撰写栏,【查看】--【撰写】--【撰写栏】,这个时候软件最下面就会出现一个撰写栏
点击撰写栏左边的图标,选择【全部会话】,然后在撰写栏写入命令,回车后就可以在所有的会话中执行了
这样就能方便的进行批量的操作了。
5.总结
至此所有虚拟机迁移完后,后续等待客户测试下迁移后的环境运行是否正常,等待测试正常后,后续再找时间进行差异数据的同步,完成后即可把原青云的业务完整的迁移到aCloud上了。
本次项目由于涉及的数据量相对来说比较大一点,操作时间较长,合理利用一些软件的小技巧可以减少部分重复操作的时间。
|