我的任务是为外部组织制定 SAN 策略。我不是系统管理员，我们无权管理这些系统。我也不是 SAN 专家。谁说工作必须有意义？
根据相关供应商提供的文档（目前运行 SAN 的外部组织没有仔细研究这些文档），我总结出了一些要点。例如“不要将高 I/O 测试存储与生产数据存储放在同一个切片上”，这些要点似乎显而易见，但实际上并非如此。
有没有关于应采取哪些通用 SAN 约定来提高性能和可靠性的建议？
对于我们的设置（EMC 硬件、DB2），这些是我拥有的关键项目：
- 理想情况下，SAN 的每个逻辑单元 (LUN) 将分布在多个物理设备上，以允许并发 I/O，从而提高性能。
- 每个 LUN 应专用（例如，特定应用程序的 DB2 存储）
- 对于 DB2 事务日志应位于与表数据物理上分开的主轴或主轴组上的单独 LUN 上
- 数据 LUN 应为 RAID-5，因为它可以提供最佳性能，但冗余度会降低
- 日志 LUN 应为 RAID-10，以提供最大冗余度
- 如果将 LUN 设置为使用文件系统而不是原始分区（建议这样做），则表空间应使用无文件系统
- CACHING 子句以提高性能
答案1
在制定政策之前，了解您要定义政策的目的会很有用。是为了实现最佳性能？数据保护？还是关于公司保留政策的具体内容？我们可以根据您的陈述假设它只是一份通用的性能/可靠性文档吗？
我之所以问这个问题，是因为 SAN（就像任何网络设备一样）通常都是根据角色进行定制的。它的硬件配置会极大地影响人们为它提出的建议。例如，SQL LUN 通常由多个快速驱动器（取决于主轴）组成时效果最佳，而用户共享或存档数据等则更适合更大、更慢的卷（您似乎知道这一点）。话虽如此，我很难明确定义 RAID 级别，因为不同的供应商对此有不同的看法。例如，EMC 可能认为 RAID10 是首选，而 NetApp 认为 24 主轴 RAID 6 是理想的。
一般来说我会说：
- 将数据 LUN 与数据库/日志 LUN 隔离
- RAID 级别和主轴数应由应用程序和供应商建议决定
- 将低优先级数据（如用户共享和存档数据）放在最慢的磁盘上
- 理想情况下，数据库/日志 LUN 具有多个小型、快速的驱动器，以增加主轴数量
- I/O 密集型应用程序应该在控制器之间进行拆分（如果可以的话）
- 如果您有一个需要隔离的测试环境以限制其对生产环境的影响（单独的控制器/卷）
除了这些非常通用的选项之外，很难再为您提供更多建议，因为您会开始考虑供应商、硬件和应用程序特定的建议。您还会考虑安全和公司政策。与创建通用 SAN 指南相比，您可能更擅长定义特定应用程序的要求。
答案2
每个 LUN 都应分布在存储目标后端的主轴上，但回到前端适配器，可能的需求（# 交换 * 交换大小 * 服务器数量）应该平衡。例如，如果我不改变我的服务器，它们的队列深度可能为 254。如果我的交换每个为 4 帧（8k），那么这些服务器中的每一个都可以阻塞 2k 的 FA。我希望平衡我的 SAN，以便总可能负载和某些时间的可能负载（当日常流量没有时备份流量命中）保持平衡。随意定义 QueueDepth 限制，并捕获超出该限制的人。如果您不知道如何捕获 QD 违规者，我可以向您展示。
我还会尝试执行一项策略：如果您不使用 SAN，您将不会被分区，并且您的端口将处于离线状态。许多环境为所有服务器提供 SAN，但它们不会立即（永远？）在 SAN 上联机。但它们往往会反复打开/关闭/打开/关闭/打开/关闭，正是这些设备导致了整个架构中的更新风暴。让我们在它们成为问题之前扼杀它们。
将设备放入默认/机箱 VSAN 或 VF：Cisco 上的 VSAN0001 或 Brocade 上的 VFAB128。当用户决定端口需要放在哪里时，将其移动到 VSAN 或 VF。VSAN0001 或 VF128 不通过 ISL/XISL——这降低了广播风暴风险。
新设备应该让请求者指示它们是单路径还是多路径，如果是多路径，则指示它们是主动被动、平衡多路径还是不平衡多路径，以便当它们不平衡时，您可以看到是否发生了配置问题或多路径工具是否行为不当。
命名一切。别名很有用。有一个命名方案，这样 Oracle14_HBA0 会让你期望 Oracle14_HBA1。当出现问题时，这会有所帮助：你可以决定 Oracle14_HBA0 是否值得现在起床，或者等到下一个工作日。
要求请求者根据延迟（毫秒）与需求（MB/秒或 IOPS）来请求存储。他们会想说“Tier1！Tier1！我的东西很棒，我需要 Tier1”，但不知道那是什么。推动 SLA，例如“200MByte/秒 40ms”，这是 2GB 单路径链接的相当容易的延迟。如果他们不知道，那么告诉他们“40ms @ 200mb/秒”，然后等待他们重申。他们最终会将数据库意图日志 LUN 的延迟改为 9ms，但不会立即生效，并且您将只在需要它们的地方使用价格昂贵的闪存支持的 SAS LUN。
VMAX 速率限制是您的好帮手：在突发需求触发您的阵列进入写入挂起状态之前抑制它。参见上文：“40ms @ 200MB/sec”。
这些是基于同时向多达 50 人教授光纤通道并观察他们遇到的问题而产生的一些想法。
答案3
其他人已经给出了建议，我将补充一些我自己的建议：
每台服务器必须有两条物理上不同的存储路径。这意味着每台服务器有两个 HBA，通过两个独立结构上的两组完全独立的 SAN 交换机，到达两个不同的后端控制器。不要为了省钱而购买双端口 HBA - 它提供带宽，但不提供弹性。（如果可能的话，让光纤使用不同的物理路由穿过服务器机房）。
一切采用多路径。至少两条路径，如果需要更好的性能，可以添加更多路径。
对 HBA 和控制器使用别名。将这些别名划分为区域。坚持使用单个启动器分区。如果您不完全理解其含义，则最不可能出现问题。根据区域所包含的内容命名区域。可选择在区域名称中包含逻辑分组。（例如“oracle_clus2_hostname_HBA0_array_port4”）
询问性能，预计会得到“不知道”或“很多！”之类的答案。这类问题很少能得到好的答案，但在整合的存储环境中，这一点很重要。整合的全部目的是获得更好的峰值性能和更低的平均性能——这适合大多数工作负载，因为“面向用户”的操作更关心单个事务响应（而不关心它是否空闲）。
不要纠结于 RAID 类型 - 它可能只是一种干扰。缓存比 RAID 类型更有影响力，而且缓存对不同类型的工作负载有不同的影响。
读取 IO 受到严格的时间限制 - 为了完成对主机的读取，阵列有从磁盘获取块。缓存预取并尝试猜测下一步需要什么 - 因此可预测的读取 IO 比随机读取更快。
写入 IO 受到软时间约束 - 您可以写入缓存，并向主机确认写入 - 稍后再将其卸载到磁盘。这意味着您可以做一些很棒的事情，例如写入合并和全条带写入，并显著减少 RAID 类型的“开销”。因此，对于日志/日记等顺序工作负载，RAID-5 实际上可以比 RAID 1+0 更快。
经常使用的术语是‘写入惩罚’——需要多少个磁盘操作才能‘完成’一次写入[1]。
- RAID 0，写入惩罚为 1 – 每次写入都需要一个写入 IO。
- RAID 1-您对两个镜像都进行写入，因此写入惩罚为 2。
- RAID 5 - 您需要写入主轴，读取/更新奇偶校验。写入惩罚为 4。
- RAID 6 - 与 raid 5 类似，但具有两次奇偶校验计算，因此写入惩罚为 6。
这意味着对于纯随机写入工作负载 - 您需要将每个主轴的理论可用 IOP（FC 为 ~150，SATA 为 ~75）除以此写入损失。
对于所有 RAID 类型，“读取惩罚”基本相同 - 您需要从阵列中的某个位置完成读取。RAID1 会给您带来一些优势，因为它可以从两个不同的位置读取，看看哪个响应更快，但优势不大 - 磁盘仍然必须旋转和寻道。
使用条带合并（大多数阵列都可以通过顺序写入来实现），您可以减少写入损失。例如，如果您拥有 RAID 5 的所有奇偶校验条带，则无需读回奇偶校验，可以根据缓存中的内容计算。在这种情况下，写入损失降至 1+ 1/Raidgroup 大小，因此对于 4+1 RAID 5 组：1.25。这意味着更好的对于持续的串行写入工作负载，RAID 1+0 的效果优于 RAID 1+0。（例如数据库日志）
弹性 - 您需要进行一些不同的计算，但我还是要说 - 不要太纠结于 RAID 类型 - 无论如何，如果您有足够长的时间线，您都会遇到复合故障，因此这里没有缓解需要一个合适的恢复解决方案。 RAID 类型之间存在弹性差异，但您绝对不应该使用的唯一类型是 RAID0 :)。
（存在其他自定义 RAID 类型。例如，NetApp 使用他们称为 RAID-DP 的东西来实现双重奇偶校验。它基本上是带有额外奇偶校验主轴的 RAID-4，但由于 NetApps 使用其“WAFL”文件系统的方式，实际上具有非常低的写入损失）