Open Stack

Chuck, David,

Thanks for your explanation and sharing.
Since RAID 0 doesn't have parity or mirroring to provide low level
redundancy which indicate there's no write penalty, it can improve overall
performance for concurrent IO of multiple disks.
I'm wondering if it make sense to use such kind of RAID without
parity/mirroring to increase R/W performance and leave replication and
distribution to higher level of Swift.




                                                                           
             Chuck Thier                                                   
             <cthier at gmail.com                                             
             >                                                          To 
             Sent by:                  David Busby <d.busby at saiweb.co.uk>, 
             openstack-bounces                                          cc 
             +zhuadl=cn.ibm.co         "openstack at lists.launchpad.net"     
             m at lists.launchpad         <openstack at lists.launchpad.net>     
             .net                                                  Subject 
                                       Re: [Openstack] [swift] RAID        
                                       Performance Issue                   
             2012-12-20 上午                                               
             12:33                                                         
                                                                           
                                                                           
                                                                           
                                                                           




There are a couple of things to think about when using RAID (or more
specifically parity RAID) with swift.

The first has already been identified in that the workload for swift
is very write heavy with small random IO, which is very bad for most
parity RAID.  In our testing, under heavy workloads, the overall RAID
performance would degrade to be as slow as a single drive.

It is very common for servers to have many hard drives (our first
servers that we did testing with had 24 2T drives).  During testing,
RAID rebuilds were looking like they would take 2 weeks or so, which
was not acceptable.  While the array was in a degraded state, the
overall performance of that box would suffer dramatically, which would
have ripple effects across the rest of the cluster.

We tried to make things work well with RAID 5 for quite a while as it
would have made operations easier, and the code simpler since we
wouldn't have had to handle many of the failure scenarios.

Looking back, having to not rely on RAID has made swift a much more
robust and fault tolerant platform.

--
Chuck

On Wed, Dec 19, 2012 at 4:32 AM, David Busby <d.busby at saiweb.co.uk> wrote:
> Hi Zang,
>
> As JuanFra points out there's not much sense in using Swift on top of
raid
> as swift handel; extending on this RAID introduces a "write penalty"
> (http://theithollow.com/2012/03/21/understanding-raid-penalty/) this in
turn
> leads to performance issues, refer the link for write penalty's per
> configuration.
>
> As I recall (though this was from way back in October 2010) the suggested
> method of deploying swift is onto standalone XFS drives, leaving swift to
> handel the replication and distribution.
>
>
> Cheers
>
> David
>
>
>
>
>
>
> On Wed, Dec 19, 2012 at 9:12 AM, JuanFra Rodriguez Cardoso
> <juanfra.rodriguez.cardoso at gmail.com> wrote:
>>
>> Hi Zang:
>>
>> Basically, it makes no sense to use Swift on top of RAID because Swift
>> just delivers replication schema.
>>
>> Regards,
>> JuanFra.
>>
>> 2012/12/19 Hua ZZ Zhang <zhuadl at cn.ibm.com>
>>>
>>> Hi,
>>>
>>> I have read the admin document of Swift and find there's recommendation
>>> of not using RAID 5 or 6 because swift performance degrades quickly
with it.
>>> Can anyone explain why this could happen? If the RAID is done by
hardware
>>> RAID controller, will the performance issue still exist?
>>> Anyone can share such kind of experience of using RAID with Swift?
>>> Appreciated for any suggestion from you.
>>>
>>> -Zhang Hua
>>>
>>>
>>> _______________________________________________
>>> Mailing list: https://launchpad.net/~openstack
>>> Post to     : openstack at lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~openstack
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openstack
>> Post to     : openstack at lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~openstack
>> More help   : https://help.launchpad.net/ListHelp
>>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack at lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>

_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to     : openstack at lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20121220/42d858d5/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20121220/42d858d5/attachment.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pic02594.gif
Type: image/gif
Size: 1255 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20121220/42d858d5/attachment-0001.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ecblank.gif
Type: image/gif
Size: 45 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20121220/42d858d5/attachment-0002.gif>