Share disk between two NT servers over SCSI RAID

Share disk between two NT servers over SCSI RAID

Post by BB » Tue, 25 Sep 2001 11:40:20



Hello,

I have two NT 4 servers plugged into a hardware SCSI RAID.  Both servers are
to share the same disk as a data drive.  They are participating in a load
balancing solution.  I am going this route not only for load balancing but
also for redundancy.  If one server fails, the other will keep up with the
load.

I initially thought I could plug them in and the hardware RAID would take
care of the details with the file system.  NOT!  It seems each server is
keeping a copy of the RAID directory in it's local memory.  This is causing
one box to write over the data written by another box.  I also have to
reboot one server in order for it to see the data written by the other
server - or wait a very long time for the directory to finally refresh.   It
is anything but real-time file sharing.

This lead me to discover SAN.  I have read up on SAN as much as possible
today, but that is now leading me to another concern:  The two SAN solutions
that I have seen all depend on one box to administer the file system.
There goes my fault tolerance!  What if that box was to fail?!

So to make a very long story short:  I'm looking for another solution.
Maybe even a device driver, that will let box boxes share the common RAID
disk, without loosing any redundancy.

ANY input is greatly appreciated!

Thank you,

Barry

 
 
 

Share disk between two NT servers over SCSI RAID

Post by TheGazMa » Tue, 25 Sep 2001 22:37:56


Barry,

What you have is a "feature" of NT. Updates will be held in NT virtual memory
"cache" until NT sees fit to write them. NT is not designed to share disks where
multiple parties can access, the performance hit would hurt too much. The
Micro$oft solution is MSCS - but here a single host manages access to a
filesystem until it fails, then the secondary host takes over.

UNIX isn't much better - but at least Clustering software is a bit more mature,
and the SYNC command is built into the OS.

SAN doesn't help much - infact it gets you into trouble - allowing "unlimited"
numbers of hosts to share data - but without any data/update integrity.

Your data can be made safe, however. IBM, EMC,  Compaq etc. all have remote copy
capabilities where a primary disk unit is "mirrored" to a second physical disk -
and SAN makes flipping over to the secondary a doddle, should the primary disk
fail.

Bottom line - unless it's read-only from all parties don't share disks between
multiple hosts unless you have a specialist product to do it (MSCS, Exchange,
various DataBases etc).


> Hello,

> I have two NT 4 servers plugged into a hardware SCSI RAID.  Both servers are
> to share the same disk as a data drive.  They are participating in a load
> balancing solution.  I am going this route not only for load balancing but
> also for redundancy.  If one server fails, the other will keep up with the
> load.

> I initially thought I could plug them in and the hardware RAID would take
> care of the details with the file system.  NOT!  It seems each server is
> keeping a copy of the RAID directory in it's local memory.  This is causing
> one box to write over the data written by another box.  I also have to
> reboot one server in order for it to see the data written by the other
> server - or wait a very long time for the directory to finally refresh.   It
> is anything but real-time file sharing.

> This lead me to discover SAN.  I have read up on SAN as much as possible
> today, but that is now leading me to another concern:  The two SAN solutions
> that I have seen all depend on one box to administer the file system.
> There goes my fault tolerance!  What if that box was to fail?!

> So to make a very long story short:  I'm looking for another solution.
> Maybe even a device driver, that will let box boxes share the common RAID
> disk, without loosing any redundancy.

> ANY input is greatly appreciated!

> Thank you,

> Barry


 
 
 

Share disk between two NT servers over SCSI RAID

Post by Bill Tod » Tue, 25 Sep 2001 22:52:37



Quote:> Hello,

> I have two NT 4 servers plugged into a hardware SCSI RAID.  Both servers
are
> to share the same disk as a data drive.  They are participating in a load
> balancing solution.  I am going this route not only for load balancing but
> also for redundancy.  If one server fails, the other will keep up with the
> load.

The answer is that you chose the wrong platform for what you want to do.

Microsoft doesn't seem interested in supporting any kind of
concurrently-shared-disk file system, so your only options would be file
systems sold for NT by other vendors.  Unfortunately, the few that I know of
that support concurrent access to shared disks still suffer from the
limitation you indicated - a central coordinating server.

Avid sells a system (Trilligent/Unity) that supports moderately fast (order
of a minute?) fail-over of that coordinating server to a twin for higher
availability.  But AFAIK they sell only full systems based on Fibre Channel
JBODs, and also may have a few feature limitations (they sell the system
primarily to support their own media-managing software).  Some of the other
similar systems (from Tivoli, HP, ADIC, and maybe Veritas - may have missed
a couple more that I can't think of right now) may also support such
fail-over by now.

It's conceivable that the 'Internet File System' (?) that Oracle supports as
a feature of its database product would provide the functionality you
describe.  But running Oracle Parallel Server on your two NT4 nodes might
constitute over-kill.

Various Unixes (and possibly even Windows 2000) support file systems that
allow you to partition your data (at directory granularity) among multiple
nodes to achieve some level of load-balancing, mount all the pieces together
into a single directory tree, and have the pieces fail over individually.
This would come somewhere near the functionality you're looking for.  And
FWIW Compaq's OpenVMS (available only on Alpha hardware) supports a file
system that does exactly what you want.

- bill

 
 
 

Share disk between two NT servers over SCSI RAID

Post by J. Clark » Wed, 26 Sep 2001 01:08:30




Quote:> Hello,

> I have two NT 4 servers plugged into a hardware SCSI RAID.  Both servers are
> to share the same disk as a data drive.  They are participating in a load
> balancing solution.  I am going this route not only for load balancing but
> also for redundancy.  If one server fails, the other will keep up with the
> load.

> I initially thought I could plug them in and the hardware RAID would take
> care of the details with the file system.  NOT!  It seems each server is
> keeping a copy of the RAID directory in it's local memory.  This is causing
> one box to write over the data written by another box.  I also have to
> reboot one server in order for it to see the data written by the other
> server - or wait a very long time for the directory to finally refresh.   It
> is anything but real-time file sharing.

> This lead me to discover SAN.  I have read up on SAN as much as possible
> today, but that is now leading me to another concern:  The two SAN solutions
> that I have seen all depend on one box to administer the file system.
> There goes my fault tolerance!  What if that box was to fail?!

> So to make a very long story short:  I'm looking for another solution.
> Maybe even a device driver, that will let box boxes share the common RAID
> disk, without loosing any redundancy.

> ANY input is greatly appreciated!

I'm not sure it will do what you're looking for, but take a look at
Novell Cluster Services.

Quote:

> Thank you,

> Barry

--
--
--John
Reply to jclarke at ae tee tee global dot net
(used to be jclarke at eye bee em dot net)
 
 
 

Share disk between two NT servers over SCSI RAID

Post by Malcolm Wei » Wed, 26 Sep 2001 04:56:49



appear as if it was written:

Quote:>What you have is a "feature" of NT. Updates will be held in NT virtual memory
>"cache" until NT sees fit to write them. NT is not designed to share disks where
>multiple parties can access, the performance hit would hurt too much. The
>Micro$oft solution is MSCS - but here a single host manages access to a
>filesystem until it fails, then the secondary host takes over.

Actually, it's a feature (no quotes) of most sophisticated OSs.

Quote:>UNIX isn't much better - but at least Clustering software is a bit more mature,
>and the SYNC command is built into the OS.

The sync command isn't relevant.  The key issue would be a disk-initiated
"reverse sync" operation.

The problem isn't as stated in the first paragraph; the problem is that
sensible file-system design mandates caching stuff like free-lists,
directories, etc.

And those caches get outdated if another host updates the underlying data,
exactly as with single-processor vs multiprocessor systems and memory.

Quote:>SAN doesn't help much - infact it gets you into trouble - allowing "unlimited"
>numbers of hosts to share data - but without any data/update integrity.

Errr.... blatantly incorrect.

Every SAN addresses the data/update integrity.  Otherwise it's just
plumbing, and we're been able to do that for years.

Quote:>Your data can be made safe, however. IBM, EMC,  Compaq etc. all have remote copy
>capabilities where a primary disk unit is "mirrored" to a second physical disk -
>and SAN makes flipping over to the secondary a doddle, should the primary disk
>fail.

>Bottom line - unless it's read-only from all parties don't share disks between
>multiple hosts unless you have a specialist product to do it (MSCS, Exchange,
>various DataBases etc).

Or a SAN.

Quote:>> I have two NT 4 servers plugged into a hardware SCSI RAID.  Both servers are
>> to share the same disk as a data drive.  They are participating in a load
>> balancing solution.  I am going this route not only for load balancing but
>> also for redundancy.  If one server fails, the other will keep up with the
>> load.

Yep.  You have a problem...

Quote:>> I initially thought I could plug them in and the hardware RAID would take
>> care of the details with the file system.  NOT!  It seems each server is
>> keeping a copy of the RAID directory in it's local memory.  This is causing
>> one box to write over the data written by another box.  I also have to
>> reboot one server in order for it to see the data written by the other
>> server - or wait a very long time for the directory to finally refresh.   It
>> is anything but real-time file sharing.

It's actually a very good way of getting BSODs.

Quote:>> This lead me to discover SAN.  I have read up on SAN as much as possible
>> today, but that is now leading me to another concern:  The two SAN solutions
>> that I have seen all depend on one box to administer the file system.
>> There goes my fault tolerance!  What if that box was to fail?!

As others have noted, your basic problem is significantly based on the
choice of OS...

Quote:>> So to make a very long story short:  I'm looking for another solution.
>> Maybe even a device driver, that will let box boxes share the common RAID
>> disk, without loosing any redundancy.

Your problem is, in the industry, "well understood" (by competent people,
that is).  The snag is that there aren't any good general-purpose solutions.

Here's one of the "gotchas": if you have a peer-to-peer sharing mechanism,
the hosts will need a locking mechanism to decide who gets to write to the
disk at any one time.  If the host currently holding the lock goes away, you
need a mechanism to forcibly steal the lock back to the other host.  And
then what if the original host reappears (it hadn't died, merely gone to
think for a while).

With the cost of hardware being what it is, I'd suggest that perhaps a
warm-standby failover approach might be better for you?

Quote:>> Barry

Malc.
 
 
 

Share disk between two NT servers over SCSI RAID

Post by Maxim S. Shatski » Wed, 26 Sep 2001 03:03:46


Quote:> I initially thought I could plug them in and the hardware RAID would take
> care of the details with the file system.  NOT!  It seems each server is

Surely not. RAID does not know on file system at all.

Quote:> This lead me to discover SAN.  I have read up on SAN as much as possible
> today, but that is now leading me to another concern:  The two SAN
solutions
> that I have seen all depend on one box to administer the file system.
> There goes my fault tolerance!  What if that box was to fail?!

Then we will not be able to administer it (change the settings), but will be
able to run it with the settings that were before the crash.

    Max

 
 
 

Share disk between two NT servers over SCSI RAID

Post by Maxim S. Shatski » Wed, 26 Sep 2001 03:04:35


Quote:> What you have is a "feature" of NT. Updates will be held in NT virtual
memory
> "cache" until NT sees fit to write them. NT is not designed to share disks
where
> multiple parties can access, the performance hit would hurt too much. The
> Micro$oft solution is MSCS - but here a single host manages access to a
> filesystem until it fails, then the secondary host takes over.

Microsoft just has no SAN filesystem. But this does not mean that there are
no non-MS SAN FSDs for NT.

    Max

 
 
 

Share disk between two NT servers over SCSI RAID

Post by Maxim S. Shatski » Wed, 26 Sep 2001 03:05:46


Quote:> Various Unixes (and possibly even Windows 2000) support file systems that
> allow you to partition your data (at directory granularity) among multiple

Yes, and even Windows NT 4.

    Max

 
 
 

Share disk between two NT servers over SCSI RAID

Post by TheGazMa » Wed, 26 Sep 2001 20:35:16




Quote:> > What you have is a "feature" of NT. Updates will be held in NT virtual
> memory
> > "cache" until NT sees fit to write them. NT is not designed to share
disks
> where
> > multiple parties can access, the performance hit would hurt too much.
The
> > Micro$oft solution is MSCS - but here a single host manages access to a
> > filesystem until it fails, then the secondary host takes over.

> Microsoft just has no SAN filesystem. But this does not mean that there
are
> no non-MS SAN FSDs for NT.

Anyone got any good or bad first hand experiences of these ?
 
 
 

Share disk between two NT servers over SCSI RAID

Post by TheGazMa » Wed, 26 Sep 2001 21:26:46




> appear as if it was written:

> >What you have is a "feature" of NT. Updates will be held in NT virtual
memory
> >"cache" until NT sees fit to write them. NT is not designed to share
disks where
> >multiple parties can access, the performance hit would hurt too much. The
> >Micro$oft solution is MSCS - but here a single host manages access to a
> >filesystem until it fails, then the secondary host takes over.

> Actually, it's a feature (no quotes) of most sophisticated OSs.

Surely a sophisticated OS would have a mechanism for sharing disk subsytems
between multiple hosts? z/OS, for example, uses a seperate piece of kit - a
Coupling Facility - for caching shared data. z/OS also interacts with
various disk unit cache subsystems to ensure updates are in disk unit NVS
before assuming an update has been done. It also uses the CF to propagate
data enqueues to all sharing hosts to maintain data integrety. Okay, it's
not as fast as local cache - but it has the advantage of working.

Quote:> >UNIX isn't much better - but at least Clustering software is a bit more
mature,
> >and the SYNC command is built into the OS.

> The sync command isn't relevant.  The key issue would be a disk-initiated
> "reverse sync" operation.

Okay - my only point was I've more faith in an OS that regonises that
flushing memory cache on demand might be a useful function, rather than NT
which doesn't (as standard).

Quote:> The problem isn't as stated in the first paragraph; the problem is that
> sensible file-system design mandates caching stuff like free-lists,
> directories, etc.

 - but it's only "sensible" if you're not sharing the disk.

Quote:> And those caches get outdated if another host updates the underlying data,
> exactly as with single-processor vs multiprocessor systems and memory.

Hmmm... true MP systems should share their level 2 cache and will enforce
single-threading via a locking mechanism when updating such data in storage.

Quote:> >SAN doesn't help much - infact it gets you into trouble - allowing
"unlimited"
> >numbers of hosts to share data - but without any data/update integrity.

> Errr.... blatantly incorrect.

> Every SAN addresses the data/update integrity.  Otherwise it's just
> plumbing, and we're been able to do that for years.

NO WAY !! - What's a SAN ?: A Storage Area Network (SAN) is a dedicated,
centrally managed, secure information infrastructure, which enables
any-to-any interconnection of servers and storage systems - i.e. plumbing. I
guess you use another definition ?

Every SAN certainly doesn't address data/update integrity - every SAN design
should, of course - but that's a very dangerous assumption. SAN out of the
box is just plumbing - and as Barry's original note suggests, people think
you get data sharing for free.

Quote:> >Your data can be made safe, however. IBM, EMC,  Compaq etc. all have
remote copy
> >capabilities where a primary disk unit is "mirrored" to a second physical
disk -
> >and SAN makes flipping over to the secondary a doddle, should the primary
disk
> >fail.

> >Bottom line - unless it's read-only from all parties don't share disks
between
> >multiple hosts unless you have a specialist product to do it (MSCS,
Exchange,
> >various DataBases etc).

> Or a SAN.

!? see above

Quote:> >> I have two NT 4 servers plugged into a hardware SCSI RAID.  Both
servers are
> >> to share the same disk as a data drive.  They are participating in a
load
> >> balancing solution.  I am going this route not only for load balancing
but
> >> also for redundancy.  If one server fails, the other will keep up with
the
> >> load.

> Yep.  You have a problem...

> >> I initially thought I could plug them in and the hardware RAID would
take
> >> care of the details with the file system.  NOT!  It seems each server
is
> >> keeping a copy of the RAID directory in it's local memory.  This is
causing
> >> one box to write over the data written by another box.  I also have to
> >> reboot one server in order for it to see the data written by the other
> >> server - or wait a very long time for the directory to finally refresh.
It
> >> is anything but real-time file sharing.

> It's actually a very good way of getting BSODs.

> >> This lead me to discover SAN.  I have read up on SAN as much as
possible
> >> today, but that is now leading me to another concern:  The two SAN
solutions
> >> that I have seen all depend on one box to administer the file system.
> >> There goes my fault tolerance!  What if that box was to fail?!

> As others have noted, your basic problem is significantly based on the
> choice of OS...

> >> So to make a very long story short:  I'm looking for another solution.
> >> Maybe even a device driver, that will let box boxes share the common
RAID
> >> disk, without loosing any redundancy.

> Your problem is, in the industry, "well understood" (by competent people,
> that is).  The snag is that there aren't any good general-purpose
solutions.

> Here's one of the "gotchas": if you have a peer-to-peer sharing mechanism,
> the hosts will need a locking mechanism to decide who gets to write to the
> disk at any one time.  If the host currently holding the lock goes away,
you
> need a mechanism to forcibly steal the lock back to the other host.  And
> then what if the original host reappears (it hadn't died, merely gone to
> think for a while).

> With the cost of hardware being what it is, I'd suggest that perhaps a
> warm-standby failover approach might be better for you?

Agree with you on that one!

- Show quoted text -

Quote:> >> Barry

> Malc.

 
 
 

Share disk between two NT servers over SCSI RAID

Post by Maxim S. Shatski » Wed, 26 Sep 2001 21:59:31


Quote:> Okay - my only point was I've more faith in an OS that regonises that
> flushing memory cache on demand might be a useful function, rather than NT
> which doesn't (as standard).

Yes, the OS must flush both caches and dirty memory-mapped-file pages on
request from the LUN. Yes, NT does not - at least filesystems shipped with
NT.
AFAIK SAN solutions are usually rely on locking feature of SCSI to share the
LUN across several hosts.

Quote:> NO WAY !! - What's a SAN ?: A Storage Area Network (SAN) is a dedicated,
> centrally managed, secure information infrastructure, which enables

Am I wrong that technically a SAN is a disk device shared across several
hosts at block level with a filesystem instance running on each host?

    Max

 
 
 

Share disk between two NT servers over SCSI RAID

Post by TheGazMa » Wed, 26 Sep 2001 23:38:04




Quote:> > Okay - my only point was I've more faith in an OS that regonises that
> > flushing memory cache on demand might be a useful function, rather than
NT
> > which doesn't (as standard).

> Yes, the OS must flush both caches and dirty memory-mapped-file pages on
> request from the LUN. Yes, NT does not - at least filesystems shipped with
> NT.
> AFAIK SAN solutions are usually rely on locking feature of SCSI to share
the
> LUN across several hosts.

> > NO WAY !! - What's a SAN ?: A Storage Area Network (SAN) is a dedicated,
> > centrally managed, secure information infrastructure, which enables

> Am I wrong that technically a SAN is a disk device shared across several
> hosts at block level with a filesystem instance running on each host?

I'd say a SAN itself has nothing to do with OS filesystems and Operating
Systems themselves. A SAN is the plumbing system - it enables any-to-any
interconnection of servers and storage systems (disk/tape whatever) - so is
comprised of fiber channel HBAs, drivers that understand FC and Operation
System I/Os , and bits of wet string that join FC HBAs together in ever more
clever ways, probably with some fibre switches and/or directors inbetween.

The largest use of SAN I've seen is for Storage Consolidation. Instead of
say 100 servers with 200 SCSI attached storage devices, you have 100
servers, 1 or more SANs, and a couple of big Storage Boxes that you carve
up, via LUN masking, to provide the equivilent of said 200 storage devices.
Then you can start consolidating servers if you want....and share data and
do SERVERless backups and ....??

 
 
 

Share disk between two NT servers over SCSI RAID

Post by BB » Thu, 27 Sep 2001 00:39:35


I looked at the MS Clustering technology yesterday.  What a joke!   I read
that one machine actually controls the shared disk.  Ok, fine.  But I also
read that the box which is sharing the disk will get the data over the
network and not the SCSI bus!  Further, it went on to say the two boxes in
the cluster must use SCSI ID's 6 & 7.  I had intended to run a few clusters
from one RAID box, breaking them up into LUN's.  Now that's just not going
to be possible if all servers must use ID's 6 and 7.

What a wakeup call this has been.   The "warm backup" server in a cluster
isn't really an option.  The whole idea of going this route was for some
real world load balancing.

Max:  If I can run the SAN environment without the box to administer it, is
it safe to say then that I only need this "administration" box up and
running once, to configure the SAN?  After that, I can take it down and only
boot it again when I want to change configuration?

Thank you, everyone, for your input.

Barry



Quote:> > I initially thought I could plug them in and the hardware RAID would
take
> > care of the details with the file system.  NOT!  It seems each server is

> Surely not. RAID does not know on file system at all.

> > This lead me to discover SAN.  I have read up on SAN as much as possible
> > today, but that is now leading me to another concern:  The two SAN
> solutions
> > that I have seen all depend on one box to administer the file system.
> > There goes my fault tolerance!  What if that box was to fail?!

> Then we will not be able to administer it (change the settings), but will
be
> able to run it with the settings that were before the crash.

>     Max

 
 
 

Share disk between two NT servers over SCSI RAID

Post by Malcolm Wei » Thu, 27 Sep 2001 03:35:56



appear as if it was written:




>> appear as if it was written:
>> Actually, it's a feature (no quotes) of most sophisticated OSs.

>Surely a sophisticated OS would have a mechanism for sharing disk subsytems
>between multiple hosts? z/OS, for example, uses a seperate piece of kit - a
>Coupling Facility - for caching shared data. z/OS also interacts with
>various disk unit cache subsystems to ensure updates are in disk unit NVS
>before assuming an update has been done. It also uses the CF to propagate
>data enqueues to all sharing hosts to maintain data integrety. Okay, it's
>not as fast as local cache - but it has the advantage of working.

I would argue that what you're describing *isn't* an OS per se, but a system
consisting of both hardware and software...

But still, I disagree with the notion that "sophisticated" implies hardware
sharing, just as I would disagree with anyone who claimed that
"sophisticated" necessarily implies multiprocessor capabilities...

Quote:>> >UNIX isn't much better - but at least Clustering software is a bit more
>mature,
>> >and the SYNC command is built into the OS.

>> The sync command isn't relevant.  The key issue would be a disk-initiated
>> "reverse sync" operation.

>Okay - my only point was I've more faith in an OS that regonises that
>flushing memory cache on demand might be a useful function, rather than NT
>which doesn't (as standard).

Agreed.  Although, of course, even sync(1m) doesn't actually guarantee much
('cos other processes can happily be dirtying your newly synced disk as the
sync command exits).

Quote:>> The problem isn't as stated in the first paragraph; the problem is that
>> sensible file-system design mandates caching stuff like free-lists,
>> directories, etc.

> - but it's only "sensible" if you're not sharing the disk.

Once again, I disagree.  It is *always* sensible to cache that stuff.  A
sharing scheme needs to address ways to manage that cache safely...

(Whether by proactively invalidating the other host's version, or by
mechanisms by which each host can detect changes.  Remember, most often
we're in a read-mostly environment, and that is a good one for shared
disks!)

Quote:>> And those caches get outdated if another host updates the underlying data,
>> exactly as with single-processor vs multiprocessor systems and memory.

>Hmmm... true MP systems should share their level 2 cache and will enforce
>single-threading via a locking mechanism when updating such data in storage.

Well... I don't know that I would exclude from being "true MP" any system
even if had separate L2 caches.  In terms of elegance, a fully shared cache
is nice, but it's not necessary.

Quote:>> >SAN doesn't help much - infact it gets you into trouble - allowing
>"unlimited"
>> >numbers of hosts to share data - but without any data/update integrity.

>> Errr.... blatantly incorrect.

>> Every SAN addresses the data/update integrity.  Otherwise it's just
>> plumbing, and we're been able to do that for years.

>NO WAY !! - What's a SAN ?: A Storage Area Network (SAN) is a dedicated,
>centrally managed, secure information infrastructure, which enables
>any-to-any interconnection of servers and storage systems - i.e. plumbing. I
>guess you use another definition ?

>Every SAN certainly doesn't address data/update integrity - every SAN design
>should, of course - but that's a very dangerous assumption. SAN out of the
>box is just plumbing - and as Barry's original note suggests, people think
>you get data sharing for free.

Ah.  Clearly you would call a couple of 10 base T adapters, a hub, and some
cable a "network".

I would suggest that there are protocols and software to be considered
before one should call that a network!

Otherwise, every SCSI bus, every Fibre Channel installation is "a SAN".

Using that definition rapidly devalues the term, so I think I'll stick with
a definition something like "a bunch of protocols and software to enable
sharing of storage hardware, possibly (but not necessarily) including the
hardware itself".

Malc.

 
 
 

Share disk between two NT servers over SCSI RAID

Post by Malcolm Wei » Thu, 27 Sep 2001 03:38:26



appear as if it was written:


>> Am I wrong that technically a SAN is a disk device shared across several
>> hosts at block level with a filesystem instance running on each host?

That works for me...

Quote:>I'd say a SAN itself has nothing to do with OS filesystems and Operating
>Systems themselves. A SAN is the plumbing system - it enables any-to-any
>interconnection of servers and storage systems (disk/tape whatever) - so is
>comprised of fiber channel HBAs, drivers that understand FC and Operation
>System I/Os , and bits of wet string that join FC HBAs together in ever more
>clever ways, probably with some fibre switches and/or directors inbetween.

Gak!  That sounds like "Fibre Channel" to me.

Quote:>The largest use of SAN I've seen is for Storage Consolidation. Instead of
>say 100 servers with 200 SCSI attached storage devices, you have 100
>servers, 1 or more SANs, and a couple of big Storage Boxes that you carve
>up, via LUN masking, to provide the equivilent of said 200 storage devices.
>Then you can start consolidating servers if you want....and share data and
>do SERVERless backups and ....??

Whoops!  If you're using LUN masking, we're *definately* not talking about
SANs.  That's plain old vanilla Fibre Channel storage...

Malc.

 
 
 

1. 13 disks, two SCSI busses, two filesystems

Hi!

I'm in the course of setting up an external RAID-System
for a Sun UltraAXi Server.

The selected RAID hardware has two internal UW-SCSI busses,
and one external UW-SCSI bus. I will connect six 9GB drives
and seven 18GB drives in Raid5 mode, giving approx. 40 and 100GB
Filesystems.

Now, what would be the best way to distribute the drives onto
the internal channels?

1. All the 9GB onto one channel, and all the 18GB onto the other?
   Pro: Every filesystem has it's own SCSI-bus and won't interrupt the
        other (except for the external SCSI :-(

2. Three 9GB drives and three 18GB drives onto one SCSI-bus, the
   rest onto the other?
   Pro: When only one Filesystem is accessed, the data is spread
        over two busses, increasing the performance (hopefully).

Both filesystems will mainly contain random-access data, with the
bigger one occasionally transferring big files (1-2GB) at once.

What do you think?

Thanks,

Andreas Holzhammer

2. MSTSC connection issues and permissions and rights

3. Shared SCSI RAID 1 on the Cheap for a cluster

4. How to Replace TaskMan Application with a custom one

5. FS:StorageWorks RAID storage with two hot swappable SCSI-2 drives

6. FS: MagicLink SkyTel Pager Card, $100

7. NT Server RAID configurations

8. VLAN Trunking problem

9. Difference between DELL NAS Appliance and Server Attached RAID SCSI Enclosures

10. Optical Disk problems under Windows NT Server 4.0

11. SCSI disk sparing algorithms (was: Disk performance issues, was IDE vs SCSI-2 using iozone (long))

12. Firewire RAID 0 or RAID 1 (dynamic disks) on Win2K

13. RAID 7 disk array platforms versus earlier RAID 4 & 5