带宽 = 峰值IO写入速率 × 容量增长系数 × 协议开销系数，但真正让信息科头疼的从来不是公式本身，而是业务峰值到底取多少、复制窗口设多长、以及RPO指标到底要不要打折扣。这套账如果只按存储厂商给的压缩比算个大概,上线第一周就会在晚高峰给你脸色看。
医院系统比银行还敏感，门诊挂号一堵，全院跟着停摆，这里不绕弯子，直接按业务逻辑把带宽这笔账拆开揉碎,讲清楚每一分带宽钱到底花在哪儿。
复制带宽估算前，先把医院业务掰成两个维度
日常运行期，带宽决定业务卡不卡
白天门诊高峰、住院医嘱开立、检验检查结果回传，这是HIS、EMR、LIS、PACS这几套核心系统的绝对主场，此时双活复制链路承载的是同步复制流量，写入主中心的每一个IO,都要等备中心返回确认才算完成。
这里有一个业内专家指出的共识：同步复制的带宽需求，本质上是业务IO的镜像，没有削峰填谷的余地，你主中心的数据库每秒产生2000笔写事务，每笔事务主备两端各落一次盘，备中心那条链路就要实打实扛住容量，估算带宽时，直接把生产存储的峰值写IOPS × 平均IO大小作为底数，再乘上TCP/IP和存储协议加起来的约15%-20%开销系数。
突发切换期，带宽决定命脉稳不稳
主中心机房空调跳闸、光纤被施工挖断，这类场景不常发生，但一旦发生，备中心要在几分钟内接管全部业务，此时复制链路的任务从同步镜像切换为追赶补发，主故障前积压的未复制数据，加上故障期间新产生的增量,都要在短时间内灌到备中心。
行业共识认为，追赶带宽需求往往是同步带宽的2-3倍，具体算账方式很直接：先估算RPO目标，比如允许丢失15秒数据，那就用每秒写入量乘以15，得出最大积压量，再除以你预设的追赶时间，比如10分钟,得出的数值就是追赶期间需要的带宽下限。
医院双活数据中心带宽怎么算：三步走实操法
第一步：摸清家底，盘出真实IO画像
不要拍脑袋，更不要直接抄同城其他医院的方案。每一家医院的业务峰值曲线都不一样，这和地方门诊量、挂号系统架构、影像设备型号都直接相关，正确做法是到生产存储上取一周、最好一个月的性能监控数据。
- 取每日峰值写IOPS，不要用平均值,平均值在带宽计算里毫无用处。
- 取峰值时段的平均IO大小，HIS这类OLTP应用通常在8KB-16KB,PACS归档通常是256KB甚至1MB以上。
- 记录写IO占比，双活关注的只有写IO,读IO不产生复制流量。
第二步：套用带宽公式，算准基线带宽
这里给一套实际可用的估算方法,比拍脑袋靠谱得多：
同步复制带宽下限 = 峰值写IOPS × 平均IO大小 × 8 × 1.2
举个例子，一套HIS峰值8000 IOPS，平均写IO 12KB，算出来是8000 × 12 × 8 × 1.2 = 6 Mbps，也就是说1G链路勉强够用，但余量太低，建议按1.5倍预留，也就是约1.4Gbps。
异步复制带宽下限 = 单位时间新增数据量 × 追赶时间系数
这里的单位时间新增数据量，指峰值时段每秒产生的净增量，含数据库日志、归档文件、影像缓存。
第三步：叠加RPO策略与快照频率的修正
很多医院买了双活之后，把RPO目标设在1秒以内，这不现实，也烧钱。建议把RPO设为5-15秒，给链路留出波动空间，同时关注快照频率，如果备中心每15分钟做一次一致性快照，快照本身也会产生复制流量，带宽需要额外增加5%-8%。
核心操作路径：登录存储管理界面，找到复制策略配置项，确认快照复制开关是否默认开启，如果开启，按快照大小除以快照间隔，得出额外带宽增量,叠加到基线带宽上。
医院双活数据中心 带宽被忽略的三个吞金兽
吞金兽一：数据库日志的放大效应
Oracle或SQL Server的归档日志和redo log，是复制流量里最容易被低估的一块，数据库写日志往往是顺序IO，单条日志可能只有4KB，但日志切换频率极高，更关键的是，数据库层的复制工具，比如DataGuard或AlwaysOn，传输的不是裸日志，而是封装后的日志块，协议开销比例远高于存储层复制，可达30%。
吞金兽二：PACS影像的突发流量
CT一次扫描产生的原始数据大约200MB-500MB，MRI更高，放射科晚上的批量读图、技师批量归档，都会催生短时大流量。PACS的复制带宽需求不能按平均增速算，要按单次检查最大文件大小除以允许的传输时延来算，比如一张500MB的CT影像，要求5秒内同步到备中心,单这一路就需要800Mbps。
吞金兽三：灾备演练和版本升级的带宽叠加
多数医院每季度做一次灾备切换演练，每年做一次全量数据校验。演练期间复制带宽需求是日常的4-5倍，因为要做增量比对、校验校验和、回切等操作，这部分流量如果不提前规划，演练时会直接挤占生产链路的日常复制带宽,导致业务延迟。
一台存储阵列决定医院双活存储复制 带宽预算
很多人忽略了一个事实：复制带宽的瓶颈往往不在链路，而在存储阵列自身的处理能力，同城双活如果走存储网关或阵列原生复制，阵列的复制引擎CPU、缓存命中率、IO队列深度,决定了实际能跑满多少带宽。
预算五万以内：走IP链路复用
如果原有链路是千兆以太网，没有额外光缆资源，预算有限的情况下，直接复用现有网络做存储复制，注意在核心交换机上为复制流量单独划分VLAN，打上QoS优先级，避免复制流量与业务流量抢带宽，这种情况下，单条万兆链路大约能满足2000-3000 IOPS的同步复制需求,适合门诊量中等的二级医院。
预算十万到三十万：上DWDM或裸光纤
这是目前三级医院的主流配置。独立裸光纤或DWDM波长通道，带宽从上Gbps到10Gbps起步
，链路延迟控制在1ms以内，满足双活对RPO近乎为零的要求，这个档位需要同步扩容存储阵列的复制许可，部分厂商的复制许可按容量计费，400TB容量的复制许可大约占总项目预算的15%-20%。
预算五十万以上：全闪双活加多链路捆绑
大型三甲医院的典型做法是全闪阵列双活加两条以上万兆链路捆绑，配合链路负载分担，两条链路同时承载业务，一条断掉时另一条自动接管全部复制流量，不做任何降级，这个方案里，带宽已经不再是核心瓶颈，链路冗余设计反而比带宽本身更值钱。
Q&A
医院双活数据中心间的复制带宽一般预留多大余量？
通常按峰值带宽的1.5-2倍预留，预留空间覆盖三块：业务增长带来的IO抬升、突发运维事件的流量叠加、以及复制协议版本升级可能带来的额外开销，规模较小的医院取1.5倍够用，大型三甲医院建议按2倍规划,同时预留单条链路的完全冗余能力。
复制带宽不足时，业务层先出现什么征兆？
最先报警的是数据库日志写入等待和存储缓存写命中率下降，业务侧表现为门诊挂号页面响应超时、护士站医嘱提交卡顿，但网络监控显示链路占用率只有60%-70%，如果出现这种情况，大概率是存储阵列的复制队列拥塞，链路带宽本身可能还没到极限，阵列复制引擎已经先饱和了。
如何在不增加带宽的前提下缓解复制压力？
调整复制策略是成本最低的解法，在医院信息科有权决定的范围内，做三件事：第一，把PACS这类大文件业务的复制优先级下调，把HIS和EMR的复制优先级拉到最高；第二，将RPO从1秒调整为5秒，给复制引擎留出合并小IO的空间；第三，关闭非核心业务系统的实时复制，改为15分钟一次的定时批量复制，按照多数医院的实际反馈，这三步操作能降低峰值时段复制流量约30%,且不增加任何硬件成本。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/703387.html
