一方、「スモールスタート用の構成は100ハイパーバイザー程度までを想定しているため、仮想ブロックストレージがスケールする必要性は低い」と前述しましたが、これは本当でしょうか? 実のところ、これも正しい場合と正しくない場合があります。なぜかというと、プロセス構成はOpenStackを利用する目的に大きく依存するためです。
OpenStackで構築した環境を、 LAMP構成のWebサービスの基盤として利用する場合を例に見てみます。想定する構成は次の通りです。
- データの保存に利用するデータベース領域に仮想ブロックストレージを利用する
- LAMP構成において1仮想マシン1機能とし、可用性や性能のためにそれぞれ2 台ずつ用意する
- このとき、1つのWebサービスでは8台の仮想マシンを利用して、1台の仮想ストレージを利用する
1ハイパーバイザーに20台の仮想マシンを配置できるようにしたとして、最大構成である100ハイパーバイザーでは2000台の仮想マシンになり、250のWeb サービスを動作させることができるとします。1つの仮想ブロックストレージのサイズを仮に1TBとすると、最大で250TBのストレージ領域がバックエンドに必要になります。
この例では Webサービスのデータベース領域にのみ仮想ブロックストレージを利用しましたが、もし仮想マシンと仮想ストレージを1対1で利用するようなアプリケーションであれば、仮想ブロックストレージの利用量はさらに増加するため、仮想ブロックストレージのスケールも必須となってきます。
この場合には、スモールスタート用の構成をそのままの構成で利用するよりも、ストレージ関連のプロセスが動作するノードを別途用意することで、スケールや管理がしやすくなります。今回の例ではストレージのバックエンドに注目して記載をしましたが、ネットワークのバックエンドについても同様なことが言えます。
もちろん、必ずしもノードを分けると管理がしやすくなるかというとそうではありません。最大構成での仮想ブロックストレージの利用量では100ハイパーバイザーの最大利用時を考えて記載しましたが、そもそもの利用目的から10ハイパーバイザー程度までしか利用しない予定であれば、ノードの種類を分けただけ管理する対象が増えてしまいます。
つまり、ここまで解説してきたように、OpenStackを利用する時の構成において、バックエンドの選択を含めて「これが唯一の正解」といった構成は存在しないのです。OpenStackの構成は「何のために使う」「どうやって使う」を意識することによって、あるべき構成が変わってくるものなのです。
今回は「OpenStackの構成はどのようにするべきか」を紹介しました。次回は今回説明したプロセスを、どのように冗長化してOpenStackの可用性を高めていくか、解説したいと思います。
室井 雅仁(むろい まさひと)
OpenStack コミュニティで「Congress」のコントリビューターとして活動中。NTT ソフトウェアイノベーションセンタに勤務し、OpenStackを利用したOSSクラウドのクラウドアーキテクトを担当している。OpenStackを利用したクラウドの開発には「Diablo」リリースより携わっている。
市川 俊一(いちかわ としかず)
クラウドや分散ストレージの分野の研究開発に10年以上携わっており、前職のVerio社ではパブリッククラウドやマネージドホスティングの開発設計と技術営業を担当。現在はOpenStackを利用したクラウドの開発やコミュニティ活動を担当している。三鷹市在住。
スピーディなビジネス展開が収益向上の鍵となっている今、ITシステム整備にも一層のスピードと柔軟性が求められている。こうした中、オープンソースで自社内にクラウド環境を構築できるOpenStackが注目を集めている。「迅速・柔軟なリソース調達・廃棄」「アプリケーションのポータビリティ」「ベンダー・既存資産にとらわれないオープン性」といった「ビジネスにリニアに連動するシステム整備」を実現し得る技術であるためだ。 ただユーザー企業が増えつつある一方で、さまざまな疑問も噴出している。本特集では日本OpenStackユーザ会の協力も得て、コンセプトから機能セット、使い方、最新情報まで、その全貌を明らかにし、今必要なITインフラの在り方を占う。
Copyright © ITmedia, Inc. All Rights Reserved.