ESXi を SAN と併用すると、柔軟性、効率、信頼性が高まります。また ESXi を SAN と併用すると、統合管理、フェイルオーバー、およびロード バランシングのテクノロジーもサポートされます。

ESXi と SAN を併用すると、次のようなメリットがあります。

  • データを安全に格納し、ストレージへのパスを複数構成することで、単一点障害を除去できます。
  • ESXi ホストは、複数のストレージ アレイ（異なるベンダーからのアレイを含む）から提供されるストレージ デバイスにアクセスできます。
  • SAN を ESXi システムと併用すると、サーバの耐障害性が得られます。SAN ストレージを使用すると、ホストで障害が発生した場合に、すべてのアプリケーションを別のホストですぐに再起動できます。
  • VMware vMotion を使用すると、仮想マシンをライブ移行できます。
  • VMware HA （High Availability）を SAN と併用すると、ホストで障害が発生した場合に、仮想マシンを最後の既知の状態で別のサーバ上で再起動できます。
  • VMware Fault Tolerance （FT）を使用すると、保護対象の仮想マシンを 2 台の異なるホストに複製できます。プライマリ ホストで障害が発生した場合、仮想マシンは中断せずにセカンダリ ホストで動作し続けます。
  • VMware DRS （Distributed Resource Scheduler）を使用すると、あるホストから別のホストに仮想マシンを移行してロード バランシングを実行できます。ストレージは共有 SAN アレイにあるため、アプリケーションはシームレスに実行を継続できます。
  • VMware DRS クラスタを使用している場合は、ESXi ホストをメンテナンス モードに切り替えて、すべての実行中の仮想マシンを別の ESXi ホストに移行します。その後、元のホストでアップグレードまたはその他のメンテナンス操作を実行できます。

このストレージが共有されているという特徴は、VMware 仮想マシンの移植性およびカプセル化でさらに強化されます。仮想マシンが SAN ベースのストレージにある場合、即座にあるサーバで仮想マシンをシャットダウンして別のサーバで起動したり、あるサーバで仮想マシンをサスペンドして同じネットワークの別のサーバで動作をレジュームしたりできます。この機能によって、共有アクセスを整合性のとれた状態で維持したまま、コンピューティング リソースを移行できます。

ESXi と SAN の使用例

SAN と併用すると、ESXi は、Storage vMotion、DRS (Distributed Resource Scheduler)、High Availability などをはじめとする複数の vSphere の機能の利点を活用できます。

ESXi を SAN と併用すると、次のタスクの実行に効果的です。

ストレージ統合とストレージ レイアウトの簡素化
複数のホストを使用していて、各ホストが複数の仮想マシンを実行している場合、ホストのストレージは不足します。外部ストレージが必要になる可能性もあります。SAN には、システム アーキテクチャが単純化されるなどの利点があります。
ダウンタイムなしのメンテナンス
ESXi ホストまたはインフラストラクチャのメンテナンスを実行するとき、vMotion を使用して、仮想マシンをほかのホストに移行します。共有ストレージが SAN にある場合、仮想マシンのユーザーの操作を停止することなく、メンテナンスを実行できます。移行の間、仮想マシンの作業プロセスは続行します。
ロード バランシング
DRS クラスタにホストを追加でき、ホストのリソースはクラスタのリソースの一部になります。クラスタ内にあるすべてのホストおよび仮想マシンの CPU およびメモリ リソースの配分と使用率を継続的に監視します。DRS は理想的なリソースの使用とこれらのメトリックを比較します。理想的な使用とは、クラスタのリソース プールと仮想マシンの属性、現在の需要、および不均衡なターゲットを考慮したものです。必要に応じて、仮想マシンの移行が実行（または推奨）されます。
ディザスタ リカバリ
VMware High Availability を使用して、複数の ESXi ホストをクラスタとして構成できます。仮想マシンで実行されるアプリケーションは、システム停止からの迅速なリカバリと、費用対効果に優れた高可用性を得ることができます。
アレイの移行とストレージのアップグレードの簡素化
新しいストレージ システムを購入したときは、Storage vMotion を使用して既存のストレージから新しいターゲットに仮想マシンをライブ移行できます。移行は、仮想マシンを停止することなく実行できます。

SAN ストレージを ESXi と併用する場合の特性

SAN と ESXi ホストとの併用は、従来の SAN の使用方法とさまざまな点で異なります。

  • ストレージ上に存在する仮想マシンのオペレーティング システムに、SAN 管理ツールを使用してアクセスすることはできません。従来のツールで監視できるのは VMware ESXi オペレーティング システムのみです。仮想マシンを監視するには、vSphere Client を使用します。
  • SAN 管理ツールで参照できる HBA は、仮想マシンの一部ではなく、ESXi システムの一部です。
  • 通常、ESXi システムは、マルチパス機能を実行します。

LUN の決定

VMFS データストアを使用して LUN をフォーマットする場合は、まず ESXi システムのストレージのセットアップ方法を検討する必要があります。

LUN を検討する際は、次の点を考慮してください。

  • 各 LUN には、その LUN を使用する仮想マシンで実行されるアプリケーションに適した RAID レベルとストレージ特性が必要です。
  • 各 LUN に含めることができる VMFS データストアは 1 つだけです。
  • 複数の仮想マシンが同じ VMFS にアクセスする場合、ディスク シェアを使用して仮想マシンに優先順位を付けます。

少数の大きな LUN を設定すると、次のようなメリットがあります。

  • 仮想マシンをより柔軟に作成でき、ストレージ管理者にディスク領域の拡張を依頼する必要がありません。
  • 仮想ディスクのサイズ変更、スナップショットの操作などをより柔軟に実行できます。
  • 管理する VMFS データストアの数が少なくなります。

多数の小さな LUN を設定すると、次のようなメリットがあります。

  • 無駄になるストレージ領域が減ります。
  • アプリケーションが異なると、必要な RAID 特性が異なる場合があります。
  • マルチパス ポリシーやディスク共有を LUN ごとに設定すると、より柔軟性が高くなります。
  • Microsoft Cluster Service を使用する場合、各クラスタ ディスク リソースが専用 LUN に存在する必要があります。
  • 1 つのボリュームに対する競合が緩和されるのでパフォーマンスが向上します。

仮想マシンのストレージ特性がわからないと、プロビジョニングする LUN の数とサイズを決めるのが難しい場合もあります。予測型スキームや適合型スキームで試行できます。

予測型スキームを使用した LUN の決定

予測型スキームを使用して試行できます。

手順

  1. ストレージ特性が異なる複数の LUN をプロビジョニングします。
  2. 各 LUN に VMFS データストアを作成し、各データストアに、その特性に応じてラベルを付けます。
  3. 仮想マシン アプリケーションのデータを、アプリケーションの要件に合わせた適切な RAID レベルで LUN 上の VMFS データストアに格納できるよう、仮想ディスクを作成します。
  4. ディスク シェアを使用して、優先順位の高い仮想マシンと優先順位の低い仮想マシンを区別します。
    注： ディスク シェアは、指定されたホスト内でのみ有効です。あるホストの仮想マシンに割り当てられたシェアは、別のホストの仮想マシンでは無効です。
  5. アプリケーションを実行し、仮想マシンのパフォーマンスが許容できる状態かどうかを判断します。

適合型スキームを使用した LUN の決定

適合型スキームを使用して試行できます。

手順

  1. 書き込みキャッシュを有効にして、大きな LUN （RAID 1+0 または RAID 5） をプロビジョニングします。
  2. その LUN に VMFS を作成します。
  3. その VMFS 上に 4 ～ 5 の仮想ディスクを作成します。
  4. アプリケーションを実行し、ディスク パフォーマンスが許容できる状態かどうかを判断します。

結果

パフォーマンスが許容可能な場合、VMFS に追加の仮想ディスクを配置できます。パフォーマンスが条件にあっていない場合は、新しく大きな LUN を作成 （おそらく別の RAID レベルで） し、このプロセスを繰り返します。移行を実行し、LUN を再作成しても仮想マシンのデータが失われないようにします。

仮想マシンの場所の選択

仮想マシンのパフォーマンスを最適化する場合、ストレージの場所が重要な要因になります。ストレージの要件に応じて、高いパフォーマンスと高可用性を提供するストレージを選択する場合や、パフォーマンスが低いストレージを選択する場合があります。

いくつかの要因に応じて、ストレージは異なる階層に分けることができます。

  • ハイ ティア：高いパフォーマンスと高い可用性を提供します。バックアップとポイント イン タイム （PiT） リストアが容易になる組み込み型スナップショットを備えていることがあります。レプリケーション、完全なストレージ プロセッサの冗長性、および SAS ドライブをサポートします。高価なスピンドルを使用しています。
  • ミッド ティア：ミッドレンジのパフォーマンス、やや低い可用性、一部のストレージ プロセッサの冗長性、および SCSI ドライブまたは SAS ドライブを備えています。スナップショットを提供することもあります。中位の価格のスピンドルを使用しています。
  • ロー ティア：パフォーマンスは低く、内部ストレージの冗長性はほとんどありません。下位の SCSI ドライブまたは SATA を使用します。

すべての仮想マシンがライフ サイクル全体で最高のパフォーマンスと可用性を備えたストレージに配置される必要があるわけではありません。

仮想マシンを配置する場所を決定するときは、次の考慮事項が適用されます。

  • 仮想マシンの重要度
  • パフォーマンスと可用性の要件
  • PiT リストア要件
  • バックアップおよびレプリケーションの要件

仮想マシンは、重要度またはテクノロジーの変更のために、ライフ サイクルを通じて階層が変わることがあります。重要度は相対的で、組織、運用プロセス、規制条件、災害計画などの変更を含め、さまざまな理由で変わることがあります。

サードパーティ製の管理アプリケーション

サードパーティ製の管理アプリケーションを ESXi ホストと一緒に使用できます。

ほとんどの SAN ハードウェアには、ストレージ管理ソフトウェアが付属しています。多くの場合、このソフトウェアは Web アプリケーションで、ネットワークに接続された Web ブラウザから利用できます。その他の場合では、このソフトウェアは通常、ストレージ システムまたは単一サーバで実行されます。 サーバが SAN をストレージとして使用しているかどうかは関係ありません。

このサードパーティ製の管理ソフトウェアを使用すると、次のタスクが実行できます。

  • ストレージ アレイの管理 （LUN の作成、アレイ キャッシュの管理、LUN のマッピング、LUN のセキュリティなど）
  • レプリケーション、チェック ポイント、スナップショット、ミラーリングの設定

仮想マシンで SAN 管理ソフトウェアを実行する場合、vMotion や VMware HA を使用したフェイルオーバーなど、仮想マシンのメリットが得られます。ただし、より間接的になるため、管理ソフトウェアで SAN を検出できないことがあります。この場合は RDM を使用できます。

注： 仮想マシンで管理ソフトウェアを正常に実行できるかどうかは、ストレージ アレイに依存します。

SAN ストレージ バックアップに関する考慮事項

適切なバックアップ戦略をとることは、SAN 管理にとって最重要事です。SAN 環境では、バックアップの目的は 2 つあります。最初の目的は、オンライン データをオフライン メディアにアーカイブすることです。このプロセスは、すべてのオンライン データに対して、定期的にスケジュールに従って繰り返されます。もう 1 つの目的は、問題からリカバリするために、オフラインデータへのアクセスを提供することです。たとえば、データベースのリカバリでは、現在オンラインではないアーカイブされたログ ファイルの取得がしばしば必要となります。

バックアップのスケジュール設定は、いくつかの要因によって異なります。

  • 一定の期間内に、より頻繁なバックアップ サイクルを必要とする重要なアプリケーションの特定。
  • リカバリ ポイントとリカバリ時間の目標。必要なリカバリ ポイントの正確さと、リカバリを待つことができる時間の長さについて考えます。
  • データに関連付けられた変更率 （RoC）。たとえば、同期/非同期レプリケーションを使用している場合、RoC が、プライマリ ストレージ デバイスとセカンダリ ストレージ デバイスの間で必要なバンド幅の量に影響を与えます。
  • SAN 環境、ストレージ パフォーマンス、およびその他のアプリケーションに対する全体的な影響。
  • SAN のピーク トラフィック時間の特定（ピーク時間にスケジュールされたバックアップは、アプリケーションおよびバックアップ プロセスの速度を低下させることがあります）。
  • データセンター内のすべてのバックアップをスケジュールする時間。
  • 個別のアプリケーションをバックアップするために必要な時間。
  • データをアーカイブするためのリソース可用性（オフライン メディア アクセスなど）。

バックアップ計画を立てるときには、アプリケーションごとのリカバリ時間の目標を含めます。つまり、バックアップを実行するために必要な時間とリソースについて考慮します。たとえば、スケジュール設定したバックアップで大量のデータが保管されるためにリカバリに長時間かかる場合は、バックアップ スケジュールを検討してみてください。バックアップの実行回数を増やすと、1 回にバックアップされるデータの量が少なくなり、リカバリ時間が短縮されます。

アプリケーションを特定の時間枠でリカバリする必要がある場合は、この要件を満たすために、バックアップ プロセスでタイム スケジュールと特別なデータ処理を指定する必要があります。高速リカバリでは、オンライン ストレージにあるリカバリ ボリュームの使用を必須とすることができます。このプロセスにより、失われたデータ コンポーネントのために低速なオフライン メディアにアクセスする必要性を低減または排除できます。

サードパーティ製のバックアップ パッケージの使用

サードパーティ製のバックアップ ソリューションを使用して、仮想マシンのシステム、アプリケーション、ユーザー データを保護します。

VMware が提供する Storage APIs - Data Protection は、サード パーティの製品と連携させることができます。API を使用するとき、サードパーティのソフトウェアはバックアップ タスクの処理で ESXi ホストをロードすることなく、バックアップを実行できます。

Storage APIs - Data Protection を使用するサードパーティの製品は、次のバックアップ タスクを実行できます。
  • 仮想マシンのフル、差分および増分イメージ バックアップおよびリストアを実行します。
  • サポートされる Windows および Linux オペレーティング システムを使用する仮想マシンのファイル レベルのバックアップを実行します。
  • サポートされる Microsoft Windows オペレーティング システムを実行する仮想マシンのために Microsoft Volume Shadow Copy Services (VSS) を使用することによって、データの整合性を確保します。

Storage APIs - Data Protection は、VMFS のスナップショット機能を使用するため、バックアップで仮想マシンを停止する必要はありません。これらのバックアップは無停止であり、いつでも実行可能であるため、バックアップ時間枠を拡大する必要はありません。

Storage APIs - Data Protection とバックアップ製品との連携の詳細については、VMware ナレッジベースの記事 (KB1021175) を参照してください。