收藏 分享(赏)

磁盘IO解读.docx

上传人:tkhy51908 文档编号:8161162 上传时间:2019-06-11 格式:DOCX 页数:18 大小:517.54KB
下载 相关 举报
磁盘IO解读.docx_第1页
第1页 / 共18页
磁盘IO解读.docx_第2页
第2页 / 共18页
磁盘IO解读.docx_第3页
第3页 / 共18页
磁盘IO解读.docx_第4页
第4页 / 共18页
磁盘IO解读.docx_第5页
第5页 / 共18页
点击查看更多>>
资源描述

1、IOPS (Input/Output Operations Per Second),即每秒进行读写(I/O)操作的次数,多用于数据库等场合,衡量随机访问的性能。存储端的 IOPS 性能和主机端的 IO 是不同的,IOPS 是指存储每秒可接受多少次主机发出的访问,主机的一次 IO 需要多次访问存储才可以完成。例如,主机写入一个最小的数据块,也要经过“发送写入请求、写入数据、收到写入确认”等三个步骤,也就是 3个存储端访问。存储阵列的瓶颈分析(接上篇) 存储网络系统由存储设备、网络设备和主机三个部分组成。存储设备是指该系统中采用的 NAS、ISCSI、FC-SAN 等磁盘阵列设备,网络设备是指 F

2、C 交换机或以太网交换机,主机是指安装了以太网卡、FC HBA 卡,并安装了一定应用软件的主机设备。存储系统的瓶颈分析主要是看这三个部分中哪一种会首先达到其性能的最大值。存储成为整个系统的瓶颈是指存储设备的带宽达到最大值,或 IOPS 达到最大值,存储设备限制了系统性能的进一步提升,甚至影响了整个系统的正常运行。由于不同业务系统对存储的性能要求不同,一般小文件(小于 1MB)读写型的系统中对 IO 的要求较高,大文件的读写型系统对存储设备带宽的要求比较高。不用应用模式下系统对存储设备的要求不同,瓶颈点出现的位置和特点也不一样。应用模式 1:小型网站系统,应用大多集中于远程用户对 WEB 页面访

3、问,网站内部为WEB 服务器和数据库之间的读写,应用系统对存储的压力非常小,差不多所有类型、所有档次的存储设备都可以作为核心存储,存储设备的带宽和 IOPS 很难会达到极限。在这样的系统中,与存储设备连接的网络设备一般都千兆以太网交换机,交换机本身的交换能力大多都是 10Gb,只有接入网部分的可用带宽较小,一般只有 100Mb/s 左右的接入带宽,因此接入网最有可能成为存储网络的瓶颈。应用模式 2:如果该网站是一个大型的网络视频系统,支持大量用户在线进行视频节目播放和下载,这种类型的网站前端接入网一般都在 2Gb/s 以上。此时要分析瓶颈位置,首先要比较接入网带宽和存储带宽,同时还要比较在线用

4、户的最大 IO访问量和存储设备的 IOPS 值。一般来讲,由于 NAS 设备的带宽和 IOPS 相对较小,因此 NAS 比 ISCSI 和 FC-SAN 设备更容易成为系统的瓶颈,而 ISCSI 和 FC-SAN 较难成为瓶颈。如果存储设备采用 NAS,则存储系统成为瓶颈的机率大于接入网,如果存储设备采用 FC-SAN,则存储系统成为瓶颈的机率小于接入网。瓶颈还经常会出现在负责节目播放和下载功能的视频服务器处。如果视频服务器配置的数量不足,或视频服务器之间无法正常地实现自动地网络负载均衡,那么整个系统的性能压力瓶颈就会出现在视频服务器,使用整个视频网站无法给远程用户提供流畅的节目画面。应用模式

5、 3:数据库系统,数据库系统的存储应用一般都表现为大量的 IO 访问,对带宽要求较低。如果存储设备的 IOPS 较小时,会降低数据库的检索和查寻速度,从来影响整个业务的效率。因此建议数据库系统采用 IOPS(可按业务规模、工作站数量、每秒的读写访问次数和估算)比较大的 FC-SAN 设备,不建议采用 IOPS相对较小的 NAS 或 ISCSI 设备。大型数据库存储最好能采用 15000RPM 的高速FC 磁盘,这样才能将数据库服务器成为整个系统的压力瓶颈。由于 SATA 硬盘在随机 IO 读写时的性能不佳,因此存储设备不建议采用 SATA 磁盘,否则存储设备极有可能数据库系统的 IOPS 瓶颈

6、。应用模式 4:非线性编辑制作系统。在非线性编辑制作网络中,所有工作站共享式地访问核心存储系统,每台工作站同时以 50-200Mb/S 的恒定码率访问存储设备。业务系统对带宽的压力非常,而 IOPS 压力较小。存储设备的总可用带宽越大,存储设备就能支持更多数量的编辑制作工作站,网络的规模就越大,网络系统所能承担的业务就越重要。因此编辑制作网的存储一般都会选择主机端口多、特别是磁盘端口多、带宽大的 FC-SAN 设备。存储设备内部设计时,一般会通过增加磁盘数量、增加扩展柜数量、跨扩展柜创建 RAID 组、增加主机通道数量等方式最大限度地利用存储控制器前端和后端的总可用带宽,使得磁盘、磁盘通道、主

7、机通道等的总带宽大于控制器的总带宽,这样在工作站访问时存储设备时,才能最大地发挥出控制器的带宽性能。带宽瓶颈在控制器部位才能说明是最好的存储系统设计方案。上篇我们分析了 raid5 与 raid10 的内部运行细节,这里我们主要分析一下存储阵列的瓶颈,因为瓶颈的出现,与 raid 方式是有很大差别的,所以我们需要先分析 raid5 与 raid10 的具体差别。阵列的瓶颈主要体现在 2 个方面,吞吐量与 IOPS。 1、吞吐量吞吐量主要取决于阵列的构架,光纤通道的大小(现在阵列一般都是光纤阵列,至于 SCSI 这样的 SSA 阵列,我们不讨论)以及硬盘的个数。阵列的构架与每个阵列不同而不同,他

8、们也都存在内部带宽(类似于 pc 的系统总线),不过一般情况下,内部带宽都设计的很充足,不是瓶颈的所在。光纤通道的影响还是比较大的,如数据仓库环境中,对数据的流量要求很大,而一块 2Gb 的光纤卡,所能支撑的最大流量应当是 2Gb/8(小 B)=250MB/s(大 B)的实际流量,当 4 块光纤卡才能达到 1GB/s 的实际流量,所以数据仓库环境可以考虑换 4Gb 的光纤卡。最后说一下硬盘的限制,这里是最重要的,当前面的瓶颈不再存在的时候,就要看硬盘的个数了,我下面列一下不同的硬盘所能支撑的流量大小:10 K rpm 15 K rpm ATA 10M/s 13M/s 8M/s那么,假定一个阵列

9、有 120 块 15K rpm 的光纤硬盘,那么硬盘上最大的可以支撑的流量为 120*13=1560MB/s,如果是 2Gb 的光纤卡,可能需要 6 块才能够,而 4Gb 的光纤卡,3-4 块就够了。 2、IOPS决定 IOPS 的主要取决与阵列的算法,cache 命中率,以及磁盘个数。阵列的算法因为不同的阵列不同而不同,如我们最近遇到在 hds usp 上面,可能因为 ldev(lun)存在队列或者资源限制,而单个 ldev 的 iops 就上不去,所以,在使用这个存储之前,有必要了解这个存储的一些算法规则与限制。cache 的命中率取决于数据的分布,cache size 的大小,数据访问的

10、规则,以及 cache 的算法,如果完整的讨论下来,这里将变得很复杂,可以有一天好讨论了。我这里只强调一个 cache 的命中率,如果一个阵列,读 cache 的命中率越高越好,一般表示它可以支持更多的 IOPS,为什么这么说呢?这个就与我们下面要讨论的硬盘 IOPS 有关系了。硬盘的限制,每个物理硬盘能处理的 IOPS 是有限制的,如10 K rpm 15 K rpm ATA 100 150 50同样,如果一个阵列有 120 块 15K rpm 的光纤硬盘,那么,它能撑的最大IOPS 为 120*150=18000,这个为硬件限制的理论值,如果超过这个值,硬盘的响应可能会变的非常缓慢而不能正

11、常提供业务。另外,我们上一篇也讨论了,在 raid5 与 raid10 上,读 iops 没有差别,但是,相同的业务写 iops,最终落在磁盘上的 iops 是有差别的,而我们评估的却正是磁盘的 IOPS,如果达到了磁盘的限制,性能肯定是上不去了。那我们假定一个 case,业务的 iops 是 10000,读 cache 命中率是 30%,读iops 为 60%,写 iops 为 40%,磁盘个数为 120,那么分别计算在 raid5 与raid10 的情况下,每个磁盘的 iops 为多少。 raid5: 1. 单块盘的 iops = (10000*(1-0.3)*0.6 + 4 * (100

12、00*0.4)/120 2. = (4200 + 16000)/120 3. = 168 这里的 10000*(1-0.3)*0.6 表示是读的 iops,比例是 0.6,除掉 cache 命中,实际只有 4200 个 iops而 4 * (10000*0.4) 表示写的 iops,因为每一个写,在 raid5 中,实际发生了 4 个 io,所以写的 iops 为 16000 个 为了考虑 raid5 在写操作的时候,那 2 个读操作也可能发生命中,所以更精确的计算为: 1. 单块盘的 iops = (10000*(1-0.3)*0.6 + 2 * (10000*0.4)*(1-0.3) +

13、2 * (10000*0.4)/120 2. = (4200 + 5600 + 8000)/120 3. = 148 计算出来单个盘的 iops 为 148 个,基本达到磁盘极限 raid10 1. 单块盘的 iops = (10000*(1-0.3)*0.6 + 2 * (10000*0.4)/120 2. = (4200 + 8000)/120 3. = 102 可以看到,因为 raid10 对于一个写操作,只发生 2 次 io,所以,同样的压力,同样的磁盘,每个盘的 iops 只有 102 个,还远远低于磁盘的极限 iops。 在一个实际的 case 中,一个恢复压力很大的 standb

14、y(这里主要是写,而且是小 io 的写),采用了 raid5 的方案,发现性能很差,通过分析,每个磁盘的iops 在高峰时期,快达到 200 了,导致响应速度巨慢无比。后来改造成raid10,就避免了这个性能问题,每个磁盘的 iops 降到 100 左右。 raid5 与 raid10 内部分析 一直以来,看到关于 raid5 与 raid10 的性能之争还是非常多的,甚至很多人那拿出了测试数据,但是,到底谁是谁非。这里,我就这两种 raid 的内部运行原理来分析一下,我们在什么情况下应当适合选哪一种 raid 方式。 为了方便对比,我这里拿同样多驱动器的磁盘来做对比,raid5 选择 3D+

15、1P 的raid 方案,raid10 选择 2D+2D 的 Raid 方案,分别如图: 那么,我们分析如下三个过程:读,连续写,随机写,但是,在介绍这三个过程之前,我需要介绍一个特别重要的概念:cache。 cache 技术最近几年,在磁盘存储技术上,发展的非常迅速,作为高端存储,cache 已经是整个存储的核心所在,就是中低端存储,也有很大的 cache 存在,包括最简单的 raid 卡,一般都包含有几十,甚至几百兆的 raid cache。cache 的主要作用是什么呢?体现在读与写两个不同的方面,如果作为写,一般存储阵列只要求写到 cache 就算完成了写操作,所以,阵列的写是非常快速的

16、,在写 cache 的数据积累到一定程度,阵列才把数据刷到磁盘,可以实现批量的写入,至于 cache 数据的保护,一般都依赖于镜相与电池(或者是 UPS)。cache 的读一样不可忽视,因为如果读能在 cache 中命中的话,将减少磁盘的寻道,因为磁盘从寻道开始到找到数据,一般都在 6ms 以上,而这个时间,对于那些密集型 io 的应用可能不是太理想。但是,如果 cache 能命中,一般响应时间则可以在 1ms 以内。不要迷信存储厂商的 iops(每秒的 io 数)数据,他们可能全部在 cache 命中的基础上做到的,但是实际上,你的 cache 命中率可能只有 10%。 介绍完 cache,

17、我们就可以解释 raid5 与 raid10 在不同的模式下,工作效率问题了,那么我们来分别分析以上三个问题。 1、读操作 因为 raid5 与 raid10 的磁盘都可以提供服务,所以,在读上面他们基本是没有差别的,除非是读的数据能影响 cache 命中率,导致命中率不一样。 2、连续写 连续写的过程,一般表示写入连续的大批量的数据,如媒体数据流,很大的文件等等,这个写操作过程,如果有写 cache 存在,并且算法没有问题的话,raid5 比 raid10 甚至会更好一些(这里要假定存储有一定大小足够的写cache,而且计算校验的 cpu 不会出现瓶颈)。因为这个时候的校验是在 cache中

18、完成,如 4 块盘的 raid5,可以先在内存中计算好校验,同时写入 3 个数据+1 个校验。而 raid10 只能同时写入 2 个数据+2 个镜相。 如,4 块盘的 raid5 可以在同时间写入 1、2、3 到 cache,并且在 cache 计算好校验之后,我这里假定是 6(实际的校验计算并不是这样的,我这里仅仅是假设),同时把三个数据写到磁盘。而 4 块盘的 raid10 不管 cache 是否存在,写的时候,都是同时写 2 个数据与 2 个镜相。 但是,我前面也说过了,写 cache 是可以缓存写操作的,等到一定时期再写到磁盘,但是,写操作不比读操作,这个写是迟早也要发生的,也就是说,

19、最后落到磁盘上的写还是避免不了的,不过,如果不是连续性的强连续写,只要不达到磁盘的写极限,差别都不是太大。 3、离散写 这里可能是最难理解,但是,也是最重要的部分,数据库,如 oracle 数据库大部分操作就是离散写,如每次写一个数据块的数据,如 8K;联机日志虽然看起来是连续写,但是因为每次写的量不多,不保证能添满 raid5 的一个条带(保证每张盘都能写入),所以很多时候也是离散写入。 我们再接上图,假定要把一个数字 2 变成数字 4,那么对于 raid5,实际发生了4 次 io,先读出 2 与校验 6,可能发生读命中然后在 cache 中计算新的校验写入新的数字 4 与新的校验 8 对于

20、 raid10,我们可以看到,同样的单个操作,最终 raid10 只需要 2 个 io,而 raid5 需要 4 个 io。 但是,这里我忽略了 raid5 在那两个读操作的时候,还可能会发生读命中操作,也就是说,如果需要读取的数据已经在 cache 中,可能是不需要 4 个 io 的,也证明了 cache 对 raid5 的重要性,不仅仅是计算校验需要,而且对性能的提升由为重要。曾经测试过,在 raid5 的阵列中,如果关闭写 cache,raid5 的性能将差很多倍。 这里,并不是说 cache 对 raid10 就不重要了,因为写缓冲,读命中等,都是提高速度的关键所在,不过的是,raid

21、10 对 cache 的依赖性没有 raid5 那么明显而已。 到这里,大家应当也大致明白了 raid5 与 raid10 的原理与差别了,一般来说,象小 io 的数据库类型操作,建议采用 raid10,而大型文件存储,数据仓库,则从空间利用的角度,可以采用 raid5。 待续。 太气愤了, HDS 的高端存储 USP 有点太垃圾了。 注:以下言论只代表个人观点,不代表公司意见或者是看法: 240 块 73G*15K 的硬盘,128G 的 cache,支撑到 17000iops 的时候,存储就成瓶颈了,单个 IO 的响应时间居然超过 100ms,如果一个语句有 100 个物理 io,那么响应时

22、间将是 100*100=10,000ms,也就是 10s 种才能返回结果,TMD,也太恐怖了,差的有点离谱。 这个转折不是线型的,可能在 15000iops 的时候,你发现单个 io 的响应时间还在 20ms 以下,16000 的时候,已经有 50ms 了,17000 的时候,可能就 100ms 了。也就是说,拐点就在这里出现了,如果一个小的 iops 的增长,将导致大量的io 响应缓慢,再导致所有的应用响应缓慢,再导致整个系统的处理能力下降。 造成这么差的原因总是多方面的,但是,根据个人经验的长期总结,有如下 2个重要原因 1、cache 机制有问题,这款号称最高端的存储采用了令人可笑的 c

23、ache 设计,256k 的 cache size,也就是说,如果数据库发生了一个 8k 的 io,存储将分配256K 的 cache size 给它,那 256-8K 的地方呢?空着呗,除非有另外的访问读取了这个 8k 附近的数据。(这里解释一下,一个 cache size 所保存的数据,在磁盘上必须是连续的,而且起始地址也是固定的,是为了寻址的设计要求)。那么,对于一个总是有很小 IO,如数据库系统,IO 又很离散的话,那么,你将遭遇到令人吃惊的存储命中率,如 10%的命中率,对于一个 128G 的 cache,数据库总大小也就 1 个 T 的环境来说,是不是太离奇了。 当初我为了跟踪这个

24、问题,几乎是找遍了所有的资源,才得到这个信息,也只能说 HDS 对中国的技术封锁还是太严重,那么,想修改这个尺寸可以吗?回答是,可以,可以从 256K 修改成 64K,但是需要停机,完全停机!但是,对于一个 99.99%的高可用系统,停机一次是一个非常大的代价。 2、算法的设计也有问题,因为存储的瓶颈不在硬盘,我们可以计算每块盘的iops,大致为 17000*0.9/200=77 左右(90%不命中,200 块盘用于数据文件),也就是说,一块盘的 iops 才 77 个,存储就如此不行了,一个硬盘,正常可以支撑到 120 iops 还没有问题(我们都是 raid10,而且肯定没有热点硬盘或者热

25、点 raid 组)。 那么瓶颈在哪里呢,其实我也不是太清楚存储的代码与算法设计,但是,我们比较一个数据,总会有点眉目: 如一个 RAID 组,分成 2 个部分,我们就假定 part1、part2。当 part 的 iops为 150 的时候,part2 的 iops 才 30,那么,虽然是同样的 raid 组,虽然part1 的命中率比 part2 要高(part1 15%,part2 大概 5%),但是,part2 的响应时间能保证在 10ms,而 part1 则可能就是 50ms 甚至更高。 这里说明了什么问题? 很有可能这里就是瓶颈的所在,一个逻辑磁盘,也就是 USP 的 ldev,当接

26、收到一定量的 io 的时候,产生了瓶颈,发生了严重的等待,甚至是拐点的出现,但是,这个等待不是发生在 OS 上的,确实是发生在存储内部的,因为以上的数据来自存储本身的监控数据,而不是 OS 的数据。 如果是存储本身的 ldev 只能支撑到一定的 IOPS,那么,我只能是猜测,存储给一个 ldev,分配的资源是有限度的,或者说,一个 ldev 中存在一个有限的队列,当不能处理超过这个队列的数据时,就发生了严重的等待与拐点。 但是,如果确实是这样,当初设计规划的人,有谁知道这个问题呢?国内的代理厂家?他们根本不懂这些,能帮你装上就不错了,其它的,只能是靠自己了,其实,我们的 ldev 也不少,一个

27、主机有 48 个,每个 50G,如果这样的话,看样子当初只能规划为每个 20G 了。但是,增加 ldev 的数量是否一定能解决这个问题呢?这个天知道。 补充 2 点,1 关于 cache size 的问题,只是在有些微码版本上是这样,新的微码是 64K 的,不过升级微码我没有发现有命中率的变化。2 中关于怀疑 ldev 是否有队列的问题,厂家不承认有这个问题。 怎么样在 AIX 上安装/卸载Powerpath(for EMC Storage) AIX 操作系统 , 主机与存储 |HW, 所有|All Blogs, 操作系统|Os piner Read on 1、检查所需要的文件集 Powerp

28、ath4.3 以上要求 5.1.0.58 以上,devices.fcp.disk.rte 5.2.0.17 以上 检查文件集 # lslpp -l devices.fcp.disk.rte Fileset Level State Description - Path: /usr/lib/objrepos devices.fcp.disk.rte 5.2.0.60 APPLIED FC SCSI CD-ROM, Disk, Read/Write Optical Device Software 5.2.0.60 APPLIED Common PCI FC Adapter Device Sof

29、tware Path: /etc/objrepos devices.fcp.disk.rte 5.2.0.60 APPLIED FC SCSI CD-ROM, Disk, Read/Write Optical Device Software 5.2.0.60 APPLIED Common PCI FC Adapter Device Software 对应的补丁要求(仅仅针对 5.2 版本) #instfix -a -ivk IY60183 IY60183 Abstract: Open failure on ESS with FC df1000fa adapter IY60183 Sympto

30、m Text: Customer sees open failures to FC attached disks across a McData or Cisco switch. I/O hangs. across the FC adapter. - Fileset :5.2.0.42 is applied on the system. Fileset devices.pci.df1000fa.rte:5.2.0.1 is applied on the system. All filesets for IY60183 were found. #instfix -a -ivk IY62117 I

31、Y62117 Abstract: I/O hang after 1 second cable pull and recovery IY62117 Symptom Text: The customer will notice I/Os hanging or I/Os not recovering. In the error log, there will be logs on the fcs device indicating link may have gone down and may have come up, and IOCB timeouts and error logs on fsc

32、si device indicating NPORT login timouts, and target reset timeouts, etc. - Fileset :5.2.0.43 is applied on the system. All filesets for IY62117 were found. 2、安装 agent,先解压 agent 软件 注意:Agent 的软件要求版本最好与存储本身的软件版本一致。 #unzip AIX_NAVIAGNTCLI_619.zip 进去到解压后的目录 # cd AIX_NAVIAGNTCLI_619 运行 #smit install_late

33、st 安装目录选择.,表示本目录 软件列表选择需要安装的 naviagent,或者是默认全部(因为本目录下只有agent) NAVIAGENT ALL + 6.19.0.4 Navisphere Disk Array Management Tool (AGENT) NAVICLI ALL + 6.19.0.4 Navisphere Disk Array Management Tool (CLI) 选择接受许可协议 ACCEPT new license agreements? Yes 回车安装 如果安装成功,将会自动在/etc/inittab 中增加 naviagent:2:wait:/etc/

34、rc.agent /dev/console 2 rm hdiskpower*; rm rhdiskpower* #savebase -v #reboot 这里再安装新的 powerpath 软件,并重新配置 # powermt config 或者 vary off volume groups on SAN (if any): #cd /dev #echo hdiskpower* | xargs -n1 rmdev -dl # rmdev -dl powerpath0 每一个光纤卡执行 #rmdev -Rdl fcs(x) 执行 cfgmgr 与 emc_cfgmgr 最后执行 #powermt config

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 企业管理 > 管理学资料

本站链接:文库   一言   我酷   合作


客服QQ:2549714901微博号:道客多多官方知乎号:道客多多

经营许可证编号: 粤ICP备2021046453号世界地图

道客多多©版权所有2020-2025营业执照举报