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
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センター
名古屋センター
師勝センター
大阪センター
心斎橋gDC
天津IDC 心斎橋gDC-EX GDC御殿山
プライベートクラウド市場の拡大†
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
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
電気料金の高騰†
震災前に比べ、一般家庭部門(電灯料金)の平均単価は約2割上昇
工場、オフィス等の産業用(電力料金)の平均単価は約3割上昇
7
活動の背景
† 経済産業省 資源エネルギー庁, “平成25年度エネルギーに関する年次報告(エネルギー白書2014)",2014-06, http://www.enecho.meti.go.jp/about/whitepaper/2014pdf/
電力効率に優れたオープンなデータセンター・ハードウェア
一般的な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/
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
目的
クラウドを構成するリソースの統合監視の構築を可能な限りスケールするように自動化・自律化するオープンな技術を確立する
ポイント
Open Compute Project準拠のオープンなH/Wで動作を確認する
広く使われているOSSの統合監視ツールを活用する
対象のベアメタルをネットワークに接続し電源をONにすれば、H/WとOSを対応付け監視を自動的に開始する
監視負荷を分散させるために、最適な監視サーバへ対象ノードを自律的に振り分ける
今回ベアメタルプロビジョニングは、IronicではなくCobblerを採用
Kiloで正式プロジェクトへ昇格した暁には・・・
10
活動の目的
Open Compute Project準拠のベアメタル:Quanta F03A, F03C
Quanta社製のOCP準拠サーバ
F03Cは1筐体に3ノード、F03Aは1筐体に4ノード格納されるが、今回はF03Cを1ノード、F03Aを1ノード用いる
12
オープンなハードウェア
F03C F03A
ベアメタルプロビジョニング:Cobbler
http://www.cobblerd.org/
ベアメタルへOSやミドルウェアを遠隔から自動プロビジョニングするためのPython製のツール群
PXEブート時にベアメタルにインストールするOSイメージの管理
kickstartのテンプレート管理
yumやaptのリポジトリミラー
等
13
オープンなソフトウェア
OSS統合監視ツール:Zabbix
http://www.zabbix.com/
マルチプラットフォームに対応した、OSSの統合監視ツール
「監視」→「監視結果の視覚化」→「監視結果に応じたアクション(メール通知・コマンド実行)」が統合的に管理可能
14
オープンなソフトウェア
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
PXEBootOS Image
RepositoryMirror
kickstarttemplate
・Zabbix Package
・Zabbix Install Script
IPMI:.12IPMI:.15
・CentOS6.6イメージ
構築前
LOM LOM
Cobbler
VMWare vSphere ESXi
IPMI:.12IPMI:.15
DHCPd
TFTPd
HTTPd
PXEBootOS Image
RepositoryMirror
kickstarttemplate
OS:.XX OS:.YY
PXEBootされたOSのIPアドレスはDHCPで動的に払い出し
ZabbixServer
ZabbixProxy
ベアメタル上にCentOS6.6を自動インストールし、Zabbix Server(Zabbix Proxy)をプロビジョニング
構築後
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自動構築
Zabbixを用いたベアメタル自動監視
ZabbixへベアメタルのH/W監視を自動登録
プロビジョニングされたOSの監視を、H/Wと対応付けて自動登録
設定したルールに従い、適切なZabbix Proxyへ自動振り分け
17
検証②:Zabbixを用いたベアメタル自動監視
Cobbler
VMWare vSphere ESXi
PXEBootOS Image
RepositoryMirror
kickstarttemplate Z
abbix
Server
Zabbix
Proxy
・HW登録用ミニOSイメージ・実OSイメージ
検証用のベアメタルが足りなかったため、Zabbix ServerとProxyは仮想環境に構築
LOM LOM
F03A F03C
監視登録前
Cobbler
VMWare vSphere ESXi
PXEBootOS Image
RepositoryMirror
kickstarttemplate Z
abbix
Server
Zabbix
Proxy
LOM LOM
実OS 実OS
プロビジョニング時に、IPMIと対応付けてOSやM/Wを監視登録
Pahse2(実OSプロビジョニング)
LOM
Cobbler
VMWare vSphere ESXi
PXEBootOS Image
RepositoryMirror
kickstarttemplate Z
abbix
Server
LOM
Zabbix
Proxy
ミニOS ミニOS
登録された監視対象ノードをルールに従って適切なProxyへ振り分け
Pahse1(NWと電源へ接続)
HW登録用のミニOSを自動起動しIPMI情報をZabbixへ登録
実OSが起動していなくてもIPMI経由でH/W監視は実行される
H/WとOSを対応付け統合監視
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情報を送信
ミニ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を用いたベアメタル自動監視
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の監視情報を送信
プロビジョニングする実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を用いたベアメタル自動監視
Proxyの割り当て処理はRuleクラスとScheduleクラスへ切り出されており、柔軟に変更可能
今回はIPMIのIPアドレスレンジに基づいて静的に割り当てるルールを実装した
各Proxyの負荷状況を元に動的に最適なProxyを選択して割り当てるルール等も実装可能
24
適切なZabbix Proxyの自動割当
今回の検証で用いた各種スクリプト類
Baremetal AutoDiscovery Tool for Zabbix(近日公開予定)
https://github.com/tech-sketch/baremetal_ad
Python 2.6系
Apache License Version2
26
ソースコードの公開
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
デザイン指向クラウドオーケストレータ CloudConductor
インフラ・運用のノウハウを込めたパターンを中心に、いつでも誰でもどのクラウドにでも、その時点で最適な非機能要件を持ったシステムを簡単に構築するツール
29
CloudConductorとは
Infrastructure Design Patterns as Code
インフラ・運用のノウハウを依存関係を整理してパターン化
パターンを機械可読な形式で集積し、集合知化
30
CloudConductorの特徴①
CloudFormation TemplateChef CookbookServerSpec TestCode…
Everyone, EveryTime & EveryCloud
必要なパターンを組み合わせて誰でも最適なインフラ設計を獲得
クラウドを跨りデータを遍在化させ、どのクラウドでもシステムを再現(現在はAWSとOpenStack)
31
CloudConductorの特徴②
Packerで生成したGlance ImageHeat APIを利用
OnDemand Service Level
「負荷分散」「災害対策」「ログ分析」等の非機能要件は最初から作りこまず、必要になった段階で適用したシステムへ乗り換え
32
CloudConductorの特徴③
宮城県登米市・慶應大学・TISで災害対策の実証実験を実施
CloudConductorを用いたシステムのクラウド間フェイルオーバー(2014/11/07)
34
CloudConductorを用いた災害対策実証実験
クラウド間フェイルオーバーさせたシステムのスペック
通常系: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 システム復旧
統合監視を含めたシステム全体を様々なクラウドへCloudConductorから自動構築し、マルチクラウド管理プラットフォームを構成する
37
最終的なイメージ
Proxy Node Neutron NodeNova Node
VM VM VM
Controller NodeSwift Node Cinder Node
Monitoring
Server
Monitoring
Server
スケールする監視環境自身の自動構築
監視ノードの自動振り分け
起動時にベアメタルのH/Wを自動登録
BareMetal Node
各ベアメタルを自動で監視
構築されたVMを自動で監視
物理・仮想NWを自動で監視
物理・仮想ストレージを自動で監視
38
CloudConductorの情報公開
公式サイト http://cloudconductor.org
ソーシャルhttps://twitter.com/ccndctr
https://www.facebook.com/cloudconductorhttps://github.com/cloudconductorhttp://www.slideshare.net/cloudconductor
本検証を進めるにあたり、Cobblerによる監視環境自動構築の実現方法について、多くの示唆を頂いたOpen Compute Project Japan Proof of Concept WG の方々に感謝いたします。
本検証を進めるにあたり、検証環境をご提供いただいたCTC様に感謝いたします。
他関係各位、この場を借りてお礼を申し上げます。
40
謝辞
Top Related