| 1 |
Am 12.06.2013 08:33, schrieb Dan Johansson: |
| 2 |
> On 12.06.2013 06:57, Norman Rieß wrote: |
| 3 |
>> Am 11.06.2013 16:19, schrieb Nick Khamis: |
| 4 |
>>> Hello Everyone, |
| 5 |
>>> |
| 6 |
>>> Was wondering what people are running these days, and how do they |
| 7 |
>>> compare to the 10,000 dollar SAN boxes. We are looking to build a fiber |
| 8 |
>>> san using IET and glusterFS, and was wondering what kind of luck people |
| 9 |
>>> where having using this approach, or any for that matter. |
| 10 |
>> |
| 11 |
>> the question is, what are you doing with it and why do you think you |
| 12 |
>> need a fibre channel SAN. |
| 13 |
>> Our goal indeed is to get rid of the SAN infrastructure as it is |
| 14 |
>> delicately to all kinds of failure with nearly zero fault tolerance. |
| 15 |
>> An example, you have an hicup or a power failure in your network. SAN is |
| 16 |
>> dead from nowon and must be reinitialized on the server. Simple NFS |
| 17 |
>> comes back up without any fuzz. |
| 18 |
>> Another, you boot your storage systems due to an os update or something |
| 19 |
>> like that. Your SAN will be dead. NFS will just go on as if nothing |
| 20 |
>> happened. |
| 21 |
>> We use netapp storage systems which are NAS and SAN capable. |
| 22 |
>> Another point is, that if you have a SAN lun, there is either no way to |
| 23 |
>> increase or decrease size on the fly, on cifs or nfs you can resize your |
| 24 |
>> share on the go. |
| 25 |
>> |
| 26 |
>> So if you do not have a _really_ good reason to use a fribre channel |
| 27 |
>> SAN, don't! |
| 28 |
> |
| 29 |
> Hello, |
| 30 |
> |
| 31 |
> I tend to disagree. A correctly designed SAN (using dual Fabric among |
| 32 |
> other things) is a lot more stable and has a lot better performance than |
| 33 |
> any NAS (NFS, CIFS, iSCSI) solution. One other thing that also needs to |
| 34 |
> be correctly configured to have a stable SAN infrastructure is the |
| 35 |
> servers on it (Multipathing, partition alignment, queue depth, ...) |
| 36 |
> according to the storage vendors recommendation. |
| 37 |
> LUN expansion/shrink is storage vendor specific, some can not (netapp |
| 38 |
> apparently) but others can. |
| 39 |
> |
| 40 |
> Just my 2 cents. |
| 41 |
> |
| 42 |
> Regards, |
| 43 |
> |
| 44 |
|
| 45 |
|
| 46 |
Hello, |
| 47 |
|
| 48 |
you are right i did not elaborate on our san setup, but dual fabric, |
| 49 |
correctly configured hba, proper timeout settings, multipathing, |
| 50 |
alignment and proper block sizes, all was cared for. |
| 51 |
And yes, it is stable as long, as no glitch in power, network etc. or |
| 52 |
maintenance is due. Here NFS is far more fault tolerant. |
| 53 |
Our servers are equipped with 10GE ports, which are bonded. Performance |
| 54 |
is not the issue. Further more, is the configuration far easier and more |
| 55 |
robust. |
| 56 |
According to roadmaps ethernet will outperform SAN infrastructure by |
| 57 |
factors soon. |
| 58 |
|
| 59 |
Oh, you can resize the lun, but on the server side you have a |
| 60 |
blockdevice exposed and need to unmount, resize if possible and mount |
| 61 |
again. On nfs it is a df for the old size, resizing and a df with the |
| 62 |
new size with no service downtime. |
| 63 |
|
| 64 |
Regards, |
| 65 |
Norman |
Archives