摘要：随着需求的增长与技术的进步，存储虚拟化被赋予新的内涵。业界普遍认为利用虚拟化技术能使存储的效率、可管理性明显提升。设备总体拥有成本大幅下降。卓越的性能优势，使存储虚拟化迅速成为业界关注的焦点。

　　从CPU、内存、主板到服务器，当越来越多的IT系统核心构件选择投身虚拟化阵营时，谁将是虚拟化阵营的下一个受益者?从目前的发展态势看，服务器虚拟化渐成主流。存储极有可能成为下一个因虚拟化而发生重要变革的IT构件。
　　
　　1、存储虚拟化概述
　　
　　事实上，存储虚拟化的概念并不新鲜.它是伴随大型计算机的发展而出现的一个经典概念。早在上世纪70年代，由于当时存储设备的容量小、价格高，大型应用程序或多程序应用都受到了极大的限制。为克服这一局面，人们开始采用存储虚拟化技术。所谓的存储虚拟化.是指对硬件资源抽象化。以虚拟形式来表示它们。虚拟化可将物理存储系统从数据驱动的具体工作负荷中分离出来，从而使你能够随心所欲地按需分配存储资源。虚拟化包括将多个物理存储资源池化成一个虚拟的存储资源，然后可对其实施集中管理或者以逻辑方式将其分区成若干个虚拟机。虚拟化还可用于使磁盘对应用程序呈现为磁带。
　　
　　随着需求的增长与技术的进步，存储虚拟化被赋予新的内涵。业界普遍认为利用虚拟化技术能使存储的效率、可管理性明显提升。设备总体拥有成本大幅下降。卓越的性能优势，使存储虚拟化迅速成为业界关注的焦点。但令人费解的是，尽管各大厂商极力推广，存储虚拟化却始终叫座不叫好。甚至有业界专家预言，目前谈论存储虚拟化还为时尚早。那么，究竟是何原因导致如此有竞争力的技术却迟迟无法打破僵局?
　　
　　有三个主要原因导致了存储虚拟化的应用进展迟缓。首先。存储虚拟化产品在几年前价格普遍较为昂贵且专注于高端用户，IT决策者对虚拟化技术的了解程度普遍较低，存储厂商和用户对虚拟化持观望态度。其次，存储系统的标准化进程缓慢，直到今天，各存储厂商虚拟化产品同的整合仍然困难重重。最后。存储虚拟化领域存在孤军奋战的现象，厂商间始终未能合力共谋发展。事实证明，只针对存储本身.而忽略其他IT组件的虚拟存储方案很难获得用户的认同。
　　
　　2、服务器虚拟化的催化效应
　　
　　与存储虚拟化的裹足不前形成鲜明对照，服务器虚拟化狂飙突进。全球越来越多的用户选择部署虚拟化技术对服务器进行整合。从而大幅度降低总体拥有成本、简化服务器的管理程序、实现服务器的快速部署、保证数据中心的可靠性。
　　
　　服务器虚拟化迅速普及，虚拟化的理念深入人心，使IT业界重新审视存储系统的虚拟化问题。事实上，服务器虚拟化将是存储虚拟化向前推进的重要力量。
　　
　　首先，服务器虚拟化为存储虚拟化的最终落地提供了绝佳的应用平台。从虚拟化发展的历程看。在PC服务器采用虚拟化之前，存储虚拟化多在Unix小型机上采用，并不适用于Windows/Linux等x86平台。直至1998年，VMware公司率先将虚拟化技术引入x86平台。这使存储虚拟化的应用得以扩展至PC服务器，从而挣脱了平台的束缚。
　　
　　其次.服务器虚拟化本身已将存储虚拟化层包含其中。以VMwarevStorage为例。它是目前市场上唯一可供生产环境使用的服务器虚拟化套件--VMwareInfrastructure的核心技术与接口之一。VMwarevStorage采用虚拟化技术创建了高效而灵活的存储池，不仅简化了虚拟机的存储操作过程。还可以直接利用存储基础架构的各项功能，为在虚拟环境中使用和管理存储系统提供了最有效的方式。
　　
　　作为VMwareInfrastructure的重要组件。VMwareStorageVMotion在共享存储位置之间和跨共享存储位置上重新分配虚拟机磁盘文件，保证了服务供应的连续性和事务处理的完整性。而VMwarevStorageVMFS是使用共享存储的群集文件系统，作为存储架梅中额外的虚拟化层。它可以让用户将虚拟机后台的存储资源作为一个大型LUN来进行管理。
　　
　　目前，VMware的虚拟化技术已全球客户提供服务。以一汽一大众为例，他们在实施虚拟化的过程中，也利用VMware的存储虚拟化技术整合了存储资源，对数据中心实施分级存储。将原先部署在一百多台服务器上的应用整合到四十多台服务器上，并在后端连接SAN存储。这种后端连接存储、多台服务器整合构成ServerFarm的方式，启用了ESXServer3高效可用、在线迁移等高级特性，显著地提升了服务器的可用性和可靠性。
　　
　　3、有效融合相得益彰
　　
　　需要注意的是，虽然服务器虚拟化已将部分存储虚拟化纳入自己的管理，但这并不意味着服务器虚拟化可以与存储虚拟化完全割裂。
　　
　　存储虚拟化有"存储设备层的虚拟化"和"服务器层存储虚拟化"的区分。前者是指在存储设备的物理一级进行的虚拟化。雨后者则是在服务器层进行的对LUN级别的存储虚拟化，即我们常说的逻辑卷管理(LVM)。例如VMware虚拟架构层中实现的存储虚拟化便属于服务器层的存储虚拟化，但又超出一般LVM的功能，因为它可以快捷地整合不同类型的存储。
　　
　　一方面。服务器层的虚拟化为存储设备层的虚拟化搭建了绝佳的平台。另一方面，如果存储设备本身没有虚拟化能力，任何RAID级别或其他配置的调整等都会引起存储设备的停机，并导致相关虚拟机停机的情况发生。这意味着。服务器层的虚拟化和存储设备层的虚拟化需要更好地融合，才能将虚拟化的价值完美地释放。
　　
　　作为业界最领先的服务器虚拟化方案供应商。VMware公司目前正与包括EMC、IBM、HP等在内的业界厂商广泛合作，联手推出服务器虚拟化和存储虚拟化的整合方案。这必将极大地推动存储虚拟化向前发展。
　　
　　4.两者之间如何做好同步
　　
　　相比采用大量的服务器及增加一些虚拟化软件如VMware来说，有些人会更加关注数据中心整合。当然，你也可以同时拥有数据中心整合和应用软件虚拟化。
　　
　　我曾经听说过，人们的服务器数量从1000台降到了100台，同时他们还没有必要改变底层的存储基础设施。我还听说，有一个网站正在使用LTO-4来备份其整合的数据中心，而且他们仍然计划使用1Gbit的光纤通道HBA和旧服务器上的1Gbit的基础设施。鉴于1Gbit的HBA已经停产，无法对LTO-4进行检测，因而你无法那样的速度来运行磁带驱动器。这些问题给人们带来了一些麻烦。
　　
　　下面让我们降低几个级别来关注一些围绕数据中心整合的问题及其将会对存储体系架构产生的影响。每当我听到有人说，他们计划要整合服务器，并且降低成本的时候，我就会反问自己，他们是否真的知道要借助什么来实现这个计划?
　　
　　假设你有1000台服务器，2000个可靠的SAN连接(保证不会出现HBA故障)。如果以1Gbit的光纤通道为例，假设每台服务器的存储带宽和IOPS(每秒的I/O操作数)的利用率为20%。因为这1000台服务器中，有很多可能都已经用了10几年了，他们能够运行72GB10KRPM驱动器，(大约每秒100次IOPS操作数和67MB/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请求。现有的PCIe2.0总线设计速度要比老式的PCI总线高许多，我发现大多数PCI总线无法达到标定的性能水平，而且没有必要达到，因为我们被局限在把1Gb光纤通道里，作为最高速度连接。新的PCIe2.0在老系统上的带宽大约是老式PCI总线的30倍之多。相比老系统来说，能够处理更多的I/O请求可能导致驱动器层级更多的寻道和旋转延迟。
　　
　　作为整合和虚拟化数据中心的架构师，你不能只拿着一份表格就想当然地在这或者在那把服务器数量精简到原来的1/10，还期望获得你预期的性能水平。你要考虑到配置的方方面面，考虑到在某些方面CPU和密度扩展比例并未保持同步。当对一个环境进行架构和虚拟化的时候，你需要考虑整个数据路径，其中包括文件系统如何在老系统上分配数据，如何在新系统中运作等等，因为随机I/O请求可能会更多。
　　
　　责任编辑：Echo