Swordfish Storage Management Falls Short

More on Infrastructure Live at Interop ITX

I think most storage admins today look wistfully at their server and network counterparts and wish they had automated management tools on par with what they use. Clearly, any real progress in agile data centers requires storage to catch up and do what public cloud vendors have been doing for years.

Automated orchestration is the goal for storage, just as it is for the other areas. This is driven partly by the emergence of software-defined storage (SDS), albeit without standards for APIs. Meanwhile, hyperconverged systems create their own management challenge with distributed virtual SANs.

The Storage Networking Industry Association (SNIA) has begun the development of a storage management tool aimed at large installations. Dubbed Swordfish, this project aims to simplify management and also cope with today's scale-out requirements. So far, unfortunately, it falls short of addressing problems on the horizon.

Swordfish derives from a prior SNIA effort, Redfish, which, by SNIA’s own admission, is complicated to set up and use. Swordfish builds on Redfish’s fundamental object classes for devices and appliances with a service layer that defines data services and a systems layer that allows aggregated groups of objects to be called out.

Where's the GUI?

Currently, the Swordfish specification is still under development. Release 1.0 is available as of January, but downloadable code is still some months away. There are some mock views of how screens might look available on the SNIA site.

Swordfish right now supports only block I/O and filers, though object storage, hyperconverged systems, and storage security are all on the roadmap. There are Swordfish APIs for applications to call provisioning and monitoring functions, which underscores one of the shortfalls of the approach. Unlike most management tools, Swordfish is a framework to allow standardization of API calls to low-level functions. It isn’t a high-order single-pane GUI management tool, so it isn’t really automated.

swordfish.png

Top-layer functionality will require another layer of code, likely from platform vendors like Dell Technologies, Hewlett-Packard Enterprise or NetApp or mainstream storage software suppliers such as IBM or Veritas. These companies can create the drill-down dashboards that are all the rage today.

Without the GUI layer, storage admins using Swordfish are reduced to defining their storage environment in exhausting detail in tabular form. Operations are CLI-based. It isn’t yet clear how far auto-discovery can go in building the system topology. Swordfish class definitions are very detailed, but much of the Swordfish management data in the system won't likely be used, while its presence will slow up admin operations enormously. For the admin, operating with a naked Swordfish interface is probably not a good plan, but the bolt-on front-ends that are in the pipeline may significantly ease management tasks in the block IO space, especially if policy-based control and operational templates are included.

Not focused on future

In a way, Swordfish seems to be solving yesterday’s SAN problems, with a priority on support for block and filer rather than cloud and object storage, a CLI-based user interface, and fine granularity on individual elements such as drives or adapters. In contrast, today’s server management tools are more “cloudy” in their approach, aiming to automate away most management interactions. We should aim to “orchestrate” storage in much the way servers and virtual networks are handled in public clouds.

To meet future requirements driven by software-defined virtualized storage (SDS), the Swordfish working group will need to shift its focus to coordinating and controlling the various SDS elements in real time. This is already a major issue in hyperconverged systems design and no good storage management solutions exist yet. The desired solution will virtualize, to allow scaling on demand for management itself and to allow these tools to co-exist within a fully virtualized environment.

The industry needs something Swordfish or something like it to make sense out of software-defined storage. We need something to standardize the semantics of SDS and to converge the APIs into a solid working set. Otherwise, we’ll need to rewrite each app or script set every time a new data service or hardware node is added to the system.

This API convergence has to accommodate extended metadata mechanisms that support data-driven storage services. A tag that says “remove after three years” needs to be honored, for example. This tagging will be a major part of any SDS system and we are already seeing its use in backup systems such as Rubrik.

Without a solid storage management solution for the next evolution of storage, we’ll have vendors hyping their SDS solutions like crazy, but the systems won't be able to talk to each other. Clearly, today’s Swordfish doesn’t stretch far enough.