Jump to content 日本-日本語
日本HPホーム 製品とサービス サポートとドライバ ソリューション ご購入方法
≫  お問い合わせ
日本HPホーム
製品とサービス >  ソフトウェアとOS >  HP- UX Developer Edge

Serviceguard

「オラクルならHP、定期セミナー」シーズンIII
知っておくべきセキュリティ対策
-HP-UXのセキュリティを極める-
特集:Webベースのクラスタ管理〜Serviceguardの新機能〜
HP Serviceguardクラスタ構築手順
コンテンツに進む
Serviceguard

Serviceguardは、豊富な実績をもつハイアベイラビリティ・ミドルウェアです。さまざまなハードウェア/ソフトウェアの障害から基幹系アプリケーションを保護する高度な機能をHP-UX上で提供します。HP Serviceguardは、最大16個のノードを疎結合することでエンタープライズ・クラスタを構成し、LANで接続されたクライアントに対して可用性の高いアプリケーション・サービス(クラスタ当たり200のパッケージ、900のサービス)を提供できます。
ハイ・アベイラビリティ
Serviceguard
  SGeFF
  CFS
  SGeRAC
  SGeSAP
  ECM/NFS Toolkit
  SGM/EMS
  Continentalclusters/ Metrocluster
  Serviceguard Storage Manegement Suite(SG SMS)

アベイラビリティに関する主な特長と利点
  • 迅速な自動障害検出とアプリケーション回復(可用性の最大化と操作ミスの低減)
  • 複数ノードの障害からも回復可能
  • ローリング・アップグレードにより、ハードウェア/ソフトウェアの保守時にもアプリケーションの可用性を確保
  • オンラインの設定変更による計画的ダウンタイムの削減
  • HP WorkLoad Manager (WLM)との統合により、ダウンタイム時にもサービスレベル目標(SLO)を維持可能
  • ロードバランシング(負荷の均衡化)

迅速な自動障害検出とアプリケーションの回復


Serviceguardがハードウェアとソフトウェアの各コンポーネントをモニタしながら、故障を自動的に検出します。故障が発見されると、直ちに別のリソースへの切り換えを行い、ミッションクリティカルなアプリケーションのサポートを続行します。故障の検出とアプリケーション・サービスの回復プロセスは完全に自動化されているため、オペレータの介入は不要です。

例えば、LANアダプタが故障した場合、Serviceguardではわずか数秒の間に回復プロセスが実行されます。アプリケーションを別のノードに切り換えるときに要する回復時間は、その時点でアプリケーションが使用しているソフトウェアにより異なります。例えば、ログ機能を使用しているデータベース・アプリケーションでは、回復プロセスの一部としてトランザクションのロールバック処理が必要となるため、このための時間も所要時間に含まれることになります。Serviceguardでは、異常ノードの検出をしてから、クラスタ設定の変更、代替ノードで実行するアプリケーション・パッケージのスタートアップ・スクリプトの開始までの処理を30秒以内に完了します。

Serviceguardは、標準で次のコンポーネントを対象に故障の検出/処置を自動的に行います。

  • システム・プロセッサー
  • システム・メモリ
  • LANメディア/アダプタ
  • システム・プロセス
  • アプリケーション・プロセス
* ServiceguardとEvent Monitoring Services(EMS)を併用することにより、ディスクなどの各種コンポーネントについても動作状況や限界値の変化などをモニタできます。Serviceguardのクラスタでは、ハイ・アベイラビリティの保証という点が設計上の主な目的となっているため、データのミラー・ディスクやLANの冗長構成を採用することにより単一障害点(Single Point of Failure : SPF)をなくすことができます。

クラスタの回復オプション


Serviceguardでは、「アクティブ・アクティブ」と「アクティブ・スタンバイ」の2つの回復モードを設定することができます。アクティブ・アクティブ設定では、個々のノードがそれぞれ1つ以上のアプリケーション・パッケージを実行しながら、別のノード上で実行されているその他のパッケージに対してバックアップ・サービスを提供します。この設定では、アイドル状態になるシステムはまったくないので、クラスタ全域のすべてのノードを最大限に有効活用することができます。

Serviceguardのもう一つの回復モードは、アクティブ・スタンバイ・モードです。この設定では、プライマリ・システムに障害が検出されると、アプリケーション・パッケージにスタンバイ・ノードの全処理機能が割り当てられます。スタンバイ・ノードは、プライマリ・ノードからスタンバイ・ノードへアプリケーション・パッケージが切り換えられた時点で終了する非ミッションクリティカルな処理に割り当てることができます。アクティブ・スタンバイ設定により、障害が発生した後でもミッションクリティカル・アプリケーションのレスポンスタイムの低下を防ぐことができます。TCO(総所有コスト)を削減するため、Serviceguardは、クラスタ中の1台または複数のサーバを冗長サーバに設定し、その他のサーバ(最大15台)をアクティブ・サーバとして構成することができます。

ハードウェア/ソフトウェアの保守作業中のアベイラビリティ


クラスタ・システムの中では、アプリケーション・パッケージを簡単に移動できるため、ハードウェアやソフトウェアのアップグレードといったシステム保守作業中にも高度なアベイラビリティが維持されます。簡単なオペレータ・コマンドを使用して、あるノードから別のノードにパッケージを移動することにより、クラスタ中のノードで予定通りの保守作業を実施する一方で、代替ノードからミッションクリティカル・アプリケーションへのサポートを続けることができます。保守作業が完了した段階で、クラスタにノードを再結合すれば、通常通りアプリケーション・パッケージの処理を続行できます。この方法は、クラスタ全域のオペレーティング・システムをアップグレードするときにも応用できます。

オンラインの設定変更による計画的ダウンタイムの削減


Serviceguardに組み込まれた新しい設定変更機能により、クラスタを実行させた状態で、クラスタ構成を変更することができます。この新しいオンライン・パッケージ機能によってクラスタやその他パッケージを実行しながら、Serviceguardではパッケージの追加/削除をはじめ、パッケージ属性の修正やパッケージ全体の変更という操作を行うことができます。このオンラインによる設定変更の機能には、オンライン状態でノードの追加や削除を行う機能も用意されています

アプリケーションの要件に応じたシステム機能


Serviceguardは、クラスタ・システムの中で可能な限り柔軟な形式で構成できるように設計されています。各クラスタは、最大16ノードで構成することが可能です。また各ノードは、SMPノード、またはユニプロセッサー・ノードだけで一律に構成できる他、SMPとユニプロセッサー・ノードを任意に組み合せることもできます。極めて柔軟な形式でシステムの選択とクラスタの構成が可能になるため、インストールしたシステムへの既存投資が保護される他、各ノードの処理機能を特定のアプリケーション・サービスの要件に応じて調整することができます。

ロード・バランス(処理負荷の均衡性)


Serviceguardのアプリケーション・パッケージは、あるノードが故障した後でも、クラスタ内の処理負荷をバランスよく配分するための強力で柔軟な機能を備えています。あるノードの各アプリケーション・パッケージを別のノードに移すことにより、特定のノードにかかる処理負荷をクラスタ内で正常に動作している他の各ノードに配分することができます。例えば、4つのノードでクラスタを構成して、各ノードで3つのパッケージを実行している場合、1つのノードが故障しても、このノードで実行される3つのパッケージをそれぞれ別のノードに移行することができます。この機能により、故障したノードの処理負荷がクラスタ内の残りの各ノード間で分散されるため、クラスタで実行されているその他のアプリケーションに対する影響が最小限に抑えられます。

またServiceguardのクラスタ・ロード・バランス機能をさらに強化するため、オプションでローテーティング・スタンバイと自動フェールオーババック機能なども用意されています。これらのオプションはクラスタ構成の柔軟性を高めるものです。ローテーティング・スタンバイを使用すると、すべてのノードをクラスタのスタンバイ・システムとして機能させることができます。例えば、4ノードのクラスタ環境で1つ目のノードが故障した場合、Serviceguardが1つ目のノードのパッケージをスタンバイ・ノード(残りの3ノード内の1つ)に移します。そして1つ目のノードの故障が修復され、クラスタへ復旧すると、Serviceguardはこの1つ目のノードを自動的に新規のスタンバイ・ノードに割り当てます。

一方、自動フェールバックの場合は、プライマリ・ノードの故障が修復されクラスタへ復旧すると、アプリケーションは自動的にプライマリ・ノードへ戻されます。例えば、4ノードのクラスタ環境で1つ目のノードが故障した場合、Serviceguardは1つ目のノードのパッケージをデフォルトのスタンバイ・ノード(4つ目のノードなど)へ移します。その後1つ目のノードが復旧すると、1つ目のノードから4つ目のノードへ移されていたパッケージは自動的に1つ目のノードに戻され、4つ目のノードは再びデフォルトのスタンバイ・ノードとして待機します。ローテーティング・スタンバイおよび自動フェールバックの両機能は、個別の構成済みパッケージとして提供可能です。

アプリケーション・パッケージの移行機能では、特別な障害がない場合でもクラスタ全域の処理負荷をバランスよく配分することができます。例えば、ピーク時の処理の間に、特定のアプリケーションからの要求が高くなりすぎた場合は、簡単なオペレータ・コマンドを使用して同じノードにあるその他のアプリケーション・パッケージをクラスタ内の別のノードに移動させることができます。この結果、処理能力が開放されるため、プライマリ・ノードの処理負荷が重くなった場合にも対応できます。またHPのオプション製品として提供されるPRM(プロセス・リソース・マネージャ)を使用すれば、エンタープライズ・クラスタ内の個々のノードに組み込まれた負荷調整の機能をさらに拡張することができます。

SGeRACによるOracle RACシステム構成例


BL860c OracleSE クラスタ構成

rx2660 OracleSE SG Light クラスタ構成

rx3600 OracleSE SG Light クラスタ構成

印刷用画面へ
プライバシー 本サイト利用時の合意事項 ウェブマスターに連絡
© 2008 Hewlett-Packard Development Company, L.P.