问存储体系结构

EN

我试图将预期的I/O需求与体系结构相匹配。对于我所做的几乎所有事情，SAN方法--如果您向它抛出足够多的磁盘--总I/Ops超过所有，但是专门的工作负载最终运行得很好。如果我已经使用了96个主轴，那么我所拥有的全部I/Ops就足以使SQL-服务器日志文件即使在同一个磁盘上运行Exchange服务器也能得到满足。

理论(I/O分离是最佳实践)的实际情况是如何设计这些大型SAN阵列。虽然四个15K RPM磁盘的顺序I/ of相当高，但许多这样的数组故意将块布局随机化，因此即使您创建了一个仅用于一个SQL日志卷的4磁盘磁盘组，也不会获得这种性能。它们可能会有一些顺序的好处，因为块大小通常比磁盘本身使用的4K要大，但是它不会是你期望的从纯顺序负载中发出的尖叫恶魔。

它起作用的地方是如果我为一个数据库建立专门的存储空间。这假设这一服务的I/O需求非常大，或者I/O SLA非常严格，因此必须有性能保证。在这种情况下，我实际上将为日志、TempDb和DB卷等内容创建离散的磁盘组。事实上，这种设计并不经常发生，也很少发生。

这取决于™。对于标准的低使用率VM，我通常会将它们中的大部分放在一些RAID 6上，并让缓存和分层处理突发事件。对于重击的Exchange服务器或Server，它们通常都有专门的LUN(s)，它们都是针对自己的需要而设计的。

不过，它确实取决于您的存储体系结构。

我很想说“是的”，因为这会让我看起来非常专业，但诚实地说，99%的时间我只需要购买我需要的任何类型的阵列(目前经历了一个大的3 3Par阶段，但多年来我已经经历了其中的大部分)，并购买了尽可能多的货架，然后用合适的数量和速度填充磁盘，然后创建符合RAID级别和性能要求的LUNs -尽管我通常不考虑性能是随机的还是连续的。我倾向于假设除了备份之外的所有东西都是随机的IO，所以根据我的假设，至少如果我获得了一些缓存或顺序的好处，那么这就是‘肉汁’。我知道这听起来有点懒散，但我照顾了很多数组，除非你有一套非常固定的要求，否则在加载数组时总是需要一些“回旋空间”，你永远无法得到正确的第一次。

这就是说，对于本地DAS，我确实要具体得多，因为这很难改变，但我通常不会使用太多。