San Performance – 连接的服务器数量

SAN的性能涉及很多variables，所以我可以理解为什么人们不会太多的了解它们。

任何给定的SAN都有其主要组成部分，它们是有限的，

• 控制器/这个/这些服务器处理请求，所以它们的整体计算能力和IO能力都是关键 – 如果控制器跟不上，没有多less高速磁盘和/或多个8 / 10Gbps接口是没有意义的。 控制器本身可能受限于devise，组件年龄，caching/当然还有他们运行的软件。
• 磁盘 – 明显是288 x 15krpm FC磁盘将比4 x 2TB SATA磁盘更快 – 但您通常购买SAN磁盘有两个原因，只是给你容量，有时创造性能 – 当然，如果你有兴趣那么你需要考虑其他的一切。
• IO接口 – 如果控制器或磁盘无法跟上，那么通常没有大量的8 / 10Gbps接口。

我很幸运，我经常为了一个目的而构buildSANarrays – 无论是数据库工作还是video内容，还是大video内容，都要尽快build立SANarrays – 我有这样的奢望，可以为每个function获得单独的系统，但每隔一段时间我都需要build立一个涵盖了两个位的东西，这是我所做的;

• 我将最快的可用IO端口用于需要性能的系统/子平台 – 这样，这些机器（通常是我的经验中的DB）可以获得专用端口的全部带宽，而其他服务器则不需要这些跺脚遍布可用带宽。 我还购买了专用高性能（即SSD和/或15k FC）磁盘，并将其装载到适当数量的机架中，以便为特定的SAN（即，带有EVA盒等的8个机架的块）实现最佳性能。 如果SANarrays能够进行硬分区，我还会将一个分区（以及某些caching）专用于该function。
• 然后，我将剩下的IO端口中的大部分用于主stream的性能生产系统，这样它们可以集中在一起，它们不会受到高性能系统和低性能系统的交叉干扰，而且我可以合理快速地购买（通常为10krpm FC / SAS）磁盘，我可以根据需要select在专用分区中运行这些磁盘。
• 然后我把其他辅助/testing/参考/备份等服务器放在剩下的一对端口上，知道他们并不关心性能，也不太可能使端口饱和。 然后，我可以愉快地分配他们慢（7.2krpm的SATA / FATA）磁盘（我有时不得不专门购买>占空比> 30％的磁盘）。

如果以这种方式规划出系统，那么当您添加服务器和负载时，您会看到渐进的，不是陡峭的，可预测的性能下降。 很明显，你没有提到你的arrays或使用模式的任何细节，但有一些情况下，单个服务器可能饱和DS3400 / NetApp，并有几千个服务器会离开同一个箱子剩余容量的海洋 – 这是真的确实涉及到系统devise和理解你的使用模式。

当你有更多的数据时，请随时回到我们这里。

不取决于系统的数量，而是取决于系统的function。 SQL +交换是沉重的用户。 特别是SQL可以使用很多光盘来正确运行（就像任何数据库一样），但是完全取决于你的操作。 我曾经见过一个有190个专用磁盘的SQL Server。 我自己的一个现在在6张光盘上，即将升级。

我不认为 – 除了技术上的限制 – 这里的指导是可能的一般条款。