[SATLUG] 1U Server and SAN

[Travis H.]

On 9/20/06, Greg Willden <gwillden at gmail.com> wrote:
> For the SAN have you looked at www.coraid.com?  The ATA over Ethernet
> (AoE) is really cool.  A coworker is using one for a project and it's
> pretty neat.

Yeah, seconded -- if you can afford the ~ 2x markup, it's probably worth it.
You get block-level access to the drives, so it doesn't matter if your client
wants to write to NTFS volumes but the NAS server only speaks Linux.

I read the storagemojo.com site quite a bit, and it seems this is the thing,
unless you can run ZFS, but if the clients don't talk it, I don't know about
running NFS over ZFS.

Their suggestion was actually to create the file _systems_ as regular files,
so that you can copy them, grow them, shrink them, back them up using
something other than dd or LVM (incidentally, none of the resizing tools
work with LVM, so if you have to move data you need space to copy it,
and you're in linearland so you need contiguous space).

But then again, if you're already going to go through the mapping from
block level to file to block level again, why not use the loopback device
thingie (OpenBSD calls it vnd, not sure if it's called losetup or -o loop or
what in GNUspeak).  You can then export the filesystems via iSCSI,
without paying 100% markup, with a little sweat-of-the-brow.

So far as I know, the only solution that allows for really dynamic growing
of the overall pool while maintaining hardware failure tolerance is ZFS,
and I suspect that ZFS doesn't have all the bugs worked out that you
would expect if you're betting your corporation's data on it.  But if
something goes wrong, you can blame Sun.

Note that only one client can use a LUN/target over iSCSI.  Not sure
about AoE, probably true of that too.  And any RAID has to be done
below that level (at the actual physical block level).

One more thing.  You might be tempted to try RAID 5.  The advice I
wish I had taken was to NOT do that, and to spend a little more for
the extra capacity to do RAID 1.  The parity calculations mean another
round trip from user to kernel mode if using software, and they mean
a parity disk bottleneck even in hardware.  With RAID 5, a write takes
2 reads, a parity calculation, and 3 writes.  With RAID 1, a write takes
2 writes.  Plus recovery is simplified; just use the data on one drive
until you can get another.  And no vendor lock-in on an outboard RAID
card that probably runs a 80186 anyway.  Makes sense to google,
makes sense to me.
-- 
Enhance your calm, fellow citizen; it's just ones and zeroes.
Unix "guru" for rent or hire -><- http://www.lightconsulting.com/~travis/
GPG fingerprint: 9D3F 395A DAC5 5CCC 9066  151D 0A6B 4098 0C55 1484