Open Stack

Yes, that's why I was careful to clarify that I was talking about parity
RAID.  Performance should be fine otherwise.

--
Chuck

On Wed, Dec 19, 2012 at 8:26 PM, Hua ZZ Zhang <zhuadl at cn.ibm.com> wrote:

> 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.
>
>
>
> [image: Inactive hide details for Chuck Thier ---2012-12-20 上午
> 12:35:58---Chuck Thier <cthier at gmail.com>]Chuck Thier ---2012-12-20 上午
> 12:35:58---Chuck Thier <cthier at gmail.com>
>
>
>    *Chuck Thier <cthier at gmail.com>*
>    Sent by: openstack-bounces+zhuadl=cn.ibm.com at lists.launchpad.net
>
>    2012-12-20 上午 12:33
>
>
> To
>
>
>    David Busby <d.busby at saiweb.co.uk>,
>
>
> cc
>
>
>    "openstack at lists.launchpad.net" <openstack at lists.launchpad.net>
>
>
> Subject
>
>
>    Re: [Openstack] [swift] RAID Performance Issue
>
>
> 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/ea956e33/attachment.html>
-------------- 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/ea956e33/attachment.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/ea956e33/attachment-0001.gif>
-------------- 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/ea956e33/attachment-0002.gif>