我负责为外部组织定义SAN策略。 我不是系统pipe理员，这不是我们有权威的系统。 我也不是SAN专家。 谁说工作有道理？
我已经根据供应商提供的文档提出了一些要点（目前正在运行SAN的外部组织还没有仔细研究过）。 诸如“不要把高I / Otesting存储与Prod数据存储放在同一片上”，这看起来应该是显而易见的，但显然不是这样。
关于一般SAN协议的任何build议都应该提供，以提高性能和可靠性？
具体到我们的设置（EMC硬件，DB2）这些是我有的关键项目：
在编写一个策略之前，知道你想要定义一个策略是很有用的。 这是为了达到最佳性能吗？ 数据保护？ 有关公司保留政策的具体内容？ 我们能否认为这只是一个基于你的陈述的通用性能/可靠性文件？
我问的原因是一个SAN（像任何networking设备）通常被定制为适合一个angular色。 它的硬件configuration可以大大影响人们可能为之提供的build议。 例如，当SQL LUN由多个快速驱动器（主轴相关）组成时，通常是最好的，而像用户份额或归档数据这样的更适合更大，更慢的卷（您似乎意识到这一点）。 也就是说，由于不同厂商对此有不同的看法，我很难确定RAID级别。 例如，EMC可能认为RAID10是首选，而NetApp认为24主轴RAID 6是理想select。
一般来说我会说：
除了这些非常通用的选项之外，您将很难给出更多的select，因为您开始涉足供应商，硬件和应用程序特定的build议。 您还将了解安全和公司政策。 在定义特定应用程序的需求方面，您可能比创build通用的SAN指南更成功。
每个LUN应分布在存储目标后端的主轴上，但是返回到前端适配器时，可能的需求（交换数量*交换数量*服务器数量）应该平衡。 例如，如果我不改变我的服务器，他们可能会有一个254的队列深度。如果我的交stream是每个4帧（8K），那么每个服务器可以扼杀2K的FA。 我想要平衡我的SAN，以便在可能的负载总量和特定时间的可能负载（日常stream量不支持的备份stream量）之间达到平衡。 随意定义QueueDepth限制，并捕捉超过它的人。 如果你不知道如何抓住QD违规者，我可以告诉你。
我也会尝试执行一项政策：如果您不使用SAN，则不会划分区域，并且您的端口将处于脱机状态。 许多环境为所有服务器提供SAN，但是它们不会立即（在前）在SAN上联机。 他们倾向于打开/closures/打开/closures/打开/closures，而这些设备会导致整个织物的更新风暴。 在他们成为问题之前先扼杀他们。
将设备放入默认/机箱VSAN或VF：思科的VSAN0001或博科的VFAB128。 当用户决定端口需要的位置时，将其移动到VSAN或VF。 VSAN0001或VF128不通过ISL / XISL – 这可以降低广播风暴的风险。
新的设备应该让请求者指出他们是单path还是多path，如果是多path，无论是主动被动，平衡多path还是非平衡多path，这样当他们不平衡时，你可以看到一个configuration问题已经发生或者多path工具行为不当。
命名一切。 别名帮助。 有一个命名scheme，这样Oracle14_HBA0会让你期待一个Oracle14_HBA1。 这有助于解决问题：您可以决定Oracle14_HBA0是否值得现在起床，或等到下一个工作日。
要求请求者根据需求（MB /秒或IOPS）以延迟（ms）为单位请求存储。 他们想要说“Tier1！Tier1！我的东西是岩石的，我需要Tier1”而不知道那是什么东西。 推送一个SLA，比如“40ms for 200MByte / sec”，这在2GB单path链路上是一个相当容易的延迟。 如果他们不知道，那就告诉他们“40ms @ 200mb / sec”，然后等待他们重申。 他们最终会将数据库意向日志LUN移至9毫秒，但不会立即生效，而且您将只为需要它们的地方安装价格超高的由闪存支持的SAS LUN。
VMAX限速是你的朋友：在触发你的arrays进入待写状态之前，压制这个突发的需求。 见上面：“40ms @ 200MB /秒”。
这些都是基于教授FibreChannel一次可以容纳多达50人的一些想法，并且看到他们拥有的问题。
其他人已经提出了build议，我会添加一些我自己的build议：
每个服务器必须有两条物理上不同的path来存储。 这意味着每个服务器有两个HBA，通过两个完全独立的SAN交换机在两个独立的结构上传输到两个不同的后端控制器。 不要吝啬购买双端口HBA – 这样可以提供带宽，但不具有弹性。 （如果可能的话，通过服务器机房使光纤使用不同的物理路由）。
多path的一切。 至less有两条path，如果需要更好的性能，则增加更多。
使用HBA和控制器的别名。 区域到这些别名。 坚持单一的发起者分区。 如果不完全理解其含义，那么导致问题的可能性最小。 根据它们包含的内容命名您的区域。 可以在区域名称中包含逻辑分组。 （'eg'oracle_clus2_hostname_HBA0_array_port4）
询问performance，期待得到'不知道'或'很多！ 键入答案。 在这样的问题上得到很好的答案是非常罕见的，但是在整合的存储环境中这一点很重要。 整合的关键在于获得更好的峰值性能和更低的平均值 – 这适合于大多数工作负载，因为“面向用户”的操作更关心单个事务响应（并且不关心闲置）。
不要挂在RAIDtypes – 它可以是一个红鲱鱼的位。 caching比RAIDtypes有更多不同，caching以不同方式影响不同types的工作负载。
读IO是在一个困难的时间限制下 – 为了完成对主机的读操作，arrays必须从磁盘读取数据块。 高速caching预取并尝试猜测接下来需要什么 – 所以可预测的读取IO比随机快。
写入IO处于软时间限制之下 – 您可以写入caching，并确认写入主机 – 并在稍后退出到磁盘。 这意味着你可以做一些很好的事情，如写合并和全条纹写入，并显着降低RAIDtypes的“开销”。 对于诸如日志/日志等顺序工作负载，RAID-5实际上可以比RAID 1 + 0更快。
通常使用的术语是“写入惩罚” – 需要多less次磁盘操作才能“完成”写入[1]。
这意味着对于一个纯粹的，随机的写入工作量 – 您需要将每个主轴的理论可用IOP（FC约为150，SATA约为75）分开。
对于所有raidtypes，“读取惩罚”基本相同 – 您需要从arrays中某个地方完成读取操作。 你从RAID1中获得了一些微小的优势，因为它可以从两个不同的位置读取，看哪个更快响应，但是没有多less – 磁盘仍然需要旋转和寻找。
使用条带合并（大多数数组可以通过顺序写入），您可以减less写入损失。 例如，如果您的RAID 5拥有所有奇偶校验条带 – 您不需要读取奇偶校验，则可以从caching中的内容中计算出奇偶校验。 在这种情况下，写惩罚下降到1 + 1 / Raidgroup大小，所以对于4 + 1 RAID 5组：1.25。 这意味着对于持续的串行写入工作负载，它比RAID 1 + 0 更好 。 （如数据库日志）
韧性 – 你有一些不同的计算，但我仍然会说 – 不要太在这里RAIDtypes挂起 – 如果你有足够长的时间线，你会得到复合失败，所以这里没有减轻需要一个体面的恢复解决scheme。 RAIDtypes之间有弹性差异，但唯一一个你绝对不应该使用的是RAID0 :)。
（其他自定义RAIDtypes也存在，例如NetApp使用称为RAID-DP的双重奇偶校验，基本上是带有额外奇偶校验主轴的RAID-4，但由于NetApp使用“WAFL”文件系统的方式，罚款）