 |
||||||||||||
|
||||||||||||
| 前のページ 1 2 3 | ||||||||||||
|
||||||||||||
| Oracle Gridの現状 | ||||||||||||
|
Oracle社はGrid Computingで実現すべきこととして、以下の点に注力している。
表4：Grid Computingで実現すべき内容
それでは、Gridの第一歩であるOracle 10g Gridが具体的にどういった形で実装されているかを細かく見ていこう。 まず、最も最下層のレイヤとして位置づけられるのがOracle Database 10ｇである。オンラインでのデータベース設定変更が可能であることはもとより、ストレージの仮想化を実現するAutomatic Storage Manager、サービスの仮想化を実現するOracle Real Application Clusters 10gといった仮想化技術がすでに実装されていることは皆様もよくご存知のことと思う。さらに動的なサービスの負荷分散を実現するWorkload Management機能も提供されている。 その上位層であるOracle Application Server 10g Release 2以降では、Oracle Database 10gと密に連携して動くFast Connection Failover機能の提供と共に、HTTPサーバからのセッションリクエストの最適な振り分けを実現するLoad Balancing機能も合わせて実現されている。 また、10.1.3からはオンラインでのユーザアプリケーションのアップグレードを実現するRolling Upgrade機能などを提供している。Oracle Enterprise Manager 10gではこれらOracle Grid製品を1つの管理コンソールから統合管理する機能を提供するだけでなく、昨今のコンプライアンス対応で必要とされるレポート機能やユーザ権限の制限機能、各種DBA業務の定型化やスケジュール機能などもあわせて提供されている。 これらの機能の中でも、特に数多くのアプリケーションをデータベース上で稼動させているユーザビリティの向上に最も貢献すると思われるのが、Oracle Database 10gのWorkload Management機能と、Oracle Application Server 10gとの連携機能であるFast Connection Failoverであろう。今回は、その中でWorkload Management機能について簡単に紹介する。 |
||||||||||||
| Workload Managementの機能 | ||||||||||||
|
Oracle Database 10gではサービスという概念がある。例えば、複数のアプリケーションが稼動しているとすると、それぞれのアプリケーションにシステムを用意するのは、それぞれのシステムに余裕をもたせる必要があり、非効率的である。 そこでサービスという概念を使ってアプリケーションが稼動するサーバの範囲を定義し、アプリケーションが稼動しているサーバの負荷が高くなったら、新たなサーバをサービスに追加することで簡単にシステム拡張が実現可能となる。 ここで「1つのデータベースで複数のサービスを稼動させる際に、それぞれの処理性能をどうやって確保するか」という問題が起こってくる。 例えば、すでにAというサービスが稼動しているシステムに対して、一部のインスタンスにBという処理を追加する場合を考えてみる。ある程度の処理性能を確保し、かつ既存のサービスに大きな影響を与えないようにするには、サービスBを追加していない、かつシステムリソースに余裕があるサーバでAのサービスを実行すればよい。 このような処理を負荷に応じて実行することでGrid環境内の全サーバの処理性能を最大化することが可能となる。ここで紹介したサービスの定義は、サーバの追加や稼動サーバの変更が柔軟にできることも特徴の1つで、システムピークにあわせたリソースの有効活用を実現している。 |
||||||||||||
| Gridの検証 | ||||||||||||
|
ここまでは製品機能について述べてきたが、NSGUCでは実際に企業システムで利用されるケースを想定し検証を行っている。図2に検証時のシステム構成およびサービス配置を、図3に検証のタイムラインを示す。  図2：検証構成図とデータベースサーバ上におけるサービス配置  図3：検証のタイムライン 今回の検証は、データベースサーバ（図2のrac25〜rac28）でservice1のアプリケーションが実行されている状態で、service2のアプリケーションをrac27、rac28に後から追加した。その結果の1例を図4に示す。  図4：Runtime Connection Load Balancing設定時のスループットの遷移 （画像をクリックすると別ウィンドウに拡大図を表示します） これを見ると、複数サーバ上でサービスを稼動させた場合のWorkload Management機能の動作がよくわかる。検証結果としてrac27、rac28のスループットは一旦増えるが、時間が経つにつれてservice2の追加で負荷が高くなったサーバから負荷の低いrac25、rac26へservice1の処理が移動しており、最終的にすべてのサーバでほぼ同じスループットが実行されるようになることがわかる。 |
||||||||||||
| Oracle Gridの今後の展望 | ||||||||||||
|
Oracle 10gに代表されるOracle Gridは、エンタープライズ領域へのGrid活用への第一歩である。さらに日本オラクル社が11月に活動を開始する「Oracle GRID Center」の展開をきっかけに単なる技術の提供から、システム実装技術の普及へとつながっていくだろう。 本連載の最終回となる次回は、より柔軟・安全で効率的な情報システムの実現に向け当社が取り組んでいるシステムトランスフォーメーションへの取り組みについて紹介していきたい。 |
||||||||||||
|
前のページ 1 2 3 |
||||||||||||
|
|
||||||||||||
|
|
||||||||||||
|
||||||||||||
|
|
||||||||||||
|
||||||||||||
|
|
||||||||||||
|
||||||||||||
-
-
連載
