Neutronのベンダープラグインとサービスプラグイン

PariのOpenStack Summitでサービスの問題とベンダープラグインの問題が議論されていました。その解決策がほぼ決まる方向にあるので書いてみます。詳しくは以下のBlogに書いてあります。

http://www.siliconloons.com/posts/2014-12-26-neutron-splits-and-spinouts/

Servicesの問題

LBaaS/VPNaas/FWaaSはNeutronのサービスということでL2/L3機能の上に実装されています。残念ながらL2/L3の機能実装にNeutronのコアチームがかかりっきりで、あまりにもこれらのサービスの進捗が悪いとの事で不満が溜まっていました。アトランタのSummitではDesign Summit外で独自の話し合いが行われ結果的にLBaaSの独立ProjectであるOctabiaが派生してしまいました。

https://wiki.openstack.org/wiki/Octavia

Neutronのチームも何もしなかったわけでは無く、Neutron-Incubationの仕組みも作りましたが結果的に別PJが発足しました。この問題点の根本的な解決策としてGitのレポジトリを分けて、コアのチームも分けてしまう事に決まりました。必要に応じてL2/L3のコアチームと共同で作業を行うことになっています。Kilo-1ではすでに別れた状態でリリースがされていますのでKiloはこの形でリリースされるものと考えられます。 “Neutronのベンダープラグインとサービスプラグイン” の続きを読む

広告
Neutronのベンダープラグインとサービスプラグイン

様々なOpenStackのインストーラー

この記事は「OpenStack (2枚目) Advent Calendar 2014」 12/16分です。

OpenStack Installerについて

ParisのSummitでのお話ですが、本番環境でHA作るならManual InstallはやめてベンダーのInstaller使っとけの話がありました。理由はMiddlewareの設定等や、HAの構成を作るところで色々ミスしやすいからといった所でした。更にSI視点ですとManual Installして保守側に引き継ぐなんて悪夢です。

とは言えパッケージを地道に一つ一つインストールして、設定すると結構勉強にはなりますので一度はやっておくのはお勧めです。以下OpenStackのインストーラーを利用するメリット・デメリットをあげてみました

  • メリット
    • 複雑な設定を一気に行える
    • ディストリビューションのサポートを受けやすい
    • 再インストールの手間を省ける
  • デメリット
    • 構成が固定される
    • 構成管理ツールの学習コストとデバック必要になる

“様々なOpenStackのインストーラー” の続きを読む

様々なOpenStackのインストーラー

Nova Schedulerも捨てたもんじゃ無い

この記事は「OpenStack (2枚目) Advent Calendar 2014」 12/14 分です。

Nova Schedulerの状況

NovaのFilter Schedulerが使えないとの事で、風当たりが強い時期がありました。それを受けてSolver Schedulerや、Ganttと呼ばれる外部のスケジューラープロジェクトが立ち上がりました。最近はそれほどの熱気は感じませんが、現状はそれぞれで粛々と対応が行われているようです。現状のFilter Schedulerも改善が続けられており、機能を理解しておけばそれなりに使えるとは思います(機能を追うのは大変ですが)

Filter Schedulerについて

基本的に複数あるホストをフィルタリングして選択して、その後重み付けで最後の一台を選ぶ作業を行います。フィルターは様々なフィルターが用意されており、以下に一覧があります。 “Nova Schedulerも捨てたもんじゃ無い” の続きを読む

Nova Schedulerも捨てたもんじゃ無い

OpenStack NeutronのML2プラグインはどのようにドライバーを呼び出しているか

Neutron ML2プラグインについて

3rd Partyの製品を使う場合にはML2のメカニズムドライバーでの実装が増えて来ました。ML2は構成上タイプドライバーとメカニズムドライバーがあります。今回はざっくりとML2がどのようにメカニズムドライバーを呼び出しているかをみて、ドライバーの動作を理解する時の助けとします。処理の流れを理解しておくとSDN Controllerにどのような命令を実際に送るのかを見ることが出来ます。ML2のプラグインは起動時に指定されたMech_driverをリスト化しています。何らかの操作を行う場合は、まずprecommit+操作が呼び出されてます。precommitはDatabaseのTransaction中に呼び出されます。precommitはDriver側で必ずしも実装している必要はありません。その後実際の設定変更を行うpostcommit+操作が呼び出されます。以下のML2 Pluginのコードを見るとcreate_subnetが呼ばれると、それぞれcreate_subnet_precommitとcreate_subnet_postcommitを呼び出しているのがわかります。 “OpenStack NeutronのML2プラグインはどのようにドライバーを呼び出しているか” の続きを読む

OpenStack NeutronのML2プラグインはどのようにドライバーを呼び出しているか

OpenStack Ceilometerについて

Ceilometerについて

Ceilometerは将来の目的として課金機能の実装がありますが、課金を行う前段階の測定部分にとどまっています。Ceilometerでは以下の機能を提供しています。
  • 各種データーを計測
  • 送られてきたデータをDBに保存
  • 閾値を設定してWeb Hookを行う
Ceilometerの詳細は以下に記述されています。
課金して、レポートティングを行うのはProjecのCloud Kittytが立ち上がっていますが、今後本体に取り込まれるかはまだわかりません。

Ceilometerへのデーターの送信について

MQを経由した送信が推奨されています。それが不可能な場合は
APIを利用して、データー送信元からCeilometerに対して
Pushで送信する事が推奨されます。非推奨はCeilometerから
データーをPoolingする事になります。

計測可能な値

以下のページにある値が標準機能で取得可能です。CollectorをCeilometerに送る事も出来ます。

バックエンドのDatabase

以下の通りMongoDB/MySQL/PostgreSQL/HBase/DB2を
サポートしています。MongoDB以外は十分テストされていない場合があるためあくまでMongo DBが推奨とされています。

“OpenStack Ceilometerについて” の続きを読む

OpenStack Ceilometerについて

OpenStack NovaのUtilization aware Schedulingを利用する

Nova ComputeはNova Schedulerに対して定期的に構成情報を送信しています。Compute Node上の</var/log/nova/nova-compute.log>を見ると確認出来ますが送信している値はFree RAM/Free Disk/Free vCPUSになります。NovaのFilter Schedulerはその値を元にしてホストを決定しています。

Icehose(2014.1)からユーザー側で上記の値以外に自由にSchedulerで利用できる値を送信出来るようになりました。それがUnitization aware schedulingです。Blueprintは以下になります。

https://blueprints.launchpad.net/nova/+spec/utilization-aware-scheduling

CPUの利用率を送信するスクリプトがサンプルとして提供されていますが、コンピュートホスト側のnova/compute/monitorsにスクリプトを配置して、正しくnova.confを設定すればnova-computeプロセスが定期的にスクリプトを実行して必要な値を送信してくれます。

nova.computeからmonitorsをimportしてrmonitors.Resouce MonitorBaseを継承してPythonスクリプトを書く事になります。returnする値はfloat型である必要があります。 “OpenStack NovaのUtilization aware Schedulingを利用する” の続きを読む

OpenStack NovaのUtilization aware Schedulingを利用する