ぶていのログでぶログ

思い出したが吉日

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構築時のフローを紹介したい。

*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以外のバックエンドを使えば解決できるかもしれないが、が、環境がないため試していない