1. 项目概述很多人一听TC就以为是天车或者Twitter客户端但在存储圈子混久了看到TC这两个字母脑子里第一反应就是某厂商高端存储的TrueCopy也就是真复制。简单说TC是一种基于存储阵列的同步远程复制技术能把一台存储上的数据实时复制到另一台存储两块盘上的数据始终保持一模一样。我最早接触TC是在一个省级客户的容灾项目里当时业务系统要求RPO接近0机房距离不到20公里光缆时延大概0.5毫秒客户兜里预算又不支持购买小机上的数据库复制软件最后就是用TC把存储层面的灾备扛起来了。这篇文章就是把这几年玩TC的经验沉淀一下先讲清楚TC的原理机制再聊配置前的那些坑紧接着给一套可以直接照着做的配置步骤最后是日常运维中常见的状态、切换和故障排查方法。无论你是刚入门存储的运维新人还是已经干了几年想系统梳理一下复制技术的老人这篇文章都适合。不需要你有很高深的存储基础只要知道LUN、RAID、SAN这些基本概念就能跟得上。2. TC是什么为什么我们需要它2.1 从业务连续性说起任何容灾方案解决的无非是两件事数据不丢和业务不停。RPO是能容忍丢多少数据RTO是能容忍停多长时间。如果业务系统只允许丢失一次提交的事务那就必须做同步复制如果业务能够容忍丢失几十秒甚至几分钟的数据那异步复制也能接受。TC属于同步复制意味着主阵列承接的每一次写I/O必须等从阵列也写成功之后才向主机返回写入完成。所以TC天然把RPO逼近到0这是它最大的价值。2.2 TC在整个复制技术里的位置复制技术分两类主机层复制和存储层复制。主机层复制大家熟悉的比如数据库的DataGuard或者卷管理器的镜像它依赖主机上必须安装对应的软件或代理一旦主机本身崩了复制链路也断了。存储层复制则完全由磁盘阵列来实现主机无感知哪怕主机宕机只要阵列还活着复制链路依然在工作。TC就属于存储层复制它利用阵列控制器内部的功能模块把主卷P-VOL的数据块实时发送到从卷S-VOL。从实现层次来看TC与存储虚拟化、快照这些功能不同它不需要额外购买服务器不占用主机资源这也是很多金融客户愿意用它的原因。2.3 TC与其它远程复制功能的分工同一厂商的高端存储上通常有好几种复制技术TC的同类产品还有URUniversal ReplicatorUR可以理解成异步版本的TC它在同步复制的基础上引入了磁盘中间缓冲Journal先把数据落到本地的日志卷再异步发送到远端因而在远距离传输时对应用性能影响更小。而TC更强调每一笔都要确认这也就决定了它对时延、带宽的要求非常苛刻。实际项目里经常是TC用于同城双活或近距灾备UR用于异地异步容灾两者配合着用。搞清楚TC能做到什么、不能做到什么才知道什么时候该选它。3. TC的工作原理别再只记命令3.1 核心组件和数据路径TC体系里最基本的单位是复制对由主卷P-VOL和从卷S-VOL组成。P-VOL是业务主机实际访问的那块卷S-VOL是远端阵列上的备份卷。每台存储的控制器里都有负责处理复制的专用功能模块叫SSPStorage Side Processor它主要负责解析写入请求、维护复制的位图和状态机。当主阵列的SSP收到主机写入命令后会先记录该LBA逻辑块地址对应的复制状态然后把数据打成固定大小的包通过光纤通道或IP网络送到从阵列。从阵列的SSP接收到数据后把数据写入S-VOL对应的逻辑块并返回确认。主阵列收到确认后才告诉主机本次写入已完成。这个流程可以用一个生活场景来类比你在银行柜台上转账柜员不会立刻说办好了而是先打电话给收款行确认对方账户已经到账才给你回执。虽然多等几秒钟但两边账目绝对一致。TC就是这种两边确认的机制安全性极高代价是每一次写请求的延迟都会被放大变成本地延迟传输时延对方写延迟的总和。3.2 同步复制过程拆解我想把同步复制的每一步拆得更细一点因为在调优和排查的时候要用到。一次完整的TC写流程是这样的主机发出写I/O到主阵列的P-VOL。主阵列控制器判断P-VOL属于TC复制对于是除了在本地缓存中更新数据外同时把写请求发送给TC控制模块。TC控制模块生成一条复制记录向远端S-VOL所在阵列发送写请求。远端阵列收到数据后将数据写入S-VOL缓存并执行远程I/O确认。主阵列收到远端确认后才对主机返回写I/O完成信号。注意这里有一个关键点TC保障的是“顺序一致性”即所有写操作必须按发送顺序在S-VOL上生效不能因为链路乱序或者网卡丢包导致数据错序。因此TC在内部为每个复制对维护了一个序列号机制每一条写记录都带顺序号远端按顺序号依次提交。这也是为什么TC不能随便修改主机总线队列深度或乱序策略。3.3 一致性组的本质单看一个复制对比如数据库有一块数据卷和一块日志卷如果只保证每一块卷都复制但两块卷之间没有统一的时间对齐点一旦切换到灾备端数据卷和日志卷可能各差了一截数据库照样起不来。一致性组Consistency Group就是把多个复制对组成一个组组内所有复制对的复制操作会同时暂停、同时恢复、同时切换这样就能保证灾难切换时整个跨多卷的应用得到一个全局一致的数据镜像。这个对于多卷业务来说不是可选项而是必选项。注意创建TC一致性组时组内最好不要混入不同用途的卷。我见过有人把一个业务的生产卷跟另一个测试卷放同组结果测试卷频繁断开导致整个一致性组进入挂起状态生产也跟着受影响。3.4 TC与UR的选型逻辑很多朋友问既然TC保证零丢失为什么不所有场景都用TC答案是距离和时延。TC要求往返时延小于等于10毫秒最好在5毫秒以内距离超过100公里光纤传输延迟本身就可能超过1毫秒再加上链路上的设备抖动就很难撑住。而UR引入日志卷后本地返回主机写入成功日志再异步复制距离和时延影响很小。所以选型逻辑很清晰需求特征推荐方案RPO0同城或园区距离时延低TCRPO可容忍秒或分钟级跨城/异地长距离链路UR既要同步复制又要保留历史状态TC配合快照使用超远距离且链路不稳定建议考虑异步复制不要把宝押在TC上4. 配置前的设计和规划4.1 判断该不该用TCTC不是万能的配置前需要先算四笔账。第一笔是距离账。用光纤直连的话光在新光纤里的传播速度大约是20万公里每秒往返100公里链路就消耗了0.5毫秒的延迟。加上交换机转发延迟和存储内部处理延迟100公里内通常没问题超过200公里就要认真核算了。第二笔是带宽账。TC是把每次写I/O都发一份副本假设业务写带宽是100MB/s链路上至少预留150MB/s以上保险起见按两倍规划否则链路拥塞会导致连锁的性能问题。第三笔是时延账。如果主机写I/O平均延迟原本只有0.5毫秒TC会把复制往返时间加进去变成2毫秒或更多。对时延极度敏感的OLTP系统需要提前做数据库负载模拟不能只看存储指标。第四笔是故障域账。TC复制链路如果断开是立刻停业务还是让主阵列继续运行但标记异常这需要在项目层面决定不能靠存储管理员拍脑袋。4.2 网络与端口规划TC可以通过FC端口、以太网端口和专用复制端口传输。常见做法是在主备阵列上各划分独立的端口专供复制流量使用不和业务I/O抢通道。如果一个复制对需要更高的带宽还可以并行配置多个端口让TC在多条链路上进行负载均衡。要给网络交换机划分专门的VSAN或用其他厂商逻辑网络隔离避免其它业务波动影响复制链路。另外强烈建议配置链路冗余至少两条路径当一个端口故障时自动切换到另一个端口。我遇到的实战案例里有客户只拉了单根光纤结果光缆被施工挖断复制中断了六个小时虽然没丢数据但那一整天的RPO变成了无穷大业务侧也是吓出一身冷汗。4.3 阵列资源规划TC复制对里的P-VOL和S-VOL原则上容量必须一致至少S-VOL不能小于P-VOL。复制过程中TC不会做压缩所有数据块原样传输。所以给S-VOL预留10%到20%的余量用于应对后续的LUN扩充和快照预留。另外S-VOL所在存储池DP Pool写性能如果太差会直接拉高复制写延迟严重时主机响应都会被拖慢。我一般建议从卷的磁盘类型和RAID策略不要低于主卷宁可使用同样等级甚至更高等级的磁盘。5. TC配置实操步骤解析5.1 实验环境描述为了避免麻烦这里不写具体厂商型号用某厂商高端存储作为样例。环境大致如下主阵列某高端存储双控制器存储池Pool_A已有生产卷。从阵列另一台同系列高端存储存储池Pool_B用于放置从卷。管理软件某Storage Navigator管理界面或命令行用于配置复制对。链路通过两个交换机连接两台存储的复制端口采用光纤通道。5.2 第一步创建数据卷在管理界面的存储池菜单中从Pool_B创建一块逻辑卷作为S-VOL。创建时注意容量按前面说的等于P-VOL大小再加一点余量。不映射给任何主机S-VOL是专供复制使用的不需要主机访问。数据初始状态为空即可TC建立后会做全量拷贝。如果使用命令行大概是这样的思路具体命令因产品版本而异这里只给逻辑# 在从存储上创建一个裸设备卷 create_lun -pool Pool_B -size 200G -name S_VOL_APP创建完成后在管理界面上可以看到这个卷的状态是Normal、未绑定。5.3 第二步建立复制对在TC菜单里选择“新建复制对”填写P-VOL选择主机正在使用的那块生产卷。S-VOL选择刚创建的从卷。复制方式选择Synchronous同步。一致性组编号如果有多个卷组成一个应用则分配同一个一致性组ID。初始复制模式通常选“Full Copy”就是先把主卷现有数据完整复制一遍到从卷。确认之前再检查一遍两块卷的容量和Pool是否匹配。执行后系统会开始创建初始拷贝状态会从SMPL变为COPY再到PAIR。在拷贝期间P-VOL的业务I/O不会中断所以不用担心停机。拷贝完成后TC才开始真正进入同步复制状态。5.4 第三步验证同步状态用命令行查看复制对状态pairdisplay -g CGroup01输出结果里会看到复制对的名字、状态、一致性组号、IO状态等。常见的状态有SMPL还没有建立复制关系。COPY正在初始全量复制。PAIR复制对已建立同步状态正常。PSUS由于某种原因暂停复制P-VOL和S-VOL有差异。PFUL / PSUE表示复制对失败或发生异常。看到PAIR说明TC已经正常工作。此时可以故意在主阵列上创建几笔数据然后手动暂停、再恢复复制观察从卷数据是否完全同步。这种验证建议在新环境上线前做一遍避免用了好几个月才发现复制其实没生效。5.5 第四步配置监控与告警一台TC复制对是否健康单靠人工登录看状态是不够的。通常要把存储的SNMP告警关联到监控平台告警规则主要关注几个点复制对状态从PAIR变为PSUS或PSUE。一致性组中出现任何一个失败复制对。复制链路带宽使用率超过70%。复制延迟超过基线值。有条件的话还可以定期执行一致性校验也就是把主卷和从卷的块数据进行比对确保位图状态一致。虽然TC本身不会无故丢数据但控制器微码bug、链路错误丢包、磁盘静默损坏都可能破坏数据一致性定期对账是很有必要的。6. 日常运维、切换演练和常见问题6.1 TC状态机速查TC的状态切换并不是只有“复制”和“停止”两个状态。在故障和切换过程中还会出现其他关键状态。我做了一张速查表方便日常排查状态含义常见触发条件处理建议SMPL无复制关系刚创建卷、删除复制对等无需处理COPY初始复制中建立复制对后等待完成注意监控带宽PAIR正常同步复制中初始复制完成或恢复复制后正常工作状态PSUS复制暂停有差异管理员暂停、链路中断告警排查原因后恢复SSUS挂起且数据不完整网络故障导致S-VOL数据未完整接收务必先重新同步PSUE复制对异常出现硬件错误或超时立即查看错误日志PFUL复制等待初始同步某些产品在初始化时等待勿强行操作6.2 计划性的切换演练容灾系统最怕“一次都没切过真出事时不会切”。所以我强烈建议在非业务高峰期做切换演练。TC的切换逻辑可以分成“正常切换”和“故障切换”。正常切换步骤如下在应用层停掉写入或通知DBA把数据库切到只读模式。在TC管理界面执行复制暂停让主卷和从卷保持一致。确认P-VOL和S-VOL数据一致后将S-VOL映射给灾备中心主机。灾备主机挂载S-VOL启动应用完成切换。后续如果生产中心恢复可以把S-VOL反向设为P-VOL再建立新的复制对新变化逐步回传。这中间最容易犯的错是“应用还没停就暂停复制”这样S-VOL上的数据可能比P-VOL落后几个事务切换后数据其实是迟到的。真正要演练的正是“应用停机那一刻和复制暂停那一刻”之间的衔接顺序。6.3 链路中断怎么处理网络抖动或者光模块故障都会导致TC链路中断。此时存储会按策略进入PSUS状态也就是暂停复制但P-VOL还是继续接收主机写操作。这样做是为了不让业务受损但P-VOL和S-VOL的差异会越积越大。排查步骤一般是检查复制链路两端的端口状态用命令行或管理界面查看“链路信息”确认设备是否在线。用ping或fcing测试物理连通性但注意有些存储复制端口并不支持ICMP响应得看具体产品。如果网络恢复了先不要急着恢复复制先观察链路稳定几分钟。执行复制对恢复系统会先做差异同步把链路中断期间P-VOL上产生的变更数据重新发到S-VOL。完成后状态回到PAIR然后立刻确认S-VOL上的数据完整性。这里最关键的坑是链路中断期间如果P-VOL和S-VOL之间的位图记录溢出比如差异超过位图容量某些情况下TC可能会无法恢复只能全量重新复制这意味着可能需要把S-VOL清空再来一遍耗时很长。所以日常监控里位图使用率也是一个指标最好记录下来长期观察。6.4 常见问题速查表我在一线实际运维中总结过一些高频问题整理成表格供参考现象可能原因处理方式复制对一直处于COPY状态初始复制带宽太小 / 远端写慢扩容带宽或检查S-VOL缓存业务IO延迟突然增高复制链路拥塞 / 远端盘故障查看两端端口速率检查从卷磁盘状态手工暂停后无法恢复暂停前有写入未刷盘检查P-VOL缓存手动flush后再恢复切换后应用起不来一致性组范围不全确认所有相关LUN都在同一CG内复制链路频繁闪断光模块老化或光纤接头脏更换光模块清洁光纤S-VOL容量不足报错初始规划未留余量扩展S-VOL或重建复制对6.5 几个避坑心得第一TC的一致性组不是越多越好也不是越少越好。太多组增加管理复杂度太少组容易把无关卷绑在一起。一个业务系统一个组最合理。第二千万不能为了性能关闭“write order”保护一旦关了远端顺序无法保证数据库崩了神仙难救。第三做复制恢复操作之前一定要先拍个存储级快照哪怕快照保留两小时也会让你在误操作后能回到过去。第四复用业务光纤链路跑TC是很冒险的一旦业务流量峰值拥塞复制流量会被挤掉而业务自己感觉不到太大变化实际上灾难恢复能力已经降级了。有条件就单独建复制网络。7. 从实际项目中得到的体会我在多个容灾项目里部署过TC最大的感受是TC本身很稳定真正出问题的往往不是TC而是人。比如有人把复制端口和业务端口插反了有人把S-VOL的LUN归属设置错误导致主机在线扫描出了两个盘有人误执行了删除复制对的命令差点把灾备端数据清掉。所以操作任何存储复制功能前建议先写一份变更脚本或操作票列出要执行的每一步命令、预期状态再找第二个人复核一遍。这种事听起来麻烦但能挡掉九成以上的低级事故。如果你所在环境还没有启用TC但已经有了灾备规划我建议先从一对测试卷开始做功能测试把流程跑通、把命令记录好再推广到生产。一次成功的TC配置不是把所有按钮都点了就完事而是你能在深夜两点被oncall叫醒时还能冷静地通过几个命令判断出“链路断了”还是“从卷坏了”这比背一百条命令都重要。