Quoting Nick Bryant <list@xxxxxxxxxxxxxxxxxxxxxx>:
>> AoE is _not_ it then. AoE does _not_ allow shared storage.
>> You must slice the array for each system so they are
>> _independent_. It is _not_ a SAN. It does not have
>> multi-targetting features, only segmented target capability.
>
> Ok forgive me for my knowledge of SANs isn't great, but I thought if you
> were using a SAN that represents itself as a block device (a real SAN) that
> only one machine could have true read/write access to the "slice"? That was
> unless you used a file system like GFS (I wasn't intending too). When I said
> shared storage I didn't mean it had to be accessed at the same time from all
> hosts. The RHEL cluster suite in an active/standby setup actually mounts the
> partitions as a host changes from standby to active after its sure the
> active host hasn't got access anymore with a "lights out" OoB setup.
>
> Well that was my understanding of how it worked anyhow?
Exactly, that was what got myself confused too. SAN doesn't provide "safe"
concurent access to device by itself, you need to have cluster-aware file
system running on top of it. With SAN, one would always configure zones (on
the switch) and/or LUN masking (on storage device) to prevent clients fighting
for the storage and corrupting data.
NAS offers safe concurent access (generally, there might be some NAS devices
outthere that do not). NAS device will manage file system internally, and
export it over NFS or SMB protocols to the clients. It's going to be slower
and less efficient than SAN device though (because of the upper protocol
overhead), and the set of features offered by file system might not be what
would be available if file system was managed by client's operating system
itself.
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
