微波EDA网,见证研发工程师的成长!
首页 > 通信和网络 > 通信网络技术文库 > NetApp V 系列与TMS RamSan-500 联合方案:无以伦比的存储性能

NetApp V 系列与TMS RamSan-500 联合方案:无以伦比的存储性能

时间:06-13 来源:与非网 点击:

同样数量的IOPS,但是由于受到内置于磁盘驱动器里的物理限制,众多的磁盘并没有对延迟改善产生帮助。这很好地描述了具有许多高性能数据库应用的情形。许多卷轴(对空间、能耗及制冷具有相应的需求)必须被部署以提供必要的I/O 吞吐量--即使当容量并不必需的时候。

这告诉我们,对于在吞吐量和/或延迟方面具有限制性的应用来说,RamSan 能带来明显的优势。本文稍后将讨论如何区分你的应用是否在I/O方面受到限制。

哪些应用能从 V 系列 RamSan 联合解决方案中获益?

你很可能已经开始猜测,V系列 RamSan联合解决方案所带来的更少的延迟以及更显著的吞吐量将使哪些应用因此受益?

总体来说,那些具有随机I/O工作负载的应用将从使用闪存设备中受益,而那些具有连续工作负载的应用则不会。联机事务处理(简称OLTP)与其它的数据库应用很明显也是合适的候选者。如果一个完整的数据库适合RamSan存储容量,那么它将立即从这一解决方案的延迟和吞吐量方面得到帮助。对于更大的数据库,通过仅仅将诸如事务日志、索引及临时空间之类的热文件存储在RamSan上,并将该数据库的其它部分放在硬盘驱动器里,你就能够利用RamSan 去改善延迟。

通常,只要整个数据集或活跃数据集适合RamSan 内存的任何应用都可能是一个好的候选,特别是当那个数据集能够被并行工作的多个服务器访问的时候。在电脑动画中使用的渲染集群都是很好的例子。当然,问题的关键在于磁盘I/O 在应用性能方面是不是限定因素。

你的应用 I/O 是否受限?

谈到改善应用性能,存储经常是性能链上最后一个被调查的环节。

图1) 改善应用性能的典型方法

这部分地是因为理解I/O性能的那些方法并没有被广泛理解。不过,现在有许多操作系统级、存储系统级和应用级的 I/O 性能分析工具能够帮助你查出可能的I/O 难题。

供研究I/O使用的操作系统级工具

对于UNIX®和Linux®操作系统来说,许多性能分析工具如Top、iostat和sar(系统活动报告人)能帮助你了解I/O对你的服务器的潜在影响。如果该服务器是(或可能)专用于单一的有趣应用,那么这些统计数据就是有用的。例如,Linux系统上的iostat命令显示"%iowait", 即该系统等待I/O所花费时间的百分比。(系统执行这个命令时仅显示了一个单一时间点。)

对于Microsoft® 的Windows®来说,最佳系统性能分析工具是性能监测器。遗憾的是,性能监视器不能提供明确的I / O等待时间统计数据。然而,它能提供包括实时处理器的性能水平和磁盘队列统计数据。"处理器:处理器时间百分比"测量出处理器所做的实际工作, 而"平均磁盘队列长度"显示了I / O操作进程的数量。如果一个承担了太多事务处理的系统显示出很高的磁盘队列水平,而"处理器时间百分比"恰巧在100% 以下,你就可以假定服务器I/O等待时间是长的。

存储系统工具

如果你使用的是智能后端存储系统,它也许能提供关于I/O的额外信息。例如,通过使用NetApp Operations Manager,你能以图表的方式清晰地看到包括卷延迟、每秒操作等在内的各种存储衡量标准。通过专注于特定应用使用的卷,你可以分辨出这些卷是否正在承担过多事务处理以及/或者高度延迟。

你可以从之前发表的Tech OnTap 文章《监测、解决问题、提高NetApp存储性能》 (Monitor, Troubleshoot, and Improve NetApp Storage Performance)和NetApp技术报告3525《存储性能管理》(Storage Performance Management)中看到更多关于如何使用这些NetApp工具的内容。

应用工具

对于最可能的应用特征来说,你需要嵌入在应用中的I/O工具来告诉你到底该应用是如何使用其时间的。许多流行的数据库和业务应用包含了这类的工具。例如,Oracle配备Statspack功能来监测数据库性能。在Oracle10g™中, Oracle推出了AWR (Automatic Workload Repository)和ADDM (Automatic Database Diagnostic Monitor)一起作为其Enterprise Manager Tool的额外成本选项。

Statspack报告包含了"最常见的5个定时活动"一节,指出首先你会渴望了解你的数据库是否在I/O约束范围内。(见图2))

图2)Oracle Statspack报告的部分内容,显示了最常见的5个定时活动(15分钟间隔)

回顾该例子的结果,非常明显,在该间隔期间内数据库花费了83% 的总运行时间的用来读龋将等待的总时间分解成以秒计的时间,将得出每次等待需要5.25毫秒的平均延迟时间。尽管这样的延迟时间还算不错,但要使这个数据库得到明显的性能提升还需要进一步削减延迟时间。为此,将V系列和RamSan结合将是一个完美的解决方

Copyright © 2017-2020 微波EDA网 版权所有

网站地图

Top