OpenStack Ops Mid-Cycle Meetup & Project Team Gathering出張報告

Copyright © NTT Communications Corporation.
Transform your business, transcend expectations with our technologically advanced solutions.
Ops Mid-Cycle Meetup &
Project Team Gathering出張報告
2017/03/24
NTTコミュニケーションズ技術開発部

● Ops Mid-cycle Meetup (Milano)
○ Rabbitmq
○ Deployment methods
○ Logging & Monitoring
○ Trove
● Project Team Gathering (Atlanta)
○ 全体概要
○ Trove
2
Agenda

Ops Mid-Cycle Meetup

RabbitMQのHA・Scaling・Logging/Monitering等について議論するセッション
● どんな環境(バージョン)を使っているか?
○ OpenStackは, LibertyとMitakaが多数 (一部Newtonも)
○ RabbitMQは, 3.6系が多数
● スケーリング/クラスタリングはどのように行っているか?
○ サービス毎(cinder, glance等)にRabbitMQを3つ立てている人が多数
● ロギングやモニタリングはどのように行っているか(どこに焦点を当てるか)
○ 1000+のキューの全監視は事実上厳しい , その上重要なキューの見分け方が確立されていない
■ Logstash Multilineの活用, Collectd Plugin, Graylog, message throughput全体を監視
● RabbitMQへの負荷に関してどう対応しているか
○ Neutronのメッセージング負荷が大きい
■ Neutron専用にRabbitMQクラスタを構築すれば良い
○ RabbitMQの統計情報の取得やceilometerによる負荷が大きい
■ 統計情報の取得はしない , ceilometerは極力使わない
4
RabbitMQ

Logging & Monitoring
OpenStackのロギングとモニタリングの手法について議論するセッション
● 参加者の分布：大多数がOpenStack Operator、一部Developerも参加
● どのようなロギングツールを使っているか
○ EFK (ElasticSearch + Fluentd + Kiban)
○ ELKF (ElasticSearch + Logstash + Kibana + (Filebeat)) <- 参加者で最も+1が多かった
○ その他
■ Monasca + Grafana、Riemann + Logstash、ManageIQ
● どのようなログ構造が良いか、またどうあるべきか
○ 特定のエラーのためのユニーク IDの割り当て
○ Logstash Templateの利用
● ログ構造化のための指標を提供すべきか
○ 機械学習や深層学習を利用するために欲しいとの意見も
○ LogStashで実現できる?
● ロギングの辛み：サービス間でのイベント相関が分からない

Logging & Monitoring
OpenStackのロギングとモニタリングの手法について議論するセッション
● どのようなモニタリングツールを利用しているか?
○ Collectd + InfluxDB + Grafana
○ ichinga2 (ngios plugin互換)
○ CheckMK + Nagios
○ Sensu + InfluxDB + Grafana
○ その他
■ Zabbix, Ganglia, Riemann, Telegraf + InfluxDB + Grafana + Kapacitor
● どういった箇所をモニタリングしているか?
○ IPv4のアドレスプール
○ Cephクラスタの状態
○ ノードのIPMI&イベントリの状態
○ その他
■ ノード間疎通性、NeutronAgentやNova-Computeの死活状態、CPU、メモリ、APIレスポンス時間
● 障害予測をどのように行うか ?

Deployment methods
OpenStack自体のデプロイ方法等を議論するセッション
● デプロイツールは何を使っているか？
○ Puppet-OpenStack, OpenStack-Ansible, Triple-Oが会場では優勢
○ Kollaを利用している人も ※Kolla: Dockerコンテナ上にOpenStackをデプロイするプロジェクト
● コンテナの利用状況について
○ 既存の環境をコンテナ化するのは難易度高く課題
○ 実際にproductionでコンテナを動かしている人は少なく，大半が検証中
● All-in-Oneのデプロイについて
○ All-in-Oneのデプロイはテストが目的
○ “real world testing”のためには役に立たないという意見も
■ プロセスやconfigの分割で問題が生じる事が多いため
○ そもそも”real world testing”とは
■ HA databases, loadbalancing, migrationがポイント
○ config management toolのテストには有効
7

Deployment methods
● Upgradeについて
○ component毎のsupprt matrixが欲しい (e.g. Nova Mitaka + Ironic Ocata = not working)
○ For puppet user
■ サービスとpuppetモジュール同時にupgradeを行うか？
■ puppetモジュール->サービスの順でやっている
■ 上記と逆だというユースケースもあり
○ Upgradeでなく"Sidegrade”をしているユーザも
■ Sidegrade : 新しい環境を作り，そこに既存ユーザ等を移行
○ b/gデプロイでupgradeしているユーザはなし
○ N -> N+1 -> N+2 の2段階upgradeのサポートを考慮するべき
■ DBスキーマの変更がネック
8

Deployment methods
● サービスディスカバリ
○ HashicorpのConsulを使うのはどうかという提案
■ どのサーバで新しいプロセスが上がったか等の監視に利用
○ puppetdbを利用して，Icingaに監視するサービスを exportしているユーザも
● プロダクションで使っているreleaseについて
○ Liberty, Mitaka, Newtonが大半で，Mitakaが多い
○ 先月リリースのOcata使用者はまだおらず
9

OpenStackのDBaaSを構築するコンポーネントであるTroveについてのセッション
● 事前投票：15/33 (General Session)
● 参加者：15人程度
● 使用状況
○ 多くの人が検証段階
■ パブリッククラウドのDBaaS提供方法として使用したい人が複数
● catalyst (New Zealand)
● UKFast (United Kingdom)
● ELITS (Sweden)
■ RabbitMQとDBのインスタンスが通信する必要があるのがネック
● 通常、RabbitMQはパブリック面にない
● RabbitMQが乗っ取られたときにすべてのサービスに影響が出るリス
ク
10
DBaaS with Trove

● 構築についての議論
○ RabbitMQの隔離・ネットワークのアーキテクチャ
■ 他コンポーネントが使用するものとは別のMQを立てる
■ ネットワーク的にも分離する
○ DBインスタンスをユーザに直接触らせない
■ ユーザのテナントではなく専用のテナントにインスタンスを立てる
● remote_(nova|cinder|neutron)_clientの設定
● それでもすべてのDBインスタンスがコントロールされるリスク
● 課金の問題
○ イメージの構築が難しい
● Web UI
○ Troveの機能に対してWeb UIでできることが少ない
■ 独自で必要なUIを実装（Swiss National Supercomputing Centre）
11
DBaaS with Trove

Project Team Gathering

概要
● Project Team Gathering(PTG)とは？
○ 従来OpenStack Summitの一部であったDesign Summitが独立
○ PTG
■ 開発者が次のサイクルに向けてロードマップの決定や
開発上の課題を直接話して解決していく場
■ Summitの約2ヶ月前に開催
■ リリースタイミングもこのタイミングに変更
○ Forum
■ OpsやUserからのフィードバックをDevが受ける場
■ Summit内で開催

概要
● PTG in Atlanta
○ 日程：2/20-2/24
○ 場所：Sheraton Atlanta Hotel, Atlanta, GA, US
○ 参加者：約500人 (Developer)
○ PTGとして初めての開催
○ 前半2/20-21がプロジェクトを横断したセッション
後半2/22-24が個別のプロジェクトのセッション
計40種類のセッション
○ NTT Com 松下，松本は2/22-23の2日間参加

Trove
● Trove: Database as a Servicesプロジェクト
○ MySQL, PostgreSQLなどのDBをデプロイする
● Tesora (開発元)、IBM、AT&T、EasyStack、NTT Comから8名が参加
○ 参考: BarcelonaのDesign Summitでは約15名参加
○ 開発をリードしていたHP、Red Hatからの
参加がなく閑散とした雰囲気
● 開発に関する議論
○ Python 3対応
○ MySQL 3.7、MongoDB 3.4対応
○ Datastore別のAPIリクエストのバリデーション
● 周辺プロジェクトとの議論
○ openstack-ansibleプロジェクトの担当者と
Troveのアーキテクチャやパラメータについて議論

PTGの感想
● 活発なプロジェクトとそうでないプロジェクトの差は歴然
○ Nova, Neutron, Cinderといったコアプロジェクトや
Ironicの部屋は盛況
○ Troveなど非コアプロジェクトは盛り上がりに欠けることも
○ Designate (DNSサービス)に至っては参加者わずか2名
● 479名が来場した事になっているが，全体としても人が少ない印象
○ 前半のみ参加した人も多かった？
● OpenStack Summitのついでなら参加できていた開発者が来れなかった？
○ 発表や展示ブースがないので業務として参加が難しい？
● DevとOps, Userの距離が遠くなる懸念
○ PTGに参加するOps, Userは少ない
○ PTGが独立したため、Forumには参加しない予定のDevがみられた

OpenStack Ops Mid-Cycle Meetup & Project Team Gathering出張報告

More Related Content

What's hot (20)

Viewers also liked (12)

Similar to OpenStack Ops Mid-Cycle Meetup & Project Team Gathering出張報告 (20)

More from NTT Communications Technology Development (12)

OpenStack Ops Mid-Cycle Meetup & Project Team Gathering出張報告