Loading
|
|
|
Loading
|
| ＠IT > 最先端の基幹システムはどう作られたか |
 |
2007年夏、ある企業のERPシステムがカットオーバーした。SAPを使ったこのシステムは、仮想化技術を駆使した自律型コンピューティングへの取り組みという点で、世界に類を見ない画期的なものとなった。 このシステムのインフラを構築し、運用しているのは日本ヒューレット・パッカード（日本HP）。新システムにおけるサーバ利用については、早い段階からこの企業と日本HPの間に1つの共通した考えがあった。この企業ではそれまで、新システム構築のたびにサーバ構成の検討を行いながらも、結果として同じように無駄の多いシステムが乱立してしまうという状況を繰り返してきた。これを何とか打破できないか。ユーザー企業はサーバを買いたいわけではなく、サーバの処理能力を利用したいだけだ。理想は、サーバを完全にリソースプール化し、必要な処理能力を必要なときに手に入れられるようにすることだ。
HPもこの理想像を「アダプティブ・インフラストラクチャ」として提唱してきた。ただ、即座にそのすべてを実現できるわけではない。「現在実装可能な範囲で、行けるところまで行きましょう、というのがお互いの了解事項だった」と、このプロジェクトの設計・構築で中心的な役割を担った日本HPコンサルティング・インテグレーション統括本部の佐藤亘は振り返る。 日本HPは、サーバ仮想化技術の活用による柔軟なシステムの実現を、今回のサーバ構築における大きな柱に据えた。しかも、要素技術としてサーバ仮想化を使うだけではなく、もう1歩進んでCPUを動的に配分する仕組みを導入した。これによって必要なハードウェア資源を最小限にして利用効率を上げることを目指した。 今回のSAPシステムは、日本HPのフラッグシップサーバ「Superdome」上で、HP-UXをプラットフォームとして稼働している。そのうえで、同OSの特徴的機能の1つである仮想化技術を適用した。では、具体的にはどのように構成したのだろうか。
HP-UXは、3種類のサーバ仮想化技術を用意している。1つは「nPartitions」（nPar）と呼ばれるもので、Superdomeのセルボード（CPUとメモリを搭載したボード）1つ、あるいは複数を1単位として単一のOSを動かすハードウェア的なサーバ仮想化技術。2つ目は単一のセルボードあるいはnParを複数のOSに分割する、ソフトウェア的な仮想化技術の「vPartitions」（vPar）で、最小で1 CPUを1単位としてOS区画（OSパーティション）を稼働することができる。3つ目は、単一のCPUで複数のOSを動かすことのできる「HP Integrity Virtual Machines」（HP VM）だ。今回のシステムの第１のポイントは、これらの仮想化技術を用途に応じて使い分け、システム全体としての最適構成を実現したことにある。 一口にSAPのシステムを構築するといっても、稼働しなければならないソフトウェアモジュールは多岐にわたる。この企業でも「SAP ERP Central Component」（ECC）をはじめとした複数のSAPプロダクトとその背後のデータベースを動かし、さらに帳票などの周辺システムを稼働する。一部のプロダクトについては、開発や検証、品質保証のためのサーバも必要だ。移行やトレーニングのためのサーバも用意しなければならない。 今回のシステムではさまざまな角度から検討した結果、CPUと仮想化技術、ソフトウェアは以下のように組み合わせることになった。 まずSuperdomeに、複数のセルボードを1つの仮想サーバにまとめたnParを作り、パフォーマンスが必要な本番機や移行機をこの上にvParで構成することにした。作成したvParは、データベースサーバ系グループと、非データベースサーバ系（すなわちアプリケーション系）グループの2つだ。2つに分離したのは、運用保守の容易性やソフトウェアライセンス費用の最小化を考慮したためだ。
一方、パフォーマンスが重視されない開発機、品質保証機などをこれとは別にHP VMとして実装、一部のCPUリソースを共用することにした。きめ細かい仮想化が特徴のHP VMを使うことで、少ないハードウェアリソースでの構成が可能となった。 2つのvParグループについては、HPの「global Work Load Manager」（gWLM）を適用して各アプリケーションへのCPU数の割り当てを導入した。これは、新システムを大きく特徴付けるものとなった。 gWLMは、事前の設定に基づき、あるOSパーティションにおけるCPU負荷が一定レベルを超えると、自動的に稼働率の低いほかのOSパーティションからCPUを借りてきて、処理能力を増やす仕組みだ。処理負荷が再び一定レベル以下に下がると、一時的に借りたCPUは、再び自動的に元のOSパーティションへ返すようになっている。これによって、予想外の負荷が発生した場合にも、管理者の介在なしに、一定のレスポンスタイムを維持することができる。 gWLM機能のおかげで、サーバ機に搭載するCPU数を確実に減らすことができた。通常のサーバ構築では、ソフトウェアコンポーネントごとにピーク時の必要CPU数を机上で算出し、これに保険としてのCPU数をさらに加えた構成のサーバあるいはサーバブレードを導入する。しかし、今回は保険的意味合いのCPUをまったく用意せずに済んだ。まず、机上での算出に基づき、ピーク時に予想される必要CPUは、各OSパーティションに対し固定的に割り当てているため、この範囲内では専用サーバを構築しているのとまったく代わらないといっていい。そしてもし、この想定ピーク負荷を超えた場合は、ほかのOSパーティションから即座に自動で割り当てられるからだ。
ここで興味深い設計上の工夫として、本番データベースサーバ系vParグループ、本番アプリケーション系vParグループのいずれにも、本番システムではないシステムを組み込んだ。本番データベースサーバ系には検証やトレーニングのサーバが一部入っており、本番アプリケーション系グループには移行サーバが含まれている。 本番系のソフトウェアコンポーネントなら、いくら役割の異なるものであっても、似たような時期に処理のピークが来ることが想定できなくはない。しかし、本番システムとは関係のないトレーニング用サーバや検証用のサーバなら、同時期にピークはあり得ないし、これらは相対的に重要度が低く、最後は犠牲にしたとしてもまったく困らない。意図的にこのような配置をしているのだ。 また、本番系サーバと待機系サーバの分担についても工夫が見られる。今回のシステムでは複数台のSuperdomeで冗長構成を実現し、本番データベースサーバや帳票サーバについてはミドルウェアの「HP ServiceGuard」によるクラスタリングが行われている。このクラスタリングでは、ソフトウェアコンポーネントによってどのサーバで本番系を動かすかを変えているのだ。例えばｎ号機でECCデータベースの本番サーバを動かしているとすると、同じn号機は別プロダクトのデータベースについては待機サーバになっている、といった具合だ。このような「互い違い」の割り当てにより、さらに拡張の柔軟性と可用性を確保している。 開発機や品質保証機の役割を果たしているHP VMグループは、グループ全体に割り当てられたCPUを必要に応じて共用する。これらについては冗長性を確保する必要はなく、すべての関連コンポーネントはいずれかのSuperdomeでのみ動作する。HP VMには、コマンド1つで仮想マシンを別の物理サーバに移動できるという便利な機能があり、開発部隊からのリクエストに応じて、負荷のかかるプロセスがあれば、ほかのプロセスを移動させるといった運用を行っている。
このシステムの設計における最大の課題は、どの技術をどう組み合わせていくかにあった。日本HPの佐藤は、本番機系と開発機系を分けて、本番系にはvPar、開発機系にはHP VMを採用し、3つのグループを構成し、それぞれのグループにおける最適な組み合わせを見極めるのがポイントだったと説明している。 「普通の事例は仮想化を入れたというレベルに留まっている。しかし、必要なときに必要なリソースを使えるというのが最終的なゴール。そこへいくための1歩が踏み出せたのではないか」 サーバ仮想化技術をここまで駆使している例は、国内はもちろん世界でも数えるほどしかない。さらに今回のようにCPUの動的な割り当てまでも組み合わせた事例は、おそらく世界で初めてといっていい。とはいえこのシステムは、ロールアウトが始まったばかり。ユーザー企業と日本HPの共通したビジョンをベースに構築されたシステムは、その柔軟性と拡張性をこれから実際に発揮していくことになる。
提供：日本ヒューレット・パッカード株式会社 企画：アイティメディア 営業局 制作：＠IT 編集部 掲載内容有効期限：2007年12月29日 |
|
