- 浏览: 89037 次
- 性别:
- 来自: 广州
文章分类
- 全部博客 (78)
- 生活 (3)
- 云计算与虚拟化 (26)
- IT技术 (13)
- VDI (7)
- WEB 2.0 (3)
- social network (1)
- API (1)
- java (1)
- tools (1)
- javascript (3)
- framework (1)
- web (1)
- virtualization (3)
- hypervisor (1)
- linux (6)
- kvm (1)
- VDI,vmware (2)
- wine (1)
- android (4)
- NoSQL (1)
- version control (1)
- (1)
- xendesktop (1)
- citrix (1)
- mobile (2)
- ebook (1)
- GUI (2)
- C# (1)
- google map (1)
- 围棋 (1)
- coding (1)
- programming (1)
最新评论
深入浅出桌面虚拟化存储性能的评估
到底该如何规划桌面虚拟化的存储性能?一帮兄弟由讨论变成了纷争。直到Citrix的大拿Davy Huang开声,讨论才戛然而止。这是我看过的桌面虚拟化IOPS评估中最有的深度的文章了。不敢私藏,拿出来与大家分享。
虚拟桌面系统很依赖存储基础架构来承载用户环境和操作系统的不同部分。如果没有合适的存储子系统的设计,用户的虚拟桌面会变得越来越慢,然后直到不可用,因为存储变为了最大的瓶颈。为了恰当的设计存储基础设施,我们需要能够计算期望的每秒Input/Output Operations ,也就是我们俗称的IOPS, 我个人认为计算IOPS 需要从以下几方面考虑:
(1)磁盘IOPS
磁盘是整个存储系统的最基本组成单元,它完成一个I/O请求所花费的时间是由寻道时间、旋转延迟和数据传输时间三部分构成:
寻道时间Tseek是指将读写磁头移动至正确的磁道上所需要的时间。寻道时间越短,I/O操作越快,目前磁盘的平均寻道时间一般在3-15ms。
旋转延迟Trotation是指盘片旋转将请求数据所在扇区移至读写磁头下方所需要的时间。旋转延迟取决于磁盘转速,通常使用磁盘旋转一周所需时间的1/2表示。比如,7200 rpm的磁盘平均旋转延迟大约为60*1000/7200/2 = 4.17ms,而转速为15000 rpm的磁盘其平均旋转延迟约为2ms。
数据传输时间Ttransfer是指完成传输所请求的数据所需要的时间,它取决于数据传输率,其值等于数据大小除以数据传输率。目前IDE/ATA能达到133MB/s,SATA II可达到300MB/s的接口数据传输率,数据传输时间通常远小于前两部分时间。因此,理论上可以计算出磁盘的最大IOPS,即IOPS = 1000 ms/ (Tseek + Troatation),忽略数据传输时间。假设磁盘平均物理寻道时间为3ms, 磁盘转速为7200,10K,15K rpm,则磁盘IOPS理论最大值分别为,
IOPS = 1000 / (3 + 60000/7200/2) = 140
IOPS = 1000 / (3 + 60000/10000/2) = 167
IOPS = 1000 / (3 + 60000/15000/2) = 200
需要注意的是,上述计算中磁盘平均寻道时间的取值对计算结果的有较大的影响;同时为了提升磁盘的IO速度,所有的磁盘都会带有缓存(Disk Buffer),这也是网上的资料有时候会看到磁盘的IOPS值大于上述理论计算值的原因.
(2)磁盘Raid IOPS
通常我们在使用存储的时候,都是把多个磁盘建成一个Raid,那么这个由多个磁盘构成的RAID的IOPS就跟我们采用的RAID LEVEL有很大关系:
读IOPS:
无论是那种RAID LEVEL,磁盘的读取性能都是所有磁盘之和,所以可以得出下面的读取IOPS:
read IOPS = disk_IOPS/(1-disk_ buffer_read_hit_ratio)*disk_num
但是不同RAID LEVEL,磁盘的写性能则会由于不同类型的数据冗余影响实际写的数量(这也称为写惩罚,penalty):
RAID 0: 无RAID 惩罚
RAID 1: penalty of 2
RAID 10: Penalty of 2
RAID 5: Penalty of 4
RAID 6: Penalty of 6
RAID0 write IOPS =disk_IOPS/(1-disk_buffer_write_hit_ratio)*disk_num/ penalty
假设组成RAID的单个磁盘的随机读写的IOPS为140,读写缓存命中率都为10%,组成阵列的磁盘个数为4。
这样RAID的读IOPS:
read IOPS = disk_IOPS/(1-disk_buffer_read_hit_ratio)*disk_num =140/(1-10%)*4 = 622
写入IOPS
RAID0 write IOPS =disk_IOPS/(1- disk_buffer_write_hit_ratio)*disk_num/ Penalty =140/(1-10%)*4/1 = 622
RAID1 write IOPS =disk_IOPS/(1- disk_buffer_write_hit_ratio)*disk_num/ Penalty =140/(1-10%)*4/2 = 311
RAID5 write IOPS =disk_IOPS/(1- disk_buffer_write_hit_ratio)*disk_num/ Penalty =140/(1-10%)*4/4 = 155
RAID6 write IOPS =disk_IOPS/(1- disk_buffer_write_hit_ratio)*disk_num/ Penalty =140/(1-10%)*4/6 = 103
RAID总IOPS=写入IOPS+读IOPS
(3)磁盘阵列IOPS
现代的磁盘阵列为了进一步提升性能,在其控制器上一般都会再加上缓存(SDRAM),有的还有第二级的缓存(Flash Memory),这样一来整个阵列和其中某个RIAD的IOPS就变得难以计算。
很多厂商公布的那些非常高的IOPS数据实际上是将被测存储系统配置了尽量多的小容量、高转速磁盘且每个磁盘装载数据量不多、设置为RAID-10时测出的100%顺序读(Sequential Read)IOPS的最大值。而且很多厂商在公布上述100%顺序读(Sequential Read)IOPS时还隐去了“100%顺序读”字样,笼统地称为IOPS。但多数用户实际使用的环境既有顺序读写、也有随机读写操作;传输数据块尺寸大小都有;为了有效利用存储系统的存储容量,很多用户都采用RAID-5,而且尽量使用大容量磁盘来减少磁盘数量,以少占存储系统的宝贵槽位空间。因此厂商测试环境得到的100%顺序读(Sequential Read)IOPS指标完全不能代表该存储产品在用户实际应用环境下的性能。这就是厂商公布的IOPS很高,而产品在用户实际使用环境中性能却很差的原因。
既然很难计算,而厂商提供的数据也不能信任,那我们怎么办呢?幸运的是我们还有SPC和SPC-1 IOPS™可以信任和参考。SPC的全称是Storage Performance Council(即:存储性能理事会),它的成员由几乎全部的国外存储厂商和部分大学、研究机构组成,SPC是一个非赢利的组织,其使命是定义、标准化存储系统的基准测试,并提升存储系统基准测试的知名度、扩展其影响,使之成为计算机行业最具权威性的存储性能测试结果,使计算机用户可以不受现存混乱的各种存储性能测试结果的影响。目前SPC的SPC-1基准测试主要是针对随机I/O应用环境的,SPC-2基准测试主要是针对顺序I/O应用环境的。SPC-1基准测试很好地模拟了OLTP、数据库和e-mail等真实应用环境,使SPC-1基准测试结果具有很高权威性和可比性。查询各存储厂商的SPC-1基准测试报告,可访问http://www.storageperformance.org/results 。测试报告中列明了进行测试的存储系统配置。但是要注意的是,这些测试结果我们不应该直接使用,因为测试的配置和我们时间项目中的配置肯定不同。所以其最重要的意义在于它使我们知道这种磁盘阵列在某种配置下,阵列的实测IOPS跟我们通过上述第(1)(2)中介绍的方法计算出来的总IOPS理论值之间的比例,这个比例(我称为提升因子)代表了阵列中的缓存对IO起到的提升作用。换句话说,以后我们在对阵列中RAID的IOPS理论计算中可以乘上这个比例。有些厂商也直接告诉你这个因子,比如说NETAPP就宣称采用PAM缓存卡可降低75%的读IO,WAFL写优化可降低50%的写IO等等,这里的1/(1-75)%和1/(1-50%)就可以看作提升因子,只不过可信度有多少就不知道了。
(4)桌面虚拟化场景下磁盘阵列IOPS的评估
在实际运行中每个桌面VM有不同的工作状态,一般而言每中工作状态对存储子系统都有不同的要求:
1. 工作:
• 轻量: 4-8 IOPS
• 普通: 8-15 IOPS
• 重量: 15-30 IOPS
2. 空闲: 4 IOPS
3. 登出: 12 IOPS
4. Offline: 0 IOPS
那么在桌面虚拟化环境下,我们如何评估一个存储系统能否满足我们的使用要求呢?我认为可以从两个方面考虑:
1. 整个系统IOPS总需求与总供给:比如我们总共需要提供给研发用户5000台重量级VM,每台VM峰值IOPS需求是30,那么总需求就是150000;每个磁盘阵列提供的IOPS大约为SPC-1测试值×SPC-1测试配置的磁盘数量/实际项目中配置的磁盘数量,总IOPS供给=磁盘阵列提供的IOPS×磁盘阵列数量。这样我们就能计算出整个存储配置能否满足项目的需求。
2. 每个SR(一个LUN,一般对应存储 阵列上的由多个磁盘组成的一个RAID)的IOPS需求与供给:根据最佳实践,每个SR上放置25-30台重量级VM,按照25台计算,因此需求是25×30=750 IOPS;而对应的RAID的供给可以由(2)中的总IOPS×(3)的提升因子计算得到。这样我们就可以判断具体某一个SR的磁盘配置能否满足项目的需要。
到底该如何规划桌面虚拟化的存储性能?一帮兄弟由讨论变成了纷争。直到Citrix的大拿Davy Huang开声,讨论才戛然而止。这是我看过的桌面虚拟化IOPS评估中最有的深度的文章了。不敢私藏,拿出来与大家分享。
虚拟桌面系统很依赖存储基础架构来承载用户环境和操作系统的不同部分。如果没有合适的存储子系统的设计,用户的虚拟桌面会变得越来越慢,然后直到不可用,因为存储变为了最大的瓶颈。为了恰当的设计存储基础设施,我们需要能够计算期望的每秒Input/Output Operations ,也就是我们俗称的IOPS, 我个人认为计算IOPS 需要从以下几方面考虑:
(1)磁盘IOPS
磁盘是整个存储系统的最基本组成单元,它完成一个I/O请求所花费的时间是由寻道时间、旋转延迟和数据传输时间三部分构成:
寻道时间Tseek是指将读写磁头移动至正确的磁道上所需要的时间。寻道时间越短,I/O操作越快,目前磁盘的平均寻道时间一般在3-15ms。
旋转延迟Trotation是指盘片旋转将请求数据所在扇区移至读写磁头下方所需要的时间。旋转延迟取决于磁盘转速,通常使用磁盘旋转一周所需时间的1/2表示。比如,7200 rpm的磁盘平均旋转延迟大约为60*1000/7200/2 = 4.17ms,而转速为15000 rpm的磁盘其平均旋转延迟约为2ms。
数据传输时间Ttransfer是指完成传输所请求的数据所需要的时间,它取决于数据传输率,其值等于数据大小除以数据传输率。目前IDE/ATA能达到133MB/s,SATA II可达到300MB/s的接口数据传输率,数据传输时间通常远小于前两部分时间。因此,理论上可以计算出磁盘的最大IOPS,即IOPS = 1000 ms/ (Tseek + Troatation),忽略数据传输时间。假设磁盘平均物理寻道时间为3ms, 磁盘转速为7200,10K,15K rpm,则磁盘IOPS理论最大值分别为,
IOPS = 1000 / (3 + 60000/7200/2) = 140
IOPS = 1000 / (3 + 60000/10000/2) = 167
IOPS = 1000 / (3 + 60000/15000/2) = 200
需要注意的是,上述计算中磁盘平均寻道时间的取值对计算结果的有较大的影响;同时为了提升磁盘的IO速度,所有的磁盘都会带有缓存(Disk Buffer),这也是网上的资料有时候会看到磁盘的IOPS值大于上述理论计算值的原因.
(2)磁盘Raid IOPS
通常我们在使用存储的时候,都是把多个磁盘建成一个Raid,那么这个由多个磁盘构成的RAID的IOPS就跟我们采用的RAID LEVEL有很大关系:
读IOPS:
无论是那种RAID LEVEL,磁盘的读取性能都是所有磁盘之和,所以可以得出下面的读取IOPS:
read IOPS = disk_IOPS/(1-disk_ buffer_read_hit_ratio)*disk_num
但是不同RAID LEVEL,磁盘的写性能则会由于不同类型的数据冗余影响实际写的数量(这也称为写惩罚,penalty):
RAID 0: 无RAID 惩罚
RAID 1: penalty of 2
RAID 10: Penalty of 2
RAID 5: Penalty of 4
RAID 6: Penalty of 6
RAID0 write IOPS =disk_IOPS/(1-disk_buffer_write_hit_ratio)*disk_num/ penalty
假设组成RAID的单个磁盘的随机读写的IOPS为140,读写缓存命中率都为10%,组成阵列的磁盘个数为4。
这样RAID的读IOPS:
read IOPS = disk_IOPS/(1-disk_buffer_read_hit_ratio)*disk_num =140/(1-10%)*4 = 622
写入IOPS
RAID0 write IOPS =disk_IOPS/(1- disk_buffer_write_hit_ratio)*disk_num/ Penalty =140/(1-10%)*4/1 = 622
RAID1 write IOPS =disk_IOPS/(1- disk_buffer_write_hit_ratio)*disk_num/ Penalty =140/(1-10%)*4/2 = 311
RAID5 write IOPS =disk_IOPS/(1- disk_buffer_write_hit_ratio)*disk_num/ Penalty =140/(1-10%)*4/4 = 155
RAID6 write IOPS =disk_IOPS/(1- disk_buffer_write_hit_ratio)*disk_num/ Penalty =140/(1-10%)*4/6 = 103
RAID总IOPS=写入IOPS+读IOPS
(3)磁盘阵列IOPS
现代的磁盘阵列为了进一步提升性能,在其控制器上一般都会再加上缓存(SDRAM),有的还有第二级的缓存(Flash Memory),这样一来整个阵列和其中某个RIAD的IOPS就变得难以计算。
很多厂商公布的那些非常高的IOPS数据实际上是将被测存储系统配置了尽量多的小容量、高转速磁盘且每个磁盘装载数据量不多、设置为RAID-10时测出的100%顺序读(Sequential Read)IOPS的最大值。而且很多厂商在公布上述100%顺序读(Sequential Read)IOPS时还隐去了“100%顺序读”字样,笼统地称为IOPS。但多数用户实际使用的环境既有顺序读写、也有随机读写操作;传输数据块尺寸大小都有;为了有效利用存储系统的存储容量,很多用户都采用RAID-5,而且尽量使用大容量磁盘来减少磁盘数量,以少占存储系统的宝贵槽位空间。因此厂商测试环境得到的100%顺序读(Sequential Read)IOPS指标完全不能代表该存储产品在用户实际应用环境下的性能。这就是厂商公布的IOPS很高,而产品在用户实际使用环境中性能却很差的原因。
既然很难计算,而厂商提供的数据也不能信任,那我们怎么办呢?幸运的是我们还有SPC和SPC-1 IOPS™可以信任和参考。SPC的全称是Storage Performance Council(即:存储性能理事会),它的成员由几乎全部的国外存储厂商和部分大学、研究机构组成,SPC是一个非赢利的组织,其使命是定义、标准化存储系统的基准测试,并提升存储系统基准测试的知名度、扩展其影响,使之成为计算机行业最具权威性的存储性能测试结果,使计算机用户可以不受现存混乱的各种存储性能测试结果的影响。目前SPC的SPC-1基准测试主要是针对随机I/O应用环境的,SPC-2基准测试主要是针对顺序I/O应用环境的。SPC-1基准测试很好地模拟了OLTP、数据库和e-mail等真实应用环境,使SPC-1基准测试结果具有很高权威性和可比性。查询各存储厂商的SPC-1基准测试报告,可访问http://www.storageperformance.org/results 。测试报告中列明了进行测试的存储系统配置。但是要注意的是,这些测试结果我们不应该直接使用,因为测试的配置和我们时间项目中的配置肯定不同。所以其最重要的意义在于它使我们知道这种磁盘阵列在某种配置下,阵列的实测IOPS跟我们通过上述第(1)(2)中介绍的方法计算出来的总IOPS理论值之间的比例,这个比例(我称为提升因子)代表了阵列中的缓存对IO起到的提升作用。换句话说,以后我们在对阵列中RAID的IOPS理论计算中可以乘上这个比例。有些厂商也直接告诉你这个因子,比如说NETAPP就宣称采用PAM缓存卡可降低75%的读IO,WAFL写优化可降低50%的写IO等等,这里的1/(1-75)%和1/(1-50%)就可以看作提升因子,只不过可信度有多少就不知道了。
(4)桌面虚拟化场景下磁盘阵列IOPS的评估
在实际运行中每个桌面VM有不同的工作状态,一般而言每中工作状态对存储子系统都有不同的要求:
1. 工作:
• 轻量: 4-8 IOPS
• 普通: 8-15 IOPS
• 重量: 15-30 IOPS
2. 空闲: 4 IOPS
3. 登出: 12 IOPS
4. Offline: 0 IOPS
那么在桌面虚拟化环境下,我们如何评估一个存储系统能否满足我们的使用要求呢?我认为可以从两个方面考虑:
1. 整个系统IOPS总需求与总供给:比如我们总共需要提供给研发用户5000台重量级VM,每台VM峰值IOPS需求是30,那么总需求就是150000;每个磁盘阵列提供的IOPS大约为SPC-1测试值×SPC-1测试配置的磁盘数量/实际项目中配置的磁盘数量,总IOPS供给=磁盘阵列提供的IOPS×磁盘阵列数量。这样我们就能计算出整个存储配置能否满足项目的需求。
2. 每个SR(一个LUN,一般对应存储 阵列上的由多个磁盘组成的一个RAID)的IOPS需求与供给:根据最佳实践,每个SR上放置25-30台重量级VM,按照25台计算,因此需求是25×30=750 IOPS;而对应的RAID的供给可以由(2)中的总IOPS×(3)的提升因子计算得到。这样我们就可以判断具体某一个SR的磁盘配置能否满足项目的需要。
发表评论
-
转:View Calculator
2012-06-30 22:22 882View Calculator Check ou ... -
转:基于 SAN 环境使用 VMControl 2.4 部署虚拟机
2012-05-02 11:17 1731基于 SAN 环境使用 VMControl 2.4 部署 ... -
转:使用 TSAM 扩展来管理 J2EE 应用程序
2012-05-02 11:16 990使用 TSAM 扩展来管理 J2EE 应用程序 ... -
转:将单租户应用程序转换为多租户应用程序
2012-04-17 18:15 1244将单租户应用程序转换 ... -
Linux虚拟化信息源
2011-10-18 15:06 846The virtualization API QEMU Em ... -
转:通向私有云的实践之旅
2011-10-18 14:14 1324通向私有云的实践之旅,第 1 部分: 概念准备 通向私有云的 ... -
转:KVM: 安装Windows virtio半虚拟化驱动
2011-10-18 13:07 2233KVM: 安装Windows virtio半虚拟化驱动 In ... -
转:实战 IBM BigInsights,轻松实现 Hadoop 的部署与管理
2011-09-21 14:23 1913实战 IBM BigInsights,轻松实现 Hadoop ... -
转:Windows and GPT FAQ
2011-09-19 19:22 1190Windows and GPT FAQ Windows an ... -
转:Using KVM virtualization in the enterprise: RHEV or RHEL?
2011-09-19 19:19 1037Using KVM virtualization in the ... -
转:使用 Node.js 作为完整的云环境开发堆栈
2011-09-12 23:40 1035使用 Node.js 作为完整的 ... -
转:一种开放的可互操作的云
2011-09-11 15:25 871一种开放的可互操作的 ... -
转:Warning: Not all cloud licensing models are user-friendly
2011-09-05 21:57 863Warning: Not all cloud licensin ... -
转:操作系统虚拟化之KVM
2011-08-19 10:22 1153操作系统虚拟化之KVM KVM(Kernel-based V ... -
转:选择云服务:货比三家
2011-08-18 15:09 1026选择云服务:货比三家 20 ... -
转:推动云计算标准化的十大组织
2011-08-18 11:17 574推动云计算标准化的十大组织 推动云计算标准化的十大组织 20 ... -
转:云计算合同中需要注意的十大关键条款
2011-08-18 10:16 574云计算合同中需要注意的十大关键条款 2011-8-16 ... -
转:分布式系统领域经典论文翻译集
2011-08-15 12:26 927分布式系统领域经典论文翻译集 分布式系统领域经典论文翻译集 ... -
IBM desktop cloud
2011-07-08 21:43 759Solutions for Smart Business - ... -
威客云
2011-07-08 21:42 5威客云 苏州威客云终端技术有限公司(简称威客云)成立于201 ...
相关推荐
《竹林蹊径:深入浅出Windows驱动开发》是由张佩、马勇、董鉴源三位作者共同编著的一本专注于Windows驱动开发的技术书籍。这本书旨在为有一定基础的Windows驱动程序开发人员提供实践经验、技术细节以及深入的框架...
"新书首发 《区块链第一课:深入浅出技术与应用》" 本书《区块链第一课:深入浅出技术与应用》是由陈浩著作的区块链技术入门书籍。本书的出版标志着作者在区块链技术领域的深入研究和实践经验的总结。作者陈浩是一...
学以致用•深入浅出数字信号处理 学以致用•深入浅出数字信号处理
竹林蹊径:深入浅出windows驱动开发》是作者根据多年的工作学习经验,总结的第一手驱动开发资料。 《竹林蹊径:深入浅出windows驱动开发》更多的是经验之谈,一些实践中的小发现小意外,颇为书中内容添彩。 《竹林蹊径...
《竹林蹊径:深入浅出windows驱动开发》是作者根据多年的工作学习经验,总结的第一手驱动开发资料。《竹林蹊径:深入浅出windows驱动开发》更多的是经验之谈,一些实践中的小发现小意外,颇为书中内容添彩。 《竹林...
《竹林蹊径:深入浅出Windows驱动开发源码》是一部专为想要深入了解Windows驱动程序开发的工程师量身打造的指南。这本书通过丰富的实例和源码解析,带领读者步入驱动开发的世界,帮助他们掌握驱动程序的基本原理和...
竹林蹊径:深入浅出Windows驱动开发(补全版_有目录) 必须GOOD
《玩转大数据:深入浅出大数据挖掘技术》是一门针对大数据挖掘技术的全面教程,旨在帮助学员理解并掌握数据挖掘的核心理念与实用方法。课程强调理论与实践相结合,通过讲解经典算法、使用流行工具和编程实现,使学员...
最近几年,Netty社区的发展如火如荼,无论是大数据领域,还是微服务架构,底层都需要一个高效的分布式通信框架作为基础组件。 Netty凭借优异的性能、...短短几年间,Netty已经成为众多Java高性能异步通信框架的首选
《深入浅出Rails》将使你的编程和生产力达到最大值。你将学习一切Rails scaffolding的基本原理,以创建自定义的交互式网络应用程序,全部使用Rails的一套丰富的工具和MVC框架。 你将掌握数据库交互、Ajax和XML的集成...
第一章 玩转大数据:深入浅出大数据挖掘技术1-9.mp4
这是《竹林蹊径--深入浅出Windows内核驱动开发》的三章试读内容,算是官方发布吧。内容是:第二章(64位编程)、第六章(内核C++)、附录2(虚拟机调试)。 本书由China-pub首发,目前在当当和淘宝上都有卖。价格低...
系统虚拟化:原理与实现.pdf
读书笔记:深入浅出Spring Boot 2.x
读书笔记:深入浅出spring boot 2.x代码
多图技术贴:深入浅出解析大数据平台架构.doc
读书笔记:深入浅出Spring Boot2.x 读书笔记及代码
读书笔记:深入浅出Spring Boot 2.x 杨开振, 陈光欣
读书笔记:深入浅出MySQL 数据库开发 优化与管理维护 第2版 唐汉明源码
教程名称:深入浅出商业智能Cognos技术与应用文档课程目录:【】商业智能深入浅出 Cognos,Informatica技术与应用(1-100)【】商业智能深入浅出 Cognos,Informatica技术与应用(101-200)【】商业智能深入浅出 Cognos...