VM対応ストレージガイド

ほとんどの企業は、共有ストレージインフラストラクチャ上で数十または数百のVMを実行しています。これには、仮想デスクトップから仮想サーバー上で稼働する本番環境データベースまで、あらゆるものが含まれます。ホスティングは、オンプレミスで行うことも、サービスとしてのインフラストラクチャ（IaaS）プロバイダーを通じて行うこともできます。通常は、論理ユニット番号（LUN – ブロック・ストレージの単位）またはファイルベースのストレージボリュームを使用します。

Mordor Intelligenceの研究によると、仮想マシン市場は2025年に135.9億米ドルと評価され、2030年までに269.4億米ドルに成長すると見込まれています。この成長により、同じ共有ストレージに搭載されるVMが増えるため、従来の方法では、どのVMが最も多くのリソースを使用しているか、または速度低下を引き起こしているかを判断することが難しくなります。VM対応ストレージは、この問題を解決するために存在します。

VM対応ストレージは各VMの活動を個別に追跡し、プロビジョニングなどのデータ サービスを個々のVMレベルで適用します。従来のストレージでは1つの単位として扱われる過去の共有ボリュームや論理ユニット番号（LUN）を確認し、どの仮想マシンが特定の時点で1秒あたり最も多くのインプット/アウトプット操作を生成しているか (IOPS) などの詳細まで、仮想マシンのパフォーマンスを追跡します。

このシステムは、複数のVMを同じプールをめぐって競合させるのではなく、各VMに必要なものを提供します。また、VMごとにサービス品質（QoS）の設定、つまり各VMが使用できるストレージパフォーマンスの量を制御するルールを割り当てることもできます。こうすることで、1つの高優先度アプリケーションが同じストレージで低優先度のアプリケーションと競合することがなくなります。ストレージは、VMが作成されるとプロビジョニングされ、ワークロードの変化に応じて調整され、VMが削除されると解放されます。

スナップショットもVMごとに処理されます。スナップショットは、特定の時点でのVMの仮想ディスクの状態をキャプチャし、何か問題が発生した場合でもデータを復元できるようにします。従来のストレージでは、アレイ・レベルのスナップショットが共有ボリューム全体をキャプチャします。VM対応ストレージは、アレイが個々のVMのスナップショットを取得できるため、1台のVMのデータ回復のためにボリューム全体を復元する必要はなくなります。（VMごとのスナップショットは、ハイパーバイザー・レベルで常に可能でしたが、VASではストレージ・レベルでそのような粒度が実現します。）

VM対応ストレージは、アーカイブまたは非構造化データに通常使用されるオブジェクトストレージではなく、VMディスクをホストするブロックおよびファイルストレージに適用されることに注意してください。ブロックストレージと他のストレージタイプの比較について詳しくは、「オブジェクト、ファイル、ブロックストレージの違い」を参照してください。

従来のストレージとVM対応ストレージの主な違いは、可視性です。従来のストレージは、ファイバー・チャネルやiSCSIなどのブロック・プロトコルに依存しています。これらは物理サーバー用に設計されており、個々のVMアクティビティーを確認する方法が組み込まれていません。通常は、ストレージ・エリア・ネットワーク（SAN）の共有ボリュームまたは論理ユニット番号（LUN）を1つのユニットとして提示します。この盲点はオーバープロビジョニングにつながります。管理者は万が一の場合に備えて追加の容量を構築しますが、そのバッファーのほとんどは未使用のままになりがちです。

VM対応ストレージでは異なるアプローチを採用しており、各VMに必要なものだけを提供します。Tintriはこのアプローチを市場に投入した最初のベンダーの一つであり、その後他のストレージベンダーも独自のバージョンを開発しています。

これは、トラブルシューティング中に最も明確に現れます。従来のストレージでは、低速なVMを検出するには、通常、ログを取得して共有ボリューム全体をチェックする必要があり、システムがすでに問題に直面している場合には時間がかかります。VM対応ストレージは、その手順を省略します。この情報は既に個々のVMに関連付けられているため、原因を簡単に特定できます。

VM対応ストレージは、仮想化という大きなメリットを基盤に、いくつかの重要な利点を提供します。

- パフォーマンスの向上
- コスト削減
- より迅速な問題解決
- スケーリングが容易
- より正確な復旧

VM対応ストレージを使用すると、VMは他のVMと結び付けられているリソースを待つ必要がなくなります。これによりレイテンシーが減るため、アプリケーションはより安定して動作します。特に、オールフラッシュ・ストレージのような高速な基盤ハードウェアと組み合わせると、効果は歴然です。

最悪のシナリオに対応するために未使用のままの容量を増やすよりも、元からの容量をより効率的に使用できるため、同じハードウェア上でより多くのVMを実行できるようになります。

ITチームは、ログをいちいち検索しなくても、問題の原因となっているVMを特定できるため、トラブルシューティングの時間が短縮されます。

VM対応ストレージを使用すると、新しいVMが追加されたときにストレージが自動的にプロビジョニングされるため、手動で容量を再設定する必要がなくなります。

単一のVMのデータは、環境の他の部分に影響を与えることなく復元できるため、1つのインシデントによって引き起こされる混乱を最小限に抑えることができます。つまり、VM対応ストレージは、障害発生前にVMごとの複製を行い、その後のより迅速かつ的を絞った復旧が可能になるため、ディザスター・リカバリー戦略に最適です。

VM対応ストレージには、次のような検討に値するトレードオフがあります。

- セットアップの複雑さ
- ベンダー・ロックイン
- コスト

VASは日常の管理を簡素化できますが、移行自体はより複雑になる可能性があります。これは単純にスイッチを入れるだけでは済みません。組織はLUNベースのセットアップから移行することを計画する必要があり、多くの場合、VMレベルの可視性をサポートするために構築されたストレージが必要になります。こうした潜在的なコストについては考慮が必要です。

一部のVM対応ストレージ・システムは、特定のハイパーバイザー（1台の物理コンピューター上で複数のVMを実行できるようにするソフトウェア・レイヤー）、または特定のストレージ・ベンダーと密接に結び付けられているため、ストレージを再構成しないと、後からプラットフォームを切り替えることが困難になります。

VM対応ストレージ・システムは、ハードウェアとソフトウェアがVMレベルでのデータの追跡と管理をサポートしている必要があるため、従来のストレージよりも初期費用が高くなる可能性があります。

VMwareはエンタープライズIT分野でトップレベルの仮想化プラットフォームであるため、ストレージベンダーもそれに合わせた構築を行ってきました。(しかし、BroadcomによるVMware買収後のライセンス変更により、一部の顧客は競合他社に移りました。)そのサポートには以下が含まれます:

- VVols
- vSAN
- VAAI

VVolsは、VMレベルのストレージ統合のためのVMwareのフレームワークです。VVolsは、各VMのディスクを従来の共有データストアに配置するのではなく、ブロック・プロトコルまたはネットワーク・ファイル・システム（NFS）を介してディスク・アレイに個別のオブジェクトとして保管します。

VVolsを使用すると、スナップショット、クローン作成、QoS設定をボリューム全体ではなく、一度に1つのVMに適用できます。

Broadcomが2023年にVMwareを買収した結果、VVolsは廃止の方向に向かっています。新しいvVolsおよびVASAプロバイダー認定は、2025年6月にリリースされたVMware Cloud Foundation（VCF）およびvSphere Foundation（VVF）9.0以降、廃止され、BroadcomはVCF/VVF 9.1でこの主要な機能を完全に削除する予定です。

VMwareはvSANも提供しています。これは独自のストレージ・オプションで、個別のSANなしで、サーバーに接続されたドライブを共有ストレージにプールします。vSANはハイパーバイザーに直接組み込まれているため、VVolsなどの別の統合レイヤーがなくても、性能とデータ保護のためのVMレベルのポリシーを適用できます。

また、VAAI（VMware vSphere Storage APIs Array Integration）もあり、プロビジョニングなどの特定のストレージ・タスクをホスト・サーバーからディスク・アレイ自体に引き継ぎます。VMがテンプレートからクローン化されると、アレイはデータをホスト経由で送信する代わりに、内部でデータをコピーまたは上書きすることができます。VAAIはプロビジョニングやクローンなどの操作を高速化しますが、それ自体はアレイに個々のVMの可視性を提供するものではありません。すべてのベンダーが同じようにVAAIをサポートしているわけではないので、プラットフォームを決定する前に確認しておくことが大切です。

すべてのワークロードが仮想マシン上で実行されるわけではありません。多くの組織では、コンテナも使用されています。コンテナは、完全なオペレーティング・システムなしでアプリケーションをパッケージ化し、多くの場合、VM内で実行されます。コンテナは、一時ストレージまたは永続ストレージ（Kubernetesやその他のオーケストレーターで管理されるクラウドネイティブ・ストレージなど）を使用できます。VMを運用する組織にとっては、VMwareだけが選択肢というわけではありません。代替ハイパーバイザーには、Hyper-V、KVM、Nutanix AHV があります。ただし、各プラットフォームはストレージをそれぞれ異なる方法で処理します。

• Hyper-Vは多くの場合、主要な機能のWindowsサーバー・ストレージ機能と組み合わせて使用され、個別のSANなしでサーバー全体のドライブを共有ストレージにプールします。
  
  
• KVMは通常、基盤となるLinuxストレージ・スタックに依存しており、クラスター全体で共有ストレージを実現するためにCephなどのツールと組み合わせて使用されるのが一般的です。
  
  
• Nutanix AHVは、ストレージとコンピューティングを別個のシステムとして実行するのではなく、単一のプラットフォームにまとめます。AHVハイパーバイザーはKVMをベースにしていますが、NutanixはHyper-VとESXiもサポートしています。

ハイパーバイザーを切り替えると、VMレベルのスナップショット、QoS設定、復旧ポリシーがリスクにさらされます。これは、これらの設定が元のハイパーバイザーのツールに関連付けられていることが多く、常に自動的に引き継がれるわけではないためです。

移行する前に、各VMにどのような保護機能が存在するかをマッピングし、新しい環境でそれらを再現できるかどうか、または再構築する必要があるかどうかを確認しましょう。一部のベンダーは複数のハイパーバイザーを 1 つのプラットフォーム上でサポートしているため、これが簡単になります。その他の場合は、単一のハイパーバイザーを中心に構築されているため、切り替え後に保護を再設定する必要がある場合があります。

2026年8月、BroadcomはVDDK (Virtual Disk Development Kit) への公開ダウンロードアクセスを撤廃しました。VDDKは、サードパーティ製ツールがゲストOSを経由せずにVMディスクを読み取れるライブラリです。Microsoft Azure Migrate、AWS Application Migration Service、Nutanix Moveなど、エージェントレスな移行に使用されていたツールは、Broadcomのテクノロジー・アライアンス・プログラムを通じたアクセスを必要とするか、エージェントベースの方法に切り替える必要があります。

プライベートクラウド、パブリッククラウド、オンプレミス環境にまたがるハイブリッドクラウド環境をすでに管理している組織は、この移行がより簡単だと感じるかもしれません。異なるインフラストラクチャー間でのワークロードの移動は、すでに日常業務の一部となっています。完全移行前に新しいプラットフォームでの復旧テストを実施しておくことには大きな価値があります。これは、テスト段階で不備を発見する方が、移行途中で発見するよりもコストがかからずに済むからです。