Re: [gentoo-user] Linux Fiber SAN

[Nick Khamis <symack@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1937 bytes --]

>
> Hello Nick,
>
> the question is, what are you doing with it and why do you think you
> need a fibre channel SAN.
> Our goal indeed is to get rid of the SAN infrastructure as it is
> delicately to all kinds of failure with nearly zero fault tolerance.
> An example, you have an hicup or a power failure in your network. SAN is
> dead from nowon and must be reinitialized on the server. Simple NFS
> comes back up without any fuzz.
> Another, you boot your storage systems due to an os update or something
> like that. Your SAN will be dead. NFS will just go on as if nothing
> happened.
> We use netapp storage systems which are NAS and SAN capable.
> Another point is, that if you have a SAN lun, there is either no way to
> increase or decrease size on the fly, on cifs or nfs you can resize your
> share on the go.
>
> So if you do not have a _really_ good reason to use a fribre channel
> SAN, don't!
>
> Regards,
> Norman
>
>
Hello Norman,

Thank you so much for your response. That is a very interesting! We
currently use an NFS to house home directories etc.., and I love how it
just bloody works!!! We do however need block level sharing. The idea is
the
typical host with multiple VM with virtual HDDs residing on a SAN..... We
figured
fibre would give us better performance (for the mean time!!!).

It was my understanding that SAN whether implemented using iSCSI
or Fibre was essentially susceptible to the same type
of faults that lead to whatever failures? The only difference being of
course, on is on fibre, and the other using ethernet. Given the price
of fibre right now, it's quite cheap and we though double the throughput,
why not?

We could have the VMs taking storage from DAS, and mount to an
external NFS for home/ etc... Not sure how it would perform in terms of
IO rates, and also, the idea of block level allocation just seems so much
cleaner no?

PS I am new to SAN, please excuse me.

Kind Regards,

Nick

[-- Attachment #2: Type: text/html, Size: 3294 bytes --]