最近、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)の構成
上記の図がneutron LBaaS(haroxy backend)を用いた一般的な構成図である。 neutron LBaaS APIを叩きLBを作成すると、network node上にLBが作成される。 Floating IP(fip)はLBのVIPに紐付けているため、インターネットからのパケットはLBを通し、各インスタンスへロードバランスされる。 この構成の場合、必ず network node上にあるLBを介して通信するためここがボトルネックになりやすい*3。
それでは、Octaviaではどうなっているか見てもらおう。
OpenStack Octaviaの構成
Octavia用のノードが増えていることがわかる。 が、これはnetwork nodeと統合しても問題はない。 ここでは説明を簡単にするため分離している。
新しいノードが増えていること以外で、neutron LBaaSとの違いで大きい点は LBがcompute node上にあることだ。 LBを普通のインスタンスとして、compute node上に構築することでネットワークトラフィックをnetwork nodeに集中することを避けている。 また、MitakaのバージョンからはAct/Sby構成が取れるため、LBを作成すると自動的に冗長構成を取ることができる。
これが、neutron LBaaS(haproxy backend)と比べたときのOctaviaのメリットである。
長くなりそうなのでこの記事はここまで。 次回は、LB構築時のフローを紹介したい。
*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以外のバックエンドを使えば解決できるかもしれないが、が、環境がないため試していない
