企业官网建设流程全解析

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-tools，Windows下是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组。我们的操作顺序是：

1. 先把所有盘的状态确认为“未配置”。
2. 选择24块盘创建RAID10，条带大小选256KB。条带大小的选择逻辑是：数据库随机IO多，条带小一点有利于分散IO；如果是视频流，条带大一点更好。256KB是个折中值，实测下来数据库场景表现不错。
3. 创建热备盘，指定一块盘为全局热备。
4. 在RAID组上创建LUN，LUN大小按业务需求划分。我们当时分了三个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 基准测试方法与工具选择

阵列配好之后，不做性能测试就上线，等于闭着眼睛开车。我们用的工具是fio，Linux下最靠谱的IO测试工具。测试之前先规划好测试项：

• 随机读IOPS：块大小4K，队列深度32，读比例100%
• 随机写IOPS：块大小4K，队列深度32，写比例100%
• 顺序读带宽：块大小1M，队列深度16，读比例100%
• 顺序写带宽：块大小1M，队列深度16，写比例100%
• 混合读写：块大小8K，队列深度32，读写比例7:3

fio的命令行大概长这样：

fio --name=randread --ioengine=libaio --iodepth=32 --rw=randread --bs=4k --direct=1 --size=10G --numjobs=4 --runtime=300 --group_reporting

测试的时候要注意：每次测试前清空缓存，否则第二次测试读的是缓存数据，结果虚高。清缓存的方法是echo 3 > /proc/sys/vm/drop_caches，或者重启服务器。我们当时偷懒没清缓存，第一次测出来随机读IOPS有8万，清完缓存再测只有1万2，差距巨大。

4.2 实测数据与瓶颈分析

我们那台阵列的实测数据如下（24块10K SAS盘，RAID10，4GB缓存）：

从数据看，随机读是强项，顺序写是短板。后来我们加了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,data=writeback，减少元数据写入。XFS建议加上noatime,nodiratime,logbsize=256k，提升日志性能。

第三，调整内核参数。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%左右，建议安排在业务低峰期。

排查硬盘故障的步骤：

1. 登录阵列管理界面，查看告警日志。
2. 确认故障盘的位置（槽位号），方便更换。
3. 更换新盘后，阵列会自动开始重建。如果没自动重建，手动把新盘指定为热备盘。
4. 重建完成后，检查RAID组状态是否恢复正常。

注意：重建期间不要拔任何其他盘，否则可能导致RAID组失效。我们有一次重建的时候，运维同事误拔了一块正常盘，结果RAID10的另一个镜像也挂了，数据差点全丢。幸好有备份，恢复了一整天才搞定。

5.2 链路故障与多路径切换

光纤链路故障的表现是：业务突然卡顿，系统日志里出现“I/O error”或者“path down”之类的报错。排查步骤：

1. 检查光纤线是否松动，交换机端口指示灯是否正常。
2. 查看多路径状态，multipath -ll看路径是否减少。
3. 检查交换机Zoning配置，确认没有误删。
4. 如果是HBA卡故障，更换HBA卡后重新配置Zoning。

我们遇到过一次链路故障，原因是光纤线被机柜门夹住了，外皮破损导致信号衰减。更换光纤线后恢复正常。所以布线的时候一定要走线槽，不要图省事直接拉。

5.3 性能突然下降的排查思路

性能突然下降的原因很多，我们整理了一个排查清单：

我们有一次性能突然掉了一半，查了半天发现是电池老化导致写缓存被禁用。更换电池后恢复正常。所以电池健康度检查一定要定期做，不要等到出问题了才想起来。

5.4 数据一致性问题的预防

光纤阵列虽然可靠，但也不是万无一失。我们遇到过两次数据不一致的情况，都是因为服务器端文件系统损坏导致的。预防措施：

第一，定期做文件系统检查。ext4用fsck，XFS用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、多路径、缓存策略、电池健康度，任何一个环节出问题都会影响业务。希望这些经验能帮你少走一些弯路。