Upload
others
View
6
Download
0
Embed Size (px)
Citation preview
OSSVERTとは
OSSセンタでは,NTTグループの
OpS(Operation Support System)
や情報系システムで,もっとも利用頻
度の高いWeb3層システム構成*1に
着目し,OSS(Open Source Soft-
ware)からなるリファレンスモデル
(モデル)*2を設計・構築し,組合せ
検証を行い,構築手順や検証データな
どのノウハウをドキュメントにまとめ提
供してきました.OSSVERT(OSs
Suites VERified Technically) と
は,モデルやドキュメントも含め,OSS
の利用を支援するためのノウハウを指
します.OSS利用のメリットは,シス
テム構築・運用コストの削減だけでな
く,ベンダロックイン*3の回避,ソー
スコードが公開されており,OSSセン
タからのサポートが継続して受けられ
ることなどが挙げられます.さらに
OSSVERTのように,あらかじめ検証
済みの推奨構成や設定を利用すること
で,OSSの選択や最適な組合せを検討
する手間を省くことができ,OSSを用
いたシステム設計・構築の効率化が期
待できます.
これまでの取り組み
OSSVERTで想定するシステムの要
件は,図1に示すようにクライアント
の同時接続数が5 000以上,データ規
模が数100 GBで,稼動率99.99%
程度の可用性を想定しており,サー
バやネットワーク機器の冗長化され
た,単一障害点のない構成を基本とし
ています.Web3層システムの主な
ソフトウェア構成として,各サーバの
OSには共通してRHEL(Red Hat
Enterprise Linux)*4を採用し,LB
(ロードバランサ)/Webサーバには,
LB UltraMonkey*5, Webサーバ
オープンソフトウェアにかかわる最新の取り組み
NTT技術ジャーナル 2011.88
オープンソースソフトの導入を支援するOSSVERTの拡張
クライアント
LB/Webサーバ
APサーバ
DBサーバ
主な構成ソフトウェア
主なシステム要件 ・性能 :クライアント同時接続数 5 000以上 ・可用性 :稼動率 99.99%
図1 リファレンスモデルの構成と要件
ACT SBY
UltraMonkey
RHEL
アプリケーション
Tomcat/JBoss
OpenJDK
RHEL
PostgreSQL/MySQL/Oracle
Heartbeat/Pacemaker
RHEL
Apache mod_ jk
OSSセンタでは,OSSからなるシステムの設計・構築,組合せ検証を事前に行うことで,OSSを適用する際の課題を取り除く活動をしてきました.現在は,これまでの成果を最新化しつつ,サーバ統合を実現する仮想化モデルや運用監視モデルの追加を行っています.
と よ だ ひろはる おくむら まさかず
豊田 裕晴 /奥村 昌和すみ りゅういち
角 隆一
NTT研究企画部門
リファレンスモデル サーバ統合 運用監視
*1 Web3層システム構成:クライアントサーバシステムを「プレゼンテーション層」「アプリケーション層」「データ層」の3層に分割して構築したシステム.
*2 リファレンスモデル:あらかじめ定義した要件に基づくリファレンス実装.
*3 ベンダロックイン:ある特定のメーカや販売会社がユーザを自社製品で囲い込むこと.
*4 RHEL:Red Hat社が開発・提供している企業向けの商用Linuxディストリビューション.
特集
NTT技術ジャーナル 2011.8 9
Apache*6,Webサーバコネクタ
mod_jk*7を採用,AP(アプリケー
ション)サーバは,Tomcat*8,もし
くはJBoss*9,Java実行環境には
Open JDK*10を採用,さらにDB(デー
タベース)サーバには,クラスタソフ
トとして,Heartbeat*11,あるいは
Pacemaker,DBMS(DataBase
Ma n a g eme n t S y s t em) に は
Pos tgreSQL*12,あるいはMySQL
などを採用しています.
OSSVERTでは,インターネット上
の書店を模擬したベンチマークアプリ
ケーションを利用し,テストベッドを
用いた実機による性能測定を行ってい
ます.システムを構成する個々のOSS
の機能検証の後,OSSを組み合わせた
モデル構成で,表1に示す①基本動
作,②障害発生時のサービス継続性,
③最大性能,および④長時間運転時
の安定性などを主な観点として検証を
行い,商用環境で安心して使えるかど
うかを判断するとともに,表2に示す
ドキュメントに検証結果やノウハウを
まとめています.
図2は,サービス継続動作検証の一
例です.APサーバにネットワークイン
タフェースのハードウェア擬似障害を
発生させるサービス継続動作検証を実
施したところ,しばらく性能が改善し
ない不具合を摘出しました.原因であ
るWebサーバコネクタmod_jk1.2.27
の採用を見送り,コミュニティに対し
てフィードバックを行うとともに,不
具合の改修が行われるまで前版の
mod_jk1.2.22を継続して推奨とする
措置をとりました.これは,OSSVERT
表2 提供内容一覧
項番
1
2
3
4
5
ドキュメント 内容
モデル概要書
インストール手順書
環境定義書
検証報告書
ノウハウ
システム要件
OSSをサーバにインストールするための手順
OSSの各種設定パラメータの設定指針,および推奨値
各種検証の結果と測定データ
設計・構築・検証を通じて得られたノウハウ
表1 OSSVERTにおける主な検証項目一覧
項番
1-1
1-2
1-3
2-1
2-2
2-3
2-4
2-5
2-6
2-7
2-8
3
4
大項目 中項目
基本動作検証
サービス継続動作検証
長時間運転検証
性能検証
アプリケーション基本動作確認
Webサーバ負荷分散動作確認
APサーバ負荷分散動作確認
LB/Webサーバ(1 台)障害時のサービス継続動作確認
LB/Webサーバ(1 台)障害時のサービス継続動作確認
APサーバ(1 台)障害時のサービス継続動作確認
DBサーバ(1 台)障害時のサービス継続動作確認
最大性能値の測定
LBソフトウェア障害
48時間連続運転検証
LBハードウェア障害
Webサーバソフトウェア障害
Webサーバハードウェア障害
APサーバソフトウェア障害
APサーバハードウェア障害
DBサーバソフトウェア障害
DBサーバハードウェア障害
*5 Ultra Monkey:Linuxオペレーティングシステム上でオープンソースのコンポーネントを使用して,ローカルエリアネットワークの負荷分散と高可用性サービスを実現するためのプロジェクト.
*6 Apache:Apache Software Foundationが開発しているHTTPサーバソフトウェアの名称.
*7 mod_jk:ApacheとTomcatを連携するためのモジュール.
*8 Tomcat:Jakartaのプロジェクトとして開発されているOSS.
*9 JBoss:J2EEアプリケーションサーバもしくはJavaによるOSSの総称.
*10 OpenJDK:Sun MicrosystemsのJDKから派生したオープンソースのJDK.
*11 Heartbeat:プライマリシステムの万一の障害に備えた冗長構成環境において,システムの状態を監視し,障害を検出した後に予備のシステムへ切替えを行うOSSミドルウェア.
*12 PostgreSQL:オープンソースのオブジェクトリレーショナルデータベース管理システムの1つ.
の取り組みにより,不具合を見つけ,
トラブルを未然に防いだ1つの例です.
モデル開発後は,OSSのバージョン
アップに伴う追検証を定期的に行い,
最新化を図っています.ここ5年間の
主な変更として,図3に示すようにOS
は,RHEL4から5へ,Java実行環
境は,商用製品のOracle JDK(Sun
JDK)からOSSのOpenJDKへ,DB
サーバは,PostgreSQL8から9へ,
クラスタソフトは,商用製品の
Matr ixHA*13から,OSSのHear t -
beat,さらに後継のPacemakerへの
移行を進めるなど,機能拡張や安定化
とともに,利用導入のしやすさからフ
ルオープンソース化の促進を進めてき
ました.
2011年3月の時点で,Web3層シ
ステム構成を中心に,16のモデルを開
発し,延べ200を超えるNTT社内シス
テムへのOSSの適用にあたり,ノウハ
ウを活用していただいています.
現状の課題
ICT環境を取り巻く変化として,コ
ストの最適化や経営環境の変化に柔軟
に対応するため,クラウドコンピュー
ティングの導入が進みつつあります.現
在は,市販製品によるクラウド環境の
構築が主ですが,OSSのメリットを活
かした低コストで柔軟性のあるクラウ
ド環境の構築についてもニーズが増え
ています.このような背景のもとに,要
素技術として,サーバ統合を実現する
方式や手順の確立が求められています.
一方,複数のOSSにより構成された
システムの運用にあたっては,個々の
OSSの運用方法だけでなく,システム
全体を統合的に監視する仕組みが求め
られています.
オープンソフトウェアにかかわる最新の取り組み
NTT技術ジャーナル 2011.810
APサーバ ハードウェア障害発生
検証条件 APサーバハードウェア障害 (ネットワークインタフェースの停止)
mod_jk 1.2.22を適用
負荷
図2 サービス継続動作検証の一例
正常動作 (仕掛かり中のコネクションのみ影響)
mod_jk 1.2.27を適用
障害発生後,タイムアウトまで の一定時間,スループット, レスポンス時間が低下
スループット
Webインタラクション(WI)
レスポンス時間
14個のWebインタラクション レスポンス時間
2 000
1 500
1 000
500
0
10 000
5 000
0
スループット
Webインタラクション(WI)
レスポンス時間
14個のWebインタラクション レスポンス時間
2 000
1 500
(ms) (WIPS)
0 5 10 15 20 25 30 35 (ms) (WIPS)
1 000
500
0
10 000
5 000
0
UltraMonkey (ACT)
LB/Webサーバ1号機
APサーバ1号機
DBサーバへ
LB/Webサーバ2号機
Apache
mod_jk
Tomcat
UltraMonkey (SBY)
APサーバ2号機
Apache
mod_jk
Tomcat
スループット
スループット
時間(min)
*13 MatrixHA:NTTコムウェアと米Poly Serveが開発したクラスタソフトウェア.複数のコンピュータを組み合わせてシステムを構成することで,どれか1つのノードに障害が発生しても,システム全体のダウンを防ぎ高可用性を実現.
特集
NTT技術ジャーナル 2011.8 11
次に,これらの課題も踏まえた最新
の活動におけるトピックを紹介します.
仮想化モデルの追加
KVM( Kernel-based Virtual
Machine)などの成熟しつつあるOSS
の仮想化ソフトウェアを用いて,複数
のAPサーバを1台の物理サーバ上に統
合した構成を実現しました.これは新
たに,もしくはサーバ更改等のタイミ
ングで,異なる業務APサーバを1台の
物理サーバ上に統合し,サーバ台数を
削減するケースを想定しています.
仮想環境における検証では,これま
での観点に加えて,物理サーバ上の仮
想マシン(VM: Virtual Machine)
の集約数を増やしていった場合の仮想
化処理のオーバヘッドの測定やCPU資
源の割り当ての方針の違いによる性能
傾向の測定,突発的な高負荷を避け
るための各仮想マシン上の起動サービ
スのスケジューリング方針の調査など
を行い,仮想環境でOSSシステムを設
計・構築・運用する際のノウハウや留
意点をまとめています.
図4は,KVMを適用し,3台の仮
想マシンを作成し,異なるAPサーバを
1つの物理サーバ上に統合した構成例
です.APサーバには,Tomcatを採用し
ており,冗長構成*14(ACT-ACT構
成)をとっています.
今回は,APサーバのハードウェアと
して,IBM社のx3650M3〔CPU
Intel社Xeon E5630×2枚(8コア
PostgrePostgreSQL9
構成品 UltraMonkey-L4
Apache
mod_jk
Tomcat5 Tomcat6
JBoss4 JBoss5
OracleJDK(SunJDK)(商用製品)
PostgreSQL8
Oracle10g(商用製品)
MartixHA(商用製品)
MySQL5
PostgreSQL9
2006 2007 2008 2009 2010
図3 主な構成ソフトウェアの変更
OpenJDK
Heartbeat
RHEL4
RHEL5
年度
LB
Web サーバ
Java 実行環境
DBMS
クラスタ
OS
APサーバ
Webサーバ コネクタ
UltraMonkey-L7
Pacemaker
*14 冗長構成:障害対策などのために,通常の運用で必要なシステム以外に予備のシステムを加え,バックアップできるようにした構成.
LB/WebRHEL
LB/WebRHEL
図4 仮想化モデルの構成例(AP層の統合)
ACT─ACT構成
仮想化の範囲
VM#1 VM#2
…
…
VM#3 VM#1 VM#2 VM#3 APLTomcat
DB#1 PostgreSQLRHEL
DB#3 PostgreSQLRHEL
RHEL
APLTomcatRHEL
KVM KVM
SBY
APLTomcatRHEL
APサーバ 1号機
APサーバ 2号機
…
共有ストレージ
DB1 DB3
オープンソフトウェアにかかわる最新の取り組み
NTT技術ジャーナル 2011.812
構成)〕を利用しましたが,このような
ハードウェア条件では,APサーバ3台
を集約した構成で,3つのシステムご
とに性能要件(クライアントの同時接
続数が5 000以上)を十分に満たすこ
とを確認しています.
また,サービス継続動作検証の1つ
として,仮想マシンVM#1に擬似障
害を発生させた際(仮想マシンゲスト
障害)のVM#2,およびVM#3
のサービスへの影響を調べました.図
5に示すように,障害発生時には瞬間
的に,Webインタラクションのレスポ
ンス時間の増大とともに性能値が劣化
しますが,VM#1の2号機への縮退
により,サービスが継続されているこ
とが分かります.仮想マシン間の影響
を極小化するため,仮想CPUを固定
的に物理コアに割り当てる設定では,
ある仮想マシンに障害が発生した場合
も同じ物理サーバ上で動作するほかの
仮想マシンには影響がないことが確認
できました.
運用監視モデルの追加
これまでの検討対象は,Web3層
システムが中心でしたが,図6に示す
ように監視サーバと組み合わせ,既存
のOSSVERT構成について稼動状況を
監視できるようにしました.
運用業務の設計においては,まず監
視項目を調査し,運用要件に合った
監視方法を決める必要があります.
OSSVERTでは,検証で利用している
ハードウェアやシステムを構成す
るRHE L,A p a c h e,T om c a t,
PostgreSQLなどのOSSについて,あ
らかじめハードウェア障害監視,死活
監視,リソース監視,プロセス監視,
ポート監視,およびログ監視などの観
点で約600の監視項目を調査し,その
設定値を整理したものを,「推奨監視
項目一覧」にまとめています.実シス
テムの運用設計では,特定の監視ソフ
トウェアに依存することなく,推奨監
視項目一覧を雛形として利用可能で
あり,OSSに関する監視項目の調査や
検討の手間を省くとともに,OSSで構
成されたシステムの統合監視が可能と
なります.
APサーバVM#1障害発生 APサーバVM#1の障害復旧
検証条件 仮想マシンVM#1 障害
図5 仮想環境におけるサービス継続動作検証の例
スループット
スループット
Webインタラクション(WI)
レスポンス時間
14個のWebインタラクション レスポンス時間
5005 10 15 20 25 30 35 40 450
400
300
200
100
0
スループット
500
400
300
200
100
0
スループット
500
400
300
200
100
0
5 000
4 000
3 000
2 000
1 000
(ms) (WIPS)
(ms) (WIPS)
(ms) (WIPS)
0
5 000
4 000
3 000
2 000
1 000
0
Webインタラクション(WI)
レスポンス時間
Webインタラクション(WI)
レスポンス時間
5 000
4 000
3 000
2 000
1 0000
システム#1 負荷
APサーバ1号機
(APサーバ1号機(物理サーバ)上で3つのVMが 稼動中に VM#1を強制終了)
システム#2 負荷
システム#3 負荷
VM#1
APL
Tomcat
RHEL
VM#2
APL
Tomcat
RHEL
VM#3
APL
Tomcat
RHEL
KVM
スループット システム#1
スループット システム#2
縮退の仕掛かり中 のみ影響
影響なし
スループット システム#3
影響なし
時間(min)
特集
NTT技術ジャーナル 2011.8 13
今後の取り組み
OSSVERTは,Web3層システム
の基本構成から,ICT環境を取り巻く
状況に合わせ,仮想化モデルや運用監
視モデルの追加など,拡張を図ってき
ました.今後は,図7に示すようにシ
ステムのライフサイクル全般をカバーで
きるように,構築だけでなく,初期検
討,設計,運用時においても活用でき
るノウハウへと拡張し,提供していき
たいと考えています.
さらに,クラウドなどの大規模運用
システムも新たなターゲットとして視野
に入れ,成熟しつつあるOSSの評価を
基に,モデル開発を行っていきたいと
考えています.
引き続き本特集では,OSSVERT
を支える基盤OSS関連技術や運用管
理ソリューションに対する取り組みと,
OSS分野における先進的な基盤技術
開発について紹介します.
■参考文献(1) 内川:“オープンソースを手際よく使うために
―― OSSVERTの取り組み,”NTT技術ジャーナル,Vol.19,No.3,pp.60-62,2007.
(左から)豊田 裕晴/ 奥村 昌和/
角 隆一
OSSVERTの拡張にあたっては,利用者の皆様のご意見が重要となります.OSS利用にあたり,ご要望などをフィードバックしていただけると幸いです.
◆問い合わせ先NTT研究企画部門OSSセンタTEL 03-5860-5055FAX 03-5463-5491E-mail contact oss.ntt.co.jp
No. 監視項目 監視単位 監視対象 マシン
監視項目 詳細
監視項目 (設定値)
監視 間隔
情報蓄積 間隔
障害レベル 警告レベル 回復レベル しきい 値 重要度
しきい 値 重要度
しきい 値 重要度
1 2 3 4 5 6 7 8 9 10
cpu. total cpu. system cpu. user cpu. steal cpu. iowait physical swap in out total
300 300 300 300 300 300 300 300 300 300
600 600 600 600 600 600 600 600 600 600
90 90 90 90 90 90 90 500 500 500
3 3 3 3 3 3 3 3 3 3
4 4 4 4 4 4 4 4 4 4
80 80 80 80 80 80 80 450 450 450
5 5 5 5 5 5 5 5 5 5
50 50 50 50 50 50 50 400 400 400
各サーバ共通 Linux監視
CPU使用率 CPU識別
メモリ使用率 メモリ識別
ページIO回数 IO種別
図6 運用監視構成の一例
「推奨監視項目一覧」の例
Crane Agent
Crane Agent
Crane Agent
約600項目 ・各リソースごとの監視項目の規定 ・しきい値やメッセージトラップの設定指針を整理 ・仮想環境における資源も監視対象
監視対象(既存のOSSVERT)
監視サーバ 監視コンソール
LB/Web サーバ
APサーバ
DBサーバ Crane Agent
Crane Manager
Crane Console
※ NTT情報流通プラットフォーム研究所開発の運用統合 ソフトウェアCraneとの組み合わせの例
マイグレーション ツール等
バックアップ・ 故障対応 運用支援等
初期検討・システム設計 運用・保守 構築
Web3層モデル
図7 OSSVERT の拡張
クラウド等の 大規模システム運用モデル
拡張
拡張
OSSソリューション
従来のOSSVERT拡張