SDSの基本概念を理解することは、このような不安や疑問を解消する一助となるだろう。ソフトウェアで定義された（Software-Defined）インフラストラクチャコンポーネントでは、コンポーネントを抽象化してプログラムによる制御方法を確立することが重要だ。それがストレージでも、コンピュータでも、ネットワークでも同じである。名前に“Software-Defined”と付くものは全て、基盤となるハードウェアから制御プレーンを抽象化し、それを使用可能なサービスとして上位装置のネットワークインタフェース経由で提供することを目的としている。サービスの利用者は、ポータルやアプリケーションのエンドユーザーだ。SDSはポータルよりもアプリケーションで使用されることが多く、該当するのはクラウドオーケストレーションツールやクラウドベースのアプリケーションなどだ。

　このAPIレベルの制御によって、サービスのプロビジョニングと分解が可能になる。この制御には、サービスの品質（QoS）ポリシーの機能とともに、その他のオーケストレーションアクティビティを伴うこともある。「全てのストレージがソフトウェアで制御されるから“Software-Defined”というのではないのか」「ほとんどのエンタープライズストレージのセールスポイントは管理インタフェースではないのか」と思う人もいるだろう。筆者の個人的な定義においてSDSの重要な概念は「抽象化」だ。

制御プレーンについて

　抽象化は、サービスをハードウェアから切り離す上で必要だ。切り離すことで異種ストレージ環境の管理が可能になる。この切り離しによって、クラウドベースのストレージ製品にアプリケーションとインフラストラクチャを移行できるようにもなる。クラウドベースのストレージ製品では、基盤となるストレージにネイティブのインタフェースが表示されない。インタフェースがないことで幾つかの問題が解消される。クラウドベースのストレージ製品では使用者に通知せずにインタフェースが変更されることが少なくないからだ。

　企業には、テスト／開発用のサーバSANと、運用アプリケーション用のストレージプラットフォーム（例えば米EMCの「EMC VMAX」ストレージプラットフォーム）が用意されているかもしれない。SANはダイレクトアタッチトストレージが単一のストレージプールを形成するように仮想化された一連のサーバだ。オーケストレーションの観点からいうと、アプリケーションに一貫したインタフェースを提供するには基盤となるストレージは抽象化されなくてはならない。クラウドアプリケーションを作成している開発者は、ストレージのサイズとともに、ストレージのクラスを指定できる必要がある。ただし、そのストレージの要求にどのアレイが応えるかは、アプリケーション開発者から見えないようになっていなければならない。

　その結果として誕生したのは、SDSがデータのために道を空ける仕組みだ。これはSDSを使用するメリットの1つである。SDSはストレージ管理タスクを管理できる。だが、実際にはデータの通信パスを提供することで管理している。前述の通り、製品によっては管理とプレゼンテーションの両方の役割を果たすものもある。

SDSは仮想ストレージではない

　Software-Defined Networking（SDN）が仮想ネットワークと異なるように、SDSは仮想ストレージとは異なる。仮想ストレージは、データプレーンを抽象化しようとする。オープンソースの「OpenFiler」は仮想ストレージの一例だ。OpenFilerなどの製品には、1つ以上のソースから物理ストレージが提供される。製品はストレージ通信プロトコルを通じて物理ストレージを提供する。サポートされているプロトコルには、Network File System（NFS）、Common Internet File System（CIFS）、iSCSIなどがある。仮想ストレージプラットフォームは、自らをストレージパスに関与させる。これに対して、SDS製品は通信のオーケストレーションを行う。

　VMwareの「VMware Virtual SAN」（VSAN）は興味深い製品だ。ターゲットを提供するためにストレージを仮想化し、ストレージを共有するためにパスを仮想化する。それから、データプレーン制御はSDSに帰属するようになっている。VSANでは、コモディティサーバハードウェアからポリシー主導のストレージを作成することが可能だ。米HPの「HP StoreVirtual Storage」プラットフォームでも“自分のアレイを構築する”オプションが提供されている。

企業向けのオプションを確認する

　SDS市場はまだ成熟過程にある。複数のベンダーの製品にまたがって制御プレーンを管理できるSDSに特化したプログラムを見つけるのは困難だろう。米EMCの「EMC ViPR」は、エンタープライズアレイのストレージのプロビジョニングに関するオープンスタンダードを活用している。だが、同製品が実行できることには限りがあり、それはEMCのストレージにおいても同様だ。また、日立製作所や米NetAppなどEMC以外のベンダーが提供するストレージシステムのサポートは限られている。

　EMCの「EMC VNX」やVMAX、米SolidFire、VMwareのVirtual SANなど、使用するのが単一のプラットフォームに限定される場合、オプションは広がる。どのベンダーも、ストレージのオーケストレーションのために何かしらの“Software-Defined”インタフェースを提供している。この例としてはEMCの「EMC Storage Integrator」が挙げられる。アプリケーションはStorage Integratorの管理ノードのアプリケーションプログラミングインタフェース（API）を通じてストレージをプロビジョニングできる。これはオーケストレーションソフトウェアからストレージを潜在的に制御するという要件を満たすが、全てのエンタープライズストレージを抽象化することは難しくなる。どの機能が複数のストレージ製品で使用できるかによって、IT部門のオプションは絞られる。

　一方、SolidFireや米X-IOなどの新興企業は、完全なREpresentational State Transfer（REST）APIを提供し、エンドツーエンドでアレイを管理できるようにしている。RESTによって、アプリケーションやオーケストレーション製品で、ベンダーネイティブの管理コンソールと同じ管理機能が利用可能になる。前述したような、複数ベンダーの製品にまたがって機能するプログラムを実現するのは、このREST APIのアプローチだ。

　REST APIを活用できるオーケストレーションツールによって、SDSの全てのメリットを享受できる完全なSDSプログラムを実現することが可能になる。VMwareの「VMware vCloud Automation Center」（vCAC）はこの一例だ。vCACは、これらのオープンなストレージ制御APIを使用して、アプリケーション開発者などのクラウド使用者にストレージサービスを提供することができる。

　市場全体はまだ成熟していないが、SDSの機能を支持する声は大きい。個人的には、SolidFireやX-IOなどの新興企業に刺激を受けて、既存のストレージプロバイダーが各社のストレージ管理製品やストレージ自体に強力なREST APIを提供することを期待している。

　ストレージベンダーがREST APIを採用することにより、オーケストレーションプロバイダーとクラウド管理プログラム（オープンソースの「OpenStack」やvCACなど）両方のSDS機能が大きく向上することを願っている。