全面升级！龙蜥自动化运维平台 SysOM 2.0 可支持操作系统一站式迁移

1.png.JPG

文/系统运维SIG

CentOS 项目将停止维护，企业和个人用户都面临着大量的 CentOS 操作系统更新、维护、系统迁移等问题。对于迁移的过程，若通过手动方式进行不仅效率低下，还存在无法标准化、无法原地迁移等问题，也将耗费大量人力和资源，这显然是不现实的。如何解决依靠工具实现一站式的从迁移的评估、迁移实施到迁移后的优化问题迫在眉睫。

基于此，龙蜥社区正式推出围绕操作系统迁移和运维的自动化运维平台 SysOM 2.0 版本，此次升级从架构到核心功能都做了优化升级，包含三个核心能力：操作系统迁移、全面升级的诊断中心和整体架构的升级。SysOM 2.0 将为用户提供包括迁移评估、迁移工具、迁移前后的对比和系统优化在内的完整迁移功能，保障了用户从迁移到运维的操作系统管理闭环。围绕迁移场景，SysOM 2.0 还在监控中心、诊断中心等模块丰富了相关的功能，使操作系统的运维体验进一步提升。

01 操作系统迁移

还在为 CentOS 停服不知道该换什么、能不能换、怎么换、换了之后系统会不会出问题而烦恼吗？SysOM 2.0 新增的“操作系统迁移”功能可以给你答案。SysOM 2.0 支持 CentOS 7 和 CentOS 8 全系操作系统迁移到龙蜥操作系统（Anolis OS） 7 和 8 版本，为用户提供简单可视化的界面来完成一站式的迁移工作。

SysOM 2.0 操作系统迁移模块功能点包括：迁移评估和迁移实施。支持原地迁移和批量迁移，来解决用户机器的规模庞大，无法进行轮转的问题。支持对迁移后系统的异常进行诊断分析和系统调优。

迁移评估：在操作系统进行迁移之前，通过自动化的迁移评估功能，用户可以了解迁移后的 Anolis OS 对原有系统的兼容性，包括软件兼容性和硬件兼容性，同时会为用户提供详细的兼容性报告，为后续迁移到 Anolis OS 做充分的信息决策的准备。

迁移评估功能包括：

迁移风险评估，针对操作系统进行全面的迁移操作风险评估。
系统评估，针对迁移前后系统内置环境变量、服务命令、内核系统调用等等系统级配置进行评估。
硬件评估，针对系统硬件信息和板卡信息进行评估。
应用评估，针对系统已安装的应用进行兼容性评估。

（图/迁移评估）

（图/迁移评估报告）

迁移实施：当用户完成迁移评估之后，可以通过迁移实施的界面操作来完成系统迁移。为了避免在迁移过程发生意外或迁移结果不如预期，用户可以通过界面提前进行系统备份。迁移实施功能支持单机迁移和批量迁移，支持单步迁移和一键迁移，支持备份还原和离线迁移等功能。

迁移实施流程包含：

实施配置，针对实施配置的一些操作。
系统备份，如果有需要则会对当前系统进行备份。
环境准备，迁移前的环境准备和工具部署。
风险评估，实施迁移会进行一次风险评估。
迁移实施，当风险评估通过之后，将执行系统迁移操作。
重启机器，迁移实施完成之后需要重启机器，当机器重启成功后，系统切换为 Anolis OS，标志着本次系统迁移完成。

如果用户对系统进行了备份，可以随时使用系统还原功能将当前系统还原为未迁移的状态。

（图/批量迁移实施）

（图/迁移实施）

02 监控中心

SysOM 2.0 新增迁移监控报表功能，该项功能对迁移前后系统的资源总额使用情况、基础指标变化趋势以及指标波动等进行采集和可视化展示，可以让用户更加直观地感受迁移前后，操作系统的变化情况。同时，通过在迁移前后运行一段时间测试任务，可以对实际业务在两种操作系统上运行的性能有一个直观的对比效果。

资源变更监控

迁移监控会对迁移前后常用资源的变更情况和变更趋势进行可视化展示，可以直观的对比迁移前后系统的资源变更情况。

（图/迁移监控）

基础指标监控

同时迁移监控会对常用指标（CPU、内存、网络、IO、磁盘）进行监控，对每个指标的实时值、变化趋势、以及波动幅度进行可视化展示，可以直观的对比迁移前后各个指标在时间维度上的波动情况。

（图/基础监控）

03 诊断中心

SysOM 2.0 提供调度、存储、网络、内存等全方位的诊断，帮助操作系统用户进行全方位的问题排查和定位。新增诊断功能：调度抖动诊断、IO 时延分析、IO hang 诊断、网络丢包诊断、网络抖动诊断、网络重传诊断、内存 Cache 分析、内存 OOM 诊断和支持自定义命令下发功能。

调度诊断中心

调度抖动诊断：在系统运维场景中，CPU 长时间在 sys 态执行，导致用户态程序得不到调度；系统长时间关中断，导致 CPU 无法正常接收 TICK 中断、引发调度抖动问题。这两种情况下往往伴随着业务进程突发调度延迟，甚至系统短暂 hang。调度抖动记录了调度抖动发生的时间点、发生的次数、和抖动的具体数值，来帮助用户更好的定位该场景下发生的问题。

存储诊断中心

IO 时延分析：IO 高延迟一般意味着 IO 性能瓶颈，如 IO 流量太多、积压，达到存储设备瓶颈或者存储设备异常、OS 存储栈异常等等，造成 IO 请求处理慢、IO 延迟高。该项监控每个存储设备的历史 IO 延迟水位，统计每分钟访问的 IO 延迟异常偏离历史水位的次数，可以快速定位出 IO 延时最大消耗在哪一层级，方便定位问题。

IO 流量分析：系统 IO 流量过高、IO 打满磁盘，容易引起 IO 资源的争抢而导致有 IO 需求的用户进程阻塞，出现这种情况，一般意味着 IO 资源没有得到合理的分配，让某些进程占据了超出预期的大量 IO 资源。该项监控每个存储设备在进程级别的 IO 资源（如 iops、吞吐）占用情况，并且能够分析出资源占用最大的进程，方便定位问题。

IO hang 诊断：IO hang 对于系统来说可谓灾难，及时发现，并将 IO 流量切换到正常的存储设备上，隔离异常的存储设备非常重要，该监控项监控系统每个存储设备的 IO 访问路径上是否存在 IO hang 问题。

网络诊断中心

网络丢包诊断：丢包诊断通过监控记录丢包的事件、丢包的硬件或网卡设备、丢包点和次数以及丢包原因。帮助用户诊断定位网络丢包的问题。

网络抖动诊断：抖动诊断目前支持 icmp 报文。其包含两个部分，一个是 ping 发起端的报文时延，即发送报文路径，另外一个是 ping 接收端的报文时延，即接收报文路径。

网络重传诊断：重传诊断通过记录重传的时间、IP、TCP socket 所处的状态和拥塞状态，帮助用户了解网络重传发生的情况。

内存诊断中心

内存 Cache 分析：内存 Cache 分析功能用于解析系统中或容器组和容器内部文件缓存和共享内存对应的文件，以及文件缓存活跃和非活跃的占比。

内存 OOM 诊断：OOM(Out of memory)是生产环境中常见的异常，当 OOM 发生时伴随着大量内核日志，而这些内核日志往往难于分析。该诊断可以帮助用户定位系统 cgroup 发生定位内存泄漏、cpuset、mempolicy 的原因等设置不合理导致的 OOM。

自定义诊断中心

命令诊断：考虑到运维人员诊断问题时会有各种各样的场景，而这些场景有可能是SysOM现有的一些诊断功能无法精确覆盖到的，因此新增了一个命令诊断功能，支持用户像平常终端输入命令一样，自定义输入自己需要的命令，然后可以查看返回的结果。

04 整体架构升级

SysOM 1.0 架构设计适用于在单机上部署全量功能，可以一键式集成主机管理、主机监控、主机诊断、宕机分析和安全检测等强大的运维功能。随着 SysOM 在多个场景的落地以及开源社区的热度升高，功能的新增和管理规模的增长对 SysOM 的架构设计提出了新的需求：

支持大规模场景。
支持快速功能扩展。

针对上述需求，SysOM 2.0 对整体的架构设计进行了全面升级，使整个平台可以更加灵活快速的部署和接入新的服务：

1. SysOM 将后端各个组件微服务化，实现部署分离，在大规模场景下支持分布式容器化部署，并且可以根据各个微服务的负载对指定微服务进行水平扩容。

2. SysOM 引入通用事件中心（Common Event Center，CEC）支撑微服务间的异步通信，促进微服务间的解耦，保证高内聚、低耦合、职责单一、关系清晰，同时可插拔式的设计可以兼容各种类型的消息队列（Message Queue，MQ）技术，在不修改代码的情况下在多种MQ之间灵活切换。

3. SysOM 提供了统一的通道能力，各个微服务可以使用通道 SDK（Channel SDK）对节点（Node）进行命令执行、文件下发和文件下载等功能，其插拔式的设计可以快速支持各种不同类型的通道，并且通道微服务采用全异步编程，大大提升了并行处理能力。

（图/SysOM 2.0 架构图）

05 使用实践

下载 rpm 包

wget https://gitee.com/anolis/sysom/releases/download/v2.0/sysom-2.0-1.an8.x86_64.rpm

安装 rpm 包

rpm -ivh sysom-2.0-1.an8.x86_64.rpm
# 或 yum install -y sysom-2.0-1.an8.x86_64.rpm

默认安装路径为 /usr/local/sysom 下
默认配置使用的 nginx 对外端口为 80，可以通过 export SERVER_PORT=xxx 来设置
默认配置的内网IP是通过 ip -4 route 命令查找的第一个 IP，可以通过 export SERVER_LOCAL_IP=xxx.xxx.xxx.xxx 来设置

启动

# 使用以下命令进行启动:
bash -x /usr/local/sysom/init_scripts/server/init.sh

当服务日志输出下列日志表示部署成功：

Oct 10 12:58:51 mfeng bash[3217754]: /usr/local/sysom/init_scripts/server
Oct 10 12:58:51 mfeng bash[3217754]: + for dir in `ls`
Oct 10 12:58:51 mfeng bash[3217754]: + '[' -d init.sh ']'
Oct 10 12:58:51 mfeng bash[3217754]: + for dir in `ls`
Oct 10 12:58:51 mfeng bash[3217754]: + '[' -d stop.sh ']'
Oct 10 12:58:51 mfeng bash[3217754]: + sed -i 's/^FIRST_INIT_DONE=0/FIRST_INIT_DONE=1/g'     /usr/local/sysom/init_scripts/server/init.sh