OpenStackネットワーク実装の現状と運用自動化開発の実際第二部:運用自動化開発の実際 – OpenStack最新情報セミナー 2015年7月

2015/7/22
ユニアデックス株式会社
佐々木智一
OpenStack最新情報セミナー(2015年7月)
夜の部『OpenStack+SDN最新動向』
OpenStackネットワーク実装の
現状と運用自動化開発の実際
0
第二部：運用自動化開発の実際

Copyright©2015 UNIADEX, Ltd. All rights reserved.
アジェンダ
自己紹介
運用自動化に注目する理由
ブルー・グリーン・デプロイメント（BGD）とは
BGDをOpenStack上で実現する方法
BGDを開発するにあたっての技術的苦労
1

自己紹介：佐々木について
2
ソフトウェア開発業務
›Javaメインに自社IP電話関連のプロダクト等
›SDN歴約２年, OpenStack歴1年半
趣味
›バックカントリースキー：過去
›家事全般 ←今ココ
›子供，料理，掃除，洗濯
›日曜大工

IKEA歴
3

Copyright©2015 UNIADEX, Ltd. All rights reserved. 4
なぜ運用自動化に
注目しているのか

なぜ，運用自動化に注目しているのか
 時代はスピードを求めている
›ビジネスにおけるスピードの要求
›ソフトウェア開発：XP，アジャイル，リーン，スクラム
 運用は手順書＋手作業．スピードとは逆を行く
›手順書を作る，手順書を維持する
›手作業で運用する．手作業で確かめる．
›確実性を担保するために，2人でダブルチェックする
›それでも失敗して，リカバリのためにタイムロス
 手順書＋手作業から，自動化へのパラダイムシフト
›運用はコンピュータにより自動化
›人は本来すべきことに集中する
 運用自動化の一つの要素に着目
「ブルー・グリーン・デプロイメント（BGD）」
5

運用自動化の一つとしてBGDに着目
ブルーグリーンデプロイメントは１つの構成要素
›ソフトウェア開発のリリースにおいて利用可能な手法
6
継続的デリバリー（CD）
Dev
開発者
Ops
運用者
Deploy Monitor Recovery
Assessme
nt
incident
Canary
Release
DevOps
継続的インテグレーション
Develop
SCM
/ ITS
Build Provision Configure Deploy Test Release
BGD

ブルー・グリーンデプロイメント
（BGD）とは
https://www.flickr.com/photos/m-louis/14096661038/

ブルー・グリーン・デプロイメント３行で
Webシステムのリリースを
２つの本番環境を使って
安全に素早く行う
8

BGD ビフォーアフター
一般的なWebシステムのリリース
›リリースには頭の痛い課題が山積み
9
検証・開発
WEB
AP
DB
本番系
WEB
AP
DB
一発勝負！
で移行する
テストに時間を
さけないので自
身を持ってリ
リースできない
本番へ反映漏
れたパッチ
切り戻し手順
に不備があっ
て二次災害！
計画停止は
機会損失
移行計画作る
の面倒
実は本番と異な
るバージョン
本番止められない
から検証系を準備
検証系と同じよ
うなテストをま
たやるのか・・
ディスクが足り
ないからデータ
移行テスト不可

BGD ビフォーアフター
ブルー・グリーン・デプロイメント
›２つの本番系を切り替えるが特徴
10
Green系
WEB
AP
グリーン系
新機能テスト
Blue系
WEB
AP
DB
ブルー系
本番
本番系を交
互に切替
バックエン
ド共用
十分に時間
をかけてテ
ストできる
本番と同じ
環境を保証
テスト済み環境
をそのまま本番
投入できる
暖機運転
済み！
旧本番へ切
り戻すこと
も可能

ブルー・グリーン・デプロイメントとは
 BlueとGreen２つの本番環境を準備し、RouterやLoad
Balancerで切り替えることで新しいバージョンをデプロイ
›Blue系で本番中、Green系で新しいバージョンのデプロイとテスト
11
http://martinfowler.com/bliki/BlueGreenDeployment.html
Martin Fowler
2010年3月
 Amazon.comではWebフロントエンドを1時間に最大1000
回デプロイする
›AWS re:invent 2012 keynote day 2 にて「クラウドネイティブな
デプロイ」という BGD と同様な手法が紹介された。(*2014では１時間あたり5700回とも）

BGDをOpenStack上に
実現する方法
https://www.flickr.com/photos/96dpi/3227807209/

OpenStackに組み込んだBGD
運用者の切り替え操作で本番系が入れ替わる
13
運用者が
切り替え操作
クライアント
クライアントの
接続先切替

BGDデモムービー
14

BGDを実現する方法
OpenStackの仮想環境でBGDを構成
15
HAProxy版

Blue, Greenの仮想ネットワークを準備
16
HAProxy版

外部からの接続の様子
17
Green系N/W Blue系N/W
外部N/W
L/B
L/Bクライアント
仮想ルータ
仮想マシン
Webサーバ
仮想マシン
Webサーバ
HAProxy版

仮想
ルーター
Floating IPを切り替えている（これだけ）
18
外部ネットワーク
I/F
I/F
FIP
I/F
FIP
L/B
ブルー系
L/B
グリーン系

Floating IPによる切り替えとした理由
 例えばLoad Balancer（L/B）のみで切り替える場合
切り替えタイミングに課題がある
›ブルー系とグリーン系に同時アクセス，またはどちらにもアク
セス出来ない時間が発生する
›ヘルスチェック機構の特徴からグリーン系がオンラインになる
ジャストなタイミングを決めにくい
19
L/B
Web101
Web102
Web201
Web202
現本番の
ブルー系
切り替えのた
めに追加した
グリーン系
ヘルスチェッ
クで１０から
１５秒後にオ
ンライン
LBのヘルスチェック機構
• ５秒毎にHTTP
• ３回連続成功したら
オンライン
• ３回連続失敗したら
オフライン

Floating IPによる切り替えとした理由
切り替えタイミング以外の理由
›リリース直前にL/Bの設定を変更することがリスク
›グリーン系がオンラインになった頃合いにブルー系を除外する
›L/B自体のテストができない
›BGDなら，L/Bの設定変更も含めて安全に行える
（少し寄り道）ちなみにAWSでのBGD
›Elastic IPをElastic Load Balancerに付与できないという
制限があって，同じ構成を取れない
›L/Bでの切り替えは前述のタイミング問題
›DNSは浸透するタイミングを制御できない
›もう少し複雑な方法もあるようですが・・・
20

BGDで利用しているOpenStackの機能
1. Heat
›インスタンス起動等の自動化機構
›オートスケーリング
2. Neutron LBaaS
›Load Balancer as a Service
›インスタンスから利用可能なロードバランサを構成
›Heatから自動構成
3. Horizon（管理画面）への独自画面組み込み
›一定のルールに従って画面組み込みが可能な仕組み
21

(1) OpenStack Heat
OpenStackの各種操作を自動化するための仕組み
22
Before After
• 自動構成
• Webサーバーの起動とセットアップ
• LB構成と外部からの接続設定
• オートスケーリング

Heat自動構成のデモムービー
23

Heatの設定の様子（HOT）
HOTに設定記述
(Heat Orchestration Template）
Load Balancerの設定
オートスケーリング対象
インスタンスの自動起動
設定（別ファイル）
オートスケールを実行す
る条件
24

(2) OpenStack Neutron LBaaS
 インスタンスが利用可能なロードバランサを構成できる
›プール，メンバー，バーチャルIP，ヘルスモニタを設定
 複数のプロバイダ（ロードバランサ）に対応
›HAProxyがデフォルト．ドライバにより商用L/Bも対応
25
プール
メンバ
VIP
ヘルスモニタ
メンバ
プロバイダ
サブネット
ロードバランス方法
メンバモニタ方法
タイムアウト
リトライ数
バーチャルIP
プロトコル・ポート
パーシステンス
IP・ポート
ウェイト

Load
Balancer
OpenStack Neutron LBaaS
画面操作後のLBaaSの動き
26
Neutron
LBaaS Driver
HAProxy
LBaaS Driver
A10
vThunder
HAProxy
@ネットワーク
ノード
LBaaS
neutron-lbaas.conf
provider=“xxxx.A10”
プール
メンバー
VIP
モニタを登録
REST API
CLI
（プロセス起動）
Horizon
管理画面
Agent

LBaaS HAProxyの内側
 LBaaS by HAProxyの内部ネットワーク構成
› ネットワークノード
› インターフェース，ブリッジ，ネームスペース，プロセス
27
br-ex
br-int
NS:qlbaas-xxxx
if: tap-xxx
proc: HAProxy
NS: qrouter-xxxx
2
if: qr-xxx
if: qg-xxx
br-eth0
NS: qdhcp-xxxx
if: tap-xxx
proc: dnsmasq
2 2
外部ネット
ワークへ
コンピュート
ノードへ
テナントごとに1組
LBDHCP
仮想ルーター
VLAN ID

(3) OpenStack Horizonで独自画面
独自画面の作成のチュートリアルが公式に存在
› http://docs.openstack.org/developer/horizon/topics/tutorial.html
Horizonはダッシュボードとパネルの集まり
›ダッシュボード内には複数のパネルが定義
›パネルの中には，部品としてのタブページや，表組み
ボタン押下時のアクションなどを定義する．
28
メニュー
組み込まれて
いるダッシュ
ボードとパネ
ルから生成
一枚の
パネル
ボタンに対する
アクション
表組み

BGDをOpenStack上で
開発するにあたっての
技術的苦労
https://www.flickr.com/photos/hugo90/4455412652/

苦労話のおしながき
1. 素のNeutronとSDNなNeutronの違いで苦労
2. BGDの切り替えが上手く行かなくて苦労
3. LBaaSカスタムの話
4. Horizonカスタムパネルの話
30

素のOpenStack環境で開発
Interop（６月）の少し前に基盤をSDN化
２つのBGD環境
31
Linuxサーバ内仮想NWBGD
商用SDNBGD+
実践的OpenStack環境
インフラ対応開発
素のOpenStack環境
制御対象
制御対象

BGD環境を構成する主なソフトウェア
OpenStack Juno
Nuage Virtual Service Platform 3.0
A10 vThunder 2.7.3
ユニアデックス独自 BGD
32
商用SDN
商用仮想LB

１．素のNeutronとSDNなNeutronの違いで苦労
Nuage VSP 3.0 をSDN基盤とした場合
ネットワークノードの有無
›SDN製品ではSPOFやボトルネックになるネットワークノ
ードを排除するものがある．Nuage VSPはその一つ
›LBaaSのデフォルトL/B（HAProxy）はネットワークノー
ドで動くので，Nuageでは別のL/Bを利用する
›A10 vThunderを採用して回避
外部ネットワークへのアクセス可否
›NuageではFloating IPを持つインスタンスだけが，外部
ネットワークにアクセス可能
Floating IPの内部実装の違い
›NuageではL/BのVIPにFloating IPを割り当てられない
33

SDN基盤上のOpenStackでのBGD環境
Nuage VSP 3.0＋A10 vThunder LBaaS＋Heat
オートスケーリング＋Uniadex BGD
34
どうしてこうなった？
Before After素のNeutron SDNなNeutron

SDN基盤上のOpenStackでのBGD環境
 外部からの接続の様子
35
Green系内部N/W
Blue系内部N/W
外部N/W
クライアント
仮想ルータ
仮想マシン
Webサーバ
仮想マシン
Webサーバ
vThunder版
Blue系外部N/WGreen系外部N/W
LBマネジメントN/W
G系L/B
フォワードプロキシ
リバースプロキシ
B系L/B
フォワードプロキシ
リバースプロキシ

どうしてこうなったの理由
vThunderは3つのセグメントを要求
• マネジメント，外部セグメント，内部セグメント
• インスタンスのNICを上の順番で割り当てる必要あり
Nuage VSPの制限回避のために，プロキシが必要
• ２つの制限は次期バージョンで改善される予定
• ロードバランサのVIPにFloating IPを設定できないた
め，リバースプロキシに割り当てている
• ロードバランサにプロキシ先が向いている
• Floating IPを持たないと外部ネットワークに接続でき
ないため，Webサーバーインスタンスがapt-get時に，
フォワードプロキシとして指定する．
36

 （細かい・・）内部セグメントが仮想ルーターに接続して
いる理由
37
仮想ルータ
仮想マシン
Webサーバ
B系L/B

1. Webサーバー起動直後のデフ
ォルトGWは仮想ルーター
2. Cloud-initは仮想ルーター経
由で起動後に実行するスクリ
プトをmetadataより取得
3. スクリプト実行の序盤でデフ
ォルトGWをL/Bに向ける
4. apt-get installの時は，L/Bの
先にあるフォワードプロキシ
を経由する
38
内部セグメントが仮想Routerに接続している理由
はCloud-init．Heatが依存

２．BGDの切り替えが上手く行かなかくて苦労
素のNeutronでHAProxyを使ったLBaaSでNG
›頻繁にHTTPリクエストを行うと，いつまでも切り替えが
発生しない
HAProxyで「HTTP Keep Alive 有効」が原因
›TCPセッションを使いまわすのでiptablesのNATテーブル
の変更が反映しなかった
›サーバー側が遊んでしまう可能性があるので，Keep Alive
を無効にするという見解もある
対処
›設定ファイルでKeep Aliveを無効にできず，ソースコード
を修正して対応
39

HTTP Keep Alive 少しだけ
 HTTP Keep Alive：RFC 2616（HTTP 1.1）
›TCPのコネクション確立処理を削減する．使い回し
›サーバー側が遊んでしまう可能性がある
› タイムアウト待ちの接続が残り，最大同時接続数に達しているため受付
不可の状態が発生する．apache2.2 以前
› apache2.4：httpsはNG．event mpm かつ http通信の場合は問題にならない
40
Client Server
TCPコネクション確立
HTTPリクエスト
・レスポンス
HTTPリクエスト
・レスポンス
Server
TCPコネクション（使用中）
TCPコネクション（使用中）
TCPコネクション（待ち）
TCPコネクション（待ち）
最大同時
接続=4
TCPコネクション確立
使い
回し
新規受
付不可

Floating IPの実現方法の違い
 素のNeutron: iptablesのNAT変換
›TCPセッションが確立されていればそのまま通信続行
›BGDの切り替え時に両系アクセスの可能性があり注意
 Nuage: openflow flow entry
›コンピュートノード上の仮想スイッチのflow entryでMACやIP
を書き換えている
› NuageがOpen vSwitchをベースにカスタムした仮想スイッチ
›TCPセッションの途中でも強制的にフローが切り替わる
› 切り替わった先でTCPセッションをResetされる動き
41
[root@vrs1 ~]# ovs-ofctl dump-flows alubr0
ALUXST_FLOW reply (xid=0x2):
・・・・
cookie=0x2, duration=270.453s, table=13, n_packets=0, n_bytes=0, hard_timeout=1, flags:0x5c0
priority=0,vrf_id=0x4f47,ip,nw_dst=111.1.1.2
actions=mod_nw_dst:10.100.1.3,set_vrf_id:0x4e21,resubmit(,13)
フローエントリの一部抜粋
Floating IP=111.1.1.2， Fixed IP(内部）＝10.100.1.3

３．LBaaSのカスタム話
vThunderのLBaaSドライバはテナント内に１つ
だけ想定した作りであった
›テナント内に複数のLBインスタンスある場合，テナント
名をハッシュした結果から，いつも固定的にLBを選んで
しまう；いつもブルー系だけ設定されてしまう
ソースコードを改変して対応
›BGD対応のためにBlue系とGreen系をネーミングルール
的に特定して設定を反映させるようにした
Junoで開発したこのソースをKiloに持って行くと
そのままで動作した
›LBaaS APIのバージョニングによる効果？
42

４．Horizonカスタムパネルの話
Horizonのカスタムパネルは意外と作れる
›コントローラーノードが準備出来ている状態から３日ほど
でBGDのプロトタイプが完成した
›公式チュートリアル＋アルファ
›コントローラーノードを準備
›公式チュートリアルでひな形ができる．ひな形はテスト実行用環
境を備えている．Webサーバー内蔵のイメージ
›REST APIやそれをラップした内部ライブラリをHorizonのソース
コードから探して，使い方を学んで実装
Junoで作ったものを，Kiloに持って行ったらその
ままで動かない
›依存しているHorizon内部のAPIに引数が増えた
›カスタムパネルはリリースごとに修正が必要になる可能性
が
43

まとめ

まとめ
 OpenStackは壮大かつ未完の建造物に似て，実際に利
用するには様々な対応が必要になる
 OpenStackの弱点：ネットワークにSDN製品活用
 ビジネスにおけるスピードの要求を受けて，システム
の運用は自動化される必要がある
 OpenStackに運用自動化のとしてBGDを実装できる
 SDN製品を採用する際には，標準Neutronとの差異に
注意が必要
45
• ぜひユニアデックスにご相談ください！

OpenStackネットワーク実装の現状と運用自動化開発の実際第二部:運用自動化開発の実際 – OpenStack最新情報セミナー 2015年7月

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

Similar to OpenStackネットワーク実装の現状と運用自動化開発の実際第二部:運用自動化開発の実際 – OpenStack最新情報セミナー 2015年7月

Similar to OpenStackネットワーク実装の現状と運用自動化開発の実際第二部:運用自動化開発の実際 – OpenStack最新情報セミナー 2015年7月 (20)

More from VirtualTech Japan Inc.

More from VirtualTech Japan Inc. (20)

Recently uploaded

Recently uploaded (9)