Tweet

EBSボリュームは従来のストレージアレイのLUNとは異なり、実際のボリュームではなく論理ディスクであるため、「EBSボリューム」という用語は少々混乱の基になることがありますが、ディスクであるため、EBSボリューム使用して複数のEBSボリュームにまたがる複合ボリュームを作成することも可能です。

従来の環境ではディスクアレイを使用する主な理由の一つがハードウェア障害に対処できる冗長性（RAID）を作成することです。EBSボリュームの場合、どの物理ディスクにどのEBSボリュームが存在するか実際に把握することはできないため、ディスクアレイと同様に冗長性を得ることはできません。同じ物理ハードウェア上にEBSボリュームが存在する場合もあり、このような場合にはハードウェア障害発生時にRAID構成は意味を成しません。また、EBSボリュームが正確には、どのような実装されているかはわかりませんが、おそらく、単一の物理ディスクの障害からデータを保護するための冗長構成は既に行われています。

なぜEC2でディスクアレイを使用するのか

それでは、なぜEC2でディスクアレイを作成するのか、その理由は主に以下の2つです。

• EBSボリュームのサイズ上限に対応するため

  現在は最大16TBであるため、あまりこれが理由になることはありませんが、以前は1TBまでという制限があったため、複数のEBSボリュームから大容量のディスクアレイを作成することがありました。

• パフォーマンス向上のため

  複数EBSボリュームをストライプで使用することで、パフォーマンス（読み書き性能）を向上させることができます。これにより、非常に高いI/Oスループットを要求するクリティカルなアプリケーションにも対応できます。

なぜパフォーマンスが向上するのか？ストレージスタックについて

ストレージスタックは、階層構造であり、各階層は他の階層に実装に関しては認識せずとも動作します。以下がストレージスタックの簡単な図です。

これにより、アプリケーションはファイルを開き、書き込むことができますが、そのファイルをファイルシステムがボリューム上でどのように扱っているかを考慮しません。ファイルシステムがどのような書き込みサイズを使用しているか不明なため、アプリケーションが最小限の書き込みを行う場合でも、ファイルシステムは自身のブロックサイズで書き込みリクエストを行います。そのため、例えば10バイトの文字列をアプリケーションが書き込んだ際に、ファイルシステムは4KBのデータを書き込み、さらにボリュームが64KBのブロックサイズを使用するなどということがあります。また、ボリュームは、その下の階層のディスクが物理ディスクであるかネットワークを介して接続されたものであるかを認識しません。

このようなストレージスタックで動作する際に、ボリュームが複数のディスクにまたがり構成されている場合、ファイルシステムが書き込み操作を行うと、ボリュームマネージャはその書き込みを複数のディスクに分割して行うことができます。これはEBSボリュームの場合も同様で、単一のアプリケーションからの書き込操作を複数のEBSボリュームへの書き込みとして分散して行うことができます。

バックアップの課題

このようなディスクアレイのバックアップを行う際に、ファイルレベルのバックアップソリューションであればディスクアレイやボリュームマネージャ影響は受けません。他のアプリケーションと同様にファイルシステムに対してリクエストを行うためです。ただ、ファイルレベルよりもブロックレベルのバックアップソリューションの方が、より効率的に、高速にバックアップとリカバリを行えます。しかし、ディスクアレイをブロックレベルのソリューションでバックアップする場合は、ファイルレベルとは状況が異なります。

いかに、EBSスナップショットを使用して複数のEBSボリュームにまたがるディスクアレイの整合性を保ってバックアップするかという課題に直面するのです。ディスクアレイのバックアップで一貫性を保証するには、完全に一致したタイミングでEBSボリュームのスナップショットを作成する必要があります。しかし、AWS APIはこの機能を提供しておらず、複数のEBSボリュームで同一時点のスナップショットを作成することはできません。AWS APIのみでとれる方法としてはできるだけ、短い間隔で各EBSボリュームのスナップショットを作成することですが、これでは問題が発生する可能性があります。

例えば、アプリケーションが書き込み操作の途中である場合、その操作は複数のEBSボリュームにまたがって行われている可能性があります。また、既に1つのEBSボリュームで、書き込み操作は完了しているが、別のボリュームでは操作途中、されに別のボリュームでは操作自体が開始されていない可能性すらあります。このような異なる時点のEBSボリュームのスナップショットから組み立てられたボリュームは破損状態となります。

ではどのように、この課題を解決するのか、それはパート2でご紹介いたします。

関連トピックス:

• AWS EC2のディスクアレイ（LVMやダイナミックディスク）をバックアップ　パート2：一貫性問題
• AWS EC2のディスクアレイ（LVMやダイナミックディスク）をバックアップ　パート3：EBSボリュームで構成されたLVM
• VMwareのスナップショット作成・削除処理の仕組み
• 【VMware】スナップショット・ファイルのロケーション変更方法
• VMware vSphere Storage vMotionで適切なフォーマットはシックか、シンのどちらか？
• XFSファイルシステムとEBSスナップショットによる一貫性のあるバックアップ (AWS)
• Data Recoveryインストール【仮想化プラットホーム VMware vSphere】
• ストレージスナップショットは従来のバックアップの代わりになるのか？