[OpenStack Days Tokyo 2015] Zabbixを用いたOCPベアメタル監視環境構築の自働化

Transcript

• 1. Zabbixを用いたOCPベアメタル監視環境構築の自動化 2015年2月3日 TIS株式会社 松井 暢之
• 2. 2 松井 暢之（まつい のぶゆき） TIS株式会社 コーポレート本部 戦略技術センター ～2003 2003～2008 2009 2010～2012 2013～ 現場PJでアーキテクト兼モデラー兼プログラマ兼…を歴任 基盤技術センター（現戦略技術センター）で不芳PJの火消しに奔走 全社生産性向上の企画策定に従事 オープンでエッジな技術を活用した事業企画に従事 Cloud Orchestrator “CloudConductor®” の企画開発とOSS化開始 http://cloudconductor.org nbyk.matsui nmatsui nbyk.matsui @n_matsui
• 3. 3 TIS株式会社 (TIS Inc.) 昭和46年（1971年）4月28日 231億円 6,077人 （2014年4月1日現在） 代表取締役会長 兼 社長 桑野 徹 1,483億円 （2013年3月期単体） 社 名 設 立 資 本 金 従 業 員 代 表 者 売 上 高 TISの会社概要 経済産業省情報セキュリティ監査企業台帳登録 経済産業省システム監査企業台帳登録 届出電気通信事業者 情報通信ネットワーク安全・信頼性対策実施登録 プライバシーマーク使用許諾事業者 ISO9001 ISO／IEC27001 ISO／IEC20000 ISO14001 東京都一般建設業 （ 電気通信工事 ） CMM (Capability Maturity model ) レベル3評定 拠 点 認定資格 ITホールディングスグループのTISは、SI・受 託開発に加え、データセンターやクラウドなど サービス型のITソリューションを多数用意して います。同時に、中国・ASEAN地域を中心と したグローバルサポート体制も整え、金融、製 造、流通/サービス、公共、通信など様々な業 界で3,000社以上のビジネスパートナーとして、 お客様の事業の成長に貢献しています。 九州支社 名古屋ｱｰﾊﾞﾝﾈｯﾄｵﾌｨｽ 浜松オフィス 松本オフィス 長野オフィス 北京駐在員事務所 ホーチミン駐在員事務所 ジャカルタ駐在員事務所 バンコク駐在員事務所 東京第1センター 東京第2センター 東京第3センター 名古屋センター 師勝センター 大阪センター 心斎橋ｇDC 天津IDC 心斎橋gDC-EX GDC御殿山
• 4. 1. 活動の背景と目的 2. ベアメタル監視環境の自動構築検証 3. 今後の展望とCloudConductor 4 本日の内容
• 5.  プライベートクラウド市場の拡大†  2013年度のクラウド市場は6,257億円、2018年度には2.9倍の1兆8,000億円まで拡大  そのうちプライベートクラウドの比率は2013年度で70.1%を占めるが、2018年度には 73.0%と緩やかにシェアを高める 5 活動の背景 † MM総研, "国内クラウドサービス需要動向(2014年版)“, 2014-11, http://www.m2ri.jp/newsreleases/main.php?id=010120141104500
• 6.  OpenStackに代表されるOSSのクラウドOSの隆盛†  利用しているプライベートクラウド環境はVMWare vSphere/vCloudが最も多く31% 検証中・計画中もあわせるとOpenStackはVMWare vSphere/vCloudに比肩する  OpenStackの利用企業は2013年と比べてほぼ倍増 6 活動の背景 † RightScale, "Cloud Computing Trends: 2014 State of the Cloud Survey“, 2014-04, http://assets.rightscale.com/uploads/pdfs/RightScale-2014-State-of-the-Cloud-Report.pdf
• 7.  電気料金の高騰†  震災前に比べ、一般家庭部門（電灯料金）の平均単価は約2割上昇  工場、オフィス等の産業用（電力料金）の平均単価は約3割上昇 7 活動の背景 † 経済産業省 資源エネルギー庁, “平成25年度エネルギーに関する年次報告（エネルギー白書2014）", 2014-06, http://www.enecho.meti.go.jp/about/whitepaper/2014pdf/
• 8.  電力効率に優れたオープンなデータセンター・ハードウェア  一般的なDCの電力効率（PUE）は1.5～2.0と言われている† （日本でもPUE1.1台の高効率なDCが作られてきているが、まだ主流になっていない）  FacebookのDCはPUE1.0台を達成しており‡、その高効率なDC・H/Wの仕様を Open Compute Projectというコミュニティで公開している 8 活動の背景 ‡ Facebook, "Prineville - Facebook Power“, 2015-01, https://www.fbpuewue.com/prineville † Datacenter Knowledge, "Survey: Industry Average Data Center PUE Stays Nearly Flat Over Four Years “, 2014-06, http://www.datacenterknowledge.com/archives/2014/06/02/survey-industry-average-data-center-pue-stays-nearly-flat-four-years/
• 9.  A社プライベートクラウドにおける仮想マシン構築リードタイム† 9 活動の背景 プライベートクラウド 運用担当 基盤担当 システム管理担当 保守担当 統合運用監視システム 担当 作業フロー 業務システム 開発者 クラウド基盤 保守 キ ッ ク オ フ ヒアリング シート記入 ヒアリング シート確認 マシン作成 報告書作成 マシン作成 報告書確認 マシン作成 マ シ ン 確 認 1~2週間（3~5人日） 1~2週間（3~5人日） 1週間（2~3人日） 1週間（2~3人日） 0.5~1週間（1~3人日）構築準備 4.5~7週間（11~19人日） 0.2~0.5週間（1~2人日） 1週間（1~3人日） 構築作業 0.2~0.5週間（1~2人日） 構築確認 1週間（1~3人日） † TIS, “運用側面からのCloudConductor調査“ 2014-03, http://download.cloudconductor.org/ whitepaper/運用側面からのCloudConductor評価.pdf
• 10.  目的  クラウドを構成するリソースの統合監視の構築を可能な限りスケールするように自動化 ・自律化するオープンな技術を確立する  ポイント  Open Compute Project準拠のオープンなH/Wで動作を確認する  広く使われているOSSの統合監視ツールを活用する  対象のベアメタルをネットワークに接続し電源をONにすれば、H/WとOSを対応付け 監視を自動的に開始する  監視負荷を分散させるために、最適な監視サーバへ対象ノードを自律的に振り分ける  今回ベアメタルプロビジョニングは、IronicではなくCobblerを採用  Kiloで正式プロジェクトへ昇格した暁には・・・ 10 活動の目的
• 11. 1. 活動の背景と目的 2. OCPベアメタル監視環境の自動構築検証 3. 今後の展望とCloudConductor 11 本日の内容
• 12.  Open Compute Project準拠のベアメタル：Quanta F03A, F03C  Quanta社製のOCP準拠サーバ  F03Cは1筐体に3ノード、F03Aは1筐体に4ノード格納されるが、 今回はF03Cを1ノード、F03Aを1ノード用いる 12 オープンなハードウェア F03C F03A
• 13.  ベアメタルプロビジョニング：Cobbler  http://www.cobblerd.org/  ベアメタルへOSやミドルウェアを遠隔から自動プロビジョニングするためのPython製 のツール群  PXEブート時にベアメタルにインストールするOSイメージの管理  kickstartのテンプレート管理  yumやaptのリポジトリミラー  等 13 オープンなソフトウェア
• 14.  OSS統合監視ツール：Zabbix  http://www.zabbix.com/  マルチプラットフォームに対応した、OSSの統合監視ツール  「監視」→「監視結果の視覚化」→「監視結果に応じたアクション(メール通知・ コマンド実行)」が統合的に管理可能 14 オープンなソフトウェア
• 15.  OCPベアメタルへのZabbix Server & Zabbix Proxy自動構築  ESXi上のCobblerを用い、OCPベアメタルへZabbix ServerやZabbix Proxyを自動構築 15 検証①：Zabbix Server & Zabbix Proxy自動構築 LOM F03A LOM F03C Cobbler VMWare vSphere ESXi 10.10.10.0/24 DHCPd TFTPd HTTPd PXEBoot OS Image Repository Mirror kickstart template ・Zabbix Package ・Zabbix Install Script IPMI：.12IPMI：.15 ・CentOS6.6イメージ 構築前 LOM LOM Cobbler VMWare vSphere ESXi IPMI：.12IPMI：.15 DHCPd TFTPd HTTPd PXEBoot OS Image Repository Mirror kickstart template OS：.XX OS：.YY PXEBootされたOSのIPアドレスは DHCPで動的に払い出し Zabbix Server Zabbix Proxy ベアメタル上にCentOS6.6を自動インストールし、 Zabbix Server（Zabbix Proxy）をプロビジョニング 構築後
• 16.  Zabbix Server構築時の処理の流れ（Zabbix Proxyも同様） 1. Cobblerのkickstartにより、Zabbixサーバ構築スクリプト実行 (cobbler/kickstart/ZabbixServer-Cent6-x86_64.ks & cobbler/snippets/pre_install_zabbix_server) 2. Zabbix Serverセットアップスクリプトが自動起動 （scheduler/caller_server.py） ① Zabbixサーバのホスト名取得 ② テンプレートの割り当て（template/zbx_export_templates.xml） ③ アクションの設定 i. IPMI情報登録用ミニOSの自動登録時に起動するアクション ii. IPMIインタフェース更新時に起動するアクション iii. Zabbix Agentインタフェース更新時に起動するアクション iv. Zabbix Proxy構築時に起動するアクション 16 検証①：Zabbix Server & Zabbix Proxy自動構築
• 17.  Zabbixを用いたベアメタル自動監視  ZabbixへベアメタルのH/W監視を自動登録  プロビジョニングされたOSの監視を、H/Wと対応付けて自動登録  設定したルールに従い、適切なZabbix Proxyへ自動振り分け 17 検証②：Zabbixを用いたベアメタル自動監視 Cobbler VMWare vSphere ESXi PXEBoot OS Image Repository Mirror kickstart template Zabbix Server Zabbix Proxy ・HW登録用ミニOSイメージ ・実OSイメージ 検証用のベアメタルが足りなかったため、 Zabbix ServerとProxyは仮想環境に構築 LOM LOM F03A F03C 監視登録前 Cobbler VMWare vSphere ESXi PXEBoot OS Image Repository Mirror kickstart template Zabbix Server Zabbix Proxy LOM LOM 実OS 実OS プロビジョニング時に、IPMIと 対応付けてOSやM/Wを監視登録 Pahse2（実OSプロビジョニング） LOM Cobbler VMWare vSphere ESXi PXEBoot OS Image Repository Mirror kickstart template Zabbix Server LOM Zabbix ProxyミニOS ミニOS 登録された監視対象ノードをルールに 従って適切なProxyへ振り分け Pahse1（NWと電源へ接続） HW登録用のミニOSを自動起動し IPMI情報をZabbixへ登録 実OSが起動していなくても IPMI経由でH/W監視は実行される H/WとOSを対応付け 統合監視
• 18.  Phase1：H/W接続時に対象ノードのIPMI情報をZabbixへ自動登録 18 検証②：Zabbixを用いたベアメタル自動監視 ベアメタル Cobbler Zabbix Server Zabbix Proxy ミニOSでPXEブート ミニOS起動 Zabbix Agent導入 Zabbix Agentが 自動登録情報を送付 ベアメタルを監視対象 ホストとして追加 IPMI IPアドレスの 取得処理起動 ミニOSに同梱された dcmitoolでIPMI情報取得 IPMIインタフェースの登録 Agent自動登録機能 HostMetadata内に”OCP STARTER”である事のフラグを 埋め込む SSH Agent機能 適切なProxyを割り当て IPMI監視情報の送付先 IPアドレス更新 IPMI監視テンプレート割当 トラッパーアクション追加 Agentインタフェース削除 Zabbix Agentでリモートコマンド実行 IPMI監視開始 Agent自動登録時のアクション により一連の処理を自動化 IPMI経由でH/W情報 を送信
• 19.  ミニOSのZabbix Agent自動登録時に起動するアクション （scheduler/caller_action.py “UpdateIpmiInterfaces” <client hostname>） 1. SSH Agentのテンプレートを割り当て、対象サーバのIPMIアドレスを取得 2. 対象サーバをZabbixへ登録しIPMI情報を変更 3. IPMIのログイン設定情報を変更 4. ホストグループへ割り当て 5. IPMIより取得した製品名から、適切なテンプレートを割り当て 6. スケジューラを呼び出し、適切なZabbix Proxyを割り当て 7. 不要になったSSH Agentテンプレートを削除 8. 不要になったミニOSのZabbix Agentインタフェースを削除 19 検証②：Zabbixを用いたベアメタル自動監視
• 20.  Phase1：H/W接続時に対象ノードのIPMI情報をZabbixへ自動登録  デモ動画 20 検証②：Zabbixを用いたベアメタル自動監視
• 21.  Phase2：プロビジョニングする実OSの監視設定をZabbixへ自動登録 21 検証②：Zabbixを用いたベアメタル自動監視 ベアメタル Cobbler Zabbix Server Zabbix Proxy 実OSでPXEブート 実OS起動 Zabbix Agent導入 Zabbix Agentが 実OSの情報を送付 zabbix_trapperで ホスト名とIPを受信 Agentインタフェース登録 監視テンプレート割当 ホスト名から登録済み H/W情報と対応付け zabbix_sender 自身のホスト名と実OSのIPアドレスをZabbix Serverへ送信 trapper受信時のアクション により一連の処理を自動化 割り当てられた Proxyを確認 Zabbix API呼び出し OS監視情報の送付先 IPアドレス更新 OSやミドルウェアの監視開始 Zabbix AgentがOSや MWの監視情報を送信
• 22.  プロビジョニングする実OSの監視設定をZabbixへ自動登録する流れ 1. Cobblerのkickstartにより、Zabbix Agent構築スクリプト実行 (cobbler/kickstart/<target os kickstart.ks> & cobbler/snippets/pre_install_zabbix_agent) 2. Zabbix Agentセットアップスクリプトが自動起動 (scheduler/client_startup/zabbix_client_startup.py <server ipaddress> <zabbix server username> <zabbix server password> <host name> <client ipaddress>) 1. Zabbix APIを呼び出し、自身に割り当てられたZabbix Proxyを取得 2. 実OSの監視情報の送信先を書き換え 3. zabbix_senderを用いて実OSの情報をzabbix_trapperに送信 3. zabbix_trapperに実OSの情報が着信した際に起動するアクション （scheduler/caller_action.py “UpdateAgentInterfaces” <client hostname>） 1. Zabbix Agentインタフェースを当該ホストへ追加登録 2. Zabbix Agnetインタフェースへ適切なテンプレートを割り当て 22 検証②：Zabbixを用いたベアメタル自動監視
• 23.  Phase2：プロビジョニングされたOSの監視情報をZabbixへ自動登録  デモ動画 23 検証②：Zabbixを用いたベアメタル自動監視
• 24.  Proxyの割り当て処理はRuleクラスとScheduleクラスへ切り出されており、柔軟に変更可能  今回はIPMIのIPアドレスレンジに基づいて静的に割り当てるルールを実装した  各Proxyの負荷状況を元に動的に最適なProxyを選択して割り当てるルール等も実装可能 24 適切なZabbix Proxyの自動割当
• 25. 25 適切なZabbix Proxyの自動割当
• 26.  今回の検証で用いた各種スクリプト類  Baremetal AutoDiscovery Tool for Zabbix（近日公開予定） https://github.com/tech-sketch/baremetal_ad  Python 2.6系  Apache License Version2 26 ソースコードの公開
• 27. 1. 活動の背景と目的 2. OCPベアメタル監視環境の自動構築検証 3. 今後の展望とCloudConductor 27 本日の内容
• 28.  Ceilometerへの対応  CeilometerでH/WやVMを監視し、何か障害が発生した際にActionを起こす設定 ノウハウは、まだ蓄積されていない → 現状ではまだZabbixに一日の長がある  Ironicへの対応  Nova APIでベアメタルを操作できる価値は高い → Ironicが安定した際にはCobblerからの移植を検討したい → ただしDeploy kernel/ramdisk BootとUser image Bootの各ステップで、本検証と 同様の操作ができるか要検証 → CloudConductorでの操作が可能になる （TISが開発しOSS公開しているクラウドオーケストレータ） 28 今後の展望 http://cloudconductor.org
• 29.  デザイン指向クラウドオーケストレータ CloudConductor  インフラ・運用のノウハウを込めたパターンを中心に、いつでも誰でもどのクラウドに でも、その時点で最適な非機能要件を持ったシステムを簡単に構築するツール 29 CloudConductorとは
• 30.  Infrastructure Design Patterns as Code  インフラ・運用のノウハウを依存関係を整理してパターン化  パターンを機械可読な形式で集積し、集合知化 30 CloudConductorの特徴① CloudFormation Template Chef Cookbook ServerSpec TestCode …
• 31.  Everyone, EveryTime & EveryCloud  必要なパターンを組み合わせて誰でも最適なインフラ設計を獲得  クラウドを跨りデータを遍在化させ、どのクラウドでもシステムを再現 （現在はAWSとOpenStack） 31 CloudConductorの特徴② Packerで生成したGlance Image Heat APIを利用
• 32.  OnDemand Service Level  「負荷分散」「災害対策」「ログ分析」等の非機能要件は最初から作りこまず、必要に なった段階で適用したシステムへ乗り換え 32 CloudConductorの特徴③
• 33. 33 CloudConductorを用いた災害対策実証実験
• 34.  宮城県登米市・慶應大学・TISで災害対策の実証実験を実施  CloudConductorを用いたシステムのクラウド間フェイルオーバー（2014/11/07） 34 CloudConductorを用いた災害対策実証実験
• 35.  実証実験の様子 35 CloudConductorを用いた災害対策実証実験
• 36.  クラウド間フェイルオーバーさせたシステムのスペック  通常系：OpenStack Icehouse上のVM（シングルノード）  災対系：Amazon EC2 東京リージョン上のVM（シングルノード）  システムの再構築に要した時間 = 6分53秒 36 CloudConductorを用いた災害対策実証実験 CPU 2コア RAM 4GB Storage 20GB CPU 4コア RAM 7.5GB Storage 2×40GB 時刻 経過時間 イベント 7:05:50 00:00 災害発生（人為的にNICをダウン） 7:06:05 00:15 CloudConductorによる障害検知 7:06:21 00:31 CloudConductorによるシステム再構築開始 7:12:43 06:53 システム復旧
• 37.  統合監視を含めたシステム全体を様々なクラウドへCloudConductorから自動構築し、 マルチクラウド管理プラットフォームを構成する 37 最終的なイメージ Proxy Node Neutron Node Nova Node VM VM VM Controller NodeSwift Node Cinder Node Monitoring Server Monitoring Server スケールする監視環境 自身の自動構築 監視ノードの 自動振り分け 起動時にベアメタルの H/Wを自動登録 BareMetal Node 各ベアメタルを 自動で監視 構築されたVMを 自動で監視 物理・仮想NWを 自動で監視 物理・仮想ストレージを 自動で監視
• 38. 38 CloudConductorの情報公開 公式サイト http://cloudconductor.org ソーシャル https://twitter.com/ccndctr https://www.facebook.com/cloudconductor https://github.com/cloudconductor http://www.slideshare.net/cloudconductor
• 39.  TISブースにてCloudConductorの出展をしております。よろしければご立ち寄りください。 39 CloudConductorのブース ココ
• 40.  本検証を進めるにあたり、Cobblerによる監視環境自動構築の実現方法について、多くの示 唆を頂いたOpen Compute Project Japan Proof of Concept WG の方々に感謝いたします。  本検証を進めるにあたり、検証環境をご提供いただいたCTC様に感謝いたします。  他関係各位、この場を借りてお礼を申し上げます。 40 謝辞