Open Stack

I'll try the boot from volume feature and see if it makes any significant difference. (fingers crossed) - I'm wondering though two things :

- How come I never had such issues (to validate) with MooseFS while it's the mfsmount is FUSE-based?
- Does that mean the issue is not si much about Gluster, rather all FUSE-based FS? 

regards,

Razique Mahroua - Nuage & Co
razique.mahroua at gmail.com
Tel : +33 9 72 37 94 15



Le 25 juil. 2013 à 09:22, Sylvain Bauza <sylvain.bauza at bull.net> a écrit :

> Hi Denis,
> 
> As per my short testings, I would assume anything but FUSE-mounted would match your needs.
> 
> On the performance glance, here is what I could suggest : 
>  - if using GlusterFS, wait for this BP [1] to be implemented. I do agree with Razique on the issues you could face with GlusterFS, this is mainly due to the Windows caching system mixed with QCOW2 copy-on-write images relying on a FUSE mountpoint. 
>  - if using Ceph, use RADOS to boot from Cinder volumes. Don't use FUSE mountpoint, again.
> 
> -Sylvain
> 
> [1] https://blueprints.launchpad.net/nova/+spec/glusterfs-native-support
> 
> 
> 
> Le 25/07/2013 08:16, Denis Loshakov a écrit :
>> So, first i'm going to try Ceph. 
>> Thanks for advices and lets RTFM begin :) 
>> 
>> On 24.07.2013 23:18, Razique Mahroua wrote: 
>>> +1 :) 
>>> 
>>> 
>>> Le 24 juil. 2013 à 21:08, Joe Topjian <joe.topjian at cybera.ca 
>>> <mailto:joe.topjian at cybera.ca>> a écrit : 
>>> 
>>>> Hi Jacob, 
>>>> 
>>>> Are you using SAS or SSD drives for Gluster? Also, do you have one 
>>>> large Gluster volume across your entire cloud or is it broke up into a 
>>>> few different ones? I've wondered if there's a benefit to doing the 
>>>> latter so distribution activity is isolated to only a few nodes. The 
>>>> downside to that, of course, is you're limited to what compute nodes 
>>>> instances can migrate to. 
>>>> 
>>>> I use Gluster for instance storage in all of my "controlled" 
>>>> environments like internal and sandbox clouds, but I'm hesitant to 
>>>> introduce it into production environments as I've seen the same issues 
>>>> that Razique describes -- especially with Windows instances. My guess 
>>>> is due to how NTFS writes to disk. 
>>>> 
>>>> I'm curious if you could report the results of the following test: in 
>>>> a Windows instance running on Gluster, copy a 3-4gb file to it from 
>>>> the local network so it comes in at a very high speed. When I do this, 
>>>> the first few gigs come in very fast, but then slows to a crawl and 
>>>> the Gluster processes on all nodes spike. 
>>>> 
>>>> Thanks, 
>>>> Joe 
>>>> 
>>>> 
>>>> 
>>>> On Wed, Jul 24, 2013 at 12:37 PM, Jacob Godin <jacobgodin at gmail.com 
>>>> <mailto:jacobgodin at gmail.com>> wrote: 
>>>> 
>>>>     Oh really, you've done away with Gluster all together? The fast 
>>>>     backbone is definitely needed, but I would think that was the case 
>>>>     with any distributed filesystem. 
>>>> 
>>>>     MooseFS looks promising, but apparently it has a few reliability 
>>>>     problems. 
>>>> 
>>>> 
>>>>     On Wed, Jul 24, 2013 at 3:31 PM, Razique Mahroua 
>>>>     <razique.mahroua at gmail.com <mailto:razique.mahroua at gmail.com>> wrote: 
>>>> 
>>>>         :-) 
>>>>         Actually I had to remove all my instances running on it 
>>>>         (especially the windows ones), yah unfortunately my network 
>>>>         backbone wasn't fast enough to support the load induced by GFS 
>>>>         - especially the numerous operations performed by the 
>>>>         self-healing agents :( 
>>>> 
>>>>         I'm currently considering MooseFS, it has the advantage to 
>>>>         have a pretty long list of companies using it in production 
>>>> 
>>>>         take care 
>>>> 
>>>> 
>>>>         Le 24 juil. 2013 à 16:40, Jacob Godin <jacobgodin at gmail.com 
>>>>         <mailto:jacobgodin at gmail.com>> a écrit : 
>>>> 
>>>>>         A few things I found were key for I/O performance: 
>>>>> 
>>>>>          1. Make sure your network can sustain the traffic. We are 
>>>>>             using a 10G backbone with 2 bonded interfaces per node. 
>>>>>          2. Use high speed drives. SATA will not cut it. 
>>>>>          3. Look into tuning settings. Razique, thanks for sending 
>>>>>             these along to me a little while back. A couple that I 
>>>>>             found were useful: 
>>>>>               * KVM cache=writeback (a little risky, but WAY faster) 
>>>>>               * Gluster write-behind-window-size (set to 4MB in our 
>>>>>                 setup) 
>>>>>               * Gluster cache-size (ideal values in our setup were 
>>>>>                 96MB-128MB) 
>>>>> 
>>>>>         Hope that helps! 
>>>>> 
>>>>> 
>>>>> 
>>>>>         On Wed, Jul 24, 2013 at 11:32 AM, Razique Mahroua 
>>>>>         <razique.mahroua at gmail.com 
>>>>>         <mailto:razique.mahroua at gmail.com>> wrote: 
>>>>> 
>>>>>             I had much performance issues myself with Windows 
>>>>>             instances, and I/O demanding instances. Make sure it fits 
>>>>>             your env. first before deploying it in production 
>>>>> 
>>>>>             Regards, 
>>>>>             Razique 
>>>>> 
>>>>>             *Razique Mahroua** - **Nuage & Co* 
>>>>>             razique.mahroua at gmail.com <mailto:razique.mahroua at gmail.com> 
>>>>>             Tel : +33 9 72 37 94 15 <tel:%2B33%209%2072%2037%2094%2015> 
>>>>> 
>>>>>             <NUAGECO-LOGO-Fblan_petit.jpg> 
>>>>> 
>>>>>             Le 24 juil. 2013 à 16:25, Jacob Godin 
>>>>>             <jacobgodin at gmail.com <mailto:jacobgodin at gmail.com>> a 
>>>>>             écrit : 
>>>>> 
>>>>>>             Hi Denis, 
>>>>>> 
>>>>>>             I would take a look into GlusterFS with a distributed, 
>>>>>>             replicated volume. We have been using it for several 
>>>>>>             months now, and it has been stable. Nova will need to 
>>>>>>             have the volume mounted to its instances directory 
>>>>>>             (default /var/lib/nova/instances), and Cinder has direct 
>>>>>>             support for Gluster as of Grizzly I believe. 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>             On Wed, Jul 24, 2013 at 11:11 AM, Denis Loshakov 
>>>>>>             <dloshakov at gmail.com <mailto:dloshakov at gmail.com>> wrote: 
>>>>>> 
>>>>>>                 Hi all, 
>>>>>> 
>>>>>>                 I have issue with creating shared storage for 
>>>>>>                 Openstack. Main idea is to create 100% redundant 
>>>>>>                 shared storage from two servers (kind of network 
>>>>>>                 RAID from two servers). 
>>>>>>                 I have two identical servers with many disks inside. 
>>>>>>                 What solution can any one provide for such schema? I 
>>>>>>                 need shared storage for running VMs (so live 
>>>>>>                 migration can work) and also for cinder-volumes. 
>>>>>> 
>>>>>>                 One solution is to install Linux on both servers and 
>>>>>>                 use DRBD + OCFS2, any comments on this? 
>>>>>>                 Also I heard about Quadstor software and it can 
>>>>>>                 create network RAID and present it via iSCSI. 
>>>>>> 
>>>>>>                 Thanks. 
>>>>>> 
>>>>>>                 P.S. Glance uses swift and is setuped on another servers 
>>>>>> 
>>>>>>                 _________________________________________________ 
>>>>>>                 OpenStack-operators mailing list 
>>>>>>                 OpenStack-operators at lists.__openstack.org 
>>>>>>                 <mailto:OpenStack-operators at lists.openstack.org> 
>>>>>>                 http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-operators
>>>>>>                 <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators>
>>>>>> 
>>>>>> 
>>>>>>             _______________________________________________ 
>>>>>>             OpenStack-operators mailing list 
>>>>>>             OpenStack-operators at lists.openstack.org 
>>>>>>             <mailto:OpenStack-operators at lists.openstack.org> 
>>>>>>             http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators 
>>>>> 
>>>>> 
>>>> 
>>>> 
>>>> 
>>>>     _______________________________________________ 
>>>>     OpenStack-operators mailing list 
>>>>     OpenStack-operators at lists.openstack.org 
>>>>     <mailto:OpenStack-operators at lists.openstack.org> 
>>>>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> -- 
>>>> Joe Topjian 
>>>> Systems Architect 
>>>> Cybera Inc. 
>>>> 
>>>> www.cybera.ca <http://www.cybera.ca/> 
>>>> 
>>>> Cybera is a not-for-profit organization that works to spur and support 
>>>> innovation, for the economic benefit of Alberta, through the use 
>>>> of cyberinfrastructure. 
>>> 
>>> 
>>> 
>>> _______________________________________________ 
>>> OpenStack-operators mailing list 
>>> OpenStack-operators at lists.openstack.org 
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators 
>>> 
>> 
>> _______________________________________________ 
>> OpenStack-operators mailing list 
>> OpenStack-operators at lists.openstack.org 
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20130725/dca1863c/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: NUAGECO-LOGO-Fblan_petit.jpg
Type: image/jpeg
Size: 10122 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20130725/dca1863c/attachment.jpg>