OpenStack Summit Tokyo 2015 報告 DAY1

OpenStack Summit および Mitaka Design Summit が10月27日から30日の日程で、東京港区のプリンスホテル高輪エリアで開催された。
会期中は会議室およびレストランが OpenStack 関係者にほぼ占有され、一般客はほとんど目にしなかった。
弊社からは小田、角馬、岩本、佐藤が参加し、Neutron および Ceph に関するセッションを中心に聴講した。

• 各セッションスケジュールについて
  各セッションの概要は OpenStack Summit スケジュールリストをご参照ください。
  • OpenStack Summit Tokyo 2015: https://openstacksummitoctober2015tokyo.sched.org/
  • Mitaka Design Summit: https://mitakadesignsummit.sched.org/
    

• Etherpad について
  本記事中に記述のある各プロジェクトの Etherpad は、以下URLをご参照ください。
  • Mitaka Etherpads: https://wiki.openstack.org/wiki/Design_Summit/Mitaka/Etherpads

• 各セッションについて
  キーノートや一般セッションは、ビデオが公開されているので、以下URLをご参照ください。
  • https://www.openstack.org/summit/tokyo-2015/videos/

• 文中表記について
  本文中のセッション名は、Main Conference と Mitaka Design Summit で色分けして表記しています。

大勢を収容できる会場がなかったため、キーノートはメイン会場の他にもいくつかの会場で行われた (それらの会場ではメイン会場を録画したものが上映された)。
参加者数は前回のバンクーバーには及ばないものの、5,000人以上であったようである。
今回で3回目となる Superuser 賞は、地元日本の NTTグループが受賞して壇上で喜びを表現していた。

Design Summit では主に開発者が今後の開発内容や方針について話し合う。いくつかのセッションは、前回 (または前々回) から続いている話題であり参加者もほぼ同じになるので、暗黙のうちに前回の知識が必要となることはある。なお、最近の恒例の nova-net migration のセッションは今回なかった。前回で議論は尽くされたということなのかもしれない (ただしget-me-a-network についてはまだ作業中)。

OpenStack Summit Keynote

報告者: 小田

• DefCore の話 (Egle Sigler 氏)
  相互運用性とか、OpenStackと言えるのはどういうものかを定義、認定しようという活動があるということのようだ。
• コミュニティの話で、各コンポーネントの成熟度に関する情報ページがあるということが言われていた。
  http://www.openstack.org/software/project-navigator
• Lithium (Lachlan Evenson 氏)
  コードの変更からデプロイまで簡単に自動的にできるデモを実施していた。
• Yahoo! Japan (Takuya Ito 氏)
  共通 API で、物理環境の違いを隠ぺいすることが重要。パートナーとの co-creating を行っていくということを言われていた。
• スーパユーザで NTT グループが栄冠。
  壇上には数十人の人が登り、大勢で喜びを表現していた。
• Bitnami (Erica Brescia 氏)
  ユーザが簡単に使えるようなものでないと使ってもらえないよ、という話。前の Lithium の話とも合わせ、そういうムーブメントが来ていると感じた。
• Intel (Imad Sousou 氏)
  OpenStack 開発者部隊を作ったり、Mirantis や他のクラウドプロバイダへの投資、キャリアグレード OpenStack への取り組みなど、かなり力を入れている様子が伺えた。CPU などハードが売れることにつながるロジックについては、私はよく分かっていないが。

OpenStack at NTT Resonant: Lessons Learned in Web infrastructure

報告者: 小田
レゾナントでの事例紹介。CentOS 6 上で、RDO Icehouse 版を使用して構築されている。
システム規模は、400 ハイパーバイザ、4,800コア、1,400 VM とのこと。VM の設定を、Puppet を使用して効率化しているのが特徴。監視システムについても話をされ、Zabbix と Redmine を使用しているとのこと。Zabbix で異常を検出すると、Redmine に自動的にチケットが切られるとのこと。その他、ログは Debug レベルにしているとか、ログを解析しやすくするための提案をしているなど、実運用者ならではの話もされていた。

Cross Project workshops: Establishing key themes for the Mitaka cycle

報告者: 岩本
Mitaka サイクルではどのようなテーマを重視しようかと話すセッションである。Rolling Upgrade (クラウドを動かしたままアップグレードする) が重要であるという意見多数であった。この Upgrade については別のセッションでも扱われ、Nova でがんばって動くようにしたので他のプロジェクトも見習ってやるようにといった主旨のことが話されていた。

他に Technical Debt (バグが解決されないまま残っている事態をかっこよく表現したもの) を減らすことに労力を集中させるべきだという意見や、それに関連して Gate bug をみんなが直せるように開発者を教育するべきだという意見がでていた。これは、サミット後にメーリングリストで話題となり、具体的なバグの修正方法に関して、以下のメールから辿れるプレゼン資料などが参考になる。
http://lists.openstack.org/pipermail/openstack-dev/2015-November/078320.html

エンタープライズ適用に向けた、ネットワークログ採取の課題と取組み

報告者: 角馬
Firewall の挙動に関連するログ採取についての機能追加。
iptables/rsyslogd + ulogd2 と言う構成でログを rsyslogd に出力。log はテナント毎にファイルを分割。主に以下のログ情報を採取。

• tenant-id
• log-level
• resource (firewall-rule, security-group-rule)
• event(allow, deny 等)

ログの採取有無をフラグで判定。ログの影響を見る為 FW/SG rule 2, 100, 500 時の性能を測定。

• スループットにはほとんど影響なし。
• CPU 使用率は 3-4% 上昇。1,000 rule でも 4%

総合的には問題ないと判断

今後

• Mitaka で実装をマージ
• 他のリソースにも展開
• 採取ログをチェックできるツールの作成

Blueprint があり実装は以下から。
https://blueprints.launchpad.net/neutron/+spec/security-group-logging
https://review.openstack.org/#/c/203509/
ログを取るのは良いが、解析が面倒なので、ツールがあると便利。

OVN: Feature Complete and Ready to Test

報告者: 小田
Neutronでよく知られている、Russell, Kyle そして OVS で有名な Ben が話すということで聴講しにいった。OVN の最近の状況の話。私的には特に目新しい話はなかった。

• securitygroup実装中。conntrack使用。
• L3の実装を進めている。l3-agentを使用せず、独自に実装。
  – ipv4, ipv6 native support – ARP/ND suppressing – Flow chacing – distributed
• DHCP, NAT, SFC, LB
• Gateway

マルチハイパバイザ環境の実現に向けた構築ノウハウと課題の共有

報告者: 角馬
背景として、当初 VMware 導入により移行した仮想サーバの台数が増え管理コストが上昇してきたため、コストを下げたいという理由から OpenStack を導入したと話されていた。Web/AP 層を KVM、VMware、DB 層をベアメタルと言う構成のモデル環境で検証したとのこと。以下の問題点を挙げていた。

• VMイメージファイルを仮想マシン用、ベアメタル用各々に用意が必要
  – 容量はハイパーバイザ分必要になる。
  – ユーザのイメージの選択ミスの懸念がある。
• 仮想/物理マシンでネットワーク環境の見え方が異なる
• openstack で検知できない障害
  – 冗長化したネットワークの片パスの障害
  – サービスの監視
• インスタンスの初回起動時に時間が掛かる

CTC (ITOCHU Techno-Solutions) – Japan’s OpenStack Market Potential:How to be Successful in the Cloud – 日本のOpenStack市場の状況と、成功のためのアプローチ

報告者: 佐藤
OpenStack システムの SI パートナー 、Solinea 社の紹介 (サポートはスコープ外？) と、今のところ OpenStack にあまり関心のない日本のユーザ層に OpenStack の POC を促す取り組みの紹介。OCP や Ceph の話はなかった。

10GbE and beyond – SR-IOV, VxLAN, OVS, DPDK, Ceph and what to expect NEXT

報告者: 角馬
QLogic 製品が Openstack の性能改善に役立つというアピール。2015年、Kilo 版から Openstack の Corporate Sponsorとなり、Kilo で SR-IOV/VXLAN offloads をサポートしている。

• Nova
  SR-IOV 10G I/O(PCI Passthrough)による VNFs、Docker Contaainer の高速化
• Neutron
  VXLAN offload, DPDK
• Cinder/Swift
  Qlogic iSCSI/FC SSD キャッシュによる Ceph の高パフォーマンス化。iSCSI offload, FC-QoS, FC provisioning

報告者: 佐藤
QLogic社ネットワーク製品によるOpenStack/Cephシステム高速化の紹介。SRIOVポート、VXLANオフロード、iSCSIオフロード、 DPDK、iSER (iSCSI RDMA) 等

Dragonflow – Neutron done the SDN Way

報告者: 角馬
日本発の OpenFlow コントローラソフト Ryu を使っていると言うので見に行ったが、特に触れられなかった。分散型 SDN。Neutron Server 上に Dragonflow plugin があり、各 Computer node 上に Dragonflow controller がある。

• Distributed L3 Virtual Router
  説明なし
• Distributed HDCP
  Controller 内の DHCP App が VM と直接やり取り。
• Pluggable distributed DB
  ETCD, RethinkDB, RAMCloud, OVSDB が扱える。

Fuel Plugin for ScaleIO

報告者: 佐藤
ScaleIOで Cinder を構成するための Fuel プラグインの紹介。

Managing Inventory with OpenStack Ironic

報告者: 佐藤
Ironic でインベントリ管理できるように開発しようという話。動作デモ (ムービー) が Mac で再生できずイメージが掴めなかった。

OSSで作るOpenStackの監視システム

報告者: 角馬
OpenStack の log を下記のツールと組み合わせてモニタリング

• log検索 – elasticsearch
• log収集 – fluentd
• log視覚化 – kibana
• log解析 – norikra
• 監視 – zabix

特定のログパターンをチェックして通知してくれる様に登録する事で、OpenStack の熟練者でなくとも監視ができる様にするとの事。

Boosting the Power of Swift Using Metadata Search

報告者: 佐藤
Swift のオブジェクトにメタデータを付与し、メタデータでオブジェクト群を扱う API を追加する話。SoftLayer 上で Spark SQL から使用できる。IoTデータ、Kibana、OpenStack Searchlight 用途。将来はファイル (NFS/SMB) にも対象を拡げ、検索 API を標準化する計画とのこと。

OpenStackを利用したゲームサービスの実装

報告者: 小田
CTC の Rack の話ということで聴講。私もオンラインゲームを楽しんでいる関係上、興味があったということもある。日本人でぎゅうぎゅうの状態であったが、これは、日本語セッションというのも関係していたようだ。
Rack はライブラリで、VM を Linux でいうプロセスに見立て、VM の起動を fork のようにアプリから行えるようにしたもの。親子 VM 間の通信を IPC ライクにも行える。VM の起動順序やスケールアウト、スケールインを外部のシステム (ex. Ceilometer + Heat)　で制御するのではなく、アプリ自身が制御できるようにしようというもの。そのためのインタフェースを提供している。コンセプトとしては、なかなか面白いものを感じた。

Cross Project workshops: Python 3

報告者: 岩本
Python 2 系列は 2.7 で終わりであり、いずれ Python 3 系列に移行しなくてはいけないので、OpenStack も Python 3 に対応させていこうという話題であり、ここ数回の恒例のセッションである。
弊社からも角馬が Python 3 対応の貢献を行っている。セッションでは、Python 3 で functional test が動かせるようにするのが当面の目標であると語られていた。なお、Devstack で USE_PYTHON3 変数をチェックしてサービスを実際に Python 3 で動かすためのパッチは、サミット後もレビューが継続されてマージされた。

各プロジェクトの Python 3 対応状況は以下のページにまとめられている。ほとんど Python 3 Compatible と書かれているが、それは必ずしも実際に Python 3 で動くことを意味しないので注意が必要である。
https://wiki.openstack.org/wiki/Python3#Python_3_Status_of_OpenStack_projects

報告者: 角馬
予め議論する Agenda を Etherpad に上げておき、ディスカッションした結果を Etherpad にまとめながら進行していた。

　　目標はfunctional testをPython 3でも動かす事。

• Proposal
  Python 2, 3 混在環境の job を non-voting で追加する。job では USE_PYTHON3 を有効に。リポジトリで PYTHON3_VERSION にマッチする classifier を追加。
• Distro Support
  Distro のサポート状況は以下ページの通り
  https://wiki.openstack.org/wiki/Python3#Status_of_Python_3_in_Linux_distributions
  (開発は 3.4 ベースで行っているので) Debian 系は 3.5 になるみたいだが、どうしようとか言うような事を議論。
• Tasks
  Devstack を Python 3 で使えるようにする。https://review.openstack.org/#/c/181165/
  全プロジェクトで mysql+pymysql:// の DSN を使用

※ チャットで:
この前見た時には Ubuntu trusty の Python 3.4 は壊れていたとか言っている。(Bug Report 済み)
Debian jessie の 3.4 は大丈夫らしい。RedHat 系は Python 3 はまだ未提供だが SCL (Software Collections) を使うとインストールできるらしい (但し Python 3.3)

Cross Project workshops: Distributed Lock manager in OpenStack

報告者: 岩本
OpenStack 全体で標準的に使える DLM を用意しようという話である。背景として、さまざまな OpenStack プロジェクトが分散ロックマネージャを必要としているが、標準で使えるものがないので DB ロックで代用しているという事情がある。特に議題とはならなかったが、どのプロジェクトがどういう理由で DLM を必要としているかは Etherpad に書かれている。

DLM の利点として、通信障害が起きた時の動作を改善できるはずである。セッションでは、具体的にどれを使うかといったことや、DLM への移行手順はどうするかなどが話されていた。結論としては、tooz という DLM の Python ラッパーのようなものを開発してそれを標準にするということになった。サミット後のメーリングリストの議論において、tooz の標準ドライバが zookeeper になることについて、zookeeper が Java で書かれているため反対論がいくつかあったが、この方針は変わらないようである。

EMC- Battle of the Titans: Real-time Demonstration of Ceph vs. ScaleIO Performance for Block Storage

報告者: 佐藤
ブロック I/F で使用するなら Ceph のオブジェクト層はオーバヘッドであるという主張と、Scale IO の方が優れているというベンチマーク実演デモ。途中からは比較方法に関する質問と回答のやり取りが続いた。

Neutron and BGP Dynamic Routing

報告者: 小田
なかなか実装の進んでいない BGP の話。継続して実装していく意思があることは確認できた。

40Gbit Ethernet Networkを利用した Open-Source Hyper-Converged OpenStack への取り組み

報告者: 佐藤
OpenStack / Ceph のシステムを Mellanox の40GbE ネットワークで高速化しかつ構成をシンプルにする POCの紹介。計算ノードが Ceph OSD ノードを兼ねる構成で、ストレージ媒体は全て PCIe SSD。VXLANオフロード、RDMA (Ceph Xio) を使ってワイヤスピードに近づける取り組みを続けている。DPDKの使用はこれから。

報告者: 角馬
40Gbit Ethernet Network を使用し、以下を目標に Openstack 環境を構築

• 容易に構築できること
  シンプルなシステム構成 (1Userver: ここでは HP DL360 Gen9, 2switch, Ceph cluster)
• 高パフォーマンス
  40Gbit/50Gbit switch, PCIe SSD (Ceph journal用)
• 情報の共有
  Juju/MAAS ツールによるデプロイ

性能測定

• Network
  – 2物理ノード上の VM 間
  – 1-16 VM/node
  – iperf3 で計測
• Storage
  – 1-4 VM/node, 1-4node
  – fio(8k 100jobs)で計測

結果は余りぱっとしないので、ボトルネック解消案として以下の対処

• Network パフォーマンス改善
  vxlan offload, DPDK
• Ceph パフォーマンスの改善
  Ceph RDMA (まだ experimental 段階)

【Network パフォーマンス改善結果】
Bandwidth (GBits/sec)

<通常>

<VXLAN offload>

対策後は40Gbit network に対しかなり性能が出ている。16-16 の場合に下がっている理由は未調査。

【Ceph パフォーマンスの改善結果】
比較値が 1vm の時しかないので 1vmの場合のみ載せる。

<Bandwidth (8k MByte/sec)>

<IOPS(8k MByte/sec)>

こちらも3倍程度改善し効果がある。RDMA はまだ正式版ではないので注意。AP が RDMA API をサポートしている事も必要。資料は以下URLを参照されたい。
https://ceph.com/releases/v0-94-hammer-released/
http://tracker.ceph.com/projects/ceph/wiki/Accelio_RDMA_Messenger

Connecting the Dots with Neutron: Unifying Network Virtualization Between Containers and VMs

報告者: 小田
コンセプトとしては、VM、Container、ベアメタル の区別なく、統一的にネットワーク抽象化をしようではないかという話。ここでの話は、その中で、VMとContainerのみ。Docker の Libnetwork というネットワークを実装するためのライブラリで、Neutron 対応を行い、VM と Container で同じ (Neutron) ネットワークに繋いで通信するデモを見せていた。

Deploying and Operating an IPv6-Only Openstack Cloud

報告者: 佐藤
IPv6 環境で Devstack (Nova, Neutron, Glance, Keystone, Horizon, Open vSwitch, VXLAN, DVR) を動作させる話。

日本でのOpenStack、企業の導入状況と今後の活用予測

報告者: 角馬
着いた時には会場から人が溢れていて中に入れなかった。ドアの外からでは声も聞こえない。翻訳機を借りて日本語CHに合わせると何とか途中から聞けた。それも電波の受信エリアを外れると直ぐ聞こえなくなり途切れ途切れになる。

• アイティメディア エグゼクティブエディター 三木 泉 氏
  何せ日本は信頼性などの細かい所のチェックがあってビジネス展開に時間が掛かる。NEC では基調講演でも言っていたSuper Integrator を推し進めていると言う話。Fujitsu K5 では Paas 機能を提供。日本での活用事例として以下のゲストの話。
• DeNA 小野 篤司 氏
  AWS は高い。安く抑えたいスタート企業向き自動化ツールと組み合わせると良い。ホワイトボックススイッチで Cumulus Linux 使用と言っていた気がする。
  導入は自社員だけでオンプレミスで対応。自前で自社専用の OpenStack 相当のシステムを作っても複雑さは同じなので、それなら OSS を使ってコスト削減を図った。自前で全部作成するより良いし、メンテナンスの手間も削減した。最近のリリースではインストール、展開等の自前で導入する部分の使い勝手が良くなった。難点としては設定、メンテナンスの敷居が高い PaaS の部分が弱い。
• CyberAgent 長谷川 誠 氏
  プライベートクラウドとして、1万コア、300 台で使用。アップグレードが難しい。やり方としてはローリングアップグレード。新しいバージョンを作成→移行→古いバージョン壊して作り直し。今のところ特に大きな問題はない。パブリッククラウドより安くあげる事が先決問題。Community への貢献はしていくつもり。
  Liberty には自分のものもコミットされた (ドキュメント関係)。

NEC- Converged System Solution Based on OpenStack and Ceph

報告者: 佐藤
Cloud Platform for IaaS (CPI) 製品とその中で使用されている Ceph および NEC の Ceph に関する取り組みの紹介。計算ノードと Ceph OSD ノードは別の構成。SSD の数を増やすと性能が下がる問題があったが、Ceph のバージョンを上げたら (tcmalloc/Firefly→jemalloc/Hammer) 改善した等。将来は Ironic, Apach Spark と組み合わせて、ビッグデータ用途に適用する計画とのこと。

DAY 2: 10月28日 (水) へ続く