[TriLUG] Any NAS recommendations: Linux & Windows in harmony

[Aaron S. Joyner]

Kevin Flanagan wrote:

>There's only one thing that gives me pause, the Database you mentioned. 
>Generally speaking, databases such as Oracle, MS SQL, etc, don't perform
>well when they are on network mounted device.  If you have a server type
>system that has the database, then users connect via JDBC, ODBC, etc,
>it'll be a lot better.  If they are using this database for the kind of
>money that you allude to then I would look at this part with a very
>critical eye.   You say that you are using SMB now, no issues with it? 
>What is the system, a Windows machine?  If you can use a server based
>database, then the snapshots aren't as bad, because you control all of
>the parts, shut down the database when you need to to snap it to another
>set of disks. 
>
>I know, many folks will say that they work just fine, and for many
>instances they will, on a network device, but when things go south, many
>a software vendor will tell you "it's the network".  You and I both know
>that most of the time it isn't, but.....
>
>
>I don't think that you will get out of this "on the cheap" if you want
>the kind of performance and reliability that you talk about. 
>
>
>On Sun, 2004-07-18 at 14:02, Glen Ford wrote:
>  
>
>>>  Solutions for video editor's rendering farms will be different from 
>>>solutions for the secretarial pool.
>>>      
>>>
>>This would be large specialized databases
>>    
>>

Kevin took the words right out of my mouth (well, as I was out of town 
over the weekend, he had plenty of time).  :)

I fought with databases being mounted over networks - only because the 
vendor required it.  Don't do it.  Let me just say it again, so 
hopefully it will sink in.  Don't do it.  Hopefully, you will clarify 
this and say that you're not currently doing that, or you have some 
particularly well-adapted solution (as you did say it's "specialized") 
and "databases" is more of a generalization than it sounds.  But as a 
warning to those who may read this in the future - Do not directly 
access databases over a network connection.  Particularly ones that were 
originally written with local-access in mind.  Especially don't do it if 
you're going multi-user.  Even more importantly, not if you're using 
Access .mdb's.  :)  Now that we've gotten that out of the way...

Jason points out that you can certainly achieve all of what you describe 
with Linux.  What he neglects to mention is that it will take a bit of 
elbow grease / leaning time if you're not already familiar with concepts 
such as setting up samba, setting up Raid, setting up LVM, doing 
snapshots with LVM, using rsync or ssh to push snapshots from one box to 
another, etc.  There are all wonderful tools to have in your brain, and 
I would suggest that everyone should give it a go so that they have used 
these utilities precisely as Jason describes.  But be aware that these 
are not "out of the box" solutions in most setups, and they'll take at 
least a little work to tie together as you describe.  Certainly, a lot 
of help is available here on the list if you run into snags along the 
way.  :)

I would suggest, given the relatively minimal details available so far, 
that you should consider going with one big box, probably running Linux, 
that's capable of housing your data.  How much data you're really 
dealing with will determine the rest of the details about your 
platform.  If your requirements really are for 6TB of storage, as you 
suggest, Linux may not be the platform for you.  Yes, this is a Linux 
list, but don't be afraid to use the right tool for the right job.  
Depending on the amount of $$ you have available to throw at this 
project, consider some of the solutions available from Sun - 
particularly something like an A5200 disk array.  Beware though, you are 
likely to get sticker shock.

If you want to use a Linux solution (which is certainly possible, but 
tricky) for a 6TB single file server, you can look towards 34 x 181GB 
drives to reach your total capacity.  Remember if you want to actually 
format this drive and put data on it, it'll need to be something more 
like 38-40 disks to actually break 6TB of usable space.  Generally, the 
performance on comparable SCSI drives (to SATA) is significantly better 
- but you will have trouble with the capacities you'll need.  Generally 
SCSI meets the capacity point better than SATA, as it just isn't as 
developed for this type of setup yet.  The largest SCSI drive you'll 
find will be around 181GB (although 74GB drives are a better choice), 
and then you're looking at 34+ drives -- don't forget the RAID aspect 
which (if you use managed RAID5) will throw you above 45 drives.  In 
order to house all that, you'll need to think "outside the box", and 
rack mount a setup of external 15-bay SCSI enclosures.  Note that to 
achieve your desired capacity you'll need something like 4 of them.  Tie 
each of those back to an internal SCSI card (may consider PCI-X to keep 
the IO bottlenecks down) on one of the newer Intel server boards (ala 
SE7210TP1-E - shop carefully for enough PCI slots).  Another neat thing 
to consider, which I just stumbled on, is Promise's 3U VTrak 15100 
15-drive SCSI-SATA RAID Storage System.  This rack-mountable beast gives 
you 2 SCSI channels to tap into 15 RAID'ed SATA drives.  Consider the 
numbers again, as 6TB = 24 drives x 250GB.  Of course mix in the usual 
overhead for RAID, formatting, etc -- and it becomes much more reasonable.

This paragraph which I don't have time to write, is how to tie into the 
second channel of that Promise box with a redundant second server, for 
when the hardware in your first server fails for what-ever reason.  :)  
Also, this is where I would probably talk about how generally you should 
avoid that problem via redundancy, etc.

Anyway, I've been blabbering for too long, and I'm being pulled away 
from the computer.  This is enough of a start, to give you a taste of 
what really lies ahead in creating a 6TB file server.  It's very 
possible, but be aware of what you're getting into, and don't hesitate 
to touch back to the list for further assistance.

Aaron S. Joyner