GlassFishのアップデートセンター
さて、GlassFishには本当に色々な機能がありますが、
アップデートセンターの機能がある事はご存知でしょうか？
今日は、GlassFishのアップデートセンターについて紹介します。
【アップデートセンターの実行方法】
GlassFishのアップデートセンターは下記のように
インストールディレクトリ配下に存在する、
[ $APP_INSTALL/updatecenter/bin/updatetool ]を実行します。
appserver1 > /sun/SUNWappserver91/updatecenter/bin/updatetool ; |
すると下記のような画面が表示されます。
タブの[ Available Software ]には、アップデート可能なソフトの一覧が
表示されます。2007年11月05日時点で下記のソフトがアップデート可能に
なっています。
● Web Technologies
ー JMaki 1.0
ー Jersey 0.2.1(RESTful Web Services)
ー Phobos 0.5.11
● JRuby on GlassFish 1.0
● Social Software
ー Weblog Server for GlassFish 1.0 Early Access 1
● Composite Applications
ー Open ESB Blueprints 1.0
ー Open ESB V2 Preview 3
● Identity
ー Access Manager 7.1 Patch 1 EA
ー Access Manager Blueprints 1.0
● Java EE 5 API Documentation
● Java EE 5 Samples
● Java EE Blueprints
● Portal
ー Portlet Container
ー Portlet Container Blueprints
ー Web Services for Remote Portlets
● Java EE 5 Tutorial
さて、ここで、GlassFishのアップデートセンターの生い立ちについて説明します。
実は元々、NetBeansのアップデートセンターを元に作られました。
そして、これは新規コンポーネントの追加や、既存コンポーネントの更新を自動的にできるツールとなっています。
また、開発者や管理者の方は新規コンポーネントや既存コンポーネントの利用が
可能になった時に、利用可能になった通知を受け取る設定も可能になっています。
[ Notify me when new updates or software are available ]
さらには、GlassFishの核となるコンポーネントに対するパッチ等を取得する事も可能です。
【開発者向け】
開発者の方たちはGlassFishのアップデートセンターに対する
自動チェック機能を有効にする事で最新のモジュールを即座に利用
する事が可能です。
【管理者向け】
取得するコンポーネントやパッチは、GlassFishのオリジナルサイトからのダウンロード
しなければならないわけではありません。
自分独自のアップデートセンターサーバを作成し、必要なファイルのみを配布する事も可能です。
これができる事により、例えば社内に多くのアプリケーションサーバを
抱えるような環境では、複数のアプリケーションサーバに対してシステムの
更新が非常に容易になります。（例：テスト用のアプリケーションサーバ１台に
更新モジュールを入れ様々なテストを行った後、一斉に他の残りのサーバに
対する更新も可能になります。）
独自サーバを作成する為にはサーバ側で、特定のディレクトリ構造を作成する必要が
ありますが詳細は下記のURLを御参照ください。（別途サーバの作り方を紹介します。）
GlassFishアップデートセンターの詳細
最後に、アップデートセンター機能の今後についてですが、
将来的には下記のURLに記載されていますが、アップデートセンターは
単にGlassFishのアップデートセンターとしてだけではなく、他の
ミドルウェアのアップデートも可能になるようです。
つまりアップデートセンターは将来的により汎用的に使える事になるんですね！！
アップデートセンター2.0
Update Center shipped with GlassFish and other middle-ware should offer uniform user experience. For
example, using the update center shipped with GlassFish, it should be possible to install other middle-ware
softwares that are part of SWI (Software Infrastructure) and vice-versa.
背景が透明なGlassFishの画像(GlassFish Image with transparent background)
仕事がらプレゼン資料を作成したりするのですが、
GlassFishの画像って、今までのは全て背景が白色になっていて、
何故か、背景が透明な物がありませんでした。
そこで、GIMPを使ってちょこっと背景を透明の
GlassFish画像を作ってみました。
ここから取得(Download Here)
 |
|
これ作るとなかなか便利で、下の技術情報アーカイブの
所のGlassFishの画像のように透過画像なので背景に
なじみます。
おかげでこんなプレゼンのタイトル画面もできました。
*************************************
I made a GlassFish image file with transparent background.
Because I tried to find the GlassFish Image with transparent background .
However , I could not find it . So I made it by using GIMP .
If I used this file on presentation tile , it became cool (a little bit ).
GlassFish マルチリンガル版メディア情報
さて、先日リリースされたマルチリンガル版ですが、
各種メディアでもGlassFish/Sun Java System Application Server 9.1マルチリンガル版の
リリースに関する情報が掲載されていますので紹介します。
● Web BCN : 「サン、オープンソースのアプリケーションサーバーの無償提供を開始」
● キーマンズネット :
「サン、アプリケーションサーバのマルチリンガル版を無償提供」
● ITmediaエンタープライズ :
「サン、アプリケーションサーバのマルチリンガル版を発表」
● マイコミジャーナル :
「”Sun Java System Application Server 9.1マルチリンガル版”が無償提供開始」
● ITpro データベース／ミドルウエア 日経コンピュータ : 「サン、Java EE 5対応のAPサーバーを無償提供」
● Enterprise Watch :
「サン、OSSベースアプリケーションサーバーのマルチリンガル版」
● ZDNet Japan
: 「サン、「JavaEE 5」の環境を多言語化」
● Open Tech Press : 「サン、アプリケーションサーバ「Sun Java System Application Server 9.1マルチリンガル版」を提供開始」
● gihyo.jp : 「Java Expert＋gihyo.jp Presents Sun Microsystems, Inc.スペシャルインタビュー集 エンタープライズJavaの鍵を握る GlassFish最新動向」
PS.
あるイベントで、御客様からHP-UXでGlassFishの導入を検討したい旨
質問を受けたのですが、その際是非御検討くださいと回答したのですが、
実は、HP-UX版はリリースされておりません。
大変申し訳ありませんでした。
GlassFish/Sun Java System Application Server 9.1の動作環境は下記となります。
● Solaris 10 および9オペレーティング･システム（SPARC）
● Solaris 10 および9オペレーティング･システム（x64/x86）
● Microsoft Windows XP®、2003、2000 Advanced Server、Vista（Business Edition）
● Red Hat Enterprise Linux 3および4
上記は、Sun Java System Appliaction Server 9.1のライセンスを
御購入頂くとSun からの正式サポートを受ける事が可能になります。
無償で御使用頂く場合には、GlassFishコミュニティでのサポートとなります。
ちなみに、Mac OS用にはGlassFishで提供されており、Sun Java System Application Server
としては提供されておりません。そして、GlassFishを使用する場合コミュニティからの
サポートを受ける事ができます。
最後に、次期アップデートリリースではAIX版もリリースされる予定ですので、
AIXでの導入を御検討の方は今暫く御待ち頂ければと思います。
SJS Application Server9.1日本語版リリース
ついに、待ちに待ったGlassFish v2 , Sun Java System Application Server 9.1の
日本語版が正式にリリースされたようです。
是非、この新しくなったGlassFish & SJS Application Server 9.1を試してください。
http://jp.sun.com/products/software/javasystem/applicationserver/appsrvr9_1.html
http://sdc.sun.co.jp/java/javaee/downloads/index.html
https://glassfish.dev.java.net/ja
PS.
来週開催されるSun TechDaysでGlassFishのブースを担当する事になりました。
ここ最近その準備で追われているのですが、ちょっと楽しいデモもできました。
是非、GlassFishのブースにも御越し下さい。
そして生のGlassFishも是非見てみてください！！
Sun Java System Web Proxy Server 4.0.6 リリース
先日、Sun Java System Web Proxy Server 4.0.6がリリースされました。
SJS Web Proxy Server 4.0.6ダウンロード
本バージョンより、SunのHardware Crypto Acceleratorである、Crypto Accelerator 6000が
正式サポートされるようになっています。
Enhanced Hardware Accelerator Encryption Support
Proxy Server 4.0.6 provides hardware accelerator support for SunTM Crypto Accelerator 6000,
a cryptographic accelerator board that enhances the performance of SSL on the Proxy Server.
Sun Crypto Acceleratorの御紹介
Sun Crypto Accelerator 6000 PCI-E アダプタは、Sun Crypto Accelerator 1000/4000 同様 SSLやIPsecで
使用される暗号アルゴリズムと、FIPS 140-2 level 3を含むセキュリティ機能とGigabit Ethernetインタフェースの
ネットワーク機能を統合した、Low profile、ハーフレングスの8レーン PCI-Express対応のアダプタです。
Sun Crypto Accelerator 6000 PCI-E アダプタは、 エンタープライズレベルのセキュリティ機能と
パフォーマンス同時に、エントリー価格にて実現可能です。
ここで、
「FIPS 140-2 Level 3」とはFIPS（米連邦情報処理規格）が規定する最も高いレベルのセキュリティ規格を意味し、
FIPS（米連邦情報処理規格）により、暗号セキュリティソリューションに求められるセキュリティ要件を規定し、
NIST（米国立標準技術研究所）がその認定を行っています。
「FIPS 140-2」をベースとした暗号モジュールは、今後日本政府の調達基準としての検討されています。
平成16 年度不正アクセス行為等対策業務
（情報セキュリティ水準向上に向けた電子署名・認証基盤の現状に関する調査研究）
電子署名法の在り方と電子文書長期保管に関する現状調査報告書
(以下 引用)
*******************************************************************************
1) 漏洩、盗難
認証局の私有鍵が、管理不十分や故意などの理由により漏洩した場合、第三者によって立
ち上げられた偽の認証局が出現する恐れがある。この場合の被害は甚大で、もはや認証局と
の信頼関係は成立しない。
漏洩は検知することが困難なため、漏洩しないための予防策が重要となる。私有鍵の漏洩
を防止するためには、私有鍵を厳格に管理し、バックアップも同様に厳格に管理しなければ
ならない。鍵の管理に、耐タンパー性のある専用の暗号装置、例えば、FIPS140(詳細後述)レ
ベル3 以上の認定を受けたHSM(Hardware Security Module)を使うことなどが考えられる。
また、複数人の権限者が揃わなければ実行できないような仕組みを取り入れることも、お互
いの牽制が働くため、内部の者の不正行為に対して有効である。
*******************************************************************************
Sun Tech Days(11/06-11/08)の受付開始
どうやら、Sun Tech Days 2007の参加申込みの
受付開始が開始したようですね！！
Sun Tech Days 2007
NetBeans Day では下記のセッション
NetBeans Welcome
New & Cool
Using NetBeans for your Existing Projects
Technologies for Creating Web 2.0 Rich Internet Applications
Ruby on Rails in the Enterprise
Beans Binding & the Swing Application Framework
Tools for Simplifying SOA
Java 関連では下記のセッション
Java EE 6 and GlassFish
Java SE 6 Top 10 features, Java SE 7 and OpenJDK
Next Generation Web and JavaServer Faces
Consumer JRE: Java on Every Desktop OR Java Performance Myths
Project Metro and REST: Web Services Everywhere
Java ME: Extreme GUI Makeover for Mobile Phones
SOA using OpenESB and JCAP
Java Scripting: JavaFX Script and JRuby
が予定されています。
どうぞ奮って、御応募ください。
ちなみに、Java EE 6 and GlassFishのセッションでは、
US Sunより、川口さんが帰国されて発表される予定です。
その他にも多くのセッションが予定されてますので、
是非御楽しみにして頂ければと思います。
Project Shoalの話も聞けるかな？
SJS Application Server 9.1 Release in US
さて、9/17（日本では同日深夜）にGlassFish v2と
Sun Java System Application Server 9.1がUSで正式にリリースされました。
日本語版のリリース次期についてはまだ正式な日程を申し上げる事はできませんが、
来月あたりのリリースを予定しております。
製品についてですが、本バージョンより、
Platform Edition(PE) , Standard Edition(SE),
Enterprise Edition(EE)という製品種別はなくなり、
Sun Java System Application Server 9.1もしくは、
Sun Java System Application Server 9.1 with HADBの
何れかを選択する事ができるようになっています。
英語版であれば、既に下記のURLよりダウンロード可能になっていますので、
日本語版が出る前に少し触ってみたいという方がいらっしゃいましたら、
どうぞ下記より入手して試してみてください。
Sun Java System Application Server 9.1ダウンロード
Sun Java System Application Server 9.1 with HADBダウンロード
御参考：アーカイブ(インストール／設定手順等)
HADBの両ノード障害発生時の復旧方法
HADBの両ノード障害発生時の復旧方法
前回、HADBノードの再起動と状態確認方法で説明しましたが、
HADBを構成するノードの再起動が必要な場合は、片ノードづつ
リブートをして頂くか、“hadbm stop HADB_NAME”を実行した後、
再起移動してください。
仮に、HADBを構成するノードがお互いに通信できなくなった場合、
もしくは、両ノードが同時に停止してしまったような場合
データベースの整合性が取れなくなりHADBサービスを提供できなくなります。
そのような場合、データベースを再構築しなくてはなりません。
今回は、両ノードが同時に停止してしまった場合、もしくはステータスが
不正な状態になった場合のHADBの復旧方法について説明します。
復旧手順は下記の２ステップを実行してください。
手順１: HADBを初期化(“hadbm clear”)する。
手順２: “asadmin configure-ha-cluster”を実行する。
両ノード障害の発生（疑似）
DBの不整合が発生する状態を作成する為、HADBが稼働している状態で、
両ノードを同時にリブートして下さい。
appserver1 > sync appserver1 > reboot appserver2 > sync appserver2 > reboot |
不正な状態に陥っている事の確認
次に、両ノードをリブートした後、それぞれのシステム上でHADBの
管理エージェント(ma)を起動して下さい。
その後、“hadbm status HADB_NAME”を実行して見ましょう。
上記で、１台づつマシンをリブートした時と比べ、いつまで経っても
状態がHAFaultTolerant,FaultTolerantに変わりません。
さらには、状態は“NonOperational”として表示されています。
この状態は、HADBとしてサービスを提供できていない状態を表しています。
appserver1 > /sun/SUNWappserver91/hadb/4/bin/ma-initd start appserver2 > /sun/SUNWappserver91/hadb/4/bin/ma-initd start appserver1 > /sun/SUNWappserver91/hadb/4/bin/hadbm status app-cluster1 Please enter the password for the admin system user:*********** 2007-09-12 14:38:44.813 INFO hadbm status –nodes=false –quiet=false –version=false –yes=false –force=false –echo=false app-cluster1 Database Status app-cluster1 NonOperational |
HADBデバイスのクリーンアップ
上記のように、”NonOperational”の状態から”HAFaultTolerant,FaultTolerant”の
状態に戻すためには、下記の手順に従い修復を行います。
HADBの修復を行うために、“hadbm clear HADB_NAME”を実行して下さい。
“hadbm clear”を実行した後、“hadbm status HADB_NAME”を実行すると
HADBの状態が”NonOperational”から“FaultTolerant”に変わる事を確認できます。
appserver1 > /sun/SUNWappserver91/hadb/4/bin/hadbm clear app-cluster1 Please enter the password for the database system user:[***********] Please retype the password for database system user:[***********] WARNING: The –dbpassword option is deprecated since it is insecure. Using this option can compromise your password. Please use either the command prompt or the –dbpasswordfile option. Please enter the password for the admin system user:[***********] 2007-09-12 14:42:32.552 INFO hadbm clear –fast=false –quiet=false –version=false –yes=false –force=false –echo=false –dbpassword=****** app-cluster1 This command will clear database app-cluster1. Type “yes” or “y” to confirm this operation, anything else to cancel: y 2007-09-12 14:42:38.555 INFO Node app-cluster1:0 is currently starting at config version 3, stopping node in order to stop database 2007-09-12 14:43:19.240 INFO Initializing device /sun/SUNWappserver91/hadb/4.4.3-6/device/app-cluster1.nilog.0 for node app-cluster1:0 2007-09-12 14:43:19.244 INFO Initializing device /sun/SUNWappserver91/hadb/4.4.3-6/device/app-cluster1.relalg.0 for node app-cluster1:0 2007-09-12 14:43:19.247 INFO Initializing device /sun/SUNWappserver91/hadb/4.4.3-6/device/app-cluster1.noman.0 for node app-cluster1:0 2007-09-12 14:43:19.249 INFO Initializing device /sun/SUNWappserver91/hadb/4.4.3-6/device/app-cluster1.data-0.0 for node app-cluster1:0 2007-09-12 14:44:16.059 INFO Starting node app-cluster1:0 at level firststart, config version 5, in order to start database 2007-09-12 14:44:16.255 INFO n:0 NSUP INF 2007-09-12 14:44:16.248 p:685 Legal realtime priorities are 0 (lowest) to 59 (highest) set it to:29 Database app-cluster1 successfully cleared. appserver1 > /sun/SUNWappserver91/hadb/4/bin/hadbm status app-cluster1 Please enter the password for the admin system user: [***********] 2007-09-12 14:46:50.316 INFO hadbm status –nodes=false –quiet=false –version=false –yes=false –force=false –echo=false app-cluster1 Database Status app-cluster1 FaultTolerant appserver1 > |
上記でHADBでバイスのクリーンアップ行った後、HADBの状態が
“FaultTolerant”に変わりました。
そこで、HADBのサービスが上記で使用可能になったのではないかと
思われるかもしれません。
しかし、実際は上記を行っただけではApplication Serverから
HADBに対して接続できません。
理由は、“hadbm clear”を実行するとHADBのデバイスの初期化が
行われるため、Application Serverから接続する為に必要なテーブルや
スキーマ等、全て初期化されてしまうからです。
これを、clusqlコマンドを使用し確認しましょう。
hadbm clear実行直後のHADBのテーブル一覧
appserver1 > /sun/SUNWappserver91/hadb/4/bin/clusql localhost:15205 system+adminadmin SQL: select * from sysroot.alltables ;
HADB-I-11930: Selected 22 row(s) SQL: quit ; appserver1 > |
HADBが正常に動作している時のテーブル一覧
appserver1 > /sun/SUNWappserver91/hadb/4/bin/clusql localhost:15205 system+adminadmin SQL: select * from sysroot.alltables ;
HADB-I-11930: Selected 27 row(s) |
上記２つのテーブル一覧を御確認ください。
確認すると、「hadbm clear実行直後のHADBのテーブル一覧」には
下記の5つのテーブルが存在していない事が確認できます。
● sessionattribute
● singlesignon
● statefulsessionbean
● blobsessions
● sessionheader
また、“hadbm clear HADB_NAME”を実行した直後、Application Serverから
HADBに接続する際に使用するユーザ(admin)でHADBに接続しようとした際、
ユーザが存在していないため、下記のエラーが出力されます。
appserver1 > /sun/SUNWappserver91/hadb/4/bin/clusql localhost:15205 admin+adminadmin HADB-E-11601: Invalid user name or password |
asadmin configure-ha-clusterの実行
そこで、HADBデバイスの初期化（”hadbm clear”）の後で、
HADBのテーブル、スキーマそしてユーザを再度構築する為に、
asadmin configure-ha-clusterコマンドを実行して下さい。
appserver1 > asadmin configure-ha-cluster –devicesize 1024 –hosts appserver01,appserver02 –user admin app-cluster1 HADBMGMT008:The database, app-cluster1, already exists Command configure-ha-cluster executed successfully. appserver1 > |
上記、asadmin configure-ha-clusterコマンドを実行すると、
Appplication ServerからHADBのサービスを利用する為に必要な、
DBスキーマ、テーブル、ユーザ等が作成されます。
そこで、Application Serverから接続するユーザ(admin)で接続が可能となります。
clusqlでHADBに接続した後、作成されたテーブルの内容をそれぞれ確認してみましょう。
appserver1 > /sun/SUNWappserver91/hadb/4/bin/clusql localhost:15205 admin+adminadmin SQL: SELECT schemaname, tablename, tableid FROM sysroot.alltables ;
HADB-I-11930: Selected 5 row(s) SQL: show table sessionattribute ;
SQL: show table singlesignon;
SQL: show table blobsessions ;
SQL: show table sessionheader ;
SQL: show table statefulsessionbean ;
SQL: quit ; |
備考：
clusqlで接続する際に、(system , admin)というユーザで接続しています。
systemはHADBのシステム管理用に使用するユーザで、adminユーザは
Application Serverから接続する際に使用するユーザ名です。
Application Serverから接続する際に使用するユーザ名、パスワード、
接続するHADBのノード名、ノードのポート番号はApplication Serverの
管理画面よりHADBのコネクションプールの設定情報(下記御参照)より確認
する事もできます。
以上で、HADBの両ノード障害が発生した場合の復旧方法について説明しましたが、
如何でしょうか。
実は、私もHADBを触り始めた当初、両ノードの同時リブートを行ってはいけない事を
知らず、やってしまい驚いてしまった事があります。
仮に同様の事をしてしまった場合には、上記を試してください。
そして、それでも駄目な場合は、弊社サポートセンターに御問い合わせください。
HADBノードの再起動と状態確認方法
さて本日は、HADBノードの再起動と状態確認方法について説明します。
１. HADBを構成するノードの再起動方法について
前回の説明で、HADBを構成するノード(appserver01,appserver02)を
再起動する際は、両ノード同時にリブートする事は避けて頂きたいと説明しました。
そこで、今回まずは片ノードづつリブートした際における、HADBの状態変化について
説明したいと思います。
片ノードをリブートした際にHADBの状態としてどのように変化するか
下記より確認してみましょう。
正常時のステータス
appserver1 > /sun/SUNWappserver91/hadb/4/bin/hadbm status app-cluster1 Please enter the password for the admin system user:[***********] Database Status app-cluster1 FaultTolerant |
正常時に“hadbm status”を実行するとDatabaseのステータスとして、
“HAFaultTolerant”（スペアノード付き）もしくは”FaultTolerant”
（スペアノード無し）が表示されます。
この状態で、片ノードに何らかの障害が発生したとします。
するとHADBは単一ノードでしかサービスを提供していませんので、
ステータスは下記のように”Operational”にかわります。
片ノードで起動している時のステータス
appserver1 > /sun/SUNWappserver91/hadb/4/bin/hadbm status app-cluster1 Please enter the password for the admin system user:*********** Database Status app-cluster1 Operational |
実際に、ステータスが変更するかを実際に確認してみましょう。
手順；
1. 初めに片ノード(appserver02)をリブートします。
2. リブートが完了した後、appserver02にログインします。
3. HADBの管理エージェントプロセス(ma)を起動します。
4. 状態の変更を確認します。
appserver2 > sync appserver2 > reboot |
上記の状態で、起動しているノード(appserver01)で
HADBのステータスを確認してみて下さい。
すると下記のようにステータスが変更されている事を確認できます。
appserver1 > /sun/SUNWappserver91/hadb/4/bin/hadbm status app-cluster1 Please enter the password for the admin system user:*********** Database Status app-cluster1 Operational |
次に、システムのリブートが完了した後、システムにログインし、
HADBの管理エージェントプロセス(ma)を起動して下さい。
> ssh -l root 192.168.0.2 パスワード: [********] Last login: Wed Sep 12 11:17:51 2007 from 192.168.0.10 Sun Microsystems Inc. SunOS 5.10 Generic January 2005 You have new mail. # tcsh appserver2 > /sun/SUNWappserver91/hadb/4/bin/ma-initd start appserver2 > Management Agent version 4.4.3.6 [V4-4-3-6 2007-06-21 17:59:42 pakker@astra07] (SunOS_5.9_sparc) starting Logging to /sun/SUNWappserver91/hadb/4.4.3-6/log/ma.log 2007-09-12 14:03:43.938 INFO Management Agent version 4.4.3.6 [V4-4-3-6 2007-06-21 17:59:42 pakker@astra07] (SunOS_5.9_sparc) starting 2007-09-12 14:03:43.956 INFO Using property: ma.server.type=jmxmp 2007-09-12 14:03:43.960 INFO Using property: ma.server.mainternal.interfaces=192.168.0.2 2007-09-12 14:03:43.962 INFO Using property: ma.server.dbhistorypath=/sun/SUNWappserver91/hadb/4.4.3-6/history 2007-09-12 14:03:43.966 INFO Using property: ma.server.dbconfigpath=/sun/SUNWappserver91/config/hadb 2007-09-12 14:03:43.968 INFO Using property: console.loglevel=INFO 2007-09-12 14:03:43.969 INFO Using property: logfile.name=/sun/SUNWappserver91/hadb/4.4.3-6/log/ma.log 2007-09-12 14:03:43.971 INFO Using property: ma.server.jmxmp.port=1862 2007-09-12 14:03:43.972 INFO Using property: logfile.loglevel=INFO 2007-09-12 14:03:43.974 INFO Using property: ma.server.dbdevicepath=/sun/SUNWappserver91/hadb/4.4.3-6/device 2007-09-12 14:03:43.975 INFO Using property: repository.dr.path=/sun/SUNWappserver91/hadb/4.4.3-6/rep 2007-09-12 14:03:45.108 INFO Listening for client connections on port 1862 2007-09-12 14:03:45.398 INFO Repository REP:-54e808d5_114ee5e4be0_-8000: Multicast address=228.8.8.8, Port=1862, Bind address=192.168.0.2, Path=/sun/SUNWappserver91/hadb/4.4.3-6/rep 2007-09-12 14:05:14.959 INFO Starting node app-cluster1:1 at level auto, config version 3 2007-09-12 14:05:15.520 INFO n:1 NSUP INF 2007-09-12 14:05:15.518 p:606 Legal realtime priorities are 0 (lowest) to 59 (highest) set it to:29 |
HADBの管理エージェントプロセスが起動すると、上記のように
メッセージが表示されます。ここで、注意して頂きたいのは
上記のメッセージが表示された直後はまだ、HADBとして
正常な状態には戻っていないという事です。
上記メッセージが出力された直後にステータスを確認してください。
すると、まだ”Operational”の状態になっている事を確認できます。
理由は、前回「High Availability Session Store(HADB)の概要」
でも説明致しましたが、appserver01のテーブルの内容と同期を取る
作業等を行っているためです。
そこで、作業完了までしばらく待った後、再度コマンドを実行して下さい。
すると、ステータスが“HAFaultTolerant”/”FaultTolerant”に変わる事が
確認できるかと思います。
appserver1 > /sun/SUNWappserver91/hadb/4/bin/hadbm status app-cluster1 Please enter the password for the admin system user:*********** Database Status app-cluster1 Operational …..しばらく時間を経過した後（テーブルの同期が完了した後） appserver1 > /sun/SUNWappserver91/hadb/4/bin/hadbm status app-cluster1 Please enter the password for the admin system user:*********** Database Status app-cluster1 FaultTolerant |
このように、HADBノードを再起動する際は、片ノードづつ実行して頂き、
片ノードが完全に立ち上がって、HADBのステータスが
“HAFaultTolerant”/”FaultTolerant”の状態に戻った事を確認した後
もう一台のHADBノードを再起動するようにして下さい。
HADB環境の構築手順
さて、今日はSJS Applicatin Server 9.1 with HADBを使用して
実際にHADBの構成を組んでみたいと思います。
HADBの構成を組む前に事前にOS側で準備して置かなければならない事が
３点あります。
HADB構成前の準備：
● OSのカーネルパラメータの編集
● IPMPの構成
● NTPによる時間同期
● 準備１：OSのカーネルパラメータの編集
HADBの設定を行う前に、必ずOSのカーネルパラメータで、
共有メモリとセマフォの値を設定して下さい。
同一システム上でHADB以外のアプリケーションが
共有メモリやセマフォを使用している場合、HADBに必要な値を加算して
共有メモリやセマフォの設定を行って下さい。
共有メモリは、Solaris上では/etc/systemファイルにshminfo_shmmaxを
編集して設定を行います。
shminfo_shmmaxは、該当のホスト上で、共有メモリセグメントの
最大サイズを指定しますが、実際にはこの値はHADBをインストールする
ホストの物理メモリの合計サイズを16進数表記で指定します。
ただし、2GB以上の値は指定しないで下さい。
例えば、下記のように1GBの物理メモリを保持するシステムの場合、
16進数表記では、0x40000000を指定します。
appserver1 > prtconf|grep Memory Memory size: 1024 Megabytes |
/etc/system (共有メモリセグメントの最大サイズ)
set shmsys:shminfo_shmmax=0x40000000 |
※ Solaris 9以降shmsys:shminfo_shmseg は使用されなくなりました。
今回はSolaris 10にインストールする為、shmsys:shminfo_shmseg は
指定しません。Solaris 8以前のシステムにHADBを導入する場合は、
下記のように１プロセス辺りのセグメント数を指定して下さい。
set shmsys:shminfo_shmseg=36
次に、セマフォ識別子数の最大値をseminfo_semmniで指定します。
全てのHADBノードでは必ず一つのセマフォ識別子を必要とします。
１台の物理的なマシン上に6つのHADBノードを構築可能ですが、
6つのHADBノードを構築する場合でも下記の値で問題ありません。
/etc/system (セマフォ識別子数の最大値)
set semsys:seminfo_semmni=10 |
次に、システム上でのセマフォの最大数をseminfo_semmnsで指定します。
全てのHADBノードでそれぞれ8つのセマフォを必要とします。
６つのHADBノードを構築する場合でも下記の値で問題ありません。
/etc/system (セマフォの最大数)
set semsys:seminfo_semmns=60 |
最後に、システム上でセマフォの取り消し機能を使用する最大数を
seminfo_semmnuで指定します。
1つの接続（NumberOfSessionsで接続数を指定、デフォルト100）に対して
1つの取り消し機能が必要です。
６つのHADBノードを構築する場合で下記の値で問題ありません。
/etc/system (セマフォの取り消し機能を使用する最大値)
set semsys:seminfo_semmnu=600 |
上記を設定した後、OSのリブートを行ってください。
＊ リブートを行う前に、手動でノードエージェントの停止・ドメインの停止を
行ってください。
ノードエージェントの停止・ドメインの停止を行わないでリブートした場合、
MQのプロセスでロックファイルが削除されずに残ってしまう場合があります。
次に、２点目はHADBを導入するシステム上でIPMP(IPマルチパッシング)構成
を組んでいる場合（推奨）、IPMPのネットワークインタフェースの障害検出
時間の設定値（FAILURE_DETECTION_TIME）を変更する必要があります。
下記のように値を1,000ミリ秒に設定して下さい。
/etc/default/mpathd
FAILURE_DETECTION_TIME=1000
● 準備２：IPMPの構成
- ● 準備３：NTPによる時刻同期
Solaris 10の管理ガイド「第 3 章 システムの時刻関連サービス」を
参照し、HADBのノード間の時刻を同期して下さい。
- 上記で、準備が完了です。
SJS Application Server 9.1のドメインが起動していない場合、
Application Server 9.1のドメインとノードエージェントをそれぞれ起動して下さい。
appserver1 > ./asadmin start-node-agent –user=admin appserver01
Please enter the admin password> [********]
Please enter the master password [Enter to accept the default]:> [********]
Redirecting output to /sun/SUNWappserver91/nodeagents/appserver01/agent/logs/server.log
Redirecting application output to /sun/SUNWappserver91/nodeagents/appserver01/agent/logs/server.log
Command start-node-agent executed successfully.
appserver1 >
appserver2 > ./asadmin start-node-agent –user=admin appserver02
Please enter the admin password> [********]
Please enter the master password [Enter to accept the default]:> [********]
Redirecting output to /sun/SUNWappserver91/nodeagents/appserver02/agent/logs/server.log
Command start-node-agent executed successfully.
それでは、実際にHADBを使用するように設定を行いましょう。
- HADBの設定
- Data storageを管理
- SQLサーバからHADBのinstruction setでリクエストの受信
- Logレコードをミラーノードに転送
1. HADBの管理エージェントの起動
HADBの管理エージェント(Management Agent)を起動して下さい。
appserver1側のHADB管理エージェントの起動
appserver1 > cd /sun/SUNWappserver91/hadb/4.4.3-6/bin appserver1 > ls clusql hadbm ma ma-initd ma.cfg appserver1 > /sun/SUNWappserver91/hadb/4.4.3-6/bin/ma-initd start Management Agent version 4.4.3.6 [V4-4-3-6 2007-06-21 17:59:42 pakker@astra07] (SunOS_5.9_sparc) starting Logging to /sun/SUNWappserver91/hadb/4.4.3-6/log/ma.log 2007-09-10 12:54:14.081 INFO Management Agent version 4.4.3.6 [V4-4-3-6 2007-06-21 17:59:42 pakker@astra07] (SunOS_5.9_sparc) starting 2007-09-10 12:54:14.102 INFO Using property: ma.server.type=jmxmp 2007-09-10 12:54:14.106 INFO Using property: ma.server.mainternal.interfaces= 2007-09-10 12:54:14.108 INFO Using property: ma.server.dbhistorypath=/sun/SUNWappserver91/hadb/4.4.3-6/history 2007-09-10 12:54:14.112 INFO Using property: ma.server.dbconfigpath=/sun/SUNWappserver91/config/hadb 2007-09-10 12:54:14.114 INFO Using property: console.loglevel=INFO 2007-09-10 12:54:14.116 INFO Using property: logfile.name=/sun/SUNWappserver91/hadb/4.4.3-6/log/ma.log 2007-09-10 12:54:14.117 INFO Using property: ma.server.jmxmp.port=1862 2007-09-10 12:54:14.119 INFO Using property: logfile.loglevel=INFO 2007-09-10 12:54:14.121 INFO Using property: ma.server.dbdevicepath=/sun/SUNWappserver91/hadb/4.4.3-6/device 2007-09-10 12:54:14.123 INFO Using property: repository.dr.path=/sun/SUNWappserver91/hadb/4.4.3-6/rep 2007-09-10 12:54:15.157 INFO Listening for client connections on port 1862 |
appserver2側のHADB管理エージェントの起動
appserver2 > /sun/SUNWappserver91/hadb/4.4.3-6/bin/ma-initd start Management Agent version 4.4.3.6 [V4-4-3-6 2007-06-21 17:59:42 pakker@astra07] (SunOS_5.9_sparc) starting Logging to /sun/SUNWappserver91/hadb/4.4.3-6/log/ma.log 2007-09-10 12:49:39.194 INFO Management Agent version 4.4.3.6 [V4-4-3-6 2007-06-21 17:59:42 pakker@astra07] (SunOS_5.9_sparc) starting 2007-09-10 12:49:39.214 INFO Using property: ma.server.type=jmxmp 2007-09-10 12:49:39.218 INFO Using property: ma.server.mainternal.interfaces= 2007-09-10 12:49:39.221 INFO Using property: ma.server.dbhistorypath=/sun/SUNWappserver91/hadb/4.4.3-6/history 2007-09-10 12:49:39.225 INFO Using property: ma.server.dbconfigpath=/sun/SUNWappserver91/config/hadb 2007-09-10 12:49:39.227 INFO Using property: console.loglevel=INFO 2007-09-10 12:49:39.228 INFO Using property: logfile.name=/sun/SUNWappserver91/hadb/4.4.3-6/log/ma.log 2007-09-10 12:49:39.230 INFO Using property: ma.server.jmxmp.port=1862 2007-09-10 12:49:39.232 INFO Using property: logfile.loglevel=INFO 2007-09-10 12:49:39.233 INFO Using property: ma.server.dbdevicepath=/sun/SUNWappserver91/hadb/4.4.3-6/device 2007-09-10 12:49:39.235 INFO Using property: repository.dr.path=/sun/SUNWappserver91/hadb/4.4.3-6/rep 2007-09-10 12:49:40.158 INFO Listening for client connections on port 1862 |
※ 仮に論理IPを使用して通信をさせたい場合は、管理エージェントの
設定ファイルを編集し、下記の１行を追加した後、
ma-initd startを実行して下さい。
appserver1 > cd /sun/SUNWappserver91/hadb/4.4.3-6/bin appserver1 > vi ma.cfg ma.server.mainternal.interfaces=192.168.0.1 //<–追加 |
2.アプリケーションに対する設定
HADBの管理エージェントが起動したので、まずはデプロイ済みのアプリケーションに対して
可用性を有効にする設定を行います。
Application Server 9.1の管理コンソールより、「Enterprise Application」→「clusterjsp」と展開して下さい。
ここで、デプロイ済みのアプリケーション「clusterjsp」に対して、
「Availability：[ ] Enabled」の項目にチェックを付け、
「Save」ボタンを押下して下さい。すると下記の画面が表示されます。
３.既存クラスタに対する設定
既存のクラスタ(app-cluster1)をHigh Availabilityにするために下記のコマンドを実行して下さい。
下記のコマンドはクラスタに対する設定の他、データベースのテーブルを作成する処理等も行います。
そこで、データベース中に作成するデバイスサイズ(devicesize)の大きさに
応じてコマンドの終了までに要する時間は異なります。
下記のコマンドでは既存のクラスタ「app-cluster1」に対してHADBのノードとして
「appserver01, appserver02」のホストを指定しHADBを2ノード作成しています。
appserver1 > asadmin configure-ha-cluster –devicesize 1024 –hosts appserver01,appserver02 –user admin app-cluster1 2007-09-10 16:42:09.576 INFO hadbm create –quiet=true –no-cleanup=false –datadevices=1 –portbase=15200 –spares=0 –devicesize=1024 –adminpasswordfile=/sun/SUNWappserver91/domains/domain1/config/adminpassword –dbpasswordfile=/sun/SUNWappserver91/domains/domain1/config/dbpassword –hosts=192.168.0.1,192.168.0.2 –agent=192.168.0.1,192.168.0.2:1862 –set=LogBufferSize=48 –no-clear=false –version=false –yes=false –force=false –echo=false app-cluster1 2007-09-10 16:42:10.985 INFO Creating new domain -54e808d5_114ee5e4be0_-8000 2007-09-10 16:42:11.010 INFO Repository REP:-54e808d5_114ee5e4be0_-8000: Multicast address=228.8.8.8, Port=1862, Bind address=192.168.0.1, Path=/sun/SUNWappserver91/hadb/4.4.3-6/rep 2007-09-10 16:43:00.538 INFO Ready to accept client requests 2007-09-10 16:43:21.378 INFO Initializing device /sun/SUNWappserver91/hadb/4.4.3-6/device/app-cluster1.noman.0 for node app-cluster1:0 2007-09-10 16:43:21.382 INFO Initializing device /sun/SUNWappserver91/hadb/4.4.3-6/device/app-cluster1.data-0.0 for node app-cluster1:0 2007-09-10 16:43:21.383 INFO Initializing device /sun/SUNWappserver91/hadb/4.4.3-6/device/app-cluster1.nilog.0 for node app-cluster1:0 2007-09-10 16:43:21.385 INFO Initializing device /sun/SUNWappserver91/hadb/4.4.3-6/device/app-cluster1.relalg.0 for node app-cluster1:0 2007-09-10 16:44:02.694 INFO Starting node app-cluster1:0 at level firststart, config version 1, in order to start database 2007-09-10 16:44:03.082 INFO n:0 NSUP INF 2007-09-10 16:44:03.069 p:921 Legal realtime priorities are 0 (lowest) to 59 (highest) set it to:29 Command configure-ha-cluster executed successfully. |
上記以外で指定可能なコマンドオプションについては、下記のオンラインヘルプを
御参照ください。
appserver1> asadmin configure-ha-cluster –help | less Administration Commands configure-ha-cluster(1) NAME configure-ha-cluster – configures an existing cluster to be highly available SYNOPSIS configure-ha-cluster [–terse={true|false}][ –echo={true|false} ] [ –interactive={true|false} ] [ –host host] [–port port] [–secure| -s ] [ –user admin_user] [–passwordfile filename] [–help] [ –devicesize devicesize] [–haagentport port_number] [–haadminpassword password] [–haadminpasswordfile file_name] –hosts hadb-host-list [–autohadb={true|false}] [ –portbase port_number] [–property (name=value)[:name-value]*] {clusterName} |
上記コマンドが完了した後、システム上にはhadbに関連する
下記の8プロセスが自動的に起動されます。
appserver1 > ps -ef | grep hadb root 794 1 0 16:36:00 ? 0:00 /sun/SUNWappserver91/hadb/4.4.3-6/bin/ma –umask=077 /sun/SUNWappserver91/hadb/ root 807 805 0 16:39:31 ? 0:17 /sun/SUNWappserver91/hadb/4.4.3-6/lib/server/clu_sql_srv -d 0x00000000 root 805 799 1 16:39:27 ? 2:36 /sun/SUNWappserver91/hadb/4.4.3-6/lib/server/clu_nsup_srv -c /sun/SUNWappserver root 808 805 0 16:39:31 ? 0:17 /sun/SUNWappserver91/hadb/4.4.3-6/lib/server/clu_sqlshm_srv -d 0x00000000 root 809 805 0 16:39:31 ? 0:15 /sun/SUNWappserver91/hadb/4.4.3-6/lib/server/clu_relalg_srv -d 0x00000000 -Drel root 806 805 1 16:39:31 ? 2:42 /sun/SUNWappserver91/hadb/4.4.3-6/lib/server/clu_trans_srv -d 0x00000000 -m /su root 810 805 1 16:39:31 ? 1:48 /sun/SUNWappserver91/hadb/4.4.3-6/lib/server/clu_noman_srv -d 0x00000000 -Dnoma root 1030 807 0 18:55:06 ? 0:04 /sun/SUNWappserver91/hadb/4.4.3-6/lib/server/clu_sql_srv -d 0x00000000 -Dsql_th |
仮にプロセス数が少ない場合は、HADBが正常に起動できていない可能性があるため、
HADBの管理エージェントのログを御確認頂き、エラーが出力されていないか確認してください。
HADB 管理エージェントのログ
appserver1 > cat /sun/SUNWappserver91/hadb/4/log/ma.log |
４.動作確認
それでは、HADBの構成が完了しましたので、動作確認をしてみましょう。
ブラウザでWeb Server経由(192.168.0.3)でデプロイしたアプリケーション
(clusterjsp)にアクセスして見ましょう。
ブラウザで接続すると下記のような画面が表示されます。
ここで、「Name of Session Attribute」、「Value of Session Attribute」の
欄にそれぞれ、適当な文字列を入力し「ADD Session DATA」ボタンを押下して下さい。
すると、ページの下側に入力した文字列(aaaa,bbbb等)が表示されます。
ここで、１点確認しておいて下さい。「Executed From Server:」、
「Executed Server IP Address:」の欄にそれぞれ、アプリケーションを実際に
実行しているアプリケーションサーバ名とIPアドレスがそれぞれ表示されています。
下記の例では、アプリケーションは「appserver01」、「192.168.0.1」で
実行されている事が確認できます。
※ アプリケーションに接続しているブラウザの画面を閉じずそのままの
画面にしたまま、下記の手順を行ってください。
アプリケーションを実行しているサーバは「appserver01」である事が
上記より確認できましたので、「appserver01」に障害が発生した事を仮定し、
「appserver01」のインスタンスを停止してみましょう。
疑似アプリケーションサーバ停止状態
Application Server 9.1の管理コンソールより、「Clusters」→「app-cluster1」
→「appserver01-instance1」を選択します。すると下記の画面が表示されますので、
「Stop Instance」ボタンを押下して下さい。
「Stop Instance」ボタンを押下すると下記の画面が表示されます。
インスタンスが停止した事を確認し、再度ブラウザに戻ってください。
そして、以前表示された画面のまま、「RELOAD PAGE」ボタンを押下してください。
すると、下記の画面が表示されます。
内容は殆ど同じですが、変更点を確認してみましょう。
先ほどは「Executed From Server:」欄に「appserver01」が記載されていましたが、
画面を再読み込みすると「appserver02」、「192.168.0.2」にかわっている事が確認できます。
さらには、画面下部には先ほど入力した内容（aaaa,bbbb等）が、そのまま
表示されている事が確認できるかと思います。
このように、HADBを使用すると、アプリケーションサーバが稼働するシステムに
何らかの障害が発生し停止した場合でも、セッション情報がHADB内に保持されているため、
引き続き���ービスを提供できる事ができます。
以上で、HADB２ノード構成のシステムを構築しましたが、実際にはHADB2ノードでは
耐障害性は十分ではありません、スペアノードを作成し、より可用性レベルの高いシステムを
構築する事が必要になってまいりますが、その方法についてはまた改めて説明したいと思います。
５.HADBシステムの停止方法
HADBの環境はプライマリーとミラーの両ノード間で通信を行っています。
仮に相手と通信ができなくなった場合、自分のミラーとして使用していた
セグメントレプリカをプライマリに変更し、自分が両方のプライマリを持っていると判断します。
このようにHADBは対となるノードに障害が発生した場合、一時的に片ノードだけでサービスを提供します。
そこでHADBの環境下でシステムを停止する際は、必ず片ノードづつリブートを行うように
して下さい。（片方が完全に立ち上がった事を確認しもう片方をリブートして下さい。）
仮に両ノードが同時に停止すると両方のノードが自分がプライマリとして判断し
データベースが壊れてしまいます。そのような場合、データベースを再構築しなくては
なりません。（その方法は別途紹介します。）
計画停電等でどうしても両ノードを停止する必要がある場合は、下記のコマンドを実行し
HADBのプロセスを明示的に停止して下さい。
appserver1 > /sun/SUNWappserver91/hadb/4/bin/hadbm stop app-cluster1 Please enter the password for the admin system user:*********** 2007-09-10 21:54:32.811 INFO hadbm stop –force=false –quiet=false –version=false –yes=false –echo=false app-cluster1 This command will stop the database app-cluster1. Type “yes” or “y” to confirm this operation, anything else to cancel:y 2007-09-10 21:54:36.076 INFO Node app-cluster1:1 is currently running at config version 1, stopping node in order to stop database Database app-cluster1 successfully stopped. |
最後に、補足事項を下記に説明します。是非参考にしてください。
補足１：HADBの各プロセスの意味
下記にHADBを実行する事により起動されるプロセスの一覧とその意味をまとめます。
| HADB | /opt/SUNWhadb/4/bin/ma /etc/opt/SUNWhadb/mgt.cfg |
HADB Management Agent起動コマンド |
| HADB | java -Djava.class.path= /opt/SUNWhadb/4.4.1-7/lib/hadbm… |
HADB Management Agent |
| HADB | clu_nsup_srv # Node supervisor (NSUP) |
HADB Node Supervisor 各HADB node毎に起動します。Node Supervisorは５つの子プロセスを監視し、ハートビートがなくなったときそれらを再起動します。 |
| HADB (Node supervisorの子プロセス) |
clu_sql_srv # SQL (SQLC) |
SQLサーバプロセス JDBC driver , clusql CLIから接続可能です。HADB instructionにコンパイルし、TRANSに送信します。また、その結果を受信しクライアントに返します。クライアント接続毎に1つのサブサーバを持ちます。 |
| HADB (Node supervisorの子プロセス) |
clu_trans_srv # Transaction (TRANS) |
トランザクションサーバプロセス 分散されたノード上のトランザクションを調整します。主な役割として次のものがあります。 |
| HADB (Node supervisorの子プロセス) |
clu_relalg_srv # Relational algebra (RELALG) |
Relational algebra query サーバプロセス。sort/join等の関係代数クエリーを調整・実行する。 |
| HADB (Node supervisorの子プロセス) |
clu_sqlshm_srv # SQL shared memory (SQLSHM) |
Shared memory segmentを管理するサーバプロセス。 SQL dictionary cacheを管理する。 |
| HADB (Node supervisorの子プロセス) |
clu_noman_srv # Node manager (NOMAN) |
Node manager サーバプロセス。 Management agentがhadbmから発行された管理コマンドを実行するために使用します。また、nodeの最新の状態を把握し、nodeが停止したときと同じ状態で起動します。 |
補足２：HADBの状態確認
hadbmコマンドを使用するとHADBの状態を確認する事ができます。
HADBは内部的に、下記の６つの状態を判定します。
| 1. High-Availability Fault Tolerant (HAFT) | データベースに耐障害性があり、DRU毎にすくなくとも１つのスペアノードを備えている。 |
| 2. Fault Tolerant (FT) | 全てのミラーノードペアが実行中である。 |
| 3. Operational (O) | 各ミラーノードペアの内少なくとも１つのノードが実行中である。 |
| 4. Non Operational (NO) | １つ以上のミラーノードペアで、両方のノードが無くなっている。 |
| 5. Stopped (S) | データベース内に実行中のノードが存在しない。 |
| 6. Unknown (U) | データベースの状態を判定できない。 |
下記のコマンドの実行例では、上から２番目の可用性(Fault Tolerant)が確保されています。
より高い可用性を確保する為には、HADBのスペアノードを追加し、HADBノードの障害時に
ノードを切り替えられるようにする必要があります。
appserver1 > /sun/SUNWappserver91/hadb/4/bin/hadbm status app-cluster1 Please enter the password for the admin system user:[***********] 2007-09-10 16:47:37.161 INFO hadbm status –nodes=false –quiet=false –version=false –yes=false –force=false –echo=false app-cluster1 Database Status app-cluster1 FaultTolerant appserver1 > |
補足3： HADBのデバイス情報の確認方法：
下記のコマンドでHADBのデバイスに関する使用状況や空きサイズ等の情報を取得可能です。
appserver1 > /sun/SUNWappserver91/hadb/4/bin/hadbm deviceinfo –details app-cluster1 Please enter the password for the admin system user:*********** 2007-09-10 16:51:48.538 INFO hadbm deviceinfo –details=true –quiet=false –version=false –yes=false –force=false –echo=false app-cluster1 NodeNo TotalSize FreeSize Usage NReads NWrites DeviceName 0 1024 841 18% 0 341 /sun/SUNWappserver91/hadb/4.4.3-6/device/app-cluster1.data-0.0 1 1024 841 18% 0 364 /sun/SUNWappserver91/hadb/4.4.3-6/device/app-cluster1.data-0.1 appserver1 > |
補足4： HADBのリソースの確認方法：
下記のコマンドでHADBのリソースに関する使用状況や空きサイズ等の情報を取得可能です。
appserver1 > /sun/SUNWappserver91/hadb/4/bin/hadbm resourceinfo app-cluster1 Please enter the password for the admin system user:*********** 2007-09-10 16:53:08.408 INFO hadbm resourceinfo –databuf=false –locks=false –logbuf=false –nilogbuf=false –quiet=false –version=false –yes=false –force=false –echo=false app-cluster1 Data buffer pool: NodeNo Avail Free Access Misses Copy-on-Write 0 198 194 25166 0 0 1 198 194 23988 0 23 Locks: NodeNo Avail Free Waits 0 50000 50000 na 1 50000 50000 na Log buffer: NodeNo Avail Free 0 44 40 1 44 40 Node internal log buffer: NodeNo Avail Free 0 11 11 1 11 11 |
補足5: ドメインを停止せずにリブートしMQが起動できなくなった場合の対処方法：
Application Serverのドメインの起動時にMQが起動できずに、
結果としてApplication Serverが正常に起動できなくなる事があります。
そのような場合、MQのlockファイルを手動で削除した後、再度ドメインを起動して下さい。
起動失敗時のサーバのログ
[#|2007-09-07T17:39:33.792+0900|SEVERE|sun-appserver9.1|javax.resourceadapter.mqjmsra.lifecycle|_ThreadID=10; _ThreadName=main;_RequestID=7ce995f7-ea5b-4e95-ae20-60e91c9888d8;|MQJMSRA_RA4001: start:Aborting:Exception starting EMBEDDED broker=EMBEDDED Broker start failure:code = 1|#] [#|2007-09-07T17:39:33.814+0900|WARNING|sun-appserver9.1|javax.enterprise.system.stream.err| _ThreadID=10;_ThreadName=main;_RequestID=7ce995f7-ea5b-4e95-ae20-60e91c9888d8;| java.lang.RuntimeException: EMBEDDED Broker start failure:code = 1 at com.sun.messaging.jms.ra.EmbeddedBrokerRunner.start(EmbeddedBrokerRunner.java:268) at com.sun.messaging.jms.ra.ResourceAdapter.start(ResourceAdapter.java:472) |
対処方法
appserver1 > pwd /sun/SUNWappserver91/domains/domain1/imq/instances/imqbroker appserver1 > ls -lF 合計 10 drwx—— 2 root root 512 9月 3日 11:46 etc/ drwxr-xr-x 3 root root 512 9月 3日 12:32 fs370/ -rw-r–r– 1 root root 27 9月 3日 12:32 lock drwx—— 2 root root 512 9月 3日 11:46 log/ drwx—— 2 root root 512 9月 3日 11:46 props/ appserver1 > less lock imqbroker:appserver01:7676 appserver1 > rm lock |
寺田 佳央 - Yoshio Terada 
