ぶていのログでぶログ

思い出したが吉日

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の管理情報と齟齬がでるが、情報が二重管理になっているのでそれはそれで…というのもある。ここらへんについて次回触れたい