最近在做的事，简单来讲，就是一套系统差不多有10多台虚拟机，都是centos系统，版本主要是7.3、7.6、7.9，现在centos停止维护了，转为了centos stream，而centos stream的定位是：Red Hat Enterprise Linux (RHEL) 开发之前持续交付的发行版，作为rhel的上游，更新迭代比较频繁，不稳定，对于生产系统来说是无法接受的。
那就只能转其他系统，具体转哪种呢，选择是很多的，简单列几个我了解到的，和centos兼容性比较好，操作习惯也基本相同的操作系统，以下部分内容来自于大模型。
国际上来说的话，免费的主要有rocky linux、alma linux，这两个我看网页提到的比较多；有钱的话，可以直接买RHEL。
完全兼容RHEL： 由原 CentOS 创始人发起，与Red Hat Enterprise Linux（RHEL）实现100%二进制兼容，无缝迁移原有CentOS应用环境134。
长期支持：提供长达10年的更新周期（如Rocky Linux 9支持至2032年），社区驱动确保维护透明性259。
RHEL克隆版：与RHEL完全兼容，由CloudLinux公司赞助，承诺长期维护（如AlmaLinux 9支持至2029年）128。
其他我看到的提到的，还有oracle linux(https://www.oracle.com/linux/)、VzLinux、Springdale Linux。
国内来说，免费的话，就是两个：
背后是阿里，完全兼容CentOS生态：提供CentOS 7/8到Anolis OS的一键迁移工具，支持国产CPU架构（如鲲鹏、飞腾）。
openEuler （欧拉）
背后是华为，高性能与多架构支持：优化内核调度，适配x86、ARM架构，适用于服务器、云计算、边缘计算。
付费的话，操作系统我比较知道的是麒麟和统信，我们最近两年上的项目，基本要求从硬件到软件，都要信创，像服务端操作系统就是用的麒麟V10。
而统信，我了解不多，听说是一些桌面版操作系统在用，体验貌似一般。
我之前，有点奇怪，为什么运维同事最终会选择openEuler，技术上来说，感觉应该都还好，反正都是linux内核，从企业角度来说，为什么不选国外的rocky linux和alma linux，那自然是因为，一方面是信创要求，另一方面，是在出了难以解决的问题时，能寻求到技术支持，有时厂商还能帮忙背下锅。
选择国内的，为啥选了openeuler，而不是麒麟v10呢，那是因为麒麟v10是要收费的，能省点就省点呗。
那要免费，怎么选了openeuler而不是阿里龙蜥呢，我在查阅资料的过程中发现，麒麟V10，就是属于openEuler生态，银河麒麟V10服务器版基于openEuler社区的开源技术路线开发，其内核直接采用了openEuler的长期支持（LTS）版本。
这个在openeuler的官网就能看到：
https://www.openeuler.org/zh/download/commercial-release/
所以，我估计，运维也是考虑到之前已经用了麒麟V10，大家用着比较习惯了，所以这次就直接选了openeuler。
而在我这一两周用起来，感觉和用centos是一样的，感觉和RHEL系兼容还是挺不错。下面就开始介绍本次是准备怎么做迁移。
openEuler是一款开源操作系统。当前openEuler内核源于Linux，支持鲲鹏及其他多种处理器，适用于数据库、大数据、云计算、人工智能等应用场景。
目前的版本（2025年4月），有这几个(https://www.openeuler.org/zh/download/)：
openEuler 25.03，这个是社区创新版本，我们一般不选；
然后主要的LTS是下面这几个：
openEuler 24.03 LTS SP1
openEuler 22.03 LTS SP4
运维组选定的是openEuler 22.03 LTS SP4。
我看了下，白皮书的内容还比较详细，可以读一下。
额外说下，22.03就是表示是2022年03月发布的，但SP4不是这个时间发布的。
另外，在白皮书中，可以看到该版本中的linux内核版本是5.10.
https://www.openeuler.org/whitepaper/openEuler 22.03 LTS SP4 技术白皮书.pdf
openeuler也提供了迁移工具x2openeuler，可以看官网这里。
我画了个简单的图，说明下这个工具的大体架构。这个工具，你可以理解成一个后台管理系统，带界面，后台是python开发的，也带个数据库marial db。
工具要对目标主机升级的时候，先把目标节点的ip加进来（以及ssh相关用户名密码），
后续，python后台，就会通过ssh通道，传一些脚本到目标主机上执行，比如检查环境是否满足升级条件等等。
这其中，有个条件比较重要，就是目标主机需要配置一个yum源，其中需要提供openEuler操作系统的相关组件。
比如，我这边就给目标主机配置了一个yum源：
[openEuler-everything]
name=openEuler-everything
baseurl=https://repo.openeuler.org/openEuler-22.03-LTS-SP4/everything/x86_64/
enabled=1
gpgcheck=1
gpgkey=https://repo.openeuler.org/openEuler-22.03-LTS-SP4/everything/x86_64/RPM-GPG-KEY-openEuler
[openEuler-EPOL]
name=openEuler-epol
baseurl=https://repo.openeuler.org/openEuler-22.03-LTS-SP4/EPOL/main/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/update/x86_64/
enabled=1
gpgcheck=0
其他需要注意的，就是升级过程前，会检查目标主机的磁盘空间是否足够（因为需要从openEuler源下载各种软件的rpm），我当时在本地虚拟机测试，磁盘空间小了，检查一直通不过。
说下为啥最终怎么没选用工具升级，因为对这个工具的研究还是不太深入，而且时间有点赶。这个工具是原地升级，工具内部怎么实现的，是黑盒；另外，本次测试，升级完成后，我发现，内核参数还是差了很多（这应该很多也是正常的，因为原系统是centos7.3，而openEuler的linux内核都是5.10了，比centos7.3的内核版本高了不少）：
当时就是黑盒的感觉比较重，然后时间也比较赶，我们这个服务器上有哪些东西我们也比较清楚（上面还有些源码编译的软件，肯定是要重新装，没法迁移的，这个工具应该是只能迁移yum/rpm安装的软件）。另外，上线的时候，进行原地升级，我和运维同事认为，风险比较大，不如弄一台新的机器出来，完全重新部署一遍（当然原地升级，其实也可以在线上对原来的虚拟机先打个快照了再操作，有问题就回滚快照），到时候有问题，流量切回原来的centos主机就行。
计算线上的centos7.3服务器，进行过哪些变更，要尽量覆盖完全
那怎么才能知道有哪些差异呢，我们的方式是，我在本地弄了个虚拟机，从网上下载了centos 7.3 1611版本的iso，完全部署了一个全新的原始的centos 7.3.
然后在原始7.3和线上7.3上，执行各种内核配置、配置文件查看/导出的命令，然后进行对比，就能找出差异项来。
申请全新的机器，部署目标系统openEuler 22.03 LTS SP4，然后对前面计算出来的差异，逐一进行配置：包括操作系统级别、系统软件级别、业务软件级别的各种差异。
最终上线时，先把原centos机器的ip（ip1）改成其他的（临时ip），然后把openEuler的ip改成ip1，看看业务是否正常；如果有问题，就把openeuler机器关了，然后把centos机器的ip改回来，应该就能恢复正常。（可能需要考虑部分机器上有arp缓存）
我们大概整理了这样的文件（初版，不全），看看需要对哪些差异进行对比。其实，这也是最核心的部分，如果有遗漏，就可能会导致出问题。
当然，我们最终还会提交测试组进行业务测试，只要业务测试能通过，说明大的问题就没有。
最终整理的，比较全面的一个版本如下，通过对应的命令查看两边系统是否有差异，以下也部分涉及如何修改：
查看是否修改了内核参数。
sysctl -a
这个的差异会比较多，需要仔细看一下。部分差异是正常的，比如本地虚拟机的内存、磁盘空间大小、网卡名称、cpu个数不一致，都会导致一些内核参数的默认值不一样
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
/etc/profile
/etc/bashrc
~/.bashrc
[root@localhost ~]# getenforce
Enforcing (打开状态)
vim /etc/selinux/config
修改：
SELINUX=disabled
重启服务器后，再次执行：
[root@localhost ~]# getenforce
Disabled
systemctl status firewalld
systemctl stop firewalld
systemctl status firewalld
systemctl disable firewalld
设置ipv4
设置ipv6
设置dns服务器：
vim /etc/resolv.conf
设置本地hosts
vim /etc/hosts
vi /etc/crontab
vi /etc/passwd
vi /etc/group
查看内核模块并按字母序排序，方便对比
lsmod | tail -n +2 | sort -k1
cd /etc/yum.repos.d/
ll
swapon --show
cat /proc/sys/vm/swappiness
接下来，我们需要查看原系统通过yum、rpm等方式安装了哪些软件。
yum --setopt=history_list_view=commands history list all
rpm -qa --last
systemctl list-unit-files --type=service
我们在这里发现，运维组后期安装的很多agent（监控类的），所以这些也需要在新机器重新安装
设置时间校准服务
/etc/fstab 文件是 Linux 系统中用于定义和管理文件系统的挂载信息的配置文件
应用软件，如果涉及到c++相关的代码，就可能有这部分。我们正好涉及了，有两个动态库（so文件），是需要放到/usr/lib64下的，不然就会加载失败报错。
像linux下，动态库的默认路径有这么几个，所以大家要有这块的意识，别漏了：
linux下，有默认值，如上面这几个路径；另外，如果有设置LD_LIBRARY_PATH环境变量，那么java.library.path的值就等于默认的几个路径（/usr/lib64、/lib64、/lib、/usr/lib） + LD_LIBRARY_PATH的值。
如jdk、以及一些通过源码编译安装的程序（如nginx、redis这类）
各种业务软件，可能还涉及到在某些目录下写入了一些文件，可能也需要迁移，这个就大家自己看着弄了。
我们这边是会把软件全部在openeuler上再重新部署一遍，包括jdk、servlet容器等等。
最终就是上面的各项配置导到不同文件，然后beyond compare对比下。
这个没啥说的了，下载openeuler的iso，安装，然后分析上述对比出来的哪些差异，需要应用到新的系统中，然后执行就行了，最终执行完，可以重启下服务器，避免有的改了忘了使其生效。
可以发现，步骤还是比较繁琐的，而且，这样也不能保证万无一失，所以还是要进行充分的测试为宜。选这种方式，也要先做好方案，然后拉会评审，大家认可这样的方案才行，毕竟这个方案，需要运维、测试的全力配合，工作量也不小。
为什么还是选了这个方案，主要还是这次要升级的是其中接入层的两台机器（系统比较重要，上面部署了openresty等接入层服务，这种c程序，反正也要编译安装，没法自动迁移），所以要求稳，对黑盒迁移工具还不够了解，促使我们做了这个选择。
老的centos 7.3，运行了很多年了，这次从零开始部署，也能方便大家把相关组件摸清楚，在保证出现问题能及时回退的情况下，我们认为这样做也值得。后续面对不那么重要的系统，可能也是会用工具来升级。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。