mexico ops meetup発表資料 20170905

Copyright © NTT Communications Corporation.

Transform your business, transcend expectations with our technologically advanced solutions.

Ops Mid-Cycle Meetup Mexico報告会

2017/09/04

NTTコミュニケーションズ技術開発部

松本赳明, 原田和明


● 概要

● セッション

– Documentation of older versions

– OpenStack on Containers

– Containers on OpenStack

– Brownfield to Containerized

– Logging and Monitoring

2

Agenda


● OpenStack Ops Meetup

– OpenStackの運用者が集まり、現状のOpenStackの問題点や解決策を議論し、知見の共有や開発者へのフィードバックを行う場

– Summitの間に年2回開催

● Ops Meetup Mexico

– 日程: 2017/8/10-11

– 会場: Digital Culture Center, Mexico City

– 参加者: 30人程度

• NTTからはSICから3名, コムから2名が参加

– Etherpad

• https://etherpad.openstack.org/p/MEX-ops-meetup

3

概要

https://etherpad.openstack.org/p/MEX-ops-meetup







● スポンサー

• Digital Culture Center

• Bloomberg

• Meltsan

• Nearshore

• nearsoft

• sentinel.la

• SUSE

• Software Guru

4

概要


● セッション

– Day1 • Documentation of older versions of OpenStack

• OpenStack on Containers

• Containers on OpenStack

• OpenStack Migrations/Upgrades

• OpenStack Resiliency

• OpenStack Extreme Testing

– Day2 • Brownfield (Legacy) to Containerized

• OpenStack Monitoring tools

• Network Management and Troubleshooting

• NFV

• Technical Committee feedback

• Service tenants/VMs

5

概要


古いバージョンのドキュメントのメンテナンスに関するセッション

● 現状

– stableブランチがなくなったバージョン(EOL)のドキュメントは

docs.openstack.orgから削除されていってしまう

– コミュニティのサポートとベンダーのサポートはライフサイクルが違う

• コミュニティ

– Icehouse-Mitaka: EOL

• Canonical

– Icehouse: 2014-2019

– Kilo: 2015-2018

– Mitaka: 2016-2021

– 実際、会場でもIcehouse-Mitakaまでのバージョンを使っている人が多数

– tagから自分でビルドするのは大変

– branchがEOLになってしまっても、ドキュメントはしばらくメンテ・ホストしてほしい

6

Documentation of older versions


● 実際に見つからなくて困ったドキュメント

– nova network

– 特定バージョンのコンフィグ, APIリファレンス

– Opsガイド

• Opsガイドはopenstack-manualsからwikiへ

● どのバージョンまで残すべきか、コミュニティorベンダーがやるべきかなど議論

● 現状まだメンテナンスされているMitakaをモデルケースにして、古いドキュメントを残していく活動をすることが決まった

7

Documentation of older versions


OpenStackコンポーネントのコンテナ化について議論するセッション

● コンテナ化したOpenStack – 今までは検証フェーズの人たちが多かったが、運用している人も増えてきた印象

– ただし、API系のみ、ステートレスなプロセスのみなどから始めている人が多い

● デプロイ先

– ベアメタル上に直接コンテナを動かす人が多い

• Docker(Pure), LXC, Kubernetes

● Kolla, Kolla-Ansible, Kolla-Kubernetes (Docker)

– プラグイン(LBaaS, ...)の追加をしようとしたときカスタムイメージのビルドが大変

– OpenStack-Ansibleのようなyamlスタイルにしてほしい

– アップグレード機能がコンフィグのvalidationをしてくれない

• osloプロジェクトで対応が進行中

– 既存環境からコンテナへの移行が考慮されていない

• 次回のPTGで議論予定

– 自分たちの環境に合うように結局オリジナルのイメージを作成

8

OpenStack on Containers


● OpenStack-Ansible (LXC)

– （Docker Registryのような？）ビルド済みのイメージ管理機能がない

• machinectlを使用したイメージ管理がNewtonから実装され、Ocataで完了した

– ただし各ホストでイメージをビルドする必要がある

• RackspaceではContainer artifactsをOSAベースで独自開発

• layerfsを使ってlayeredなイメージを使うことができるがTrustyでは不安定なため、デフォルトでは有効になっていない（Xenialでは改善）

– OSAは比較的枯れていて、デプロイの変更方法の知見もある

• LXCコンテナの無効化、initスクリプトの確認、サービス停止、再デプロイ

• ジャンプアップグレードのドキュメントも https://github.com/openstack/openstack-ansible-ops/tree/master/leap-upgrades

– Ocataから課金やリソース管理に便利なsystemd.sliceを使った管理機能が実装

9

OpenStack on Containers

https://github.com/openstack/openstack-ansible-ops/tree/master/leap-upgrades









OpenStack上のコンテナサービスについて議論するセッション

● コンテナサービスを現在ユーザに提供しているか？

– 提供を考えている人は複数いるが現在提供している人はなし

● ユーザに期待されているもの

– マネージドなKubernetesクラスタ or その他COE

• 現状ユーザがそれぞれOpenStack上に構築している

• K8sの運用をインフラに任せたい

● 実現方法

– Magnum

• 知見がない、試したけど動かない

– OpenStack上にK8sを構築してK8s as a Serviceとして提供

• マルチテナンシーの問題

– プロジェクトごとにクラスタを作成する

• ネットワーク

– Calico, Kuryr...

10

Containers on OpenStack


構築済みのOpenStack環境から、コンテナへ移行する方法を議論するセッション

● 取り組んでいる人はいるか？ → セッション内では1名だけ

● コンテナに移行しようとしている人 → 3名

コンテナ上にOpenStackを構築する OpenStackの隣にコンテナを構築する

↑セッションではこちらがメイン

11

Brownfield to Containerized

Container

OpenStack

Service(2)

OpenStack

Service(1) OpenStack Container


● 移行にあたり、様々なことを行う必要がある

– 設計と開発フェーズ

• OpenStack全体をk8s上に設計

• k8sクラスタの設計

• OpenStackのコンテナの作成

• OpenStackとk8sのモニタリング方法の設計

• 単体テスト、結合テスト、テスト、テスト、テスト...

12



– デプロイメントフェーズ

• k8sクラスタのデプロイ、OpenStackコンテナのデプロイ

• 従来のOpenStack環境からの移行

– 運用フェーズ

• OpenStackとk8sの監視

移行に取り組んでいる人のコメント：

「コントロールサーバの機能を一つずつコンテナ化している．

HAProxyを変更して稼働中のサービスを新しい基盤に切り替えている．」

13



OpenStackのロギングとモニタリングを議論するセッション

● どのようなモニタリングツールを使っているか

14

Logging and Monitoring


● その他のモニタリングツール

– ops developed tools: http://git.openstack.org/cgit/openstack/osops-tools-monitoring/tree/

OpenStackサービス監視用のシェルやpythonコード

nagios / sensuプラグインを提供

15


http://git.openstack.org/cgit/openstack/osops-tools-monitoring/tree/







● その他のモニタリングツール

– OSA TICK stack (influx+telegraf+kapacitor w/ grafana) https://github.com/openstack/openstack-ansible-ops/tree/master/cluster_metrics

OpenStackクラスタのメトリックを収集するスタック

Openstack-ansibleでデプロイができる

16


https://github.com/openstack/openstack-ansible-ops/tree/master/cluster_metrics






● どのようなロギングツールを使っているか

17


EFK = ElasticSearch + Fluentd +

kibana

ELK = ElasticSearch + Logstash +

kibana


● どのようなメトリクス計測ツールを使っているか

18



● その他のメトリクス計測ツール

– Telemetry + gnocchi https://www.openstack.org/videos/boston-2017/openstack-telemetry-and-the-10000-instances

• Bostonでのプレゼン“OpenStack Telemetry and the 10,000 Instances”

でベンチマークなどが発表されている

• 5,000 Nodeまで容易にスケールできるらしい

– Diamond+influxdb

https://github.com/python-diamond/Diamond

• Diamondを用いてinfluxdbにメトリクスを渡す

Diamond ─ メトリクスを収集するpythonデーモン

19


https://www.openstack.org/videos/boston-2017/openstack-telemetry-and-the-10000-instances















● どのような項目をモニタリングしているか

– ネットワーク

• ジッター、レイテンシ、スループット、セション数、パケットロス

– CPU使用率

– ストレージ使用率

– リンクアグリゲーション

– 帯域使用率 (請求用途)

• libvirtのI/OをDiamondを使って取得後、influxdbに格納し請求書を作成

20



まとめ

• 普段のOps Meet Upより参加者は少なかった

• Mitakaをモデルとして、古いドキュメントを残していくことが決まった

• コンテナをあつかう取り組みはまだまだ発展途上である

• 構築済みOpenStack環境からコンテナ化された環境へ移行する知見はまだ乏しい

ご清聴ありがとうございました

mexico ops meetup発表資料 20170905

Technology