原来Advanced Format HDD已经普及了

数据库 Oracle
硬件发展虽然没有我们想象的那么快,只不过DBA的硬件知识更新的太慢了。以至于现代硬件数年前就已经研究的很清楚的问题,我们今天才去关注。如果不是那个Oracle的BUG,我可能还停留在HDD 512扇区的惯性里。这种知识的学习,什么时候是个头啊,选择DBA这个职业,真的得保持一颗学习的心。

​DBA对现代硬件的了解总是不足够的,虽然说有时候不了解这些东西,也不影响我们搞数据库运维。不过多了解一些这方面的知识总是好的。7、8年前我们刚刚开始使用SSD的时候遇到过4K扇区的问题,SSD盘分区的时候没有对齐性能会有影响。甚至弄得不好,存储在SSD盘上的Oracle Redo Log还会给你弄出点性能问题。

在一个朋友提出了一个Oracle 问题之前,我一直没有关注过目前普通机械盘是否也存在4K扇区的问题。直到前几天,一个朋友发了一个补丁,问512e是个啥意思。

图片

这是一个Oracle 19C的BUG,在运行于RHEL/CENTOS 8的19.3的Oracle上,如果使用了ASMLIB,并且ASM磁盘组的磁盘包含512e的磁盘,则查询v$asm_disk的时候会出现CORE DUMP。而如果往这个磁盘组中添加磁盘的时候,甚至会导致整个磁盘组损坏。问题够吓人。

512e这个概念在数年前搞SSD盘的时候就大致了解过,学名叫512字节扇区仿真访问模式。在一些不支持原生态4K扇区的场景下,通过512字节的逻辑扇区来访问4K物理扇区的SSD设备也是以前经常用的方法。而这个BUG出现在HDD上,难道现在HDD也开始使用4K扇区了吗?于是我马上谷歌了一下,发现一种称为Advanced Format Hard Disk的磁盘技术在十多年前就已经开始出现了,而2014年后,大部分的硬盘企业都推出了企业级的AF硬盘。

图片

关于4K扇区磁盘的好处,我在这里简单的讲一下,首先磁盘越来越大,4K盘可以在使用相同的寻址空间上获得更大的存储空间,另外一点,因为元数据的减少,也提高了磁盘容量的实际使用率,从硬盘厂商发布的数据看,使用4K扇区后,磁盘空间可用量多了7%以上。而从他们发布的性能数据上看,对于顺序读,顺序写的性能,采用4K扇区后都是有所提升的,随机读的性能略高(不知道这种略高是不是磁盘技术带来的,从转速和读取的性能上实际上是没有什么提升的),随机写的性能略有下降,不过几乎可以忽略。磁盘场厂商的数据告诉你,方向使用4K HDD吧,性能是没问题的。我咨询了一些国内的一些这方面的朋友,他们告诉我性能差异可以接受如果对齐边界,看不出明显的差别。不过不同的场景下,这些指标可能会有不同。只不过无论我们接受不接受,今后4K扇区的Advanced Format HDD肯定是标配了。

图片

上面这个磁盘上面的红框中的LOGO就是4KN磁盘的标识。如果我们仔细查看一下自己手头的硬盘,应该可以发现存在这样的标识:

图片

我们可以看到上面有两种LOGO,一种是512e的,另外一种是4Kn的,这是两种新的磁盘扇区访问的模式。AF是指本磁盘是4K一个扇区的,不过支持512逻辑扇区访问模式,操作系统可以把我当成512字节扇区的磁盘来访问。4Kn是指磁盘本身是4K扇区的,并且支持OS以4K本地访问的模式来访问这个磁盘。再加上原来的物理扇区就是512字节的磁盘,其访问模式称为512n,这三种磁盘访问模式就是我们日常能够遇到的HDD的访问模式。

于是我们的HDD世界中存在两种扇区规格,512和4K。为了向前兼容,4K扇区的磁盘也搞了一个512e的仿真访问模式,使原来的应用可以不做修改就能够访问4K扇区的磁盘。于是磁盘访问模式出现了3种:1)512n,其物理扇区和逻辑扇区都是512字节的,这是以前的传统访问模式;2)512e,其磁盘的物理扇区是4K的,不过为了兼容原有的系统,在分区的时候选择了512逻辑扇区大小;3)4Kn,其物理扇区与逻辑扇区都是4K的,系统采用原生4K的方式去访问这些磁盘。

图片

Linux从RHEL/CENTOS 6开始支持原生的4Kn,之前都是通过512e的硬盘格式仿真访问。如果你采用4Kn的硬盘格式,那么是不需要考虑任何分区对齐之类的问题的。而如果你使用512e的方式,那么就必须认真考虑对齐的问题了。因为如果分区不做4K对齐,那么原本一个IO可以搞定的问题,就可能因为边界问题而要使用2个IO了,IO数量翻了一倍,对磁盘的压力也大了,IO延时也会增加。这对于数据库系统来说是十分不好的事情。

对于数据库来说,理解这些差异也是有用的。MySQL、PostgreSQL等数据库都是把数据放在文件系统上,IO也都是向Linux的文件系统发起,这些磁盘格式之间的差异被文件系统给屏蔽了,因此我们平时也不需要太关注这些。而如果你使用Oracle则有些不同了。

Oracle从11.2.0.3开始全面支持4K扇区磁盘,支持4Kn。Oracle的ASM是自己对IO进行优化的,为了达到极致,Oracle在Linux内核中增加了一个ASMLIB模块,用于和裸设备打交道。在普通情况下,Oracle通过512e的发格式访问磁盘扇区的数据,而在使用了ASMLIB的方式下,可以使用4Kn的模式访问磁盘,从而获得最佳的性能。

在创建磁盘组的时候,Oracle ASM的接口会自动获得逻辑扇区/物理扇区的大小,如果发现某个磁盘组内有不同的逻辑磁盘/物理磁盘大小的时候,就会报错。如果运气不好,遇到了本文开头提到的那个BUG,这时候还可能会引起DISKGROUP的故障(一般情况下不会,如果ASM实例设置了不理会逻辑扇区大小的参数_disk_sector_size_override,则大概率会出现此问题)。

在Oracle中使用4K扇区的磁盘,一定要注意几个方面:1)表空间的BLOCKSIZE不要低于4K,否则会面临性能问题,还好我们的绝大多数数据库都是用默认的8K BLOCKSZIE,不过某些超高并发,存在严重热块争用的系统往往会使用较小的BLOCKSIZE,也有一些客户为了避免热块冲突,把索引存放在2K BLOCKSIZE的表空间中;2)REDO LOG尽可能使用4Kn的磁盘格式,并且将REDO BLOCK大小设置为4K,而不是使用默认的512;3)创建磁盘组或者向磁盘组中加入新盘的时候,一定要检查物理扇区和逻辑扇区的大小,从而避免不兼容问题的出现。

图片

最后要说的是,针对4Kn还是512e/512n模式,这是一个全链路问题。从磁盘到操作系统的任何一个环节上出现不一致的配置,或者不兼容的硬件,都会影响到我们最终获得的设备的属性。我在网上看到过一个案例。在同一台存储上分配的两个LUN,在操作系统层面看到的山区格式不同。

图片

这种情况会导致创建ASM DISKGROUP的时候报错,在操作系统上检查了很久也没有发现问题,最终在存储上找到了原因。

图片

在创建LUN的时候,同一个管理员在两个不同时间里创建的两个LUN使用了不同的BLOCK SIZE。存储管理员是不管这些的,他们也不知道这个参数还会引发Oracle的问题。

硬件发展虽然没有我们想象的那么快,只不过DBA的硬件知识更新的太慢了。以至于现代硬件数年前就已经研究的很清楚的问题,我们今天才去关注。如果不是那个Oracle的BUG,我可能还停留在HDD 512扇区的惯性里。这种知识的学习,什么时候是个头啊,选择DBA这个职业,真的得保持一颗学习的心。

责任编辑:武晓燕 来源: 白鳝的洞穴
相关推荐

2016-12-20 19:59:08

科技WIFI手机

2017-11-12 21:12:34

HPC

2014-03-11 10:03:25

设计模式

2009-09-04 05:34:57

KVM性能红帽KVM

2021-05-25 14:10:34

AI 数据人工智能

2020-04-08 17:26:19

QLCSSDHDD

2012-05-08 16:07:38

Android

2022-12-18 22:11:46

2018-06-27 08:30:51

HDD密度存储

2020-09-28 18:04:37

SessionToken服务端

2019-05-05 09:24:09

KafkaTopicPartition

2021-11-30 08:04:32

AIIT运维

2021-03-01 16:07:29

戴尔

2021-05-01 09:45:43

GitHub谷歌FLoC

2022-07-20 13:55:28

算法AI人工智能

2011-10-18 10:30:55

Unix

2013-08-20 15:27:59

Linux操作系统

2020-06-04 11:31:23

5G网络技术

2019-08-05 14:30:44

无人驾驶技术人工智能

2012-11-21 11:14:06

Windows 1.0
点赞
收藏

51CTO技术栈公众号