前回はOpenStack Octaviaの概要を説明したので、今回はLoadBalancer(LB)が作られたときにOpenStack Octaviaがどのような動作をするか説明したい。 なお、LBの更新や破棄、PoolやListenerなどなどの操作については、今回説明する内容とほとんど同じであるため説明を省略する。
基本構成
基本構成は前回説明したものと同じ。 neutronとnovaがあり*1、Octaviaが単独のノードとして存在する。 Octaviaはneutron LBaaSのバックエンドととして動作するように設定されている。
1. neutron LBaaS APIが叩かれるとOctaviaに通知が行く
クライアントから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インスタンスを作成する
Octaviaは、nova APIを使用しLBインスタンスを作成する。 nova APIを叩いたあと、インスタンスが起動したことを確認するため、LBインスタンスに定期的に通信を行う。
3. VIPポートの作成と設定
LBインスタンス用のVIPを作成するために、neutronへポート作成要求を行う。 そして、各LBインスタンスでVIP宛の通信を受信できるように、allow-address-parisの設定を行う。
LBインスタンスでは、agentが起動していてこちらもREST APIインターフェイスを持っている。 このインターフェイスを通し、作成したVIPのアドレスを、LBインスタンスに通知する。
4. 定期的にチェックする
Octaviaは定期的にLBインスタンスの死活監視を行う。 LBインスタンスの応答がない場合、インスタンスを破棄し新たにLBインスタンスを作成する。
おわりに
ここまでがOpenStack Octaviaの挙動の説明になる。 OctaviaはnovaやneutronのAPIを叩くだけであり、直接インスタンスやプロセスの作成やネットワークを設定するようなことはしない。 また、neutronとは独立したDBを持っているために、実はOctaviaはneutronとも疎な関係にある。 ココラヘンの話は次回以降にしたいと思う。
前回は社内説明用にGoogle Appsの図形描画で書いていた。 今回の記事を書くために draw.io を使って書き直したのだが、レイヤーが使えてとても便利であった。 図形情報の保存先がローカル以外にも複数のクラウドストレージが選べるのもポイントが高い…！ もう今後はネットワーク図を書くときはdraw.ioを使おうっと思った次第。
