存储系统----测量性能（2）

23ee

文件布局
传统的存储系统提供可预测的性能。如果你知道有多少事务要处理，你就能预测存储系统需要多少磁盘。例如，假设你要处理10000个事务，存储有10K的SAS驱动组成，一个10K的SAS的IOPS大约是140，因此你需要142个10KSAS驱动器。71个足够承受10K读，但配置RAID1+0，数量要翻倍。如果你要处理大量tempdb操作，那么你需要适当大小的用于tempdb的驱动器。倘若这样，用于主数据文件的预期I/O中，大约20%，即2000 IOPS，要用于tempdb，RAID10配置中需要28个磁盘来支持tempdb数据库。
你当然希望备份负载能够是完全连续的。记住，SATA驱动执行连续操作非常好，所以它们是转储（dump）驱动器的极好候选，与SAS或FC磁盘相比，这种驱动通常是更低成本更高容量。大型的SATS驱动器以一种非常紧凑的格式存储数据，这使得它们面临更大的故障风险，同时，在RAID系统从第一次故障中重新生成数据之前，也增大了二次故障的可能性。因此，RAID6是保护数据磁盘的一个理想的候选。RAID6有最大的性能开销，所以适当调整备份I/O是重要的。大部分情况下，备份I/O不应超过512KB传输大小。
最后，你需要计划你的日志驱动，日志对延迟非常敏感。因此，你应该完全把日志隔离到它自己的RAID10 SAS磁盘驱动器集中。你期望连续的I/O，因此，磁盘数取决于容量，而不是随机的性能I/O。把日志驱动和备份驱动混在一起，会引起磁头过度搜寻，这个过度的磁头搜寻被称为大块随机存取（large block random access）。过度搜寻能降低一半潜在的IOPS：15K SAS Max Seek: 90 = 1,000 ÷ (9 + ((60,000 ÷ 15,000) ÷ 2))。
隔离连续性能不只用于日志文件，在数据库中，你常常要确定特殊的数据表被连续访问，在一个主存储卷上，分离连续的访问会极大地降低性能要求。在写入负载非常重的大型数据库中，检查点进程常常能压垮存储阵列。SQL Server检查点试图保证一个数据库能够在默认设置的1分钟内，从一个计划外的中断中恢复。在极短的时间内，这会产生巨大的数据尖峰电压（spike）。
SQL Server 2008和2008 R2，你可以用-k命令行选项启动SQL Server（-k后面的数字代表每秒钟检查点允许刷的最大MB），这个选项能够消除检查点在长时间恢复和改变写入行为方面的影响。SQL Server 2012有一个 称之为间接检查点的新特性，下面的语句能够激活间接检查点：

• ALTER DATABASE <Database_Name>  
• SET TARGET_RECOVERY_TIME = 60 SECONDS  
  

很多组织使用共享存储阵列和精简存储池来提升存储利用率。记住，存储池合并的不仅有容量，而且还有性能。前面推荐数据、日志、备份和tempdb文件隔离到各自的物理存储。然而，在一个存储池中，如果存储是共享的，那么隔离就不再有意义。目前分离的理由是保护数据，在故障域里分散他们。换句话说，就是不要把所有的鸡蛋放在一个篮子里。建议要确保数据库备份和物理数据存放在不同的存储组里，甚至不同的存储 阵列。一旦你的应用系统在共享的精简存储池上运行，性能监视是个关键。如果你的应用系统对其他应用系统产生负面影响，把它移除共享存储环境并放到一个分离的系统中，常常更加有利，更加划算。
分区对齐
Windows Sever 2008之前的版本没有恰当地把分区对齐到存储体（underlying storage geometry），尤其是Windows隐藏了63KB的扇区。NTFS分配单元默认为4K，常常分为2个，因为隐藏的分区是奇数，所有的NTFS分区单元都是偏移的。这 就导致了可能产生两倍的NTFS请求数。任何使用Windows 2008 或更新的OS创建的分区都会自动创建扇区对齐。如果一个卷是使用Windows 2003或更老OS创建的，那么它就可能出现扇区没有对齐的情况。不幸的是，没有对齐的分区必须重建，才能正确地对齐。更多关于扇区对齐额信息，可以看看这篇博客：http://sqlvelocity.typepad.com/blog/2011/02/windows-disk-alignment.html。
NTFS分配单元大小
格式化分区时，有个分配单元大小的选项，默认为4KB。分配单元决定了磁盘上文件占用的最小空间，以及主文件表（$MFT）的大小。如果一个文件是7KB大小，它将占用两个4KB的分配单元。SQL Server文件常常很大，Microsoft推荐使用64KB的分配单元大小，用于数据、日志和tempdb。请注意，如果你使用大于4KB的分配单元，Windows就会禁用NTFS数据压缩（这不会影响SQL Server压缩）。为SQL Server的大文件创建更少大簇（cluster）比创建更多小簇要高效很多。虽然大簇对一些小文件是有效率的，但反过来，对很过小文件同样有效率。这有可能用完簇，浪费存储容量。
簇大小最佳实践有些例外，当你使用SQL Server文件流去存储非结构化的数据是，要确保使用合适的扇区大小来格式化用于主机文件流数据的分区，通常是4K。SSAS读写Cube数据到XML小文件，因此也应该使用4K扇区大小。
闪存
基于NAND的闪存可以替代硬盘。删除没有移动部件，因此提供一致的读取性能，它不会受随机I/O的影响。删除比传统的硬盘要贵很多，但这个成本可由它的I/O性能来抵消。一个15K的硬盘仅能执行大约180 IOPS，然而，一个闪存能执行20000或更多。可以确信，RAID10中用两块闪存可以替换220个15K的硬盘。使用闪存理想的情况是，当应用程序有相当小的数据集，并且有非常高的性能要求。OLTP和SSAS数据Cube是利用闪存性能优势的极好例子。NAND闪存对读取请求最高效。写入闪存是项非常复杂的操作，它要花费比读取操作更长的时间。擦除NAND闪存的数据块是一项更耗资源的操作。混合读写会降低闪存潜在的性能。如果一个磁盘能够处理20000或30000读操作，它或许只能支撑5000个写操作。
不是所有的闪存都是一样地被创建，创建闪存有单层（SLC）和多层（MLC）两种技术。SLC更贵但效能更高，MLC使用多层堆叠单元格，这些单元格共享一个晶体管。这使MLC制造成本更低，但它有降低性能、增加潜在故障率的缺点。企业MLC（eMLC）是更新一代的闪存技术，它增加了多级闪存（multi-level Flash）的可靠性和性能。选购闪存前，理解闪存能承受多少读写是重要的。如果应用系统产出超大量的I/O请求，闪存可能表现不错；相反，如果产生一些大请求，例如DW应用系统，那么闪存可能就没多大用处。
一些厂商销售一种基于闪存的PCI express NAND闪存设备。这些卡片提供高I/O比率下非常低的延迟。单个卡片能在数十微妙响应，产生数百数千的IOPS。与之相比，共享阵列要响应数百微妙，甚至毫秒。如果应用系统产生这类的I/O负载，这些卡片能极大提升潜在的性能。这种卡片不仅能支撑数百数千的I/O，每个返回也更快。这能缓解很多SQL阻塞问题。
我们强调你的应用系统必须能够产生适当的I/O，因为很多客户对低性能失望时，把安装闪存当初灵丹妙药。如果应用系统受限于不好的设计，那么在新技术上撒钱往往不能解决问题。
现在有混合的基于PCI express的解决方案，它把服务器软件、PCI express闪存卡和共享存储阵列合并在一起。这些系统会监视I/O访问模式，如果工作负载合适，数据就会在PCI express闪存卡片上存放和访问。为了保持数据完整性，数据也会存放在共享存储阵列上。这种混合方式有利于超大数据集，其不适合一串闪存。另外，SAN功能，例如复制，也能与这项新技术混合。
很多共享存储阵列提供闪存解决方案来增大阵列的缓存。这些系统工作类似于PCI express混合解决方案，除了闪存存放在共享存储阵列。适量的数据迁移到闪存，因此提升性能。如前面所诉，如果阵列认为访问模式不合适，那么数据就不会移动。突发性的繁重写入任务就是一个例子。试图写入30000 IOPS的大量检查点可能永远不会提升到闪存，因为要访问的数据时刻在改变。
共享存储阵列与闪存驱动器混合分层及自动分层。当你考虑大多数数据库时，在给定的时间内，仅仅数据的一个子集在使用。在一个OLTP系统，你关心新写入的数据，和需要在短时间内访问到的数据。一旦过了一个销售季度或年度，这些数据基本上被归档。一些DBA迁移这种归档数据。自动分层提供了低开销的系统，它可以积极地监视数据使用。活跃的数据被推送到闪存层；中等访问程度的数据迁移到FC或SAS层；归档的数据自动存放在高容量的SATA。
存储性能测试
各个工作负载是不一样的。没有单一的存储系统能够解决每种技术或业务问题，任何系统在投入生产部署前都必须要验证。你应该在验证和测试之间加以区别。如果你能用精确地副本重建生产系统，并且精确运行相同的工作负载，你的结果应该可以反映（mirror）生产状况。验证允许管理员收集有用的数据，并在随后将其应用到真实问题上。
微软提供了两个有用的性能测试工具：用于系统验证的SQLIOSim和用于性能测定的SQLIO。 SQLIOSim用来模拟SQL Server I/O，可以看成是功能测试工具。它会给SQL Server、Windows Server和存储施压，但不能施压到最大性能。SQLIOSim可以从http://support.microsoft.com/kb/231619下载。准备开始之前注意，如果延迟超过15秒，SQLIOSim会报告一个错误。对于I/O而言，偶然的高延迟完全正常。我们推荐使用GUI来运行功能系统测试（如果4-13），尽管这个工具也能通过命令行执行。

SQLIO是一个生成I/O的工具。这个应用程式通过命令行执行，不需要SQL Server运行。下载SQLIO可从：http://www.microsoft.com/en-us/download/details.aspx?displaylang=en&id=20163。安装SQLIO后，打开param.txt，其默认路径是C:\Program Files (x86)\SQLIO，该文件包括如下代码：
c:\testfile.dat 2 0x0 100
#d:\testfile.dat 2 0x0 100
param文件的第一行定义测试文件放在哪里。使用井号（#）来注释一行。第一个数字定义每个测试文件的线程数，微软推荐设置为CPU内核数。掩码就设置为0x0，最后的数字定义测试文件的大小（MB）。确保测试文件足够大到超过专用于存储卷的缓存数。如果主机文件太小，它最终将存放在阵列缓存内。SQLIO是为每个实例运行一个特定工作负载而设计的。每次使用参数执行SQLIO.exe，都会定义一个特定类型的I/O。针对同一个测试文件，并行执行多个SQLIO实例完全是允许的。最好从确认一些可计算额假设开始。如果你有100个10K SAS磁盘配置在RAID10中，你可以假设随机I/O会执行14000读。要测试这样的假设，执行一个SQLIO.exe实例：
sqlio –kR –s300 –frandom –o1 –b8 –LS –Fparam.txt
-k选项设置R（read）或W（write）。-s设置测试运行多久，推荐至少几分钟（实例使用5分钟），时间太短的话，不能精确反映一个大型RAID控制器缓存的运行状况。相似的测试之间暂停也是重要的，否则，阵列缓存会复用已存在的数据，可能使结果出现偏差。-f选项设置运行I/O的类型，random或sequential。-o参数定义未完成的I/O请求数。-b选项定义I/O请求的大小（KB），SQL Server通常至少读取64KB。-LS用于收集系统的延迟信息，64位的系统上你可以添加-64来激活选项，以充分利用64位内存系统。最后使用-F选项定义param.txt文件的位置。下面是测试输出：
sqlio v1.5.SG
using system counter for latency timings, 14318180 counts per second
parameter file used: param.txt
file c:\testfile.dat with 2 threads (0-1) using mask 0x0 (0)
2 threads reading for 300 secs from file c:\testfile.dat
using 8KB random IOs
enabling multiple I/Os per thread with 8 outstanding
size of file c:\testfile.dat needs to be: 104857600 bytes
current file size: 0 bytes
need to expand by: 104857600 bytes
expanding c:\testfile.dat ... done.
using specified size: 100 MB for file: c:\testfile.dat
initialization done
CUMULATIVE DATA:
throughput metrics:
IOs/sec: 13080.21
MBs/sec: 102.18
latency metrics:
Min_Latency(ms): 0
Avg_Latency(ms): 0
Max_Latency(ms): 114
histogram:
ms: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24+
%: 37 59 3 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
这个测试完美地展示了一个系统未能利用最大潜在性能。要正确测试一个特定的系统，动态测量工作负载以确定在增加负载的情况下如何执行是个不错的主意。要完成这个，你可以写如下SQLIO脚本：
sqlio –kR –s300 –frandom –o1 –b8 –LS –Fparam.txt
sqlio –kR –s300 –frandom –o2 –b8 –LS –Fparam.txt
sqlio –kR –s300 –frandom –o4 –b8 –LS –Fparam.txt
sqlio –kR –s300 –frandom –o8 –b8 –LS –Fparam.txt
sqlio –kR –s300 –frandom –o1 –b16 –LS –Fparam.txt
sqlio –kR –s300 –frandom –o1 –b32 –LS –Fparam.txt
sqlio –kR –s300 –frandom –o1 –b64 –LS –Fparam.txt
sqlio –kR –s300 –frandom –o1 –b128 –LS –Fparam.txt
sqlio –kR –s300 –frandom –o1 –b256 –LS –Fparam.txt
在命令行运行这个批文件，并把结果捕获到一个输出文件：RunSQLIO.bat > Result.txt
理想状况下，你会测试几个不同的场景。创建一个批文件，每个场景未完成I/O的范围从1到256，例如下面的：
小块随机读性能：sqlio –kR –s300 –frandom –o1 –b8 –LS –Fparam.txt
小块随机写性能：sqlio –kW –s300 –frandom –o1 –b8 –LS –Fparam.txt
大块连续读性能：sqlio –kR –s300 – fsequential –o1 –b8 –LS –Fparam.txt
大块连续写性能：sqlio –kR –s300 –fsequential –o1 –b8 –LS –Fparam.txt
以一个批文件的形式执行这些场景，会自动化I/O系统测试过程。最重要的数据点是延迟和性能测量。当测试超出你的最大延迟容忍度，通常不差过20毫秒时，就超出了I/O子系统的能力。如果系统不能满足你整体的性能要求，那么你需要调查系统的错误或配置问题。最后，你或许需要优化存储系统的性能，以确保满足前面设定的要求。
概要
数据库专家能够通过设计、测试及监视存储系统来避免I/O问题。你不需要一个专门的存储专家来确保可靠的系统性能，只要遵循下面这些简单的指南：

• 设计和计划数据库系统时要包括I/O系统
• 经常测试存储系统的功能和性能
• 持续监视存储性能，确保存储系统满足需求
• 为恢复及灾难做好计划。把你的计划文档化，并测试它，以确保它能被执行。