FibreChannel Stuff

Wed Sep 21 13:19:59 PDT 2005

On Wed, Sep 21, 2005 at 12:14:59PM -0700, Jim Kavitsky wrote:
> Are you planning to use this system "direct attached" via a fiber
> channel arbitrated loop (FCAL) or through a switched fabric SAN?

Direct attached, if I can get away with it.  For a newbie like me,
introducing a SAN network ... that gets complicated, and complicated
things are easier to break and harder to fix.  I'm comfortable with
the KISS principle where if my controller or host fails, I call the
datacenter and asking them to move the connector, if need be.  20-40
minutes downtime ... versus an extra ten thousand dollars and mastery of
new technology on my end.

RAID appliances ... it sounds like the low-end is pretty much FC to
SATA-backed storage.  It sounds like a SATA drive can only attach to one
RAID controller, so I can't have a system where redundant controllers
fail over for each other if one controller fails, though I do some
OS-level "clustering" (say, mirror across RAID controllers) which starts
to violate my KISS principles.

At the next level up, there seems to be this mythical Adaptec SANbloc
which had two FC loops so the drives apparently attached to both Mylex
controllers, but every time I ask the Adaptec vendor about this they
come back at me with FS4500, their SATA-backed solution.  The SANbloc
manual says it supports only two HBAs, one of which is no longer
available, and the other using PCI.

And then there's NetApp ... 

As far as database replication, the dev team has a long-term project to
get a multi-master replication setup.  What about database scalability?
Our database has grown over time and is crufty, the devs have developed
tools to cut out the cruft, and we are moving toward a model where we
can support smaller databases that are dedicated to particulart clients
or client clusters.  My scalability issue, if the devs work right, is
that I get to shrink smaller, lighter databases. :)

So, I need a high-performance solution that can offer if not high
availability, at least a very clean failover process.  FreeBSD is hardly
required for the database, so unless we can find an HBA and disk
appliance combo that we find to work great under load, we are happy to
go with FreeBSD.  I have received one response from this list that
UFS3+journalling is robust with short time-to-recovery (no fsck
required) in the face of a server crash.

Thanks for all your responses so far.  I'll probably have to write an
article or two once I get through all this. :)

Cheers,
-danny

-- 
http://dannyman.toldme.com/