ぶていのログでぶログ

思い出したが吉日

5分でわかるOpenStack Octaviaという内容で社内LTしました

社内LTの機会があったので、最近いじっているOpenStack Octaviaについて発表しました。 発表内容はブログで書いたことをもう少し利用者側よりにそして、Octaviaを使うとどう便利なのか?を主眼にしています。 また、今のところ公式CLIツールがないので、発表に間に合わせてツールを作りました!っとバーン感を出していますw 発表したツールは↓です。

github.com

yao(Yet Another OpenStack API Wrapper)は、弊社のOSSRubyのOpenStackライブラリです。 これを用いてCLIを作っています。 なぜあえてCLIを再実装しているかという話は別途できればと思います。。

github.com

hubotでAkamaiのFast Purgeを実行するスクリプトを作った

タイトルの通りです。 package.jsonのdependenciesに追加して、external-scirpts.jsonに追記すれば使えると思います。

www.npmjs.com

github.com

設定

Akamai {OPEN} APIを使っているで事前にクレデンシャルの発行が必要です。 クレデンシャルの発行は以下に公式の日本語の解説ページがあるので参考にしてください。 なお、LunaでAdminロールがついていないと発行できないです。一時的にAdminをつけて発行後に戻すとかでできるかもしれない…(未確認

blogs.akamai.com

クレデンシャルを発行したら client_token / client_secret / access_token / host をそれぞれ対応する環境変数にセットしhubotを起動してください。

おわりに

Fast Purgeが使えるようになったので今までPurgeに5分位かかっていたのが5秒で終わるようになって生産性↑↑です(作ったばかりで実績はまだないけど!!!)

あと、初めてAkamai APIを触ったのですが、ドキュメントが複雑だったり難しいイメージがあり、今まで敬遠していたのですが、Akamaiが用意しているライブラリを使うとあっさりAPIが利用できてかなり便利でした! 他の言語のバインディングもあるので、Akamai APIでゴニョりたいときにはシュッとできそうな気がします。

蛇足

Akamaiが公式でCLIを作っているみたい。 今回作ったFast Purge(CCU v3)もできるようなので、黒画面からポチポチする場合は便利だと思います。 まだ機能はすくないけど今後拡張していくのかな、たぶん。

github.com

OpenStack Octaviaの挙動

前回はOpenStack Octaviaの概要を説明したので、今回はLoadBalancer(LB)が作られたときにOpenStack Octaviaがどのような動作をするか説明したい。 なお、LBの更新や破棄、PoolやListenerなどなどの操作については、今回説明する内容とほとんど同じであるため説明を省略する。

基本構成

f:id:buty4649:20170628180318p:plain

基本構成は前回説明したものと同じ。 neutronとnovaがあり*1、Octaviaが単独のノードとして存在する。 Octaviaはneutron LBaaSのバックエンドととして動作するように設定されている。

1. neutron LBaaS APIが叩かれるとOctaviaに通知が行く

f:id:buty4649:20170628181552p:plain

クライアントからLBの作成要求が来る。 要求を受け取ったneutronは、OctaviaにLB作成要求をする。

OctaviaはREST APIインターフェイスを持っているので、neutronはAPIを叩くだけになっている。 特に、OpenStack OcataからはOctavia API v2.0になりneutron LBaaS API互換となるため、neutronはリクエストをそのままOctavia APIに転送するだけになる。 そのため、クライアントは直接Octavia APIを叩くこともできる*2

2. nova APIを使用しLBインスタンスを作成する

f:id:buty4649:20170628182337p:plain

Octaviaは、nova APIを使用しLBインスタンスを作成する。 nova APIを叩いたあと、インスタンスが起動したことを確認するため、LBインスタンスに定期的に通信を行う。

3. VIPポートの作成と設定

f:id:buty4649:20170628182750p:plain

LBインスタンス用のVIPを作成するために、neutronへポート作成要求を行う。 そして、各LBインスタンスでVIP宛の通信を受信できるように、allow-address-parisの設定を行う。

LBインスタンスでは、agentが起動していてこちらもREST APIインターフェイスを持っている。 このインターフェイスを通し、作成したVIPのアドレスを、LBインスタンスに通知する。

4. 定期的にチェックする

f:id:buty4649:20170628184531p:plain

Octaviaは定期的にLBインスタンスの死活監視を行う。 LBインスタンスの応答がない場合、インスタンスを破棄し新たにLBインスタンスを作成する。

おわりに

ここまでがOpenStack Octaviaの挙動の説明になる。 OctaviaはnovaやneutronのAPIを叩くだけであり、直接インスタンスやプロセスの作成やネットワークを設定するようなことはしない。 また、neutronとは独立したDBを持っているために、実はOctaviaはneutronとも疎な関係にある。 ココラヘンの話は次回以降にしたいと思う。


前回は社内説明用にGoogle Appsの図形描画で書いていた。 今回の記事を書くために draw.io を使って書き直したのだが、レイヤーが使えてとても便利であった。 図形情報の保存先がローカル以外にも複数のクラウドストレージが選べるのもポイントが高い…! もう今後はネットワーク図を書くときはdraw.ioを使おうっと思った次第。

*1:これ以外にもコンポーネントは存在するがここでは説明を省く

*2:そうすると、neutronの管理情報と齟齬がでるが、情報が二重管理になっているのでそれはそれで…というのもある。ここらへんについて次回触れたい

OpenStack Octaviaの概要

最近、OpenStackのOctaviaコンポーネントを弄っていて、だいぶわかってきたのでメモ代わりにまとめておく。

OpenStack Octaviaとは

私ってほんとバカではなく、将来的にOpenStackの標準的なLBaaS APIエンドポイントとして機能すべく開発されているコンポーネント*1である。 OpenStack Mitakaから標準でサポートされ、Pikeでv1.0がリリースされる予定*2になっている。

OpenStackのLBaaSといえば、neutron LBaaSがある。 neutron LBaaSとOctaviaはどう違うのだろうか? Octaviaの説明についてプロジェクトページには以下のように書いてある。

Octavia is an operator-grade open source scalable load balancer for use in large OpenStack deployments.

オペレータグレードでオープンソースなスケーラブルなロードバランサーなのだ! な、なるほど…?

これではよくわからないので、neutron LBaaSとの違いについて構成を見ながら説明していく。 なお、ここでは、neutron LBaaSのバックエンドはhaproxyを使用しているものとして説明する。

neutron LBaaS(haproxy backend)の構成

f:id:buty4649:20170619134354p:plain

上記の図がneutron LBaaS(haroxy backend)を用いた一般的な構成図である。 neutron LBaaS APIを叩きLBを作成すると、network node上にLBが作成される。 Floating IP(fip)はLBのVIPに紐付けているため、インターネットからのパケットはLBを通し、各インスタンスへロードバランスされる。 この構成の場合、必ず network node上にあるLBを介して通信するためここがボトルネックになりやすい*3

それでは、Octaviaではどうなっているか見てもらおう。

OpenStack Octaviaの構成

f:id:buty4649:20170619141017p:plain

Octavia用のノードが増えていることがわかる。 が、これはnetwork nodeと統合しても問題はない。 ここでは説明を簡単にするため分離している。

新しいノードが増えていること以外で、neutron LBaaSとの違いで大きい点は LBがcompute node上にあることだ。 LBを普通のインスタンスとして、compute node上に構築することでネットワークトラフィックをnetwork nodeに集中することを避けている。 また、MitakaのバージョンからはAct/Sby構成が取れるため、LBを作成すると自動的に冗長構成を取ることができる。

これが、neutron LBaaS(haproxy backend)と比べたときのOctaviaのメリットである。

長くなりそうなのでこの記事はここまで。 次回は、LB構築時のフローを紹介したい。

次: OpenStack Octaviaの挙動

*1:https://github.com/openstack/octavia/blob/master/README.rst#octavia

*2:https://wiki.openstack.org/wiki/Octavia/Roadmap#Major_milestone:Octavia_Version_1.0-_Planned

*3:haproxy以外のバックエンドを使えば解決できるかもしれないが、が、環境がないため試していない

ピンチはチャンス

今日は久しぶりに渋かった。。 長年サービス/システムを運用しているとあるあるだと思う。

まさに、今日、私が踏み抜いた。

最初何が起こっているのか理解できなかった。 本当に渋い。誰が悪いのかすらわからないほどだった。

貧乏くじを引いた…

原因が明らかにつれて私は焦った。 私の経験上、この場合知らなかったとはいえ、実作業を行った私の責任になる。 そうなると、何故それをしたのか?何故こうしたのか?糾弾されると思い、社内の上役に説明するのが怖かった。

説明を終えると上役の方は言った。 「貧乏くじではない。これはチャンスだ!」

そう私は、自分の保身に走り見えていなかった。 もっと視野を広げると、今まで分かっていなかったことが明らかになり、今後ビジネスを進めるうえで、一歩進めることが出来ると。 また、今までそう言われたことがなく保身しか考えていなかった、自分が恥ずかしくなった。

そう言った激励もあり、最高の同僚の助けも借り、見事復旧出来た。 最低の体験だと思ったけど、最高の体験ができとてもよかった。

デュアルキーボードを始めた

周りでセパレート型のキーボードがこっそり流行り始めたので、波にのるべくデュアルキーボードで擬似セパレートキーボードを始めた。

とりあえずわかったことは、ブラインドタッチが下手だということ。 擬似セパレートにしたことで、ホームポジションから正しい指でキータイプしないと意図した入力ができない…。 いつもは無意識にオレオレタイピングだったんだろうなぁっと。

セパレートにしたことで、肩幅が広がって猫背が矯正される、らしい。 が、あまり視力がよくなく前屈みになってしまって意味ねーなー感。。

1週間試してみて、良さそうなら左側も有線モデルに買い替えよう。 電池切れで左側だけ使えないのは悲しすぎるので…

iTerm2+tmuxでエスケープシーケンスを使ったクリップボードコピーがいい感じになっていた

tmuxで set-option -g set-clipboard on を設定して、iTerm2の設定からApplications in terminal may access clipboardを有効にするとエスケープシーケンス(OSC52)を使ってクリップボードにコピーされる。 …が、700byteくらいでコピーした内容が途切れてしまうので、pbcopyやrpbcopy を使って回避していた。

いつのまにか途切れなくなっていた

今日iTerm2周りの設定を見直しているときに、久しぶりにset-option -g set-clipboard onしたらなんと 700byte以上コピーできている!!!

$ pbpaste |wc -c
144108

リモートのtmuxでもコピーできるのでとても便利だ!(だけど、なんかやたら遅い…)。 また、私はローカルでもtmuxを使っているので、リモートでtmuxを起動するとtmux on tmuxになる。 それでも、よしなにクリップボードコピーされるのでとても便利なのであった。

おまけ

set-option -g terminal-overrides ',xterm*:Ms=\EPtmux;\E\E]52;%p1%s;%p2%s\007\E\\'

こんな感じでハックするとtmux on tmuxでもOSC52をうまく扱えるのだ!!!! っという記事にしようと思ったのだけど set-option -g set-clipboard on だけでいい感じに動いてしまったのでお蔵入り…