cloudstack-users-cn mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jijun <jiju...@gmail.com>
Subject Re: 回复: 回复: 回复: 回复: 回复: 回复: 回复: Re: 请问大家在生产环境中使用什么样的存储方式?
Date Sun, 09 Jun 2013 03:13:58 GMT
zhang.xiaofei

我测试了clvm和gfs2两种方式,8台server的集群。
总结如下:
8台计算节点,hba卡连接8个lun。
gfs2写入速度大约160MB/s,损失3/4性能。使用qcow2格式,安装virtio驱动,性
能还可以接受。
clvm性能更高。因为每台虚拟机对应一个lv,是raw设备。但是在建立模板时速度
很慢,通过模板创建虚拟机时也很慢,另外不支持 thinprovisioning。

zhang.xiaofei能否说说你现在的方案。





On 06/08/2013 09:47 AM, linuxbqj@gmail.com wrote:
> 如果没有专业的存储设备
> 可以使用drbd+nfs 或者使用ZFS+NFS
>
>
> 在 2013年6月4日下午12:33,zhang.xiaofei <zhang.xiaofei@oncloudit.com>写道:
>
>> 嗯 把高速缓存关掉的话 写入在150m/s左右 主机用的千兆网卡 现在改方案了
不搞clvm了 =。=
>>
>> 2013-06-04
>>
>>
>>
>> zhang.xiaofei
>>
>>
>>
>> 发件人:"WXR" <474745079@qq.com>
>> 发送时间:2013-06-04 11:57
>> 主题:回复: 回复: 回复: 回复: 回复: 回复: 回复: Re: 请问大家在生产环境中使用什么样的存储方式?
>> 收件人:"users-cn"<users-cn@cloudstack.apache.org>
>> 抄送:
>>
>> 你在测试的时候,那个数值是不是包括了存储的写缓存的功能?
>> 如果排除掉写缓存,纯粹是看硬盘组成RAID后的写入速度,是不是也会下降很多呢?
>>
>>
>>
>>
>> ------------------ 原始邮件 ------------------
>> 发件人: "zhang.xiaofei"<zhang.xiaofei@oncloudit.com>;
>> 发送时间: 2013年6月4日(星期二) 中午11:55
>> 收件人: "users-cn"<users-cn@cloudstack.apache.org>;
>>
>> 主题:  回复:  回复: 回复:  回复: 回复: 回复: Re: 请问大家在生产环境中使用什么样的存储方式?
>>
>>
>>
>> 用的阵列柜做的iscsi 6个磁盘做的raid6 然后 6台服务器的2个万兆卡做bond
0 接万兆交换机
>> 然后做的gfs 然后测的单点的速度
>> 最后卡在fence这步 死掉一个节点 就会全死  =。=  dell的r720 有人做rhcs成功过么
>> 2013-06-04
>>
>>
>>
>> zhang.xiaofei
>>
>>
>>
>> 发件人:"WXR" <474745079@qq.com>
>> 发送时间:2013-06-04 10:52
>> 主题:回复: 回复: 回复: 回复: 回复: Re: 请问大家在生产环境中使用什么样的存储方式?
>> 收件人:"users-cn"<users-cn@cloudstack.apache.org>
>> 抄送:
>>
>> 请问你是用的几块盘做的RAID6呢,是用的15K的SAS盘吗。
>> 我这里测试的机器条件有限,我在单机上用7.2k的SATA盘组了RAID0,RAID5和RAID6分别做了测试。
>> 感觉做RAID5和RAID6以后写性能下降好多啊。你是怎么达到1.3gb/s的写入速度的呢。
>>
>> 下面是我测试的连续写的速度:
>> 单块硬盘是75MB/s
>> 3块盘做RAID0是130MB/s
>> 3块盘做RAID5只有25MB/s
>> 4块盘做RAID6只有20MB/s
>>
>>
>>
>>
>> ------------------ 原始邮件 ------------------
>> 发件人: "zhang.xiaofei"<zhang.xiaofei@oncloudit.com>;
>> 发送时间: 2013年6月4日(星期二) 上午10:22
>> 收件人: "users-cn"<users-cn@cloudstack.apache.org>;
>>
>> 主题:  回复:  回复: 回复: 回复: Re: 请问大家在生产环境中使用什么样的存储方式?
>>
>>
>>
>> 万兆卡加iscis磁盘raid6 写入速度1.3gb/s 6个物理机  没开虚拟机
>>
>> 2013-06-04
>>
>>
>>
>> zhang.xiaofei
>>
>>
>>
>> 发件人:"WXR" <474745079@qq.com>
>> 发送时间:2013-06-04 10:09
>> 主题:回复: 回复: 回复: Re: 请问大家在生产环境中使用什么样的存储方式?
>> 收件人:"users-cn"<users-cn@cloudstack.apache.org>
>> 抄送:
>>
>> 请问你用的存储最大的传输速率能够达到多少呢,是带了多少物理机,上面总的开了多少虚拟机呢?
>>
>>
>>
>>
>> ------------------ 原始邮件 ------------------
>> 发件人: "Fan Lei"<leifan8440@gmail.com>;
>> 发送时间: 2013年6月4日(星期二) 上午10:07
>> 收件人: "users-cn"<users-cn@cloudstack.apache.org>;
>>
>> 主题: Re: 回复: 回复: Re: 请问大家在生产环境中使用什么样的存储方式?
>>
>>
>>
>> 我用的iscsi存储有12个网口,每个网口有1个IP,多个host连上去的时候可以自动负载均衡
>> 万兆网的瓶颈是硬盘,不是本身的链路速度了
>>
>>
>> 在 2013年6月4日上午9:55,WXR <474745079@qq.com>写道:
>>
>>> Fan Lei,请问你说的不止一个千兆口,是指要做端口聚合来扩大带宽吗?
>>> 另外万兆的话,可以用万兆的以太网吗,那个速度能够达到多少呢,能达到理论的10Gb的速度吗?
>>> 如果用FC的话是不是就不能用NFS了
>>>
>>>
>>>
>>>
>>> ------------------ 原始邮件 ------------------
>>> 发件人: "zhang.xiaofei"<zhang.xiaofei@oncloudit.com>;
>>> 发送时间: 2013年6月4日(星期二) 上午9:49
>>> 收件人: "users-cn"<users-cn@cloudstack.apache.org>;
>>>
>>> 主题:  回复:  Re: 请问大家在生产环境中使用什么样的存储方式?
>>>
>>>
>>>
>>> 有人试过用clvm没哈? 有成功过的么  那个通过gfs用sharepoint方式做主存储
有人在生产环境试过么?
>>>
>>> 2013-06-04
>>>
>>>
>>>
>>> zhang.xiaofei
>>>
>>>
>>>
>>> 发件人:Fan Lei <leifan8440@gmail.com>
>>> 发送时间:2013-06-04 09:43
>>> 主题:Re: 请问大家在生产环境中使用什么样的存储方式?
>>> 收件人:"users-cn"<users-cn@cloudstack.apache.org>
>>> 抄送:
>>>
>>> 要求不高千兆IP-SAN是可以满足需求的,不会所有的vm都在持续读写,另外存储不是只有1个网口的
>>> 要求高的话就上万兆、FC
>>>
>>>
>>> 在 2013年6月4日上午9:26,WXR <474745079@qq.com>写道:
>>>
>>>> 我看网上资料和大家讨论的都是以NFS为主,那么在生产环境中大家也用它吗?
>>>> 如果使用NFS的话,通常一个主存储带多少台HOST主机,每台主机上开多少个虚拟机是最佳的呢?
>>>>
>>>>
>>>>
>> 我对网络存储不太了解,没有用过。以前只在单机上开过虚拟机。根据我之前的经验,跑我们自己所需的业务,一块硬盘如果开15个虚拟机可能就已经到达读写的上限了,如果到20个就很可能卡了。
>>>> 如果我想要充分利用一台物理机的内存和CPU资源,可能我会在上面挂4块硬盘,这样可以开60个虚拟机(假设不考虑数据的安全性)。
>>>>
>>>>
>>>>
>> 那么如果用NFS的话,如果HOST主机用千兆网络连接到主存储,那么最大速率理论上是125MB/s,也就相当于一块硬盘。这样的话单台物理机连接到存储也只相当于本地挂一块硬盘的速率,只能达到我前面挂4块盘的1/4,如果要再多连几个物理机,效果就更差了。
>>>> 这样的话用NFS岂不是相当于多台物理机同时使用一块普通硬盘的读写性能,会非常的卡?
>
>


Mime
View raw message