report of openstack ops meetup palo alto (in japanese)
TRANSCRIPT
Copyright©2015 NTT corp. All Rights Reserved.
Ops Mid-cycle Meetup@Palo Alto参加報告
2015/09/11NTT ソフトウェアイノベーションセンタ
市原 裕史
2Copyright©2015 NTT corp. All Rights Reserved.
市原 裕史
• 所属• NTT SIC 第三推進プロジェクト
• 年次• 4 年目
• OpenStack Developer• メインは Neutron 、サブで Devstack
• 技術 : SDN/NFV 中心• Linuxcon で DPDK の性能の発表• Neutron への機能提案
自己紹介
http://stackalytics.com/?module=neutron
3Copyright©2015 NTT corp. All Rights Reserved.
• 会議の概要と参加目的
• ライトニングトーク• High Availability 構成の OpenStack を実現する Matcha• NTT グループの OpenStack ユースケース
• DefCore
• OpenStack ネットワークのオペレーション
• その他のセッションでの所感等
アジェンダ
4Copyright©2015 NTT corp. All Rights Reserved.
• 開催日時• 2015/9/18 – 2015/9/19
• 開催場所• Crown Plaza Hotel, Palo Alto, CA, USA
• 参加人数• 約 200 人 (2 日間合計 )
• 日本から 5 名、 EU から x 名、他は US 国内• 事前登録・約 300 人(参加費無料)
• 会議の Etherpad• https://etherpad.openstack.org/p/PAO-ops-meetup
• ソフトウェアイノベーションセンタからの参加• 市原裕史、室井雅人、市川俊一
OpsMeetup 概要
5Copyright©2015 NTT corp. All Rights Reserved.
会場の様子
6Copyright©2015 NTT corp. All Rights Reserved.
ライトニングトーク
7Copyright©2015 NTT corp. All Rights Reserved.
• High Availability 構成の OpenStack を実現• VMHA を実現• 完全なスケーラビリティを持つ• スライド :
http://www.slideshare.net/masahito12/matcha-51836442
• フィードバック• Matcha のアップグレード方法に関しての質問が多数• Slide share の analytics によると、何故かベトナムからの
アクセスが 3 位
Matcha
8Copyright©2015 NTT corp. All Rights Reserved.
• NTT レゾナントの OpenStack ユースケースの紹介• Icehouse バージョン、 400HV 、 4800 コア、 1700+VM• http://www.slideshare.net/toshikazu_org/openstack-
ops-meetup-palo-alto-lt
• フィードバック• CentOS6 上の OpenStack Juno/Kilo のパッケージング
問題GoDaddy の Kris Lindgren から、 GoDaddy (や CERN)
で行っている方法( Anvil : https://github.com/stackforge/anvil を使う+試行錯誤)を共有してもらえた。
• Foundation メンバからの反応Jonathan(CEO):NFV の User Story が欲しいAllison(Marketing 担当 ):Superuser ブログの記事にした
い
NTT グループユースケース
9Copyright©2015 NTT corp. All Rights Reserved.
• Ops 会議中、 DefCore について議論は特になかった• Chris Hoge にランチ中に話をして分かったこと
• Tempest の実装の都合でパスしないテストケースがある。そういうテストはフラグが付いていて、無視してよい
• RefStack ( http://refstack.net/)を使うことを推奨• Tempest の DefCore 関連のテストだけ実行し、匿名で共有のた
めのサイトにアップロードする機能もある。フラグについても分かりやすく表示してくれる
• NTT の試験結果に興味があるということで、アカウントくれたら自分で試験してくれるとのこと
• 今後の進め方案• RefStack を使って試験結果をコミュニティに共有• 試験結果に問題がある場合、 DefCore ML で議論を進める
• 東京サミットの時期までに 2016.01 版( 2015.07 の次)の草案が出るので、無視すべきケースは指摘しておいたほうが良い
DefCore
10Copyright©2015 NTT corp. All Rights Reserved.
ネットワークオペレーション
まずはおさらいから
11Copyright©2015 NTT corp. All Rights Reserved.
• マルチテナント環境でユーザに仮想 NW を提供する• Neutron のコアリソース
• ネットワーク : 仮想的な L2 ネットワーク( L2 スイッチ)• サブネット : ネットワークに設定する IP アドレス• ポート : L2 ネットワーク上のポート
• サービスプラグインで拡張可能な Neutron のリソース
• ルータ (Floating IP 含む )• ロードバランサ• VPN• ファイアウォール
Neutron 概要
L2 スイッチ
仮想計算機
ルータ
VPN ファイアウォール
ロードバランサ
テナント A テナント B
12Copyright©2015 NTT corp. All Rights Reserved.
• 仮想ルータの HA 機能• 従来はフェイルオーバー時にリソース再作成を行っていたが再
作成に時間がかかり、通信断時間が延びるという欠点があった• L3HA 機能では keepalived を使用、 VRRP を用いて死活監視、
フェイルオーバー時に仮想 IP アドレスを Act から Stby へ移行
Neutron L3HA
VMVM
コンピュートノード
ネットワークノード
ActRouter1
ネットワークノード
StbyRouter1Heartbeat
VMVM
コンピュートノード
ネットワークノード
ActRouter1
ネットワークノード
ActRouter1
障害仮想計算機(VM)
フェイルオーバー前 フェイルオーバー後
13Copyright©2015 NTT corp. All Rights Reserved.
• 分散仮想ルータ機能• すべての仮想ルータはネットワークノードに配置され、南北のト
ラヒックだけでなく東西のトラヒックもネットワークノードを経由していたためボトルネックとなっていた
• コンピュートノードにルータを分散配置してボトルネックを解消
Neutron DVR
VMVMVM VM
コンピュートノード
コンピュートノード
ネットワークノード
Router
Router
VMVMVM VM
コンピュートノード
コンピュートノード
ネットワークノード
VPN
Firewall
Router Router
従来のルータモデル 分散ルータモデル
14Copyright©2015 NTT corp. All Rights Reserved.
• Neutron 内部のコアリソースを管理するコアプラグイン、その他のリソースを管理するサービスプラグインを Neutron から外出しする
Neutron decomposed
ML2NEC
VMwareJuniper
AristaBrocade
Cisco…
A10
vArmourHAproxy
AristaBrocade Cisco
…
コアプラグインサービスプラグイン
Neutron
ロードバランサ
L2 スイッチ
ルータ
Juniper Contrail でルータと L2 スイッチを提供
HAproxy でロードバランサを提供
Neutron
A10EmbranceHAproxyNetScaler
ロードバランサ
Cisco OpenSwanVPN
iptables vArmourファイアウォール
ML2NECVMware Juniper
AristabrocadeCisco …
Simple L2 / L3
AristaCisco
Brocadeルータ
コアプラグイン
15Copyright©2015 NTT corp. All Rights Reserved.
• Neutron の L3 チームリーダー Carl がリモートで参加
• Carl が中心として L サイクルで努力したが、オペレータが要求するものとズレがある
• Carl の想定は、 L2 セグメントでの IP管理から L3 セグメントの管理へ移行することだが、オペレータ側は IP アドレスの管理自体をもっと柔軟にする大掛かりなリソース管理を想定していた
• 今後ユースケースを整理して議論を続けていく。この議論で一番声が大きかった Calico は独自にプラグインを提供して対応
Large deployment
16Copyright©2015 NTT corp. All Rights Reserved.
• Nova network• まだ使っているというアンケートには 2票• ほとんどのオペレータがすでに Neutron へ移行済み
• Segment model• FLAT 3票 /VLAN 6票 /VXLAN 7票 /Provider network 3 票
• OVS vs Linuxbridge• ML2 Linuxbridge 10票 /ML2 OVS 10票• SDN アプライアンスを使っているのは全体の 40%程度• Linuxbridge DVR を必要かどうかについては 7票
• Neutron HA & High scalability vs Manually• DVR 2票 /HA 1票。今後使いたいという人は 1, 2 人くらい• そもそも使っている人が少なすぎて issue も溜まっていない
Network Models
17Copyright©2015 NTT corp. All Rights Reserved.
その他 所感
18Copyright©2015 NTT corp. All Rights Reserved.
• Logging & tools では実行力の弱さが課題• Summit, meetup で共に Next Action が同じで前に進めていない
• まとめよう -> リポジトリ作ろう -> 実行されず次の会合• いわゆるノウハウの供給にあたるため、利害が一致していないように見える
• ツールがほしい人 : まだ運用できていない• ツールをあげれる人 : すでに運用できているから問題なし• ツールのグループをまとめたい人 : 運用ノウハウをまとめて売りたい
その他 Logging&tools 所感
19Copyright©2015 NTT corp. All Rights Reserved.
• コンテナ• 文脈:基盤構築のためであって、ユーザ向けサービスではない• 24 名程度がコンテナを使っていると手をあげた(多い)
• LXC が 14 名、 Docker (もはや LXC を使ってない)が 10 名• Kubernetes や mesos をこのレベルで使っている人はいない
• 気をつけるべきこと・はまったこと• iscsi や neutron の一部はコンテナに入れると動かないから
baremetal にしないといけない• RabbitMQ がコンテナではなくホスト OS のメモリサイズを基準
に確保するメモリの量を決めてしまう(コンテナ毎にメモリの上限を設定して使いたいのだが)
• Post-copy migration• 確実に終わる live migration として注目されている• 10 名程度が注目していると手を上げた
• RabbitMQ• 鎮火(炎上具合がキャンプファイアになった、と)
その他のセッションでの所感①
20Copyright©2015 NTT corp. All Rights Reserved.
• Public Cloud@Large Deployment team• OpenStack で実装すべきものに限らず、ユースケースと周辺
を含めた機能について情報交換していこう、という流れがある• マルチテナントの隔離が十分ではない
• ドメイン名、イメージ名が global ユニークでないといけない• フォレンジックのために VM やボリュームの保全
• 法律で必要• OpenStack の外側ですべきか?
• Deployment• Galera/replication を使っている人は、会場の半分• DC またぎで Galera/replication を使っている人は、 3 名挙手
• 回線を持っていて占有しているケースは、性能の問題なし• Keystone のデータだけ、かつ、 fernet token を使っている
ケースは、性能の問題なし
その他のセッションでの所感②
21Copyright©2015 NTT corp. All Rights Reserved.
付録
22Copyright©2015 NTT corp. All Rights Reserved.
• 2月ぐらいに話題になった問題• OVS のポートを namespace 間で移動させるとクラッシュす
る• 元々は OVS側の問題だが、 Neutron バグレポ (neutron/
+bug/1418097) では High が付けられ 4 日くらいで対応された
• 結局、 Kernel側にもすぐにパッチが当たって一応収束した
• この問題を発端に namespace を使うのをやめてOVS 機能をフル活用しようという議論に発展
• OVS+CT(Connection Tracking) による stateful firewall• OVS+OF(OpenFlow) による QoS• OF によるルーティングと OVS+CT による NAT• OVS ブリッジを分けずに 1 つに集約して高速化
• そもそも OVS の高機能化を必要としない人もいるなかでどれだけ取り組む価値があるのか
OVS の課題
23Copyright©2015 NTT corp. All Rights Reserved.
• メンテナ : Aaron Rosen, Chris Wright, Jeremy Stribling, Justin Pettit, Ken Duda, Madhu Venugopal, Martin Casado, Pankaj Thakkar, Russell Bryant, Teemu Koponen
OVN(Open Virtual Network)