OpenStack について学ぶ: ストレージ関連コンポーネントの Swift と Cinder

この記事では、OpenStack のブロック・ストレージ (Swift) プロジェクトとオブジェクト・ストレージ (Glance) プロジェクトを紹介し、OpenStack のアーキテクチャー全体の中でこの 2つのプロジェクトがどのような位置を占めており、どのような機能を実現するのかを説明します。また、これらのコンポーネントをインストール、構成、使用する上での要件についても説明します。

John Rhoton, Cloud Computing Strategist, Recursive

Author photoJohn Rhoton は、パブリック・クラウド、プライベート・クラウド、ハイブリッド・クラウド・コンピューティングに焦点を絞り、世界の企業を顧客としたコンサルティングを専門とする技術ストラテジストです。彼はさまざまな業界イベントで、モバイル、ソーシャル・ネットワーキング、仮想化などの新興技術に関する講演を頻繁に行っており、また『Cloud Computing Explained』(2009年)、『Cloud Computing Architected』(2011年) など、6 冊の著作があります。



2014年 2月 06日

この記事で取り上げるのは、他の OpenStack プロジェクトに永続ストレージを提供する OpenStack Storage です。

コンピューテーションを行うワークロードでは、(OpenStack Compute に関する記事で述べたように) 中心となるのはコンピューテーションであるため、コンピューテーションを行うインスタンスのみがあればよい場合もありますが、多くの場合はインスタンスの存続期間にわたって維持される耐久性のあるストレージが必要になります。あるいは、実行中のサービスの間で大量のデータを共有しなければならないこともあります。

実際に、OpenStack 環境の外部で実行されるアプリケーションが、スケーラブルで信頼性が高い、複製されたストレージを利用する場合があるかもしれません。OpenStack Storage は、こうしたストレージの仕様を満たしますが、その選択肢について評価する前に、OpenStack とその他多くのクラウド・サービスには、根本的に異なる 2 つのストレージ・サービスがあることを理解しておく必要があります。

  • OpenStack Swift は、Amazon Simple Storage Service と概念が似通ったオブジェクト・ストレージの一例です。
  • 対照的に、OpenStack Cinder は、Amazon Elastic Block Store と似通ったブロック・ストレージの一例です。

ブロック・ストレージ (Cinder)

Cinder とは、ゲスト VM (仮想マシン) に永続的なブロック・ストレージを提供する OpenStack Block Storage のプロジェクト名です。ブロック・ストレージは、ブロック・レベルのロー・ストレージにアクセスしなければならないアプリケーションで必要とされますが、拡張可能なファイルシステムや、最大限のパフォーマンスの実現、エンタープライズ・ストレージ・サービスとの統合などにも必要になることがよくあります。

このシステムは、デバイスを公開および接続した後に、ブロック・ストレージの作成や、サーバーに対する接続および接続解除を管理することができます。また API (アプリケーション・プログラミング・インターフェース) により、ブロック・ストレージのボリュームのバックアップを実現するスナップショットの管理も簡単に行うことができます。


オブジェクト・ストア (Swift)

Swift と Cinder のどちらをどのような場合に使用するべきか?

Swift と Cinder のどちらを使用するべきかと言うと、その答えはアプリケーション次第です。商用アプリケーションまたはレガシー・アプリケーションを実行する必要があるとしたら、選択の余地はほぼありません。そのようなアプリケーションの場合、コードが Swift API を利用するように作成されている見込みはほとんどありませんが、ほとんどのアプリケーションに直接接続されたストレージのように動作する Cinder ディスクであれば、簡単にマウントすることができます。

もちろん、新しいアプリケーションに Cinder を使用することもできますが、その場合、自動的にレジリエンシーと冗長性が実現される Swift のメリットは得られません。プログラマーが難題に取り組む意欲を持っているようであれば、Swift のスケーラブルな分散アーキテクチャーを検討する価値は間違いなくあります。

Swift は、OpenStack が初めてリリースされたときからコア・プロジェクトとなっており、もう一方のオファリングである Cinder よりも成熟しています。API でアクセス可能な分散型ストレージ・プラットフォームとして機能する Swift は、アプリケーションに直接統合することも、VMイメージ、バックアップ、アーカイブ、そして比較的小さいファイル (写真や e-メール・メッセージなど) を保管するために使用することもできます。

オブジェクト・ストアには、オブジェクトとコンテナーという 2 つの主要概念があります。

オブジェクトは、主要なストレージ・エンティティーです。オブジェクトには、格納すべき中心となる内容の他に、OpenStack Object Storage システムに保管されるファイルに関連付けられた、オプションのメタデータを格納することができます。これらのデータは圧縮も暗号化もされないフォーマットで保存され、オブジェクトの名前、コンテナー、メタデータがキーと値のペアという形で含まれます。オブジェクトは、データ・センター全体で複数のディスクに分散されます。このように分散することで、Swift はデータの複製と完全性を確実にします。分散処理では、一般商品化された安価なハードウェアを利用できると同時に、スケーラビリティー、冗長性、耐久性が強化されます。

コンテナーは、ファイル一式を格納するストレージの区画であるという点で、Windows のフォルダーと似ています。コンテナーをネストすることはできませんが、テナントが作成できるコンテナーの数に制限はありません。オブジェクトはコンテナーに保管されなければならないため、オブジェクト・ストアを使用するには、少なくとも 1 つのコンテナーが必要です。

従来のファイル・サーバーとは異なり、Swift は複数のシステムに分散されます。Swift は、可用性とスケーラビリティーを最大限にするために、自動的に各オブジェクトの冗長コピーを保管します。また、オブジェクトをバージョン管理することによって、不慮のデータ損失やデータの上書きに対する保護をさらに強化します。


Swift のアーキテクチャー

Swift のアーキテクチャーを構成するコンポーネントには、サーバー、プロセス、リングの 3 つがあります。

サーバー

Swift のアーキテクチャーは、単一障害点を防止するため、さらには水平スケーリングを可能にするという目的で分散されています。このアーキテクチャーには以下の 4 つのサーバーが含まれています。

  • プロキシー・サーバー
  • オブジェクト・サーバー
  • コンテナー・サーバー
  • アカウント・サーバー

プロキシー・サーバーは、OpenStack Object Storage アーキテクチャーの他の要素に対し、統一インターフェースを提供します。このサーバーは、コンテナー作成、ファイル・アップロード、メタデータ変更のリクエストを受け入れ、コンテナーのリストを提供したり、保管されているファイルを提供したりすることもできます。そしてリクエストを受け取ると、リング内でのアカウント、コンテナー、またはオブジェクトの位置を判別して、そのリクエストを該当するサーバーに転送します。

オブジェクト・サーバーは、管理対象のデバイスに保管するオブジェクト (通常はファイル) のアップロードや、それらのデバイスに保管されているオブジェクトの変更、取得を行える単純なサーバーです。オブジェクトは、あらゆるメタデータを保持するための拡張属性を使用して、ローカル・ファイルシステムに保管されます。オブジェクトには、オブジェクト名のハッシュとタイムスタンプに基づいたパスが指定されます。

コンテナー・サーバーは、基本的にはオブジェクトのディレクトリーであり、特定のコンテナーへのオブジェクトの割り当て処理を行い、リクエストに応じてコンテナーのリストを提供します。コンテナーのリストがクラスター全体で複製されることで、冗長性が実現されます。

SoftLayer を試してください!

セルフサービス IaaS SoftLayer インフラストラクチャーの試用

アカウント・サーバーは、オブジェクト・ストレージ・サービスを使用してアカウントを管理します。その動作は、リストを提供するという点で、コンテナー・サーバーと同様です。アカウント・サーバーの場合、リストには特定のアカウントに割り当てられているコンテナーが列挙されます。

プロセス

データ・ストアは、レプリケーション・サービス、オーディター、アップデーターなど、スケジューリングされた複数のハウスキーピング・プロセスによって管理されます。

最も重要なプロセスは、レプリケーション・サービスです。レプリケーション・サービスによって、クラスター全体での一貫性と可用性が確保されるためです。オブジェクト・ストアの主な魅力の 1 つは、これが分散ストレージであることなので、停電やコンポーネント障害などの一時的エラーが発生した場合でも、OpenStack は一貫した状態を維持しなければなりません。そのために OpenStack では、定期的にローカル・データをリモートにあるそのコピーと比較して、すべてのレプリカのデータが最新のバージョンであることを確実にします。

比較に必要となるネットワーク・トラフィック量を最小限にするために、レプリケーション・サービスは各パーティションのサブセクションのハッシュを作成して、ハッシュが含まれたリストを比較します。コンテナーおよびアカウントのレプリケーションでもハッシュを使用しますが、共有ハイウォーター・マークで補完します。実際の更新をプッシュするには、一般に rsync を使用して、オブジェクト、コンテナー、アカウントをコピーします。

オブジェクト、コンテナー、またはアカウントが削除される際に、整合性のあるデータ削除を行うために、レプリケーターはガーベッジ・コレクションも行います。これらの要素の削除時に、システムは最新バージョンにツームストーンでマークを付けます。これは、削除したのと同じアイテムをすべての複製ノードから削除するように指示する、レプリケーターへのシグナルとなります。

最善のレプリケーション設計であっても、その効果はそれを実装するコンポーネントによって限られたものになります。本番環境は、障害に対処できなければなりません。それは、障害の原因がハードウェアやソフトウェアの不具合にある場合でも、単に製品の容量不足にある場合でも同じことです。Swift では障害に対処するために、アップデーターとオーディターを使用します。

アップデーターは、障害時にシステムの整合性を確保する役目を果たします。レプリケーション・サービスで問題が発生してコンテナーやアカウントを更新できない場合、不整合が生じる期間が発生します。つまり、オブジェクトはストレージに存在していても、すべてのコンテナー・サーバーまたはアカウント・サーバーのリストに記載されているわけではない期間です。この場合、システムがローカル・ファイルシステムに対する更新をキューに入れて、アップデーター・プロセスがその更新を定期的に再試行します。

オーディターは、不整合に対する付加的レベルの保護を提供します。オーディターは定期的にローカル・リポジトリーをスキャンして、アカウント、コンテナー、およびオブジェクトの整合性を検証します。破損した要素が見つかると、その要素を隔離して、別のレプリカからのコピーで置き換えます。調整不可能な不整合 (例えば、どのコンテナーにも属していないオブジェクトなど) が見つかった場合は、エラーをログ・ファイルに記録します。

リング

ユーザーおよび他の OpenStack プロジェクトは、ストレージ・エンティティーをその論理名で参照しますが、読み取りリクエストであろうと書き込みリクエストであろうと、すべてのリクエストは、最終的に物理的な位置へとマッピングされなければなりません。そのためには、プロキシー・サーバーと、レプリケーション・サービスを含むバックグラウンド・プロセスには、論理名を物理的な位置へとマッピングする機能が必要です。このマッピングは、「リング」と呼ばれます。アカウント、コンテナー、オブジェクトには、それぞれ別個のリングが割り当てられます。リングはこのマッピングを、デバイス、パーティション、レプリカ、およびゾーンの観点から記述します。

このコンテキストでは、「パーティション」という用語は、リングに保管されている内容の論理サブセットを指します。パーティションに関しては、クラスターに含まれるデバイスごとに 100 個のパーティションを割り当てることが推奨されています。パーティションは、OpenStack Object Storage に割り当てられているすべてのデバイスの間で均等に分散されます。サイズが異なる複数のドライブを使用しているクラスターでは、デバイス間でのパーティションの分散を均一化するための重みを割り当てることも可能です。

デフォルトでは、各パーティションが 3 回複製されます。可用性を最大限にするために、回数をこれより増やすことも可能ですが、その場合は当然、ストレージの使用量も増えます。リングは、障害のシナリオで引き継ぎに使用するデバイスと、クラスターのデバイスが追加または削除されたときにパーティションを再分散する方法も指定します。

最後に説明するリング・マッピングの要素は、ゾーンです。ゾーンは、データのアフィニティーとアンチアフィニティーを実現するために使用されます。ゾーンは、ストレージ・デバイス、物理サーバー、または場所 (ラック、通路、データ・センターなど) を表すことがあります。ゾーンは論理概念であり、ユーザーはそれぞれの必要に応じてゾーンを使用できますが、ゾーンは場所、電源、ネットワーク接続などの物理要素を反映するのが通常です。


Cinder のアーキテクチャー

Cinder はオブジェクトの自動分散も自動レプリケーションも行わないため、そのアーキテクチャーは Swift よりもかなりシンプルです。図 1 に、Cinder のアーキテクチャーを示します。

図 1. Cinder のアーキテクチャー
Cinder のアーキテクチャーを示す図

他の OpenStack プロジェクトと同様に、Cinder の機能は、ダッシュボード (Dashboard) とコマンドライン (Command Line) の両方に API を介して公開されます。Cinder では、REST(Representational State Transfer)-ful な HTTP API を介してオブジェクト・ストアにアクセスし、「認証マネージャー (Auth Manager)」と呼ばれる Python クラスを使用して、認証を OpenStack Keystone に統合することができます。

この API は、受信したすべてのリクエストを構文解析してメッセージ・キュー (Message Queue) に転送します。メッセージ・キューでは、スケジューラー (scheduler) とボリューム (volume) サービスによって実際の処理が行われます。新しいボリュームが作成されると、スケジューラーがそのボリュームを担当するホストを決定します。デフォルトでは、スケジューラーは、使用可能な領域が最も多いノードを選択します。

ボリューム・マネージャーは、「ボリューム」と呼ばれる動的に接続可能なブロック・ストレージ・デバイス (block storage provider) を管理します。ブロック・ストレージ・デバイスは、仮想インスタンスのブート・デバイスとして使用することも、セカンダリー・ストレージとして接続することもできます。Cinder には、スナップショットのための機能も用意されています。スナップショットとは、ボリュームの読み取り専用のコピーであり、読み取り/書き込み用の新規ボリュームを作成するために、これらのスナップショットを使用することができます。

一般に、ボリュームは iSCSI を介してコンピュート・ノードに接続されます。ブロック・ストレージにも、何らかの形のバックエンド・ストレージが必要です (デフォルトのバックエンド・ストレージは、ローカル・ボリューム・グループでの論理ボリューム管理の形になっていますが、ドライバーを使用して外部ストレージ・アレイまたは外部ストレージ・アプライアンスに拡張することもできます)。


セットアップ

OpenStack のコンポーネントを実際にインストールする手順は、ディストリビューションによっても OpenStack のリリースによっても大きく異なります。通常、OpenStack のコンポーネントはディストリビューションの一部として提供されますが、これらのコンポーネントを使用するには、基本的な作業を完了しておかなければなりません。このセクションでは、必要となる作業の概要を説明します。

システム要件

OpenStack は 64 ビット x86 アーキテクチャーを利用します。それ以外の点では、一般商品化されたハードウェア用に設計されているため、最小システム要件は厳しいものではありません。8GB の RAM を搭載した単一システムがあれば、一連の OpenStack プロジェクトのすべてを実行することができます。ただし、ワークロードが大きい場合には、ストレージ専用のシステムを使用するのが妥当です。一般商品化された装置に重点が置かれているので、RAID (Redundant Array of Independent Disks) 機能は必要ありませんが、少なくともデュアル・クアッドコア CPU、8GB から 12GB の RAM、1GB ネットワーク・アダプターを使用するように推奨されています。当然のことながら、HDD (ハード・ディスク・ドライブ) または SSD (ソリッド・ステート・ドライブ) のサイズは、保管するデータの量と、必要とする冗長性レベルに依存します。

インストール

インストール手順はディストリビューションによって異なります。さらに具体的に言うと、どのパッケージ管理ユーティリティーを選択するかによって変わってきます。ほとんどの場合に共通で必要となるのは、リポジトリーの宣言です。例えば、Zypper の場合には、zypper ar を使用して libzypp を宣言します。

リスティングを見るにはここをクリック

# zypper ar -f http://download.opensuse.org/repositories/Cloud:/OpenStack:/Grizzly/SLE_11_SP3/Cloud:OpenStack:Grizzly.repo

次に、必要な Swift パッケージか Cinder パッケージ、あるいはその両方をインストールします。すべての依存関係は、パッケージ管理ユーティリティーによって自動的にインストールされるはずです。完全なインストール手順は、目的とする構成と OpenStack の当該リリースによって異なるため、正式な手順については、必ずインストール・ガイドを調べてください。例として、以下に Debian (例えば Ubuntu)、Red Hat (例えば Red Had Enterprise Linux、CentOS、Fedora)、および openSUSE の場合に使用する主要なコマンドを記載します。

  • Debian: 以下のコマンドを使用して、すべてのホストにベース Swift パッケージをインストールします。
    sudo apt-get install python-swift
    sudo apt-get install swift
    and the server-specific packages on the hosts that will be running them:
    sudo apt-get install swift-auth
    sudo apt-get install swift-proxy
    sudo apt-get install swift-account
    sudo apt-get install swift-container
    sudo apt-get install swift-object

    Cinder パッケージには、API、スケジューラー、ボリューム・マネージャーが含まれています。

    sudo apt-get install cinder-api
    sudo apt-get install cinder-scheduler
    sudo apt-get install cinder-volume
  • Red Hat: Red Hat システムでは、以下のコマンドを使用します。
    sudo yum install openstack-swift
    sudo yum install openstack-swift-proxy
    sudo yum install openstack-swift-account
    sudo yum install openstack-swift-container
    sudo yum install openstack-swift-object
    sudo yum install openstack-swift-doc
    sudo yum install openstack-cinder
    sudo yum install openstack-cinder-doc
  • openSUSE: openSUSE システムでは、以下のコマンドを使用します。
    sudo zypper install  openstack-swift
    sudo zypper install  openstack-swift-auth 
    sudo zypper install  openstack-swift-account 
    sudo zypper install  openstack-swift-container 
    sudo zypper install  openstack-swift-object 
    sudo zypper install  openstack-swift-proxy
    sudo zypper install openstack-cinder-api
    sudo zypper install openstack-cinder-scheduler
    sudo zypper install openstack-cinder-volume

構成

OpenStack Object Storage インストール済み環境を構成するには、4 つのパッケージのそれぞれに対して以下の構成ファイルを調整する作業が必要です。

  • account-server.conf
  • container-server.conf
  • object-server.conf
  • proxy-server.conf

これらの構成ファイルは、/etc/swift/ にインストールされています。標準的なインストールに対しては、デフォルトのオプション設定で十分ですが、特殊な要件がある場合には、構成を編集する必要があります。


使用シナリオ

OpenStack ストレージの使用法を把握するためのシナリオとして、あるサービスで、ファイルシステムと新規コードを使用してレガシー・ソフトウェアを実行するとします。新規コードでは、分散オブジェクト・ストレージを使用する予定です。このプロジェクトの環境には、Swift と Cinder の両方を含める必要があります。

まずは、Cinder から取り掛かります。

  1. メンバー・ロールが割り当てられたユーザーとして、OpenStack Dashboard にログインします。ナビゲーション・ペインで、「Manage Computer (コンピューターの管理)」の下に表示されている「Volumes (ボリューム)」 > 「Create Volume (ボリュームの作成)」を順にクリックします。
    図 2. ボリュームを作成する
    ボリュームの作成方法を示す画像
  2. 作成したボリュームが、プロジェクトのリストに表示されます。
    図 3. プロジェクトに含まれるボリューム
    プロジェクトのボリュームを示す画像

    クリックして大きなイメージを見る

    図 3. プロジェクトに含まれるボリューム

    プロジェクトのボリュームを示す画像
  3. 接続について編集することで、コンピュート・インスタンスのいずれかにボリュームを接続します。
    図 4. ボリューム接続を管理する
    接続について編集する方法を示す画像

OpenStack は、一意に決まる iSCSI 修飾名を作成し、iSCSI セッションがアクティブになっているコンピュート・ノードに、その名前を公開します。これで、インスタンスは Cinder ボリュームをローカル・ストレージであるかのように使用できます (通常は /dev/sdX ディスクです)。

プロジェクトで Swift を使用するには、最初にコンテナーを作成する必要があります。

  1. メンバー・ロールが割り当てられたユーザーとして、OpenStack Dashboard にログインします。ナビゲーション・ペインで、「Object Store (オブジェクト・ストア)」の下に表示されている「Containers (コンテナー)」 > 「Create Container (コンテナーの作成)」を順にクリックします。
    図 5. コンテナーを作成する
    コンテナーの作成方法を示す画像

    これは、データをまったく提供する必要がない単純な操作です。入力するのは単なる名前に過ぎません。

  2. コンテナーが用意されると、通常はアプリケーションがそこにオブジェクトを取り込み、プログラミング・インターフェースを使用して必要に応じてオブジェクトを取得します。
    図 6. オブジェクトが取り込まれたコンテナー
    オブジェクトが取り込まれたコンテナーを示す画像

    クリックして大きなイメージを見る

    図 6. オブジェクトが取り込まれたコンテナー

    オブジェクトが取り込まれたコンテナーを示す画像
  3. ただし、ダッシュボードからオブジェクトをアップロードすることもできます。それには、「Object Store (オブジェクト・ストア)」の下に表示されている「Containers (コンテナー)」 > 「Upload Object (オブジェクトのアップロード)」を順にクリックし、格納する内容が含まれたファイルを指定します。
    図 7. オブジェクトをアップロードする
    オブジェクトのアップロード方法を示す画像

このインターフェースは、オブジェクトをダウンロード、コピー、または削除するためにも使用することができます。


まとめ

ご覧のとおり、OpenStack ではプライベート・クラウド・ストレージをセットアップしたり、そのストレージをワークロードで使用できるようにしたりするための直観的なインターフェースを提供しています。これは OpenStack で可能なことのほんの一部に過ぎません。例えば、バックエンド・ストレージ・メカニズムとして、多くの顧客が Ceph または GlusterFS を使用していますが、そのような場合でも、エンド・ユーザーに必要な作業はユーザー・インターフェースを操作することのみです。この連載のこれまでの記事で説明したように、OpenStack は、一連のプラガブル・コンポーネントを統合する抽象化層に過ぎません。

参考文献

学ぶために

製品や技術を入手するために

議論するために

  • developerWorks コミュニティーに参加してください。ここでは他の developerWorks ユーザーとのつながりを持てる他、開発者によるブログ、フォーラム、グループ、Wiki を調べることができます。

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Cloud computing, Open source
ArticleID=961277
ArticleTitle=OpenStack について学ぶ: ストレージ関連コンポーネントの Swift と Cinder
publish-date=02062014