TruCluster Server 環境を導入すると,最小限の作業で,既存のアプリケーションをクライアントに対して高可用性にすることができます。また,クラスタの性能と高可用性の機能を十分に活用する新しいアプリケーションも稼働させることができます。クラスタ内で実行していることをあまり意識しないで,高可用性アプリケーションを稼働させることができ,アプリケーションは,どのクラスタのメンバからもディスクのデータにアクセスすることができます。
TruCluster Server の CAA (Cluster Application Availability) サブシステムを使用すると,アプリケーションを別のクラスタ・メンバ上で再起動して,メンバとリソースの障害から回復できます。アプリケーションが実行されているクラスタ・メンバに障害が発生するか,または特定の必要なリソースに障害が発生すると,CAA はそのアプリケーションを別のメンバに再配置するか,またはフェイルオーバします。別のメンバとは,必要なリソースが使用できるか,またはそのメンバ上でリソースの起動が可能なメンバです。
TruCluster Server ではまた,分散型アプリケーションのコンポーネントを並列に実行することができます。これにより,クラスタ特有の同期メカニズムと性能の最適化を利用しながら,高可用性を実現することができます。
TruCluster Server を初めて導入する場合は,TruCluster Server の 『クラスタ概要』をまず読んで,TruCluster Server 製品の概要を理解してください。また,アプリケーションの高可用性を実現する TruCluster Server の各種機能については,次の章を参照してください。
第 2 章では,CAA サブシステムを使ってシングル・インスタンス・アプリケーションの高可用性を実現する方法を説明します。
第 3 章では,マルチ・インスタンス・アプリケーションで省略時のクラスタ別名を使って,ネットワーク・クライアントがクラスタを単一システムとして見えるようにする方法を説明します。
TruCluster Available Server または TruCluster Production Server 環境から移行する場合は,Part 2 をお読みください。ASE スタイルのアプリケーションを TruCluster Server に移行する方法について説明しています。
この章では,次のようなクラスタ・アプリケーションについて説明します。各アプリケーションの種類は 1.1 節で詳しく説明します。
シングル・インスタンス
マルチ・インスタンス
分散型
クラスタ・アプリケーションは,表 1-1
に示す基本的なタイプに分けることができます。
表 1-1: TruCluster Server アプリケーションのタイプ
タイプ | 説明 | 例 |
シングル・インスタンス | シングル・インスタンス・アプリケーションは,一度にクラスタの 1 つのメンバ上だけで動作できる。 | シングル・インスタンスの DHCP (Dynamic Host Configuration Protocol) サーバ |
マルチ・インスタンス | マルチ・インスタンス・アプリケーションは,クラスタの複数のメンバ上で動作できる。また,1 つのクラスタでいくつでもアプリケーションのコピーを実行できる。 | マルチ・インスタンスの Apache Web サーバ |
分散型 | 分散型アプリケーションでは,クラスタ・メンバ全体に分散して配置されたモジュールが,独立に連携して動作する。 | OPS (Oracle Parallel Server),Oracle 9i RAC (Real Application Cluster) |
以降の各項では,これらの 3 つのタイプについて詳しく説明します。
1.1.1 シングル・インスタンス・アプリケーション
シングル・インスタンス・アプリケーションは,一度に 1 つのクラスタ・メンバ上でのみ動作します。図 1-1
に示すように,すべてのクライアントが 1 つのメンバ上のシングル・インスタンス・アプリケーションにアクセスします。
図 1-1: シングル・インスタンス・アプリケーションへのアクセス
アプリケーションがインストールされているクラスタ・メンバに障害が発生したり,リソースにアクセスできなくなった場合,CAA サブシステムは,動作中の別のメンバへアプリケーションをフェイルオーバさせることができます。CAA の使用方法についての詳細は,第 2 章を参照してください。図 1-2
に,1 つのクラスタ・メンバに障害が発生したために,アプリケーションが 2 番目のクラスタ・メンバにフェイルオーバされる方法を示します。
図 1-2: CAA を使用したアプリケーションのフェイルオーバ
表 1-2
では,TruCluster Server と,TruCluster 製品の以前のバージョンとのシングル・インスタンス・アプリケーションのアーキテクチャの違いを説明しています。
表 1-2: シングル・インスタンス・アプリケーションのアーキテクチャの違い
TruCluster Server バージョン 5.0 以降 | TruCluster Available Server と TruCluster Production Server バージョン 1.6 以前 |
クラスタ・ファイル・システム (CFS) があるため,クラスタの 1 つのメンバ上にインストールしたアプリケーションとその構成内容を,すべてのメンバ上で見ることができる。ただし,アプリケーションに同期機構が組み込まれていないため,一度に 1 つのメンバでしかアプリケーションを実行できない。 | クラスタの 1 つのメンバ上にインストールしたアプリケーションとその構成内容は,そのメンバ上でしか見たり使用したりすることはできない。 |
CAA を使って,アプリケーションの起動,停止,およびリソースの依存性の要件を定義する。ストレージは,CFS とデバイス要求ディスパッチャによって透過的に管理される。CAA の処理スクリプト内でクラスタ別名やインタフェース別名を使って,IP 別名の要件を処理することができる。 | ASE を使って,アプリケーションの起動,停止,ストレージ,および IP 別名を定義する。 |
TruCluster Server は,Tru64 UNIX バージョン 5.1B とバイナリ互換性があるため,Tru64 UNIX 上で正常に動作し,新しい形式のデバイス名 (dsk
) を認識するアプリケーションは,クラスタ内の少なくとも 1 つのメンバ上で動作します。デバイスの命名規則については,4.2 節を参照してください。
1.1.2 マルチ・インスタンス・アプリケーション
マルチ・インスタンス・アプリケーションは,その複数のインスタンスが 1 つのシステム上で,または,クラスタ内の複数のメンバ上で動作できます。マルチ・インスタンス・アプリケーションを複数のシステム上で実行する場合,アプリケーションはクラスタ対応に修正されています。たとえば,一時ファイル名は,上書きを防ぐために変更されています。
マルチ・インスタンス・アプリケーションは,典型的な高可用性アプリケーションです。1 つのクラスタ・メンバが故障しても,他のメンバ上で動作するそのアプリケーションの別のインスタンスに影響を与えません。図 1-3
に示すように,マルチ・インスタンス・アプリケーションでは,クラスタ別名を利用して,クライアントの要求を他のすべてのクラスタ・メンバに分散させることができます。この図では,クライアントはクラスタ別名
deli
を介してマルチ・インスタンス・アプリケーションにアクセスしています。
図 1-3: マルチ・インスタンス・アプリケーションへのアクセス
表 1-3
では,TruCluster Server とそれ以前の TruCluster ソフトウェア製品におけるマルチ・インスタンス・アプリケーションのアーキテクチャの違いを説明しています。
表 1-3: マルチ・インスタンス・アプリケーションのアーキテクチャの違い
TruCluster Server バージョン 5.0 以降 | TruCluster Available Server と TruCluster Production Server バージョン 1.6 以前 |
クラスタ対応のマルチ・インスタンス・アプリケーションでは,ソース・レベルで明示的に分散ロック・マネージャ (DLM) のアプリケーション・プログラミング・インタフェース (API) を使用する。クラスタ別名により,アプリケーションのインスタンス内でのクライアント要求のルーティングが自動化される。 | アプリケーションは,固有のインタフェース別名を持つ複数の ASE サービスを作成することにより,マルチ・インスタンスとして実行できる。クラスタ別名はない。負荷分散とクライアント要求の分散は,アプリケーション内に設計しておかなければならない。アプリケーションでは,DRD (Distributed Raw Disk) デバイスをストレージとして使用できる必要があり,UNIX ファイル・ロック・セマンティクス,DLM またはアプリケーション固有のロック・メカニズムを使用する必要がある。 |
クラスタ対応でないマルチ・インスタンス・アプリケーションでは,標準 UNIX ファイル・ロックまたは DLM を使って,共用データへのアクセスの同期をとる必要がある。 | 標準 UNIX ファイル・ロックはクラスタ単位で動作するように実装されていないため,クラスタ対応でないアプリケーションでは,DLM を明示的に使用する必要がある。 |
クラスタ内で複数のアプリケーション・インスタンスを実行できるようにするには,次のことを行わなければなりません。
プロセス間通信は,リモート・プロシージャ・コール (RPC) またはソケット接続を介して行う。
共用ファイルや共用データのアクセスでは,同期をとる必要がある。
flock
() システム・コールまたは分散ロック・マネージャ (DLM) を使って,共用データへのアクセスの同期をとります。
コンテキスト依存シンボリック・リンク (CDSL) または他の方法を使って,アプリケーションのインスタンスごとにログ・ファイルと一時ファイルを作成する。
アプリケーションの構成に対してメンバごとに固有な要件がある場合は,そのアプリケーションの動作する各メンバにログオンしてアプリケーションを構成する必要がある。
たとえば,アプリケーションのインストール・スクリプトがクラスタ対応でない (つまり,アプリケーションが,クラスタ内にインストールされていることを意識していない) 場合,アプリケーションをインストールした後に,構成を調整する必要があります。詳細は,アプリケーションの構成を説明したドキュメントを参照してください。
省略時のクラスタ別名を使ってネットワーク接続要求を他のメンバに分散させるためには,/etc/clua_services
ファイルに各アプリケーションのポートを定義する必要がある。
in_multi
別名属性を付け加え,クラスタ別名サブシステムが,省略時のクラスタ別名宛の接続要求を,その別名のすべてのメンバに分散させるようにします。ポートの定義についての詳細は,clua_services
(4) を参照し,マルチ・インスタンス・アプリケーションにクライアントを透過的にアクセスさせるために,クラスタ別名を使用する方法については,第 3 章を参照してください。
上記の内容の詳細説明と,アプリケーションの移行に関する一般的な説明については,第 4 章を参照してください。
1.1.3 分散型アプリケーション
分散型アプリケーションは,クラスタ対応のアプリケーションです。 つまり,クラスタ上で動作していることを認識し,通常,分散実行により性能の向上を計っています。分散型アプリケーションは,DLM や Memory Channel など,クラスタのアプリケーション・プログラミング・インタフェース (API) を使用します。分散型アプリケーションについての詳細は,第 6 章を参照してください。