ストレージは OpenStack スタックの多くの部分に存在し、これらのタイプの違いにより経験豊富なクラウド技術者でさえ混乱する事があります。本章では、あなたのクラウドで設定可能な永続的ストレージに焦点を当てます。
エフェメラルストレージ | ブロックストレージ | オブジェクトストレージ | |
---|---|---|---|
使用目的 |
OS を起動し、空き領域に記録する |
永続的なストレージを仮想マシン(VM)へ追加する |
データを保存する(VMイメージも含む) |
アクセス方法 |
ファイルシステム |
パーティション作成、フォーマット、マウントされたblock device(/dev/vdc など) |
REST API |
アクセス可能な場所 |
VM内 |
VM内 |
どこからでも |
管理元 |
OpenStack Compute (Nova) |
OpenStack Block Storage (Cinder) |
OpenStack Object Storage (Swift) |
データの残存期間 |
VM終了まで |
ユーザーが削除するまで |
ユーザーが削除するまで |
容量の指定 |
管理者がサイズ設定(フレーバーとも呼ばれる)を用意する |
ユーザが指定する |
利用可能な物理ディスクの総量で決まる |
典型的な利用例 |
10GBの1台目ディスク、30GBの2台目ディスク |
1TBディスク |
数十TBのデータセットストレージ |
Novaのみを構成した場合、デフォルトではユーザにはあらゆる種類の永続ストレージへのアクセス方法がありません。この状態でVMに割り当てられるディスクは「エフェメラル」であり、これは仮想マシンが削除された時にディスクが削除される事を意味します。そのためユーザに対してどんなタイプの永続的ストレージがサポートされているか明示しておく必要があります。
現在、OpenStackでは二つの永続的ストレージ(object storage と block storage)がサポートされています。
オブジェクトストレージでは、ユーザはREST APIを経由してバイナリオブジェクトへアクセスします。有名なオブジェクトストレージにAmazon S3があります。ユーザがアーカイブ領域や大容量のデータセットを必要としたときにオブジェクトストレージは有効です。またOpenStackはファイルシステムの代わりにオブジェクトストレージに仮想マシンイメージを保存する事が可能です。
ブロックストレージ(ボリュームストレージとも呼ばれる)はユーザにブロックデバイスを提供します。ユーザは実行中のVMにボリュームをアタッチして、ブロックストレージを利用します。
このボリュームは永続的です。データを残したまま仮想マシンからデタッチし、別の仮想マシンへ再アタッチすることができます。OpenStack では、ブロックストレージは OpenStack Block Storage (Cinder)で実装されており、複数のバックエンドストレージをドライバという形式でサポートします。あなたが選択するストレージバックエンドは、Block Storage のドライバによりサポートされている必要があります。
多くのストレージドライバはインスタンスが直接ストレージハードウェアのブロックデバイスへアクセスできるようにします。これは リード/ライト I/O 性能の向上に役立ちます。
Folsomリリースではファイルをボリュームとして利用するための実験的サポートを開始しました。これは、最初は Cinder で NFS を使用するためのリファレンスドライバとしてスタートしたものです。Grizzly リリースまでに、このドライバはGlusterFS ドライバと同様、完全な NFS ドライバに拡張されました。
これらのドライバーは従来のブロックストレージドライバとは少々異なる動作をします。NFSやGlusterFSでは1つのファイルが作成され、インスタンスに対して「仮想」ボリュームとしてマッピングされます。このマッピング/変換は/var/lib/nova/instances
下に保存される、QEMUのファイルベースの仮想マシンの、OpenStackによる扱い方と同様です。
ファイルレベルストレージでは、ユーザはOSのファイルシステムインターフェースを使ってデータへアクセスします。ほとんどのユーザは(以前ネットワークソリューションを使用した経験があった場合)この種類のネットワークストレージに遭遇したことがあります。UnixではNFSが一般的で、WindowsではCIFS(旧 SMB)が一般的です。
OpenStackではエンドユーザがファイルレベルストレージを目にすることはありません。しかし、クラウド設計時、/var/lib/nova/instances
下のインスタンス保存用にファイルレベルストレージを検討する事は重要です。なぜなら、ライブマイグレーションをサポートしたい場合、共有ファイルシステムが必須だからです。
storage back-end 選択における一般的な考慮事項:
ユーザがブロックストレージを必要とするか?
ユーザがオブジェクトストレージを必要とするか?
管理者がライブマイグレーションを必要とするか?
永続的ストレージをコンピュートノード内に持つべきか?それとも外部ストレージに持つべきか?
実現可能な容量は?ネットワークアクセスでも、より多くのディスクがより良い I/O 性能に繋がるか?
どちらが自分の意図した最高のコストパフォーマンスシナリオを実現するか?
ストレージの運用管理をどうするか?
ストレージの冗長性と分散をどうするか?ストレージノード障害でどうなるか?災害時、自分のデータ消失をどの程度軽減できるのか?
コモディティハードウェアを利用したストレージ環境の構築に、下記に表に示したいくつかのオープンソースパッケージを利用可能です。
オブジェクトストレージ | ブロックストレージ | ファイルレベルストレージ* (ライブマイグレーションサポート) | |
---|---|---|---|
Swift |
|||
LVM |
|||
Ceph |
実験的 |
||
Gluster |
|||
NFS |
|||
ZFS |
|||
Sheepdog |
実験的 |
* このOSS ファイルレベル共有ストレージのリストは完全ではなく、他にもOSSが存在します(MooseFS)。あなたの組織では既に利用可能なファイルレベル共有ストレージがあるかもしれません。
OSSに加えて、OpenStack Block Storageではいくつかのプロプライエタリなストレージを公式にサポートしています。それらは以下のベンダーによって提供されています。
IBM (Storwize family/SVC, XIV)
NetApp
Nexenta
SolidFire
こちらのリンクからドライバごとにサポートされている機能マトリックスを参照できます。 OpenStack wiki (https://wiki.openstack.org/wiki/CinderSupportMatrix)
クラウド内でオブジェクトストレージの利用を検討する必要があります。コンピュートクラウドで提供されるオブジェクトストレージの一般的な利用方法は以下の二つです。
ユーザに永続的ストレージの仕組みを提供する
スケーラブルで信頼性のある仮想マシンイメージデータストアとして利用する
このセクションでは様々な コモディティハードウェアを利用するストレージ技術の差異について、上位レベルの概要を提供します。
OpenStack Object Storage (Swift)。OpenStack公式のオブジェクトストア実装です。これはRackspace Cloud Files で採用されており、既に数年間の商用実績を持つ成熟した技術です。高度なスケーラビリティを備え、ペタバイトストレージの管理に適しています。OpenStack Object Storageの利点はOpenStackとの統合(OpenStack Identityとの統合、OpenStack Dashboardインターフェースでの操作)と、非同期の結果整合性レプリケーションによる複数データセンターのサポートです。
従って、将来的に複数データセンターにまたがった分散ストレージクラスタを計画する場合や、コンピュートとオブジェクトストレージ間で統一されたアカウントを必要とする場合、または OpenStack Dashboard を使ってオブジェクトストレージを操作したい場合などに OpenStack Object Storage を検討します。OpenStack Object Storage のより詳細な情報は以後のセクションで記載します。
Ceph。コモディティなストレージノード間でデータレプリケーションを行う、スケーラブルなストレージソリューションです。Ceph は元々DreamHost の創設者の一人が開発し、現在はDreamHost の商用サービスで利用されています。
Ceph はエンドユーザに対して異なるストレージインターフェースが利用できるよう設計されています: オブジェクトストレージ、ブロックストレージ、ファイルシステムをサポートしていますが、ファイルシステムはまだ商用利用可能な状態ではありません。CephはオブジェクトストレージでSwiftと同じAPIをサポートし、Cinder ブロックストレージのバックエンドとしても利用でき、Glance用イメージのバックエンドストレージとしても利用できます。Cephはcopy-on-wirteを使って実装されたシンプロビジョニングをサポートしています。
ボリューム作成が非常に高速なため、boot-from-volume に有効です。またCephはKeystoneベースの認証(version 0.56等)をサポートするため、デフォルトのOpenStack Swift との置き換えをシームレスに行えます。
Cephのメリットは、管理者がデータの分散とレプリケーションを細かく計画する事ができること、ブロックストレージとオブジェクトストレージを統合できること、シンプロビジョニングを使ってインスタンスのboot-from-volumeを高速で行えること、 商用利用にはまだ推奨されていませんが (http://ceph.com/docs/master/faq/) 分散ファイルシステムのインターフェースを利用できることです。
単一システムでブロックストレージとオブジェクトストレージを管理したい場合や、高速なboot-from-volumeをサポートしたい場合はCephの利用を検討してください。
Gluster 分散共有ファイルシステムです。Gluster 3.3の時点で、オブジェクトストレージとファイルストレージを統合して利用でき、これはGluster UFOと呼ばれています。Gluster UFOは、Glusterをバックエンドとして使うようにカスタマイズされたSwiftを利用しています。
正規のSwift経由でGluster UFOを使う利点は、分散ファイルシステムをサポートしたい時や、共有ストレージによるライブマイグレーションのサポートや、個別サービスとしてエンドユーザにGluster UFOを提供できる事です。単一ストレージシステムでオブジェクトストレージとファイルストレージを管理したい場合はGluster UFOを検討します。
LVM 論理ボリュームマネージャ。オペレーティングシステムへ論理ディスクを公開するために、物理ディスク上の抽象化レイヤーを提供するLinuxベースの仕組みです。LVM(論理ボリュームマネージャ)のバックエンドは、LVM論理パーティションとしてブロックストレージを提供します。
ブロックストレージを収容する各ホストでは、管理者は事前にブロックストレージ専用のボリュームグループを作成しておく必要があります。ブロックストレージはLVM論理ボリュームから作られます。
注記 LVMはレプリケーションを提供しません。通常、管理者はブロックストレージとしてLVMを利用するホスト上にRAIDを構成し、ここのハードディスク障害からブロックストレージを保護します。しかしRAIDではホストそのものの障害には対応できません。
Solarisの OpenStack Block Storage用のiSCSIドライバーはZFSを実態としたブロックストレージを実装しています。ZFSはボリュームマネージャ機能を持ったファイルシステムです。これはボリュームマネージャ(LVM)とファイルシステム(ext3, ext4, xfs, btrfsのような)が分離しているLinuxとは異なっています。ZFSはデータ整合性チェックを含み、ext4より多くの利点を持っています。
OpenStack Block Storage用のZFSバックエンドは Illumos 等のSolaris ベースのシステムのみをサポートします。LinuxにポーティングされたZFSもありますが、標準的なLinuxディストリビューションには含まれておらず、OpenStack Block Storage でもテストされていません。LVMと同様にZFSはホスト間のレプリケーション機能を提供していませんので、ストレージノードの障害に対応するためには、ZFS上にレプリケーション機能を追加する必要があります。
ここではLinuxベースのシステムを前提としているので、これまでにZFSの構築実績が無ければ、Solarisの知識を前提とするZFSはあえてお薦めしません。
Sheepdog KVMのインスタンスにブロックストレージを提供する事に特化した新しいプロジェクトで、ホスト間のレプリケーションもサポートします。ただし、作者であるNTT研究所では、Sheepdogは実験的な技術と考えており、商用クラウドサービスでの利用はお薦めしません。
OpenStack Object Storage は従来のファイルシステムの制約を一部緩和することで、高いスケーラビリティと可用性を実現しています。その設計のためには、動作のキーコンセプトを理解することが重要です。このタイプのストレージはあらゆる場所・レベルにおいてハードウェア障害が発生する、という考えに基づいて構築されています。他のストレージシステムでは動作不能になってしまうような、まれに発生するRAIDカードやホスト全体の障害に対しても OpenStack Object Storage は正常に動作します。
オブジェクトストレージのアーキテクチャについて the developer documentation (http://docs.openstack.org/developer/swift/overview_architecture.html) に記述されています。まずアーキテクチャを理解し、プロキシサーバーとZoneがどのように働くか知る必要があります。重要なポイント見逃さないように注意してください。
クラスタの設計には耐久性と可用性を検討する必要があります。耐久性と可用性はハードウェアの信頼性ではなく、データの分布と配置が重要です。デフォルトのレプリカ数3について考えます。これはオブジェクトが書き込まれた時に少なくとも2つのコピーが存在する事を意味します。1台のサーバーへの書き込みが失敗した場合、3つ目のコピーは書き込み操作が返った直後には存在するかもしれないし、存在しないかもしれません。レプリカ数を増やすとデータの堅牢性は増しますが、利用できるストレージの総量は減ってしまいます。次にサーバーの配置を見てみます。データセンター全体でネットワークや電源の障害箇所とサーバーの分布を考えてください。その障害ではラック、サーバー、ディスクのどこが影響を受けますか?
オブジェクトストレージのネットワークのトラフィックは通常とは異なっているかもしれません。以下のトラフィックを考慮してください。
object/container/account server と proxy server の間
proxy server と 利用者の間
オブジェクトストレージはデータを保持するノード間で頻繁に通信を行います。 小さなクラスタでさえ、これは数MB/sのトラフィックで主に他ホストにオブジェクトの存在確認を行いっています。相手ノードにオブジェクトが無い場合はレプリケーションが開始されます。
サーバー障害で3つのコピーを保つために、24TBのデータ転送が必要になる場合を考えてみてください。これはネットワークに大きな負荷を発生させます。
忘れてはいけない事として、レプリカがあるためファイルがアップロードされたときに、proxy server は多くのストリームを書き出す必要があることです。これは3レプリカの場合、10Gbpsのアップロードに対して、30Gbpsのダウンロードになります。これはパブリック側のネットワークよりも、プライベート側のネットワークがより多くの帯域を必要とすることを意味しています。OpenStack Object Storage はパフォーマンスのために非暗号化、未認証のrsync通信を行います。そのためプライベートネットワークは非公開である必要があります。
残りのポイントはパブリック側のネットワーク帯域になります。swift-proxyはステートレスなため、ノードを追加し、HTTPロードバランスを使うことで帯域の増加と可用性の向上を容易に行うことができます。
ストレージ側の性能が十分であれば、proxy server の増加は帯域の増加になります。