金融行业老旧设备更新全过程技术要点和实战经验分享

一、 为什么要开展老旧设备更新

电子元器件的使用寿命遵循浴盆曲线规律，当使用达到一定“年头”，IT设备将进入到磨损故障期，故障率明显升高，以分布式计算类系统的机械硬盘故障为例，每日频繁的IO读写加剧了大容量磁盘的损耗，运行期超过4年后，磁盘故障率陡增，表现出零星的磁盘读写失败，这会导致批处理任务执行耗时长或最终失败。当发现并处理完一批次故障后，新的一批磁盘故障又逐个出现，可谓此消彼长。

图1 电子系统与器件失效浴盆曲线

另外动力环境、负载变化、设备搬迁等不确定因素还会造成高故障率提前。设备老化、使用年限过长，将造成备件、人力、耗能、环保等各项运维成本投入增大，事故发生风险概率升高。

图2 设备更新的起因与影响

随着企业发展，设备性能也可能出现瓶颈，不再满足业务需求，为保持或提升企业市场竞争力，需要及时对设备更新换代。

此外一些外部环境因素，如设备备件停产、服务商停服、固件版本停止更新等，也迫使用户必须开展设备更新。因此，在设备达到一定使用年限开始逐步淘汰或更新势在必行。

二、 老旧设备更新的年限要求

三、 老旧设备更新有几种方式

1、 在线替换

在机房资源充足情况下，将新资源部署入网，通过虚机、存储等资源迁移，业务流量入口切换或主备链路切换的方式实现在线替换。如新系统上线后，切换业务入口完成新老系统交替；网络设备接入网后，通过主备链路切换完成新老设备交替。 具体的实施过程将在“六、老旧设备更新实施”部分介绍。

图3 新老系统切换

2、 离线替换

四、 老旧设备更新有哪几种情况

1、 业务系统更新

由承建部门负责牵头实施，对原系统整体重新立项、建设，对于运维来说更加友好。这种“拆迁式”更新，保留了大部分原系统主体功能，并扩容、改造原功能，待新系统上线并“迁”入交易后，拆除老系统。

2、 设备更新

多系统复用，建设期个别利旧，系统规模小，或软件授权无替代等原因导致不能整体替换的，需对单台或多台设备逐个替换。鉴于设备使用的影响范围，按照业内使用的常规情况，对几种设备类型的复用情况，替换难度、风险等进行比较：

表1 不同类型设备更新情况比较

主机设备， 应用服务一般具备高可用架构；

存储设备， 基本被多台主机共用，数据冗余情况根据业务的重要程度有所区分，替换时需在主机层先进行数据迁移后再替换下线；

网络设备， 这里包括了存储网络、业务网络等，因接口多设备老，梳理互联关系难度大，切换主备链路，风险大；

动环设备， 虽不涉及程序或数据的调整，但影响面大，替换的风险较高；

安全设备， 设备种类多，通用性一般，与上下游设备之间、应用程序之间均需要做兼容适配，过程复杂，难度较高；

五、 老旧设备更新有哪些前期准备工作

1、 软硬件之间的适配

包括了主机硬件与操作系统层适配，操作系统层与数据库、中间件及各类开源软件的适配工作。如果调整了CPU芯片架构（如x86转为ARM），则CPU芯片与各软件之间均需适配，当然平台移植性较强的java或容器等适配，是依靠底层的java虚拟机JVM或容器底座来完成适配的。

主机类设备替换，为了简化上层数据库或应用程序的调整，可尝试继续延用原操作系统版本。操作系统与硬件之间适配，按照7年估算硬件产品升级，CPU芯片等各类硬件迭代在2-3次，操作系统支持情况有较大变化（如表2所示）。

操作系统与硬件在做适配性测试时，需关注包括各类驱动对硬件识别情况，硬件性能是否达标。另外与操作系统、硬件厂商确认，针对缺陷或新特性是否需要补丁更新。

表2 Intel Xeon Scalable Processors Minimum OS Support Matrix

老旧设备更新的初衷是提高系统运行效率及稳定，同时淘汰老产品减轻运维负担。所以在替换中，尽可能使用新版软件，这样软硬件兼容度、新特性发挥等方面更好，对运维来说，减少软件版本数量，将利于日后数据统计、运维工具开发、监控平台对接等等工作。

不管是被迫更换还是主动升级软件，都会引入应用程序、中间件、数据库与操作系统之间的重新适配工作，测试中需验证各类软件的部署及运行是否正常，验证QPS、吞吐量是否达标等。

2、 新设备与老环境之间的适配

当替换生产中某个节点设备，必然要考虑和上下游之间的适配，如主机接口与原存储 、业务网络交换端口速率、通信协议、工作模式是否兼容，是否需要降低配置规格适配老环境（以图4为例），如果不适配，是否需要增加配件或设备，连带上下游硬件一起更新来扩大改造面，在替换改造前，需协调设备厂商根据现场环境做好评估及验证。

图 4 交换机工作模式修改为半双工

3、 应用程序迁移验证

对主机的替换，涉及应用重新部署。目前国内部分操作系统厂商提供系统迁移软件，如统信有易可实现centos向统信UOS迁移，但也存在诸多的局限性。正常情况下，迁移前完成程序打包，并测试验证再次部署、发布、运行是否正常，以确保后续迁移顺利实施。

4、 生产地址是否变更

主机的生产地址是否变更，由替换方式决定，如果是原位置替换，原地址可继续复用；如果是在线替换，新、老设备并行运行，因接入交换机差异，地址会发生变化。 生产地址发生变化时，系统内各个主机间访问的地址以及外部系统访问本地地址均需调整，本系统自身调整外，关联系统也需要配合改造。修订的内容涉及程序配置文件、数据库、甚至是应用程序代码，全部修订完后，可通过抓包的方式，来观测内外部是否还存在访问老主机地址的进程，来判定是否修改完整。

5、 设备关系梳理

没有孤立的业务系统或设备，故需梳理清楚上下游关系，交换机需整理替换端口映射表（如表3所示），查缺补漏，通过排查MAC地址或WWN信息来明确每个端口标签和实际设备是否一致，这里如果发现主备接反或接入到同台设备时应及时整改，防止切换后业务中断；存储需明确每个LUN盘的分配使用对象；主机需明确上层应用服务及涉及范围等。

表 3 SAN交换机端口信息表结构

梳理新、老设备之间的对应替换关系，提前打印、粘贴标签，保证替换时做到一一对应。

利旧线缆梳理，对原位置设备替换，可以利旧的线缆，明确并打印相应标签，哪些线缆需要重新部署，提前做好规划、实施。

6、 验证准备

人员安排，需安排业务人员及运维人员做好替换过程中的业务验证；安排相关厂商做好部署前后的检查工作；如果涉及到停业，尽早发布停业通告。

7、 应急方案

老旧设备更新也是对生产环境的变更操作，涉及变更，就需要充分考虑数据备份、回退方案和应急处理措施。关键数据备份是运维人的“底线”，回退方案要明确具体步骤，应急方案应切实有效，提前做好演练。

8、 细化任务

六、 老旧设备更新实施大致有哪些环节

1、 环境部署

安装部署、配置新的替换设备。这里需要强调的是，在没有正式的设备替换流程前，替换未必会遵守正常的工程建设流程执行，所以强调在安装部署时，应按照生产基线进行配置，包括各类固件微码版本升级、驱动补丁更新、设备初始化、设备调试等，防止投产后再进行变更。

此外根据设备关系梳理情况，布放新设备到关联设备之间的新增网线、光缆等，同步做好线缆标签标识的打印、粘贴。

2、 替换过程

主机类设备：

非云场景下的主机替换，在确认“应用程序迁移验证”无异常后先行在新设备上重新部署相关软件，在集群内有多台主机来保证高可用和负载能力前提下，将新设备入网，确认承接业务情况，老设备下线，确认交易。剩余主机均按照“上线-确认-下线-确认”来实现逐台替换。

云场景下的主机替换，因系统及业务数据均存储在商业磁盘阵列介质中，可使用冷迁移或疏散方式将虚机迁移到其他计算节点，如果原云下资源不足，可先将新主机初始化后扩容到云内，再将老设备上虚机指定迁移到新主机上。

存储类设备：

存储设备只能采用在线替换，先完成新老设备间数据迁移，再对老设备下线。数据迁移已有很多成熟的方案，可参考 《存储迁移优化实施方案的四种选择》 。这里再介绍实际应用中的三种场景：

Oracle数据库的ASM，Oracle ASM管理大大简化了磁盘管理和数据迁移，在ASM管理下，对磁盘组（diskgroup）扩容新存储逻辑卷，再剔除老存储逻辑卷，再启动数据均衡（reblance），等待数据均衡完成，即实现新老磁盘替换。这种在线迁移方式有一定的IO读写开销，一般选择业务低峰时段操作。另外如果迁移时间充裕的话，可放慢数据均衡速率以换取安全稳定。

LVM的文件系统，LVM底层可通过操作PV（物理卷）实现数据迁移，对VG（卷池）扩容，再将老卷移出（pvmove）VG，即实现新老磁盘替换。卷移出操作不影响文件系统读写，将移出操作放置在后台执行，即可实现在线迁移，该迁移速度慢，占用IO较少，且支持断点续传（慎用），上层基本无感知。

云上虚机及文件系统，可通过cinder retype等实现系统盘和数据盘迁移。该方式离线迁移，当系统盘需要迁移时使用，否则优先使用“LVM的文件系统”进行数据迁移。

交换机设备：

对照生产环境重新配置新交换机，网络交换机配置包括路由信息，部署模式，主备关系，业务网关，vrrp组等，光纤交换机包括基础配置，zone信息等等。

为了保证高可用，交换机多为主备，入网时，采用逐台进行的原则，关停一台后，先检查各区域连通性，是否有主机连通异常或主机数据读写异常（存储网络），如无问题，说明对位交换机已接管成功，再进行老设备下架、新设备入网、线缆接入，完成后先断开对位老设备的某个端口，观测新设备对应端口的互通情况，无异常说明接管成功，再进行后续设备的断电更换工作，如图5所示。

图 5 网络交换机设备替换

七、 老旧设备更新难点及风险点在哪

1、 复用设备梳理遗漏

网络、存储等复用设备，在梳理端口关系、存储盘映射关系时，一旦出现遗漏则可能在老设备关停时造成生产故障，所以梳理不容小觑。不要“过分相信”线缆上的标签，标签打印，沾粘过程中都可能出现人为错误，最真实的是主机上识别到的MAC地址、WWPN号、LUN盘UUID号信息，采集这些信息并与标签比对，可以发现哪些标签是错误的。

2、 温和替换

新系统部署上线前，有充分的测试验证期，而在设备更替、切换中，验证时间窗口不会很充分。所以在替换中，每个检查过程不能省略，变更时尽量小范围试点，如端口先试点切换，再到整机。

3、 留足空间

存储替换时，确认原存储是否有超分，规划时确保新存储空间满足已分配的空间总和；另外存储分配剩余至少空闲5%空间，保证存储整体性能。

需要特别提醒，使用LVM做数据迁移时，因存储或操作系统对磁盘空间的计算差异，可能导致新分配空间略小于原存储分配空间，致使因空间不足迁移失败。所以新磁盘空间稍多于原有磁盘，如老存储划分1000GB，则新盘划分1001GB。

4、 云上虚机迁移

八、 收尾工作

1、 资产信息更新

及时闭环设备出库、部署上线及老旧设备的下线、报废流程，更新CMDB（资产配置管理系统）中的资产数据。对照部署上线流程，及时将新设备的软硬件纳管到原监控系统中。

2、 原设备数据清理

下线设备及时做好数据清理，特别是对服务器本地盘或存储磁盘做好格式化 ，如果计划报废，则需进行磁盘物理消磁。

3、 文档整理总结

因涉及资产变动，各项流程应尽量做好留痕，无线上流程的，也应通过线下纸质方式完成各项审批及信息备份。

根据实施过程中出现的各类状况，结合运营环境和实施流程，总结整理本次替换方案和过程中的文档、工具、流程，完善工作制度，为后续的设备替换工作提供依据、指导 。

点击阅读原文可到社区原文下留言交流

觉得本文有用，请 转发、点赞 或点击 赏 ，让更多同行看到

*本公众号所发布内容仅代表作者观点，不代表社区立场