Revision as of 10:13, 2 October 2014

RACK (Real Application Centric Kernel)

The concept of RACK: "OpenStack Native Application"

OpenStack Native Application とは、OpenStackのリソース（たとえば、VMやVNET）を、アプリケーションの中から直接利用して動作するソフトウェアの事です。現在主流のアプリケーションは、"クラウド以前"にデザインされており、クラウドとの親和性が考慮されていません。そのため、これらのアプリケーションがOpenStack上で動作するには、ChefやPuppetといったツールと連携する必要があり、システムが複雑化しています。

RACKはOpenStack上で直接動作するソフトウェア、"After the Cloud" アプリケーションを簡単に作成するための仕組みです。プログラマはRACKを使うことで、外部との連携を必要とせずに、OpenStack上でスケールし、移植可能なアプリケーションを記述し動作させることができます。

RACKの概念は以下になります。

機能を持たせたVMを1つの実行バイナリファイルとして扱う。"機能"とは、アプリが動作するために必要なOS、ミドル、プログラムの事を指します。ここでのプログラムはRACKのAPIを呼び出して動作するように作ります。
この実行バイナリを、OpenStack上に展開することで、このVMはLinuxプロセスのように振る舞い、何らかの仕事をします。
このプロセスは、プログラムの中で記述に基づき、Forkして子プロセスを生成したり、プロセス間で通信を行います。

手っ取り早くRACKを体験するには、サンプルプログラムを見てください

What is RACK?

RACKは、NovaやNeutron等のAPIをラッピングし、VMがプロセスのように振る舞うためのデータ構造を定義します。そして、このプロセスとして扱われるVM間で、通信やデータ共有を行うためのAPIを提供します。アプリケーションはこのAPIをコールすることで動作するように記述していきます。更にRACKはこのAPIを利用するためのライブラリ[1]も提供しています。このライブラリを使うことで、簡単にOpenStack Native Applicationが記述できます。 RACKは、OpenStack Native Applicationを記述するためのフレームワークとも言えます。

What we call "process"

RACKではプロセスという単語がよく出てきます。このプロセスの実態はNova上の仮想マシンインスタンスです。しかしこのインスタンスは、起動すると何かの仕事をするように作られています。これは、Linuxの各種実行ファイル、たとえば lsコマンドやgrepコマンドが起動されると仕事をするのと似ています。 Linuxでは起動した実行ファイルはメモリ上のプロセスとなり、仕事を行い、最後には終了してメモリ上から消えます。 RACKはこの考え方をOpenStack上で再現します。機能を持たせたglanceイメージをNova上で展開し、展開されたインスタンスが何か仕事を行い、最後に消えます。そのため、RACKでは仮想マシンインスタンス＝プロセスと呼んでいます。

プロセスとして起動されるVMインスタンスは、PIDを持ち、Fork可能で親子関係を持ちます。また関係性を持ったプロセス間（VM間）では、IPアドレスを意識しないプロセス間通信やデータ共有、同一名前空間を持ったファイルシステムが利用可能で、この実行バイナリを作成するプログラマは、Linuxのプログラムを作る感覚で、OpenStack Native Applicationを記述できます。

Architecture

RACKはVMをプロセスとして扱うためのデータ構造を定義したデータベースを持ち、このデータ構造を操作するためのRestfulなAPIを提供します。アプリケーションから命令を受けると、OpenStackのAPIをコールし、プロセスの属性情報を自身のデータベースに書き込みます。

Attibutes of a process

プロセスの属性情報には下記のようなものがあります。

keypair, security-group, network

Nova、Neutronによって提供されるリソースです。実体はOpenStack上にありますが、プロセスの属性情報としてそれぞれのリソースIDを保持しています。

GID (group ID)

各プロセスは一つのグループに所属します。同じグループに所属するプロセスは、同一名前空間でファイル共有できるなどのメリットがあります。

PID, PPID

各プロセスに付与されるIDおよびその親のIDです。これによりプロセス間の親子関係が表現されています。

rack-proxy

各グループにはそれぞれrack-proxyというプロセスが存在します。 rack-apiがパブリックなAPIなのに対し、rack-proxyはそのグループだけがアクセス可能なAPIを提供します。プロセス間通信やファイルシステムといった機能は、rack-proxyが提供します。

Deployment of rack-api and rack-proxy

現状、rack-apiとrack-proxyはそれぞれVMとして起動されます。 rack-apiは単独のネットワークに配置され、パブリックにアクセス可能とします。グループごとに存在するrack-proxyは、rack-apiのAPIをコールすることで起動します。 rack-apiおよびすべてのrack-proxyは、同じデータベースを共有します。

将来的には、rack-apiはOpenStackのコントローラノードに、rack-proxyはneutron-ns-metadata-proxyのようにネットワークノード内に起動するような構成を想定しています。 これらはOpenStackのコアプロジェクトと密接に関わってくる範囲なので、現状はVMとして配置させています。

Interprocess communication support

RACKはプロセスのデータ構造操作、起動停止に加え、プロセス間での通信、データ共有を支援する機能を持っています。これらはライブラリ[2]と組み合わせて実現されています。

ファイルシステム

グループ内で共有されるファイルシステムを提供します。プロセスは同じ名前空間でファイルにアクセスすることができ、あたかもローカルのファイルシステムにアクセスしているかのごとく利用できます。

共有メモリ

簡単なデータをプロセス間で共有するための機能です。複数のプロセスで同時に同じデータを参照したい場合などに利用できます。

パイプ

Unix-pipeライクな機能を提供します。あるプロセスで処理した結果を別のプロセスに渡すということが簡単にできます。相手のIPアドレスを知る必要はなく、相手が起動するまで待つ必要もありません。

シグナル

PIDの指定だけで任意のプロセスに文字列送信ができる機能です。使い方によって複数のプロセスにマルチキャスト送信することも可能です。

Use cases

RACKの使い方に制限はありません。プロセスの追加・削除、プロセス間のデータ共有、データ通知などはすべて、プログラムによって記述可能です。 RACKを使えば、OpenStack Nativeなアプリケーションを簡単に開発することができます。

RACKの使い方のヒントとして、いくつかのサンプルアプリケーションを用意しています。まずはサンプルアプリケーションを動かしてみて、OpenStack Native Applicationとはどのようなものか体験してください。

Resources

ソースコード: https://github.com/stackforge/rack

ライブラリ: https://github.com/stackforge/python-rackclient

デプロイメントガイド: https://github.com/stackforge/rack/tree/master/tools/setup

サンプルプリケーション:

Difference between revisions of "RACK/ja"