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

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

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

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

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

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

12. Copyright©2015 UNIADEX, Ltd. All rights reserved. ブルー・グリーン・デプロイメントとは  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回とも）

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

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

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

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

27. Copyright©2015 UNIADEX, Ltd. All rights reserved. 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

28. Copyright©2015 UNIADEX, Ltd. All rights reserved. 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

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

34. Copyright©2015 UNIADEX, Ltd. All rights reserved. １．素の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

36. Copyright©2015 UNIADEX, Ltd. All rights reserved. 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 フォワードプロキシリバースプロキシ

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

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

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

41. Copyright©2015 UNIADEX, Ltd. All rights reserved. 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コネクション確立使い回し新規受付不可

42. Copyright©2015 UNIADEX, Ltd. All rights reserved. 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

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

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

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

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

VirtualTech Japan Inc.