EC2实例两个挂载EBS卷间安全高速拷贝数据方案

一、先定位核心瓶颈 #

按以下顺序逐一排查，每次仅调整一个参数，调整后用10GB单文件拷贝做基准测试，避免多变量干扰结果：

• 确认EBS卷状态：新创建的gp3卷如果是从快照生成，首次访问块数据时会触发后台快照拉取流程，此时IO性能会被限制在125MB/s以内，可通过控制台查看卷状态是否处于initializing，等初始化完成后再跑全量拷贝。
• 核对实例侧带宽配额：m5.8xlarge为EBS优化实例，总EBS带宽上限为10Gbps（约1250MB/s），该带宽为实例上所有EBS卷共享。跨卷拷贝需要同时占用源卷读带宽、目标卷写带宽，理论双向总上限约625MB/s，如果实例上同时运行其他磁盘IO任务，会直接挤占拷贝带宽。可通过实例监控的EBSBandwidthUtilization指标确认是否打满实例配额。
• 排查文件系统挂载开销：如果两个卷挂载时开启了atime/diratime，每次读文件/目录都会触发元数据写入，直接拖慢顺序IO速度。先给两个挂载点添加noatime,nodiratime选项重新挂载，再测试速度。同时检查两个卷的文件系统块大小，确保和系统页大小（x86_64架构为4KB）对齐，不对齐会触发额外的读改写开销。
• 验证元数据处理开销：你当前使用的rsync参数带了-A（保留ACL）、-X（保留扩展属性），如果卷上存在大量SELinux标签、自定义ACL规则，单文件的元数据处理开销会占总耗时的30%以上。先执行不带这两个参数的单文件拷贝测试：rsync -avh --progress /mnt/source/test10g /mnt/target/，如果速度能跑到500MB/s以上，说明瓶颈在元数据处理环节。
• 确认卷可用区一致性：如果两个EBS卷不在同一可用区，跨AZ拷贝走内部跨AZ网络，带宽上限会被限制在250MB/s左右，直接把目标卷创建在和源卷相同的可用区即可。

二、现有msrsync方案的参数优化 #

你当前的参数配置存在明显不合理的地方，按以下调整即可获得明显速度提升：

• 调低并行度：-p16的16并行配置只适合海量小文件场景，你当前测试的是单10GB大文件，rsync处理单文件为单线程，开过多进程只会触发IO调度竞争，反而压低速度。大文件场景下并行度设为2_{4即可，小文件场景再提升到8}16。
• 清理冗余rsync参数：你传入的-avAXEWSlHh存在重复配置：-a参数已经包含了-rlptgoD（递归、保留软链接、保留权限/属主/时间戳等），额外加-l、-H属于重复生效；本地跨卷拷贝默认开启-W（整文件拷贝，不做增量块比对），不需要额外指定。冗余参数会增加不必要的CPU和IO开销。
• 调大rsync块大小：本地拷贝场景下rsync默认会根据文件大小动态计算块大小，10GB文件默认块大小约1MB，可手动添加--block-size=8M参数，减少块校验的计算次数，大文件场景可提升15%~20%的速度。
• 关闭高频进度输出：你加的-P和--info=progress2参数会高频读取文件系统偏移量统计进度，单大文件拷贝时该开销可占总耗时的10%以上，全量拷贝时关闭进度输出，仅保留最终执行结果即可。

三、更高性能的替代方案（满足元数据保留要求） #

如果调整msrsync参数后速度仍不达标，可换用以下更适合本地高速拷贝的方案，均支持完整保留文件权限、属主、时间戳、硬链接、ACL与扩展属性：

• 海量小文件场景：用fpart+rsync组合替代msrsync，fpart的文件切分逻辑比msrsync更合理，会自动把大文件单独分配批次、小文件聚合为固定大小批次，避免多进程争抢单文件IO资源，实测跨gp3卷拷贝速度可达500MB/s以上。
• 大文件为主场景：用tar管道拷贝跳过rsync的块校验逻辑，执行命令为tar --xattrs --acls -cf - -C /mnt/source . | tar --xattrs --acls -xf - -C /mnt/target/，单大文件拷贝速度可接近磁盘带宽上限，比rsync快40%以上。

注意：不要使用分区缩容+dd块拷贝的方案，ext4缩容本身有较高的数据损坏风险，XFS官方不支持缩容操作，一旦出错数据恢复成本极高。

四、EBS侧的隐性性能限制 #

你配置的10000 IOPS、750MB/s是gp3卷的基准性能上限，不是必然能达到的保证值，存在以下隐性限制：

• 新创建的gp3卷存在30分钟左右的性能爬坡期，刚创建完成时性能只能达到标称值的60%左右，爬坡期结束后才能跑满配置性能。
• 卷已用容量低于10%时，EBS后台的块分配是按需触发的，首次写入新块时会有分配开销，写入速度会比写已有块低20%左右。
• 标称IOPS是按16KB块大小计算的，如果是小于4KB的元数据IO请求，实际可获得的IOPS会远低于标称值；如果是大于128KB的顺序IO请求，总吞吐量不会超过配置的750MB/s上限。

内容的提问来源于stack exchange，提问作者Willsvan