統合ストレージは、ブロック・ストレージ、ファイル・ストレージ、オブジェクト・ストレージのプロトコルを単一の管理可能なシステムに統合するストレージ・アーキテクチャです。マルチプロトコル・ストレージまたはネットワーク統合ストレージ（NUS）とも呼ばれ、iSCSI、ファイバー・チャネル、NFS、SMB、S3 などの複数のストレージ・プロトコルを処理する単一のプラットフォームを、統合管理インターフェースを通じて展開できます。
統合は複雑さを軽減します。例えば、ある企業では 4～5 台の個別のストレージ・アレイがあり、それぞれに専用のハードウェア、ソフトウェア・ライセンス、専門知識が必要となる場合があります。統合ストレージは、ユースケースごとに個別のインフラを必要とせずに、異なるワークロード要件に適合する単一のプラットフォームを提供することで、この断片化を排除します。
このアーキテクチャは、従来のエンタープライズ・アプリケーションとクラウド・ネイティブなワークロードとのバランスをとることで、特に重要になります。仮想マシン、データベース、ファイル共有は、同じインフラ上に共存できます。システムは、所定のストレージ・サイロではなく、実際の使用パターンに基づいてリソースを動的に割り当てます。
統合ストレージの進化
2000 年代初頭のストレージ・アーキテクチャは、組織をサイロ化させました。ストレージ・エリア・ネットワーク（SAN）は、ブロック・プロトコルを介してデータベースや仮想マシンを処理し、ネットワーク接続ストレージ（NAS）システムはファイル共有を管理します。ハードウェア、管理ツール、サポートの各チームが必要でした。ブロック・ストレージとファイル・ストレージの両方を必要とする単一のアプリケーションは、2 つの完全なインフラ・スタックを展開することを意味していました。
2010 年頃、ベンダーがファイル機能をブロック最適化アレイに組み込んだことで、統合ストレージの試みが始まりました。これらのハイブリッド・システムは、ハードウェアのフットプリントを削減しましたが、性能に苦労しました。リソースをめぐって競合するファイルやブロックのワークロードは、予測不可能なレイテンシーを生み出しました。
オールフラッシュ・ストレージは、全てを変えました。フラッシュは、機械的制約を排除し、ブロックとファイルのワークロードが共存する真の統合プラットフォームを可能にし、性能の妥協はありません。最新のシステムでは、マルチプロトコルの同時アクセスが処理され、5 年間で運用コストが個別のシステムの管理と比較して 53% 削減されることが明らかになりました。
統合ストレージのコア機能
マルチプロトコルのサポート
統合ストレージ・プラットフォームは、複数のアクセス方法を同時に処理します。
ブロック・プロトコル（iSCSI、ファイバー・チャネル、NVMe-oF）：
- データベースや VM への直接かつ低レイテンシーのアクセス
- アプリケーションが直接フォーマットできる未加工のディスク・ボリューム
- トランザクション・ワークロードに最適
ファイル・プロトコル（NFS、SMB）：
- Linux、Unix、Windows 間の標準ファイル共有
- ファイルとフォルダの階層
- バックエンド・アーキテクチャに関する知識は不要
オブジェクト・プロトコル（S3 互換 API）：
システムは、ストレージ・レイヤーのプロトコル間で変換します。仮想マシンはデータをブロックとして書き込む一方、バックアップ・システムは同じ情報をファイル・プロトコル経由で読み取ります。データのコピーや変換は一切必要ありません。
グローバル・ストレージ・プール
従来のアーキテクチャでは、容量を事前に割り当てています。SAN は、データベースに 10 TB、ファイル共有に 5 TB を割り当て、人為的な境界を作り出します。データベースの消費が 6 TB に過ぎず、ファイル共有に 8 TB が必要になった場合は、データベース容量の超過分は使用されません。
統合ストレージは、グローバル・プールを通じてこれらの境界を排除します。総容量は、プロトコルに関係なく、あらゆるワークロードで利用可能であり、割り当ては実際の使用量に基づいて動的に行われます。これにより、一般的な展開における総容量要件が削減されます。
統合管理インターフェース
単一の管理インターフェースが、プロビジョニング、監視、性能最適化、データ保護など、全てのストレージ操作を処理します。管理者はポリシーを一度設定するだけで、アクセス・プロトコルに関係なく、全てのワークロードに適用できます。この一元化により、管理オーバーヘッドが削減され、複数のシステム間で変更を調整する際に発生する構成エラーが最小限に抑えられます。
統合ストレージ・アーキテクチャの仕組み
統合ストレージ・システムは、2 つのコンポーネントを統合します。
ハードウェア・インフラには、I/O 操作を管理する高性能ストレージ・コントローラ、ストレージ・メディア（通常はオールフラッシュ）、ブロックとファイル・プロトコルの両方をサポートするネットワーク・インターフェースが含まれます。コントローラはプロトコル変換を処理するため、ブロックとファイル要求は競合することなく同じストレージ・プールにアクセスします。
管理レイヤーは、全てのプロトコルにわたって統合管理、監視、自動化を提供します。このレイヤーは、ポリシーの適用、QoS 管理、データ配置の最適化、容量の割り当てを単一のインターフェースで処理します。
ハイブリッドおよびマルチクラウド環境のための統合ストレージ
モダンな統合プラットフォームはオンプレミス・インフラを超えて拡張されます。データセンターやパブリック・クラウドに同じストレージ・プラットフォームを展開することで、場所を問わず運用の一貫性を確保できます。
クラウド統合の主なメリット：
- 再フォーマットなしで環境間を移動
- アプリケーションは、オンプレミスまたはクラウドで同一のストレージ API を維持
- ワークロードのモビリティとディザスタ・リカバリを簡素化
- クラウド・ストレージへの階層化を自動化し、長期保持を実現
マルチクラウド環境では、複数のクラウド・プロバイダをサポートする統合プラットフォームにより、AWS、Azure、Google Cloud 全体で一貫したデータ・サービスを提供します。マルチクラウド戦略は、統合ポリシー管理のメリットを享受します。クラウド間でのデータの移行時にも、セキュリティ管理、バックアップ・スケジュール、保持ポリシーは一貫しています。
ガートナーの調査によると、パブリック・クラウド・サービスに対するエンドユーザーの支出は、2028 年までに 1 兆ドルを超えると予測されており、オンプレミス環境とクラウド環境を橋渡しするストレージ・アーキテクチャの重要性が高まっています。
統合ストレージの主なユースケース
医療・ヘルスケア：病院は、データベース、DICOM 医療画像、管理ファイル内の EHR など、多様なデータを同時に管理します。統合ストレージは、このインフラを統合します。データベース・サーバーはブロック・プロトコルを介して患者記録にアクセスし、放射線科医はファイルまたはオブジェクト・プロトコルを介して画像を全て 1 つのプラットフォームから取得します。単一のバックアップ・ポリシーが全てをカバーします。
仮想化：VM の性能にはブロック・ストレージが必要ですが、管理者はテンプレートや構成にファイル共有が必要です。統合ストレージは、妥協することなく、容量の無駄もありません。
科学的研究：計算ワークロードでは、分析中にブロック性能が求められますが、研究者は共有とアーカイブのためにファイルベースのアクセスが必要です。統合ストレージは、データセットが研究のライフサイクルを通じて移行するにつれて、システム間での時間のかかるデータ移動を排除します。
メディア制作：編集者にはフレーム単位の正確なランダム・アクセス（ブロック・プロトコル）が必要ですが、資産管理には階層型のファイル構成が必要です。同じコンテンツに異なる方法でアクセスでき、データをコピーする必要はありません。
AI/ML トレーニング：トレーニング・パイプラインは数百万もの小さなファイルにアクセスできますが、GPU の活用をボトルネックにしないようにブロック・レベルの性能が必要です。統合ストレージは、ブロック性能を備えたファイル構造化データを提供します。
DevOps とコンテナ：Kubernetes のようなコンテナ・オーケストレーターは、共有ファイル・システムやオブジェクト・リポジトリとともに、永続ボリューム（ブロック）を使用して構成やログを作成します。これは、統合プラットフォームに自然に適しています。
実装に関する考慮事項
ワークロードの評価から始める：既存のストレージ・システムのインベントリ、ドキュメント容量の要件、アプリケーションの依存関係のマッピングを行います。これにより、統合の機会が明らかになります。同様の性能ニーズを持つアプリケーションはストレージ層を共有でき、関連するデータセットは容量プールを共有できます。
性能の調整が重要：ブロックとファイルのワークロードには、異なる特性があります（ブロックは IOPS／レイテンシを強調し、ファイルはスループットを優先します）。モダンなプラットフォームは自動的に最適化を行いますが、本番アプリケーションを移行する前に、実際の利用状況を反映したワークロードで性能を検証してください。
段階的に移行：
- 重要でないワークロードから始めて機能を検証
- メンテナンス・ウィンドウのあるアプリケーションでは、予定されたダウンタイム中に従来の移行を使用
- 継続的な可用性を必要とするシステムでは、カットオーバー前にデータ・レプリケーションでライブ移行を実行
- 常にロールバック・オプションを計画
考慮すべき潜在的な欠点
学習曲線：ブロック・システムとファイル・システムの分離に慣れているチームは、統合管理パラダイムに関するトレーニングを受ける必要があります。この移行中に一時的な非効率性が生じることを計画します。
極めて高い性能が求められるケース：絶対最大 IOPS を必要とするアプリケーションの中には、専用のストレージが利用できるものもあります。ワークロード評価時にこれらを特定します。通常は、エンタープライズ・ワークロードのごく一部です。
長期コミットメント：統合プラットフォームの選択は重要です。クラウド統合、プロトコルの進化、将来を見据えた機能のベンダー・ロードマップを、コミットする前に評価してください。
ブロック・ストレージ、ファイル・ストレージ、統合ストレージ
ブロック、ファイル、統合ストレージの違いを理解することで、統合ストレージがエンタープライズ・データセンターのどこに当てはまるかを明確にすることができます。
