迁移国产ARM平台，雷真多！

这段时间想了想还有什么写的，今天这篇准备上干货，就着今年做过的信创平台ARM迁移适配项目，整体梳理下跨平台软件迁移工作流程。

从Intel迁移到ARM平台，最常见的麻烦在于指令集较少，而且不能直接使用，ARM的迁移工具不如原生丝滑，后期业务软件维护测试也存在不确定性。

做ARM迁移我大概需要以下五个步骤， 下面主要以Intel平台迁移到华为鲲鹏为例，协助相关做此工作的开发人员避坑以及遇到的问题进行叙述。

1.迁移前的准备工作—收集软硬件

配置方面一定要选好，基于之前的服务器，在选择CPU、内存、硬盘、操作系统等方面进行对齐，主要是CPU性能功能的对齐。比如CPU的主频、核心数、最高加速频、功耗等方面，比如用的服务器是Intel的6148，现在由于信创的替换，使用了华为鲲鹏920-5250这一款进行对标。因为Intel都有超线程/睿频功能，而鲲鹏ARM没有此功能，所以，按核心进行了对比，而6148的基频是2.4GHz（最高加速品率是3.7GHz），5250的基频是2.6GHz，基本上能进行对标。然后就是操作系统，网上下载了centos支持aarch64的版本，Openeuler的版本暂时作为后备替代使用。

2.迁移前分析—评系统软件栈制定方案

软件技术栈主要包括是否应用开源软件，编译型软件、JDK、软件相关的依赖库，其中OS自带的软件还好些，更换yum源之后，可以直接yum install解决。对于开源软件，需要获取适配了鲲鹏的源码进行下载编译，包括java/python，java和python编译的组件在迁移过程中还需要分析是不是引用了C的库文件或者是C编写的其中部分，并且JDK是否屏蔽与指令集相关的部分，如果是，这一部分需要进行重新编译和替换。另外对于引用的动态库文件也需要进行重新编译运行（C写的），去debug出现的错误。如果需要用到商用软件，不支持ARM指令集的话，先按功能先通过开源软件进行替代，搭建好环境之后先run一遍业务再进行后续推进。在编译器方面使用了支持鲲鹏ARM的GCC9.1版本，JDK使用了openjdk。

3.软件包的编译安装

由于ARM上层生态具有局限性，为了发展合作伙伴，华为也做了一个欧拉的开源社区，把国内的软硬件厂商拉进来，在ARM平台上做迁移适配，这样就扩大了生态，所以对于开源软件也可以去欧拉社区上去搜索。对于软件包的编译，基本上涉及到两种场景，一个是代码的迁移，不同编译型语言要做不同的修改，比如C/C++，需要进行重新编译，对于原应用的调用指令，鲲鹏ARM上没有，就要参考华为给的文档做相应替换。而对于编译好的rpm/deb包，需要查看依赖是否有问题，如果有问题也需要进行重构及替换。

4.性能调优

关于性能的测试，包含两方面，一个是基准benchmark测试，包括信创的测试项，SPECCPU2006计算性能测试、Stream内存带宽测试、LTP稳定性测试、Linpack计算性能测试，Netperf网络性能测试，Unixbench系统性能测试等。第二个就是业务应用系统的测试，主要是网络转发性能以及IO性能，数据库性能等。这方面的优化通常需要通过华为鲲鹏的人进行对接，但是回复起来也是慢慢悠悠，由于鲲鹏是NUMA架构，需要进行核心/内存绑定，也需要在内核策略上进行持续优化。

5.持续压力测试及后续运维

使用其他机器给鲲鹏ARM服务器加压（stress），在此过程中进行操作系统下各功能的监控，但是由于环境的改变，会遇到很多工具都不能进行使用，比如turbostat工具，用来监控在压力下每个core的频率等相关信息。目前只支持了intel/amd/hygon如图：

而且鲲鹏ARM是不支持pstate调频的，一般来说，在服务器idle或者逐渐加压的过程中，频率是逐渐上升的，而对于鲲鹏ARM来说，只有一个频率2.6GHz，而Intel的服务器是有多个频点的，在idle状态下会工作在最低频点，保证了服务器功耗最小，达到节能的效果，在运维过程中，通过使用cpupower也证明了鲲鹏ARM也是不支持的。

所以从绿色机房角度上来说，鲲鹏ARM的节能模式不符合标准，而且在全负载的时候也会超过热设计功耗，这对于机柜的功耗设计是一个坑，如果有涉及可以部分的小伙伴，那得注意了。