Report of OpenStack Ops Meetup Palo Alto (in Japanese)

Copyright©2015 NTT corp. All Rights Reserved.
Ops Mid-cycle Meetup@Palo Alto
参加報告
2015/09/11
NTT ソフトウェアイノベーションセンタ
市原裕史

2Copyright©2015 NTT corp. All Rights Reserved.
市原裕史
• 所属
• NTT SIC 第三推進プロジェクト
• 年次
• 4年目
• OpenStack Developer
• メインはNeutron、サブでDevstack
• 技術: SDN/NFV中心
• LinuxconでDPDKの性能の発表
• Neutronへの機能提案
自己紹介
http://stackalytics.com/?module=neutron

• 会議の概要と参加目的
• ライトニングトーク
• High Availability 構成のOpenStackを実現する Matcha
• NTTグループのOpenStackユースケース
• DefCore
• OpenStack ネットワークのオペレーション
• その他のセッションでの所感等
アジェンダ

• 開催日時
• 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 概要

会場の様子

ライトニングトーク

• High Availability 構成のOpenStackを実現
• VMHAを実現
• 完全なスケーラビリティを持つ
• スライド:
http://www.slideshare.net/masahito12/matcha-
51836442
• フィードバック
• Matcha のアップグレード方法に関しての質問が多数
• Slide share の analytics によると、何故かベトナムからのア
クセスが 3 位
Matcha

• 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グループユースケース

• Ops会議中、DefCoreについて議論は特になかった
• Chris Hogeにランチ中に話をして分かったこと
• Tempestの実装の都合でパスしないテストケースがある。そう
いうテストはフラグが付いていて、無視してよい
• RefStack （http://refstack.net/）を使うことを推奨
• TempestのDefCore関連のテストだけ実行し、匿名で共有のため
のサイトにアップロードする機能もある。フラグについても分かり
やすく表示してくれる
• NTTの試験結果に興味があるということで、アカウントくれた
ら自分で試験してくれるとのこと
• 今後の進め方案
• RefStackを使って試験結果をコミュニティに共有
• 試験結果に問題がある場合、DefCore MLで議論を進める
• 東京サミットの時期までに2016.01版（2015.07の次）の草案が
出るので、無視すべきケースは指摘しておいたほうが良い
DefCore

ネットワークオペレーション
まずはおさらいから

• マルチテナント環境でユーザに仮想NWを提供する
• Neutronのコアリソース
• ネットワーク: 仮想的なL2ネットワーク（L2スイッチ）
• サブネット: ネットワークに設定するIPアドレス
• ポート: L2ネットワーク上のポート
• サービスプラグインで拡張可能なNeutronのリソース
• ルータ(Floating IP含む)
• ロードバランサ
• VPN
• ファイアウォール
Neutron 概要
L2スイッチ
仮想計算機
ルータ
VPN
ファイアウォール
ロードバランサ
テナントA テナントB

• 仮想ルータのHA機能
• 従来はフェイルオーバー時にリソース再作成を行っていたが再
作成に時間がかかり、通信断時間が延びるという欠点があった
• L3HA機能ではkeepalivedを使用、VRRPを用いて死活監視、
フェイルオーバー時に仮想IPアドレスをActからStbyへ移行
Neutron L3HA
VMVM
コンピュート
ノード
ネットワーク
ノード
Act
Router1
ネットワーク
ノード
Stby
Router1
Heartbeat
VMVM
コンピュート
ノード
ネットワーク
ノード
Act
Router1
ネットワーク
ノード
Act
Router1
障害仮想計算機
(VM)
フェイルオーバー前フェイルオーバー後

• 分散仮想ルータ機能
• すべての仮想ルータはネットワークノードに配置され、南北のト
ラヒックだけでなく東西のトラヒックもネットワークノードを経
由していたためボトルネックとなっていた
• コンピュートノードにルータを分散配置してボトルネックを解消
Neutron DVR
VMVMVM VM
コンピュート
ノード
コンピュート
ノード
ネットワーク
ノード
Router
Router
VMVMVM VM
コンピュート
ノード
コンピュート
ノード
ネットワーク
ノード
VPN
Firewall
Router Router
従来のルータモデル分散ルータモデル

• Neutron内部のコアリソースを管理するコアプラグイ
ン、その他のリソースを管理するサービスプラグインを
Neutronから外出しする
Neutron decomposed
ML2
NEC
VMware
Juniper
Arista
Brocade
Cisco
…
A10
vArmour
HAproxy
Arista
Brocade Cisco
…
コアプラグインサービスプラグイン
Neutron
L2スイッチ
ルータ
Juniper Contrailでルータ
とL2スイッチを提供
HAproxyでロード
バランサを提供
Neutron
A10
EmbranceHAproxy
NetScaler
Cisco OpenSwan
VPN
iptables vArmour
ファイアウォール
ML2NEC
VMware Juniper
Aristabrocade
Cisco …
Simple L2 / L3
Arista
Cisco
Brocade
ルータ
コアプラグイン

• NeutronのL3チームリーダーCarlがリモートで参加
• Carlが中心としてLサイクルで努力したが、オペレータ
が要求するものとズレがある
• Carlの想定は、L2セグメントでのIP管理からL3セグメントの管
理へ移行することだが、オペレータ側はIPアドレスの管理自体
をもっと柔軟にする大掛かりなリソース管理を想定していた
• 今後ユースケースを整理して議論を続けていく。この議
論で一番声が大きかったCalicoは独自にプラグインを
提供して対応
Large deployment

• 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

その他所感

• Logging & tools では実行力の弱さが課題
• Summit, meetup で共に Next Action が同じで前
に進めていない
• まとめよう -> リポジトリ作ろう -> 実行されず次の会合
• いわゆるノウハウの供給にあたるため、利害が一致して
いないように見える
• ツールがほしい人: まだ運用できていない
• ツールをあげれる人: すでに運用できているから問題なし
• ツールのグループをまとめたい人: 運用ノウハウをまとめて売
りたい
その他 Logging&tools 所感

• コンテナ
• 文脈：基盤構築のためであって、ユーザ向けサービスではない
• 24名程度がコンテナを使っていると手をあげた（多い）
• LXCが14名、Docker（もはやLXCを使ってない）が10名
• Kubernetesやmesosをこのレベルで使っている人はいない
• 気をつけるべきこと・はまったこと
• iscsiやneutronの一部はコンテナに入れると動かないから
baremetalにしないといけない
• RabbitMQがコンテナではなくホストOSのメモリサイズを基準に
確保するメモリの量を決めてしまう（コンテナ毎にメモリの上限を
設定して使いたいのだが）
• Post-copy migration
• 確実に終わるlive migrationとして注目されている
• 10名程度が注目していると手を上げた
• RabbitMQ
• 鎮火（炎上具合がキャンプファイアになった、と）
その他のセッションでの所感①

• Public Cloud@Large Deployment team
• OpenStackで実装すべきものに限らず、ユースケースと周辺を
含めた機能について情報交換していこう、という流れがある
• マルチテナントの隔離が十分ではない
• ドメイン名、イメージ名がglobalユニークでないといけない
• フォレンジックのためにVMやボリュームの保全
• 法律で必要
• OpenStackの外側ですべきか？
• Deployment
• Galera/replicationを使っている人は、会場の半分
• DCまたぎでGalera/replicationを使っている人は、3名挙手
• 回線を持っていて占有しているケースは、性能の問題なし
• Keystoneのデータだけ、かつ、fernet tokenを使っているケース
は、性能の問題なし
その他のセッションでの所感②

付録

• 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の課題

• メンテナ: Aaron Rosen, Chris Wright, Jeremy
Stribling, Justin Pettit, Ken Duda, Madhu
Venugopal, Martin Casado, Pankaj Thakkar,
Russell Bryant, Teemu Koponen
OVN(Open Virtual Network)

Report of OpenStack Ops Meetup Palo Alto (in Japanese)

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (8)

Similar to Report of OpenStack Ops Meetup Palo Alto (in Japanese)

Similar to Report of OpenStack Ops Meetup Palo Alto (in Japanese) (20)

Report of OpenStack Ops Meetup Palo Alto (in Japanese)