2008年（8065）
分类： 服务器与存储
2008-12-14 16:01:53
我曾经听说过，人们的服务器数量从1000台降到了100台，同时他们还没有必要改变底层的存储基础设施。我还听说，有一个网站正在使用LTO-4来备份其整合的数据中心，而且他们仍然计划使用1Gbit的光纤通道HBA和旧服务器上的1Gbit的基础设施。鉴于1Gbit的HBA已经停产，无法对LTO-4进行检测，因而你无法那样的速度来运行磁带驱动器。这些问题给人们带来了一些麻烦。
下面让我们降低几个级别来关注一些围绕数据中心整合的问题及其将会对存储体系架构产生的影响。每当我听到有人说，他们计划要整合服务器，并且降低成本的时候，我就会反问自己，他们是否真的知道要借助什么来实现这个计划?
假设你有1000台服务器，2000个可靠的SAN连接(保证不会出现HBA故障)。如果以1Gbit的光纤通道为例，假设每台服务器的存储带宽和IOPS(每秒的I/O操作数)的利用率为20%。因为这1000台服务器中，有很多可能都已经用了10几年了，他们能够运行72GB 10K RPM驱动器，(大约每秒100次IOPS操作数和67 MB/s的持续性能)。在这期间，RAID控制器可能同时支持128个重要的I/O请求，对于很多控制器来说还能具备光纤通道的处理速率。应该指出的一点是，对于大多数这种类型的Windows应用来说，IOPS要比流式处理重要的多，因为NTFS分配数据的方式是不同的。
让我们来看一看这些问题的具体例子：
这个表格有什么问题吗?我认为存在很多问题。从服务器和存储器的带宽方面来看，总带宽大幅下滑。因为来自服务器的带宽是有限的，所以RAID带宽就不可能提高。即使以前的利用率很低(大约是存储性能的20%)，而现在你能以50%的理论带宽运行，这也是无法承受的。
我认为最大的问题就在于IOPS性能。IOPS性能提高了3.6倍，这只是杯水车薪。从1000台服务器精简到100台意味着每台服务器的IOPS会增长10倍。让我们再回到那个假设，虽然利用率为20%，但是你的CPU能力提高了10倍，因此2000个CPU可以处理更多的IOPS。显然，CPU性能的10倍提升和存储空间的10倍提升并不等于IOPS的3.6倍提升。
我还发现一个问题，一台服务器向存储器同时发出的不同应用请求越多，存储系统中的随机I/O请求就越多。如果多应用同时发出多请求的话，NFTS可以很好地持续分配数据。对于所有免费的Linux文件系统也一样，因为许多服务器虚拟化产品都是在Linux操作系统下运行的，所以在制订架构策略的时候一定要记住这一点。多I/O数据流的连续分配问题一直是文件系统开发者尝试着解决却没有成功的一大难题。至少就我所知，整合的程度越高，就越需要关注存储性能，这意味着要提高IOPS的可用性。
架构师应该做什么?
在过去的八年时间里，我们把CPU性能提高了10倍。即使你正在使用1.5万转的2.5英寸SAS驱动器，IOPS性能也仅仅提高了2.5倍，从100次IOPS提高到250次IOPS。
2.5英寸驱动器的每个驱动器的存储容量稍低一些，所以在正确架构的情况下你能更有效地使用它。现在希捷1.5万转、73GB的2.5英寸SAS驱动器IOPS性能提高了9.86倍，CPU数量和CPU性能比是10:1。这非常接近现有的CPU数量，比使用1.5万转300GB驱动器的3.6:1好很多，因为驱动器更少。
如果我正着手开发一个虚拟环境的系统架构，那么我会首先看一看现有系统的以下五个重要因素：
● 从服务器到存储器的带宽利用率是多少?
● 从服务器到存储器的IOPS利用率是多少?
● 从服务器到存储器的可用带宽是多少?
● 从服务器到存储器的总IOPS是多少?
● 底层文件系统是什么?这些文件系统如何处理同时写入的多个数据流?
上面的第五点是问题的症结所在。如果你不知道文件系统分配多I/O请求数据有多么糟糕的话，那么你就很难决定到底需要多少IOPS带宽。
IOPS随着CPU性能的提升而增加。如果CPU性能增长了10倍，那么磁盘的IOPS至少要提高10倍甚至更多。问题是，由于IOPS和带宽的原因，I/O性能并不随着密度增加而提高。记住一点，采用老系统的时候，更少的数据流流向更少的磁盘驱动器，文件系统可能连续分配数据，减少寻道和旋转延迟的开销数量。即使你可以有效地维持不变的CPU计算能力，那也有可能在使用新系统的时候要处理更多的I/O请求。现有的PCIe 2.0总线设计速度要比老式的PCI总线高许多，我发现大多数PCI总线无法达到标定的性能水平，而且没有必要达到，因为我们被局限在把1Gb光纤通道里，作为最高速度连接。新的PCIe 2.0在老系统上的带宽大约是老式PCI总线的30倍之多。相比老系统来说，能够处理更多的I/O请求可能导致驱动器层级更多的寻道和旋转延迟。
作为整合和虚拟化数据中心的架构师，你不能只拿着一份表格就想当然地在这或者在那把服务器数量精简到原来的1/10，还期望获得你预期的性能水平。你要考虑到配置的方方面面，考虑到在某些方面CPU和密度扩展比例并未保持同步。当对一个环境进行架构和虚拟化的时候，你需要考虑整个数据路径，其中包括文件系统如何在老系统上分配数据，如何在新系统中运作等等，因为随机I/O请求可能会更多。
