最近のたまおきの取り組み〜 OpenStack+α の実現に向けて

〜

日本仮想化技術株式会社VitrualTech.jp

たまおき のぶゆき

自己紹介

• 日本仮想化技術の中の人• オープンスタック関連の

ビジネス創出中– EnterpriseCloud.jp の管理者– 『 OpenStack 最新情報セミ

ナー』の企画・運営

2

本日のお題

• OpenStack にまつわる課題• OpenStack+α による解決

– 仮想ネットワークの高速化– GPU on OpenStack– ログ解析の高度化

• OpenStack 共同検証ラボのご紹介

3

OPENSTACK にまつわる課題

4

OpenStack を取り巻く状況の変化

• OpenStack 基盤は「作る」から「動かす」に– 鉄板構成が浸透してきた– 運用上の課題解決がポイントに– 新技術の取り込みや運用課題の改善提案を

取り組み機運がでてきた

5

参考 ) OpenStack 基盤について

6

クラウドコントローラ

仮想マシン 仮想マシン

ベアメタルサーバ ベアメタルサーバ

L2/L3 スイッチ

アン

ダー

クラ

ウド

クラ

ウド

ソフ

トウ

ェア

OpenStack 基盤

ログ解析ツール

監視・モニタリングツール

インシデント管理ツール

問題管理ツール

自動化ツール

構成管理ツール

OpenStack 基盤の運用についての課題

OpenStack 基盤の運用についての課題 ( 一例 ) 注 1

• OpenStack についての課題– OpenStack に障害検知の仕組みがない 注 2

– OpenStack のメータリング機能（リソース使用状況を可視化）が使えない 注 3

– 仮想ネットワークの監視や QoS 管理についてのノウハウが足りない 注 4

• OpenStack 基盤の運用・監視における課題– 監視ツールのアラーム設定やログ管理ツールの Black/White list や問題発生

時に参照するナレッジベースを手動で管理している– アラーム設定やナレッジベースの更新は OpenStack の熟練者にしかできな

い– 正常時の監視についてのノウハウが足りない 注 5

7

注 1: OpenStack 基盤の運用におけるよくある課題を列記注 2: OPNFV の Doctor プロジェクトに期待注 3: Ceilometer + Gnocchi に期待注 4: 商用の SDN 製品を使えば解決、ＯＶＳとか Linux Bridge でどうするか注 5: SRE などの考え方の伝播や Chaos Monkey などのツールの活用に期待

OpenStack 基盤の運用についての課題

OpenStack 基盤の運用についての課題 ( 一例 )• OpenStack 基盤のログ管理についての課題

– OpenStack 基盤から出力されるログの量が多すぎる 注 6

– システムで一意で一貫性のあるログが出力されない– ログから原因を特定するのが難しい（ OpenStack についての高度な知見が必

要 ) 注 7

• 運用オペレーションについての課題– インシデント管理の対応記録とナレッジベースの紐付けが不十分– OpenStack 基盤の構成管理情報が Excel 管理で他システムから参照できない– アラーム設定や Black/White list やナレッジベースは OpenStack のバージョン

や機器構成が変わるたびに見直さないといけない 注 8

8

注 6: 本番環境でもログレベルを Debug で運用しているため注 7: ログファイルにてトランザクション ID が引き継がれない場合があることが原因注 8: 今後の改善に期待

OPENSTACK ＋ Α による解決

9

α

OpenStack + α とは

10

クラウドコントローラ

仮想マシン 仮想マシン

ベアメタルサーバ ベアメタルサーバ

L2/L3 スイッチ

アン

ダー

クラ

ウド

クラ

ウド

ソフ

トウ

ェア

OpenStack 基盤

ログ解析ツール

監視・モニタリングツール

インシデント管理ツール

問題管理ツール

自動化ツール

構成管理ツール

OpenStack + α とは

11

クラウドコントローラ

仮想マシン 仮想マシン

ベアメタルサーバ ベアメタルサーバ

L2/L3 スイッチ

アン

ダー

クラ

ウド

クラ

ウド

ソフ

トウ

ェア

OpenStack 基盤

ログ解析ツール

監視・モニタリングツール

インシデント管理ツール

問題管理ツール

自動化ツール

構成管理ツール

① 仮想ネット

ワークの高速化

②GPU on OpenStack

③ ログ解析の高度化

① 仮想ネットワークの高速化

12

Smart NIC による高速化• NIC に CPU が載ったもの• 重いネットワーク処理を HW オフロード

– OVS や vRouter や IPSec など

13

CPU

NIC

NIC

VF

VF

VF

VF

VF

VF

VF

VF

VF

VFPF 1

VFPF 2

VF

Smart NIC ホスト OS ゲスト OS

PF: Physical functionVF: Virtual function

仮想ネットワークの高速化手法

14

OVS + DPDK SR-IOV Smart NICOVS(Open vSwitch) での仮想ネットワークの高速化手法

NIC NIC Smart NIC

OVS flowtable

OVS ManagementDPDK

VM VM

OVS Management

VM VM

OVS flowtable

OVS Management

VM VM

VF

DPDK を使用した仮想スイッチの高速化

パススルー技術を活用したネットワークの高

速化

HW オフロードを使用した仮想スイッチの高

速化

Open vSwitch 2.3 からDPDK 機能を内包

6Wind 社などが商用製品を提供

SR-IOV を有効化するために、 BIOS と

Linux カーネルを一部変更

HW オフロード NIC を使用

Netronome 社やCavium 社などが商用

製品を提供

VirtIO VirtIO VirtIO VirtIOVFVF

OVS flowtable

仮想ネットワークの高速化手法

15

OVS + DPDK SR-IOV SmartNICOVS(Open vSwitch) での仮想ネットワークの高速化手法

性能：△ 性能：○ 性能：○

管理のしやすさ：○ 管理のしやすさ：△（ × ） 管理のしやすさ：○

導入が容易ユーザは意識せず使用専用設備を必要としな

い

帯域上限まで使えるＶＭに負荷をかけない専用設備を必要としな

い

帯域上限まで使える？ユーザは意識せず使用VM に負荷をかけないＶＦの割当・変更は不

要

実績：△ 実績：△ 実績： ×

帯域上限まで使えないDPDK処理用の VM

（ CPU処理）を割り当てる

VF の割当・変更が手動VM のマイグレーショ

ン作業が面倒OpenStack 連携が未熟

専用設備を必要とする実績は乏しい

Cons

Pros

②GPU ON OPENSTACK

16

参考：人工知能と機械 /深層学習の整理

人工知能 > 機械学習 > 深層学習

• 人工知能 : Artificial Intelligence – 知的と考えられるような処理、すなわち記号論理処理やパ

ターン認識、分類、推論、統計解析、予測などを実行するさまざまな情報技術の集合体

• 機械学習 : Machine Learning– 訓練データからルールを発見し、モデルを獲得させて、そ

れを使って認識や分類、予測を行なうアルゴリズム• 深層学習 : Deep Learning

– 機械学習の手法の一つの「ニューラルネットワーク」を複数層に重ねたもの

17人工知能とは何か ? 機械学習、深層学習の違いとは ?http://pc.watch.impress.co.jp/docs/column/ai_nyumon/1021030.html

機械学習や深層学習への期待

18

KDDI総合研究所 人工知能を活用したネットワーク自動運用システムの実証に成功 http://www.kddi-research.jp/newsrelease/2016/022201.html

機械学習や深層学習への期待

19

Huawei 社 MIND: Machine Learning based Network Dynamicshttp://events.linuxfoundation.org/sites/events/files/slides/ONS_MIND_Huawei.pdf

GPU on OpenStack

20

コントローラノード 仮想マシン

　コンピュートノード

Nova API

Nova Compute

App

KVM

IOMMU/VT-d

GPU

AMQP

Nova Scheduler

GPUパススルー技術を活用して、仮想マシンに GPU を割り当てる（ GPU インスタンス）

GPU Driver

③ ログ解析の高度化

21

大量のログ情報との戦い

22

引用： http://www.slideshare.net/VirtualTech-JP/ntt-openstack-summit-2015-tokyo-after-one-year-of-openstack-cloud-operation-ntt-docomo

ログ出力数80M行&100GB/ 日(内クリティカル０ )

OpenStack 共同検証ラボの昨年度の取り組みfluentd+elastic によるログ分析

23

ログ分析サーバ

監視サーバ

(Agent)

(Server)

ログ収集 /タグ付け /転送・ White リスト定義

ログ集約・Elasticserchへログ格納

ログ蓄積 / 分析

分析結果可視化・Black リスト定義

GitHub: openstack-lab/OPS-Manager にて公開中https://github.com/openstack-lab/OPS-Manager

ログ解析にまつわる課題PP6-7 からログ解析にまつわる課題を抽出– 監視ツールのアラーム設定やログ管理ツールの

Black/ White list や問題発生時に参照するナレッジベースを手動で管理している

– アラーム設定やナレッジベースの更新は IaaS 環境の熟練者にしかできない

– IaaS 環境から出力されるログの量が多すぎる– システムで一意で一貫性のあるログが出力されない– アラーム設定や Black/White list やナレッジベースは

OpenStack のバージョンや機器構成が変わるたびに見直さないといけない

24

Elastic + prelert による異常検知

25「 Prelert でプログラミングレスな異常検知に挑戦！」より引用http://acro-engineer.hatenablog.com/entry/2016/11/02/120000

Moogsoft によるログ解析イベント入力 フィルター

頻出するイベントは排除する、などの独自のロジックにより98% のノイズを削除

時系列による分類

類似事象による分類

構成管理に紐付いた

分類

アノマリー検知

レシピによる分類

ナレッジによる分類

シチュエーションＡ

シチュエーション

B

シチュエーション作成

多角的のアノマリー検知により、 99.5% のノイズを削除

プライオリティ付け＆通知

Black List / White List 運用に替わる方式への期待

OPENSTACK 共同検証ラボのご紹介

27

OpenStack 共同検証ラボ

28

ブロードバンドタワー様と立ち上げ。現在 7 社でコラボ中。

OpenStack 共同検証ラボとは• ブロードバンドタワー様のデータセンター施

設を利用し、検証環境を用意いたします。• 『 OpenStack 共同検証ラボ』に協賛いただく

会社を募り、協賛企業の皆様と共に検証を行います。– 協賛企業の皆様は検証テーマを提案できます。– 本ラボが提案した検証テーマに参画いただくこと

も可能です。• 『 OpenStack 共同検証ラボ』で得たノウハウ

や知見をドキュメント化し、ドキュメントを一般公開いたします。29

昨年度実施した評価・検証 ( 一例 )

OpenStack 共同検証ラボhttps://enterprisecloud.jp/openstack-lab/

GitHub https://github.com/openstack-lab/OPS-Manager

31

32