← Back to team overview

openstack team mailing list archive

Re: [swift] RAID Performance Issue

 

Its always nice to have the benefit of a nice, big, fat BBU cache :)

On Dec 21, 2012, at 12:03 AM, Chuck Thier wrote:

> 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@xxxxxxxxxx> 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.
> 
> 
> 
> <graycol.gif>Chuck Thier ---2012-12-20 上午 12:35:58---Chuck Thier <cthier@xxxxxxxxx>
> 
> Chuck Thier <cthier@xxxxxxxxx> 
> Sent by: openstack-bounces+zhuadl=cn.ibm.com@xxxxxxxxxxxxxxxxxxx
> 2012-12-20 上午 12:33
> 
> <ecblank.gif>
> To
> <ecblank.gif>
> David Busby <d.busby@xxxxxxxxxxxx>,
> <ecblank.gif>
> cc
> <ecblank.gif>
> "openstack@xxxxxxxxxxxxxxxxxxx" <openstack@xxxxxxxxxxxxxxxxxxx>
> <ecblank.gif>
> Subject
> <ecblank.gif>
> Re: [Openstack] [swift] RAID Performance Issue
> <ecblank.gif>	<ecblank.gif>
> 
> 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@xxxxxxxxxxxx> 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@xxxxxxxxx> 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@xxxxxxxxxx>
> >>>
> >>> 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@xxxxxxxxxxxxxxxxxxx
> >>> Unsubscribe : https://launchpad.net/~openstack
> >>> More help   : https://help.launchpad.net/ListHelp
> >>>
> >>
> >>
> >> _______________________________________________
> >> Mailing list: https://launchpad.net/~openstack
> >> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> >> Unsubscribe : https://launchpad.net/~openstack
> >> More help   : https://help.launchpad.net/ListHelp
> >>
> >
> >
> > _______________________________________________
> > Mailing list: https://launchpad.net/~openstack
> > Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> > Unsubscribe : https://launchpad.net/~openstack
> > More help   : https://help.launchpad.net/ListHelp
> >
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
> 
> 
> 
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp




References