Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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

356 views

Published on

2017年3月にMilanoで開催されたOps Mid-Cycle Meetupと2017年2月に開催されたProject Team Gatheringの参加報告資料です

Published in: Technology
  • Be the first to comment

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

  1. 1. 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コミュニケーションズ 技術開発部
  2. 2. Copyright © NTT Communications Corporation. ● Ops Mid-cycle Meetup (Milano) ○ Rabbitmq ○ Deployment methods ○ Logging & Monitoring ○ Trove ● Project Team Gathering (Atlanta) ○ 全体概要 ○ Trove 2 Agenda
  3. 3. Copyright © NTT Communications Corporation. Ops Mid-Cycle Meetup
  4. 4. Copyright © NTT Communications Corporation. 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
  5. 5. Copyright © NTT Communications Corporation. 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で実現できる? ● ロギングの辛み: サービス間でのイベント相関が分からない
  6. 6. Copyright © NTT Communications Corporation. 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レスポンス時間 ● 障害予測をどのように行うか ?
  7. 7. Copyright © NTT Communications Corporation. 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
  8. 8. Copyright © NTT Communications Corporation. 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
  9. 9. Copyright © NTT Communications Corporation. Deployment methods ● サービスディスカバリ ○ HashicorpのConsulを使うのはどうかという提案 ■ どのサーバで新しいプロセスが上がったか等の監視に利用 ○ puppetdbを利用して,Icingaに監視するサービスを exportしているユーザも ● プロダクションで使っているreleaseについて ○ Liberty, Mitaka, Newtonが大半で,Mitakaが多い ○ 先月リリースのOcata使用者はまだおらず 9
  10. 10. Copyright © NTT Communications Corporation. 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
  11. 11. Copyright © NTT Communications Corporation. ● 構築についての議論 ○ RabbitMQの隔離・ネットワークのアーキテクチャ ■ 他コンポーネントが使用するものとは別のMQを立てる ■ ネットワーク的にも分離する ○ DBインスタンスをユーザに直接触らせない ■ ユーザのテナントではなく専用のテナントにインスタンスを立てる ● remote_(nova|cinder|neutron)_clientの設定 ● それでもすべてのDBインスタンスがコントロールされるリスク ● 課金の問題 ○ イメージの構築が難しい ● Web UI ○ Troveの機能に対してWeb UIでできることが少ない ■ 独自で必要なUIを実装(Swiss National Supercomputing Centre) 11 DBaaS with Trove
  12. 12. Copyright © NTT Communications Corporation. Project Team Gathering
  13. 13. Copyright © NTT Communications Corporation. 概要 ● Project Team Gathering(PTG)とは? ○ 従来OpenStack Summitの一部であったDesign Summitが独立 ○ PTG ■ 開発者が次のサイクルに向けてロードマップの決定や 開発上の課題を直接話して解決していく場 ■ Summitの約2ヶ月前に開催 ■ リリースタイミングもこのタイミングに変更 ○ Forum ■ OpsやUserからのフィードバックをDevが受ける場 ■ Summit内で開催
  14. 14. Copyright © NTT Communications Corporation. 概要 ● 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日間参加
  15. 15. Copyright © NTT Communications Corporation. 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のアーキテクチャやパラメータについて議論
  16. 16. Copyright © NTT Communications Corporation. PTGの感想 ● 活発なプロジェクトとそうでないプロジェクトの差は歴然 ○ Nova, Neutron, Cinderといったコアプロジェクトや Ironicの部屋は盛況 ○ Troveなど非コアプロジェクトは盛り上がりに欠けることも ○ Designate (DNSサービス)に至っては参加者わずか2名 ● 479名が来場した事になっているが,全体としても人が少ない印象 ○ 前半のみ参加した人も多かった? ● OpenStack Summitのついでなら参加できていた開発者が来れなかった? ○ 発表や展示ブースがないので業務として参加が難しい? ● DevとOps, Userの距離が遠くなる懸念 ○ PTGに参加するOps, Userは少ない ○ PTGが独立したため、Forumには参加しない予定のDevがみられた

×