openstackネットワーク実装の現状と運用自動化開発の実際...

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 RecoveryAssessme

ntincident

Canary

Release

DevOps

継続的インテグレーション

DevelopSCM/ 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サーバ


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

A10vThunder

HAProxy@ネットワーク

ノード

LBaaSneutron-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

クライアント

仮想ルータ



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

仮想ルータ


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 alubr0ALUXST_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.2actions=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


まとめ

https://www.flickr.com/photos/stewtopia/2073660077/


まとめ

OpenStackは壮大かつ未完の建造物に似て，実際に利用するには様々な対応が必要になる

OpenStackの弱点：ネットワークにSDN製品活用

ビジネスにおけるスピードの要求を受けて，システムの運用は自動化される必要がある

OpenStackに運用自動化のとしてBGDを実装できる

SDN製品を採用する際には，標準Neutronとの差異に注意が必要

45

• ぜひユニアデックスにご相談ください！

openstackネットワーク実装の 現状と運用自動化開発の実際...

Technology

openstackネットワーク実装の現状と運用自動化開発の実際...