某政务云项目业务系统迁移调研最佳实践

某政务云项目业务系统迁移调研最佳实践

 

「知了Prophet」

主机详细信息调研工具
 

 

 

项目背景

 
 
 

某国家部委云平台项目自2020年中旬开始建设云平台,后期期望将全部VMware主机迁移至国产云平台内,但是由于虚拟机数量较大,系统调研工作迟迟未能完成,导致项目严重超期。从2021年6月介入该项目后,我们通过「知了Prophet」自动化调研工具,快速帮助用户完成业务系统调研工作,还通过”容灾渐进式“迁移的理念打消了用户在迁移前的顾虑,在不到1个多月的时间内,顺利完成了多套业务系统迁移工作,涉及虚拟机数量超过百台。本文重点介绍如何利用「知了Prophet」调研工具,完成自动化调研及系统信息梳理工作。
 

 

用户环境

 
 
 

客户本次要迁移的业务系统运行在以VMware为主的虚拟化平台上,VMware ESXi版本主要集中在5.1、5.5和6.5版本上,共计20台ESXi服务器,虚拟机数量1000台以上,分为业务区和DMZ区。

 

调研环境准备

【软-件-安-装】
 

1、准备运行环境

在ESXi上创建一台虚拟机,配置如下:

操作系统:CentOS 7.3

规格:2 CPU 2G Memory 40G

网络:能够访问vCenterESXi,443和902端口(TCP协议)

2、安装容器

登陆到系统内部,使用root容器安装Docker

wget https://download.docker.com/linux/static/stable/x86_64/docker-19.03.15.tgz

配置容器
 

setenforce 0

tar -zxvf docker-19.03.15.tgz

mv docker/* /usr/bin/ && rm -rf docker 

cat > /etc/systemd/system/docker.service <<-EOF

[Unit]

Description=Docker Application Container Engine

Documentation=https://docs.docker.com

After=network-online.target firewalld.service

Wants=network-online.target

[Service]

Type=notify

# the default is not to use systemd for cgroups because the delegate issues still

# exists and systemd currently does not support the cgroup feature set required

# for containers run by docker

ExecStart=/usr/bin/dockerd -H tcp://0.0.0.0:2375 -H unix://var/run/docker.sock

ExecReload=/bin/kill -s HUP

# Having non-zero Limit*s causes performance problems due to accounting overhead

# in the kernel. We recommend using cgroups to do container-local accounting.

LimitNOFILE=infinity

LimitNPROC=infinity

LimitCORE=infinity

# Uncomment TasksMax if your systemd version supports it.

# Only systemd 226 and above support this version.

#TasksMax=infinity

TimeoutStartSec=0

# set delegate yes so that systemd does not reset the cgroups of docker containers

Delegate=yes

# kill only the docker process, not all processes in the cgroup

KillMode=process

# restart the docker process if it exits prematurely

Restart=on-failure

StartLimitBurst=3

StartLimitInterval=60s

[Install]
 

WantedBy=multi-user.target

EOF

运行容器

systemctl daemon-reload

systemctl start docker

3、安装「知了Prophet」调研工具

docker pull \

  registry.cn-beijing.aliyuncs.com/oneprocloud-opensource/cloud-discovery-prophet:latest

4、运行容器

我们将/root目录映射到容器内部

docker run \

  --net host \

  --privileged=true \

  --name prophet \

  -v $HOME:/root \

  -dit \

  registry.cn-beijing.aliyuncs.com/oneprocloud-opensource/cloud-discovery-prophet:latest


 

系统调研
 

 【系-统-信-息-采-集】

1、进入「知了Prophet」容器

docker exec -ti prophet bash

2、扫描全网中活跃主机

扫描指定网络地址段内的主机,并进行记录,可以作为后续更详细信息采集的输入。扫描完成后,将自动在指定的/root路径下生成 csv 文件。

prophet-cli scan --host 10.1.0.43-62 --output-path /root

3、填写用户名/密码

将生成CSV文件回传本地,用Excel编辑,填写用户名/密码信息


 

CSV结构说明(填写标红字段必填项)

4、执行采集

填写完成后,将scan_hosts.csv文件传到宿主机/root目录下,就可以执行详细信息采集了,方法如下:

prophet-cli collect --host-file /root/scan_hosts.csv --output-path /root/

指令运行后,会有汇总性的信息,如果采集失败,则需要在日志中查询错误原因

===========Summary==========

Total 73 host(s) in list, Need to check 2 host(s), success 0 hosts, failed 2 hosts.

Failed hosts: ['[WINDOWS]xxx', '[LINUX]xxx']

============================

执行完成后,将在ouput-path中生成host_collection_xxx.zip文件,该文件就是采集后的打包文件。

 

【系-统-信-息-分-析】

对上一步运行的结果进行分析

prophet-cli report \

  --package-file /root/host_collection_20210804091400.zip \

  --output-path /root/

最后生成的analysis_report.csv就是分析后的文件,可以传输回本地,进行进一步分析,至此完成了全部信息采集工作。

 


总结
 

在本次调研工作中,脚本总运行时间在30分钟内,共调研出虚拟机数量1049,其中Window 582台,Linux 467台,CPU总数量 7734核,内存总大小19T,总存储容量为60TB。

在大规模系统调研中,自动化是必须的手段,而目前在迁移调研领域的工具少之又少,所以「知了Prophet」工具无疑是对系统调研准确性的最好的保障。

 

联系我们

 
 
 

现在,「知了Prophet」开源上线github,并同步至国内的gitee上。

Github地址:

https://github.com/Cloud-Discovery/prophet

Gitee地址:

https://gitee.com/cloud-discovery/prophet

我们希望,大家在使用过程的问题和新需求,都可以和我们提出来。大家可以在github上提交issue,或者加入我们的开发交流群,与我们一起共建Prophet。

内容推荐

从VMware到华为云Stack,迁移利器出鞘!

近日,澳大利亚公司Computershare因为VMware政策调整“喜提”10-15倍账单,不得不选择将2.4万台虚机从VMware迁移到其他虚拟化平台。&nbsp;正如外媒所说,此次事件只是个开始。面对暴涨的成本,绝大部分企业已经开始着手寻找其替代方案。从VMware到公有云、私有云还是超融合,客户因为行业、规模等背景不同,选择也各不相同,在选择目标平台时客户更关心迁移产品的效率和成功率问题,当然这其中也涉及到产品的兼容性以及自动化设计程度。&nbsp;华为云Stack(全称:HUAWEI

云迁移最佳实践:云迁移中存储资源池如何更换类型

编者荐语:用户前期把系统和数据盘都存储在SATA资源池,实际演练中发现SATA资源池内的主机运行过慢,需将数据盘移至SAS资源池,为了不影响整个迁移流程,团队决定直接修改卷类型,将用于数据同步的SATA卷通过底层同步至SAS资源池,不改变原有卷的id.以下文章来源于老孙正经胡说

先迁移,再调研——容灾渐进式迁移最佳实践

迁移通常是客户上云之前的最后一道门槛,对于集成商伙伴来说,云已经搭好了,最后上云一步往往难以跨越,这是为什么?&nbsp;业务系统分散在不同平台,IT人员缺失,老旧系统无人维护等,碰到这样的甲方客户,集成商往往都很难办,不得不投入大量的现场运维人员做前期调研,甚至请迁移厂商驻场,但这也意味着过程中会消耗大量的人力财力,且周期难以预测。这样巨大的迁移成本,让集成商对于提供云迁移服务望而却步,身边没几个咨询顾问,你都不好意思跟客户打招呼?!&nbsp;在对业务关联性没有充分调研的情况下,大干快上的迁

VMware到OpenStack备份容灾及其反向备份容灾解决方案

VMware与OpenStack在企业中应用广泛,HyperBDR作为云原生容灾工具,通过多种功能可实现它们之间高度自动化的异构平台备份容灾。