openstack運用管理最前線 - openstack最新情報セミナー 2014年12月

Ver：1.6MiracleLinux Inc,.Project Hatohol team

Copyright © 2000-2014 MIRACLE LINUX CORPORATION All rights reserved

OpenStack運用管理最前線

https://github.com/project-hatohol/hatohol

自己紹介


所属：ミラクル・リナックス株式会社　

事業戦略本部　マーケティング部

Hatohol(はとほる）、OpenStack担当

名前：林勝賢

1

本日お伝えしたい事

Copyright © 2000-2014 MIRACLE LINUX CORPORATION All rights reserved 2

◎ OpenStack Summit Parisで聴講した運用管理３つの事例

◎ Techtalkでの弊社発表内容のフィードバックAn QoS Solution for SIP on OpenStack with Hatohol

OpenStack Summitに参加した目的


◎ OpenStackに関連したサービスを計画中で、特に運用管理の技術情報を収集するため

◎ Hatohol＋OpenStackソリューションを世界に知ってもらうため

弊社がサミットで注目したセッション


構築実装運用管理（ここに注目）

監視、障害対応、パフォーマンス、HA、DRなど

発表した各社の取り組み（抜粋）会社名実装構築運用

Cisco Monitoring,Ceilometer

RackSpace Container,Scaling, Multi-cell

Monitoring

CERN Scaling, Multi-cell Booting,Performance

Kent Univ. Scaling, Multi-cell Monitoring, Ceilometer

SuSE HA,完全自動構成

IBM HA,DR、Monitoring,Monasca

HP Monitoring, Monasca

CTC,OOL Native Application

Bloomberg OpenCompute,Ironic

TATA NFV

Mirantis Scaling,performance

Redhat DR

5

これから紹介する３つの事例


1，大量のVMの一斉起動の高速化 (by CERN)

2， Ceilometerを使った不適切行為の検出 (by Cisco, Kent Univ.)

3，大規模環境の監視における大量アラートの対策(by RackSpace)

事例 Cold start booting 1000 VMs in under 10 minutes


by CERN

大量のVMの一斉起動の高速化



計算クラスタ背景

保守期間中に、リソースを有効活用するために OpenStackを導入して、約1200台のVMで並列に計算できるくらいのパワーを提供

構成の特徴OpenStackのコンポーネントで、nova, nova-api, keystone, glance以外は使用していない



直面した問題

・起動時間がVMの同時起動数と正比例　　に増加。　（この例では１2００VMの起動は4時間ほ　　どかかる）・インフラを使用できる時間が限られる。

起動時間のかかる原因

・スケジューラとGlanceがボトルネック・解析ソフトウエアのVMイメージの更新が頻　繁でキャッシュの使用効率が悪い

VM起動までの流れ：1. ClientからVM起動リクエストを送る2. APIが解釈し、スケジューラへ転送する3. スケジューラがNovaへリクエストを送る4. リクエストを受け取った NovaはGlanceを参照し仮想ディスク（１．３GB）を取得(REST API)5. NovaがVMを起動する。



起動高速化の対策

1. VMイメージをNovaのキャッシュに事前配布

・　Novaのキャッシュに事前に配布これにより、１回目以降の起動が高速化

2. 事前配布の効率化

・　VMイメージの取得経路を変更Glance ---> (Apache + Squid) ----> NovaSquidのキャッシュから配布することで高速化

・効率のよい圧縮・解凍アルゴリズムによる転送及び起動時間の短縮Gzip6が解凍・圧縮が最も高速且つ、圧縮率が高い。



/var/www/vm_xxx

Apache

gzip6で圧縮

ControllerController

ControllerController

Squidキャッシュ

NovaNova

NovaNova

Nova

一千台以上

NovaNova

Nova

Novaコントローラ4台にぞれぞれsquidを導入

高速ネットワーク

wget -p proxy_squid xx

gzip 6で解凍

Nova cache

Glance

高速化のために改造した箇所ソフトが更新の度新しいVMイメージ入力

http http

http

http

①

②

③

④

/tmp/imxxx

⑤

mcollectiveを使用して、各コマンドを



・圧縮効率はgzip-9が上だが、大した差はない。・圧縮時間と解凍時間を比較したら gzip-6が圧倒的に効率がよかった。

非圧縮 gzip-6 gzip-9 bzip2

サイズ 1.3GB 393MB 391MB 341MB

圧縮時間 1m37s 6m58s 3m57s

解凍時間 0m18s 0m18s 1m5s

Squidなし Squidあり

圧縮なし 3.7hours 27.5minutes

圧縮あり(gzip-6)

1.1hours 8.3minutes

1200台のNovaにイメージを配布した場合の時間

圧縮アルゴリズムの比較

1200台VMの起動時間（縦軸：VM数、横軸：時間）1/4くらい圧縮



CERNからOpenStackコミュニティーへの提案

1. Novaのプロキシサポート2. Glanceの自身の圧縮イメージサポート

将来この手法が標準（もしくはオプション）として完全に実装されると手軽に大規模なnode展開がしやすくなる　（Juno（2014.2）にはまだ実装されてないかもしれません）。

事例 Using Ceilometer data to detect fraudulent activity in our OpenStack cluster


by Cisco, Kent University

Ceilometerを使った不適切行為の検出



背景クラウドの不適切な利用によるリソース大量消費の問題が増えている。

目的OpenStackクラウド上で行われている不適正な利用者を特定する。



不適切な利用者の特定までの流れ

１、情報収集　　Ceilometerを使って、適切使用時のホストと不適切使　　　用時のホストのリソース使用状況をサンプルとして収集　　する２、複数の学習アルゴリズムに教師データとして投入し、機　　械学習させる

３、それぞれの学習結果を評価する　　Ceilometerから取った実データをマイニングして、　　不適切使用のホストを特定する

学習段階



目標システム：学習できた状態で不適切な利用者を特定する

Ceilometer + 機械学習でリアルタイムで検出

情報収集(Collect)

分類(Classify)

対応(Counteract)

CPU使用率ネットワーク流量（ in/out)ディスクへのアクセス量 (read/write)

五秒間ごとにサンプルを取得

Neural NetworkSVMRandom ForestNaive Bayes...

Data mining toolhttp://orange.biolab.si/

アラームQuotaを減らすリソースを停止するユーザをブロックする...

様々なアルゴリズムポリシー

http://orange.biolab.si/

http://orange.biolab.si/



1、適切な使用時のホスト情報

例： ①ベンチマーク（HBench）　 ②高負荷状態（CPU)

③アイドル状態

２、不適切な使用時のホスト情報

例： ④DDoS攻撃を実行している

⑤仮想通貨のマイニング　（Bitcoin/Litecoin）

情報収集(Collect)事前学習させる

① ②

④

⑤

③

※右のグラフは、横軸：ネットワーク通信量、　縦軸：CPU使用率

　　検証環境で下記の情報を取得



取得したデータを、OSSのデータマイニングツール「Orange」を使って、いくつかのアルゴリズムで最適解を求め、不適切行為を突き止める

分類（Classify)

データマイニングツールOrange

PCASVMRandom ForestNaive BayesLogistic RegressionNeural Networkk-Means Clustering

色々なアルゴリズムを使って分類する。

アルゴリズムの例

事例 Monitoring Enterprise in OpenStack


大規模環境の監視における大量アラートの対策

by RackSpace



課題

１、障害が発生すると大量のアラートが発生するが、何を調べれば分からない。

効率よく根本原因を突き止めるために障害毎に発生するアラートの関連を整理することが必要

２、リソースの枯渇が原因で、突然サービスが停止することがある。

リソースの枯渇を事前に知る方法を確立することが必要



（監視による）対策

１、障害発生後、素早く原因を特定

２、障害発生の事前防止

無駄な調査時間を省略し、根本原因の特定を効率化

● パフォーマンスデータの監視● 統計的な指標に基づいた計算

● イベントとアラート情報の相関（Correlation）を整理。● 調べる必要のないアラートを抑制(Suppression)する。

枯渇しそうかどうかの判断



Alert ID 監視項目 Suppress(抑制） ID

1 Horizon Content 2

2 Horizon Auth -

3 Apache Health 1,2

4 Keystone health 2

5 MySQL Health 6,4,2

6 DB Record 4,2

各監視項目とそれに対する抑制対象項目とのマップを作成

アラートの相関関係のマッピングの例



Horizon

Apache

Keystone

MySQL

content check

Authentication check

Health check

Health check

Health check

DB Record

Alert ID 監視項目 Suppress ID

1 Horizon Content 2

2 Horizon Auth -

3 Apache Health 1,2

4 Keystone health 2

5 MySQL Health 6,4,2

6 DB Record 4,2

アラート抑制の例

Down Service

Alert Suppressed Alerts

MySQL Health

CRITICAL: MySQL Read VIP down

Horizon Auth, Keystone Auth

Keystone Health

CRITICAL: KeystoneVIP down

Horizon Auth



リソース枯渇の予測方法：

1、測定対象リソースの平均値や最大値を計測して閾値を決める

2、一定期間中（例えば、一週間）の変化率を求めてリソース枯渇までの時期を予測

※ マシン毎のリソース使用量のばらつきを考慮し、標準偏差を使って、予測の精度を上げることも可能。

リソース使用量予測の例

その他の考慮

１、（日中、週単位、月単位、季節単位）周期的に変化するパターンの対応２、閾値との乖離からアラートを生成し、システムの最適化を図る　　　例、仮想ホストのプロヴィジョニングとデ・プロヴィジョニング

リソース名使用率増加率/週閾値到達までの時間（週）

CPU 34% 4% 4

vCPUs 73% 2% 6

Memory 57% 6% 3.8

Disk 22% 3% 19.3

閾値：CPU平均使用率 > 50% 又は　　　メモリ平均使用率 > 80% 又は　　　 Disk 最大使用量 > 80% 又は　　　 vCPUの配布率 > 85%


Hatoholを使ったSIPサービスのQoSソリューション

プロジェクト Hatohol


It was born here (Tokyo, Japan)

◎ Jun 27,2013 誕生日

◎ ソースコード・れポジトリ https://github.com/project-hatohol/hatohol

◎ GPLv2

◎ 3ヶ月一回リリース

◎ 運用統合ツールを目指しています。

27


インフラでの日常的な管理事項


◎ イベント管理(Event management) CPU、メモリ、ネットワーク、ログなどのリソースを監視、異常を検知し　　て、アラートを通知する。

◎ インシデント管理（Incident management）異常や障害を検知した場合、インシデントを作成し対応状態を管理する。

◎ ログ管理（Log management）全てのログがアーカイブされ、必要に応じて解析を行い、レポートする。

◎ リソース管理（Resource management）必要に応じてシステムの構成を更新・追加、セキュリティパッチを適用したりするなどを行う。

Openstackにおいて現時点、上記のことを実現する機能はまだない

28

　OSSの連携で運用統合


Zabbix

Nagios

fluentd

Redmine

ssh

イベント管理

変更管理リリース管理

インシデント管理

問題管理Zabbix

稼働監視リソース監視障害判定

自動起票エスカレーションステータス管理

ホスト管理資源／資産管理設定管理一括変更

ログ管理リソース状況参照

イベント通知イン

シデント登録

リモートコ

マンド問題切り分

け

状況表示イベント管理イベント通知

様々な運用ツールを統合し、オンプレミス環境、プライベートクラウド、パブリッククラウドな

ど環境を問わずシームレスに運用、管理を一元で行なうハブのようなソフトになることを目

指しています！

サービスデスクCeilometr

29


Hatohol ソフトウエア構造　　　　　　　　

※ 画面表示：ReST APIを呼び出すカスタマイズ・アプリ作成可能※ データ収集：HAPIを通じて他のアプリケーションと通信

カスタマイズ画面

30

機能: 統合監視


Applications

Guest OS

Applications

Guest OS

Virtual Machine

VirtualMachine

HyperVisor

ZabbixNagiosFluentd

Ceilometerlibvirt

ZabbixNagiosFluentd

ゲストOS、アプリのリソース、ログ

仮想マシン・リソース

物理マシン、 OpenStackのリソース、ログ

OpenStack

Host OS

・複数の監視サーバを統合してイベントを管理

複数の監視ソフトで取得した情報を統合管理

・複数の管理対象のリソースを縦串、横串で確認

監視ソフトの違い、環境の違いを意識せず、一括でグラフ表示、イベント表示

監視サーバ、監視対象を問わずグラフを並べて表示

31

機能: アクセス・コントロール


CustomerVM

ZBX agentCustomer

VM

ZBX agentZBX sever

VM

CustomerVM

ZBX agentCustomer

VM

ZBX agentZBX sever

VM

CustomerVM

NRPZCustomer

VM

NREZ

Nagios

Net1

Net2

Net3

Net4

OpenStack networks

USER1can only see

Net1

USER2can only see Net1 to Net3

USER3can only see Net3

and Net4

CustomerVM

ZBX agentCustomer

VM

ZBX agentZBX sever

VM

Access permission control

Hatohol

マルチテナント監視・お客様テナント毎にZabbixサーバを用意し、Hatohol通じて柔軟なアクセス制御

　各テナントのサブネットが同じでも floating IPで対応可能

・クラウド基盤の各レイヤーを別々の Zabbixサーバで管理し、Hatoholで一元管理

32

事例:A QoS Solution for SIP service

Zabbix

Hatohol

Nagios

SIP Server

virtual machine

Physical machine

virtual machine

virtual machine

Host management

AutomaticOrachration

OpenStack API

AddSIP Machine

SIP Server

SIP Server Physical machine

OpenStacks

Ironic

Traffic

Standby Group

decreaselevel

increaselevel

Active Group

Remove

33



Welcome to join the project https://github.com/project-hatohol/hatohol

34



2015/02/03-04 OpenStack Days 2015に出展決定

・Hatoholを使ったOpenStack監視のデモを行います。

・2015/02/04 　2日目の13:50-14:30でセッション使ってわかった！現場担当者が語るOpenStack運用管理の課題


35

2015/2月以降の予定

・OpenStack監視用のZabbixテンプレートを公開

・Zabbix/Hatohol内容も含めたOpenStack構築手順書を公開

今後の活動

openstack運用管理最前線 - openstack最新情報セミナー 2014年12月

Technology