OpenStack本番環境の作り方
日本仮想化技術株式会社
VitrualTech.jp
2016/7/4
本日のアジェンダ
• OpenStack共同検証ラボのご紹介
• 構築環境のご紹介
• ログ収集の仕組み
• クラウド監視の仕組み
• 運用オペレーションについて
• 今後のアクション
2
OpenStack共同検証ラボ
3
ブロードバンドタワー様と立ち上げ。現在4社でコラボ中。
OpenStack共同検証ラボとは
• ブロードバンドタワー様のデータセンター施設を
利用し、検証環境を用意いたします。
• 『OpenStack共同検証ラボ』に協賛いただく会社を
募り、協賛企業の皆様と共に検証を行います。
– 協賛企業の皆様は検証テーマを提案できます。
– 本ラボが提案した検証テーマに参画いただくことも可
能です。
• 『OpenStack共同検証ラボ』で得たノウハウや知
見をドキュメント化し、ドキュメントを一般公開い
たします。
4
OpenStack共同検証ラボ 概要
• 当初は2つのゾーンを用意
• ゾーンは3ヶ月~6ヶ月の周期で環境構築・調査・報告作成
を繰り返していく。
5
• SDN/NFV製品の機能
検証
• パフォーマンス検証
• 可用性検証
• SDN/NFV製品の運
用・トラブルシューティ
ング
など
• 基盤の運用・監視ツー
ルの機能検証
• 自動化ツールの機能検
証
• 基盤の運用・トラブル
シューティング
など
SDN/NFVゾーン DevOpsゾーン
成果をオープンソースに!
http://openstack-lab.enterprisecloud.jp 注
https://github.com/openstack-lab で公開
6
注:http://openstack-lab.enterprisecloud.jp は現在準備中です
本日のアジェンダ
• OpenStack共同検証ラボのご紹介
• 構築環境のご紹介
• ログ収集の仕組み
• クラウド監視の仕組み
• 運用オペレーションについて
• 今後のアクション
7
今回構築したシステム①
8
サーバ#1 サーバ#2 サーバ#3 サーバ#4
サーバ#5 サーバ#6 サーバ#7
物理サーバ × 7台
HP BladeSystem c3000
BL460c G7
CPU: Xeon E5540 2P/8C
Memory: 32GB
Disk: SSD 256GB or HDD 300GB
今回構築したシステム②
9
OpenStack-Ansible(Kiloバージョン)を使用し環境構築
サーバ#1 サーバ#2 サーバ#3 サーバ#4 サーバ#5 サーバ#6
コントローラノード コンピュートノード
ログ保存
・ログ分析
サーバ
サーバ#7
監視
サーバ
OpenStack
コントローラ
OpenStack
コントローラ
OpenStack
コントローラ
参考)OpenStack-Ansibleとは?
10
OpenStack-Ansibleとは・・AnsibleをOpenStackのデプロイメントに
使用するOpenStackコミュニティ公式プロジェクト
コントローラノードはLXC上にデプロイされ、
HA構成を自動で構築可能
デプロイメント
root@cont001:~# lxc-ls -1
cont001_galera_container-c9d3d5e8
cont001_glance_container-c40b58d0
cont001_heat_apis_container-f1c4d05a
cont001_heat_engine_container-ad711748
cont001_horizon_container-3c7e39ac
cont001_keystone_container-f7040592
cont001_memcached_container-c3e4e138
cont001_neutron_agents_container-937789b6
cont001_neutron_server_container-19bf2279
cont001_nova_api_metadata_container-15744d51
cont001_nova_api_os_compute_container-23911ee1
cont001_nova_cert_container-e6a940ad
cont001_nova_conductor_container-6f958a7c
cont001_nova_console_container-e4b59b5c
cont001_nova_scheduler_container-d75c5788
cont001_rabbit_mq_container-64d81a88
cont001_repo_container-1f05900c
cont001_utility_container-db4b0fe9
参考)実行するコマンド
11
controller$ sudo git clone https://github.com/openstack/openstack-
ansible /opt/openstack-ansible
controller$ vi openstack_user_config.yml
controller$ vi user_variables.yml
controller$ vi user_secret.yml
controller$ cd /opt/openstack-ansible/
controller$ sudo scripts/bootstrap-ansible.sh
controller$ cd /opt/openstack-ansible/playbooks/
controller$ sudo openstack-ansible setup-hosts.yml –vvv
controller$ sudo openstack-ansible haproxy-install.yml –vvv
controller$ sudo openstack-ansible setup-infrastructure.yml –vvv
controller$ sudo openstack-ansible setup-openstack.yml -vvv
1
2
3
4
5
6
7
8
9
10
11
コントローラノード
コントローラノード
今回構築したシステム③
12
コントローラノードに下記コンポーネントをデプロイ
コントローラノード
glance
galera
keystone
nova
controller
neutron horizon
heat
memcached rabbitmq
今回構築したシステム④
13
OpenStack
Management NW
(VLAN ID:2811)
VXLAN NW
(VLAN ID:2812)
Host NW
(VLANタグなし)
em2
.10〜12
172.28.1.0/24
br-vlan
VLAN NW
br-vlan
br-vxlan
em1.2811
em2.
2812
em1
em1.2811
em2.
2812
172.29.236.0/22
172.29.240.0/22
.10
em1
.62〜64
br-mgmt br-mgmt
br-vxlan
em
2×3台 ×2台
.65〜66
コントローラノード コンピュートノード
.13〜14
Global IP
システムの全体像
14
サーバ
L2/L3
fluentd
Elasticserch
Kibana
OpenStack
有識者
サーバ
運用ダッシュ
ボード
(Hatohol)
オペレータ
ZabbixAgent
Zabbix
OpenStack
仮想マシン 仮想マシン
インシデント
ナレッジ
管理
(Redmine)
コミュニ
ケーション
(Slack)
[ログ収集・分析・可視化]
Fluentd + Elasticserch + Kibana
[監視]
Zabbix + Hatohol
[ナレッジ・インシデント管理]
Redmine
[コミュニケーション]
Slack
可視化
ログ
収集
監視
ログ表示
ログ解析
ログ表示
モニタ
リング
チケット
発行
会話
会話
インシデント
ナレッジ記載
インシデント
ナレッジ表示
Fluentdについて
15
Fluentdとは・・・Treasure Data社が開発している
ログファイルの収集・転送・集約が行えるOSS
ログに正規表現でタグを付けしElasticserchに転送することで、
Kibanaを使用したログ解析・可視化を行える
生ログデータ
Fluentd
date 2016-05-07 14:06:05.569
pid 19670
level INFO
message neutron.agent.linux.daemon -
Process runs with uid/gid: 999/999
収集したログの内容にタグ付け
Elasticserch
タグ付けしたログを転送
ログを収集
2016-05-07 14:06:05.569 19670 INFO
neutron.agent.linux.daemon [-] Process runs
with uid/gid: 999/999
Elasticserch/Kibanaについて
16
Elasticserchとは・・・Elastic社が開発している
ビックデータの蓄積・解析が行えるOSS
Kibanaによって解析結果の可視化が可能
Hatoholについて
17
Hatoholとは・・・MIRACLE LINUX社が開発しているOSS
複数のZabbix・NagiosのGUIを1つにまとめて表示ができる
オペレータ
Zabbix Zabbix Zabbix
表示している
Zabbixの
画面多いな。。
リージョンA リージョンB リージョンC
Zabbix Zabbix Zabbix
リージョンA リージョンB リージョンC
オペレータ
複数のZabbixか
ら監視データを取
得・集約
運用ダッシュ
ボード
(Hatohol)
オペレータはHatohol
から登録されている
Zabbixの監視データと
閲覧する
ユーザ毎にフィルタを
定義し、予め表示させ
るイベント・障害を絞り
込める。
例)[Bリージョン]の
[〜アイテム]の[障害]
のみ表示
フィルタ
参考)Hatoholのアップデート計画
18
HatoholからRedmineの
チケットのステータス変更
Hatohol
インシデント
管理
(Redmine)
チケット
ステータス
対処中→終了
Hatohol
イベント
類似ナレッジ:http://・・・
対処法案:・・・・
イベント(Zabbixで検知した障害)
にテキストを付与
発生したイベントを
グループ化しまとめる
Hatohol
イベント
検知ホスト:nova-scheduler
イベント
検知ホスト:nova-API
イベント
検知ホスト:nova-conductor
イベント:Nova-controllerグループ HatoholLDAP
認証
LDAP認証
開発拠点が日本のため、
ユーザとしての要望を届けやすい。
本日のアジェンダ
• OpenStack共同検証ラボのご紹介
• 構築環境のご紹介
• ログ収集の仕組み
• クラウド監視の仕組み
• 運用オペレーションについて
• 今後のアクション
19
ログ収集のスコープ
サーバ
L2/L3
fluentd
Elasticserch
Kibana
OpenStack
有識者
サーバ
運用ダッシュ
ボード
(Hatohol)
オペレータ
ZabbixAgent
Zabbix
OpenStack
仮想マシン 仮想マシン
インシデント
ナレッジ
管理
(Redmine)
コミュニ
ケーション
(Slack)
可視化
ログ
収集
監視
ログ表示
ログ解析
ログ表示
モニタ
リング
チケット
発行
会話
会話
インシデント
ナレッジ記載
インシデント
ナレッジ表示
OpenStackログ
21
サービス ログファイル
Nova
(7ファイル)
/var/log/nova/nova-api-metadata.log
/var/log/nova/nova-compute.log
/var/log/nova/nova-scheduler.log
/var/log/nova/nova-api-os-compute.log
/var/log/nova/nova-cert.log
/var/log/nova/nova-conductor.log
/var/log/nova/nova-consoleauth.log
Keystone
(3ファイル)
/var/log/keystone/keystone-apache-error.log
/var/log/keystone/keystone.log
/var/log/keystone/ssl_access.log
Neutron
(9ファイル)
/var/log/neutron/neutron-dnsmasq.log
/var/log/neutron/neutron-ha-tool.log
/var/log/neutron/neutron-dhcp-agent.log
/var/log/neutron/neutron-l3-agent.log
/var/log/neutron/neutron-linuxbridge-agent.log
/var/log/neutron/neutron-metadata-agent.log
/var/log/neutron/neutron-metering-agent.log
/var/log/neutron/neutron-ns-metadata-proxy-*.log
/var/log/neutron/neutron-server.log
Glance
(2ファイル)
/var/log/glance/glance-api.log
/var/log/glance/glance-registry.log
Horizon
(2ファイル)
/var/log/horizon/horizon-error.log
/var/log/horizon/ssl_access.log
サービス ログファイル
Cinder
(3ファイル)
/var/log/cinder/cinder-volume.log
/var/log/cinder/cinder-scheduler.log
/var/log/cinder/cinder-api.log
RabbitMQ
(6ファイル)
/var/log/rabbitmq/rabbit*rabbit_mq_*.log
/var/log/rabbitmq/rabbit*_rabbit_mq_*sasl.log
/var/log/rabbitmq/shutdown_log
/var/log/rabbitmq/shutdown_err
/var/log/rabbitmq/startup_log
/var/log/rabbitmq/startup_err
GaleraCluster
(1ファイル)
/var/log/mysql_logs/galera_server_error.log
Memcached
(1ファイル)
/var/log/memcached.log
計34ファイル + syslog
(物理サーバ7台環境で
約120万行/日のログ出力)
ログ収集の処理フロー
22
[収集方針]
syslog及びOpenStackコンポーネントが出力するログをfluentdタグ付
けし、全ログを収集する。ログの絞り込みはKibanaで実施する。
Elasticserch
Kibana
OpenStack
有識者
転送 可視化
ログ絞り
込み
2016-05-07 12:00:00 WARN neutron.・・ Process
runs・・
Fluentd
date 2016-05-07 12:00:00
level WARN
message neutron.・・ Process runs with・・・
収集したログの内容にタグ付け
生ログデータ
2016-05-08 12:00:00 ERROR Nova・・neutron.・・
date 2016-05-08 12:00:00
level ERROR
message Nova・・neutron.・・
2016/05/07~2016/05/08
に出力されたneutronを含むロ
グのうちErrorの件数
・・2件
絞り込みフィルター
ログを収集
ログ収集設定管理フロー
23
[設定ファイル管理]
fluentdは正規表現でタグ付けを行っている。
タグ付けの対象の変更は設定ファイルの変更が必要
設定ファイルをgitを使ってバージョン管理することでデグレの防止、
Redmineで変更履歴管理を実施
2016-05-07 12:00:00 ・・・・ WARN neutron.・・
Fluentd
date 2016-05-07 12:00:00
level WARN
message neutron.・・ Process runs with・・・
生ログデータ
設定ファイルv1
正規表現A
設定ファイルv2
正規表現B
date 2016-05-07
time 12:00:00
level WARN
message neutron.・・ Process runs with・・・
git
設定ファイルv1
正規表現A
設定ファイルv2
正規表現B
バージョン
管理
ナレッジ
管理
(Redmine)
変更履歴
記載
ログを収集
タグ
付け
タグ
付け
本日のアジェンダ
• OpenStack共同検証ラボのご紹介
• 構築環境のご紹介
• ログ収集の仕組み
• クラウド監視の仕組み
• 運用オペレーションについて
• 今後のアクション
24
クラウド監視のスコープ
サーバ
L2/L3
fluentd
Elasticserch
Kibana
OpenStack
有識者
サーバ
運用ダッシュ
ボード
(Hatohol)
オペレータ
Zabbix
OpenStack
仮想マシン 仮想マシン
インシデント
ナレッジ
管理
(Redmine)
コミュニ
ケーション
(Slack)
可視化
ログ
収集
監視
ログ表示
ログ解析
ログ表示
モニタ
リング
チケット
発行
会話
会話
インシデント
ナレッジ記載
インシデント
ナレッジ表示
ZabbixAgent
監視対象
26
プロセス・ポート・ハードウェアリソース・ネットワーク死活監視
+OpenStack特有の項目として
API死活監視・MessageQueのキュー長を監視
OpenStackのコマンド及びHorizonから操作を行うと各コンポーネントのAPIが叩か
れ、APIサーバからMessageQueに命令リクエストが送信される
APIサービスダウン時は、命令リクエストが送信できず、操作不能となる。
API監視について
27
nova-
API
Message
Que
Horizon
コマンド
参考:http://openstack.jp/assets/files/20121216/osc2012cloudjosugamqpv2-121216085708-phpapp02.pdf
API
API
API
nova-
scheduler
nova-
compute
nova-boot
リクエスト
nova-boot
実行
APIがダウンしているため、
nova-bootリクエストが
MeesageQueに送信されない
リクエスト
はないな
新規
リクエストは
ないな
リクエストが
来るまで何も
しない
nova-boot
リクエスト
OpenStackのコンポーネント及びサービス間の通信は全てMessageQueを介して
行われるため、キューが溜まりやすい特徴がある。
キューが溜まりすぎると命令リクエストが正常に処理されず、OpenStack全体の動
作が不安定となりやすい
MessageQue監視について
28
nova-
API
Message
Que
参考:http://openstack.jp/assets/files/20121216/osc2012cloudjosugamqpv2-121216085708-phpapp02.pdf
nova-
scheduler
cinder-
scheduler
nova-boot
リクエスト
nova-boot
実行
nova-boot
リクエストnova-boot
リクエストnova-boot
リクエストnova-boot
リクエスト
cinder-list
実行
cinder-
API
cinder-list
リクエスト
キューが溢れると
新規命令リクエスト
が受け付けられない
nova-boot
リクエスト
MessageQueが処理
するキューより入る命
令リクエストが多いと
キューが溢れる
cinder-list
リクエスト
cinder-list
リクエスト
cinder-list
リクエスト
Zabbixの自動登録機能を使用し監視対象ホストの自動登録を実施
自動登録機能では、Agentに設定されたメタデータ・ホスト名で登録する監視対象
ホストに割り当てる監視テンプレートを指定
参考)監視対象の自動登録フロー
29
サーバ
Zabbix 3.0ZabbixAgent
Ansible
登録要求
インストール・
設定投入
keystone
keystone
監視対象として登録
割り当てテンプレート:keystone
アクション:管理外のAgentから
アクセス
ホスト名:keystone
メタデータ:BBTlab
投入される設定
ZabbixServerIP:xx.xx.xx.xx
Zabbix-agentホスト名:keystone
メタデータ:BBTlab 等
監視開始
Zabbixのネットワークディスカバリ機能を使用し監視対象ホストの登録解除を実施
特定サブネット上のZabbixAgentの応答確認を行い、応答が無くなった場合、
監視の停止→監視対象から除外が行われる
参考)監視対象の自動登録解除フロー
30
サーバ
Zabbix 3.0ZabbixAgent
keystone
nova compute
応答確
認:OK
サーバ
ZabbixAgent
nova compute
keystone
応答確
認:NG
ZabbixAgentから応答が無くなってから
48時間経過・・監視の停止
72時間経過・・監視対象から除外
本日のアジェンダ
• OpenStack共同検証ラボのご紹介
• 構築環境のご紹介
• ログ収集の仕組み
• クラウド監視の仕組み
• 運用オペレーションについて
• 今後のアクション
31
運用オペレーション
32
下記の障害時オペレーションについて記載
・ 障害時のオペレータの行動フロー
・ 障害時のOpenStack有識者の行動フロー
障害時オペレーション(オペレータ)
33
[オペレーション]
① Zabbixが障害を検知
OpenStack
仮想マシン 仮想マシン
サーバ
L2/L3
今回構築した環境
fluentd
Elasticserch
Kibana
OpenStack
有識者
インシデント
管理
(Redmine)
サーバ
運用ダッシュ
ボードツール
(Hatohol)
オペレータ
①
③
ZabbixAgent
Zabbix
②
④
⑤
② オペレータへエラー通知・Redmineチケット作成
③ オペレータは障害発生時刻のログ収集
④ ③のログ情報をチケットへ反映・過去ナレッジ検索
⑤ 過去ナレッジに情報があれば暫定対処
⑥ 重要度の高い障害はエスカレーション ナレッジ
管理
(Redmine)
Slack
④
⑥
⑥
障害時オペレーション(オペレータ)
34
① Zabbixが障害を検知しHatoholに通知
OpenStack
仮想マシン 仮想マシン
サーバ
L2/L3
今回構築した環境
fluentd
Elasticserch
Kibana
OpenStack
有識者
インシデント
管理
(Redmine)
サーバ
運用ダッシュ
ボードツール
(Hatohol)
オペレータ
①
③
ZabbixAgent
Zabbix
②
④
⑤
② オペレータへエラー通知・Redmineチケット作成
③ オペレータは障害発生時刻のログ収集
④ ③のログ情報をチケットへ反映・過去ナレッジ検索
⑤ 過去ナレッジに情報があれば暫定対処
⑥ 重要度の高い障害はエスカレーション ナレッジ
管理
(Redmine)
Slack
④
⑥
[オペレーション]
⑥
ZabbixAgent
障害時オペレーション(オペレータ)
35
① Zabbixが障害を検知しHatoholに通知
OpenStack
仮想マシン 仮想マシン
サーバ
L2/L3
今回構築した環境
fluentd
Elasticserch
Kibana
OpenStack
有識者
インシデント
管理
(Redmine)
サーバ
運用ダッシュ
ボードツール
(Hatohol)
オペレータ
①
Zabbix
② オペレータへエラー通知・Redmineチケット作成
③ オペレータは障害発生時刻のログ収集
④ ③のログ情報をチケットへ反映・過去ナレッジ検索
⑤ 過去ナレッジに情報があれば暫定対処
⑥ 重要度の高い障害はエスカレーション ナレッジ
管理
(Redmine)
Slack
⑥
②
[オペレーション]
③ ④
⑤
障害時オペレーション(OpenStack有識者)
36
[オペレーション]
OpenStack
仮想マシン 仮想マシン
サーバ
L2/L3
今回構築した環境
fluentd
Elasticserch
Kibana
OpenStack
有識者
インシデント
管理
(Redmine)
サーバ
運用ダッシュ
ボードツール
(Hatohol)
オペレータ
ZabbixAgent
Zabbix
⑤
④
Slack
②
②
①
ナレッジ
管理
(Redmine)
③③
① エスカレーション通知を受ける
② 有識者は現状確認・詳細なログ分析を実施
③ 原因特定後チケット・ナレッジを更新
④ チケットの更新がオペレータに通知される
⑤ 問題対処を実施
障害時オペレーション(OpenStack有識者)
37
[オペレーション]
OpenStack
仮想マシン 仮想マシン
サーバ
L2/L3
今回構築した環境
fluentd
Elasticserch
Kibana
OpenStack
有識者
インシデント
管理
(Redmine)
サーバ
運用ダッシュ
ボードツール
(Hatohol)
オペレータ
Zabbix
④
Slack
①
ナレッジ
管理
(Redmine)
① エスカレーション通知を受ける
② 有識者は現状確認・詳細なログ分析を実施
③ 原因特定後チケット・ナレッジを更新
④ チケットの更新がオペレータに通知される
⑤ 問題対処を実施
ZabbixAgent
②
③
本日のアジェンダ
• OpenStack共同検証ラボのご紹介
• 構築環境のご紹介
• ログ収集の仕組み
• クラウド監視の仕組み
• 運用オペレーションについて
• 今後のアクション
38
残タスク整理
• サービスを意図的に停止させるなどの疑似障害を発生させ、
監視アイテムやfluentdの対象ログを確認及び精度の向上
• Chaosmonky(障害発生ツール)を稼働させ、常に障害を発生
させる
• ログ解析ツール(Kibana)のユースケースの検討
• 運用ダッシュボードツール(Hatohol)のユースケースの検討
• ブラックリスト / ホワイトリスト の追加
39
今後のアクションについて
• API監視の深掘り
– API応答速度、複数API組み合わせた処理の監視
• 構成管理ツールを使用したプロビジョニング
• 監視&ログのデータ処理フローの高度化
40
Horizon
API監視の深堀り
41
APIの死活監視だけでは監視しにくいアイテム
・輻輳時のAPIの応答速度
・複数のAPI操作が必要となる機能の正常性
(Glanceイメージ登録→Neutronネットワーク作成→Novaインスタンス作成・・・ )
OpenStack
仮想マシン 仮想マシン
動くけど
応答が
遅い・・・
アクセス
APIサービス
レスポンス遅延
機能3
一部の機能に
異常発生
Zabbix
環境は
正常動作
ユーザ
オペレータ
機能2機能1
200:OK→正
常
API
Tempest + Rally の活用
42
OpenStackのTempest、Rallyコンポーネントを使用
・ Tempest・・・ OpenStackのプロジェクトの1つ
Novaインスタンスの作成→Novaインスタンスを削除といったシナリオに
沿ってOpenStackのテストを行える
・Rally・・・ OpenStackのプロジェクトの1つ
OpenStackの全体のベンチマークツール、Tempestのフレームワークとして
使用ができる
OpenStack
仮想マシン 仮想マシン
API
問題
Rally
限界性能の確認
高負荷時の動作確認
Tempest
手順1
手順2
手順3
用意されたテスト
ケースで異常を検知
新規
サーバ
構成管理ツールを使用したプロビジョニング
43
構成管理
ツール
オペレータ
Ansible
プロビジョニング
サーバのハードウェア情
報・ラック搭載位置・配線
等の情報を登録
オペレータ
新しいサーバ
の情報を登録
新しいサーバ
をコンピュート
ノードにしたい
登録されているサーバ情報か
らAnsibleのプロビジョニング
定義ファイル生成し、構成情報
を更新
OpenStack
コンピュート
ハードウェア等の資産情報管理やOpenStackのプロビジョニングの自動化を行う
ために構成管理ツールの導入を検討
参考)
NTT Docomo様での取り組みイメージ
44
出典:http://www.slideshare.net/VirtualTech-JP/ntt-openstack-summit-2015-tokyo-after-one-year-of-openstack-cloud-operation-ntt-docomo
45
出典:http://www.slideshare.net/VirtualTech-JP/ntt-openstack-summit-2015-tokyo-after-one-year-of-openstack-cloud-operation-ntt-docomo
参考)
NTT Docomo様での取り組みイメージ
ログ監視の問題
46
Elastic
search
120万件/日
Zabbixで120万件/日ログ処理が必要となり、Zabbixのテキスト処理の
処理が追いつかず、パフォーマンス問題が発生する可能性がある。
また、仮にZabbixで「Error」をトリガーに監視した場合、Hatoholから
Redmineへ大量の通知が発生する
Hatohol
16.04
Redmine
3.2.04万エラー/日 エラー通知
Slack
Maria
DB
ZabbixAgent
Zabbix
3.0
チケット
Zabbixのテキスト処理能力問題
MarriaDBのデータサイズ肥大
チケット
チケット
チケット
チケット
チケットの
大量生成
チケット
チケット
チケット
チケット
チケット
チケット
チケット
チケット
チケット
チケット
チケット
チケット
チケット
チケット
チケット

OpenStack本番環境の作り方