Re: RAID performance

[Stan Hoeppner <stan@hardwarefreak.com>]

On 2/20/2013 9:10 PM, Adam Goryachev wrote:
> On 21/02/13 11:45, Stan Hoeppner wrote:

> Not a problem, the root SSD is not really in question here, it is not
> relevant to the system performance overall, it was just as a comparative
> value...

Yes, I was simply explaining one reason the results on a per drive basis
would be a little lower for the root drive.

> Is there a way to tell FIO to do random read/write tests?

Yes.  The job file in my previous email is exclusively random tests.  It
also contains things that should give results that reflect more closely
your actual workloads.

...
> You can call it any number of things, including pissing in the wind, but
> sometimes it just makes life easier when doing a tender/proposal for a
> prospective client to tick the box "do you have a disaster recovery
> plan, does it include offsite/remote computer facilities/whatever... A
> lot of these are government or corporate tenders where in reality, it
> would never make a difference, but they feel like they need to ask, and
> saying no gives a competitor some advantage.

...
> The main aim would be to allow recovery from a localised disaster for
> all the remote offices, while head office might get trashed, at least if
> the remote offices can continue with business as usual, then there is
> still an income/etc. If there was a real disaster
> (earthquake/flooding/etc) then they are not likely to be doing much
> business in the short term, but soon after the recovery, they would want
> to be ready to provide services, whether that is by one of the remote
> offices handling the workload, etc.

If you're doing real DAR planning, you're going to need more than just a
block IO mirror at the remote site, obviously.  You also need a plan in
place to get people connected with the data on it, get them working
again, which means workstations and office space, and have it all lined
up and in place before disaster strikes.  It's literally just like
football, tennis, etc.  You have to practice before the big match.

I've developed DAR plans for two former employers, implemented one.  One
decided it was too costly.  The other gave me budget for leasing office
space for a skeleton crew, not just IT but a few people from each dept.
 We had complete duplicate servers and storage, workstations, switches,
router, all pre-configured, phones, etc.  We had a DAR clause added to
our Bell contract and lines in place for phone trunk and a T1 for net.
Upon activation of our DAR plan, Bell would switch our circuits over
with 4 hours of the call, and we could pick up our tapes from the vault
immediately to start our restore from the previous night.  We performed
a test run sans the phone cutover, worked out some kinks, and everything
worked on the second go, up in 24 hours working straight through.

That's how DAR is done properly.  Or at least, one method of many.  This
is called a "warm site".  A cold site would be arranged but unallocated
office space with equipment staged in storage, no circuit arrangement.
Hot site is self evident.

> As I've discussed with other clients, especially where they only have a
> single office, and all staff live locally, having an inter-state
> disaster recovery centre is pretty useless, since with that level of
> disaster you will all be dead anyway, so who really cares :) ie, if a
> nuclear weapon is detonated in my city, my customers won't be alive to
> call me, and I won't be alive to deal with it, and their customers won't
> be alive/etc (ie, does your local butcher need offsite
> backup/replication...)

Nobody doing DAR considers nuclear war.  Earthquake, floods, tsunamis,
tornadoes, terrorism, design flaw structural failure, stuff like that.
Which are survivable, but can leave a facility in shambles, companies in
ruin, and people out of work.

> As mentioned, the business case is minimal, which is why the budget for
> it is minimal. If it can't be achieved with minimal (basically nil)
> expenditure, then it will be delayed for another day. However, having it
> will mostly benefit by adding something else for the salespeople to talk
> about more than the actual functionality/effectiveness.

Hell, if the issue is sales, they're lying if their mouth is open.  Just
tell clients you have it, regardless. ;)

> At worst, having DRBD simply re-sync each night would provide adequate
> advantage/protection.

Of that data.  As I stated above, people need to be able to get to it
and get working afterward.  That's part of the "business case" I was
referring to.

...
> I didn't know all that, but it was definitely a large part of my
> preference. I really dislike corporations that behave badly, and like to
> support the better behaved corporations where possible (ie, basic
> business sense still plays a part, but I'd rather pay 5% more for AMD
> for example).

AMD has already announced their intention to de-emphasize their x86
processor business and focus on the mobile market.  This was a result of
the Bulldozer CPUs performing lower than expected, lower than the
previous generation in many applications, and falling even further
behind Intel in performance.  And a huge loss that quarter.  I hope they
reverse course here...

> All very interesting information, thanks for sharing, I'll keep it in
> mind on my next system spec.

Not only does SuperMicro offer far more Intel server boards than Intel,
they also offer more AMD server boards than anyone.  Here's an
inexpensive server board for Opteron 3000 (AM3+) that has an integrated
8 pot LSI 2308 (9207--same as yours):
http://www.supermicro.com/Aplus/motherboard/Opteron3000/SR56x0/H8SML-7.cfm

-- 
Stan