某省级城商银行信创操作系统迁移实战经验及难点

字数 7127阅读 3798评论 5赞 5

内容摘要：

中小银行需尽快替换现有CentOS系统，信创操作系统可承担职能。迁移需遵循原则，难点包括适配、硬件迁移和业务系统变更。云平台和大数据平台迁移方案包括节点规划、备份方案等。信创操作系统替代业务系统仍需攻克难题。

当前摘要为AI生成

在2020年12月8日，CentOS项目宣布，CentOS Linux 8于2021年12月31日停止维护和更新，CentOS Linux 7将持续更新至2024年6月30日，未来，CentOS项目的投入重点将由CentOS Linux转向CentOS Stream。这就意味着2024年6月30日以后，中小银行将得不到CentOS系统更新、维护、迁移等相关服务，而中小银行作为业务用户，科技力量比较薄弱，并不具备系统更新和迁移的专业能力，因此，尽快对现有运行环境中的CentOS进行国产化替换，由国内信创操作系统承担起产品、技术和服务的职能，成为国内各个中小银行信创改造的当务之急 。本文将从迁移原则、迁移应对措施、迁移难点和迁移场景实战分析几个方面介绍中小银行信创操作系统迁移的实战经验。
# 1 迁移原则
 笔者所在单位为省级中小城商行，在Centos发布停服通知时，我行约20%的业务系统使用Centos操作系统（主要为管理类系统）， CentOS系统停服给我行带来了重大安全挑战，因此迫切需要做好CentOS系统的迁移和接管准备。
 系统迁移应当力求对原系统或者业务影响最小,我行 主要秉承了以下几个迁移原则。
## 1.1 由边缘至核心
 首先考虑在非核心业务系统的迁移，如OA、邮件等，非核心业务系统迁移以后再考虑关键系统。
## 1.2 原子化
 迁移的方案在制定时力求对每一个系统或者业务都细化到不可分割的程度，例如某个系统由web、数据库与中间件三个部分组成，则在迁移方案制定阶段需要对三部分都制定不同的方案，若存在不同的数据库，则需要对不同的数据库分别制定方案 。
## 1.3 链路由上至下
 在迁移的制定与迁移的实施中，率先迁移在一条业务链路中处于上游的系统，以便快速进行验证，将测试验证的时间缩短到最小 。
## 1.4 先测试再迁移
 尽量先模拟生产环境创建测试环境，在测试环境上验证了迁移方案以后再在生产环境迁移，若环境允许，最好在准生产环境进行验证 。
## 1.5 滚动迁移
 若被迁移环境为集群，选择先从集群中拿出部分节点进行迁移，迁移完成以后再上线，上线度过观察期以后再迁移 其余 节点 。
## 1.6 重视迁移方案
 迁移前需要严格制定迁移方案，并与相关方充分沟通，明确职责、窗口期、测试方案等因素 。
# 2 迁移应对措施
## 2.1 存量替换
 麒麟和统信服务器版操作系统都具备相应的系统迁移软件（麒麟的服务器迁移运维管理平台和统信的 有易UYi ），将基于 现有 硬件设备（X86等架构）及业务软件平滑、快速的迁移之信创环境中。专门针对此种场景下的用户，通过替代内核、软件包的方式完成操作系统替代，应用此方案进行迁移无风险。满足不同业务场景下的用户需求，适用于已有业务系统的硬件利旧或业务系统同架构硬件的大规模批量替代场景。
 此方案优势在于无需重新配置或导入系统参数，无需重新部署应用，完全兼容CentOS系列软硬件生态，并提供系统迁移服务、安全增强、易管理等特点。劣势为兼容性要求较高，业务影响相对不可控，只能通过全量备份还原，回退时间长。替代之后，可能还需要软件包适配调试。
## 2.2 新增迁移
 采用信创服务器操作系统通过重新安装系统达到替代目标。如并行扩容，即业务系统不动，以信创扩容方式新建业务节点并行工作，新系统稳定运行后，旧业务下线；或直接进行业务新建，采用信创架构，全新部署，建设新的业务系统。
 此方案优势明显，可以在线下充分测试验证后再割接到生产，变更时间可控，对业务影响可控。劣势也显而易见，需要不同类型的技术资源支持，系统参数配置需要完整固化，需要进行应用数据迁移或同步，耗费较多人力物力。
## 2.3 安全接管
 安全漏洞是停更后用户面临的主要问题和风险之一。针对部分无法完成CentOS迁移，在停更后仍使用CentOS的中小银行，信创操作系统也可对CentOS系统提供安全漏洞公告、安全修复更新源、技术支持和安全加固等服务。
 此方案优势在于简单易行，不需要投入人力物力新建或重装操作系统，保证了系统的安全；劣势在于仅对安全漏洞进行修复，未进行系统版本替换，无法规避停服后其他潜在问题，也会带来监管风险。
# 3 迁移难点
 基于以上应对措施，产生了如下迁移难点：
 1.在存量替换场景下， 利旧 现有 Intel硬件服务器，业务系统迁移改造工作量 大；
 2. 在 新增迁移场景 下，选择全栈创新架构，业务系统迁移改造/适配 难度大， 涉及的业务系统多，缺乏统筹管理机制；
 3.在安全接管场景下， 不具备操作系统变更条件，老旧业务系统无人维护、核心关键业务系统暂时不能变更 ，带来潜在安全隐患 。
# 4 迁移场景实战分析
 基于以上迁移难点，本节将对迁移场景进行详细分析，以期对迁移难点的解决提供一定的参考。
## 4.1 单机环境
 针对单机服务器是基于CentOS部署的业务系统场景，需要将CentOS替换为信创操作系统。目前信创操作系统软件针对利旧场景，均提供了基于信创服务器系统迁移软件，将承载在CentOS上的业务应用系统，快速安全地迁移至信创服务器操作系统。
 迁移的前提是：业务应用软件已经与信创服务器操作系统做了适配及测试。
迁移主要过程：
第一步：环境检测
 为了做好迁移评估，需要实施人员明确迁移的范围、当前环境、实施条件及其他相关信息。首先在通过迁移软件对被迁移的服务器进行检测操作系统版本、内核版本、磁盘可用空间、架构类型等以及其他与迁移相关的系统信息，并要做数据备份提醒，开源数据备份方案。
第二步：迁移评估
 评估是迁移的必要步骤。为了做好迁移评估，需要对环境检测的结果和实施迁移的范围、当前环境、实施条件及其他相关信息做迁移评估，这种情况下，评估过程中首先要了解迁移实施所需的信息，并确定相关各方的角色和职责。在评估的方式上，首先要针对收集到的部署与迁移、业务要求和决策、硬件和软件、拓扑、基础结构、应用程序代码等有关的必要信息。并进行软件包版本对比分析，ABI兼容性分析，源代码分析，硬件兼容性分析，配置差异分析等迁移相关内容。
第三步：迁移实施
 由于是单机场景，无法在迁移过程中，保持业务系统的连续性，需要将业务系统中断后，才能进行操作系统的迁移工作。
 在迁移操作前需要进行，系统备份，业务应用备份，数据备份，业务隔离等工作。
 迁移替代过程，主要是通过迁移软件进行操作系统的迁移替代，主要包括操作系统内核替代、系统调用层处理、系统配置参数恢复、软件包替代安装等迁移工作。
第四步：迁移验证
 完成迁移后，需要对业务系统进行迁移结果评估验证；包括重启被迁移服务器，原CentOS操作系统完全替换成信创服务器操作系统,并且业务系统启动后，要进行数据验证、功能验证、性能验证、安全性验证、稳定性验证并做系统调优等工作，确保业务系统在迁移操作系统后能正常使用。
注意事项:
 由于是单机部署运行并且是服务器利旧场景，所以要求业务系统同信创服务器操作系统兼容性要比较高。由于迁移过程是不可逆，所以对业务影响相对不可控，如果迁移不成功，只能通过全量备份还原，回退时间长。
 如果在资源充足的情况下，建议采用业务系统新增节点的部署方式，完成业务系统的迁移。
## 4.2 集群环境
 针对集群环境，需要将主备服务器的CentOS都要替换为国产操作系统。可以分别通过对主备两台服务器分别前后按照单台服务器迁移场景进行操作系统迁移。最终实现将承载在CentOS上的业务应用系统，快速、平滑、稳定并安全地迁移至信创服务器操作系统。
 HA场景迁移的前提是：业务应用软件和HA软件均已经与信创服务器操作系统做了适配及测试。
迁移主要过程：
第一步：替换备服务器B操作系统
 先将备服务器B基于CentOS/RHEL的操作系统按照基于单机场景进行迁移，实现单台服务器B 操作系统 迁移到信创服务器操作系统。
第二步：主备业务切换
 将原来提供对外业务系统的从主服务器A切换到备服务器B上面，然后在备服务器B做迁移验证（功能、性能、稳定性、数据测试）。
第三步：替换主服务器A操作系统
 在备服务器B上验证通过一段时间后，再在主服务器A按照基于单机场景进行迁移，实现单台服务器A操作系统迁移到信创服务器操作系统。
第四步：主备业务倒换
 通过主备切换将原来提供对外业务系统从备服务器B切换到主服务器A上面，然后在主服务器A做迁移验证（功能、性能、稳定性、数据测试）。在服务器上验证通过一段时间后，最终就实现了基于主备服务器场景下，实现所有服务器操作系统迁移到信创服务器操作系统。
## 4.3 云平台环境
 以业内比较主流的，基于OpenStack为底层架构的云平台为例，介绍迁移的具体过程。迁移的前提条件是，云平台厂家与统信服务器操作系统已完成适配及测试工作；
 虚拟化平台迁移场景示意
迁移主要过程：
1.评估及准备
 第一步:对整个云平台进行巡检，处理完成所有告警信息，保证云平台处于健康状态。
 第二步：登录云平台资源及服务健康页面，检查管理资源及业务资源使用率是否在正常范围内，各项管理组件及业务组件健康状态是否良好，以保证迁移前各项指标及资源满足迁移需求。
 第三步：对迁移替换过程进行风险评估，制定迁移实施方案和风险应对方案，如遇到问题可迅速进行回退到原始状态，保证业务不受影响。
2.云平台迁移
1）针对管理节点
 由于云平台的控制节点为3节点高可用部署，并且该节点上部署的虚拟机全部为管理平台各个组件及服务，不涉及到客户业务系统，相对风险较小，可先对3控制节点进行底层HostOS系统替换，一般管理组件及服务都是双副本或者三副本分别分布部署在三台控制节点上，所以需要提前摸清楚每个管理组件及服务的分布情况，并且根据策略规划进行虚拟机热迁移到对应节点上，保证在关闭任何一台管理节点的情况下，不影响管理界面的访问。
 经过前期准备及规划工作后进行迁移替换，首先按照云平台管理页面的剔除管理节点流程进行操作，先剔除其中一台管理节点到集群外，然后通过云平台自动化管理扩容工具，重新对管理节点进行扩容操作（提前上传信创操作系统镜像），该节点会在自动化扩容工具的作用下自动部署信创操作系统，然后自动创建虚拟机，自动部署之前存在的管理组件及服务，最终完成所有扩容及服务工作，然后由云厂家技术进行管理页面及3控制节点高可用验证阶段，然后进入试运行阶段。
2）针对计算节点
 由于计算节点上的虚拟机都运行着业务系统，比较敏感，迁移风险比较大，所以需要提前做好方案规划及应急预案，由于云平台一般为规模较大集群，其平台资源充足，一般资源池会有多余可用于计算节点故障迁移虚拟机的迁移资源，所以，可以利用这些空余计算节点资源进行临时过渡迁移。
 先以其中一台计算节点迁移替换为例，先评估该节点上虚拟机的数量，类型，资源配置，业务情况等信息，然后从空余计算节点上进行匹配，找到可以满足迁移所需的空余节点资源，然后通过虚拟机热迁移功能（前提是Ceph等共享存储环境来实现，云厂商和存储服务商来提供该技术保证），把需要迁移替换节点上的虚拟机逐台迁移到目的计算节点上，迁移过程业务不中断。
 虚拟机迁移完成后，原计算节点已无业务虚拟机，可以通过管理页面把该节点进行缩容操作，然后通过云平台扩容工具把该节点重新扩容到计算节点资源池中（提前上传 信创 服务器操作系统镜像），然后工具自动启动该节点上的相关组件及服务，由云厂家技术通过虚拟机热迁移功能回迁原虚拟机（如果迁移失败，系统会自动回退到原节点，不影响业务），云厂家技术检查测试计算节点状态及服务是否正常，业务系统检查验证业务是否受到影响。
 若 有较充足预算，可采取完整新建一套云平台集群，部署业务系统 后 进行联调测试，然后与原系统进行 双轨 运行，在试运行一段时间后没有问题，可逐步停用原云平台集群中的业务系统，完全由新云平台提供支持业务。
## 4.4 大数据平台环境
 我行是基于物理机部署的大数据集群，在迁移之前由我行主导，信创操作系统厂商和大数据厂商配,合 划定系统迁移范围（业务选型、迁移数量）、待迁移的目标集群，制定迁移原则和计划，梳理业务系统的集群架构，比如清点管理控制、计算、存储各个节点的数量、硬件配置、软件组件清单和软件配置清单，梳理归档。协同业务部门根据集群架构和集群节点角色，优化迁移顺序，制定相应的系统和数据备份方案、业务割接方案，单节点系统迁移替换方案和控制节点主备切换等方案，从而形成场景化的迁移方案。
1.兼容性适配和测试
 确保在迁移之前，完成大数据场景服务器、存储等硬件，大数据集群软件组件与信创服务器系统的兼容性适配和测试，以及根据业务要求的性能对比等测试。
 大数据平台测试样例：

|   |   |
| ------------ | ------------ |
| 测试需求内容 | 测试需求描述 |
| 安装测试 | 1）ClouderaManager安装测试2）ClouderaCDH安装测试3）支持Hadoop自动化、流程化集群安装4）支持Hadoop组件/节点/角色的批量安装操作5）支持Kafka安装部署6）支持ELK安装部署7）支持Storm安装部署8）支持Flink安装部署 |
| 组件支持 | 1）支持HDFS2）支持YARN3）支持Hbase1）支持Hive2）支持Impala3）支持Spark4）支持Flink5）支持Kafka6）支持Zookeeper7）支持Sqoop8）支持Oozie或其它调度组件9）支持Sentry或其它权限管控组件10）支持Hue11）支持Flume12）支持LDAP、Kerberos安全集成13）支持ELK |
| 单点故障测试 | 1）支持HDFSNamenode/datanode高可用，无单点故障问题2）支持YARNResourceManager/nodemanager高可用，无单点故障问题3）支持HbaseMaster/regionserver高可用，无单点故障问题4）支持HiveMataStoreServer/Hiveserver2的高可用及loadbalance，无单点故障问题5）支持zookeeper高可用，无单点故障问题6）支持Oozie的高可用及loadbalance，无单点故障问题7）支持hue的高可用及Loadbalance，无单点故障问题8）支持LDAP/Kerberos/DNS服务等周边组件服务高可用，无单点故障问题9）支持kafkabroker高可用，无单点故障问题10）支持StormNimbus/Supervisor高可用，无单点故障问题11）支持ES高可用，无单点故障问题 |
| 组件应用测试 | 1）ClouderaManager集群管理及图表查看测试(集群/组件/节点/角色实例启停、集群容量/组件性能图表查看/集群/组件服务监控告警、各组件管理UI使用测试)2）HDFS读写相关测试(上传、下载、创建目录/文件、ACL授权测试)3）Hbase读写相关测试(表空间和表创建/删除/授权操作测试、读写测试)4）Hivebeeline连接、库表创建/删除/授权操作测试、读写测试5）MapReduce/Spark/Flink作业提交及YARN作业管理测试6）Hue测试(认证登录、编辑器使用、workflow创建运行)7）Kafka读写相关测试(topic创建/删除/授权操作测试、读写测试)8）ES读写相关测试(索引创建/删除/授权操作测试、读写测试) |

（2）制定系统备份方案
 大数据系统备份方案可根据其共享文件系统，如HDFS文件系统的集群属性来考量并制定系统备份方案和数据备份方案。如根据节点架构、数据分布以及当前存储的数据量，来决定进行系统全量备份，还是进行只备份应用配置和数据的数据备份 ， 或者根据集群多副本属性，优化迁移顺序，跳过巨大数据量的备份。
（3）制定业务割接方案
 根据实际生产环境业务需要，制定业务割接方案。比如在允许执行节点下线的时间窗口，遵循先迁计算（数据节点），后迁管理，最后迁存储节点的先后顺序。如果使用的是独立的共享存储，则无需替换存储，在迁移之前断开存储即可。
（4）预测试
 根据实际生产业务负载量和集群资源配比，结合业务窗口期，腾出可用于预测试的带有大数据业务系统、相对闲置的服务器资源，以供迁移前预测试，从而验证整套方案的可行性 。
（5）系统迁移
 使用 信创系统 迁移工具，有序展开大数据节点的单节点系统替换或多节点批量替换工作。工作内容包括环境检测、迁移评估、批量一键迁移、结果评估等功能。
（6）业务验证
 大数据业务部门，参照之前大数据集群系统的功能测试、安全测试、性能测试方法，对本次系统迁移后的大数据集群节点，执行上线节点、业务流量平衡后的系统业务数据完整性校验、功能测试、安全测试与性能对比测试。确保替换 后的 大数据集群节点，较之原来的系统，功能正常，数据完整，安全达标，性能达标或优于原来的水平。
# 5 总结
 信创操作系统对业务系统全面替代任重道远，系统迁移之后，上下游生态体系的建立健全、与存量业务的适配、运维便捷性、故障诊断可靠性等问题，仍旧是信创操作系统函需攻克的主要难题，笔者希望信创操作系统厂商能够潜心进行技术研究，解决用户痛点问题，不断更新迭代，构建更好的信创生态圈。

信创操作系统技术实践系统迁移

著作权归作者所有

如果觉得我的文章对您有用，请点赞。您的支持将鼓励我继续创作！

添加新评论5 条评论

红牛vc运维工程师广州金融行业
2024-03-22 17:22

文章结构清晰，可以直接拿来参考并投入实战的文章

menglunyang

系统工程师中国银行
2024-03-21 22:24

文章质量非常高，提供了一份详尽的指南和参考框架，对于那些需要进行类似迁移的机构来说非常有价值。它不仅展示了一个成功的迁移案例，还诚实地讨论了过程中的困难和解决方案，对于读者来说既有启发性又具有实用性。作者对于技术细节的深入了解和对于迁移过程中策略性思考的展示，使得这篇文章成为了该领域的一个重要参考资料。