[K12OSN] New Server Capacity Thoughts.

[James P. Kinney III]

On Sun, 2008-06-08 at 20:31 -0400, "Terrell Prudé Jr." wrote:
> Almquist Burke wrote:
> >
> > On Jun 8, 2008, at 4:33 PM, Terrell Prudé Jr. wrote:
> > > Can you clarify "can't control how the drives will be put to use"? 
> > I use hardware RAID all the time, and I can control exactly how my
> > drives will be used.
> >
> > He means that if you are using hardware RAID it actually sees the two
> > drives as a single drive. You can't partition some of the drive as
> > RAID 1, some as RAID 0, and some as just a standard partition. Also,
> > you can't move them to a machine with a different RAID controller
> > usually and still read them.

Exactly. Until the hardware has fully opensource drivers, I don't trust
them. I know many people love 'em and trust but I don't. I've had to
many mission critical system become crippled until a restore from backup
could happen because the controller died and it's out of production and
the replacement one can't use the drives until they are initialized,
i.e. wiped out blank and reformatted by the new controller.

I can take a Linux software RAID drive pile and move it to a new machine
entirely and I'm good to go.
> 
> Hmm...I'm not sure why that would be desirable outside of an academic
> exercise...but I guess if you're testing, it might be fun to play around
> with.  I just don't see it as enough of a compelling advantage over the
> benefits of hardware RAID, though.
My internal testing showed a performance hit of about 1-3% (about 4
years ago) using software raid vs hardware raid in a sequence of real
world tests (i.e. combination read/write work called by multiple
clients). 
> 
> And as for moving the drives to a different RAID controller, actually
> that can be done if both controllers are the same model, often even the
> same brand (I've done this with Compaq SmartArray 3200's to 5300's). 
> This works because the RAID ID is stored on the drive as well as the
> controller; the original purpose of this is so you can replace the
> controller and not lose your RAID if said controller goes Tango
> Uniform.  This is why my district tends to standardize on one or two
> hardware platforms and then keep a spare RAID controller around.

I have been a HUGE advocate of skip the extended warranty and spend the
same amount of cash to buy replacement parts at the beginning of the
server lifetime. Compaq and Dell raid cards have provided me the most
trouble. Dell has been a nightmare. Can't stand 'em. Won't recommend
'em. Don't support 'em. Get something else!
> 
> I just put the OS (/boot, /, /usr, swap, etc.) on a RAID 1, and then
> /home on a nice, big, honkin' RAID 5 with at least six spindles.  Great
> performance that way, and good SATA disks are cheap.  You want to expand
> your volume group with another RAID?  Much easier with hardware RAID's
> "one disk" appearance to the OS than software RAID.

I no longer use raid 5. Got bit too many times with systems that would
have 2+ drives fail within a single day. Noticed it happened on systems
with sequential serial numbers more often that mixed numbers. With
software raid, I can create partitions to squirrel away config data,
install media, etc and still be able to create raid systems and used
drives from different vendors, brands and even sizes so I don't get the
"next in line" failures.

My current preferred setup is raid 10, stripped mirrors: use an even
number of drives, pair them into mirrors, strip across the pairings:
single speed writes for small chunk size data, distributed writes for
large chunk sizes, blazing fast reads (each drive of the mirror can read
independently of the other so concurrent reads!) and solid data security
(loose a drive in the mirror the stripe is still live - with a
mix-n-match drive pile sudden loss of two drives is minimal and system
can theoretically loose 1/2 the total amount before disaster).

Raid 5 in my mind _requires_ hardware raid to offload the
checksum/parity calculation part. Drive space is cheap enough that a
full mirror is no longer too costly to use.
> 
> The point about swap, though, is a valid one, so I simply add enough
> DRAM to where it isn't a problem anymore.  :-)  That's, of course, what
> should be done anyway if swapping becomes an issue.

For LTSP server I actually turn off swap. If it starts getting used, the
box load is up around 60 anyway so it's going down!
> 
> --TP
> 
> _______________________________________________
> K12OSN mailing list
> K12OSN at redhat.com
> https://www.redhat.com/mailman/listinfo/k12osn
> For more info see <http://www.k12os.org>
> 
-- 
James P. Kinney III          
CEO & Director of Engineering 
Local Net Solutions,LLC                           
http://www.localnetsolutions.com

GPG ID: 829C6CA7 James P. Kinney III (M.S. Physics)
<jkinney at localnetsolutions.com>
Fingerprint = 3C9E 6366 54FC A3FE BA4D 0659 6190 ADC3 829C 6CA7


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.