存储区域网络可能很复杂。如果管理不善时，情况更加严重。故障排除非常困难，因为很少有好的设计，而且光纤通道标准的宽松程度会使互操作性成为问题。
光纤通道(FC)存储区域网络已被iSCSI SAN取代，成为很多数据中心的块存储选择。然而，尽管iSCSI是成本更低的替代方案、更易于管理，还可使用熟悉的以太网网络技术，并且可以共享现有的LAN，但是当需要高性能块存储时，FC仍然是首选协议。因此，尽管出现其他替代方案，它仍然是大多数企业中重要的存储替代方案。
对于FC SAN，重要的是要了解常见问题，以便弄清楚如何诊断和解决问题，或者首先是如何防止出现问题。
常见问题
在复杂的存储网络中，很多事情都可能出错。FC是从零开始构建，以支持网络存储系统，因此，对于管理，除了需要常规网络知识，还需要大量的专业化知识。同时，还应注意，在过去的几年中，通过自动化某些功能并减少LUN配置等的所需步骤，FC SAN供应商已经简化阵列管理。
也就是说，保持FC SAN的性能仍然是一个挑战，但是根据问题的不同，你可以将问题缩小到潜在的原因，以加快故障排除和解决的速度。主要常见问题包括以下：
1. 兼容性问题
尽管FC SAN已经存在近三十年，但并不是所有设备都能很好地兼容。我们经常会看到很多SAN问题源自不兼容的组件。所有存储供应商都会发布某种形式的支持矩阵(通常称为硬件兼容性列表(HCL))，其中他们会记录存储阵列微码、SAN交换机固件和主机硬件/软件的经过测试和受支持的配置。使用HCL以外的硬件或软件，SAN可能会在一段时间内正常运行，但是这种做法存在风险，这会使故障排除性能问题变得更加困难。
2. 超出容量限制
显然，饱和的SAN端口会导致瓶颈问题，而这些瓶颈问题可能会转变成难以诊断的应用程序问题。通常，我们很容易查看SAN的主机或存储端口，并确定它是否100%繁忙，但我们很难确定过载的交换机间链接(ISL)是否是问题根源。有时I / O本身不是瓶颈，而是限制问题(例如风扇比率-分区到存储端口的主机总线适配器(HBA)的数量)-以及超过架构中交换机的数量，从而导致连接问题。
FC交换机供应商通常会提供软件，以帮助检测瓶颈问题，甚至可能提出解决方案。另外还有可用的第三方应用程序，例如SolarWinds系列产品、NetApp的OnCommand应用程序和用于SAN的IntelliMagic Vision，它们可以洞悉SAN的运行情况以跟踪和缓解瓶颈。这些第三方工具通常支持多种不同的存储品牌和型号，因此它们在混合供应商环境中可能特别有用。这类工具已经存在一段时间，最初统称为存储资源监视器;这些工具在开始时并没有引起关注，因为它们很复杂，但现在它们已经精简，并已增加功能和提高可用性。
3. 错误配置或分区
糟糕或不正确分区是SAN问题的最常见原因之一。也许是因为我们最经常更改SAN分区。这也可能很常见，因为区域包含那些棘手的16位十六进制全球通用名称(WWN)。
4. 易出故障的连接和电缆
当光纤电缆发生故障时，似乎很少会完全失效。通常它们会出现间歇性问题，并缓慢失效。在这个过程中，应用程序和管理员会适应间歇性问题。由于大多数SAN环境支持多种电缆类型，这些问题可能会更加复杂，因此监控工具会有所帮助，它们可从各种电缆介质返回准确结果。
5. 存储阵列配置问题
每个品牌的存储阵列的管理方式略有不同，但是它们都基于一些基本概念。LUN必须通过前端SAN端口创建并分配给HBA。当存储管理员在配置阵列时输入错误时，经常会出现问题。手动创建LUN是繁琐的过程，因此容易出错。
6. 主机配置问题
服务器方面很容易出现问题。网络环境中的服务器代表着SAN组件堆栈的很大部分，其中包括卷管理器、操作系统、多路径软件、HBA驱动程序、HBA固件和HBA硬件。所有组件都必须根据存储供应商的规范进行配置;与供应商规范的任何偏差都可能导致问题。在大多数企业中，服务器虚拟化显着增加运行服务器的数量。除了增加服务器配置问题外，由于有大量其他服务器，虚拟服务器可能还需要服务器管理员进行一些特殊设置。
7. SAN硬件故障
在常见的SAN问题中，硬件故障排在最后，这是因为，尽管它通常是我们关注的首要问题，但实际很少发生这种问题。现在的SAN硬件非常可靠，但硬件确实偶尔会出现故障。影响主机访问的常见故障是SFP端口故障、端口卡故障和整个交换机故障。
8. 缓慢的存储响应时间
存储网络是复杂的环境，其中包含很多组件，必须正确设置和仔细监视，但是性能问题也可能是由存储设备本身引起。数据存储介质将对整体SAN性能产生深远影响。现在，大多数存储阵列至少都包含SSD，因此，性能调整可能涉及切换到固态存储或添加更多的SSD。如果很多应用程序都需要高性能，则可能需要使用全闪存阵列。如果你坚持使用仅硬盘驱动器的阵列，那么就需要挤出额外的性能，但传统的调整(例如，短暂敲击磁盘驱动器)可能会带来额外的麻烦。
问题确定
当你对SAN进行故障排除时，你需要深入了解特定系统的所需配置和预期行为。当发生问题时，通过排除SAN、主机和存储中正常运行的组件，可以更好地瞄准问题。
- SAN。最近是否发生SAN变更?询问一下其他人员，检查SAN日志，然后将正在运行的配置与文档进行比较。SAN报告时间或错误是否相关?查找失效端口、最近端口注销或架构重建。
- 主机。其他主机能否看到有问题的存储?该主机能否看到其他存储?HBA是否日志记录在架构中?最近是否发生任何主机更改?主机的系统消息日志中是否有与SAN相关的消息?
- 存储。其他主机能否看到有问题的存储?存储端口是否日志记录到架构中?最近是否发生任何存储更改?是否有存储阵列日志报告错误?
如果使用变更管理软件，则将显著简化上述所有检查工作。变更管理应用程序还可以帮助提醒支持人员注意可能被孤立或不包含在备份操作中的任何服务器或数据存储。
避免将来出现问题
检查支持矩阵
请定期检查存储供应商的HCL和其他支持材料，以对比当前支持的内容与你的配置。并且，制造商不断通过新代码修复漏洞，你还应检查是否有任何更新，并保持软件版本最新和受支持-这将有助于避免很多问题。
(1) 记录SAN
这个很重要。在解决问题时，了解原始的SAN环境设计意图非常重要。请确保文档记录了主机、HBA、WWN及其连接位置。其中应包括存储、存储端口及其WWN。最后，SAN文档应描述架构、ISL、区域集、区域和区域成员。
如果没有原始设计文档，则你应该能够使用SAN管理或变更管理应用程序来发现和记录所有网络设备-而且，在很多情况下，还应该记录关键配置信息，例如网络地址。
(2) 基准化SAN性能
除非你记录每天发生的事情，否则很难确定繁忙的端口是正常情况还是问题的罪魁祸首。请至少记录SAN中每个端口的平均端口利用率。如果你使用SAN监视工具，则它可能可以做到这一点-实际上，在建立可接受的性能阈值后，当出现异常时，大多数监视应用程序都会发送电子邮件或文本警报。SAN监视应用程序还提供仪表板，以实时了解网络状态和单个网络组件。
(3) 计划你的变更
为避免管理员引起的中断，请使用SAN文档来定义变更，然后再进行变更。如果你在执行变更时才决定要做什么，那么你就错了。而且，在变更发生后很容易忘记记录变更。某些变更管理应用程序还将使你能够进行“假设分析”，以测试预期的变更对SAN环境或与其连接的存储系统的影响。
(4) 备份配置
在每天SAN变更后，请备份并安全地存储交换机配置。当交换机出故障或在变更期间完全混乱，这将确保你可以从备份中快速回滚变更。为了更加安全，请配置备份应用程序，以在日常数据备份操作期间定期备份所有关键配置文件。
当某些事情在控制之中且网络环境被很好地映射，解决SAN问题可能是相对容易的过程。 请将这些最佳做法作为日常SAN健康方案的一部分，以避免当出现故障时造成更大的问题。
