centos迁移openEuler_centos停服，迁移centos7.3系统到新搭建的openEuler

[]]

近期所从事的工作，概括来说，涉及一套包含约十余台虚拟机的系统，这些均为操作系统，其版本主要为7.3、7.6和7.9，目前该系统已停止维护。与此同时，我们转向了另一种系统，该系统的定位是作为Red Hat Linux（RHEL）开发阶段的持续交付版本，位于RHEL之上，更新和迭代较为频繁，但稳定性不足，对于生产环境而言，这样的特性是无法满足需求的。

唯有转向其他系统，至于具体转向哪一个，可选范围颇广。不妨简单列举几款我有所了解的，它们在兼容性方面表现不错，且操作方式大致相同，其中一些信息摘自大型模型。

在全球范围内，免费的操作系统主要包括Rocky Linux和Alma Linux，这两个系统我在浏览网页时了解到提及较多；若资金充足，您可以直接购买RHEL。

与RHEL完全兼容，此项目由创始人倡导，确保与Red Hat Linux（RHEL）在二进制层面达到100%的兼容性，实现原有应用环境的无缝迁移，共计134项。

长期提供支持：涵盖长达十年的更新服务周期，例如Rocky Linux 9将持续支持至2032年；社区驱动的模式保证了维护工作的透明度，达到259标准。

RHEL的克隆版本：与RHEL保持完全一致，由企业支持，并保证持续更新服务（例如，对版本9的支持将持续到2029年）。

其他我看到的提到的，还有 linux()、、 Linux。

国内来说，免费的话，就是两个：

依托于阿里集团，全面适配生态系统：提供从7/8到OS的一键转换工具，并对国产CPU架构（例如鲲鹏、飞腾）给予支持。

关于操作系统，我较为熟悉的是麒麟和统信这两个品牌。在过去的两年里，我们参与的项目普遍要求硬件与软件均采用信创技术。具体到服务端操作系统，我们主要采用了麒麟V10版本。

关于统信，我所知有限，听闻它被某些桌面操作系统所采用，用户的使用感受似乎并不出众。

我先前感到有些不解，为何运维的同事们最终会作出这样的选择。从技术层面来看，大家的系统都是基于Linux内核，似乎并无太大差异。然而，从企业的立场出发，为何不选择国外的Rocky Linux和Alma Linux呢？这其中的原因自然是多方面的。一方面，是出于对信创要求的遵循，另一方面，则是考虑到在遇到难以解决的问题时，能够获得技术上的支持，甚至在某些情况下，厂商还能为我们承担一定的责任。

在国内品牌中，我为何选择了这款而非麒麟v10？原因在于麒麟v10需要额外付费，既然可以节省开支，何乐而不为呢？

为何不选择阿里龙蜥而是选择了免费版本？在我搜集资料的过程中了解到，麒麟V10属于生态系统的一部分，银河麒麟V10服务器版是基于社区开源技术路线开发的，其内核直接使用了长期支持（LTS）版本。

这个在的官网就能看到：

因此，我推测，运维团队可能考虑到之前已经采用了麒麟V10，大家对其使用较为熟悉，因此这次便直接选择了它。

在我近期的使用体验中，我发现其表现与之前并无二致，与RHEL系列的兼容性也相当良好。接下来，我将详细阐述本次迁移的具体操作步骤。

介绍

这是一款开放源代码的操作系统，其核心部分源自Linux，兼容鲲鹏以及众多其他处理器，能够满足数据库、大数据处理、云计算以及人工智能等多个领域的应用需求。

目前的版本（2025年4月），有这几个()：

25.03，这个是社区创新版本，我们一般不选；

然后主要的LTS是下面这几个：

24.03 LTS SP1

22.03 LTS SP4

运维组选定的是 22.03 LTS SP4。

我看了下，白皮书的内容还比较详细，可以读一下。

额外补充，22.03代表的是2022年3月份的发布日期，然而SP4并非在那时推出。

此外，查阅白皮书内容可知，该版本所采用的Linux内核版本号为5.10。

22.03 LTS SP4 技术白皮书.pdf

迁移方式之迁移工具

也提供了迁移工具，可以看官网这里。

我绘制了一张简易的图表，用以阐述该工具的基本框架。此工具本质上是一个具备界面的后台管理系统，其后台部分负责开发，并且还配备了一个数据库，即 db。

在进行工具对目标主机的升级操作前，需先将目标节点的IP地址添加至配置（同时包括相应的SSH用户名和密码）。

之后，系统后台将通过SSH连接，向目标主机传输并执行一系列脚本，例如，检测环境是否满足升级所需的各种条件。

在此过程中，有一个关键条件必须满足，即目标主机必须设置一个yum源，并且该源需包含操作系统所需的各种组件。

比如，我这边就给目标主机配置了一个yum源：

  
  

   
   Copy
  
  
[openEuler-everything]
name=openEuler-everything
baseurl=该链接指向openEuler-22.03-LTS-SP4版本中，位于everything目录下的x86_64架构的软件资源。
enabled=1
gpgcheck=1
gpgkey=请访问该链接以获取openEuler 22.03 LTS SP4版本中x86_64架构的RPM-GPG-KEY文件。
[openEuler-EPOL]
name=openEuler-epol
baseurl=该链接指向的是openEuler-22.03-LTS-SP4版本中EPOL主目录下的x86_64架构的软件资源。
enabled=1
gpgcheck=0
[openEuler-2203-lts-sp4-update]
name=openEuler-2203-lts-sp4-update
baseurl=请访问https://repo.openeuler.org/，在openEuler-22.03-LTS-SP4更新库中，找到x86_64架构的相关资源。
enabled=1
gpgcheck=0

在升级流程开始之前，我们必须确认目标主机的磁盘容量是否充裕（考虑到安装过程中需要从源头下载多种软件的rpm包），在我对本地虚拟机进行测试时，由于磁盘空间不足，检查环节始终未能通过。

解释一下为何最终没有选择使用工具进行升级，原因在于对这款工具的研究还不够充分，同时时间上也显得有些紧迫。该工具属于就地升级类型，其内部实现机制是个黑盒；此外，在完成升级后，我发现内核参数仍有较大差距（这种情况或许也是正常的，因为原系统版本为.3，而当前使用的Linux内核已经是5.10，相较于.3版本，内核版本有了显著提升）：

当时给我的感觉就像是面对一个黑盒子，而且时间紧迫，至于我们服务器上具体有哪些内容，我们心里有数（上面存放着一些需要重新安装的源码编译软件，显然无法进行迁移，而这款工具似乎仅支持yum/rpm安装的软件进行迁移）。此外，在系统上线阶段，我们选择原地升级，但我和运维团队成员都认为这样做风险较高。我们提议，不如购置一台新机器，从零开始进行全面部署。当然，原地升级也可以采取先对线上原有虚拟机创建快照，然后进行操作的方法，一旦出现问题，即可通过回滚快照来恢复。如果部署过程中出现故障，我们可以将流量切换回原有主机处理。

最终的升级思路 升级步骤--差异计算

我们大致浏览了这份文件（系初稿，内容尚不完整），并思考了哪些差异需要我们进行细致对比。实际上，这部分内容至关重要，一旦有所疏漏，便可能引发问题。

自然，我们最终还需将测试团队纳入业务检验流程，一旦业务检验顺利过关，便可证明整体上不存在重大问题。

经过精心整理的，内容相对较为全面的版本中，可以通过执行相应的指令来检查两个系统之间是否存在差异，同时其中也部分说明了如何进行修改操作。

os层面 /etc/.conf

查看是否修改了内核参数。

-a

  
  

   
   Copy
  
  
sysctl -a 
这种差异相对较大，需要我们逐一审慎观察。其中，有些差异是符合常理的，例如，本地虚拟机的内存容量、磁盘存储空间、网络接口卡名称以及CPU核心数量等方面的不同，都可能导致内核参数的预设值存在差异。

lang/

  
  

   
   Copy
  
  
echo $LANG
vim /etc/locale.conf
如果有变更，则需要修改，如改成中文：
可先查看支持的中文locale：
[root@localhost ~]# locale -a|grep zh_CN
zh_CN.utf8
vim /etc/locale.conf
LANG="zh_CN.utf8"
刷新：
source /etc/locale.conf
[root@localhost ~]# echo $LANG
zh_CN.utf8

环境变量

  
  

   
   Copy
  
  
/etc/profile
/etc/bashrc
~/.bashrc

  
  

   
   Copy
  
  
[root@localhost ~]# getenforce
Enforcing (打开状态)
vim /etc/selinux/config 
修改：
SELINUX=disabled
重启服务器后，再次执行：
[root@localhost ~]# getenforce
Disabled

  
  

   
   Copy
  
  
systemctl status firewalld
systemctl stop firewalld
systemctl status firewalld
systemctl disable firewalld

ip、dns cron

  
  

   
   Copy
  
  
vi /etc/crontab

user

  
  

   
   Copy
  
  
vi /etc/passwd
vi /etc/group

内核模块

查看内核模块并按字母序排序，方便对比

  
  

   
   Copy
  
  
lsmod | tail -n +2 | sort -k1

repo

  
  

   
   Copy
  
  
cd  /etc/yum.repos.d/
ll

swap

  
  

   
   Copy
  
  
swapon --show
cat /proc/sys/vm/swappiness

软件

我们接下来必须检查原系统，看看它通过yum、rpm等工具安装了哪些应用程序。

yum

  
  

   
   Copy
  
  
yum --setopt=history_list_view=commands history list all

rpm -qa --last

  
  

   
   Copy
  
  
rpm -qa --last

  
  

   
   Copy
  
  
systemctl list-unit-files --type=service 

在此地，我们注意到运维团队在后期部署了众多监控类agent，因此，这些组件在新的设备上同样需要重新进行安装。

ntp

  
  

   
   Copy
  
  
设置时间校准服务

nfs挂载

  
  

   
   Copy
  
  
在 Linux 操作系统中，负责存储和配置文件系统挂载信息的文件是 /etc/fstab。

动态库路径

若软件中包含C++相关代码，则可能包含此类内容。恰巧，我们项目中也涉及了这一部分，具体包括两个动态库（即so文件），这些库文件必须放置于/usr/lib64目录中，否则将导致加载失败并出现错误提示。

在类似Linux的操作系统中，动态库的预设存放位置包括数个特定路径，因此，大家对此应有足够的认识，以免出现遗漏。

在Linux系统中，存在一些预设的路径值，例如前述的这些路径；此外，若已配置环境变量，则java.path的设定将等同于这些预设路径（包括/usr/lib64、/lib64、/lib、/usr/lib）与相应变量值的组合。

基础软件及业务软件

例如，Java开发工具包（JDK）还有众多通过源代码编译并安装的应用程序，诸如nginx和redis等。

文件、文件夹对比

各类业务软件或许在特定文件夹中存有文件，或许还需进行迁移，具体操作请大家自行处理。

我们这边会进行全面的软件更新，重新部署所有相关组件，诸如Java开发工具包（jdk）以及容器等。

差异对比

最终就是上面的各项配置导到不同文件，然后 对比下。

差异执行

这个环节无需多言，只需下载ISO镜像，完成安装步骤，接着对之前对比得出的差异进行分析，确定哪些需要在新系统中实施，随后进行操作。操作完成后，不妨重启一下服务器，以防某些更改虽已实施却未及时生效。

总结

步骤相对复杂，且无法确保绝对无误，因此进行彻底的测试是更为妥当的选择。采用这种方法，首先需制定详尽的计划，接着召开评审会议，确保大家对此方案达成共识。毕竟，这个方案的实施需要运维和测试团队的紧密协作，工作量同样不容小觑。

之所以依然决定采用该方案，关键在于此次升级涉及的是接入层中的两台设备（这些系统至关重要，承载了众多接入层服务，且涉及c程序，自然需要编译和安装，无法实现自动迁移），因此稳定性至关重要。加之我们对黑盒迁移工具的了解尚浅，这也是我们做出这一决策的主要动因。

这款7.3版本的系统已经运行了多年，此次我们决定从头开始进行部署，这样做不仅有助于大家深入了解相关组件，还能确保在遇到问题时能够迅速进行回退。我们相信，采取这种方式是值得的。对于后续那些不那么关键的系统，我们或许也会考虑使用工具进行升级。

博客分类指引贴：这是我们的博客目录导航，邀请大家一同学习，内容将持续更新。

我是逐日，曾供职于华为和腾讯，如今在成都的一家小公司过着悠闲的生活，欢迎关注我的公众号，记得时常查看，我会不定时更新；此外，你还可以在页面右下角找到加号图标，那是我们博客园的入口。

原创作者: grey-wolf 转载于: