围绕4KB扇区硬盘,由于大家在这方面了解的基础不同。可能会有如下的疑问:
1、为什么会有4KB扇区硬盘?好处在哪里?2、原生4KB扇区和模拟512byte,兼容性有什么差别?3、4KB扇区对性能的影响4、软硬件生态系统,需要做哪些配合?5、SSD目前主要还是仿真磁盘块设备来使用,它是512byte还是4KB设备呢?6、在RAID阵列和虚拟机环境,硬件与Guest OS之间多了一个抽象层,这是否也会影响到4KB兼容?
以上6点相互关联,因此在本文中都会有所涉及。首先引起我们注意的是,近日有一份来自戴尔的资料,其中提到了2.5” 2TB 7.2K NLSAS(近线SAS)HDD的引入,这款硬盘采用的是512byte仿真扇区大小。
上表列出了3种硬盘扇区格式类型。512n——物理格式化和向主机呈现的逻辑扇区字节数均为512byte,早期的硬盘都是这样;512e——物理扇区大小为4096字节,逻辑上仿真为(8个)512字节扇区,为了兼容性的一种过渡;4Kn——即原生4KB,物理和逻辑扇区字节数都是4KB。
4KB扇区硬盘与生态系统概述
由于IT栈中的组件默认针对512b扇区大小已经30年了,下面我们来看看针对4KB扇区硬盘,整个生态系统需要分析/升级的地方。
服务器BIOS/UEFI – 支持4K可能需要UEFI – 传统BIOS需要修改来增加针对4KB原生驱动器的支持。
存储控制器(HBA)– 驱动和firmware需要改变。
RAID stack(位于RAID卡和阵列控制器)–驱动和firmware需要改变。
OS stack – 操作系统必须是4K感知才能使用4K原生驱动器;512e驱动器对于许多组件都支持,但是扇区对齐决定了获得最好性能。
文件系统 – 基于不同OS版本,这里可能有一些问题。微软对NTFS 做了一些改动,针对在Windows 7/2008 R2中支持512e。
应用 – 需要理解那些进行unbuffered(未缓冲)写入的应用。
Hypervisors – 512e可以被用于当前的微软/VMware hypervisors(性能可能变差),但 VHD 1.0是硬性编码到512 byte并且没有当前的hypervisor支持4K原生 – 必须支持VHD 2.0规范来获得4K原生支持。
开发工具 – 分区对齐对于在512e 驱动器上达到最好性能是个关键。4K原生– 还没有数据来理解开发方面的问题。
什么是4KB高级格式化、路线图
如上图,原生512n每个扇区都有50bytes的ECC纠错码;4KB扇区将这个ECC区域合并、扩大(但没有50bytes的8倍那么大),并省去了间隔、地址标记等空间,因此格式化效率提升到大约97%,并且能否检测和纠正更大的介质错误。
也就是说,在磁记录密度不变的情况下,“高级格式化”能够提供更大的实际可用容量。随着硬盘上的记录单元——磁极尺寸不断缩小,容量增速放缓,4KB扇区是未来大容量硬盘的趋势。
参考上图,512byte原生扇区硬盘的生命周期将在2017年终止(部分企业级产品和老型号可能例外)。按照这个之前的预计,以3.5” 7200转为例最大是4TB,超出该容量物理扇区只有4KB了?实际上我们看到有硬盘厂商推出6TB 512byte物理扇区的型号,包括密封充氦7碟片和非充氦普通6碟片,但继续增大容量还是需要4KB扇区。
4KB扇区仿真512byte已经广泛应用于客户端,毕竟即使出现写放大或者未对齐写入产生更多I/O,PC用户对磁盘性能也没有那么敏感,但企业级应用则要保守多了。除了4KB扇区仿真512byte,原生4KB扇区硬盘直到2014年晚期才发布针对企业级市场的版本,它无法工作在Windows Server 8(2012)之前的操作系统,并且与上文中我们介绍的生态系统密切相关。
物理、VMware虚拟机环境的“对齐/非对齐”写入
这一段的几张截图来自IBM的一份文档,其中“Misaligned”和“Aligned”分别表示在使用512e硬盘时非对齐和对齐的4KB I/O块操作。由于4KB块(比如对应文件系统的页面)操作需要先以8个512bytes逻辑扇区写入到硬盘,再合并记录到4KB物理扇区,在非对齐的情况下,一个4KB逻辑写I/O对应到2个物理磁盘扇区,如果是新写入就会产生2次I/O;若是改写之前物理扇区中的数据,则需要读-更改-写的操作,这种非原子写入(non-atomic)最多可能产生4次I/O。
而对齐的情况则简单多了,尽管中间要经过硬盘模拟512bytes扇区的过程,但每个4KB的I/O操作都是对应到一个物理扇区。属于比较理想的情况。
我们参考下这个表格里不同操作系统对高级格式化的感知情况。其中,Windows从Server 2008开始能够感知512e硬盘并自动对齐分区;Server 2012进一步加入了对原生4Kn设备的支持。RHEL 6可以感知512e和4Kn硬盘并能自动对齐;SLES 11能感知512e和4Kn硬盘却无法自动对齐?VMware ESXi 4.x和5.x都无法感知512e和4Kn硬盘,但支持自动分区对齐。这里有必要进一步解释下。
首先对于Windows Server 2003、RHEL 5和SLES 10来说,512e硬盘首先是可以用的,只是操作系统“意识不到”而当成512n来用了。微软如今已经停止了对Server 2003的支持(戴尔等厂商为用户提供迁移方案和服务),如果我们在这些较早的操作系统上使用第三方分区工具,或者手动指定开始扇区建立对齐的分区,应该可以规避一部分性能影响。
对于4Kn来说,这三款操作系统应该就没有办法兼容了,同样的还有VMware ESXi 4.x和5.x。尽管,VMware Hypervisor支持自动分区对齐(VMFS-3和VMFS-5分别以第128和2048为起始扇区),但目前的ESXi 6.0和VSAN版本还是无法感知512e和4Kn,其中512e硬盘由于潜在性能问题而不被VMware官方支持。
上图截自VMware网站,供大家参考
这张图演示了在虚拟化环境下对齐和非对齐分区的情况。当“Aligned”对齐时,在Hypervisor层VMFS-5的文件块大小统一为1MB,子块(Sub-Blocks)大小8KB正好对应2个物理扇区上的16个逻辑扇区。此时如果虚拟机的OS block正好与VMFS子块对齐的话,等于就是与物理磁盘扇区对齐了,这样还算好一些的情况。
而对于“Misaligned”未对齐配置,如果要写入到虚拟机中的OS block 1,有2个VMFS子块被写入,并且每个子块需要2次读-修改-写周期(指改写而不是写入空白块,因为每半个VMFS block在“错位”情况下也会对应到2个物理扇区)。这样就有可能在底层产生8次I/O?
我们在VMware网站查询了更多关于4KB扇区兼容的情况,这方面应该还在遥远一些的Roadmap中。毕竟对于Hypervisor而言广泛的向后兼容性相当重要,512e我觉得将来会支持,而如果上层虚拟机就是要在4Kn硬盘上进行512byte的磁盘I/O,软件厂商没义务去做这个转换啊。
既然VMware如此,估计KVM和Xen的情况也不会好多少,对此我了解有限就不班门弄斧了。而Hyper-V可能是个特例吧,因为微软虚拟化平台上跑Windows虚拟机比较多,那么用VHD 2.0规范的4K原生磁盘格式运行Server 2012虚拟机应该不会出问题。
“对齐”并不代表性能就完全达到512n的水平,如果是小于4KB的随机写入512e硬盘还是会产生写放大或者惩罚。上面的软件兼容情况也适用于RAID卡和磁盘阵列的LUN,因为操作系统和虚拟机HyperVisor对它们是与本地磁盘同样的方式来看待。下面我们再来谈一下磁盘控制器对4KB扇区的兼容支持情况。
PERC卡和MD控制器的4KB扇区支持
如上图,左边是比较早的戴尔服务器SAS RAID卡、HBA、主板集成软RAID和MD家族阵列控制器。它们能够支持512e仿真扇区的硬盘,对于较早的操作系统可能需要补丁、对齐工具(比如让NTFS文件系统的簇与物理扇区对齐)和驱动更新。
对于这些传统磁盘控制器,对上层主机呈现的LUN(逻辑盘)都是512byte扇区。
到了新一代的PERC 9、MD38xx阵列控制器,以及未来的服务器软件RAID,已经能够支持原生4K扇区硬盘,并提供给主机4K格式的LUN。有同行朋友说这样做在一些场景下有性能的改善,也听到有专家说微乎其微。而我们想提醒大家的是:在选择这种“前卫”的配置之前,部分存储产品已经做好了准备,但上层软件兼容性需要用户自己注意,参考包括本文在内的资料,征询工程师/技术顾问的建议,必要情况下进行测试。
如上图,这台戴尔服务器配置了PERC 9系列RAID卡中的H730P Mini,它识别到当前选定SAS硬盘的物理和逻辑扇区大小都是512Byte。
组建RAID之后的虚拟逻辑盘(LUN),自然也是512Byte扇区格式。当您阅读本文到这里,在此机器上如果换成512e或者4Kn的硬盘,会产生什么样的结果、有哪些注意事项就比较清楚了吧?
SSD的“扇区”是多大?
这里也要提一句SSD,据我们了解目前大多数的SAS/SATA SSD,在RAID卡和磁盘控制器管理程序中显示的物理和逻辑扇区大小都是512Byte,同样是兼容性考虑。其实闪存的最小写入单元——页面大小目前一般为4KB或者8KB,那么“扇区”也都是模拟出来的。测试反映这种模拟对性能的影响不大,因为FTL的存在,数据在SSD上的逻辑地址与物理闪存位置的对应关系都是可变的,来自主机小于4KB的写入也可能会合并到一个闪存页面上。
PCIe SSD(闪存卡)的情况不太一样,有些厂商在出货时“格式化”为4KB扇区,如果遇到软件应用不兼容的情况(比如Oracle数据库等),可以使用专门的工具转换格式为512byte扇区大小。
当存储虚拟化网关遇上“4KB LUN”
从前端到后端都呈现4KB也许会在未来某个时候流行。而对于存储控制器而言,使用原生4KB扇区硬盘,却向上给主机呈现512byte的LUN单从技术实现上看却也可行,只要您不在乎性能打折扣——小于4KB的IO都会被放大至一个硬盘扇区,一次下发8个512byte写请求也可能会落到2个4KB扇区上(如果文件系统/应用层未对齐的话)。
这就是在控制器层面的“欺骗”,之前讲的512e是在硬盘层面上“欺骗”。
欺骗一词,用在这里并不是贬义。RAID技术本身就是将一组硬盘“虚拟化”为一块盘呈现给主机。由此我们还联想到被戏称为“上骗主机,下骗阵列”的存储虚拟化设备,它们与RAID控制器最大的不同就是其后端管理的存储单元由磁盘/SSD变成了阵列的LUN。
存储虚拟化对于后端阵列表现为“主机”,而在前端主机看来它又是一台“阵列”,基本原理可以简单解释为用Initiator导入LUN,再将其用Target导出给主机,中间可选加入数据服务。目前我们还没留意到有存储虚拟化产品宣称兼容4KB扇区格式的LUN?这一点在技术上实现估计并不是太难,关键取决于兼容性测试的工作量,以及实际的需求。
举例来说,一些存储虚拟化产品根据设置会在后端设备的LUN上再做一次条带化,以前都是按照512byte扇区来考虑,数据切块大小可以直接按一定数量扇区来计算就行。而如果扇区大小变成4KB,要是继续保持原有扇区数的话就意味着“条带”增大了8倍。对于导出给前端主机的LUN容量,也会存在类似的问题。
总结硬盘厂商对4KB扇区支持的动力毋庸置疑,但在逻辑上是否继续模拟512byte则取决于生态系统的进展。
对于企业存储而言,由于一些传统应用(如:Oracle数据库)的I/O操作最小单位仍小于4KB,使用原生512byte扇区硬盘可以保证最好的性能;模拟512byte能够兼容,但容易产生性能影响;至于原生4KB硬盘,则要求文件系统、卷管理器具备相应的支持,否则会报错。
目前一些比较新的服务器、磁盘阵列上的存储控制器,已经能够兼容原生4KB硬盘