Openstack Days Tokyo 2105に行って、聞いてきた話の続き
次は
使って分かった現場担当者が語るOpenStack運用管理の課題
講師:ミラクルな人と、日本仮想化技術の玉置さん
をメモメモ
OpenStackの運用上の課題
・管理対象のサーバーが莫大:物理マシン1万台も?
・スケールアウト前提
・運用上の効率化が求められる:1人で1000台
・障害検知
OpenStack環境の特徴
・大量の物理マシン、ハイパーバイザー
→故障頻発
・物理マシン増減する→壊れたら、増強したら
運用の効率化にむけて
・監視アプローチの0変更
サービスの継続
壊れたマシン切り離し→原因究明は後回し
きっかけを見つけること大事
検知→自動化
・Zabbix:OSSの監視ソフト
Miracle z VX
→テンプレート、無償公開
・Zabbixによる監視システム
監視マネージャー:重い
→スケールアウト必須
hatohol
スケールアウトした監視サーバーを統合
インシデント自動登録
Hatohol
だれでも最新ソースへアクセスできる
構成概念
監視対象:一覧で確認できる
スケールアウト
Hatoholのオーケストレーション
Zabbixはインスタンス入らないから落とすを理解しない
→あんりーちゃぶるになる
→APIで事前削除
マルチテナント構成
Hatoholで実現する運用管理
これからのインフラ管理
OpenStack環境の課題
障害検知
・API
・キュー
命令出しても即時終了しない
プローブ
パラダイムシフト
・カオスモンキー:統合
・アノーマリ:
・自動学習
次は
使って分かった現場担当者が語るOpenStack運用管理の課題
講師:ミラクルな人と、日本仮想化技術の玉置さん
をメモメモ
OpenStackの運用上の課題
・管理対象のサーバーが莫大:物理マシン1万台も?
・スケールアウト前提
・運用上の効率化が求められる:1人で1000台
・障害検知
OpenStack環境の特徴
・大量の物理マシン、ハイパーバイザー
→故障頻発
・物理マシン増減する→壊れたら、増強したら
運用の効率化にむけて
・監視アプローチの0変更
サービスの継続
壊れたマシン切り離し→原因究明は後回し
きっかけを見つけること大事
検知→自動化
・Zabbix:OSSの監視ソフト
Miracle z VX
→テンプレート、無償公開
・Zabbixによる監視システム
監視マネージャー:重い
→スケールアウト必須
hatohol
スケールアウトした監視サーバーを統合
インシデント自動登録
Hatohol
だれでも最新ソースへアクセスできる
構成概念
監視対象:一覧で確認できる
スケールアウト
Hatoholのオーケストレーション
Zabbixはインスタンス入らないから落とすを理解しない
→あんりーちゃぶるになる
→APIで事前削除
マルチテナント構成
Hatoholで実現する運用管理
これからのインフラ管理
OpenStack環境の課題
障害検知
・API
・キュー
命令出しても即時終了しない
プローブ
パラダイムシフト
・カオスモンキー:統合
・アノーマリ:
・自動学習