how complicated is your automation ?
What sorts of things do you do? For me it's mostly snapshots. I have quite a bit of work invested in orchestrating snapshots. My most complex one was recently here is a visio digram:
Which is co-ordinating a data refresh amongst 26 different systems as a single "process" (where process here means it's all done to achieve a single goal). Basically restoring production MySQL database data to a few different locations for different uses. In order for an environment to properly use the data a bunch of stuff has to be done to the data and to the environment to get it ready for use. You can't just slap a new database in and expect it to work. So there's 8 MySQL databases involved, the data set is about 250G.
It's by far the most complex thing I've personally done (though really the complexity is not high it's more the number of moving parts is the highest). At least 2,000 lines of scripting involved and the process as a whole is based off something I started back in 2007, so the core of it is quite mature. It runs very reliably.
Of what is probably 500 commands that are executed as part of this process (hard to say for sure on the spot since I have scripts abstracting other scripts sometimes abstracting another layer of scripting). Of that, I determined how much goes to the storage array itself.
33 (one of those is optional, I could exclude it and lose no functionality but I like it in there)
That is 4 commands per MySQL database volume which comes down to:
- remove VLUN
- remove volume
- create volume(snapshot)
- create VLUN
(one set of commands for each of the 8 MySQL hosts)
I use software iSCSI a lot as part of this process due to what I consider a flaw in how vSphere handles raw devices maps in 4.x (and I assume 5.x too). I wrote about it four years ago here:
(still using fibre channel as the source volumes, basically ones that don't need to detach and get destroyed on a regular basis)
There isn't a whole lot else I *need* to automate as the platform is already pretty heavily automated on it's own(it's 3PAR in the event my posting didn't obviously imply that from my history).
The point is, of course - it SHOULD be trivial for me to adapt my scripts to pretty much any block storage platform as long as it accepts SSH login, since 99.93% (33 out of 500) commands are not dealing with the storage array directly.
I just checked - and my process has 72 mysql execution commands, so more than double the commands executing SQL code vs running CLI operations on the storage.
So again I don't know what sort of automation your doing, or what you might NEED to do on a new platform, but you might find it's a lot simpler than you think because perhaps you only need to do a tiny amount of work.
At least for the legacy vendors they should be able to change the architecture or CLI interface and maintain some level of backwards compatibility. For example CLI changes, they can just have different CLI modes that one can use(and set as default) for a transition period. For architecture you can change the architecture and if people want to still create a bunch of small LUNs to expose to a host (even though there's no point in said new architecture) let them do it, doesn't hurt the system. Or if they want to pin hosts to particular controllers(even if there's no point) let them do it.
I've never directly scripted on any of the other big storage platforms, I did work with some scripts another person wrote on the EMC Clariion platform in 2003 - 2004, it wasn't pretty.
Storage is not my primary responsibility - certainly not a task I've ever been assigned full time work for. I think I've learned a good amount of interesting stuff over the years on 3PAR though. I think if storage today still worked like EMC Clariion did back in 2004, I know I would probably not be involved in storage today. I saw the spreadsheets and visios the folks made back then and I said to myself "I'm not getting into storage that is way too complicated to be spending my time on(on top of servers, and networking, security, etc etc)".
Then I came across 3PAR (and was having them compete with NetApp at the time since I heard similar simplicity things about that platform at the time - the 3PAR rep was actually the EMC rep for the company that had the Clariions that is how he knew of me and it was a cold call process that took 6 months until we decided to get an eval going). NetApp outright refused to give my company an evaluation array (was looking for a small one at the time just a couple shelves). It was really that refusal that drove me to 3PAR in 2006, which turned out to be a good choice in my book. It took me a while to get up to speed on the architecture (thin provisioning, wide striping, chunklets etc) and stuff but once I did a whole new world opened up and it was pretty cool. Before that time I basically thought any dual controller array was the same as another (specifically I recall looking at possibly using Infortrend FC storage as a much cheaper alternative to 3PAR etc). Sooooo glad I did not go that route!!