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

[John Franklin]

Don't build it yourself.  Linux is cool, but you need something that's 
bulletproof reliable, tested as such, and supported.  Talk to the big 
boys of NAS.  NetApp, EMC, IBM.

The rest of this is pulled out of my protein-based memory, and as such 
should be double checked before being taken as gospel.  Especially the 
"foo does bar" statements.  Invite the vendors, let them razzle dazzle 
you.

NetApp uses a file system based on LFS (Log-based File System.)  LFS 
excels in writes because it treats the entire drive as one giant log.  
Writes are always in the next available segment, and until you reach 
80% full, most writes -- even large ones -- don't require the drive 
head to move.  Very very fast.  At 80% full the system spends a huge 
amount of time trying to coalesce segments together to free up space.  
Very very not fast.

For database support, look for something that can export the raw disk 
device.  NBD is the way Linux does it.  iSCSI is another option with 
some support out there.  Databases that can use their own partitions do 
so because they can improve their speed if they can assume that logical 
sequential blocks are (most likely) physically sequential.  More true 
for raw block devices than for file systems.  NAS vendors offer raw 
disk exports to support this.  Bring your DB guys into the vendor 
meetings.

NetApp and EMC support what they call "snapshots."  I think IBM does, 
too, but talk to their sales rep about it.  Snapshots take a moment in 
time and say, "This is the state of the disk at this time."  Takes 
maybe 20 seconds to snapshot the disk.  Subsequent changes are diffs 
based off of that snapshot.  When you go to do a backup, you backup the 
latest snapshot which will be stable and quiescent.  Zero down time, 
clean backups.  You might not need this level since you're dealing with 
short bursts of intense activity with lots of slow time in between.

For each directory, NetApp (IIRC) adds a .snapshot directory which has 
the snapshot versions of the files.  If a user accidentally deletes his 
file, he can cp the latest snapshot out without bothering the admin.  
Users can't write or delete files in the .snapshot directory.  Other 
vendors have their own ways of doing this.

A few bits on NAS boxen:

1. Everything is a bottleneck.  Fiber Channel, GigE, PCI, even main 
memory.  Compute the total I/O the box can do, compare it to the memory 
bus speed.

2. More drives does not have to mean more space.  More drives means 
more spindles which means more disk throughput.  (See bottlenecks 
above.)

3. Bigger drives means more space.

4. FC switches are expensive.  And for good reason.

5. More main memory means more cache.  At 4TB drive space the best you 
can hope for is 4G RAM to 4TB drive space.  You have 0.1% cache space.  
At 6TB...  (Oh, and the OS and services have to fit in there, too.)

6. Good things are redundant, which is good.

jf

On Jul 18, 2004, at 2:02 PM, Glen Ford wrote:

> John Franklin wrote:
>
>> A few questions about your installation:
>>
>> 1. How much space will they need?
>
> 6TB
>
>>   How many users will be connecting to it?
>
> 10-30
>
>> 2. What OSes are the client machines running
>
> Windows XP
>
>> and what is the role of the client machines/users?
>
> Running specialty app that crunches large amounts of data
>
>>   What I'm looking for here is how intensive will their use of the 
>> NAS boxes be?
>
> Large amount of time with small updates and then large spikes in data 
> writes.
>
>>   Solutions for video editor's rendering farms will be different from 
>> solutions for the secretarial pool.
>
> This would be large specialized databases
>
>> 3. Do they need backups?
>
> YES
>
>>   What level of backups?
>
> FULL snapshot.  I.E. copy all data to seprate NAS .
>
>>   Weekly?  Daily?  Do you need to be able to snapshot the NAS box 
>> every six hours?
>
> Snap shot once a day and option for on demand snap shot
>
>>   Is there a downtime where files aren't being actively modified when 
>> a (potentially long) backup can occur?
>
> Not sure. Need to talk to D/B folks about quescing
>
>> 4. How critical is their availability/accessibility need?
>
> Very, as in lots O'money depends on it.
>
>>   That is, how important is it that the system not be down for a day. 
>>  Everyone says "critical", but there's a difference between "used 
>> while tracking the 101st into Falujah" critical, "Air traffic 
>> controllers are using this" critical, and "my dentist can't bill 
>> clients without it" critical.
>>
>> I know, it'd be nice if it were all OS agnostic, but SMB is good for 
>> Windows and NFS is good for *NIX.  There are NFS clients for Windows 
>> and SMB clients for *NIX, but SMB was built targeting Windows and NFS 
>> was built targeting *NIX.
>
> Current solution is SMB. See no reason to change
>
>>
>> On Jul 17, 2004, at 1:37 PM, Glen Ford wrote:
>>
>>>
>>> -- 
>>> TriLUG mailing list        : 
>>> http://www.trilug.org/mailman/listinfo/trilug
>>> TriLUG Organizational FAQ  : http://trilug.org/faq/
>>> TriLUG Member Services FAQ : http://members.trilug.org/services_faq/
>>> TriLUG PGP Keyring         : http://trilug.org/~chrish/trilug.asc
>>>
>
> -- 
> TriLUG mailing list        : 
> http://www.trilug.org/mailman/listinfo/trilug
> TriLUG Organizational FAQ  : http://trilug.org/faq/
> TriLUG Member Services FAQ : http://members.trilug.org/services_faq/
> TriLUG PGP Keyring         : http://trilug.org/~chrish/trilug.asc
>
-- 
John Franklin
franklin at elfie.org
ICBM: 38º 56' 32.6"N 77º 24' 47.7"W Z+62m
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
URL: <http://www.trilug.org/pipermail/trilug/attachments/20040719/80bb917e/attachment.pgp>