存储报价单上的数字最近几个月已经涨得让人觉得不太真实。DRAM合约价连续多个季度保持两位数级别的环比涨幅NAND Flash晶圆价格比年初翻了一倍多落到企业级SSD和内存条上采购成本一年间涨了九成以上。最夸张的是大容量机械硬盘渠道报价一周一个样不少IT负责人刚准备做扩容采购就被预算“顶”了回去。如果你正卡在信创迁移和成本控制这两件事之间这轮涨价潮带来的直接问题就是新存储买不起老存储要不要留、能不能留我的答案是与其焦虑行情不如把存量资产彻底盘一遍。能利旧的利旧能分级的分级该新购的坚决不省。下面这套思路是我在几个迁移项目里逐步打磨出来的后文还会用一个超千台老旧系统的实际迁移案例把从摸底、测试到正式割接的完整路径串起来。1. 这轮存储涨价到底涨在哪为什么被称为“史上最强”1.1 三条线同时在涨颗粒、盘片、原材料这轮涨价不是某个单品缺货而是一条产业链的集体上涨。算下来主要是三条线在同时涨第一是内存颗粒。DRAM合约价连续数个季度保持在两位数级别的环比涨幅部分DDR4/DDR5产品规格几乎一个季度一个价。第二是闪存颗粒。NAND Flash晶圆价格从年初到现在累计涨幅超过80%个别大容量颗粒甚至翻倍。第三是机械硬盘。虽然单块硬盘的涨幅没有SSD那么夸张但16TB以上的数据中心硬盘已经经历过多轮调价渠道端报价基本按周更新。存储阵列、服务器、备份设备、NAS——所有和存储沾边的硬件成本都在肉眼可见地抬升。1.2 为什么说这次情况特殊涨价逻辑和过往不太一样做存储的都知道这个行业周期性很强隔两年涨一回并不新鲜。但这次之所以被很多人称为“史上最强”是因为涨价背后不是单一因素而是三重压力叠在了一起。AI服务器成了最大的那台“抽水机”。存储原厂的高端产能大量转向HBM高带宽内存和企业级大容量SSD普通DRAM和通用SSD能分到的晶圆产能自然被压缩。再加上DDR4向DDR5切换带来的规格过渡空窗以及原厂前两年主动减产造成的库存出清多个因素叠加在一起就形成了“产能挤占、供给收缩、库存不足”的共振局面。说得直白一点厂商把晶圆切给利润更高的颗粒去了普通产品线只能承受缺货和涨价的结果。这不是某一家厂商能单独解决的所以短期内看不到快速回落的迹象。1.3 涨价潮对信创迁移的传导链预算、周期、方案全被打乱对正在做信创迁移的单位来说存储涨价带来的不是“多花点钱”这么简单而是整个时间表可能被推翻。信创项目通常对国产软硬件有明确要求核心数据要落到新底座上而存储是整个底座里最贵、也最难补齐的环节。如果按照去年的方案全部采购新存储预算很可能会被顶破如果干脆延期到明年再买项目计划又撑不住。更麻烦的是交付周期。高端存储、全闪阵列这类产品本来就存在一定的订货周期涨价背景下原厂优先供给利润更高的订单普通企业级订单的交期反而被拉得更长。等于你手里有预算都不一定能很快拿到货。所以越来越多做迁移规划的人开始认真面对两个字利旧。2. 信创迁移中存储的四种角色与利旧控本的决策思路2.1 迁移的本质是数据底座重建不是换几台服务器先纠正一个常见误区信创迁移不等于“把旧机器淘汰扔掉”。它本质上是一次数据底座的重新搭建——操作系统要换计算平台要换但数据要完整地搬过去业务应用要在新平台上继续跑。在这个过程里存储至少承担四种角色每种角色对可靠性和性能的要求都完全不同核心业务的数据承载数据库、交易系统、审批流要求低延迟、高可靠宕机窗口是分钟级。一般业务的文件与数据库存储OA、工单、邮件、报表允许秒级延迟但不能长期抖动。海量冷数据的归档池监控录像、历史附件、留痕日志对IOPS几乎无要求但对容量和成本极其敏感。备份容灾的副本目标要求能用、能还原对性能要求最低但容量不能小。正是因为存储在里面扮演的“角色”不一样才给利旧留出了合理空间。很多团队一上来就谈老存储性能差、不安全、不能用其实是没有先做数据分级。2.2 利旧控本的四个认知前提我判断一台旧存储能不能继续用通常先问三个问题信创服务器上的操作系统和驱动能不能识别它它剩余的健康寿命窗口能不能覆盖未来两到三年的业务周期它的性能和容量放到哪个数据等级里才不至于拖后腿这三个问题有了答案才谈得上控本。还有一个容易忽略的前提利旧不等于所有设备都硬留。老设备如果已经到了故障高发期或者容量小、端口慢、维护成本高那它就算“还能通电”放在资产池里也是在消耗运维精力。利旧控本的核心是很残酷的一句话——能用有用的不能用别硬撑。2.3 数据分级是决定利旧策略的“总开关”我习惯把存量数据分成四档每档对应不同的利旧策略数据等级典型场景存量占比参考利旧策略Tier 0核心交易、账务、身份等10%~15%不轻易利旧优先新购全闪或高端存储Tier 1一般业务库、中间件25%~30%可用旧中端阵列但需保证冗余链路Tier 2文件、影像、日志35%~45%按容量利旧对IOPS要求低Tier 3备份、归档、冷数据20%左右几乎所有老存储都能继续承担举个例子监控录像、工单附件、日志归档这类冷数据容量占比可能超过一半但每分钟真正写入的IOPS可能只有几百。让它们继续跑在旧盘阵上用户完全感知不到变化反过来如果用全闪存放这类数据等于是把高成本硬件浪费在几乎不产生价值的角落。2.4 先算再动需求量和设备能力要对上账利旧决策最怕拍脑袋。我建议在做任何迁移动作之前先做一轮“供需对账”把老系统近三个月的实际IOPS、吞吐量、容量增长趋势拉出来把旧存储可提供的裸容量、有效容量、控制性能估算出来算出每个LUN的“占用比”。估算公式很简单占用比 实际使用指标 ÷ 设备可提供指标。如果占用比在40%以下属于安全利旧区间如果超过70%这个LUN就不该再放进旧存储应该按新购规划重新测算。不提前算这笔账最容易出现的局面是迁移过去才发现旧盘阵承受不了业务高峰整条链路慢成蜗牛然后又要返工把数据迁回。这种折腾比直接买新存储更费钱。3. 老存储利旧的实操细节盘点、压测、接法与验证3.1 资产盘点要做到“单盘级别”利旧的第一步不是连存储而是把家底摸清。我建议资产台账至少包含这些字段设备型号、序列号、固件版本端口类型与速率FC 8Gb/16Gb、万兆iSCSI等已用容量、剩余容量、卷映射关系对端主机/应用、业务负责人、数据增长趋势故障历史、告警记录、各盘位的健康状态。这里有一条非常实在的经验盘点一定要做到“单盘级别”。很多人只记录“这个框里有48块盘”但真正导致迁移事故的往往就是其中一两块即将退休的盘。每块盘的SMART健康数据都应该拉出来过一遍重点关注机械硬盘的坏道重映射计数、SSD的磨损与寿命百分比。提前替换掉那些已经出现重试或坏块递增的盘比迁移进行中救火便宜得多也从容得多。3.2 性能摸底要按实际业务模型来测存量数据搬过去之前旧存储能不能扛住目标工作负载必须用实测来回答不能只看纸面指标。压测工具有很多fio、vdbench、iometer都可以。关键是测试模型不能照搬理想化剧本别用什么“4K 100%全随机”这种实验室参数。真实业务往往是70%读、30%写还会夹杂大量顺序大块访问。所以我会先统计目标应用自己的IO特征再按照那个比例去压测。压测时还要盯延迟而不是只看平均IOPS。老存储的典型问题是中等负载下表现尚可一旦负载逼近上限延迟会非线性上升从几毫秒直接飙到几百毫秒。这种“悬崖式”下跌如果不提前摸清迁移期间就会突然卡死。测试时间建议至少持续7天跨过工作周和周末记录昼夜峰值差异。同时把历史监控数据调出来观察控制器CPU、单盘IO分布和高温告警。很多隐患是慢盘引起的性能拐点而这些数据平时没人看往往要等出了故障才会被注意到。3.3 接法选择FC-SAN还是iSCSI取决于兼容性验证老存储最常见的接法有两种FC-SAN和iSCSI。FC-SAN延迟低、稳定性好但要求信创服务器上有兼容的FC HBA驱动并且多路径软件能正常识别存储侧的LUN。iSCSI则更容易兼容走万兆网络就能跑部署也灵活代价是稍微多占一些主机CPU资源。真正容易出问题的不是选哪种协议而是驱动和链路兼容性。不少信创服务器默认内核里没有某些旧HBA卡的驱动或者多路径软件识别不了第三方存储的盘。典型症状是主机能看到LUN但一跑I/O就掉线重试几次之后盘直接消失。这种问题排查起来非常头疼因为它不是硬件坏了而是软件栈不认。我的建议是在正式迁移启动前先做一轮最小化验证。拿两台信创主机接一块旧阵列把存储端多路径、卷遮蔽、协议协商都调通跑一轮读写压测。这个小规模验证看起来只覆盖了一小块环境但它能挡掉后期一半以上的“盘看不到”问题。3.4 利旧存储的“退路”设计不管技术方案多漂亮利旧存储都必须留退路。我会在规划阶段就对每一台利旧设备标注“剩余使用寿命预判”然后做三件事重要数据在利旧设备上运行时同时在备份系统里保留一份独立副本给利旧设备留出冷备件控制器、电源模块、甚至整机;规划下一条迁移路径如果这台设备在两年内宕机数据能快速切到哪里。利旧设备的物理寿命是不可控的。软件和流程问题可以靠管控解决但跑了六七年磁盘阵列的电子元件老化不遵从任何人的意志。所以“退路”不是可选优化项而是必选项。4. 超千台老旧系统迁移实例预算只有六成数据却一点没丢4.1 项目背景与初步分组下面这个案例是我参与过的某集团信创迁移项目。这里不写具体公司名只说背景和操作路径给正在做同类项目的团队一个参考。该集团信息中心统计下来存量老旧系统总数1160余台其中物理机218台、虚拟机924台累计数据量约4.3PB。迁移周期被压缩在三个季度内而最终批复的预算只相当于原规划的六成。这就意味着用全新的高端存储替换所有数据的方案根本无法执行必须靠利旧设备撑起大半边天。我们做的第一件事是把1160台系统按业务重要性和数据特征分成四类类别台数数据量典型特征A类核心业务约120台约0.6PB交易、账务极端敏感B类一般业务约460台约1.2PBOA、工单、报表允许秒级延迟C类文件/归档/日志约380台约2.2PB容量大、IOPS压力低D类停运保留约200台约0.3PB已无在线访问需长期留存分类逻辑很简单A类对延迟和可靠性最敏感B类允许秒级延迟C类重点是容量D类几乎没有在线访问要求。这个分类直接决定了后面所有存储资源的分配策略。4.2 利旧与新购怎么配比6成存量靠旧设备扛该集团原有的存储家底并不差8套中端磁盘阵列、32套老旧盘阵和SATA JBOD还有3套磁带库。我们把这些存量设备全部纳入“可利旧资产池”。其中8套中端阵列主要分配给B类一般业务和C类热数据段部分老旧盘阵降级为备份目标和归档存储磁带库继续承担离线归档。新采购部分只规划了两块一套信创全闪资源池专门给A类核心业务使用另一套高容量分布式存储应对C类里面比较“热”的文件服务。其余超过六成的容量全部由利旧设备承担。最终算账的时候新购存储容量不到全部可用容量的四成。相比“全部推倒重来”的原始方案整个预算压缩了大约三分之一。省钱效果立竿见影。4.3 三批迁移节奏先易后难逐步加压项目被拆成三批迁移节奏上先易后难每一步都建立在前一步的流程验证之上。第一批D类停运性系统加C类归档日志。这批系统停机窗口最宽直接走离线拷贝和存储侧复制工具白天就能完成。目的有两个一是把存量数据完整搬运到信创新存储池二是把迁移流程和校验机制跑通。第二批B类一般业务。采用“预迁移增量同步窗口切换”的方式。先在旧存储上做快照把全量数据复制到新环境切换前一天再做一轮增量同步把差异时间缩到最短切换窗口放在夜间低峰期切换后观察两到三天再关闭旧数据。第三批A类核心交易系统这部分最难。存储在切换时必须保证数据一致性容不得半点闪失。我们的做法是用存储异步复制加数据库日志同步先让两边数据追平再在30分钟内完成数据库切换。这个窗口听起来很短但事前做了三次完整演练才敢在实际环境执行。4.4 现场翻过的车与处理办法没有任何一个大规模迁移是顺风顺水的这个项目同样踩了不少坑这里挑几个典型的讲。老HBA驱动不兼容。某批信创服务器默认内核里没有旧存储厂商的FC驱动反复调试无果。我们果断调整为iSCSI方案用万兆网络承载这部分流量虽然多占了一些CPU资源但没有影响整体进度。老阵列控制器突然离线。迁移进行到第三周一台旧存储的控制器毫无征兆地出现故障整个阵列读写中断。幸好现场准备了冷备件用了一晚上时间完成控制器更换并恢复业务。从那之后我们对所有利旧设备做了一轮控制器和电源模块的健康排查。快照导致写放大。老阵列控制器的缓存很小大量快照会明显拖慢IO。我们发现后立刻缩减快照数量关闭了不必要的自动快照计划仅保留迁移所需的必要快照性能才恢复过来。慢盘拖垮LUN。部分SATA盘在大流量同步时被存储识别为慢盘单个LUN的延迟从几毫秒飙到几百毫秒。解决方式是在复制工具里限制迁移带宽让大流量“平着走”别一次性打满链路。慢盘问题就这样被压制住了。4.5 项目收尾没有丢一条数据三个季度后1160台老旧系统全部完成迁移。A类核心业务使用新购信创存储剩余约九成数据由利旧设备承载。迁移期间虽然出现过故障但没有发生一起数据丢失切换后业务基本稳定原本被认为“不行了”的旧设备在正确规划下又稳稳定服役了两年以上。回头看这个项目能成靠的是三件事分组决策、分批节奏、以及每一批后的复盘检查。这三点缺一不可。5. 利旧控本最容易踩的坑与排查办法5.1 高频问题速查表把几个项目里反复出现的问题整理成一张速查表做迁移的时候可以直接对照排查症状常见原因处理办法信创主机看不到LUN驱动/多路径未配置先做最小化验证检查存储端遮蔽与协议协商IO一跑就掉线HBA固件与存储兼容性不佳更新或降级固件必要时改用iSCSI通道迁移大流量时LUN延迟猛增慢盘或控制器过载限制复制带宽、隔离慢盘、提前更换危险盘快照后业务变卡写前拷贝放大减少快照数量关闭自动快照策略光纤链路协商异常模块类型或速率不匹配强制定速检查多模/单模光模块迁移完成后数据不一致源端文件系统本身存在问题做文件数和字节数双重校验抽样比对5.2 数据校验不能只看“系统起来了”很多团队做完数据拷贝看到系统能启动就算大功告成。实际上老存储上往往积累了大量文件系统内部不一致的残留数据信创新环境挂载后可能根本读不出来或者读出来是坏的。我的习惯是每一次迁移都在源端和目标端各跑一次文件数与字节数核对再抽查目录结构。数据库类数据还要额外做一次逻辑校验比如表数量、记录数、关键字段抽样对比。校验这一步虽然耗时但能避免“迁完才发现数据是坏的”这种灾难性事故。5.3 备份纪律是利旧的红线利旧设备承载的数据必须同时存在第二份独立副本哪怕只是冷备磁带。这不仅是技术洁癖更是对老设备故障率的直观尊重——我可以控制软件和流程但我控制不了已经跑了六七年磁盘阵列的物理寿命。具体执行时我会按数据等级确定备份频率Tier 1每天增备、每周全备Tier 2每周增备、每月全备Tier 3每月全备即可。备份介质优先选择与利旧设备不同故障域的磁带库或另一套独立存储避免“备份和源数据在同一台设备上”这种形同虚设的安排。5.4 常态化巡检和“三页纸”报告利旧存储进入生产环境后要建立常态化巡检计划。每季度至少一次全量链路检查内容包括控制器健康状态、盘SMART信息、链路误码率、容量水位、固件版本是否更新。迁移期间我习惯每周出一次简短报告专门记录近期告警和性能拐点。报告不用复杂三页纸足够一页健康度一页容量趋势一页风险清单。这份报告既是给领导看进度的依据也是自己排查隐患的抓手。很多潜在故障其实在报告里连续出现两三次之后就能看出来苗头。6. 一些个人体会与后续扩展空间我这两年做过的存储相关项目里凡是利旧做得比较好的团队都有一个共同点他们没有把旧设备当成“省钱道具”而是认真给每台设备做了健康档案并且舍得在迁移前投入时间做压测和校验。利旧控本的本质是让还在生命周期内的硬件在最合适的位置上继续发光。省钱只是结果不是目的。如果存储价格后续回落这套架构还可以继续平滑演进先把利旧设备上的高价值数据逐步迁移到新购存储把旧设备降级为备份归档必要时再逐步下线。部署信创底座后不用一上来就搞得大而全三年滚动演进反而更稳妥。最后再提醒一句所有利旧决策都要留退路。不管技术方案做得多漂亮老设备的物理寿命和不可预测故障始终存在所以灾备和冷备永远不能省。迁移不是终点之后的日常运维才是真正的考验。