Linuxでの高可用性ミドルウェア、第1回: HeartbeatとApache Webサーバー

オープン・ソースのソフトウェアが低価格ソリューションを提供

この記事は5回シリーズの第1回です。今回はソフトウェアの高可用性とはどのようなものか、またHigh-Availability Linuxプロジェクトのheartbeatソフトウェアを2ノードのシステムにインストール、設定するにはどうすべきかについて学びます。また、高可用サービスとして実行するために、Apache Webサーバーをどのように構成するかについても学びます。

Hidayatullah Shaikh (hshaikh@us.ibm.com), Senior Software Engineer, IBM

Hidayatullah H. ShaikhはIBM T.J. Watson Research Centerのオンデマンド・アーキテクチャーと開発チームのシニア・ソフトウェア技術者です。関心領域は広く、ビジネス・プロセスのモデル化と統合、サービス指向アーキテクチャー、グリッド・コンピューティング、eコマース、エンタープライズJava、データベース管理システム、それに高可用性クラスターに渡っています。連絡先はhshaikh@us.ibm.comです。



2004年 10月 12日

オンデマンド・コンピューティングの成功にとって、システムの稼働時間を最大に維持することが次第に重要になってきています。残念ながら、高可用性(high availability: HA)のための市販ソリューションは高価な上、使いこなすためには熟練が必要です。このシリーズでは、市販のソリューションに頼らず安価にHAサービスを実現するために、公開で入手可能なソフトウェアを利用する手法を5回に渡って解説して行きます。

このシリーズでは順を追いながら、高可用性のApache WebサーバーやWebSphere® MQキュー・マネージャー、LoadLevelerクラスター、WebSphere Application Serverクラスター、そしてDB2® Universal Database on Linux™を、どのように構築するかを説明します。システム管理者がこのシステムの使い方や維持管理を学ぶために必要な時間の投資は、ごく僅かです。このシリーズで説明する手法はまた、Linux上のどんなサービスにも適用することができます。

このシリーズを最大限に利用するためには、WebSphere MQやWebSphere Application Server、IBM LoadLeveler、DB2 Universal Database、それに高可用性クラスターに関して、基本的な理解が必要です。

最初に

ビジネス上致命的に重要な環境で、あるいは非常に役割の大きな環境でソフトウェア製品を使用する場合には、可用性を考慮する必要があります。可用性というのはシステムの能力の指標であり、クラッシュが起きた場合、また機器の故障、環境のトラブルなどの状況下であっても、行うべきことを行えるかどうかを表します。最近では重要な商用アプリケーションが次々にインターネットに移行しつつあるため、高可用性サービスを提供することが次第に重要になってきています。

この記事では、HAソリューションを実装する上で突き当たるような問題に焦点を当てます。まずHAの概念や入手可能なHAソフトウェア、使用するハードウェア、heartbeat(Linux用のオープン・ソースのソフトウェア)のインストールや構成の詳細などを再確認し、heartbeatを使うことによって、いかにWebサーバーを高可用なものにできるかを見て行きます。


ハードウェア要求

このシリーズで説明するテスト・シナリオでは、次のようなハードウェアが必要です。

  • イーサネット・アダプターを備え、Linuxをサポートする4台のシステム
  • 共有の外部SCSIハード・ドライブ(ツイン・テール・ディスク)が1台
  • IBM仕様のシリアル・ヌル・モデム・ケーブルが1本

私の構成では、1 GBのRAMを備えたIBM eServer™ xSeries® 335マシンを使いました。共有ディスクとしては、これらのマシンの1台をNFSサーバーとして使用しました。この記事で必要なソフトウェアはRed Hat Enterprise Linuxとheartbeatのみですが、完全な構成に必要なソフトウェアは次の通りです。

  • Red Hat Enterprise Linux 3.0 (2.4.21-15.EL)
  • heartbeat 1.2.2
  • IBM Java 2 SDK 1.4.2
  • WebSphere MQ for Linux 5.3.0.2 with Fix Pack 7
  • LoadLeveler for Linux 3.2
  • WebSphere Base Edition 5.1.1 for Linux with Cumulative Fix 1
  • WebSphere ND 5.1 for Linux with Fixpack 1
  • DB2 Universal Database Enterprise Server Edition 8.1 Linux

テスト・シナリオは、下記のDownloadセクションにリストされたコード・パッケージをダウンロードすることで入手できます。表1はhahbcode.tar.gzにあるディレクトリーを表します。

表1. サンプルのコード・パッケージに含まれているもの
ディレクトリー内容
heartbeatheartbeat用のサンプル・コンフィギュレーション・ファイル
wwwApache Web ServerのHAをテストするためのHTMLファイル
mqWebSphere MQ HA用のスクリプトとコード
  • mqseries: Linuxサービスとして、WebSphere MQキュー・マネージャーや他のプロセスを起動停止するためのスクリプト
  • hascript: HAキュー・マネージャーを作るためのスクリプト
  • send (sh/bat): データをキューに置くためのスクリプト
  • receive (sh/bat): キューからデータを取得/閲覧するためのスクリプト
loadlLinuxサービスとしてのLoadLevelerを起動停止するためのloadlファイル
wasWebSphere Application Server HA用のスクリプトとコード
  • wasdmgr: LinuxサービスとしてWebSphere ND Deployment Managerを起動停止するためのスクリプト
  • wasnode: LinuxサービスとしてのWebSphere Node Agentを起動停止するためのスクリプト
  • wasserver: LinuxサービスとしてのWebSphere Application Serverを起動停止するためのスクリプト
  • sample_ver_(1/2/3): WebSphere HAテスト用エンタープライズ・アプリケーション・サンプルの様々なバージョンを含むディレクトリー
db2データベースの可用性チェックや表の生成、表への行の挿入、表の行の選択などを行うスクリプト

高可用性の概念

高可用性は、システムやコンポーネント、アプリケーションなどのトラブルの際に、重要なサービスを素早く回復するためのシステム管理戦略です。高可用性の目標は、耐障害性よりもむしろ、サービスの中断を最小限にとどめることです。重要なビジネス・オペレーションを行っているシステムの故障に対して最も一般的なソリューションは、もう1台のシステムを待機させておき、故障したシステムの作業負荷は待機しているシステムで担わせるようにするものです。

「クラスター」という用語は、コンピューター業界では異なった意味を持っています。この記事では特に断らない限り、クラスターとはハートビート・クラスターを意味します。ハートビート・クラスターは、クラスター内部で実行していて高可用性サービスを提供するために協力しているノードとリソース(ディスクやネットワークなど)の集合です。もし使われているマシンの1台が故障すると、ビジネス・オペレーションを維持するために必要なリソースは、クラスター内で使用可能な別のマシンに移されます。

主なクラスター構成には次のような2つがあります。

  • スタンバイ構成: 最も基本的なクラスター構成で、一つのノードが実際の動作を行い、もう一方のノードはスタンバイとしてのみ動作します。スタンバイ・ノードは実際の動作は行わず、アイドル状態と言われます。この構成はコールド・スタンバイ(cold standby)と呼ばれることもあります。この構成ではハードウェアに高度の冗長性が必要となります。このシリーズの記事では、コールド・スタンバイ構成に焦点を当てることにします。
  • テークオーバー構成(Takeover configuration): より高度な構成で、全てのノードが何らかの動作を行います。一つのノードが故障した場合には、重要な動作は引き継がれます。一方的テークオーバー(one-sided takeover)構成の場合には、付加的で、重要でなく、移動可能ではない一部の動作をスタンバイ・ノードが実行します。相互テークオーバー(mutual takeover)構成の場合には、全てのノードが高可用(移動可能)な動作を行います。このシリーズの記事では、テークオーバー構成は取り上げません。

HAクラスターをセットアップするためには、幾つかの重要項目に関して計画を立てる必要があります。

  • データを保存するために使用するディスクは、クラスターを構成するサーバーに対して、共有ではない独立の接続(シリアル・ケーブル)またはLANで接続されている必要がある。
  • 故障したリソースを自動検出する方法が必要である。これはハートビート・モニターと呼ばれるソフトウェア・コンポーネントによって行われる。
  • 故障が起きた場合には、生き残っている1台以上のクラスター・メンバーに対して、リソース所有権を自動転送する必要がある。

入手可能なHAソフトウェア

現在入手できるようなソフトウェアの大部分は、heartbeatのモニタリング機能やリソース・テークオーバー機能を備えています。下記のリストは、様々なオペレーティング・システムで高可用性クラスターを構成するために利用可能なソフトウェアのリストです。

  • heartbeat (Linux)
  • High Availability Cluster Multiprocessing - HACMP (AIX)
  • IBM Tivoli System Automation for Multiplatforms (AIX, Linux)
  • Legato AAM 5.1 (AIX, HP-UX, Solaris, Linux, Windows)
  • SteelEye LifeKeeper (Linux, Windows)
  • Veritas Cluster Server (AIX, HP-UX, Solaris, Linux, Windows)

このシリーズではオープン・ソースのHAソフトウェアheartbeatについて説明しますが、ここで学ぶ概念は、上記ソフトウェア・システムのどれに対しても当てはめることができます。


High-Availability Linuxプロジェクトとheartbeat

High-Availability Linuxプロジェクトと呼ばれるオープン・ソースのプロジェクトの目標は、コミュニティーでの開発作業を通してRAS、つまり信頼性(Reliability)、可用性(Availability)、サービス性(Serviceability)を向上するクラスター化ソリューションをLinuxに対して提供することです。Linux-HAプロジェクトは広く使われており、数多くの興味深い高可用性ソリューションにおいて、重要コンポーネントになっています。

HeartbeatはLinux-HAプロジェクトのWebサイトで入手できる公開パッケージの一つであり、どのようなHAシステムでも要求される基本的な機能、つまりリソースの起動停止やクラスター内のシステムの可用性モニタリング、クラスター内ノード間での共有IPアドレス所有権の転送などを提供します。heartbeatはシリアル・インターフェースまたはイーサネット、あるいはその両方を通して、特定なサービスが健全な状態にあるかどうかをモニターします。現在のバージョンでは、特別なheartbeat「pings」を使ってサービスの状態や可用性をチェックする場合、2ノードの構成をサポートしています。heartbeatはこのシリーズの記事での解説をはるかに上回る複雑なシナリオ、例えば2つのノードが並行動作して負荷分散するアクティブ/アクティブ構成などにおいても、重要な基礎となります。

heartbeatと、heartbeatが使われているプロジェクトに関する情報はLinux-HAプロジェクトのWebサイトを見てください(参考文献にリンクがあります)。


クラスター構成

このシリーズの記事で使用するテスト用のクラスター構成を図1に示します。この構成は1対のクラスター化したサーバー(ha1とha2)から成り、そのどちらも、複数台の物理ディスクを持つ共有ディスク格納装置に対してアクセスできます。これらのサーバーはコールド・スタンバイ・モードにあります。アプリケーション・データは、どちらのノードからもアクセスできる共有デバイス上にある必要があります。これは共有ディスクの場合もあれば、ネットワーク・ファイルシステムの場合もあります。デバイス自体は、データ破損を避けるためにミラーリングしておくか、またはデータ保護機構を持つべきです。こうした構成はしばしば共有ディスク・クラスターと呼ばれますが、実際にはどのディスクも一度に1ノード以上からアクセスされることはないので、何も共有しない構成と言えます。

図1. 実稼働環境でのheartbeatクラスター構成
Heartbeat cluster configuration in a production environment

私はテスト用の構成として、図2に示すようにNFSを共有ディスク機構として使います。ただし、特に実稼働環境では、図1に示すオプションを使うようにお勧めします。2つのシステムのシリアル・ポート間を接続したヌル・モデム・ケーブルは、2つのノード間でのheartbeatを伝送するために使われます。

図2. NFSを共有ファイル・システムに使ったheartbeatクラスター構成
Heartbeat cluster configuration using NFS for shared file system

表2は私が両ノードで使った構成を示しています。皆さんの場合には、DNSあるいは両ノードの/etc/hostsファイルで、ホスト名とIPアドレスが分かっている必要があります。

表2. テスト用のクラスター構成
役割ホスト名IP アドレス
共有(クラスター)IPha.haw2.ibm.com9.22.7.46
ノード1(マスター)ha1.haw2.ibm.com9.22.7.48
ノード2(バックアップ)ha2.haw2.ibm.com9.22.7.49
ノード3(図では示していない)ha3.haw2.ibm.com9.23.7.50
NFSサーバーhanfs.haw2.ibm.com9.2.14.175

シリアル接続を設定する

2つのノードのシリアル・ポートをヌル・モデム・ケーブルで接続します。そして次のようにシリアル接続をテストします。

ha1(受信側)では次のようにタイプします。

cat < /dev/ttyS0

ha2(送信側)では次のようにタイプします。

echo "Serial Connection test" > /dev/ttyS0

受信側ノード(ha1)にテキストが現れるはずです。これが動作したら送受信を逆にし、再度テストします。


共有ファイル・システム用にNFSを設定する

先に書いた通り、テスト用の構成では、ノード間でのデータ共有用にNFSを使っています。

  • ノードnfsha.haw2.ibm.comはNFSサーバーとして使われます。
  • ファイルシステム /haは共有されます。

NFSを立ち上げて動作させるには次のようにします。

  1. nfshaノードにディレクトリー /haを作る。
  2. /etc/exportsファイルを編集する。このファイルには、共有ボリュームとそのボリュームがどのように共有されているかを表す、エントリーのリストが含まれています。リスト1は私の構成でのexportsファイルの中で、関係のある部分を示しています。
    リスト1. exportsファイル
    ...
    /ha 9.22.7.48(rw,no_root_squash)
    /ha 9.22.7.46(rw,no_root_squash)
    /ha 9.22.7.35(rw,no_root_squash)
    /ha 9.22.7.49(rw,no_root_squash)
    /ha 9.22.7.50(rw,no_root_squash)
    ...
  3. NFSサービスを起動する。既にNFSが実行している場合には/usr/sbin/exportfs -raコマンドを実行して、強制的に/etc/exportsファイルをnfsdに再度読み込ませます。
  4. ローカル・ファイルシステムと同じように、両方のHAノード(ha1とha2)の /etc/fstabファイルにファイル・システム /haを追加します。リスト2は、私の構成でのfstabファイルで関係のある部分を示しています。

    リスト2. fstabファイル
    ...
    nfsha.haw2.ibm.com:/ha    /ha    nfs    noauto,rw,hard 0 0
    ...

    これから先では、このファイルシステムをマウントするためにheartbeatを設定します。

  5. リスト3に示すコマンドを使用して、このファイルシステムにあるコード・サンプルhahbcode.tar.gzを展開します。(最初に下記のDownloadセクションからコード・サンプルをダウンロードしてください。)
    リスト3. サンプル・コードを展開する
    cd /ha
    tar  xvfz  hahbcode.tar.gz

heartbeatをダウンロードし、インストールする

参考文献にあるリンクを使ってheartbeatをダウンロードし、リスト4にあるコマンドを(この順番で)入力して、ha1とha2の両方にインストールします。

リスト4. heartbeatをインストールするためのコマンド
rpm -ivh heartbeat-pils-1.2.2-8.rh.el.3.0.i386.rpm
rpm -ivh heartbeat-stonith-1.2.2-8.rh.el.3.0.i386.rpm
rpm -ivh heartbeat-1.2.2-8.rh.el.3.0.i386.rpm

heartbeatを設定する

heartbeatが動作するようにするには、authkeysとha.cfそれにharesourcesという、3つのファイルを設定する必要があります。ここではこの実装のために使った専用の構成を示しますが、さらに情報が必要な場合には、heartbeatのWebサイトでドキュメンテーションを読んでください(参考文献)。

1. /etc/ha.d/authkeysを設定する

このファイルはクラスターに対する認証キーを決定します。認証キーは両方のノードで同じである必要があります。認証スキームとしては、crc、md5またはsha1の3つの中から選ぶことができます。heartbeatが、例えば例に挙げたクロスオーバー・ケーブルのようにセキュアなネットワーク上で実行する場合には普通、crcを使うでしょう。リソースの面から言うと、これは最も安価な方法です。ネットワークがセキュアではないものの皆さんがあまり偏執的ではないか、またはCPUリソースを最小限にすることが心配なのであれば、md5を使うべきでしょう。そして最後に、CPUリソースを気にせず、最高の認証を望むのであれば、一番堅牢なsha1を使うべきでしょう。

このファイルのフォーマットは以下の通りです。

auth <number>
<number> <authmethod> [<authkey>]

このテスト構成では、crcスキームを使用しました。リスト5は/etc/ha.d/authkeysファイルを示しています。そのパーミッションが、例えば600など、安全なことを確認します。

リスト5. authkeysファイル
auth 2
2 crc

2. /etc/ha.d/ha.cfを設定する

このファイルは、インストール後に生成される /etc/ha.dディレクトリーに置かれます。このファイルは、どのようなメディア・パスを使うのか、それをどのように設定するかをheartbeatに対して伝えます。またクラスター中のノードや、システムが立ち上がっているかどうかを調べるためにheartbeatが使うインターフェースも定義します。リスト6は、私の構成での /etc/ha.d/ha.cfファイルで関係のある部分を示します。

リスト6. ha.cfファイル
...
#	File to write debug messages to
debugfile /var/log/ha-debug
#
#
# 	File to write other messages to
#
logfile	/var/log/ha-log
#
#
#	Facility to use for syslog()/logger
#
logfacility	local0
#
#
#	keepalive: how long between heartbeats?
#
keepalive 2
#
#	deadtime: how long-to-declare-host-dead?
#
deadtime 60
#
#	warntime: how long before issuing "late heartbeat" warning?
#
warntime 10
#
#
#	Very first dead time (initdead)
#
initdead 120
#
...
#	Baud rate for serial ports...
#
baud	19200
#
#	serial	serialportname ...
serial	/dev/ttyS0
#	auto_failback:  determines whether a resource will
#	automatically fail back to its "primary" node, or remain
#	on whatever node is serving it until that node fails, or
#	an administrator intervenes.
#
auto_failback on
#
...
#
#	Tell what machines are in the cluster
#	node	nodename ...	-- must match uname -n
node	ha1.haw2.ibm.com
node	ha2.haw2.ibm.com
#
#	Less common options...
#
#	Treats 10.10.10.254 as a pseudo-cluster-member
#	Used together with ipfail below...
#
ping 9.22.7.1
#	Processes started and stopped with heartbeat.  Restarted unless
#		they exit with rc=100
#
respawn hacluster /usr/lib/heartbeat/ipfail
...

3. /etc/ha.d/haresourcesを設定する

このファイルは、heartbeatが管理するリソースを記述します。このリソースは基本的に、/etc/rc.d/init.dでリソースを起動/停止するために使われるものとよく似た、単なる開始/停止スクリプトです。heartbeatはスクリプトを探して /etc/rc.d/init.dと/etc/ha.d/resource.dの中を見ることに注意してください。スクリプト・ファイルhttpdはheartbeatに付属してきます。リスト7は私の /etc/ha.d/haresourcesファイルを示します。

リスト7. haresourcesファイル
ha1.haw2.ibm.com 9.22.7.46 Filesystem::nfsha.haw2.ibm.com:/ha::/ha::nfs::rw,hard httpd

このファイルは両方のノードで同じである必要があります。

この行は、起動に際して次のようにするように言っています。

  • ha1をIP 9.22.7.46として動作させる
  • NFS共有ファイルシステム /haをマウントする
  • Apache Webサーバーを起動する

このファイルには、今後の記事の中でさらにリソースを追加します。heartbeatはシャットダウンに際しては下記を行います。

  • Apacheサーバーを停止する
  • 共有ファイルシステムをアンマウントする
  • IPを返上する

これはコマンドuname -nがha1.haw2.ibm.comを表示すると想定しています。皆さんのものはha1を生成するかもしれません。その場合はそれを使うようにします。


HA用にApache HTTPサーバーを設定する

このステップではApache Webサーバーの設定に対して少し変更を加え、共有システムから、またha1とha2という2台のマシンにローカルなファイルシステムから、ファイルをサービスできるようにします。index.htmlファイル(コード・サンプルに含まれています)は共有ディスクからサービスされ、またhostname.htmlファイルは、ha1とha2それぞれのマシンのローカル・ファイルシステムからサービスされます。Apache WebサーバーでHAを実装するには次のようにします。

  1. Rootとしてログインする
  2. 共有ディスク(/ha)に次のディレクトリーを作る /ha/www
    /ha/www/html
  3. 下記のコマンドを使い、ノードha1で、適当なパーミッションを共有ディレクトリーに設定する chmod 775 /ha/www
    chmod 775 /ha/www/html
  4. プライマリー・マシンとバックアップ・マシンの両方で、Apache Webサーバーのhtmlディレクトリーをリネームする mv /var/www/html /var/www/htmllocal
  5. 次のコマンドを使い、両方のマシンで共有ディレクトリーにシンボリック・リンクを作る ln -s /ha/www/html /var/www/html
  6. index.htmlファイルをノードha1の/ha/www/htmlディレクトリーにコピーする cp /ha/hahbcode/www/index.html /var/www/html

    皆さんの場合はこのファイルのクラスター名を変更する必要があります

  7. hostname.htmlファイルを両方のマシンの/ha/www/htmllocalディレクトリーにコピーする cp /ha/hahbcode/www/hostname.html /var/www/html

    このファイルのクラスター名とノード名を変更します

  8. 両方のマシンのファイルhostname.htmlにシンボリック・リンクを作る ln -s /var/www/htmllocal/hostname.html /ha/www/html/hostname.html

これでHA実装をテストできるようになります。


Apache HTTPサーバーでHAをテストする

Webサーバーで高可用性をテストするには次のようにします。

  1. 次のコマンドを使い、最初にプライマリー・ノードで、次にバックアップ・ノードで、heartbeatサービスを起動する /etc/rc.d/init.d/heartbeat start

    もしうまく動作しない場合には、/var/log/messagesを見て原因を特定し、修正します。heartbeatがうまく起動すれば、ha.cfファイルで設定したIPアドレスを持つ、新しいネットワーク・インターフェースが見えるはずです。heartbeatを起動したら、プライマリーのログ・ファイル(デフォルトは/var/log/ha-logです)をちょっと覗き、確実にIPテークオーバーを行ってからApache Webサーバーを起動していることを確認します。psコマンドを使い、Webサーバー・デーモンがプライマリー・ノードで実行していることを確認します。heartbeatは、バックアップ・ノードでは何のWebサーバー・プロセスも起動しません。これが起きるのはプライマリーが故障した後のみです。

  2. ブラウザーで次のURLを指定し、ha1ノードで2つのWebページが正しくサービスされていることを確認します(皆さんが別のホスト名を使っている場合にはURLも変わってきます)。 http://ha.haw2.ibm.com/index.html
    http://ha.haw2.ibm.com/hostname.html

    ここではプライマリー・ノードのアドレスではなく、上のURLのクラスター・アドレスを使っていることに注意してください。

    最初のURLに対して、ブラウザーは次のようなテキストを表示するはずです。

    Hello!!! I am being served from a High Availability Cluster ha.haw2.ibm.com

    2番目のURLに対しては次のように表示するはずです。

    Hello!!! I am being served from a node ha1.haw2.ibm.com in a High Availability Cluster ha.haw2.ibm.com
  3. 下記のコマンドを使い、単純にプライマリー・システムでheartbeatを停止させることで、フェールオーバーをシミュレートします。 /etc/rc.d/init.d/heartbeat stop

    1分間以内に、全てのWebサーバー・プロセスが2番目のマシンに現れるはずです。もし現れない場合には、/var/log/messagesを見て問題を特定し、修正します。

  4. ブラウザーで次のURLを指定し、ha2ノードで2つのWebページが正しくサービスされていることを確認します。 http://ha.haw2.ibm.com/index.html
    http://ha.haw2.ibm.com/hostname.html

    最初のURLに対して、ブラウザーは次のようなテキストを表示するはずです。

    Hello!!! I am being served from a High Availability Cluster ha.haw2.ibm.com

    2番目のURLに対しては次のように表示するはずです。

    Hello!!! I am being served from a node ha2.haw2.ibm.com in a High Availability Cluster ha.haw2.ibm.com

    このページをサービスしているのが、今度はha2であることに注意してください。

  5. プライマリーでheartbeat・サービスを再起動します。これによって2番目のマシンでのApacheサーバー・プロセスは停止され、プライマリーで開始させるはずです。プライマリーはまた、クラスターIPをテークオーバーするはずです。

このようにWebページを共有ディスクに置くことによって、プライマリー・マシンが故障した場合には2番目のマシンが、そのWebページをクライアントに対してサービスできます。このフェールオーバーはウェブページをアクセスするクライアントには見えません。この手法は、CGIスクリプトをサービスする場合にも応用できます。


まとめ

今回は、安価なハードウェアと手軽に入手できるソフトウェアを使って高可用性Webサーバーを構成する手法を紹介しましたが、皆さんにもこれを試して欲しいと思います。次の記事では、WebSphere MQを使い、高可用性メッセージング・キュー・マネージャーをどのように構築するかを見ることにします。


ダウンロード

内容ファイル名サイズ
この記事用のサンプル・コード・パッケージhahbcode.tar.gz25KB

参考文献

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Linux
ArticleID=228543
ArticleTitle=Linuxでの高可用性ミドルウェア、第1回: HeartbeatとApache Webサーバー
publish-date=10122004