龙蜥社区及阿里云CentOS迁移方案|飞天技术沙龙-CentOS 迁移替换专场
内容介绍
1.背景介绍
2.方案选型
3.迁移支持
非常高兴今天有这个机会与大家一起探讨关于 CentOS 迁移的相关话题。其实刚才前面的同学已经介绍过了，无论是从龙蜥社区的角度，还是针对整个阿里巴巴 CLB Linux 云上的 CentOS 用户，其目标都是致力于帮助 CentOS 的用户进行国产化迁移或相关操作系统的迁移，努力确保大家能够平稳地将业务迁移到新的操作系统上。
其实在整个迁移方案中会从两个角度来进行阐述。首先从整体方案的角度出发将探讨如何选型，比如选择哪种方案来帮助大家进行迁移或升级操作系统。其次从社区的角度介绍为大家提供的支持。在阿里云平台上不仅提供了标准的产品来帮助大家进行迁移，还如刚才小贾提到的在云端配备了专业的技术团队，以解决大家在迁移过程中遇到的各种问题。致力于为用户提供端到端的服务，以解决 CentOS 替换中的一切难题。
01.背景介绍
关于 CentOS 停服的背景，相信今天来参加这个沙龙的各位已经非常熟悉了。因此将简要介绍一下：从 2003 年开始， CentOS 发布了它的第一个版本。
CentOS 实际上是基于上游的 Red Hat 红帽操作系统免费发行的一个版本，旨在让广大用户能够享受到 Red Hat 的一些特性。在 2014 年， Red Hat 收购了 CentOS ，然后在 2019 年， IBM 又收购了 Red Hat ，这主要是为了进军整个企业云市场。次年 Red Hat 宣布了基于 CentOS 7 的停服消息。关于停服的节奏，相信大家已经比较了解了。 CentOS 在 2021 年 12 月 31 日已经停服，而 CentOS 7 也将在今年，即 2024 年 6 月 30 日全面停服。这对所有 CentOS 用户的影响是非常大的。
基于 Red Hat 宣布的停服消息，同时他们也为用户提供了一个解决方案。这个解决方案正如上边所展示的图表一样，针对整个 CentOS 用户群体。红帽的指导建议是，对于测试和开发相关的业务，可以迁移到 CentOS Stream 上；而对于生产系统，红帽则建议迁移到其收费版本，即 Red Hat Enterprise Linux 上。
关于 CentOS Stream ，可能有些朋友还不太了解。它实际上是将原本基于 Red Hat 下游的 CentOS ，转变为 Red Hat 上游的一个滚动发行版本。这就意味着 CentOS Stream 是一个相对不稳定的版本，对企业的可靠性和安全性带来了相当大的挑战。
在面对红帽推荐的操作系统选择时还有一个选择，那就是是否继续留在 CentOS 这个操作系统上。然而这个方案也伴随着诸多隐患。其中最大的隐患就是操作系统无法再进行升级，包括 CVE 通用漏洞披露和安全相关的更新，以及系统 Bug 的修复，都无法再获得安全补丁和漏洞更新的支持。这对业务的影响是非常大的。正如杨勇老师一开始所介绍的，企业对安全水位的要求在不断提升。在这个背景下如果继续使用 CentOS ，那么对于业务的数据安全和合规性都将面临巨大的挑战。
从数据上来看，目前国内的 CentOS 用户群体仍然非常庞大。根据去年 IDC 发布的服务器操作系统报告，国内 CentOS 的市场占有率仍保持在 20% 以上，这意味着国内有近 350 万套 CentOS 系统仍在持续运行中。因此这对于整个企业界来说，压力是相当大的。除了技术和选择方案上的考量，国内政策也在积极推动 CentOS 迁移活动。政府已经意识到这样的风险，包括操作系统厂商在内的多方都提出了相应要求。例如开源社区的一些产品发行版要求具有 CentOS 兼容性，并且鼓励使用国内的自主平台创新操作系统。这是政策层面对操作系统厂商的要求。此外对于一些重点单位，政策也倾向于促使它们尽快迁移到国产操作系统上。
02.方案选型
接下来将讲述在 CentOS 迁移过程中面临的一些方案选型问题。实际上市面上很难找到一种能够全面解决企业所有迁移问题的方案。
因为企业内部的业务应用实际上是多种多样的，对于不同的应用可能需要采用不同的迁移方案。因此对于企业而言，无论是企业内部还是外部，都需要先对自己的应用或业务进行细致的划分。不同的应用和业务可能适用于不同的迁移场景。这一部分工作可能需要丰富的经验和指导。所以无论是开源社区还是阿里云等平台，其实，在见过众多企业的迁移方案和痛点后都总结了一些值得考虑的方面。第一方面是需要对整体业务场景进行分类。在这里们将业务场景的诉求分为了三类，分别占据了业务场景比例的 20% 、 30% 和 50% 。
实际上在最底层的 50% 业务场景中，大部分企业的业务连续性要求并不高，例如测试或开发环境。在切换这些环境时可能并不严格要求其具备高度的平滑性或连续性。同时这些业务在技术实现上相对简单，可能只是运行一些 Java 应用。因此对于这类业务场景更推荐用户使用社区提供或云平台上的一键迁移工具来解决迁移问题。
第二类问题是业务对稳定性有一定诉求，同时技术实现相对简单，适配工作也不算复杂。但在这类业务中，对稳定性的要求相对较高。因此对于企业的这部分业务，如果在迁移过程中出现问题，需要能够及时回滚，并确保在迁移整个过程中业务不受影响，例如避免数据或配置信息的丢失。针对这种业务场景更推荐用户使用商业衍生版本或通过比较稳定的社区版本，采用成熟的整体迁移方案来完成迁移工作。
最上面的一类业务场景，是对整个业务和迁移过程要求最高的。这类业务场景无论是对稳定性、业务连续性，还是业务复杂度，都有着极高的要求。特别是在技术栈非常复杂的情况下，例如底层使用 C 或 C++ 编写的应用，且未对底层操作系统做过多适配，那么在迁移过程中就可能需要从代码层面进行更多的改造。这会导致业务复杂度显著提升。因此在这种场景下推荐用户首先使用商业衍生版本。其次也建议用户购买配套的迁移知识服务，比如原厂的迁移支持服务，这些服务可以很好地帮助企业进行应用的改造或迁移。
从迁移方案的角度来看，整体的迁移方案主要分为两大类。第一类是原地升级。原地升级意味着，例如当前实例正在运行一个 CentOS ，在原实例上进行软件包和内核的替换，从而将其升级为新的实例。这种方式不需要额外的资源来进行替换。但是在整个原地升级的过程中，节点会进行重启，因此并不是一个完全平滑的状态。
虽然他对于迁移过程中操作的要求相对较低，但他对于整个运行于操作系统之上的应用却有着非常高的要求。就像之前提到的，例如 Java 类的应用，它们从 JDK 层面就已经对底层操作系统 OS 进行了适配。因此在进行原地升级或原地迁移时，这些应用不太可能出现兼容性问题。所以在原地迁移的场景下，对应用还是有非常高的要求的。
而第二种方案是一个适用性更强的场景，那就是轮转升级。所谓的轮转升级，是指用户在新节点上部署新的操作系统，然后进行应用的迁移。这种场景基本上适用于所有的应用或业务，因为它是一个更为普遍的场景。然而这个场景也会给用户带来一些问题。首先，它可能需要更多的基础设施成本，因为用户需要购买新的基础设施，并将原有基础设施上运行的资源迁移到新的基础设施上，这会带来额外的成本。其次在工作量上也会非常高，因为用户需要重建系统，包括重新配置之前的用户设置或存储库等，最后再将整个应用迁移过去。但从结果来看这种迁移方式对用户来说更为稳妥。综合考虑整体的迁移方案，这是不可忽视的一点。
其次需要考虑从操作系统本身的兼容性角度出发，如何做出相应的选择。这里举了三个例子，前两个例子都属于同版本的迁移。即当前使用的 CentOS 7 、龙蜥 7 以及阿里巴巴 Cloud OS 2 ，它们都属于同版本的情况。同版本迁移的适配性相对较好，基本上不需要额外的工作量。而当从比如 CentOS 迁移到龙蜥新版本，或者是阿里巴巴 Cloud OS 3 时，就面临跨版本的升级。这其中就涉及到内核升级的操作。因此对于应用的一些评估和兼容性测试，需要投入更多的工作量。所以在这种场景下，一般不会直接升级操作系统，而是使用相关的兼容性评估工具，无论是社区提供的还是市面上的，先进行评估，然后根据评估结果对应用进行相应的改造，最后再进行升级。
03.迁移支持
接下来看一下迁移过程中应用适配这一关键部分。
这里的数据是基于游戏或阿里云上运行的大部分应用所做的统计。所列出的所有场景都是在客户方案中已实践过的。这些应用可以分为几种类型。其中 Java 类应用基本上不需要任何改造。而 C++ 类应用，如果它们不是操作系统原生应用兼容的，可能需要进行大量的适配和改造。 Python 类应用、主流数据库、大数据应用以及外部应用等，都已经得到了相关验证，都可以实现相对平滑的迁移。
讲完了技术层面的迁移选型后，最后一点是希望借助整个社区和阿里云的知识库，帮助大家在迁移过程中利用这些知识顺利完成迁移。龙蜥社区在这方面提供了大量的迁移帮助，无论是迁移工具的使用，还是迁移前后的调优工作。之前小贾也提到过，在 Kingston 上进行操作系统的调优。对于用户而言，他们非常关心从 A 迁移到 B 后，性能是否有下降，或者稳定性是否有变化。因此这部分需要大量的数据或信息来支撑他们的决策。为此还在社区中提供了相应的工具，帮助用户消除迁移后可能出现的性能问题疑虑。
还有一部分是提供的前后系统兼容性分析工具，以及整理的兼容性列表。这个列表是基于实践和兼容性认证，通过与合作伙伴的合作，不断扩大操作系统的兼容性范围而得出的。通过这份列表客户可以清晰地了解到哪些应用在龙蜥操作系统上是完全兼容的。这为客户在迁移后验证兼容性问题提供了一个很好的参考。另外在安全合规方面，社区也提供了大量的支持。包括在组织层面，如联盟、组织、委员会等，它们都在为用户在使用容器操作系统时提供一个安全的环境而努力。
从数据建设的角度来看，鹏程在开始时已经提到过，龙蜥社区有一个专门的板块，用于提供操作系统 CentOS 停服支持。在这个板块里也提供了众多方案，这些方案都是社区内实践过的，包括社区的实施经验和工具。这里提到的一些内容，都可以在 CentOS 的停服迁移方案中找到。最后一点，社区还会提供丰富的文档支持，帮助用户按照步骤逐一完成迁移过程。
除此之外从社区的角度来看一些迁移工具更多是基于命令行，即黑屏化的。这可能对于很多企业来说，存在一定的使用门槛。因此在社区上还提供了一个平台化的工具，它是一个端到端的迁移平台。此外还提供了操作系统的运维工具，名为 COM 。 COM 工具涵盖了从迁移初期的评估，到迁移实施，再到迁移后的监控以及性能对比等全过程。这些功能都通过白屏化的用户界面供用户使用。例如，用户可以通过简单的点击操作，将原系统迁移到目标系统，整个迁移过程中的所有进程和最终结果，都会以直观的白屏化方式展现给用户。
除了迁移功能外，整个操作系统上遇到的一些问题，如小霞之前提到的抖动、网络问题、调度问题等，都可以通过这个平台进行相关诊断或监控。在迁移的关键节点上为用户提供了诸多便利。迁移前，用户可以在平台上自动完成备份、环境摸排等工作。迁移过程中，如果遇到迁移失败或出现问题，平台还提供了回滚等解决方案。整个迁移过程，包括这些关键步骤，都是通过平台以白屏化的方式为用户提供的，确保用户能够轻松、直观地完成迁移任务。
除了社区提供的迁移能力之外，阿里云上还有一款标准的迁移产品，名为 SMC ，即 Server Migration Center ，服务器迁移中心，专为阿里云的客户设计。目前这款迁移产品支持的场景已经基本覆盖了从 CentOS 7 到龙蜥 7 以及阿里巴巴 Cloud NX 等系统。无论是 x86 架构还是 ARM 架构， SMC 都能够覆盖到几乎所有的 CentOS 迁移场景。
这个方案及其产品具有几个显著特点。首先与云下环境相比，云上环境在实力的可靠性、快照功能以及整个自动化流程方面，它拥有更强的把控力。因此在整个迁移流程中能够确保过程的高度可靠性。此外该产品还提供了白屏化的界面，使得操作简单易用。而且 GTS 团队也配备了专业的迁移支持人员。在使用这个平台时，客户能够体验到从迁移前到迁移后的一致性效果。
整个迁移流程非常简洁：只需打开 SMC 界面，导入待迁移的实例，点击迁移任务，即可完成迁移。后续可能还有同学会基于这个工具进行更深入的演示或介绍。总的来说这就是在阿里云和容器上迁移方案的选型，以及迁移工具的介绍。如果大家线下有任何关于迁移的问题或场景咨询，欢迎在群内随时交流。
