#WakameVdc のドキュメンテーションについて

12/10担当: Wakame-vdc / OpenVNet Advent Calendar 2014 参加記事です。1週間遅れの投稿ですみません。(ToT)

Wakame-vdcプロジェクトは少数で開発していて、新規の機能開発や、複数の商用環境への投入とメンテナンスなどの全て並行して賄って来ました。 自動化を進めてもらったおかげで、人手に依存せず、少人数でもうまくいくようになってきました。 その中で僕達自身が一番困っているのがドキュメンテーションです。

やはりWakame-vdcをできるだけ色々な方々にインストールしてご利用いただけるようにしようと、インストール手順をWikiなどに掲載したりしてきました。 しかし、今もなお実装の改善が入ることがあって、すぐにインストール手順は古くなってしまいます。 ちょっと気を抜くと、ユーザ様から、インストール手順通りに試したけどインストールできません、とご指摘いただく形になってしまうのです。 この状態を解消するために、rpmによるインストールの簡略化や、マシンイメージでの提供によってインストールそのものを無くす手法を試みて来ましたが、これはインストール手順そのものへの対策ではあっても、ドキュメントがあっと言う間に古くなると言う本来の課題には応えられていません。

結局のところ、開発のスピードを犠牲にしてでも、ドキュメンテーション専門の時間を明確に作らない限り、整備はされないのだなと言う当たり前の結論に落ち着きまして、最近は少しずつではありますが、作業のアサインをするようになりました。 その成果が、GitHubのリポジトリにあるWikiのページです。 今回は、そのWikiページに何が書かれているのか、ご紹介します。

基本方針

基本的には、できるだけ全て英語で記述するようにしています。 世の中は英語ができるエンジニアの方が多いので、理にかなってはいるかなと思っています。 また、先述した通り、ドキュメンテーションに割けるリソースも限界があるため、まずは英語で集中的に仕上げていこうと考えています。 日本語に翻訳してくださる方を募集中です。

仮想データセンターのコンセプト

https://github.com/axsh/wakame-vdc/wiki/Concept

Wakame-vdcとは一体何なのかが書かれています。 特にコンセプトである、仮想データセンターのあたりが重要です。 このコンセプトは2009年にクラウドコンピューティングと言う単語が先行する中で、本当に自分たちが一番実現したいことは何なのかを考えた結果でもあります。 もう5年は経過しているのですが、未だに実現まで少し距離感があります。 ただ、時代は着実にそれを求めていると、昨今では当時よりも強く確信しています。

簡単なインストール

https://github.com/axsh/wakame-vdc/wiki/install-guide

Wakame-vdcはインストールが簡単です。CentOSであれば、サクッとインストールが出来ますし、デモが見たいならば、ここからインストール済みの仮想マシンイメージをダウンロードして、お手元のコンピューターで動作させる事ができます。

冗長化についても、いくつかある商用環境でのノウハウをいずれ公開したいと思っていますが、基本的には、複数サーバへの分散とフェイルオーバー、プロセス監視と再起動が出来ていれば問題ありません。 その他、MySQLサーバなど、既存ミドルウェアの冗長化などは既に様々なノウハウがインターネットに溢れていますので、少しでもOSSの取り扱い経験があれば、さほど問題にはならないでしょう。

仮想マシンの利用が簡単にできる

https://github.com/axsh/wakame-vdc/wiki/Basic-usage

Wakame-vdcが標準で備えるGUIをとりあえずウォークスルーしてみています。基本的な部分のひと通りの使い方が分かるよう、スクリーンショット多めに交えての紹介です。

独自のマシンイメージも作成できる

https://github.com/axsh/wakame-vdc/wiki/Custom-images

ここでは、OpenVZコンテナベースの環境に、httpdが標準インストールされ、ブート後に自動で起動してきるCentOSイメージを作成し、登録する手順が記載されています。 wakame-initと呼ばれるブート専用のスクリプトを導入することで、マシンイメージはWakame-vdcのsshの鍵管理と連携することができるようになります。 最後に、出来上がったマシンイメージをWakame-vdcの管理専用コマンドであるvdc-manageを用いて登録すれば、無事ブート可能なマシンイメージとして選択できるようになります。

起動した仮想マシンへの通信をセキュアにできる

https://github.com/axsh/wakame-vdc/wiki/security-groups

Wakame-vdcの優れた機能として、セキュリティグループの機能があります。これはエッジネットワークで全て制御されるため、Tagged VLANを一切使わず、低コストに動的ファイアウォールとして機能するのが最大の特長です。現在はNetfilterを標準利用しており、OpenFlowと切り替えられるようにはなっていますが、いずれはOpenFlowの方を標準にしていくことになります。

機能的にはL2/L3レベルのフィルタリングをしており、仮想マシンへ論理名を持ったルールセットを動的に適用して、通信の制御することができるものです。Referenceの機能説明に記載されている部分が最もセキュリティグループらしい箇所であり、簡単にティアを組める所以でもあります。

簡単にバックアップも取れる

https://github.com/axsh/wakame-vdc/wiki/backup-instances

バックアップ用のストレージを設定し、そこに仮想マシンのバックアップを作る方法を示しています。

Wakame-vdcは、ローカルディスクだけでなく、NFSやWebDAV形式のインターフェイスを持った外部ディスクに、仮想マシンのコピーを作成することができます。外部ディスクに論理名を付けて登録し、それをバックアップ先に設定するだけで利用できます。

ドキュメントのメンテナンス方法

これらドキュメントは、下記リポジトリで管理されています。

https://github.com/axsh/wakame-vdc-wiki

上記リポジトリをcloneするなどして、編集します。その後、gollumと言うWikiエンジンで閲覧して確認をします。gollumは、Gitで利用できる文法と多少差異はありますが、レイアウトも含めてほぼ同じなので、手軽で良いでしょう。何か良いドキュメントができたら、ぜひpull-requestをくださいませ。

IaaS基盤を提供する会社としてImmutableをオススメしたい背景

３つある。

マシンイメージを手軽に生成できて、環境構築ができる世界を作る

１つ目は、担当授業でのフィードバックからの気付きだった。2010年頃、Immutableや、Blue-Green Deploymentと言うキーワードが無かったものの、その都度マシンイメージから新規環境を構築して、環境を丸ごと切り替える手法は、2010年に私が国立情報学研究所(NII)で担当するクラウド関連の授業で教えていた。これがもっともクラウドらしいデプロイメントだと考えていたためだ。しかし、当時の受講生の反応の大半は、これは実用的ではないと言うものだった。どこに課題があるのかを考えてみたが、結局のところ次のような点に集約される。

1. マシンイメージをどう作り直すか
2. 新規環境をどう本番環境へ昇華させるか

これら２点に良い手法があれば、アプリケーションデプロイは大きく変わるのだろう、と言う感覚が十分にあった。

状態管理を放棄しても差し支えない

２つ目は、VMの状態管理が大変だと言うことだ。同じくして2010年頃、その頃はChefはまだ新しくて日本ではそんなに有名ではなかったが、Puppetを使っている人がちょっと先を行っているぞ、みたいな雰囲気だった。我々もアプローチは異なるが、2009年4月に似たような手順エンジンとしてWakame-fuelと言うものをリリースしていて、オートスケールの手順をサンプルに、簡単な状態管理をしたりしていた。

状態管理が大変なのは、頭の中では同じ状態のVMだと思っているだけであって、厳密には全てのVMは状態が異なっていると言うところにある。LBの下には「同じWebサーバ用のVMが複数動いている」と思いこんでいる。しかし実際は違う。細かいが、簡単なところでは、メモリやディスクの使用容量は一致しない。LBが均一にバランスしているわけではないので、準じてログのサイズなどに偏りが出る。例えば、ディスク上のワーキングエリアが十分ある前提でスクリプトを組んで走らせると、タイミングによっては失敗するWebサーバも出てくると言うことだ。

同じWebサーバなのに、違う結果を返す。生きているサーバを管理している以上、それぞれは稼動した瞬間から違う状態になると思っていた方が良い。ChefやPuppetでそれを封じ込めるのには限度がある。スクリプトを走らせる時は、それが状態の違うものに対する差分の手順であることを、常に意識しなければならない。僕らがWakame-fuelの開発をあるときから止めた要因のひとつは、そこに限界を感じたからだ。システムを外部から「維持しよう」とする設計である以上、必ずこの限界にぶち当たるのだ。（ちなみにそうじゃないアプローチが必要だと考え、プロトタイプした結果は、とある研究成果として利用されているが、その話はまた別途…）

それ以降、当時から「ChefやろうかPuppetやろうか、今ならどっちが良いですかね？」と相談される度に「どちらでもない。同じ状態になるマシンイメージを、いつでもポンと作れるようにした方が良い」と言うようになった。

環境をスクラップ＆ビルドできるようにしてみたら快適だった

３つ目は、CIとクラウド基盤の運用ノウハウこそが答えだったと言うことだった。僕達には、2009年の秋くらいから開発を始め、2010年4月にリリースしたWakame-vdcと言うIaaSの基盤ソフトウェアがある。これを実際お客様に向けて機能追加し、運用もする中で、僕らは色々と苦労をしてきた。

特に、テストが大問題だった。理由の一つは、お客様毎にインストールする環境が異なること。これらを本気で網羅的にテストをやろうとしたら、それぞれの物理環境が必要になってしまうので、仮想で何とかしたかった。その上で様々な構成をテストしよう、と。 通常のWebアプリケーションのテストの場合、デプロイが繰り返しできれば良くて、足回りが何パターンもあるとかあまり無い。IaaS基盤ソフトウェアは、Webアプリケーションを稼動させるための文字通り基盤であるため、これをテストしようとするとインストールのパターンがいくつか必要になる。

テスト環境はお客様に持っていただいているものもあるが、これはお客様都合で用途が変わることがある。お金の問題もあって、テスト環境の一部がいつの間にか別のものに利用されるなど、融通されることは良くある話だ。毎日動いていて欲しいが、保証はない。

そこで、僕達は小企業ではあるが、ある程度はオンプレでテスト環境を持つことにした。潤沢なリソースがあるわけではないので、その上を仮想化して環境ごとのテストをスクラップ＆ビルドしようと言う目論見だ。

結局出来上がったのは、以下のようなCI環境だった。

1. リポジトリへコード修正が上がる
2. rpmなどのパッケージを自動生成する
3. テスト環境が無い場合、
   いくつものマシンイメージを自動生成し、rpmパッケージも自動インストールする
4. 上記マシンイメージをテスト環境でVMとして起動し、コンフィグする
5. テスト環境があれば、そこにデプロイスクリプトが走り、rpmなどが更新される。
6. テストスクリプトが走る
7. 上記プロセスの進捗がHipchatに逐次報告される
8. 必要なければ好きな時にテスト環境を廃棄できる

僕達の場合は、テストをどうするかと言う観点から始まったが、これは当然一般のアプリケーションのデプロイと言う視点でも捉えられる。Webアプリケーションの場合、テストのための環境をVMで再度構築するようなプロセスは大げさすぎるかもしれない。しかし、このプロセスがあれば、いつでもアプリケーションをゼロから構築しなおせる。上流のネットワークで切り替えれば、このテスト済みの環境をそのまま本番環境に仕立てることもできる。あとはデータベースなどのデータをどうマイグレートするかを検討すれば良さそうだ。

ImmutableでBlue-Green Deploymentをやろう

ここまでで、パッケージを基にマシンイメージを作り、起動したらテストを流して確認し、本番環境として切り替えて利用する、そんなプロセスが出来上がった。この過程でまた細かなツール群が誕生し、僕達の中でも、何だか全部こんな感じで良いんじゃないかって言う気がしてきたわけです。

あとは、いかにマシンイメージをオンデマンドに作るかと言う手軽さが論点になってくる。望む状態のマシンイメージが好きな時に手に入りさえすれば、現在稼動中のサーバを維持する必要がなくなる。

マシンイメージの作成って面倒くさいけど、もし、簡単に好きなイメージがポンと作れたら、生きているインスタンスを触ってミドルウェアをちまちまとインストールする現在のスタイルは変わる気がする。

— Yasuhiro Yamazaki (@sparklegate) December 25, 2012

そして、色々議論して約1年前の2013年春には、こんな結論に達した。

当時のWakame-Fuelやめた理由は、環境の差分をコードで表現するのに限界を感じたから。某パペも某シェも、結局良い答えが見つかっていないと思う。最近、僕らのなかでは、もうマシンイメージから作り直すのが一番合理的って事になってる。

— Yasuhiro Yamazaki (@sparklegate) May 27, 2013

それが、Immutableな発想に基いて準備されたマシンイメージを用いて、Blue-Green Deploymentが日常的になされている世界なんだね。

仮想ネットワークはユーザへシンプルなネットワークを提供することが最も重要な役割になる

ユーザのメリットを見直してみた

ここ１年ほど、様々な方と仮想ネットワークについて議論を重ねてきた。いつも決まって話題になるのは、ユーザのメリットは何があるのかと言う点。 よく言われるのは、柔軟性だ。確かに、仮想のネットワークのレイヤに、L2やL3を自由に組み上げられるその仕組みは柔軟性が高く、物理ネットワークで苦労してきた人には外し難いメリットの一つなのかもしれない。 見方を変えると、これは仮想ネットワークで複雑な構成が組める、と言うことを意味するわけだが、本当にそれがメリットなのだろうか。

アプリケーションエンジニアが作るネットワークこそ究極の姿になる

私が仮想ネットワークに期待するのは、プレイヤーが変わることによる、「思いもつかないユースケースの発生」だ。つまり、かつて物理ネットワークを触ってきた人ではない人が、仮想ネットワークから触り始めることによって、何が起こるのかに興味がある。

アプリケーションエンジニアと呼ばれる人々の中には、物理ネットワークの変更操作まではできない人がそれなりにいる。そうなると、彼らはそれが出来る他の専門の人へ作業をお願いすることになる。組織としても、ここで役割が大きく分かれているため、コミュニケーションのオーバヘッドが大きい。これがプロジェクトの持つスピードを損ねる要因になったりもする。

仮想ネットワークは、物理ネットワークを隠蔽し、本来自分が欲しかったネットワークを仮想のレイヤへ、自由に構築できるものである。アプリケーションエンジニアのような人々にも、ネットワークのコントロール権限を与えるものだ。物理ネットワーク専門の人へ作業を依頼せずとも、おおよそのことはこの仮想レイヤで賄えるようになる。

シンプルなネットワークへのパラダイムが起こる

そしてパラダイムはここから起こる。物理ネットワークの世界で、職人芸を見せてきたエンジニアの方々であれば、軽々しく賛同いただけないような構成を、アプリケーションエンジニアは試し始めるのだ。「ヒャッハー」「ネットワークちょろいぜー」って言いながら、ネットワークを我流で組み始める。時はまさに世紀末だ。そして仮想の世界は、ソフトウェアの力が全てである。Try & Errorが圧倒的にやりやすい世界であるので、アプリケーションエンジニア達は、あっという間にベストプラクティスを作り上げることになるだろう。そして、そのベストプラクティスは、物理ネットワークのエンジニア達が想像もしなかったような、一種原理主義的で、極端に合理的な結論として姿を見せる。

その結論が今何なのか具体的に述べられないが、間違いないのは、複雑なものではなく、シンプルなものだ、と言うことだ。何でもできるようにと議論が重ねられ、複雑になったXMLやSOAPは世界を制しなかった。結局程々に大体のことができ、シンプルなJSONやRESTが主流になった。仮想ネットワークを使い倒して行くと、想像もできないほどシンプルで合理的なものがベストプラクティスとして生き残る。

僕には、それが生み出せるポテンシャルこそ仮想ネットワークの真価だと思える。

The virtual network simplifies our network.

仮想ネットワークは、複雑なネットワークを作り出すためのものではない。仮想ネットワークは、複雑な物理ネットワークを意識することなく、究極にまで削ぎ落とされたシンプルなネットワークをオーバレイするものだ。

僕はそう信じている。

【商用事例】Fluentdを使ったログのメッセージ監視を使ってみた

本記事は、Fluentd Advent Calendar 2013へのエントリ記事です。関連があるので、ついでにWakame Users Group Advent Calendar 2013の方にもダブルエントリしておきます。(ズルい)

IaaSに強力なメッセージ監視を備えられる！

京セラコミュニケーションシステム様にて運営なさっている"GreenOffice Unified Cloud (GOUC)”と言うサービスがあります。特長的なのは、IaaSであるWakame-vdcを拡張した運用管理の統合ツールとなっている点です。システムそのものはシンプルで面白い試みがたくさん詰まっており、特に本日記事に取り上げるFluentdを用いたログ監視(メッセージ監視)はお手軽で強力なので、ご紹介します。

おおまかな手順としては下記の通り進めます。

1. ブラウザからログ内で検出したい文字列を指定する
2. サーバ内部の設定を修正する
   • td-agent.confに監視対象のログファイルを指定する
   • td-agentを再起動する
3. アラートを動作させ、ブラウザで確認をしてみる

これだけです。

ブラウザからログ内で検出したい文字列を指定する

上図のようなUIを用いて、サーバを起動し、グローバルIPを割り当てて、セキュリティグループはssh接続とhttp(80)のアクセスを許可しておきます。起動ができたらログ監視の設定をしていきます。

上図にあるように、起動したサーバに対し、ログ監視の設定をします。ここでは、apacheのアクセスログの中に、"HelloWorld"と言う文字列を見つけた際に、アラートを上げるように仕掛けてみました。実際は、UIではこの程度の設定をするだけで準備が完了します。あとは、サーバの内部の設定をしましょう。

サーバの設定を変更する

これも簡単です。お手元のターミナルからsshを用いてサーバへログインします。この辺りはIaaSを使ったことのある方ならもはや説明は不要でしょう。

起動したサーバには、下記する通り、予めtd-agent 1.1.13がインストールされています。

$ rpm -qi td-agent
Name        : td-agent                     Relocations: (not relocatable)
Version     : 1.1.13                            Vendor: Treasure Data, Inc.
Release     : 0                             Build Date: Tue 23 Apr 2013 02:56:08 PM JST
Install Date: Fri 27 Sep 2013 12:50:40 PM JST      Build Host: ip-10-123-31-198.ec2.internal
Group       : System Environment/Daemons    Source RPM: td-agent-1.1.13-0.src.rpm
Size        : 94742991                         License: APL2
Signature   : (none)
URL         : http://treasure-data.com/
Summary     : td-agent
Description :

あとはこいつの設定ファイルを変えるだけです。本来ならapacheのインストールやら、ログのパーミッション変更やらあるのですが、その辺も常識的な話なので割愛して、さっさと設定に移ります。

まずは、設定ファイル(td-agent.conf)を修正しましょう。

$ sudo vi /etc/td-agent/td-agent.conf

下記のような設定にします。この辺りは、Fluentdをご利用の方には馴染みのある設定だと思います。ちなみに、GOUCでは、td-agent.confのサンプル設定がコメントアウトで入っているため、実際は#を取り除いていくだけの作業になります。

<source>
  type tail
  format /^(?<message>.*)$/
  path /var/log/httpd/access_log
  pos_file /var/log/td-agent/position_files/httpd_access_log.pos
  tag var.log.httpd.access_log
</source>
<match **>
  type forward
  flush_interval 60s
  <server>
    name logservice
    host fluent.local
    port 24224
  </server>
</match>

少し変わっているのが、fluent.localと言うエンドポイントです。これは、GOUCの基盤であるWakame-vdcによってあらかじめ仮想的に準備されているものです。サーバの管理者は、特にその先を意識することなく、ただログを投げつければ良くなっています。あとは、td-agentを再起動しておきましょう。これで設定は完了です。あっという間でした。

$ sudo /etc/init.d/td-agent restart
Shutting down td-agent:                                    [  OK  ]
Starting td-agent:                                         [  OK  ]

アラートを作動させてみよう！

あとは、access_logをtailしつつ、このサーバ上のapacheにアクセスをしてみます。

$ tail -f /var/log/httpd/access_log
xxx.xxx.xxx.xxx - - [16/Dec/2013:13:03:28 +0900] "GET / HTTP/1.1" 403 5039 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.63 Safari/537.36"
xxx.xxx.xxx.xxx - - [16/Dec/2013:13:03:28 +0900] "GET /icons/apache_pb.gif HTTP/1.1" 200 2326 "http://yyy.yyy.yyy.yyy/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.63 Safari/537.36"
xxx.xxx.xxx.xxx - - [16/Dec/2013:13:03:28 +0900] "GET /icons/poweredby.png HTTP/1.1" 200 3956 "http://yyy.yyy.yyy.yyy/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.63 Safari/537.36"
xxx.xxx.xxx.xxx - - [16/Dec/2013:13:03:29 +0900] "GET /favicon.ico HTTP/1.1" 404 290 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.63 Safari/537.36"

当然ですが、ログが記録されていますね。さて、このログ内に、"HelloWorld"があればWakame-vdcが検出をするはずです。一番簡単な方法は、User-Agentを"HelloWorld"に偽装してアクセスしてみることですので、ChromeのUser-Agent Switcherを利用します。リロードしてみましょう。

xxx.xxx.xxx.xxx - - [16/Dec/2013:13:05:35 +0900] "GET / HTTP/1.1" 403 5039 "-" "HelloWorld"
xxx.xxx.xxx.xxx - - [16/Dec/2013:13:05:35 +0900] "GET /icons/apache_pb.gif HTTP/1.1" 304 - "http://yyy.yyy.yyy.yyy/" "HelloWorld"
xxx.xxx.xxx.xxx - - [16/Dec/2013:13:05:35 +0900] "GET /icons/poweredby.png HTTP/1.1" 304 - "http://yyy.yyy.yyy.yyy/" "HelloWorld"

無事、access_logに、"HelloWorld"の文字が出現しました。これでアラートが挙がるはずです。

アラートを確認してみよう！

しばらくすると、UIからはアラートが確認できます。設定されていれば、メールも飛んできますよ。
詳細画面からは、実際にどのようなメッセージを検出しているのかが閲覧できる他、自動的にチケットとして起票して、解決の運用フローへとつなげることもできます。
このように、Wakame-vdc基盤側に、サービスとしてFluentdを埋め込んでおくと、サーバからそれを利用するだけで良くなります。ログに関する様々な厄介事から逃れることができます。アラートはサーバに近いところでやり、将来的には分析のためにTresure Dataさんに直接ログを飛ばしても良いかも知れません。実際目の当たりにすると、更に色々な応用を思いつきますね。

以上、商用のIaaS基盤GOUCで使われているWakame-vdcがFluentdを活用しているお話でした。

エンジニアじゃないけど仮想ネットワークOSSのOpenVNetをサクっとインストールしとく。 #wakameug

12/2担当: Wakame Users Group Advent Calendar 2013

前日12/1に、記念すべき本企画最初の記事「Wakame-vdc編 - nested KVM を用いた環境で Wakame-VDC 環境の作り方」が羽深さんの手によりリリースされました。おかげさまで幸先良く無事開幕しました。Wakame-vdcのインストールに試行錯誤をした素敵な記事だったので、僕は最近リリースされたOpenVNetのインストールについて書いてみることにしました。これでアナタもOpenFlowの世界へ飛び込んでみてください！ちなみに、今からでもエントリは遅くありません。参加記事の中から最も素敵な記事には、なんとプレステ４を差し上げます。

OpenVNetは、GitHubにrpmを構築する方法が記載されています。このrpmを、あらかじめ置いておいたものを利用して、インストールすることもできます。 現在、公式なものではありませんが、rpmが下記URLにて提供されています。

• http://dlc.openvnet.axsh.jp/packages/rhel/6/vnet/current/

この他、サードパーティ製のバイナリも下記にまとめてあります。

• http://dlc.openvnet.axsh.jp/packages/rhel/6/third_party/current/

前準備

とりあえず簡単にインストールするために、下記の環境を用意してみました。

• ホスト環境: MacBook Pro 2.4GHz Intel Core i5 / 16GB RAM
• ハイパーバイザー: VMware Fusion Professional Version 5.0.3
• ゲスト環境: CentOS 6.4 / GNOME Desktop

僕のマシンは、エンジニアのお下がりなのですが、メモリが16GB入っていて快適です。 CentOS 6.4が動き出しているところからインストールを初めてみます。

yumコマンドを利用する場合は、冒頭のrpm群を、リポジトリファイルとして書いておくと便利です。早速作業にとりかかりましょう。

/etc/yum.repos.d/openvnet.repo

[openvnet]
name=OpenVNet
baseurl=http://dlc.openvnet.axsh.jp/packages/rhel/6/vnet/current/
enabled=1
gpgcheck=0

/etc/yum.repos.d/openvnet-third-party.repo

[openvnet-third-party]
name=OpenVNet Third Party
baseurl=http://dlc.openvnet.axsh.jp/packages/rhel/6/third_party/current/
enabled=1
gpgcheck=0

インストールしてみよう

epelも必要ですので、下記にまとめてあるrpmをインストールしておきます。

$ rpm -Uvh http://dlc.wakame.axsh.jp.s3-website-us-east-1.amazonaws.com/epel-release

先述したリポジトリファイルがあれば、下記するコマンドでインストールすることができます。

$ yum install -y wakame-vnet

wakame-vnetは、OpenVNetのプロジェクトネームで、現在もまだ変更されずに色々な箇所で名残を見せています。いずれ修正されるはずですので、お気をつけください。 しばらく時間がかかりますが、Complete!と出れば完了です。

設定ファイルを見てみよう

設定ファイル類は、おおよそ /etc/wakame-vnet/ 以下に配置されています。

$ ls /etc/wakame-vnet/
common.conf  vna.conf  vnmgr.conf  webapi.conf

基本的に、各ノード共通の設定ファイル"common.conf"と、個別の設定ファイルによって構成されており、vna、vnmgr, webapiと言ったシステムを構成するノードの名称が見えます。

vna (Virtual Network Agent)

これが、OVSのコントロールをするエージェントです。ネットワークを流れるパケットの動きを変えたいと思ったところに、OVSと対になるようにこのエージェントを配置する必要があります。現在ではそのような配置から、vnaはOVSとUnix Socket通信するように書かれています。いずれはOVSをオフロードするようになれば、一般的なTCP通信へと切り替えるのが良いのでしょう。設定ファイルのアドレスは、ZeroMQと言うキューサーバーへの接続先です。

vnmgr (Virtual Network Manager)

キューネットワークを介したMySQLへのアクセスを司る他、データセンター全体の物理・仮想ネットワーク構成を俯瞰して観ることができるプログラムです。必要なvnaへの指令を出し、ネットワーク全体を正しく動かす役目を持ちます。

webapi (Web API)

HTTPサーバとして機能し、curlや、wgetのような、HTTPクライアントからの接続と要求に応じて、vnmgrに向けて処理の依頼を投げかけるプログラムです。どのようなインターフェイス定義になっているかは、ドキュメントを御覧ください。ただし、ソースコードは日々更新されているため、ドキュメントが少し古くなっていることがあります。

MySQLを起動し、データベースを設定しよう

手動での起動のついでに、自動起動もONにしておきましょう。

$ service mysqld start
$ chkconfig mysqld on

その後、データベースへスキーマを流し込みます。

$ cd /opt/axsh/wakame-vnet/vnet
$ bundle exec rake db:init

一応、下記の手順でスキーマが入っているかを確認してみてください。

$ mysql -u root
mysql> use vnet;
mysql> show tables;

うまく行けば、vnetデータベース内に、networksなど複数のテーブルが確認できるはずです。

OpenVNetのサービスを起動してみよう

とりあえずここまでで基本的なインストールはおしまい。あとは各プログラムを起動してみましょう。

$ initctl start vnet-vnmgr
$ initctl start vnet-webapi
$ initctl start vnet-vna

うまく起動しているかどうか確認するには、statusを見ると良いでしょう。

$ initctl status vnet-vnmgr
vnet-vnmgr start/running, process 41789

その他のプログラムも同様に確認することができます。

さて、次回はこれらのノードの説明と、データパスの設定などがあり、それから応用としての使い方などの説明へとつなげて行きたいと思っています。

エッジネットワークの分散ルータ構成は、物理ピアでルーティングできるところが強力すぎる

最近OpenVNetにご質問いただく中で、分散ルータってのが、役割としては理解できるが、アーキテクチャ上どうなっているのかと、そのメリットが分かりづらいらしく、どんなものなのかまとめておきます。

ルータの機能をVMとして実装してしまうのは、あまりに効率的ではない

最初に、分かりやすいがオススメできない実装を述べておきます。それは、Vyattaみたいなものを、VMの内部に立てて、そいつのコンフィギュレーションを外部から行うことでルーティングさせる方法です。VMがあるのでトポロジが従来のルータとして見えやすく、その辺りが理解を助けているのでしょう。ここでは、便宜上このようなVMになったルータを、VMルータと呼んでおきましょう。

しかし、動作実験と決め込むなら良いですが、これを商用ネットワークの基盤として標準機能にしてしまうのは、下記する理由で、全くあり得ないなと思っています。

• (1) 管理やコントロールが悪くなる
• (2) スケーラビリティが低い
• (3) エッジネットワークになっていない

最後の(3)は、エッジネットワーキングと言っているのに、エッジで処理されていないと言うアーキテクチャ上の一貫性が無いと言うだけなので、説明は割愛しておきます。最初の２点について詳しく述べておきます。

(1) VMルータだと管理やコントロールが悪くなる

まず、仮想ネットワーク上にVMルータを置いて制御すると、エッジ側の物理ネットワークのVM間をパケットが走ります。 エッジネットワークは、仮想ネットワークを解釈された結果として、物理のピアができて、そこにパケットが流れるのですが、VMルータを持つことで、異なる仮想L2に属するVM間が、VMルータを経由し、純粋に物理のピアとはならなくなるのです。

このような状態で、トラフィックを管理/コントロールしようと思うと、これが非効率なのは明らかです。 物理のピアで通信しないとなった以上、パフォーマンスの面からも、VMルータのネットワーク的な距離も重要になってきますね。 無駄なトラフィックを生まないように、帯域を踏まえた設計をする必要があり、クラクラしてきます。 物理ネットワーク上の経路制御が困難になるのです。

(2) VMルータだとスケーラビリティが低い

これも大きな課題です。現段階であまり必要がありませんが、将来的に大規模ネットワークを仮想ネットワーク上に設計する場合、仮想ルータを数個配置し、ルーティングさせるようになるかもしれません。 VMルータを複数設置すると、それぞれのVMルータ間にパケットが走るため、ルーティングのホップ数が増えるだけでトラフィックを消費してしまいます。 エッジネットワークでは、おおよそのトラフィックは集約された帯域の物理ネットワークに収容されることが多いため、ルーティング程度でLANの帯域をどんどん消費してしまうのはマズい。

これらの課題は分散ルータで解決できる！

解決方法は、VMルータを止め、ルーティングが必要なパケットを物理のピアで届くように最適化することです。 特に仮想ネットワーク内では、パケットが最終的に届く先が物理的にどこになるのか判定することができるため、複数の仮想ルータで複雑にホップするように指定していても、物理のピアとして決めて届けられるはずです。

OpenVNetの分散ルータは、パケットの最終到着地を決定するために、エッジノード内部でルーティングを済ませ、物理のピアを決定してから転送をするものです。 VMルータのように、どこかにVMとして起動されていて、そこでルーティングの処理を集中的に行うものではありません。 全てのエッジノード内部にルーティングを解決する処理を持たせるのです。 物理ネットワークに対して集中型のトポロジをもたらしてしまうVMルータと対比して、OpenVNetでは上記のようなルーティングの仕方を、分散ルータと呼んでいます。

もちろん良いことだけではない

最終的に物理でピアになる分散ルータは、複雑なルーティングを設定された仮想ネットワークであっても効率的にパケットを転送することが分かりました。 しかし、そのせいで、tracerouteのようなものを仕掛けると、最適化されたホップで結果を返してしまいます。 運用時のトラブルシュートが難しくなるので、ここでは「仮想化されたネットワークの特性として、そうなるものだ」と捉えるか、「シミュレーションするモードを入れるべきだ(それで得られた結果がどんな意味を持つのか)」など、今後は考え方が色々出てくると思います。

何にしても仮想ネットワーク面白いです！

オープンソースだけで手軽に仮想ネットワークを実現しようと思ったらぜひOpenVNetを

仮想ネットワークの時代がやってきた！

ちょうど２週間前にOpenVNetを無事リリースいたしました。 仮想ネットワークを無料で誰もが作れるようになる、そんなオープンソースライセンス(LGPL v3)の最先端ソフトウェアです。 同じ分野には、プロプライエタリソフトウェアとして、Nicira(現VMware)社のNVP(現NSX)や、ミドクラ社のMidoNet、ストラトスフィア社のSSPなどがあり、オープンソースプロジェクトとしては、このOpenVNetの他に、OpenDaylightや、OpenContrailがあります。細かなものも拾うと、OpenStackのプラグイン類も含まれそうですが、オープンソースのものは、他にも色々あるので、SDN Centralの一覧ページをご参考になさってください。

色々あって悩ましいですが、オープンソースだけで手軽に仮想ネットワークを実現できるOpenVNetをぜひお試しください。ハードウェアに特殊なスイッチも必要がありません。

OpenVNetは何が良いのか

まず、オープンと言うこと。最先端技術がブラックボックスではいけません。また、実績が多くあると言うこと。OpenVNetのソフトウェアアーキテクチャは、エッジネットワーキングと言うWakame-vdcのモダンな設計を踏襲しており、パブリッククラウドの構築実績を含め、多くのプロジェクトで既に利用されてきたものです。

OpenVNetの経緯

簡単に言うと、OpenVNetは、Wakame-vdcからのスピンアウトプロジェクトとして2013年4月に始まりました。それ以前に、2011年12月時点でWakame-vdcがOpenFlow 1.0に対応を済ませて、現在の設計の基礎を完成させました。その後、機能を仮想ネットワークへと拡張していますが、この辺りの経緯は別のエントリにまとめてあります。2012年3月には、仮想ネットワークは動作していました。それから１年間はWakame-vdcもやることが増えてきたため、仮想ネットワーク以外の部分に力を入れていました。無事、仮想ネットワークについてもニーズが見えてきたので、2013年4月から本格的にOpenVNetと言う独立したプロジェクトにまとめなおすことになりました。新しく考えなおしたのは、OpenFlow 1.3へのアップグレード対応と、新機能(仮想L3やゲートウェイなど)を追加した部分で、基本設計と言う意味ではWakame-vdcと大きな違いはありません。

Wakame-vdcの時代から、Tremaを利用してきたのもきっかけとなり、NEC様のご協力をいただき、OpenVNetの検証がなされています。現場の技術者グループとは良く意見交換をさせていただくのですが、お互い実際に動くコードを使いながらの話なので非常に明快で、活用方法にもきちんとしたビジョンがあり、非常に楽しいです。ここからコミュニティを発展させていくつもりですので、ぜひ皆様もご一緒しませんか。

「独習Linux専科」を読みました。これから学ぶ人も、すでに知っている人も、基礎知識の総集編としておすすめ。

著者の中井さんからいただいた「独習Linux専科」を読みました。 少し前にいただいていたのですが、ボリュームがあって、結構時間かかっちゃいました。

第４、５章がとても良い

特に４章は、ファイルサーバ作ってみよう！とか、データベースを管理してみよう！とか、Ruby on Railsを使えるようにしよう！とか、目標が明確だから良いのです。モチベーションの湧かない人は、こういうところから入るべし、です。第４章を進める上で、基礎部分に課題が見えたら、その前の章までに記述がありますので、その時遡って読んでもいいかも知れない。そして、最後の５章で、この書籍の中で一番ディープなところに踏み込みます。おそらく４章を読み終えたら、Linuxってそもそもどう言う概念で作られているんだっけ？みたいなところが気になってきますよね。完全に網羅されているわけではありませんが、期待通りエッセンスは書かれています。

実際、ここまで読み進めていくと、このまま第６章が読みたくなってきますが、残念ながら本書はここでおしまい。でも、気がつけば、自力で羽ばたくことができるようにはなっているのではないでしょうか。最後には、読者の学習意欲に期待しつつ、著者も学びの手を止めません、という旨が書かれていました。

「分かりやすさ」でオススメしたい

中井さんの文章は分かりやすい。つい最近もそれを知らしめるエピソードがありました。僕から、中井さんに、昨今考えている技術の話を説明したんです。この話は３年くらい色々な人に話しをしたけれど、なかなか理解してもらえなかった。きっと難しいんだろうと思って諦めていたんです。でも、中井さんは、そんな僕の話を理解してくださっただけでなく、自分の言葉で皆に分かるように直してしまった。実際にその言葉を聞いた皆さんが納得している。つまり、僕の話は決して難しいものではなく、ただややこしいだけだったんですね。そう言う視点で僕はこの本を読みました。

平易な言葉でありながら、決して足りなくはない。慎重に選ばれています。脳みそに染みこんで来ます。だから今からLinuxを始める人もそうですが、復習がてら自分の理解をまとめるためにも、この本はきっと役立つと思いますよ。知識を得た皆様は、いつか誰かに自分も誰かへLinuxの「いろは」を教えなければならない日がくるかも知れません。その時は、この本に書いてある言葉で伝えてみてください。いや、この本を手渡してしまった方が早いかな。

「独習Linux専科」サーバ構築/運用/管理 ――あなたに伝えたい技と知恵と鉄則 (Software Design plus) [大型本]

中井 悦司

技術評論社

2013-08-30

Wakame-VDCを活用したKCCS様の新サービスGreenOffice Unified Cloudについて

Wakame-VDCを利用したKCCS様の新サービスGreenOffice Unified Cloud (GOUC)が5/15(水)にリリースされました。

Wakame-VDCを用いたオンデマンドなリソースコントロールと、仮想データセンターの技術コンセプトが活かされているのはもちろんです。それだけでなく、クラウド上でのサービス開発・運用に必要な機能が付いている！と言う点が、僕が個人的に思う最大の特長です。

記録を残しながらクラウドを管理する

GOUCで実現されている機能のうち、一番運用を意識していて面白いと感じるのは、チケットシステムです。チケットを起票して、それのステータス管理やら、コメント記入やらをやるものです。

これに類する仕組みは、どの現場でも割りと広く使われているのではないでしょうか。しかし、特にユニークだと思うのは、チケットにコメントを書くのと同じ要領で、インフラの操作をしたものもチケットへ記録に残せると言う点です。そう、チケットシステムが、インフラとガッチリ連携しているのです。

想像してみてください。運用時には様々なトラブルが起こるわけです。特定のサーバだけレスポンスが悪いだとか、リリースのために新しいマシンイメージを作るだとか、監視してたらアラート来たとか。

それらを全部チケットで管理するわけですが、GOUCでは、手動で任意のチケットを作るのはもちろん、アラートなどはできるだけ自動でチケット化されます。その上で、各チケットに関連した作業として、マシンのリブートをしたとか、新しいインスタンスを追加で起動したとか、そんなのがコメントと一緒に残るのです。

通常、この辺りはデータセンターリソースを操作する事だけを目的に作られたコンパネではやらない部分です。仮想マシンを再起動したりする操作はGUIで提供されますが、その操作が「何のために行われたのか」は管理していません。チケットに基いて操作を行う、このコンセプトが運用のシーンでは嬉しいですし、基盤とガッチリ連携していなければ実現できない部分でもあります。

この辺り、現場の方とはお客様に何が必要なのかと言うところを議論したり、実際にヒアリングに行ったりして、組み立ててきた背景があります。そのプロセス自体がとてもおもしろい試みでしたし、結果的に面白いものができた実感につながっています。これからもお客様の声で成長していくものですから、ぜひ使ってみて、ご意見ください。

技術的なところ

前回同様、今回も機能面が色々パワーアップしています。

一番大きいのは、東京と京都の二拠点にデータセンターがあり、Wakame-VDCはそれぞれに分散してインストールされて、相互にマシンイメージの転送を行うことができるようになっています。これで、バックアップサイトや、激甚災害対策(DR)等の構築の役に立てることができると思います。bkstaと言う専用のエージェントが追加されています。

次に、グローバルIPを任意のVMに割り当てることができるようになりました。Wakame-VDCにはnatboxと呼ばれるエージェントが追加されており、ここには、OpenFlowのフローテーブルがバリバリ使われています。

それから、割りと地味な機能ですが、Wakame-VDCのログ保存方式が、fluentd+cassandraになりました。今までのファイルベースのやり方でもいいのでしょうけれども、今後ログの収集は基本的にこの仕組を横展開しようと考えています。

メッセージ通知サービス(プロジェクト名"Dolphin")も追加されています。これは内部では死活監視Zabbixと連携して、イベントメッセージを吸い上げるためのインターフェイスとして利用されています。

※public/masterへのソースコード公開はもう少々お待ちください

Wakame-VDCはまだまだ成長します

順調に成長していますので、今後もご期待ください。無い機能、欲しい機能は一緒に作りましょう！OSSはそうして成長をしていくのです。そしてまた、いつでもそのフィードバックを得ることができます。

Wakame-VDCを利用したパブリッククラウドWebARENA VPSクラウドについて

Wakame-VDCを使ったWebARENA VPSクラウドが、このほどNTTPCコミュニケーションズ様よりリリースされました。このプレスリリースは2013/3/5のものでしたから、今日でもう2週間も経ってしまってブログを書いていると言う体たらくですみません。

ぜひ使ってみてください。今ならキャンペーン中なので、2013/5/13までに申し込むと、最大３ヶ月間、プラン100が無料になってお得です。

Wakame-VDCの進化

実際、NTTPCコミュニケーションズ様とは、Wakame Software Foundationにご加盟いただいて、一緒にWakame-VDCを育てていこうと言うところからスタートしています。最初の頃の打ち合わせは、どうやってWakame-VDCを活用するのか四六時中議論をしました。Wakame-VDCは、なぜ現在のアプリケーションデザインになっているのか、未来のクラウドコンピューティングの形、そしてOpen Source Software (OSS)に対する考えなどを共有していくにつれ、サービスのイメージが出来てきた、と言った感じです。そこから足りないものを、共同でどんどん実装し、リリースとなったわけです。

OSSは製品ではなく、生き物です

個人的に思うのは、OSSを製品として見ても良いのですが、製品として見過ぎると、今ある機能に目が行きがちです。OSSの最も重要なポイントは、自らの力で変化をさせられるところです。「製品」と言うよりは、未来をどうするべきか考えながら成長をさせていける「生き物」なのです。機能比較表みたいなものを作って、現時点版のOSSに、○×を付ける事の意味はあまりありません。本当に必要な機能なのであれば、そう願い、そう行動すれば、×だったものも数カ月後には○になる。未来を共に作れるのです。それがOSSの意義なのであり、Wakame-VDCのような、オープンな技術を採用した効果と言えるわけです。

割りとこの辺りで、主体的に動こうとする企業様が少ないのは事実です。どうしても自分でやるよりは、誰かにやらせようとします。OSSは自分で学ぶことができ、それを怠りさえしなければ、ベンダーロックインから開放されるのです。実装を誰かに任せ、取り扱いも誰かにやらせ続けていたら、ベンダーロックインに自ら嵌り込むだけなのです。OSSがプロプライエタリ製品と大きく違うのは、ソースコードを見て自ら学習できる点です。ここに投資しなければ、OSSである意味がありません。

僕達は、本当にオープンな技術とは何か、真の意味を問うています。Wakame-VDCは、それを応援できる数少ないOSSです。関連する全ての技術をお渡しします。皆様と共に、Wakame-VDCの輪を広げたいと思っていますので、どうぞよろしくお願いいたします。気軽にご連絡ください。