オンデマンド・コンピューティングの成功にとって、システムの稼働時間を最大に維持することが次第に重要になってきています。残念ながら、高可用性(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. サンプルのコード・パッケージに含まれているもの
| ディレクトリー | 内容 |
|---|---|
| heartbeat | heartbeat用のサンプル・コンフィギュレーション・ファイル |
| www | Apache Web ServerのHAをテストするためのHTMLファイル |
| mq | WebSphere MQ HA用のスクリプトとコード
|
| loadl | LinuxサービスとしてのLoadLevelerを起動停止するためのloadlファイル |
| was | WebSphere Application Server HA用のスクリプトとコード
|
| db2 | データベースの可用性チェックや表の生成、表への行の挿入、表の行の選択などを行うスクリプト |
高可用性は、システムやコンポーネント、アプリケーションなどのトラブルの際に、重要なサービスを素早く回復するためのシステム管理戦略です。高可用性の目標は、耐障害性よりもむしろ、サービスの中断を最小限にとどめることです。重要なビジネス・オペレーションを行っているシステムの故障に対して最も一般的なソリューションは、もう1台のシステムを待機させておき、故障したシステムの作業負荷は待機しているシステムで担わせるようにするものです。
「クラスター」という用語は、コンピューター業界では異なった意味を持っています。この記事では特に断らない限り、クラスターとはハートビート・クラスターを意味します。ハートビート・クラスターは、クラスター内部で実行していて高可用性サービスを提供するために協力しているノードとリソース(ディスクやネットワークなど)の集合です。もし使われているマシンの1台が故障すると、ビジネス・オペレーションを維持するために必要なリソースは、クラスター内で使用可能な別のマシンに移されます。
主なクラスター構成には次のような2つがあります。
- スタンバイ構成: 最も基本的なクラスター構成で、一つのノードが実際の動作を行い、もう一方のノードはスタンバイとしてのみ動作します。スタンバイ・ノードは実際の動作は行わず、アイドル状態と言われます。この構成はコールド・スタンバイ(cold standby)と呼ばれることもあります。この構成ではハードウェアに高度の冗長性が必要となります。このシリーズの記事では、コールド・スタンバイ構成に焦点を当てることにします。
- テークオーバー構成(Takeover configuration): より高度な構成で、全てのノードが何らかの動作を行います。一つのノードが故障した場合には、重要な動作は引き継がれます。一方的テークオーバー(one-sided takeover)構成の場合には、付加的で、重要でなく、移動可能ではない一部の動作をスタンバイ・ノードが実行します。相互テークオーバー(mutual takeover)構成の場合には、全てのノードが高可用(移動可能)な動作を行います。このシリーズの記事では、テークオーバー構成は取り上げません。
HAクラスターをセットアップするためには、幾つかの重要項目に関して計画を立てる必要があります。
- データを保存するために使用するディスクは、クラスターを構成するサーバーに対して、共有ではない独立の接続(シリアル・ケーブル)またはLANで接続されている必要がある。
- 故障したリソースを自動検出する方法が必要である。これはハートビート・モニターと呼ばれるソフトウェア・コンポーネントによって行われる。
- 故障が起きた場合には、生き残っている1台以上のクラスター・メンバーに対して、リソース所有権を自動転送する必要がある。
現在入手できるようなソフトウェアの大部分は、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クラスター構成
私はテスト用の構成として、図2に示すようにNFSを共有ディスク機構として使います。ただし、特に実稼働環境では、図1に示すオプションを使うようにお勧めします。2つのシステムのシリアル・ポート間を接続したヌル・モデム・ケーブルは、2つのノード間でのheartbeatを伝送するために使われます。
図2. NFSを共有ファイル・システムに使ったheartbeatクラスター構成
表2は私が両ノードで使った構成を示しています。皆さんの場合には、DNSあるいは両ノードの/etc/hostsファイルで、ホスト名とIPアドレスが分かっている必要があります。
表2. テスト用のクラスター構成
| 役割 | ホスト名 | IP アドレス |
|---|---|---|
| 共有(クラスター)IP | ha.haw2.ibm.com | 9.22.7.46 |
| ノード1(マスター) | ha1.haw2.ibm.com | 9.22.7.48 |
| ノード2(バックアップ) | ha2.haw2.ibm.com | 9.22.7.49 |
| ノード3(図では示していない) | ha3.haw2.ibm.com | 9.23.7.50 |
| NFSサーバー | hanfs.haw2.ibm.com | 9.2.14.175 |
2つのノードのシリアル・ポートをヌル・モデム・ケーブルで接続します。そして次のようにシリアル接続をテストします。
ha1(受信側)では次のようにタイプします。
cat < /dev/ttyS0 |
ha2(送信側)では次のようにタイプします。
echo "Serial Connection test" > /dev/ttyS0 |
受信側ノード(ha1)にテキストが現れるはずです。これが動作したら送受信を逆にし、再度テストします。
先に書いた通り、テスト用の構成では、ノード間でのデータ共有用にNFSを使っています。
- ノードnfsha.haw2.ibm.comはNFSサーバーとして使われます。
- ファイルシステム /haは共有されます。
NFSを立ち上げて動作させるには次のようにします。
- nfshaノードにディレクトリー /haを作る。
- /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) ...
- NFSサービスを起動する。既にNFSが実行している場合には
/usr/sbin/exportfs -raコマンドを実行して、強制的に/etc/exportsファイルをnfsdに再度読み込ませます。 - ローカル・ファイルシステムと同じように、両方のHAノード(ha1とha2)の /etc/fstabファイルにファイル・システム /haを追加します。リスト2は、私の構成でのfstabファイルで関係のある部分を示しています。
リスト2. fstabファイル... nfsha.haw2.ibm.com:/ha /ha nfs noauto,rw,hard 0 0 ...
これから先では、このファイルシステムをマウントするためにheartbeatを設定します。
- リスト3に示すコマンドを使用して、このファイルシステムにあるコード・サンプルhahbcode.tar.gzを展開します。(最初に下記のDownloadセクションからコード・サンプルをダウンロードしてください。)
リスト3. サンプル・コードを展開するcd /ha tar xvfz hahbcode.tar.gz
参考文献にあるリンクを使って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が動作するようにするには、authkeysとha.cfそれにharesourcesという、3つのファイルを設定する必要があります。ここではこの実装のために使った専用の構成を示しますが、さらに情報が必要な場合には、heartbeatのWebサイトでドキュメンテーションを読んでください(参考文献)。
このファイルはクラスターに対する認証キーを決定します。認証キーは両方のノードで同じである必要があります。認証スキームとしては、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
|
このファイルは、インストール後に生成される /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
... |
このファイルは、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を生成するかもしれません。その場合はそれを使うようにします。
このステップではApache Webサーバーの設定に対して少し変更を加え、共有システムから、またha1とha2という2台のマシンにローカルなファイルシステムから、ファイルをサービスできるようにします。index.htmlファイル(コード・サンプルに含まれています)は共有ディスクからサービスされ、またhostname.htmlファイルは、ha1とha2それぞれのマシンのローカル・ファイルシステムからサービスされます。Apache WebサーバーでHAを実装するには次のようにします。
- Rootとしてログインする
- 共有ディスク(/ha)に次のディレクトリーを作る /ha/www
/ha/www/html
- 下記のコマンドを使い、ノードha1で、適当なパーミッションを共有ディレクトリーに設定する
chmod 775 /ha/www
chmod 775 /ha/www/html
- プライマリー・マシンとバックアップ・マシンの両方で、Apache Webサーバーのhtmlディレクトリーをリネームする
mv /var/www/html /var/www/htmllocal
- 次のコマンドを使い、両方のマシンで共有ディレクトリーにシンボリック・リンクを作る
ln -s /ha/www/html /var/www/html
- index.htmlファイルをノードha1の/ha/www/htmlディレクトリーにコピーする
cp /ha/hahbcode/www/index.html /var/www/html皆さんの場合はこのファイルのクラスター名を変更する必要があります
- hostname.htmlファイルを両方のマシンの/ha/www/htmllocalディレクトリーにコピーする
cp /ha/hahbcode/www/hostname.html /var/www/htmlこのファイルのクラスター名とノード名を変更します
- 両方のマシンのファイルhostname.htmlにシンボリック・リンクを作る
ln -s /var/www/htmllocal/hostname.html /ha/www/html/hostname.html
これでHA実装をテストできるようになります。
Webサーバーで高可用性をテストするには次のようにします。
- 次のコマンドを使い、最初にプライマリー・ノードで、次にバックアップ・ノードで、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サーバー・プロセスも起動しません。これが起きるのはプライマリーが故障した後のみです。
- ブラウザーで次の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.com2番目のURLに対しては次のように表示するはずです。
Hello!!! I am being served from a node ha1.haw2.ibm.com in a High Availability Cluster ha.haw2.ibm.com
- 下記のコマンドを使い、単純にプライマリー・システムでheartbeatを停止させることで、フェールオーバーをシミュレートします。
/etc/rc.d/init.d/heartbeat stop1分間以内に、全てのWebサーバー・プロセスが2番目のマシンに現れるはずです。もし現れない場合には、/var/log/messagesを見て問題を特定し、修正します。
- ブラウザーで次の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.com2番目のURLに対しては次のように表示するはずです。
Hello!!! I am being served from a node ha2.haw2.ibm.com in a High Availability Cluster ha.haw2.ibm.comこのページをサービスしているのが、今度はha2であることに注意してください。
- プライマリーでheartbeat・サービスを再起動します。これによって2番目のマシンでのApacheサーバー・プロセスは停止され、プライマリーで開始させるはずです。プライマリーはまた、クラスターIPをテークオーバーするはずです。
このようにWebページを共有ディスクに置くことによって、プライマリー・マシンが故障した場合には2番目のマシンが、そのWebページをクライアントに対してサービスできます。このフェールオーバーはウェブページをアクセスするクライアントには見えません。この手法は、CGIスクリプトをサービスする場合にも応用できます。
今回は、安価なハードウェアと手軽に入手できるソフトウェアを使って高可用性Webサーバーを構成する手法を紹介しましたが、皆さんにもこれを試して欲しいと思います。次の記事では、WebSphere MQを使い、高可用性メッセージング・キュー・マネージャーをどのように構築するかを見ることにします。
| 内容 | ファイル名 | サイズ | ダウンロード形式 |
|---|---|---|---|
| この記事用のサンプル・コード・パッケージ | hahbcode.tar.gz | 25KB | FTP |
-
High-Availability Linux project Web siteにはheartbeat success storiesを含めて、さらに情報がありますので、よく見てください。
- このシリーズの記事で必要なソフトウェアの大部分は下記からダウンロードすることができます(全てのダウンロードが無料ではありませんので、注意してください)。
- 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
- WebSphere Base Edition 5.1.1 for Linux with Cumulative Fix 1
- DB2 Universal Database Enterprise Server Edition V8.1 for Linux
- HA NFSサーバーをどのように構築するかを、André Bonhôteがヨーロッパ版Linux Magazineの2003年8月号の記事Inner Pulse(PDF)で説明しています。
- この記事で触れた、他の高可用性ソリューションについても調べてみてください。
- High Availability Cluster Multiprocessing (HACMP)
- IBM Tivoli System Automation for Multiplatforms
- SteelEye LifeKeeper
- Veritas Cluster Server
- 高可用性機能を提供するDB2 Universal Databaseについて、An Overview of High Availability and Disaster Recovery for DB2 UDB(developerWorks, 2003年4月)で学んでください。
- 可用性についての詳細な議論と、エンタープライズのミドルウェア環境をいかに計画、維持管理するかに関して、Planning for Availability in the Enterpriseを読んでください(developerWorks, 2003年12月)。
- developerWorksのLinuxゾーンにはLinux開発者向けの資料が他にも用意されていますので、ご覧ください。
- Linux上で実行する、IBMミドルウェア製品の無料試用版をダウンロードしてください。developerWorksのSpeed-start your Linux appセクションから、WebSphere® Studio Application Developer, WebSphere Application Server, DB2® Universal Database, Tivoli® Access Manager, そしてTivoli Directory Serverが入手できます。またハウ・ツー記事や技術サポート情報もご利用ください。
-
developerWorks blogsに参加して、developerWorksコミュニティーに加わってください。
- Developer BookstoreのLinuxセクションではLinux関連の書籍が値引きして購入できますのでご利用ください。
Hidayatullah H. ShaikhはIBM T.J. Watson Research Centerのオンデマンド・アーキテクチャーと開発チームのシニア・ソフトウェア技術者です。関心領域は広く、ビジネス・プロセスのモデル化と統合、サービス指向アーキテクチャー、グリッド・コンピューティング、eコマース、エンタープライズJava、データベース管理システム、それに高可用性クラスターに渡っています。連絡先はhshaikh@us.ibm.comです。