1. 光纤磁盘阵列到底是个什么东西第一次接触光纤磁盘阵列是在一个中小型数据库迁移项目里当时业务侧反馈每天早高峰的订单写入延迟会突然飙到几百毫秒排查了一圈发现瓶颈根本不在应用层而是存储侧的IOPS被机械盘拖死了。那时候摆在面前的选择有几个换全闪存服务器本地盘、上分布式存储、或者搞一台光纤磁盘阵列。最后我们选了第三条路原因很实际——预算有限、数据可靠性要求高、而且后续还要横向扩展容量。这套东西用下来前前后后折腾了小半年踩过的坑比想象中多得多今天就把这些经验完整地摊开讲一讲。光纤磁盘阵列英文一般叫Fibre Channel Disk Array本质上是一套独立的存储系统它把一堆硬盘机械盘、SSD或者混插通过RAID技术组织成一个逻辑卷再通过光纤通道协议对外提供块级存储服务。跟普通的NAS或者直连存储最大的区别在于它走的是专门的FC网络不占用业务以太网带宽延迟低、稳定性高而且支持多路径冗余。你可以把它理解成一个专门管硬盘的“独立机房”服务器只管通过光纤卡去读写剩下的RAID校验、缓存调度、快照、克隆这些脏活累活全由阵列自己扛。这套方案适合什么人我的判断是中小规模的核心数据库、虚拟化集群的共享存储池、视频剪辑团队的集中素材库以及任何对数据可靠性和IO一致性有硬要求、但又不想上全闪存阵列烧钱的场景。如果你只是家用或者小团队做文件共享那NAS足够了没必要碰光纤阵列光是HBA卡和光纤交换机的成本就够买好几台NAS了。但如果你手里有十几台服务器要共享同一份数据而且对延迟敏感那光纤阵列的性价比就体现出来了。我下面要聊的内容全部基于真实项目里的实操经验包括选型逻辑、配置细节、性能调优、故障排查以及那些文档里不会写的坑。不管你是刚接触存储的新手还是已经用过几年阵列的老手应该都能从里面找到一些有用的东西。2. 整体方案设计与选型思路拆解2.1 为什么选光纤阵列而不是其他方案当时我们对比了三种方案这里把决策逻辑完整还原一下方便你在类似场景里做参考。第一种是服务器本地全闪存。优点是延迟极低、部署简单插上就能用。但问题也很明显数据孤岛。十几台服务器各自有盘共享数据要靠应用层做同步一致性很难保证。而且本地盘扩容意味着停机加盘业务连续性受不了。第二种是分布式存储比如用几台服务器组一个集群靠软件层做副本。这个方案扩展性好成本也相对可控。但我们团队当时没有专职的存储运维分布式存储的调优和故障处理门槛不低一旦出现脑裂或者副本不一致恢复起来非常麻烦。第三种就是光纤磁盘阵列。它最大的优势是“专业设备干专业事”RAID由硬件控制器做不消耗服务器CPU缓存有电池保护断电不丢数据多路径软件成熟链路故障自动切换。而且光纤协议本身是块级传输比NFS或者iSCSI在延迟上更有优势。最终我们选了一台中端光纤阵列配了24块10K SAS盘做RAID10另外加了两块SSD做缓存加速。这里补充一个选型时的关键判断如果你的业务是随机小IO为主比如数据库那RAID10比RAID5合适得多虽然容量利用率只有50%但写惩罚小、重建速度快。如果是顺序大IO为主比如视频素材RAID6更划算容量利用率高还能容忍两块盘同时故障。我们当时是数据库场景所以毫不犹豫选了RAID10。2.2 光纤链路的规划要点光纤阵列不是插上就能用的链路规划错了后面全是坑。我们当时用的是8Gb FC服务器端配双口HBA卡阵列端配双控制器每个控制器出两个端口总共四条链路。交换机用了两台做冗余。这里的关键是服务器到交换机的连线、交换机到阵列的连线必须交叉分布在不同交换机上这样任何一台交换机挂了链路还能通。Zoning配置也是必须的。光纤交换机默认是所有端口互通如果不做Zoning任何一台服务器都能看到阵列的所有LUN轻则误操作写坏数据重则多台服务器同时挂载同一个LUN导致文件系统损坏。我们的做法是单initiator单target的Zoning也就是每台服务器的HBA端口和阵列的控制器端口单独划一个Zone互不干扰。虽然配置起来麻烦一点但安全性最高。多路径软件我们用的是操作系统自带的方案Linux下是multipath-toolsWindows下是MPIO。配置的时候要注意路径的优先级和故障切换策略。默认的round-robin在大多数场景下够用但如果你的阵列控制器有active/active和active/passive的区别那就要手动调整路径优先级否则流量会全跑到一个控制器上另一个闲着。2.3 容量规划和RAID策略容量规划这块我的经验是永远不要按当前需求买盘至少预留30%的扩展空间。我们当时买了24块盘RAID10之后可用容量大概10TB出头业务数据当时只有4TB看起来够用。但半年后数据涨到7TB再加上快照和克隆占用的空间差点就要扩容了。扩容虽然可以在线做但RAID10加盘需要重新平衡数据对性能有影响能避免就避免。RAID策略方面除了前面说的RAID10和RAID6的选择还有一个细节是热备盘。我们配了一块全局热备盘任何RAID组里有盘故障热备盘自动顶上开始重建。重建期间性能会下降但至少数据不会丢。热备盘的数量建议至少一块如果RAID组比较多可以配两块分别做不同控制器下的热备。注意热备盘不要选和成员盘同一批次的否则可能同时出现批次性故障。我们当时特意混了两个批次的盘虽然采购麻烦一点但可靠性提升明显。3. 核心配置细节与实操要点3.1 阵列初始化与RAID创建新阵列到手第一步是初始化。这个过程会清空所有盘上的数据所以如果是二手设备务必确认没有重要数据。初始化时间取决于盘的数量和容量24块盘大概要几个小时。初始化期间不要断电否则可能损坏控制器固件。初始化完成后通过管理界面或者串口登录阵列开始创建RAID组。我们的操作顺序是先把所有盘的状态确认为“未配置”。选择24块盘创建RAID10条带大小选256KB。条带大小的选择逻辑是数据库随机IO多条带小一点有利于分散IO如果是视频流条带大一点更好。256KB是个折中值实测下来数据库场景表现不错。创建热备盘指定一块盘为全局热备。在RAID组上创建LUNLUN大小按业务需求划分。我们当时分了三个LUN一个给数据库数据一个给日志一个给备份。这里有个细节LUN的条带对齐。如果服务器上的文件系统块大小和阵列的条带大小不匹配会出现“读-改-写”放大性能直接砍半。我们的做法是让文件系统块大小比如ext4的4K和阵列条带大小成整数倍关系并且分区时手动指定起始扇区对齐。虽然麻烦但性能差异非常明显。3.2 缓存策略与电池保护光纤阵列的缓存是性能的关键。我们那台阵列配了4GB缓存分成读缓存和写缓存。写缓存默认是“回写”模式也就是数据先写到缓存就返回成功后台再刷到盘上。这个模式性能最好但必须有电池保护否则断电会丢数据。电池保护模块需要定期检查。我们遇到过电池老化导致写缓存自动切换成“直写”模式的情况性能直接掉到原来的三分之一。排查了半天才发现是电池健康度低于阈值。所以建议每季度检查一次电池状态如果健康度低于80%就安排更换。读缓存策略有“预读”和“不预读”两种。数据库场景建议关闭预读因为随机IO多预读反而浪费缓存。文件共享场景可以开启预读顺序读性能会好很多。我们当时是数据库为主所以关了预读把缓存全留给写操作。3.3 多路径配置与链路冗余多路径配置是光纤阵列最容易被忽视的环节。很多人插上光纤线看到系统认到盘就以为完事了其实链路冗余根本没生效。Linux下的配置步骤大致如下# 安装multipath-tools apt-get install multipath-tools # 编辑配置文件 vi /etc/multipath.conf # 添加以下内容 defaults { user_friendly_names yes path_grouping_policy multibus failback immediate no_path_retry fail } # 重启服务 systemctl restart multipathd # 查看多路径状态 multipath -ll执行multipath -ll后你应该看到每个LUN有多条路径并且有一个路径组。如果只看到一条路径说明Zoning或者HBA配置有问题。我们当时有一台服务器只认到一条路径查了半天发现是交换机上一个端口没配Zoning加上之后立刻正常了。Windows下用MPIO需要在服务器管理器里添加“多路径IO”功能然后在MPIO配置里勾选“添加对iSCSI设备的支持”和“添加对光纤通道设备的支持”。配置完成后设备管理器里每个LUN会显示多个实例磁盘管理里只看到一个盘这就对了。提示多路径配置完成后一定要做一次链路切换测试。拔掉一条光纤线观察业务是否中断。我们测试的时候发现切换时间大概在2-3秒业务层有短暂卡顿但没断。如果切换时间超过10秒那就要检查failback策略和交换机配置了。4. 性能调优与实测数据记录4.1 基准测试方法与工具选择阵列配好之后不做性能测试就上线等于闭着眼睛开车。我们用的工具是fioLinux下最靠谱的IO测试工具。测试之前先规划好测试项随机读IOPS块大小4K队列深度32读比例100%随机写IOPS块大小4K队列深度32写比例100%顺序读带宽块大小1M队列深度16读比例100%顺序写带宽块大小1M队列深度16写比例100%混合读写块大小8K队列深度32读写比例7:3fio的命令行大概长这样fio --namerandread --ioenginelibaio --iodepth32 --rwrandread --bs4k --direct1 --size10G --numjobs4 --runtime300 --group_reporting测试的时候要注意每次测试前清空缓存否则第二次测试读的是缓存数据结果虚高。清缓存的方法是echo 3 /proc/sys/vm/drop_caches或者重启服务器。我们当时偷懒没清缓存第一次测出来随机读IOPS有8万清完缓存再测只有1万2差距巨大。4.2 实测数据与瓶颈分析我们那台阵列的实测数据如下24块10K SAS盘RAID104GB缓存测试项实测值理论值差距分析随机读IOPS12,00015,000受限于盘的数量和转速随机写IOPS6,5008,000写惩罚导致RAID10写惩罚为2顺序读带宽1.8GB/s2.4GB/s受限于FC 8Gb链路带宽顺序写带宽1.2GB/s2.4GB/s缓存刷盘速度限制混合读写IOPS9,000-读写比例7:3下的综合表现从数据看随机读是强项顺序写是短板。后来我们加了SSD缓存加速把随机写IOPS提升到了1万5左右效果非常明显。SSD缓存的做法是把热点数据放在SSD上阵列自动做分层。配置的时候要注意SSD的寿命建议选企业级SSD带断电保护的那种。4.3 操作系统层调优阵列调好了操作系统层不调优也白搭。我们做了以下几件事第一调整IO调度器。Linux默认的CFQ调度器适合桌面场景服务器上建议换成deadline或者noop。对于SSD缓存加速的阵列noop最合适因为阵列自己会做IO调度。# 查看当前调度器 cat /sys/block/sdb/queue/scheduler # 修改为noop echo noop /sys/block/sdb/queue/scheduler第二调整文件系统挂载参数。ext4建议加上noatime,nodiratime,datawriteback减少元数据写入。XFS建议加上noatime,nodiratime,logbsize256k提升日志性能。第三调整内核参数。vm.dirty_ratio和vm.dirty_background_ratio控制脏页回写频率数据库场景建议调低让数据尽快刷到阵列缓存。# 编辑/etc/sysctl.conf vm.dirty_ratio 10 vm.dirty_background_ratio 5这些调整做完之后数据库的写入延迟从平均8ms降到了3ms左右效果立竿见影。5. 常见故障与排查技巧实录5.1 硬盘故障与重建硬盘故障是阵列最常见的故障。我们那半年里坏了两块盘都是通过热备盘自动重建恢复的。重建时间取决于盘的大小和负载10K SAS 600GB的盘大概要2-3小时。重建期间性能会下降30%左右建议安排在业务低峰期。排查硬盘故障的步骤登录阵列管理界面查看告警日志。确认故障盘的位置槽位号方便更换。更换新盘后阵列会自动开始重建。如果没自动重建手动把新盘指定为热备盘。重建完成后检查RAID组状态是否恢复正常。注意重建期间不要拔任何其他盘否则可能导致RAID组失效。我们有一次重建的时候运维同事误拔了一块正常盘结果RAID10的另一个镜像也挂了数据差点全丢。幸好有备份恢复了一整天才搞定。5.2 链路故障与多路径切换光纤链路故障的表现是业务突然卡顿系统日志里出现“I/O error”或者“path down”之类的报错。排查步骤检查光纤线是否松动交换机端口指示灯是否正常。查看多路径状态multipath -ll看路径是否减少。检查交换机Zoning配置确认没有误删。如果是HBA卡故障更换HBA卡后重新配置Zoning。我们遇到过一次链路故障原因是光纤线被机柜门夹住了外皮破损导致信号衰减。更换光纤线后恢复正常。所以布线的时候一定要走线槽不要图省事直接拉。5.3 性能突然下降的排查思路性能突然下降的原因很多我们整理了一个排查清单现象可能原因排查方法随机读IOPS下降缓存被禁用检查电池健康度随机写IOPS下降写缓存切换成直写检查电池和缓存策略顺序带宽下降链路降速检查FC端口速率延迟突然升高硬盘故障重建检查RAID组状态整体性能下降多路径失效检查multipath状态我们有一次性能突然掉了一半查了半天发现是电池老化导致写缓存被禁用。更换电池后恢复正常。所以电池健康度检查一定要定期做不要等到出问题了才想起来。5.4 数据一致性问题的预防光纤阵列虽然可靠但也不是万无一失。我们遇到过两次数据不一致的情况都是因为服务器端文件系统损坏导致的。预防措施第一定期做文件系统检查。ext4用fsckXFS用xfs_repair。检查前先卸载文件系统或者用只读模式挂载。第二配置阵列快照。快照可以在数据损坏时快速回滚比从备份恢复快得多。我们当时每小时做一次快照保留24小时。快照会占用额外空间规划容量的时候要算进去。第三多路径配置里加上no_path_retry fail这样所有路径都断了之后IO会直接报错而不是排队等待避免应用层卡死。6. 日常运维与长期使用心得6.1 监控告警配置阵列的监控不能只靠管理界面要接入统一的监控系统。我们用的是SNMP Trap把阵列的告警推送到监控平台邮件和短信通知。关键监控项包括硬盘状态任何一块盘从“正常”变成“故障”都要告警电池健康度低于80%告警缓存状态写缓存被禁用告警链路状态任何一条路径断开告警容量使用率超过80%告警监控配好之后大部分问题都能在影响业务之前发现。我们有一次收到电池健康度告警提前安排了更换避免了性能下降。6.2 固件升级的注意事项阵列固件升级有风险搞不好会变砖。我们的经验是第一升级前一定要看Release Notes确认新固件修复了哪些问题有没有已知的坑。第二升级前做完整备份。固件升级过程中如果断电阵列可能无法启动数据虽然不会丢但恢复起来非常麻烦。第三升级要选业务低峰期升级过程中业务会中断一般需要30分钟到1小时。第四升级完成后做一次全面测试包括IO性能、多路径切换、快照功能等。我们升级过一次固件升级后多路径配置丢了重新配了一遍才恢复。所以升级后一定要检查所有配置项。6.3 扩容与数据迁移扩容有两种方式加盘和换大容量盘。加盘比较简单在RAID组里添加新盘然后做在线扩容。换盘麻烦一些需要一块一块换每换一块等重建完成再换下一块。扩容过程中性能会下降建议在业务低峰期做。数据迁移到新阵列的话我们用的是存储虚拟化或者主机层迁移。主机层迁移就是用dd或者rsync把数据从旧LUN复制到新LUN然后切换挂载点。这种方式对业务影响小但迁移速度受限于主机性能。我们迁移了4TB数据大概用了6个小时。提示迁移前一定要做一次完整备份迁移过程中不要做任何写操作。我们迁移的时候业务侧忘了停写结果迁移完成后数据不一致又花了一倍时间重新迁移。6.4 成本控制与生命周期管理光纤阵列的成本不只是采购成本还有运维成本和电费。我们算过一笔账24块盘的阵列满载功耗大概400W一年电费就要几千块。加上电池更换、硬盘故障更换、光纤线损耗每年的运维成本大概是采购成本的10%左右。生命周期管理方面我们的经验是阵列用满5年就可以考虑更换了。5年之后故障率明显上升而且新阵列的能效比和性能都好很多。更换下来的旧阵列可以做备份存储或者测试环境不要直接报废。最后分享一个小技巧阵列的缓存电池即使不用也会老化所以如果阵列长期闲置建议每半年通电一次让电池充放电一次延长寿命。我们有一台备用阵列闲置了一年再开机的时候电池已经彻底坏了只能换新。这套光纤磁盘阵列用了大半年整体感受是前期配置麻烦但配好之后非常稳定性能也满足需求。最大的坑都在细节里Zoning、多路径、缓存策略、电池健康度任何一个环节出问题都会影响业务。希望这些经验能帮你少走一些弯路。
