ソフトウェア指向ストレージ

この記事は、Jet Infosystems Storage Systems DivisionのエキスパートであるArtem Demarinによって作成されました。



今日、多くの人は映画を見に行くよりもVoD（Video on Demand）のサービスを好んでいます。 または、カフェを訪れる代わりに、自宅で食事を注文します。 サービスの形でのリソースの消費はすでに当たり前のことであり、当たり前のことです。

徐々に、このアプローチはITインフラストラクチャ/ ITサービスに適用され始めました。 リソースのオンデマンド作成は、固定構成からの抽象化を可能にするサーバー仮想化システムの積極的な使用のおかげで可能になりました。 初期段階では、これによりITインフラストラクチャとITサービスをサービスと見なすことができましたが、ユーザーの要求を満たすために必要な柔軟性とダイナミズムは提供されませんでした。 この問題を解決するために、ソフトウェア定義のデータセンター（Software Defined Datacenter、SDDC）の概念が開発され、ハードウェアからのすべてのデータセンターコンポーネントの抽象化が提供されます。



このアプローチは昨日発生しませんでしたが、いくつかの要因がその実装を妨げました。 最も重要なのはストレージインフラストラクチャです。 アプリケーション、サーバーおよびネットワーク、ストレージリソース、およびそれらとの生産システムのデータとは対照的に、多くの場合、さまざまなメーカーの固有の機器に関連付けられています。







歴史的に、各ベンダーは利用可能なハードウェアプラットフォームとOSに基づいて製品を作成したか、独自のソフトウェアインターフェイス（API）と独自の機能セットを備えたまったく新しい複合体を開発しました。 その結果、プラットフォームや製品にはさまざまな種類があるため、同じメーカーのアレイでも互いに互換性がない場合があります（複製など、完全または部分的な相互作用の可能性はありません）。



x86サーバーのコンピューティング能力の大幅な向上、およびクラウドテクノロジーの積極的な使用は、ソフトウェア指向のストレージシステム（Software-Defined Storage、SDS）の開発の基盤となっています。 これらのソリューションのストレージおよびデータ管理機能については、ソフトウェアはコンピューティング環境の標準コンポーネント（サーバー、拡張ディスクシェルフ、スイッチ、コントローラーなど）に基づいています。 それらの主な機能は、個々の機能の実装を提供する特殊なハードウェアの欠如です。 現在、ソフトウェア指向のストレージシステムのいくつかのクラスを区別できます。

• 従来のアレイ（EMC XtremIO、IBM FlashSystemsなど）のアーキテクチャを繰り返すハードウェアおよびソフトウェアソリューション。
• x86サーバー（EMC ScaleIO、pNFS、RAIDIX、EuroNAS、Open-Eなど）に基づくソリューションを構築するための独立したソフトウェア。
• オブジェクトデータウェアハウス（Gluster、OpenStack Swift、Ceph、EMC Atmos、HDS HCP、Quantum Lattus、EMC ViPRなど）;
• Hadoop互換ストレージ（Apache Hadoop HDFS互換ソリューション）;
• ディスク仮想化システム（EMC ViPR、IBM SVC、Huawei VISなど）。

この分類は非常に条件付きです。多くの場合、製品はいくつかのクラスに属する機能を実装します。



SDDCの概念は、より均質なコンピューティングコンポーネントを使用し、ソフトウェアレベルで役割を割り当てることにより、ITインフラストラクチャを簡素化することを意味します。 同時に、役割のコンポーネントを選択したり、1組の機器で複数の役割を組み合わせたりすることができます。









図 1.従来のストレージアーキテクチャとソフトウェア指向のストレージアーキテクチャのトップレベルの比較

オブジェクトストレージ

過去7〜10年で、クラシックアレイのメーカーは、ポートフォリオにSDSソリューションを追加し始めました。 ほとんどの場合、従来のストレージシステムを繰り返します：標準プロトコル（FC、iSCSI、IB、FCoE、CIFS、NFS）および同様の機能（動的リソース管理、レプリケーション、スナップショット、クローンなど）を使用してデータへのアクセスを提供します。



明らかに、従来のアレイのアーキテクチャを複製するSDSシステムには、同じ技術的制限があります。つまり、一定数のコントローラー（ノード）、インターフェイスインタラクションポート、およびドライブ（ハードドライブ、SSD）です。 ただし、ソフトウェア定義の概念への移行により、以前は複雑なハイエンドでしか利用できなかったテクノロジー（たとえば、外部ディスクリソースの仮想化）を使用できるようになりました。 基本レベルおよび中間レベルのソリューションのスタックにSDS製品が含まれているため、ベンダーはこれらのセグメントの機能を大幅に強化しています。



今日最も人気のあるのは、データストレージのオブジェクト原則を備えたSDSソリューションです。 主な消費者は、Dropbox、Apple、Amazon、Googleなどの大規模および中規模のクラウドストレージサービスプロバイダーです。プライベートクラウドの場合、オブジェクトアプローチは、サービスを提供できるユニバーサルな新しいノード（サーバー）を追加することで、コンピューティングコンポーネントの統合とインフラストラクチャの動的な拡張を保証します他の役割と同時にストレージ。



オブジェクトの原則は、データ配列の一部の複数のコピー（いわゆるオブジェクト）のストレージを提供します（クラシックソリューションは、1つのリソース内でデータ配列全体の保証されたストレージを担当します）。 セットの少なくとも1つのインスタンスが使用可能な場合、データの安全性が確保されます。 オブジェクトストレージを使用すると、SDSコンポーネントの場所に応じてデータをバックアップできます。 たとえば、データセンターの異なるラックにある異なるノード（SDSに参加しているサーバー）のリソースでオブジェクトを複製できます。 この場合、各オブジェクトの1つまたは複数のコピーが保存されていれば、コンポーネントの一部の損失は許容されます。



オブジェクトの原則により、リソース管理のスケーラビリティと柔軟性が大幅に向上します。 1つ目は、多くのピアの使用により提供されます。 その結果、この特性はハードウェアコンポーネントの制限への依存度が低くなりますが、これは従来のアレイとは言えません。 リソース管理の柔軟性は、動的オブジェクト分散およびストレージアルゴリズムの使用により実現されます。ビジネス要件に応じてストレージの原則を迅速に変更できます。



オブジェクトストレージの主な欠点は、N倍のリソース（Nはオブジェクトの保存されたコピーの数、したがってデータ保護のレベル）と、オブジェクトプロトコル（S3、REST API）を介したデータへのアクセスが必要なことです。 ただし、大量生産のコンポーネント（サーバー、ハードドライブ、スイッチング機器）を使用することにより、過剰なボリュームの費用が払い戻されます。 データアクセスプロトコルの問題はより深刻です。現在、ほとんどのビジネスアプリケーションおよびアプリケーションソフトウェアはオブジェクトプロトコルをサポートしていません。 同時に、許容できる時間と妥当なお金で使用されるソフトウェアの最終化または交換は、多くの場合不可能です。 この点で、主要なSDS製品には現在、従来のプロトコル（iSCSI、NFS、CIFS）を介してリソースを提供するための個別のコンポーネント（役割）があります。



ほとんどの場合、オブジェクトベースまたはストレージベースのストレージシステムを使用するには、従来のアレイまたは類似のアレイとは対照的に、ソリューション機能のより詳細な調査と評価が必要です。 これは、インフラストラクチャ、データバックアップ（RK）、および複合体全体（災害復旧、DR）に対するまったく異なるアプローチによるものです。 この場所での間違いは費用がかかる可能性があります。 考えられる結果の1つは、一貫したパフォーマンスの欠如です。 使用されるデータ分散およびキャッシュアルゴリズムによっては、ローカルリソースではなく、内部ネットワーク（イーサネット、InfiniBand、WAN）を介して他のノード（単一のデータセットのストレージグループのメンバー）にアクセスする場合に状況が発生する場合があります。 図 図2は、このようなパフォーマンスの変動の例を示しています。





図 2.可能なマルチノードSDSソリューションのパフォーマンスのスケジュール



赤い線は、I / O操作の応答時間を表します。 ピーク値は、リモートノードでの操作で発生します。 応答時間を長くすると、操作のパフォーマンスに直接影響します（この時間が長くなるほど、特定の期間に実行できる操作が少なくなります）。 この例は、リモート操作の実行の遅延が一定ではなく、全体的なパフォーマンスが大幅に低下する可能性があることを示しています。 リモートノードでの操作が長くなるほど、全体的なパフォーマンスへの影響は大きくなります。



本稼働環境でのマルチノードSDSのこの機能の影響を最小限に抑えるには、構成の予備的な詳細調査を実施し、そのアプリケーションの基本的な可能性を評価する必要があります。



SDSテクノロジーの積極的な使用が開始された主な分野とソリューション：

• テストおよび開発環境。
• バックアップおよびアーカイブデータの保存。
• パブリック/コーポレートクラウドストレージシステム（Dropboxなど）;
• データのパブリック/企業ウェブホスティング;
• 汎用ファイルストレージ（共有ファイルリソース）;
• 非構造化データの機械処理システム（ソーシャルネットワーク、統計データ処理など）。
• 仮想マシンストレージ
• 情報システムの二次データのBLOBストレージ。

ソフトウェアデファインドストレージシステムは、データストレージソリューションのグループの中で最も柔軟で動的に開発されているテクノロジーです。 それらで使用されるアルゴリズムにより、使用されるコンポーネントとソリューションの総コストを削減できます。 例として、ストレージ環境を構築するタスク。 同社には、同じ都市内に3つのデータセンターがあり、十分な帯域幅のIPチャネルで接続されています。 ストレージ要件は次のとおりです。

• 総データ量-100 TB;
• 3つのデータセンターからの同時読み取り/書き込みアクセス。
• いずれかのデータセンターの損失レベルに対するフォールトトレランス。

従来のディスクアレイでは、この問題を完全に解決することはできません。 現在、2つの技術サイト（HDS G1000 GADなど）からのみ、またはすべてのデータセンターからデータセンターの1つに配置され、他のデータセンターに予約されている単一のストレージへの同時アクセス（読み取り/書き込み用）を提供するシステムがあります。 条件付きソリューションは、サイトごとにセグメントに分割されたストレージリソースの編成と、データセンター間のこれらのセグメントの予約です。 この実装の例を図に示します。 3。









図 3.クラシックアレイを使用した一般化されたソリューションスキーム



このアプローチの実装には、ストレージとバックアップを整理し、ローカルセグメントボリュームへのローカルフル（読み取り/書き込み）アクセスを制限するために、少なくとも200 TBの合計使用可能容量が必要です。 リモートセグメントへの書き込みアクセスは、サイト間の通信チャネルを介して行う必要があります。 したがって、アプリケーションソフトウェアに3つの独立したデータセグメントを提供する必要があります。



次に、オブジェクトアクセスを備えたSDSシステムの使用を検討します。 この場合、3つのサイトのコンポーネント（ノード）の場所を使用して単一のデータウェアハウスを構築することができます。 動的ストレージアルゴリズムにより、各サイトに少なくとも1つのコピーを保存できるようになり、3つのデータセンターのうち最大2つが失われた場合のデータの安全性が保証されます。 このアプローチは、従来のアレイの場合のように、ボリュームの3倍のストレージを必要としますが、安価なコンポーネントを使用すると、ハードウェアのTCOが削減されます。

必要な機器をすべてのデータセンターに配置できない場合があります（スペースの不足、電源の不足、冷却などのため）。 ソリューションは、Quantum Lattusなどのユニークな（より複雑な）データ配布アルゴリズムを備えたSDSソリューションです。データは、回復のためのサービス情報のストレージとともにここに保存されます。 同様のソリューションは、パリティデータを使用してアレイを復元するRAID 5または6です。 Quantum Lattusと従来のRAIDの主な違いは、サービス情報のレベルを制御する機能です。 このため、特定の数のコンポーネントに障害が発生した場合に必要なデータ安全性のレベルを設定できます。 たとえば、いずれかの技術サイトのすべてのコンポーネントの損失を指定できます。この場合、100 TBの使用可能な容量を提供するために必要なストレージボリュームは約164 TBです。









図 4. SDSを使用した一般化されたソリューションスキーム



このソリューションでは、データストレージを確保するための容量を最小限に抑えることができますが、同時に、アクセシビリティ、サイトとSRKソフトウェアのセット間の通信チャネルのスループット、およびデータアーカイブ（オブジェクトストレージシステムと連携できる必要があります）により厳しい要件が課されます。

---

ソフトウェア指向のストレージの開発と使用は、ストレージ業界で最も有望な方向と見なされるべきです。 現在のSDSの実際の使用はいくつかの要因によって制限されていますが、その機能を高め、コンポーネントの安定性と予測可能性を徐々に高めることで、最終的にSDSをほとんどの領域のメインストレージシステムと考えることができます。



オブジェクトSDSの使用における主な制限は、ソフトウェアが利用できないことです。 ほとんどの場合、大規模なソフトウェア製品では新しい機能の実装が遅れ、多くの場合、アーキテクチャ上不可能です。



新しいソフトウェアと従来の製品が「額に」衝突しないことが望まれます。 最善の選択肢は、意思決定のスムーズな変更、または両方の種がニッチを占有し、あまり競争しないモデルです。 特定の技術の擁護者の輪の中に参加することも、側面から観察することもできます。両方から最高の仕事を申し込むことができます。



建設的なコメントを歓迎します。