目次


IBM PureApplication System に高可用性をもたらすためのトポロジー

Comments

はじめに

IBM PureApplication System に関してお客様から最もよく寄せられる質問に、「可用性の高い IBM PureApplication System をセットアップするにはどのようにすればよいのでしょうか?」という質問があります。この記事では、可用性の高い IBM PureApplication System をセットアップするための概要と推奨されるセットアップ方法を説明します。ただし、「継続的可用性 (Continuous Availability: CA)」に関する問題は対象外としていることに注意してください。これらの問題はより複雑なので、別のトピックとして取り上げます。また、ここで検討するのは、WebSphere Application Server 上に作成された仮想システムに関する「高可用性 (High Availability: HA)」についてのみです。仮想アプリケーションの HA (特にラック間の HA) や、WebSphere MQ および WebSphere Message Brokerなどの他の IBM ミドルウェアの HA については、今後の記事で取り上げることにします。

この記事は入門編として、上述の質問に対する答えとなる方法の概要を説明します。今後の一連の記事で、この記事で説明する可用性レベルを実現する例を詳しく説明します。

高可用性

高可用性 (HA) のために検討しなければならないメカニズムは 2 種類あります。1 つは、PureApplication System のファームウェアとハードウェアに組み込まれる、ラック内のメカニズムです。このメカニズムでは、PureApplication System 機器ごとに 2 つの管理ノード (一方は、もう一方のバックアップ用) が含まれるため、管理環境自体もラック内で冗長化されます。

PureApplication System は、それぞれのラック内に単一障害点が一切存在することがないように慎重に設計されています。したがって、WebSphere 製品と DB2 からなる仮想システムが、完全にラック内で実行される複数の WebSphere Application Server クラスター・メンバーを持つようにすれば、計算ノード、ハードディスク・ドライブ、さらには TOR (Top Of Rack) スイッチのいずれかで障害が発生したとしても、ラックに組み込まれた冗長性によって障害から保護されます。計算ノードに障害が発生した場合は、そのノード上で実行されている JVM が消失するため、WebSphere HTTP Server プラグイン自体が障害を検出し、すべてのトラフィックが他のクラスター・メンバーへとシームレスにリルートされます。

すると、PureApplication System が計算ノードのダウン状態を検出し、その計算ノードから同じクラウド・グループ内の別の計算ノードに仮想マシンを移します。ダウン状態の計算ノードは、最終的にはプラグインによって再びクラスターに結合されて、トラフィックの受け入れを再開します。同様に、同じクラウド・グループ内にシステム全体が構築された DB2 HADR (High Availability Disaster Recovery) システムは、プライマリー・データベースで障害が発生すると、要求をシームレスにセカンダリー・データベースに転送します。PureApplication System の配置アルゴリズムには、ほとんどの場合、単一の計算ノード上に 2 つのクラスター・メンバーを配置すること (クラウド・グループの構成とそのクラウド・グループ内での計算リソースの可用性がこの配置を許容する場合) をできるだけ避けようとするだけのインテリジェンスがあります。

フェイルオーバーのニーズの 90% には、これらのメカニズムで対処できるはずです。これは素晴らしいことですが、それでも多くのお客様にとっての「HA」に完全に対応するわけではありません。お客様が「HA」と言うときに、具体的に意味しているのは、ラック間のメカニズムです。つまり、壊滅的な障害 (例えば、水冷式ドアの配管が破損して、1 つのラック全体に水がかぶってしまった場合など) により、1 つのラック全体に障害が発生した場合にどう備えるかといったことです。このような高可用性を提供するためにも、WebSphere 製品、DB2、および IBM Workload Deployer の標準機能を利用することができます。

これらの機能で何ができるかと言うと、まず、標準パターンを使用して 1 つのラックに プライマリー・データベースをセットアップし、別のラックにセカンダリー・データベースをセットアップします。こうすることで、ラック内のハードウェア障害 (計算ノードの障害) や、1 つのラック全体に及ぶ障害 (配管が破損した例など) によって プライマリー・データベースに障害が発生したとしても、データベース要求を処理することができます。同様に、WebSphere Application Server に備わっている従来の HA メカニズムを利用して、2 つの異なるフェイルオーバー・メカニズムを提供することもできます。その 1 つの方法は、「2 番目」のラックに WebSphere Application Server インスタンスを作成し、これらのインスタンスを「1 番目」のラック内の Deployment Manager (DMgr) とフェデレーションさせることです。あるいは、2 つのセル (ラックごとに 1 つ) を作成し、セル間の負荷分散を (例えば、外部 DataPower 機器で Application Optimization オプションのロード・バランシング機能を使用して) ラック外部で管理するという方法もあります。これらのメカニズムを使用するには、いずれにしてもシステムを作成する PureApplication System 管理者の側で、手作業による介入がある程度必要です。それがどれだけ必要になるかは、コンポーネントごとに異なります。

この記事では、以下の 2 つのシナリオを検討します。

  1. 最初のシナリオは、1 つのデータ・センター内部に 2 つの (あるいはそれ以上の) PureApplication System ラックの間に HA を提供するというシナリオです。
  2. もう 1 つは、地理的に離れた 2 つのデータ・センター間でのシナリオです。

1 つのデータ・センター内のシナリオ

最初のシナリオで保護する対象となるのは、1 つの PureApplication System 全体の障害です。ラック内のすべてのコンポーネントに冗長性があることを考えると、PureApplication System 全体の障害はとても起こりそうもない事態ですが、1 つのデータ・センター内で複数の PureApplication System ラック間に HA を構成するのが望ましい理由は他にもあります。例えば、単一のラックやハイパフォーマンス・ラックでさえも持ちこたえられないほどにトラフィックが急増した場合です。図 1 に、実現するべき最終的なシステム構成を示します。

図 1. データ・センター内で 1 つのセルを共有する HA 構成
データ・センター内で 1 つのセルを共有する HA 構成
データ・センター内で 1 つのセルを共有する HA 構成

このシナリオ (「シングル・セル」モデルと呼びます) で最初に取り掛かる作業は、1 番目のラック (図 1 の IPAS A) に DMgr、IHS (IBM HTTP Server) ノード、および WebSphere Application Server ノードからなるセルを定義する仮想システム・パターンを作成することです。次に、IPAS B ラックで 2 番目の仮想システム・パターンを作成します。この仮想システム・パターンには、IHS ノードと WebSphere Application Server ノードだけを含め、これらのノードを作成済みのセルに手作業で関連付けます。これにより、図 1 に示されているように、両方のマシンにまたがるセル境界が定義されます。同じように、IPAS A の プライマリー DB2 HADR ノードの仮想システム・パターンを作成し、IPAS B のセカンダリー DB2 HADR ノードの仮想システム・パターンを作成します。この構成を有効にするには、2 つのラック内の IHS インスタンスのすべてを認識するように外部ロード・バランサーを構成しなければならないことに注意してください。さらに、2 つのラック全体での HTTP セッション管理を考慮する必要があります。その手法として最も単純なのは、共有データベースに対するデータベース・セッション・パーシスタンスを有効にすることです。

このように構成すると、いずれかのラックが完全に使用できなくなるような障害にも耐えられるようになります。ラック A に障害が発生した場合、ラック B 上の IHS インスタンスと WebSphere Application Server ノードが外部ロード・バランサーから要求を受け取り、セカンダリー DB2 HADR が障害の発生した プライマリー・ノードを引き継ぎます。この場合に失われる唯一の機能は、DMgr が使用できなくなることから変更内容をラック B 上のクラスター・メンバーにデプロイできなくなることです。ラック B に障害が発生した場合には、ラック A は引き続き通常通りに機能し、外部ロード・バランサーからの要求をいつものように受け入れます。

2 つのデータ・センター間のシナリオ

2 つの PureApplication System ラックが地理的に離れた場所にある場合、事態は少し複雑になります。このシナリオ (「デュアル・セル」モデルと呼びます) では、共有データベースを使用して、少なくとも 2 つの異なるセルを作成する必要があります (図 2 を参照)。

共有データベースを介して 2 つのセルで HTTP セッション・レプリケーションを使用することは可能ですが、この方法が採られることはめったにありません。ほとんどの場合は、外部ロード・バランサーにセッション・アフィニティーを構成します。つまり、特定のセルで開始されたセッションの要求は、常にそのセルにルーティングされるということです。フェイルオーバーによってセッション・データが失われるのを許容できる場合には、セッション・パーシスタンスのために別個のローカル・データベースをセットアップすることができます。

図 2. 2 つのアクティブ・アクティブ WebSphere セル
2 つのアクティブ・アクティブ WebSphere セル
2 つのアクティブ・アクティブ WebSphere セル

図 2 に示されているセルの構成に注目してください。このシナリオでは、各 PureApplication Systemに、それぞれ別々にセルを作成します。ただし、これらのセルはまったく同一のものです。前述のとおり、セル境界は各システム内に完全に収容されます。この手法では、WebSphere セルはアクティブ・アクティブ・モードで構成される一方、DB2 HADR データベースは前のシナリオと同じくアクティブ・パッシブ・モードで構成されます。このシナリオでの違いは、セルが互いに独立していることです。それぞれの WebSphere Application Server ノードがラック間で通信することはありません。

この手法を実装するのにおそらく最も簡単な方法は、最初のセルを IPAS A 内の仮想システムで作成してから、その仮想システム・パターンをエクスポートして IPAS B にインポートし、最後にそのパターンの新しいインスタンスを IPAS B で作成することです。この場合も前の例と同じく、IPAS A の仮想システム・パターンを使用して プライマリー DB2 HADR を作成し、IPAS B の別の仮想システム・パターンを使用して セカンダリー DB2 HADR を作成する必要があります。この場合の外部ロード・バランサーも同じく、両方のセル内の IHS インスタンスのすべてにトラフィックをフィードするようにセットアップされます。いずれかのラックが障害で完全に使用できなくなった場合には、もう一方のラックがトラフィックを中断させることなく引き継ぎます。

前の例ではすべてのインスタンスを 1 つのセルに参加させましたが、それとは対照的に、このシナリオでは 2 つのセルを作成する必要があります。その理由は、一般に、クラスター・メンバーをその DMgr から地理的に分散させることは望ましくないためです。DMgr とクラスター・メンバーとの間で (管理やコード配布などのために) 必要となる通信を広域ネットワークで行うのは効率的ではないため、ベスト・プラクティスとして、長距離でセルのフェデレーションを行うことはお勧めしません。

2 つのシナリオの比較

シングル・セルのシナリオでは、すべての WebSphere Application Server インスタンスを 1 箇所から管理します。つまり、1 つの Deployment Manager で 1 つの管理コンソールを使用して、環境の変更を両方のラックに適用するということです。しかも、リソースが効率的に使用されるように、IHS プラグインによって追加のロード・バランシングおよびサーバー・アフィニティーを両方のラックに設定することができます。従って基本的に、2 つの別個のラックを使用しているという事実は、WebSphere をセットアップする際にはまったくわからないようになっています。

その一方、この手法には初期セットアップが複雑になるという犠牲が伴います。この手法では、個別のパターンで構成されたラック B 上のノードが、ラック A 上の DMgr に接続されます。外部ロード・バランサーにはすべての IHS インスタンスが構成されていなければならないため、いずれかのラックで新しい IHS インスタンスが作成されて起動されるたびに、この構成ステップを繰り返さなければなりません。また、仮想システムの観点から考えると、2 つの個別の仮想システム (ラックごとに 1 つ) があるということは、すべての必要な変更をその両方に、できれば同時に適用しなければなりません。さらに、ラックの間には追加の (理想的には極めて高速な) ネットワーク層が設けられるため、例えば 2 番目のラックから 1 番目のラックのデータベースを呼び出す場合や、一方のラック上の IHS ノードともう一方のラック上のクラスター・メンバーの JVM との間で要求を受け渡す場合、あるいは DMgr と 2 番目のラック上の個々のノード・エージェントとの間で通信を行う場合などは、余計にコストがかかることになります。そうは言っても、2 つのラック間に極めて高速なネットワーク接続が確立されることを前提にすれば、このオーバーヘッドは許容できるはずです。

デュアル・セルのシナリオでは、セットアップが単純化されます。実際、このシナリオは 1 つのデータ・センター内で簡単に実行することができます。両方のセルは、WebSphere 管理コンソールの観点からも、PureApplication System 管理の観点からも、それぞれに独立して管理されます。これは例えば、ラック間の影響を考慮することなく、ルーティングやスケーリング・ポリシーなどの PureApplication System のメカニズムを最大限に活用できることを意味します。したがって、それぞれのラックには同じパターンをデプロイして異なる IP アドレスを使用することが可能になります。

しかしデュアル・セルのシナリオにも欠点はあります。それは、すべての管理上の変更は、2 つの異なるコンソールから 2 つの WebSphere セルに適用しなければならないことです。また、外部ロード・バランサーは、最初のシナリオと同じく自らの手で構成する必要があります。いずれのシナリオでも、アクティブなデータベース・サーバーは常に 1 つだけです。これは、セカンダリー・データベースが設定されたラック上のリソースの一部は、通常の運用状態では使用されないことを意味します。

まとめ

この記事では、WebSphere Application Server と DB2 アプリケーションで高可用性を実現する方法を、データ・センター内でシングル・セルまたはデュアル・セルの手法を使用した場合、およびデータ・センター間でデュアル・セルの手法を使用した場合のそれぞれで説明しました。

ラックが 3 つ以上ある場合をはじめ、この記事で説明した以外の構成も可能であることに注意してください。例えば、データ・センターごとに 2 つのラックを設け、それぞれのラックにセルを定義すれば、セルの数は合計 4 つになります。あるいは、ラックごとに複数のセルを定義することもできます。さらに、セルによって異なる数のクラスター・メンバーを含めることも考えられます。

このようにさまざまな構成が考えられますが、いずれにしても、構成手順とベスト・プラクティスは PureApplication 以外の環境での場合と同じです。この記事では単に、PureApplication System を実行する場合に適用される検討事項を追加し、そのコンテキストで上記各シナリオにおけるセットアップ方法を説明しました。2 つのデータ・センターで 1 つの WebSphere セルを実行することはできるだけ避けたほうが良いため、そのシナリオは意図的に取り上げていません。

この記事で説明した例は、WebSphere Application Server と DB2 で構成されるアプリケーションに限定された例でしたが、これらの手法を適用して他の製品構成に限定される方法にすることができます。WebSphere MQ や WebSphere Message Broker などの他のエンタープライズ・ソリューションに対する手法については、今後の記事で紹介します。


ダウンロード可能なリソース


関連トピック


コメント

コメントを登録するにはサインインあるいは登録してください。

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=WebSphere, Cloud computing
ArticleID=826725
ArticleTitle=IBM PureApplication System に高可用性をもたらすためのトポロジー
publish-date=07262012