Suggestions for simple, RELIABLE NAS?

We currently have a NAS solution that, while it more-than meets our
need in storage capacity and performance, isn't as reliable as we'd
like: 2 hosts attached to the same SCSI bus, using a commercial
clustering software to failover NFS and IP between 2 hosts.

Obviously, the SCSI chain is a single-point-of-failure, and it's
bitten us several times. I'm looking for alternatives.

We don't need much scalability: 1 40GB filesystem and 1 60GB
filesystem is more than we'll need in the foreseeable future.

We don't need much performance: both filesystems are used mostly for
applications reading config files during startup (and that doesn't
happen often; even when it does, disk IO is still very low);

So we just need reliability. And I'd like to eliminate the "one SCSI
bus" as a SPOF.

So I'd really appreciate suggestions on alternate configurations. The
only thing I can think of that might resolve our SCSI issue would be
to setup some kind of data replication (VVR or an equivalent,
perhaps)?; the destination filesystem would handle NFS once the IP
used for NFS was failed over (but then what about nfs file locks, and
other stuff?).

Help/ideas greatly appreciated.

(Beeblebrox) wrote in message . com...
We currently have a NAS solution that, while it more-than meets our
need in storage capacity and performance, isn't as reliable as we'd
like: 2 hosts attached to the same SCSI bus, using a commercial
clustering software to failover NFS and IP between 2 hosts.

Obviously, the SCSI chain is a single-point-of-failure, and it's
bitten us several times. I'm looking for alternatives.

We don't need much scalability: 1 40GB filesystem and 1 60GB
filesystem is more than we'll need in the foreseeable future.

We don't need much performance: both filesystems are used mostly for
applications reading config files during startup (and that doesn't
happen often; even when it does, disk IO is still very low);

So we just need reliability. And I'd like to eliminate the "one SCSI
bus" as a SPOF.

So I'd really appreciate suggestions on alternate configurations. The
only thing I can think of that might resolve our SCSI issue would be
to setup some kind of data replication (VVR or an equivalent,
perhaps)?; the destination filesystem would handle NFS once the IP
used for NFS was failed over (but then what about nfs file locks, and
other stuff?).

Help/ideas greatly appreciated.

Ah, so I've STUMPED this usenet group! Cool. I'm blazing new territory!

That's cool. Blazing new territory is why I make the big bucks!

(Beeblebrox) wrote in message . com...
(Beeblebrox) wrote in message . com...
We currently have a NAS solution that, while it more-than meets our
need in storage capacity and performance, isn't as reliable as we'd
like: 2 hosts attached to the same SCSI bus, using a commercial
clustering software to failover NFS and IP between 2 hosts.

Obviously, the SCSI chain is a single-point-of-failure, and it's
bitten us several times. I'm looking for alternatives.

We don't need much scalability: 1 40GB filesystem and 1 60GB
filesystem is more than we'll need in the foreseeable future.

We don't need much performance: both filesystems are used mostly for
applications reading config files during startup (and that doesn't
happen often; even when it does, disk IO is still very low);

So we just need reliability. And I'd like to eliminate the "one SCSI
bus" as a SPOF.

So I'd really appreciate suggestions on alternate configurations. The
only thing I can think of that might resolve our SCSI issue would be
to setup some kind of data replication (VVR or an equivalent,
perhaps)?; the destination filesystem would handle NFS once the IP
used for NFS was failed over (but then what about nfs file locks, and
other stuff?).

Help/ideas greatly appreciated.

Ah, so I've STUMPED this usenet group! Cool. I'm blazing new territory!

That's cool. Blazing new territory is why I make the big bucks!


VVR would be good, but you should wait, they are VRTS is revamping
their product line soon. If you use Netbackup there will be a "data
Life cycle manager" module for NBU 5.0. This will have many
replication and data movement features that will kind of overlap VVR,
and it may be a straight add-on for NBU. In other words nothing to
buy.
The stumper on your problem is that you have low volume, and I presume
low criticality data. So anything that I recommend is going to be
really expensive.
The new Sun 3310 arrays have dual SCSI controllers, that might be an
option. Also you might look at a low end Clariion or even Spinnaker.
Spinnaker is supposed to be a good name in NAS systems.
Then of course there is Netapp. but that sounds like killing a fly
with a 155mm howitzer.

Beeblebrox wrote:
+ (Beeblebrox) wrote in message . com...
+ We currently have a NAS solution that, while it more-than meets our
+ need in storage capacity and performance, isn't as reliable as we'd
+ like: 2 hosts attached to the same SCSI bus, using a commercial
+ clustering software to failover NFS and IP between 2 hosts.
+
+ Obviously, the SCSI chain is a single-point-of-failure, and it's
+ bitten us several times. I'm looking for alternatives.
+
+ We don't need much scalability: 1 40GB filesystem and 1 60GB
+ filesystem is more than we'll need in the foreseeable future.
+
+ We don't need much performance: both filesystems are used mostly for
+ applications reading config files during startup (and that doesn't
+ happen often; even when it does, disk IO is still very low);
+
+ So we just need reliability. And I'd like to eliminate the "one SCSI
+ bus" as a SPOF.
+
+ So I'd really appreciate suggestions on alternate configurations. The
+ only thing I can think of that might resolve our SCSI issue would be
+ to setup some kind of data replication (VVR or an equivalent,
+ perhaps)?; the destination filesystem would handle NFS once the IP
+ used for NFS was failed over (but then what about nfs file locks, and
+ other stuff?).
+
+ Help/ideas greatly appreciated.
+
+ Ah, so I've STUMPED this usenet group! Cool. I'm blazing new territory!
+
+ That's cool. Blazing new territory is why I make the big bucks!

Perhaps RAID-1 across independent iSCSI servers. (For example, MS has
software for turning an x86 system into an iSCSI server.)

Tom Payne

"Beeblebrox" wrote in message
om...
(Beeblebrox) wrote in message
. com...
We currently have a NAS solution that, while it more-than meets our
need in storage capacity and performance, isn't as reliable as we'd
like: 2 hosts attached to the same SCSI bus, using a commercial
clustering software to failover NFS and IP between 2 hosts.

Obviously, the SCSI chain is a single-point-of-failure, and it's
bitten us several times. I'm looking for alternatives.

We don't need much scalability: 1 40GB filesystem and 1 60GB
filesystem is more than we'll need in the foreseeable future.

We don't need much performance: both filesystems are used mostly for
applications reading config files during startup (and that doesn't
happen often; even when it does, disk IO is still very low);

So we just need reliability. And I'd like to eliminate the "one SCSI
bus" as a SPOF.

So I'd really appreciate suggestions on alternate configurations. The
only thing I can think of that might resolve our SCSI issue would be
to setup some kind of data replication (VVR or an equivalent,
perhaps)?; the destination filesystem would handle NFS once the IP
used for NFS was failed over (but then what about nfs file locks, and
other stuff?).

Help/ideas greatly appreciated.

Ah, so I've STUMPED this usenet group! Cool. I'm blazing new territory!

That's cool. Blazing new territory is why I make the big bucks!

While I've got a pretty good idea of what would meet your requirements, I
don't happen to know whether anyone has built it.

What I'd do is use a pair of servers with directly-attached storage (i.e.,
inexpensive hardware, though ECC memory would be good), one being primary
and one a secondary to which all updates were mirrored in a
quasi-transactional manner (i.e., a software solution avoiding both the
expense and the complexity of concurrently-shared - or even
failover-shared - storage). IP failover would work as it does in your
current system. Additional bells and whistles which you wouldn't need
include logical update-mirroring at the file rather than the storage-block
level (the secondary manages its own metadata independently in such a case,
which since it isn't doing anything else useful is reasonable) and/or
concurrent use of the secondary to split the workload. The latter gets a
bit more complex: if the secondary is simply a standby mirror that takes
over on primary failure, you can mirror at the storage-block level via
driver-level software (though this requires that metadata updates associated
with a data update get sent over the interconnect as block changes rather
than being implicit in the single data update message) and, if you're using
a log-protected file system like ext3fs, limit most added complexity to that
special disk-level driver - Linux actually has such mirroring drivers, but
whether there's a surrounding package that would give you everything you're
looking for I don't know (and one of the important things is some guarantee
that once the system fails over to the secondary it won't fail *back* to the
primary without appropriate clean-up of the primary's disk content, which
can be at least - and for at least simple implementations at most - one
disk-write out of synch with the secondary on any fail-over).

As for reestablishing NFS lock context, I'm pretty sure that Sun had
mechanisms to do that with its early cluster software, and my impression was
that they were incorporated into NFS rather than being proprietary - but I
don't know in any detail. Of course, if you want *really* high levels of
reliability you'll need truly fault-tolerant hardware (from Tandem or
Stratus) on your servers (lacking that, operating and file system software
that's suitably paranoid about issuing internal sanity-checks is good for
ensuring 'fail-fast' operation that stops the server before it can
contaminate its partner), storage software that continually checks the
readability of all data so that if a disk fails you aren't likely to find
that one of the sectors on the mirror copy has quietly become unreadable,
and a file system that aggressively validates stored content against
separate checksums (to catch otherwise undetected bus errors, for example,
before they can contaminate the mirror copies).

- bill