X

News, tips, partners, and perspectives for the Oracle Solaris operating system

Solaris Cluster による Sun Java System Application Server の可用性の向上

Guest Author

概要

Sun Java System Application Server は、堅牢なアーキテクチャー、安定性、使いやすさを特徴とする、市場でも有数のミドルウェア製品です。Application Server の設計には、高可用性 (High Availability、HA) の機能が含まれています。この機能では、複数のノードに分散されたノードエージェント (Node Agent、NA) により、単一障害点 (Single Point of Failure、SPoF) を回避します。この設計について、簡単な図を次に示します。




ただし、上のブロック図からわかるとおり、ドメイン管理サーバー (Domain Administration Server、DAS) の可用性は高くありません。DAS がダウンした場合、管理タスクは完了できません。インスタンスまたは NA で障害が発生したり使用不可となったりする場合、クライアントの接続先がクラスタのほかのインスタンスに変更されますが、クラスタの残りのインスタンスに対する負荷を減らすには自動回復が望ましい手段となります。また、アップタイムが主要な条件の 1 つである重要な配備については、ハードウェア、OS、およびネットワーク障害のシナリオを考慮する必要があります。 

高可用性ソリューションが必要な理由

高可用性ソリューションは、ネットワーク、ハードウェア、オペレーティングシステムの障害やヒューマンエラーなど、Application Server やユーザーランドアプリケーションで回復できない障害に対処するために必要です。このほか、OS やハードウェアのアップグレードまたは保守が行われた場合でも継続したサービスを提供するようなシナリオもあります。

高可用性ソリューションは、障害に対処するだけでなく、配備において、ネットワークレベルの負荷分散、リンク障害の検出、仮想化など、オペレーティングシステムの機能を最大限活用するのに役立ちます。

最適なソリューションの決定方法

高可用性ソリューションにより配備を改善できると判断した場合、市販製品からどのソリューションを選択すべきかを決定する必要があります。ソリューションを決定する際には、次の質問に対する答えが参考になります。

十分に成熟した堅牢なソリューションであるか。

ベンダーにより Sun Java System Application Server 専用に設計されたエージェントが提供されているか。

使用や配備が非常に簡単なソリューションであるか。

費用効率の高いソリューションであるか。

完成したソリューションであるか。Message Queue などの関連コンポーネントについて高可用性を
提供できるか。

重要な点として、優れたサポート (マニュアル、顧客サービス、シングルポイントでのサポート) が提供されるか。

Solaris Cluster が最適である理由

Solaris Cluster は、市販の Solaris プラットフォームに最適な高可用性ソリューションです。Solaris オペレーティングシステムと優れた形で統合できるため、Solaris に導入された新機能を、配備を変更せずに利用することが可能となります。Solaris Cluster では、コンテナでのアプリケーションの実行がサポートされており、使用可能なファイルシステムやプロセッサアーキテクチャーなどを適切に選択できます。たとえば、次のような特徴があります。

コンテナ、ZFS、FMA など、Solaris の機能を利用するためのカーネルレベルの統合。

市場でもっとも一般的に使用されているアプリケーションをサポートするための、多様なエージェント。

非常に堅牢で迅速な障害検出メカニズムと、負荷が非常に高い場合でも変わらない安定性。

IPMP ベースのネットワーク障害検出および負荷分散。

Sun Java System Application Server および Glassfish の両方で同一のエージェントを使用可能。

もっとも一般的な Solaris Cluster タスク用のデータサービス設定ウィザード。

データの破壊を回避するための、高度なフェンシングメカニズム。

ディスクパスの監視による、ストレージへのアクセスの喪失の検出。

Solaris Cluster による高可用性の実現方法

Solaris Cluster では、冗長コンポーネントを使用して高可用性を実現します。ストレージ、サーバー、およびネットワークカードが冗長です。 次の図では、2 つのノードを持つ単純なクラスタについて説明します。このクラスタには、推奨された冗長インターコネクト、両方のノードにアクセスできるストレージ、それぞれにパブリックネットワークインタフェースがあります。これは推奨される構成であり、最小限の構成に使用できる共有ストレージ、インターコネクト、およびパブリックネットワークインタフェースは 1 つのみであることに注意してください。Solaris Cluster には、個々のニーズに応じて、単一ノードのクラスタに対応できる柔軟性もあります。

LH =  論理ホスト名。複数の NIC での IP アドレスの移動に使用する仮想 IP のタイプ。

RAID =  冗長性とパフォーマンスの両方を提供する、適切なソフトウェアまたはハードウェアに基づく RAID メカニズム。

高可用性を DAS についてのみ提供するか、ノードエージェントについても提供するかを選択できます。この選択は、環境に応じて決定します。単一の Solaris Cluster インストールに複数のノードエ��ジェントを配備できるため、ノードエージェントのスケーラビリティは、高可用性の配備については問題となりません。これらのノードエージェントは、複数のリソースグループで設定されます。各リソースグループには、単一の論理ホスト、HAStoragePlus、エージェントノードリソースが含まれます。通常の配備ではノードエージェントは複数のノードに分散されているので、可用性の高いアーキテクチャーを使用するためにハードウェアを追加する必要はありません。ストレージは、ソフトウェアまたはハードウェアに基づく RAID により冗長にできます。

障害時の Solaris Cluster のフェイルオーバー手順

Solaris Cluster で提供される高度なアルゴリズムのセットを使用して、アプリケーションを再起動するか、冗長ノードにフェイルオーバーするかを決定できます。通常、IP アドレス、アプリケーションバイナリやデータが存在するファイルシステム、アプリケーションリソースは、リソースグループ (Resource Group、RG) と呼ばれる論理エンティティーにグループ化されます。その名前が示すとおり、IP アドレス、ファイルシステム、アプリケーションはリソースと見なされ、それぞれ一般的にエージェントと呼ばれるリソースタイプ (Resource Type、RT) で識別されます。回復メカニズム、つまり、再起動または別のノードへのフェイルオーバーは、タイムアウト、再起動の回数、およびフェイルオーバーの履歴の組み合わせに基づいて決定されます。エージェントには通常、アプリケーションの状態が変化するたびに起動、停止、および要件の確認に使用する開始メソッド、停止メソッド、確認メソッドがあります。また、アプリケーションの可用性を決定するために既定の期間に実行されるプローブも含まれています。

Solaris Cluster には、Sun Java System Application Server 用に 2 つの RT またはエージェントがあります。 DAS には SUNW.jsas、ノードエージェントには SUNW.jsas_na の各リソースタイプが使用されます。プローブのメカニズムには、"asadmin list-domain" および "asadmin list-node-agents" コマンドを実行して出力を解析し、DAS とノードエージェントが目的の状態にあるかどうかを判断することが含まれます。フェイルオーバー時、Application Server ソフトウェア、ファイルシステム、IP アドレスは、冗長ノードに移動されます。詳細は、Sun Cluster データサービスのガイド (http://docs.sun.com/app/docs/doc/819-2988) を参照してください。

サーバー障害時のフェイルオーバーについて、簡単な図を次に示します。
 

前述の設定では、NIC の 1 つのみに障害が発生した場合、Application Server は 2 つ目のノードに
フェイルオーバーされません。同じ IPMP グループに含まれる冗長 NIC は、DAS と NA が利用する論理ホストに対応します。一時的なネットワーク遅延は、論理ホストが NIC1 から NIC2 へ移動されるまでに発見されます。

Application Server の配備にはグローバルファイルシステム (Global File System、GFS) をお勧めします。これは、構成ファイル (および特定の配備ではバイナリ) がインストールされるファイルシステム上でログ以外の書き込みアクティビティーがほとんどないためです。GFS は常にすべてのノードにマウントされるので、ノード障害などの問題が発生した場合にフェイルオーバー時間を短縮して Application Server を迅速に起動できます。

保守とアップグレード

Solaris Cluster で障害から回復する際に役立つプロパティは、保守やアップグレードの作業時にサービスを継続して提供する目的でも使用できます。 

計画された OS の保守やアップグレードを行う場合、RG が冗長ノードに切り替えられ、保守を必要とするノードが非クラスタモードで再起動されます。計画されたアクションが実行されたあと、ノードがクラスタで再起動されます。クラスタの残りのノードすべてについて、同じ手順を繰り返すことができます。

Application Server の保守やアップグレードは、バイナリ、データ、および構成ファイルの格納方法によって異なります。 

1.) バイナリをノードの内部ハードディスクに、ドメインおよびノードエージェントの関連ファイルを共有ストレージに格納する。これは、頻繁な更新が必要な環境に望ましい方法です。欠点としては、パッチやアップグレードが異なるために、アプリケーションバイナリに不一致が生じる可能性があります。

2.) バイナリとデータの両方を共有ストレージに格納する。この方法では、常に一貫したデータを提供できますが、機能を停止せずにアップグレードや保守を行うのが困難です。

この選択は、組織の手順やプロセスを考慮して行う必要があります。

その他の機能

Solaris Cluster には、アフィニティーの概念に基づいて共存サービスに使用できる機能もあります。たとえば、ネガティブアフィニティーを使用して、本稼働環境がノードに切り替えられた場合にテスト環境を退避したり、ポジティブアフィニティーを使用して、データベースサーバーがパフォーマンス改善のためにホストされている同一のノードに Application Server リソースを移動したりできます。

Solaris Cluster に含まれている Sun Cluster Manager は、簡単に使えてわかりやすい GUI 管理ツールで、ほとんどの管理タスクの実行に使用可能です。

Solaris Cluster の内蔵テレメトリ機能により、CPU やメモリーなどのリソースの使用状況を監視できます。


Sun Java System Application Server では、Solaris Cluster に変更を加える必要はありません。エージェントがこのシナリオを考慮して設計されているためです。

同じエージェントを Glassfish にも使用できます。

メッセージキューブローカは、Sun Java System Message Queue エージェントの HA と同様に可用性を高くすることができます。

Sun の理念に従い、この製品は段階的にオープンソースとなっており、エージェントはすでに CDDL ライセンスに基づいて利用可能です。

同じコードベースに基づくオープンソース製品が、Open High Availability Cluster と呼ばれる OpenSolaris リリースについて入手できます。製品の詳細およびコミュニティーについては、http://www.opensolaris.org/os/communities/ohac にアクセスしてください。

また、オープンソース製品には、ユーザーが配備を十分にテストできるようにするための包括的なテストスイートが含まれています。詳細は、http://opensolaris.org/os/community/ha-clusters/ohac/Documentation/Tests/ を参照してください。


まとめ

ミッションクリティカルな環境では、あらゆるタイプの障害に対する可用性が非常に重要な基準となります。Solaris Cluster の設計は、Solaris OS との統合、安定性、Sun Java System Application Server 専用に設計されたエージェントを特徴としており、Application Server の最高の可用性を提供するのに最適です。
 

Madhan Kumar
Solaris Cluster エンジニアリング

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.