In a previous post I decided to shine a light on the murky world of SAN administration and blithely stated that the complexity of fibre-channel is over-stated. And I'll stand by that; I can provision storage in the fibre-channel world pretty much as fast as NAS. I don't need to worry about getting IP addresses allocated, ensure routing is correct and the bane of our lives, ensure that firewalls aren't getting in the way. So when all things are considered, fibre-channel administration is pretty easy until…..
You want to upgrade a component's firmware! Then life becomes nightmarish; last year it took us three months to plan and implement a firmware update on some of our DMXs. Why? Well, we had to ensure that all our servers were at the right firmware; operating-system at the right patch; Oracle at the right patch; ensure that no conflicts were found; then we had to do our directors, then finally we got to do our DMXs. And guess what? We had some problems; so we re-checked everything, only to find that the levels had changed and the HEAT reports flagged things red which were fine when they were run previously. It actually turned out to be something else….
And then I want to install a new DMX4 and guess what? The whole process starts again!
If I want to upgrade some NAS firmware, I don't worry about any of this and that is where NAS wins currently. So FC guys, can you make that easier? Can you not just blithely insist that the latest firmware levels are what we need to go to? I want to know if something won't work obviously but I'll tell you another thing; when my guys raise a support call, tell your support guys that simply telling them to go to the latest level doesn't wash! They'll ask where in the release notes for the latest patch it states that it will fix our problem…why? See above! It simply isn't realistic to track every firmware….and obviously, we'll never go to the first release of anything!
Howdy,
This isnt a fibre channel thing, its the fact that over the many years each storage vendor did not quite adhere to the traditional fibre channel standards.
Each vendor added its own tweaks here, a few tweaks there without really following the “standard”. I am sure there was good reason (well i hope so)!
We still see this now with certain fibre channel switches offering different functionality.
enter… storage admin hell!
Remember the times when you could get LP9000-S, LP9000-E and LP9000 (and i’m sure i am missing some here!). Which vendor would support which?
On numerous occasions I was told under no circumstances would we support your environment if you had a LP9000-x instead of a LP9000-y….
GO FCoE!! 🙂
You could say that NAS is a bit less complex. However, I recently updated Ontap and it introduced a NFS bug that forced an upgrade/patch to every kernel throughout the building. I think you will see similar issues with the clustered NAS solutions as well.
I feel your pain on the dependencies with DMX code and EMCs compatibility matrix! The last shop I was at provided an interesting mix where you would find a server with LUNs from many different versions of FLARE code and Engenuity code. EMC worked through the issues until that one time a FLARE code update brought down hundreds of servers. They were really good at pointing fingers, and then selling millions of dollars worth of Professional Services contracts to fix the “issues”.
Switch to HDS’ USP V. DMX microcode upgrades are always more daunting than USP/USP V.
Put SVC in the middle and you won’t have to worry. As long as we have supported the DD or firmware level in the past, we will support it when you upgrade SVC or your controllers…
Interop requirements and stupidity will be the deathnell of this generation of storage technologies…
IP object stores have many issues, but a massive benefit is that the interop moves to an API level!
The machoistic area of our industy that thinks interop matricies are good, and the tight coupling of interop over many layers of the stack is a good idea, should frankly be put to sleep as soon as physically possible…
We spend most of our working lives managing the tech interop of the infrastructure h/ware & s/ware stack and it simply isn’t sustainable, sensible or commercially valid…