Hello!
The comments on this profile are unclaimed and thus are unverified.
Do they belong to you? Claim these comments.
Chuck Hollis
Is this you? Claim Profile »
6 months ago
in Of Emulated Fibre Channel, Virtualization, And The Right Tool For The Job on Stephen Foskett, Pack Rat
Hi Steve -- great post, as usual. There's a good reason why you're on my blog rail!
If you don't mind, a few clarifying statements?
You are quite correct that most FC and iSCSI arrays compose physical disks and allow users to slice them up into logical chunks. However, this can be done preserving the physical nature of the drives, if desired -- for example, putting data on outer tracks to get more performance, or laying things out sequentially if needed, or building certain kinds of wide stripes.
My issue with NetApp and similar emulated approaches is that you lose this capability. The array decides how to lay out the data, and not a skilled user. In some cases, this is not a big deal -- especially when the workloads are not demanding. But, when workloads are demanding, you've taken away an important tool from the storage admin's bag of tricks. And this tends to show up in demanding FC environments.
Put differently, sometimes it's OK to have a file system abstraction layer between you and your disks, and sometimes it's not.
My second comment is that I disagree as to where this might be important. You state it's all about overselling low-end kit. I tend to think it's about having the right tools for the job at hand. Part of the problem is that statements like "Exchange ran OK" are meaningless without context, given the incredibly wide range of how people actually use these applications. I've seen people run Exchange inside a virtual machine from a desktop. It worked great -- for what they were doing!
Finally, this argument extends well outside of the low-end, and into healthy-sized configurations of both NetApp's FAS products, as well as EMC's Celerra / CX product line, where perhaps the differences would be more noticeable.
Thanks again for a thoughtful post!
-- Chuck
If you don't mind, a few clarifying statements?
You are quite correct that most FC and iSCSI arrays compose physical disks and allow users to slice them up into logical chunks. However, this can be done preserving the physical nature of the drives, if desired -- for example, putting data on outer tracks to get more performance, or laying things out sequentially if needed, or building certain kinds of wide stripes.
My issue with NetApp and similar emulated approaches is that you lose this capability. The array decides how to lay out the data, and not a skilled user. In some cases, this is not a big deal -- especially when the workloads are not demanding. But, when workloads are demanding, you've taken away an important tool from the storage admin's bag of tricks. And this tends to show up in demanding FC environments.
Put differently, sometimes it's OK to have a file system abstraction layer between you and your disks, and sometimes it's not.
My second comment is that I disagree as to where this might be important. You state it's all about overselling low-end kit. I tend to think it's about having the right tools for the job at hand. Part of the problem is that statements like "Exchange ran OK" are meaningless without context, given the incredibly wide range of how people actually use these applications. I've seen people run Exchange inside a virtual machine from a desktop. It worked great -- for what they were doing!
Finally, this argument extends well outside of the low-end, and into healthy-sized configurations of both NetApp's FAS products, as well as EMC's Celerra / CX product line, where perhaps the differences would be more noticeable.
Thanks again for a thoughtful post!
-- Chuck
1 reply
I certainly agree that this is important at all levels, but the discussion I linked to was totally focused on the specific case of the NX/AX and lower-end NetApp gear, at least to my eyes. If we open up discussion to the whole of enterprise storage, I bet the discussion would be similar, though the differences might indeed be greater.
Thanks for reading and posting!