[TriLUG] Any NAS recommendations: Linux & Windows in harmony
franklin at elfie.org
Mon Jul 19 20:58:06 EDT 2004
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
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
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
2. More drives does not have to mean more space. More drives means
more spindles which means more disk throughput. (See bottlenecks
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.
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?
>> How many users will be connecting to it?
>> 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
>> 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?
>> 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 :
>>> 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 :
> 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
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...
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://www.trilug.org/pipermail/trilug/attachments/20040719/80bb917e/PGP.bin
More information about the TriLUG