数据存储产业服务平台

风中岁月存储专栏:EMC存储最佳实践R22(3)

前文再叙,书接上一回

文件系统的对齐

文件系统的不对齐会在以下两个方面影响性能:

1.不对齐造成了跨硬盘的访问:一个I/O跨越了两个硬盘(正常来说是只会访问到一个硬盘)

2.不对齐会让大的没有cache的写操作,变得难以条带对齐(strip-align)

第一个情形是更加容易碰到的。就算磁盘上的操作使用了cache的缓冲,也会对(性能)产生负面的影响,因为这会使cache的flushing变慢。随机的读操作(通过正常要求的磁盘访问产生的),也会受到相应的影响,不管是直接的(等待两个磁盘的响应以便返回数据)还是间接的(使磁盘的操作比正常更加忙)。

一个通常的例子如下图所示。基于intel架构的系统是不对齐的,这是因为元数据(Metadata)是被BIOS所写的。在一个对齐的系统,64KB的写操作会由单独一个硬盘来服务。


跨越磁盘的小I/O在一些主机的类型里显得更加重要,而我们接下来将会探讨为什么会导致这种状况。

当以下情况发生的时候,跨越磁盘将会对响应时间有一个显而易见的影响:

a)有大比例的block size大于16KB的随机I/O

b)Navisphere Analyzer报告的硬盘的平均等候队列长度比4大的时候对齐4KB或者8KB边界的时候(例如Exchange和Oracle),工作负载将会从对齐中获得一些优势。但因为I/O当中,小于6%(对于4KB)或者12%(对于8KB)的I/O都会造成跨盘操作(碰巧的是他们可能会以并行的方式来完成)。这种额外的收益可能很难在实践中注意到。但如果当一个特定的文件系统和/或应用鼓励使用对齐的地址空间并且位移(offset)被注明,EMC推荐使用操作系统的磁盘管理来调整分区。Navisphere LUN的绑定位移(offset)工具应该要小心的使用,因为它可能反而会影响分层的应用同步速度。

在intel架构系统中的文件对齐

intel架构的系统,包括windows2000/windows2003,都会受到在LUN上元数据的位置的影响,这也会导致磁盘分区的不对齐。这是因为遗留的BIOS的代码问题,BIOS里面用的是磁柱,磁头和扇区地址来取代LBA地址。

(这个问题一样影响了使用intel架构的linux操作系统,正如windowsNT,2000,和2003。这个问题也一样影响了运行在intel硬件上的VMWare系统)

fdisk 命令,正如windows的Disk Manager,把MBR(Master Boot Record)放在每一个SCDI设备上。MBA将会占用设备上的63个扇区。其余可访问的地址是紧接着这63个隐藏分区。这将会后续的数据结构跟CLARiiONRAID的stripe变得不对齐。

在linux系统上,这个隐藏扇区的多少取决于boot loader和/或磁盘管理软件,但63个扇区是一个最常遇到的情况。对于VMware,位移(offset)是63。

在任何情况下,这个结果都为确定的比例的I/O而导致不对齐。大的I/O是最受影响的。例如,假设使用CLARiiON默认的stripe element 64KB,所有的64KB的I/O都会导致跨盘操作。对于那些比这个stripe element的小的I/O,会导致跨盘操作的I/O的比例,我们可以通过以下公式来计算:

Percentage of data crossing=(I/O size)/(stripe element size)

这个结果会给你一个大致的概念,在不对齐的时候的开销状况。当cache慢慢被填充的时候,这种开销会变得更大。


<未完待续>

未经允许不得转载:存储在线-存储专业媒体 » 风中岁月存储专栏:EMC存储最佳实践R22(3)