Octaviaの概要
Openstack Neutron ロードバランサーサービス

2017年５月
SCSK株式会社
R＆Dセンター 技術戦略部※本文中の会社名、商品名は、各社の商標及び登録商標です。

ロードバランサーサービスとはWebシステムにかかる負荷を複数のサーバに分散させ、処理のバランスを調整●

パフォーマンスと可用性を向上●

一般的には、ハードウェアで実現、負荷分散装置と呼べれている●

ソフトウェアでも実現可能●– HA Proxyなど

OctaviaとはOpenstackのNeutron LBaaSプロジェクトから派生したクラウド向けに最適化されたプロジェクト●

複数の仮想マシンを管理して柔軟な水平スケーリン
グなロードバランサーサービスを提供●

Neutron LBaaSv2 APIやCLIを使って管理●

Neutron LBaaSの置き換えではなく、NeutronLBaaSV2のプラグインである●

OctaviaのAPIもある●Octaviaの構成要素
HA Proxy●– フリーのソフトウェアロードバランサ– C言語で書かれていて、高速かつ信頼性が高い– TCP、HTTPベースアプリの要求を代理– Linux Kernel 2.4以上で利用可能

アンフォラ:●– ロードバランサーサービスを提供する仮想マシン– HA Proxyが中で動作– OSはUbuntu– バックエンドのネットワークとLBネットワーク上に配置– フロントエンドからのリクエストをバックエンドのサーバに分配– コントローラとLBネットワーク上で通信Octaviaの構成要素
LB（ロードバランサー） ネットワーク●–

コントローラとアンフォラが通信するネットワーク

コントローラ●–

LBネットワークとOpenstackのコンポーネントにアクセスできるデーモン–

Octaviaの全体を管理する４つのプロセスで構成されている

Octaviaドライバー●–

Neutron Lbaas APIをOctavia apiプロセスに渡すコンポーネント

VIP(Virtual IP Address):●–

ロードバランサーに紐付けている単体のIPアドレス–

フロントエンドからこのIPアドレスにアクセス–

HA構成では、VRRPを使って２台のアンフォラに紐付け

Octaviaのプロセス
APIコントローラ:●–

APIリクエストを処理するプロセス–

Osloメッセージを使ってコントローラワーカーに実行を依頼する

コントローラワーカー:●–

APIコントローラからの依頼を処理するプロセス–

LBネットワーク経由でアンフォラを操作する

ヘルスマネジャー:●–アンフォラを監視するプロセス–

アンフォラに異常がある場合、フェイルオーバー処理する

ハウスキーピングマネジャー:●–

古いDBレコードを削除するプロセス–

スペアのプールを管理

プロセス構成図

Octaviaのロードバランサ構成図
１つの仮想ロードバランサ

アンフォラ０１
HAProxy動作

Openstackの中LBネットワーク

バックエンドWebサーバ１

１つのVIP（VRRP)
アンフォラ０２
HAProxy動作

クライ
アント

APIコントローラ

コントローラワーカ

Webサーバ２

Webサーバ３

ヘルスマネジャー

管理者

データベース

ハウス
キーパー

仮想マシン

プロセス

OctaviaのDB構成の概念
プール：ロードバランサー経由のトラフィックを処理メンバーのグループ
メンバー：バックエンドサーバである。
１つのメンバーは１つのプールにのみ紐付けされる

Webサーバ１

DBのオブジェクト
リスナー：あるロードバランサーでトラフィックをリッスンするポート番号を定義したもの

リスナー８０

ロードバランサ：同
じロードバランサーに複数のリスナーを関連付けできます

ロードバランサ１

リスナー８０８０

Webサーバ３

ヘルスモニター：メンバーは時としてオフラインになることがあります。ヘルスモニターは、正常に応答していないメンバーにトラフィックが向かないようにします。ヘルスモニターはプールに関連付けされます。

Webサーバ４

ヘルスモニター１

Webサーバ５

ヘルスモニター２

Webサーバ２

HA Proxyができること
負荷分散機能を提供●

TCP接続のプロキシ、アクセス経路を設定●

HTTPリバースプロキシ機能、リクエストを別のサーバに渡す●

URLやヘッダの書き換え●

SSLやHTTP圧縮を肩代わり●

ロギング機能、ネットワーク上の観測点●

トラフィックのコントロール●

HA Proxyができないこと
キャッシュもしない●

bodyの書き換えもしない●

Webサーバではない●

IPやUDPといったパケットレベルのレイヤは見ない●Octaviaインストール
devstackでオールインワン環境で構築●

OS:Ubuntu16.04●

local.confに以下を追加し、stack.shを実行する●●

enable_service q-lbaasv2●

enable_service octavia●

enable_service o-cw●

enable_service o-hk●

enable_service o-hm●

enable_service o-api

●

●

●

enable_plugin neutron-lbaas https://github.com/openstack/neutron-lbaas.git
stable/ocata
enable_plugin octavia https://github.com/openstack/octavia.git
stable/ocataロードバランサーの作成
シナリオ– パブリックネットワーク、ルータを作成– プライベートネットワーク上にバックエンドのサーバ２つ作成（HTTPサービスを提供）– Neutron LBaaSV2のCLIを使用してOctaviaのロードバランシングサービスを設定– プライベートネットワーク上にロードバランサーを作成し、floating IPを使用してロードバランサーのVIPと紐付け、パブリック側からバックエンドのHTTPサービスにアクセスできるようにするネットワークとルータを作成
ルータを作成●– neutron router-create router1– neutron router-gateway-set router1 public– neutron router-interface-add router1

subnet=private-subnet

ネットワークとルータを作成
パブリックネットワークを作成●– neutron net-create public --router:external --provider:physical_network public -provider:network_type flat
– neutron subnet-create --name public-subnet --gateway 172.17.0.254 --allocation-poolstart=172.17.56.200,end=172.17.56.254 --dnsnameserver 172.18.1.10 --disable-dhcp public
172.17.0.0/16

ネットワークとルータを作成
プライベートネットワークを作成●– neutron net-create private --provider:network_type vxlan– neutron subnet-create --name private-subnet --gateway 10.0.0.1 --allocation-poolstart=10.0.0.2,end=10.0.0.254 --dns-nameserver
172.18.1.10 private 10.0.0.0/24

ネットワークとルータを作成
ルータを作成●– neutron router-create router1– neutron router-gateway-set router1 public– neutron router-interface-add router1

subnet=private-subnet

ロードバランサーサービス作成順番
ロードバランサーを作成●

リスナーを作成し、ロードバランサーに紐付け●

プールを作成（このときリスナーを参照）●

メンバーを作成して、プールに追加●

ヘルスモニターを作成●

Floating IPを作成し、VIPのポートに紐付け●ロードバランサーを作成– neutron lbaas-loadbalancer-create --name lb1

private-subnet

リスナーを作成– neutron lbaas-listener-create --name listener1 --loadbalancer lb1 --protocol HTTP --protocolport 80

プールを作成– neutron lbaas-pool-create --name pool1 --lb-algorithm ROUND_ROBIN --listener listener1 -protocol HTTP

メンバーを作成– neutron lbaas-member-create --subnet private-

subnet --address 10.0.0.6 --protocol-port 80
pool1

メンバーを作成– neutron lbaas-member-create --subnet private-

subnet --address 10.0.0.3 --protocol-port 80
pool1

ヘルスモニターを作成– lbaas-healthmonitor-create --delay 5 --max-retries 4 --timeout 10 --type HTTP --url_path /--pool pool1

Floating IPを作成– neutron floatingip-create publicFloating IPをVIPに紐付け– neutron floatingip-associate– 3dc47a3b-becb-4a93-9e18-1b3c9852186a– 6fd12458-1c0c-4d82-9023-6e65e9864ec7– 書式は floatingip-associate <floating_ip_id><load_balancer_vip_port_id>– これで外から172.17.56.206でロードバランサーにHTTPアクセスできる。

HA構成(ACTIVE-STANDBY)

●

シナリオ

●

– ロードバランサーサービスをHA構成で構築– 自動でマスターとスレーブのアンフォラを作成するように、octaviaのロードバランサートポロジーをactive-standbyに変更– （Octaviaのデフォルトの設定はstandalone)HA構成/etc/octavia/octavia.confを以下のように編集●loadbalancer_topology = ACTIVE_STANDBY●

コントロールワーカープロセスを再起動●

同様にロードバランサーを作成●

HA構成アンフォラが２つ作成されていることが確認できる●

HA構成ロードバランサーは１つ

●

HA構成

DBを覗くとどのアンフォラがマスターかスレーブを確認できる

HA構成 フェイルオーバー
マスターアンフォラが落ちた場合、スレーブアンフォラがマスターアンフォラになる●

落ちたマスターアンフォラのインスタンスが削除され、新しいアンフォラが自動的に作成され、その役割はスレーブである●

ただし、このときDB上のroleカラムが変更されることはない！

つまり、フェイルオーバーが起きた時に、DBのroleと実際のアンフォラの役割が逆となる！

どうすれば、本当の役割確認できるかアンフォラにログインして確認するしかない●

以下の方法でアンフォラにsshできる●– $ ssh -i /etc/octavia/.ssh/octavia_ssh_key– ubuntu@192.168.0.9– ログインした後、sudo ip netns exec amphora-haproxy ipaddrを実行すると、

どうすれば、本当の役割確認できるか– $ ssh -i /etc/octavia/.ssh/octavia_ssh_key– ubuntu@192.168.0.6– ログインした後、sudo ip netns exec amphora-haproxy ip addrを実行すると、– Inet 10.0.0.13/32 scope global eth1がない！
– ＝＞これはスレーブ