OpenStack本番環境の作り方
•Download as PPTX, PDF•
2 likes•2,837 views
アジェンダ - OpenStack共同検証ラボのご紹介 - 構築環境のご紹介 - ログ収集の仕組み - クラウド監視の仕組み - 運用オペレーションについて - 今後のアクション
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to OpenStack本番環境の作り方
Similar to OpenStack本番環境の作り方 (20)
More from VirtualTech Japan Inc.
More from VirtualTech Japan Inc. (20)
Recently uploaded
Recently uploaded (8)
OpenStack本番環境の作り方
- 2. 本日のアジェンダ • OpenStack共同検証ラボのご紹介 • 構築環境のご紹介 • ログ収集の仕組み • クラウド監視の仕組み • 運用オペレーションについて • 今後のアクション 2
- 4. OpenStack共同検証ラボとは • ブロードバンドタワー様のデータセンター施設を 利用し、検証環境を用意いたします。 • 『OpenStack共同検証ラボ』に協賛いただく会社を 募り、協賛企業の皆様と共に検証を行います。 – 協賛企業の皆様は検証テーマを提案できます。 – 本ラボが提案した検証テーマに参画いただくことも可 能です。 • 『OpenStack共同検証ラボ』で得たノウハウや知 見をドキュメント化し、ドキュメントを一般公開い たします。 4
- 5. OpenStack共同検証ラボ 概要 • 当初は2つのゾーンを用意 • ゾーンは3ヶ月~6ヶ月の周期で環境構築・調査・報告作成 を繰り返していく。 5 • SDN/NFV製品の機能 検証 • パフォーマンス検証 • 可用性検証 • SDN/NFV製品の運 用・トラブルシューティ ング など • 基盤の運用・監視ツー ルの機能検証 • 自動化ツールの機能検 証 • 基盤の運用・トラブル シューティング など SDN/NFVゾーン DevOpsゾーン
- 7. 本日のアジェンダ • OpenStack共同検証ラボのご紹介 • 構築環境のご紹介 • ログ収集の仕組み • クラウド監視の仕組み • 運用オペレーションについて • 今後のアクション 7
- 8. 今回構築したシステム① 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. 今回構築したシステム② 9 OpenStack-Ansible(Kiloバージョン)を使用し環境構築 サーバ#1 サーバ#2 サーバ#3 サーバ#4 サーバ#5 サーバ#6 コントローラノード コンピュートノード ログ保存 ・ログ分析 サーバ サーバ#7 監視 サーバ OpenStack コントローラ OpenStack コントローラ OpenStack コントローラ
- 11. 参考）実行するコマンド 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
- 13. 今回構築したシステム④ 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. システムの全体像 14 サーバ L2/L3 fluentd Elasticserch Kibana OpenStack 有識者 サーバ 運用ダッシュ ボード （Hatohol） オペレータ ZabbixAgent Zabbix OpenStack 仮想マシン 仮想マシン インシデント ナレッジ 管理 （Redmine） コミュニ ケーション (Slack) [ログ収集・分析・可視化] Fluentd + Elasticserch + Kibana [監視] Zabbix + Hatohol [ナレッジ・インシデント管理] Redmine [コミュニケーション] Slack 可視化 ログ 収集 監視 ログ表示 ログ解析 ログ表示 モニタ リング チケット 発行 会話 会話 インシデント ナレッジ記載 インシデント ナレッジ表示
- 15. 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
- 17. Hatoholについて 17 Hatoholとは・・・MIRACLE LINUX社が開発しているOSS 複数のZabbix・NagiosのGUIを１つにまとめて表示ができる オペレータ Zabbix Zabbix Zabbix 表示している Zabbixの 画面多いな。。 リージョンA リージョンB リージョンC Zabbix Zabbix Zabbix リージョンA リージョンB リージョンC オペレータ 複数のZabbixか ら監視データを取 得・集約 運用ダッシュ ボード （Hatohol） オペレータはHatohol から登録されている Zabbixの監視データと 閲覧する ユーザ毎にフィルタを 定義し、予め表示させ るイベント・障害を絞り 込める。 例)[Bリージョン]の [〜アイテム]の[障害] のみ表示 フィルタ
- 19. 本日のアジェンダ • OpenStack共同検証ラボのご紹介 • 構築環境のご紹介 • ログ収集の仕組み • クラウド監視の仕組み • 運用オペレーションについて • 今後のアクション 19
- 22. ログ収集の処理フロー 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. ログ収集設定管理フロー 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） 変更履歴 記載 ログを収集 タグ 付け タグ 付け
- 24. 本日のアジェンダ • OpenStack共同検証ラボのご紹介 • 構築環境のご紹介 • ログ収集の仕組み • クラウド監視の仕組み • 運用オペレーションについて • 今後のアクション 24
- 30. Zabbixのネットワークディスカバリ機能を使用し監視対象ホストの登録解除を実施 特定サブネット上のZabbixAgentの応答確認を行い、応答が無くなった場合、 監視の停止→監視対象から除外が行われる 参考)監視対象の自動登録解除フロー 30 サーバ Zabbix 3.0ZabbixAgent keystone nova compute 応答確 認:OK サーバ ZabbixAgent nova compute keystone 応答確 認:NG ZabbixAgentから応答が無くなってから 48時間経過・・監視の停止 72時間経過・・監視対象から除外
- 31. 本日のアジェンダ • OpenStack共同検証ラボのご紹介 • 構築環境のご紹介 • ログ収集の仕組み • クラウド監視の仕組み • 運用オペレーションについて • 今後のアクション 31
- 33. 障害時オペレーション(オペレータ) 33 [オペレーション] ① Zabbixが障害を検知 OpenStack 仮想マシン 仮想マシン サーバ L2/L3 今回構築した環境 fluentd Elasticserch Kibana OpenStack 有識者 インシデント 管理 （Redmine） サーバ 運用ダッシュ ボードツール （Hatohol） オペレータ ① ③ ZabbixAgent Zabbix ② ④ ⑤ ② オペレータへエラー通知・Redmineチケット作成 ③ オペレータは障害発生時刻のログ収集 ④ ③のログ情報をチケットへ反映・過去ナレッジ検索 ⑤ 過去ナレッジに情報があれば暫定対処 ⑥ 重要度の高い障害はエスカレーション ナレッジ 管理 （Redmine） Slack ④ ⑥ ⑥
- 34. 障害時オペレーション(オペレータ) 34 ① Zabbixが障害を検知しHatoholに通知 OpenStack 仮想マシン 仮想マシン サーバ L2/L3 今回構築した環境 fluentd Elasticserch Kibana OpenStack 有識者 インシデント 管理 （Redmine） サーバ 運用ダッシュ ボードツール （Hatohol） オペレータ ① ③ ZabbixAgent Zabbix ② ④ ⑤ ② オペレータへエラー通知・Redmineチケット作成 ③ オペレータは障害発生時刻のログ収集 ④ ③のログ情報をチケットへ反映・過去ナレッジ検索 ⑤ 過去ナレッジに情報があれば暫定対処 ⑥ 重要度の高い障害はエスカレーション ナレッジ 管理 （Redmine） Slack ④ ⑥ [オペレーション] ⑥
- 35. ZabbixAgent 障害時オペレーション(オペレータ) 35 ① Zabbixが障害を検知しHatoholに通知 OpenStack 仮想マシン 仮想マシン サーバ L2/L3 今回構築した環境 fluentd Elasticserch Kibana OpenStack 有識者 インシデント 管理 （Redmine） サーバ 運用ダッシュ ボードツール （Hatohol） オペレータ ① Zabbix ② オペレータへエラー通知・Redmineチケット作成 ③ オペレータは障害発生時刻のログ収集 ④ ③のログ情報をチケットへ反映・過去ナレッジ検索 ⑤ 過去ナレッジに情報があれば暫定対処 ⑥ 重要度の高い障害はエスカレーション ナレッジ 管理 （Redmine） Slack ⑥ ② [オペレーション] ③ ④ ⑤
- 36. 障害時オペレーション(OpenStack有識者) 36 [オペレーション] OpenStack 仮想マシン 仮想マシン サーバ L2/L3 今回構築した環境 fluentd Elasticserch Kibana OpenStack 有識者 インシデント 管理 （Redmine） サーバ 運用ダッシュ ボードツール （Hatohol） オペレータ ZabbixAgent Zabbix ⑤ ④ Slack ② ② ① ナレッジ 管理 （Redmine） ③③ ① エスカレーション通知を受ける ② 有識者は現状確認・詳細なログ分析を実施 ③ 原因特定後チケット・ナレッジを更新 ④ チケットの更新がオペレータに通知される ⑤ 問題対処を実施
- 37. 障害時オペレーション(OpenStack有識者) 37 [オペレーション] OpenStack 仮想マシン 仮想マシン サーバ L2/L3 今回構築した環境 fluentd Elasticserch Kibana OpenStack 有識者 インシデント 管理 （Redmine） サーバ 運用ダッシュ ボードツール （Hatohol） オペレータ Zabbix ④ Slack ① ナレッジ 管理 （Redmine） ① エスカレーション通知を受ける ② 有識者は現状確認・詳細なログ分析を実施 ③ 原因特定後チケット・ナレッジを更新 ④ チケットの更新がオペレータに通知される ⑤ 問題対処を実施 ZabbixAgent ② ③
- 38. 本日のアジェンダ • OpenStack共同検証ラボのご紹介 • 構築環境のご紹介 • ログ収集の仕組み • クラウド監視の仕組み • 運用オペレーションについて • 今後のアクション 38
- 39. 残タスク整理 • サービスを意図的に停止させるなどの疑似障害を発生させ、 監視アイテムやfluentdの対象ログを確認及び精度の向上 • Chaosmonky(障害発生ツール)を稼働させ、常に障害を発生 させる • ログ解析ツール(Kibana)のユースケースの検討 • 運用ダッシュボードツール(Hatohol)のユースケースの検討 • ブラックリスト / ホワイトリスト の追加 39
- 40. 今後のアクションについて • API監視の深掘り – API応答速度、複数API組み合わせた処理の監視 • 構成管理ツールを使用したプロビジョニング • 監視＆ログのデータ処理フローの高度化 40
- 42. Tempest + Rally の活用 42 OpenStackのTempest、Rallyコンポーネントを使用 ・ Tempest・・・ OpenStackのプロジェクトの1つ Novaインスタンスの作成→Novaインスタンスを削除といったシナリオに 沿ってOpenStackのテストを行える ・Rally・・・ OpenStackのプロジェクトの１つ OpenStackの全体のベンチマークツール、Tempestのフレームワークとして 使用ができる OpenStack 仮想マシン 仮想マシン API 問題 Rally 限界性能の確認 高負荷時の動作確認 Tempest 手順１ 手順2 手順3 用意されたテスト ケースで異常を検知