Archive for 2010年2月5日

GlassFish SSLの設定 (サーバ証明書の設定)

※ GlassFish で証明書の管理や鍵の管理を行う場合、
管理コンソールからは行えません.コマンドを使用してください.

SSLの設定(サーバ認証の設定)

クライアントのWebブラウザからサーバに対してSSL通信を行う場合,通常アプリケーションサーバの前段に配置するロードバランサもしくはリバースプロキシなどのシステムでSSL設定を行い,前段のシステムとアプリケーションサーバ間はSSLによる通信を行わない場合が多いです.しかしミッションクリティカルな環境では,前段のシステムとアプリケーションサーバ間もセキュアな通信路を確保する必要があリます.そのような場合,アプリケーションサーバ上でもSSLのサーバ証明書を設定する必要があります.ここでは前段のシステムからSSLで負荷分散されることを想定しクラスタ環境に対してSSLの設定を行う方法について紹介します.単一サーバインスタンスに対する設定を行う場合も基本的には同様の手続きで可能ですので参考にしてください.

今回紹介するクラスタ環境におけるSSL証明書管理の利点は,クラスタ構成に対して一度だけ設定を行えばクラスタに所属する全てのインスタンスに対して共通のSSL設定が有効になりますので,管理するマシンの台数が多い場合非常に便利です。
GlassFishのSSL設定はサーバ証明書のニックネームを変更する以外の殆どの設定操作をコマンドを使用して行います.そこで以下の説明では全ての操作をコマンドを使用して管理する方法を紹介します.

また,下記の手順は開発者プロファイル,クラスタプロファイル(Sun GlassFish Enterprise Server/OSS版GlassFish)を使用した場合の方法を紹介します.開発者プロファイル,クラスタプロファイルを使用する場合,証明書の管理にJava SEに付属するkeytoolを使用して管理します.エンタープライズプロファイル(Sun GlassFish Enterprise Server with HADB)を使用する場合は,NSS (Network Security Service)のcertutilコマンドやライブラリを使用します.certutilコマンドを使用した証明書管理方法は別途「GlassFish Enteprise Server管理ガイド」をご参照ください.

既存の自己署名証明書の確認

keytoolの-listコマンドを使用してGlassFishのインストール時に,デフォルトでインストールされている証明書を確認できます.証明書のキーストアはドメインのconfigディレクトリ中に存在しています.keystore.jksにはサーバ証明書などを格納します.またcacerts.jksには認証局(CA)の証明書などを格納します.

dashost > cd /export/home/appserv/domains/clusterDomain/config/
dashost > ls keystore.jks cacerts.jks
cacerts.jks keystore.jks
dashost > keytool -list -keystore ./keystore.jks -alias s1as -storepass changeit
s1as, 2009/12/03, PrivateKeyEntry,
証明書のフィンガープリント (MD5): E7:3A:3C:2A:F1:AE:7D:E8:72:0D:E5:A7:AE:87:97:DA
dashost > keytool -list -keystore cacerts.jks -alias s1as -storepass changeit
s1as, 2009/12/03, trustedCertEntry,
証明書のフィンガープリント (MD5): E7:3A:3C:2A:F1:AE:7D:E8:72:0D:E5:A7:AE:87:97:DA

鍵のペア(公開鍵および関連する非公開鍵)の生成

keytoolの-genkeypairコマンドを使用して鍵のペアを生成します.クラスタ環境では実際の接続先はクラスタに所属するノードエージェントのホスト名になるため,CNにワイルドカードでホスト名を指定(*.japan.sun.com)することをおすすめします.ワイルドカードを使用すると,実際の接続先がnodeagent1.japan.sun.comやnodeagent2.japan.sun.comであった場合も正当なサーバ証明書として利用できます.単一のサーバインスタンスに対するサーバ証明書を作成する際は,CNに対してサーバ名をFQDN(www.japan.sun.com)で指定してください.

dashost > keytool -genkeypair -alias cluster -keystore keystore.jks -keyalg RSA -keysize 2048 -validity 365 -dname “CN=*.japan.sun.com, OU=Software Practice, O=Sun Microsystems, L=Setagaya, ST=Tokyo, C=JP” -storepass changeit -keypass changeit

証明書署名要求(CSR)の生成

keytool の-certreqコマンドを使用して証明書署名要求(CSR)を作成します.クラスタ環境における実際の接続先はクラスタに所属するノードエージェント上のインスタンスになるため,ワイルドカードでホスト名を指定することをおすすめします.ワイルドカードを使用すると,実際の接続先がnodeagent1.japan.sun.comやnodeagent2.japan.sun.comであった場合も正当なサーバ証明書として利用できます.(単一のサーバインスタンスに対してサーバ証明書を作成する際は,*(アスタリスク)の代わりにサーバ名をFQDNで指定してください.)

dashost > keytool -certreq -alias cluster -keystore ./keystore.jks -file cluster.japan.sun.com.csr -storepass changeit

署名前のサーバ証明書の確認

下記のコマンドを実行しkeytoolで作成したCSRの内容を確認します.

dashost > openssl req -text -in ./cluster.japan.sun.com.csr
Certificate Request:
Data:
Version: 0 (0x0)
Subject: C=JP, ST=Tokyo, L=Setagaya, O=Sun Microsystems, OU=Software Practice, CN=*.japan.sun.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (2048 bit)
(省略)

認証局(CA)でサーバ証明書を署名

GlassFish 上で生成した CSR を元に認証局で署名を行います.

ca-server > openssl ca -in cluster.japan.sun.com.csr -keyfile ./demoCA/private/cakey.pem -cert ./demoCA/cacert.pem -out /tmp/signed-cluster.japan.sun.com.cert
Using configuration from /usr/local/ssl/openssl.cnf
Enter pass phrase for ./demoCA/private/cakey.pem:
Check that the request matches the signature
Signature ok
Certificate Details:
Serial Number:
cd:ea:db:f4:c8:e3:93:8f
(省略)
Certificate is to be certified until Dec 3 11:23:45 2010 GMT (365 days)
Sign the certificate? [y/n]: y
1 out of 1 certificate requests certified, commit? [y/n] y
Write out database with 1 new entries
Data Base Updated

認証局(CA)でサーバ証明書をバイナリ(DER)形式に変換

keytool で証明書(鍵)データベースに保存するため,署名された証明書(signed-cluster.japan.sun.com.cert)をバイナリ(DER)形式(signed-cluster.japan.sun.com.der)に変換します.

ca-server > openssl x509 -in /tmp/signed-cluster.japan.sun.com.cert -outform DER -out /tmp/signed-cluster.japan.sun.com.der

認証局(CA)の証明書(cecert.pem)からX.509形式の証明書を準備

自己認証局によって署名されたサーバ証明書をGlassFishにインポートする前に,認証機関の証明書をGlassFishの証明書(鍵)データベースにインポートする必要があります.下記のように認証局のX.509形式のフォーマットを別ファイルにコピー&ペーストして保存してください.

dashost > vi cacert.x509
“cacert.x509” [新規ファイル]
—–BEGIN CERTIFICATE—–
MIIDmTCCAwKgAwIBAgIJAM3q2/TI45OEMA0GCSqGSIb3DQEBBQUAMIGQMQswCQYD
VQQGEwJKUDEOMAwGA1UECBMFVG9reW8xGTAXBgNVBAoTEFN1biBNaWNyb3N5c3Rl
bXMxGjAYBgNVBAsTEVNvZnR3YXJlIFByYWN0aWNlMRowGAYDVQQDExFjYS1zZXJ2
ZXIuc3VuLmNvbTEeMBwGCSqGSIb3DQEJARYPY2FhZG1pbkBTdW4uQ09NMB4XDTA5
MTEwOTA0NDAwOVoXDTEyMTEwODA0NDAwOVowgZAxCzAJBgNVBAYTAkpQMQ4wDAYD
VQQIEwVUb2t5bzEZMBcGA1UEChMQU3VuIE1pY3Jvc3lzdGVtczEaMBgGA1UECxMR
U29mdHdhcmUgUHJhY3RpY2UxGjAYBgNVBAMTEWNhLXNlcnZlci5zdW4uY29tMR4w
HAYJKoZIhvcNAQkBFg9jYWFkbWluQFN1bi5DT00wgZ8wDQYJKoZIhvcNAQEBBQAD
gY0AMIGJAoGBALbumBZl+9qUSGdxADtmgW8JRlriRmwOgOoYyrifayZz7to2SB09
+gk7alqzEFz1vFA2jUZu4X8veWMP/PLFvmjwPVXtSbk3HeRWosinb0ge49sX1/Nl
GOe90wGQzxci30O6V8FlHo1bWt9p/SSXZzLAtSn9Y5Au1GlpGHO4gL4hAgMBAAGj
gfgwgfUwHQYDVR0OBBYEFB24TDDMoTWycjWgisz6+RecxNJKMIHFBgNVHSMEgb0w
gbqAFB24TDDMoTWycjWgisz6+RecxNJKoYGWpIGTMIGQMQswCQYDVQQGEwJKUDEO
MAwGA1UECBMFVG9reW8xGTAXBgNVBAoTEFN1biBNaWNyb3N5c3RlbXMxGjAYBgNV
BAsTEVNvZnR3YXJlIFByYWN0aWNlMRowGAYDVQQDExFjYS1zZXJ2ZXIuc3VuLmNv
bTEeMBwGCSqGSIb3DQEJARYPY2FhZG1pbkBTdW4uQ09NggkAzerb9Mjjk4QwDAYD
VR0TBAUwAwEB/zANBgkqhkiG9w0BAQUFAAOBgQAyiypjUnJBMMyy615ZYM3oOUYZ
3UgwLOnos/rGGCov9CIcxiLH8PcXc3IXRYgRFDqINRhSqfDrjt4YP9cz4QmEbNqy
9wPxrje4HPYZU+AKErN7Wt058dKFSeA+Wp2JsDiwdoARy4Ow/j/tkhVoOm07E3fM
TbEdS42dtkHlBgdSrw==
—–END CERTIFICATE—–

GlassFish 上で認証局の証明書をインポート

認証期間の署名書(cacert.x509)を,GlassFishが稼働するマシン上にコピーしそれぞれ証明書データベース,鍵データベースにインポートしてください.

dashost > keytool -import -file /tmp/cacert.x509 -trustcacerts -alias private-ca -keystore keystore.jks -storepass changeit
所有者: EMAILADDRESS=caadmin@Sun.COM, CN=ca-server.sun.com, OU=Software Practice, O=Sun Microsystems, ST=Tokyo, C=JP
発行者: EMAILADDRESS=caadmin@Sun.COM, CN=ca-server.sun.com, OU=Software Practice, O=Sun Microsystems, ST=Tokyo, C=JP
シリアル番号: cdeadbf4c8e39384
有効期間の開始日: Mon Nov 09 13:40:09 JST 2009 終了日: Thu Nov 08 13:40:09 JST 2012
証明書のフィンガープリント:
MD5: 7C:21:2B:4A:DF:A4:5D:BF:78:1D:56:22:54:3F:4E:48
SHA1: 00:3C:55:1E:34:60:FC:77:24:38:7E:64:39:C4:38:48:79:92:2F:31
署名アルゴリズム名: SHA1withRSA
バージョン: 3
(省略)
この証明書を信頼しますか? [no]: yes
証明書がキーストアに追加されました。

dashost > keytool -import -file /tmp/cacert.x509 -trustcacerts -alias private-ca -keystore cacerts.jks -storepass changeit
所有者: EMAILADDRESS=caadmin@Sun.COM, CN=ca-server.sun.com, OU=Software Practice, O=Sun Microsystems, ST=Tokyo, C=JP
発行者: EMAILADDRESS=caadmin@Sun.COM, CN=ca-server.sun.com, OU=Software Practice, O=Sun Microsystems, ST=Tokyo, C=JP
シリアル番号: cdeadbf4c8e39384
有効期間の開始日: Mon Nov 09 13:40:09 JST 2009 終了日: Thu Nov 08 13:40:09 JST 2012
証明書のフィンガープリント:
MD5: 7C:21:2B:4A:DF:A4:5D:BF:78:1D:56:22:54:3F:4E:48
SHA1: 00:3C:55:1E:34:60:FC:77:24:38:7E:64:39:C4:38:48:79:92:2F:31
署名アルゴリズム名: SHA1withRSA
バージョン: 3
(省略)
この証明書を信頼しますか? [no]: yes
証明書がキーストアに追加されました。

GlassFish上で認証局(CA)で署名されたサーバ証明書をインポート

認証局の証明書をインポートした後に,認証局で署名されたバイナリ(DER)形式のサーバ証明書を鍵データベースにインポートします。この時このサーバ証明書を識別するためのエイリアスとして cluster という名前を設定して実行します.

dashost > keytool -import -alias cluster -file /tmp/signed-cluster.japan.sun.com.der -keystore keystore.jks -storepass changeit
証明書応答がキーストアにインストールされました。


署名済みサーバ証明書をインポートした後,鍵データベースの内容を確認してみましょう.

dashost > keytool -list -keystore keystore.jks -storepass changeit
キーストアのタイプ: JKS
キーストアのプロバイダ: SUN
キーストアには 3 エントリが含まれます。
cluster, 2009/12/03, PrivateKeyEntry,
証明書のフィンガープリント (MD5): 2A:50:2A:50:1E:B9:3F:42:DB:4C:AF:8D:48:38:AB:05
private-ca, 2009/12/03, trustedCertEntry,
証明書のフィンガープリント (MD5): 7C:21:2B:4A:DF:A4:5D:BF:78:1D:56:22:54:3F:4E:48
s1as, 2009/12/03, PrivateKeyEntry,
証明書のフィンガープリント (MD5): B0:69:F8:C5:C0:09:44:D7:0C:9A:06:4B:33:53:E0:05


次に,インポートしたサーバ証明書をクラスタ環境で利用できるように,クラスタで使用するSSLのサーバ証明書ニックネームを全てs1asからcluster変更します.クラスタ設定で s1as を参照するSSLの設定一覧を表示し確認します.

dashost > asadmin get “*” | grep cluster1 | grep s1as
cluster1-config.admin-service.jmx-connector.system.ssl.cert-nickname = s1as
cluster1-config.http-service.http-listener.http-listener-2.ssl.cert-nickname = s1as
cluster1-config.iiop-service.iiop-listener.SSL.ssl.cert-nickname = s1as
cluster1-config.iiop-service.iiop-listener.SSL_MUTUALAUTH.ssl.cert-nickname = s1as
cluster1.admin-service.jmx-connector.system.ssl.cert-nickname = s1as
cluster1.http-service.http-listener.http-listener-2.ssl.cert-nickname = s1as
cluster1.iiop-service.iiop-listener.SSL.ssl.cert-nickname = s1as
cluster1.iiop-service.iiop-listener.SSL_MUTUALAUTH.ssl.cert-nickname = s1as


s1as の証明書ニックネームを参照している全ての設定をasadmin setコマンドを使用してclusterに変更します.

dashost > asadmin set cluster1-config.admin-service.jmx-connector.system.ssl.cert-nickname=cluster
dashost > asadmin set cluster1-config.http-service.http-listener.http-listener-2.ssl.cert-nickname=cluster
dashost > asadmin set cluster1-config.iiop-service.iiop-listener.SSL.ssl.cert-nickname=cluster
dashost > asadmin set cluster1-config.iiop-service.iiop-listener.SSL_MUTUALAUTH.ssl.cert-nickname=cluster
dashost > asadmin set cluster1.admin-service.jmx-connector.system.ssl.cert-nickname=cluster
dashost > asadmin set cluster1.http-service.http-listener.http-listener-2.ssl.cert-nickname=cluster
dashost > asadmin set cluster1.iiop-service.iiop-listener.SSL.ssl.cert-nickname=cluster
dashost > asadmin set cluster1.iiop-service.iiop-listener.SSL_MUTUALAUTH.ssl.cert-nickname=cluster


上記で,GlassFish のサーバ証明書の設定はすべて完了です.設定内容を反映させるため,最後にクラスタを再起動します.

dashost > asadmin stop-cluster cluster1
クラスタ化されたインスタンス instance1 の停止に成功しました。
クラスタ化されたインスタンス instance2 の停止に成功しました。
コマンド stop-cluster は正常に実行されました。
dashost > asadmin start-cluster cluster1
クラスタ化されたインスタンス instance1 の起動に成功しました。
クラスタ化されたインスタンス instance2 の起動に成功しました。
コマンド start-cluster は正常に実行されました。


ブラウザからアクセスして証明書の内容を表示すると,
ca-server.sun.comによって署名されたサーバ証明書を確認できます.

ブラウザでサーバ証明書の内容を確認

ブラウザでサーバ証明書の内容を確認

SSL 設定に関するデバッグ方法

最後に、SSLの設定に関するデバッグ方法を紹介します.SSLの設定で何らかの問題が発生した場合は,下記コマンドを実行して各インスタンスのログを確認してください.

dashost > asadmin create-jvm-options –target cluster1 “-Djavax.net.debug=ssl”
コマンド create-jvm-options は正常に実行されました。
dashost > asadmin stop-cluster cluster1
クラスタ化されたインスタンス instance1 の停止に成功しました。
クラスタ化されたインスタンス instance2 の停止に成功しました。
コマンド stop-cluster は正常に実行されました。
dashost > asadmin start-cluster cluster1
クラスタ化されたインスタンス instance1 の起動に成功しました。
クラスタ化されたインスタンス instance2 の起動に成功しました。
コマンド start-cluster は正常に実行されました。


証明書失効リスト(CRL)のチェック方法については下記のブログを参照してください.
http://weblogs.java.net/blog/kumarjayanti/archive/2007/11/ssl_and_crl_che.html

2010年2月5日 at 6:29 午後

GlassFish ドメイン管理サーバのバックアップとリストア

※ GlassFish のドメイン管理サーバのバックアップとリストアは
管理コンソールからは行えません.コマンドを使用してください.

ドメイン管理サーバが稼働するサーバが何らかの障害により起動できなくなった場合,ドメインの管理ができなくなります.ドメイン管理サーバが稼働していない状態でもサーバインスタンスを稼働させることはできますが,ドメイン管理サーバが壊れている状態ではアプリケーションの更新やリソースの設定変更等ができなくなります.このような場合、ドメイン管理サーバの設定をバックアップしておくことで,他のサーバをドメイン管理サーバの代替えとして利用することができます.バックアップはドメイン管理サーバ上で何らかの設定変更を行った際,その都度取得しておくことを推奨します.

バックアップを取得する前に,ドメイン管理サーバを停止してください.ドメイン管理サーバを停止しても提供しているサービスに影響は及びませんのでこの作業は本番稼働中に行っても問題ありません.

dashost > asadmin stop-domain clusterDomain
ドメイン clusterDomain が停止しました。


次にドメイン管理サーバのバックアップを行います.–domaindirには対象のドメインが含まれるディレクトリを指定します.

dashost > asadmin backup-domain –domaindir /export/home/appserv/domains clusterDomain
ドメインを正常にバックアップしました
説明: 1259776406949
バックアップファイル名: /export/home/appserv/domains/clusterDomain/backups/sjsas_backup_v00001.zip
バックアップを実行した日付と時刻: Thu Dec 03 02:53:26 JST 2009
ドメインディレクトリ: /export/home/appserv/domains
ドメインディレクトリ: /export/home/appserv/domains/clusterDomain
ドメイン名: clusterDomain
バックアップを実行したユーザーの名前: appserv


バックアップコマンドを実行すると,sjsas_backup_vXXXXX.zipと名付けられたバックアップファイルが作成されます.このファイルをドメイン管理サーバのバックアップ用のサーバにFTP等を利用してコピーしておきます.ここではドメイン管理サーバのバックアップ用のサーバとしてnodeagent1を使用します.本番環境ではノードエージェントとは別のマシン上に構築することを推奨します.

nodeagent1 > asadmin restore-domain –filename ./sjsas_backup_v00001.zip clusterDomain
ドメイン clusterDomain の /export/home/appserv/domains/clusterDomain への復元に成功しました
説明: 1259776406949
バックアップファイル名: /export/home/appserv/domains/clusterDomain/backups/sjsas_backup_v00001.zip
バックアップを実行した日付と時刻: Thu Dec 03 02:53:26 JST 2009
ドメインディレクトリ: /export/home/appserv/domains
ドメインディレクトリ: /export/home/appserv/domains/clusterDomain
ドメイン名: clusterDomain
バックアップを実行したユーザーの名前: appser


展開したファイル中よりドメイン管理サーバ名が記載されている箇所を手動で編集します.domains/clusterDomain/config /domain.xml中より修正する必要のある該当箇所を表示し,dashostからnodeagent1に変更します.

nodeagent1 > grep dashost domain.xml
<property name="client-hostname" value="dashost“/>
<jms-host admin-password="admin" admin-user-name="admin" host="dashost” name=”default_JMS_host” port=”5076″/>
<property name="client-hostname" value="dashost“/>
<jms-host admin-password="admin" admin-user-name="admin" host="dashost” name=”default_JMS_host” port=”${JMS_PROVIDER_PORT}”/>
<property name="client-hostname" value="dashost“/>
<jms-host admin-password="admin" admin-user-name="admin" host="dashost” name=”default_JMS_host” port=”${JMS_PROVIDER_PORT}”/>


新しい環境上で再度環境変数を設定した後,ドメインを起動します.

nodeagent1 > setenv AS_ADMIN_HOST nodeagent1.japan.sun.com
nodeagent1 > env |grep AS
AS_ADMIN_USER=clusterAdmin
AS_ADMIN_PASSWORDFILE=/export/home/appserv/.passwordfile
AS_ADMIN_HOST=nodeagent1.japan.sun.com
AS_ADMIN_PORT=5048
nodeagent1 > asadmin start-domain clusterDomain
ドメイン clusterDomain を起動しています。お待ちください。
デフォルトのログの場所は /export/home/appserv/domains/clusterDomain/logs/server.log です。
出力を /export/home/appserv/domains/clusterDomain/logs/server.log にリダイレクトしています
ドメイン clusterDomain が起動しました。
ドメイン [clusterDomain] はその設定で [Sun GlassFish Enterprise Server v2.1.1 ((v2.1 Patch06)(9.1_02 Patch12)) (build b31g-fcs)] を実行しています。ログは [/export/home/appserv/domains] にあります。
管理コンソールは [http://localhost:5048] で使用できます。
“asadmin” コマンドにも同じポート [5048] を使用します。
ユーザーの Web アプリケーションは次の URL で使用できます:
[http://localhost:5080 https://localhost:5081 ]。
次の web-contexts を使用できます:
[/web1 /__wstx-services ]。
標準の JMX クライアント (JConsole など) はドメイン管理のために JMXServiceURL:
[service:jmx:rmi:///jndi/rmi://nodeagent1.japan.sun.com:5086/jmxrmi]
に接続できます。
ドメインは少なくとも次のポートで接続を待機しています:
[5080 5081 5048 5037 5038 5039 5086 ]。
ドメインはアプリケーションサーバークラスタおよびその他のスタンドアロンインスタンスをサポートします。


上記で,ドメインのリストアは完了です.仮にドメイン管理サーバにアクセスするためにSSLを有効にしている場合にドメイン管理サーバのホスト名が変わる場合,サーバ証明書の更新も必要です.デフォルトでインストールされている自己署名サーバ証明書は変更前のドメイン管理サーバ名が記載されていますので更新の必要があります.
最後に,念のためノードエージェントが保持するドメイン管理サーバへの参照情報が更新されているか確認してください.全てのノードエージェントはagentディレクトリ中にconfigディレクトリが存在しています.このディレクトリ配下にdas.propertiesファイルが存在しており,ドメイン管理サーバへ接続するための接続情報などが記載されています.そこでファイルの内容を確認しdashostからnodeagent1に変更されていることを確認してください.仮に変更されていない場合は手動で変更してください.

nodeagent1 > pwd
/export/home/appserv/nodeagents/nodeagent1/agent/config
nodeagent1 > grep das.host das.properties
agent.das.host=nodeagent1
nodeagent2 > pwd
/export/home/appserv/nodeagents/nodeagent2/agent/config
nodeagent2 > grep das.host das.properties
agent.das.host=nodeagent1

2010年2月5日 at 4:35 午後

GlassFish クラスタとクラスタインスタンス管理(作成、削除、起動、停止)

ここでは管理ツールを使用しクラスタの管理を行う方法について紹介します.

クラスタの作成

クラスタ構成を作成するためにはcreate-clusterコマンドを使用します.コマンド引数にクラスタ名を指定してクラスタを作成します.

asadmin create-cluster cluster1
コマンド create-cluster は正常に実行されました。

また,管理コンソールから左ペインの「クラスタ」を選択し右ペインの「新規…」ボタンを押すことによって作成することができます.

クラスタの作成

クラスタの作成

クラスタサーバインスタンスの作成

クラスタに所属するサーバインスタンスを作成するためには,create-instanceコマンドを実行します.コマンド引数にインスタンスを配置するノードエージェント名とクラスタ名を指定してインスタンスを作成します.

dashost > asadmin create-instance –nodeagent nodeagent1 –cluster cluster1 instance1
コマンド create-instance は正常に実行されました。
dashost > asadmin create-instance –nodeagent nodeagent2 –cluster cluster1 instance2
コマンド create-instance は正常に実行されました

また,クラスタに所属するサーバインスタンスは「クラスタ」作成のウィザードから「作成するサーバインスタンス(2)」のテーブルから,「新規…」ボタンを押すことによって作成することができます.この時ノードエージェントの選択コンボボックスからサーバインスタンスが稼働するノードエージェントを選択します.

クラスタインスタンスの作成

クラスタインスタンスの作成

クラスタの一覧表示

ドメイン内に存在するクラスタの一覧を表示するためにはlist-clustersコマンドを使用します.またコマンドを実行すると一覧表示の他クラスタの稼働状態も表示します.

dashost > asadmin list-clusters
cluster2 実行していません
cluster1 実行しています
コマンド list-clusters は正常に実行されました。

また,管理コンソールから左ペインの「クラスタ」を選択して確認できます.

クラスタの一覧表示

クラスタの一覧表示

クラスタの起動

クラスタの起動はstart-clusterコマンドを使用します.コマンド引数にクラスタ名を指定して起動します.

dashost > asadmin start-cluster cluster2
クラスタ化されたインスタンス instance3 の起動に成功しました。
クラスタ化されたインスタンス instance4 の起動に成功しました。
コマンド start-cluster は正常に実行されました。

また,管理コンソールから左ペインの「クラスタ」を選択し右ペイン中より対象のクラスタにチェックを付け「クラスタの起動」ボタンを押すことによって作成することができます.

クラスタの起動

クラスタの起動

クラスタの停止

クラスタの停止はstop-clusterコマンドを実行します.コマンド引数にクラスタ名を指定して停止します.

dashost > asadmin stop-cluster cluster1
クラスタ化されたインスタンス instance1 の停止に成功しました。
クラスタ化されたインスタンス instance2 の停止に成功しました。
コマンド は正常に実行されました。

また,管理コンソールから左ペインの「クラスタ」を選択し右ペイン中より対象のクラスタにチェックを付け「クラスタの停止」ボタンを押すことによってクラスタを停止することができます.

クラスタの停止

クラスタの停止

クラスタの削除

クラスタを削除するためには,クラスタに所属している全てのインスタンスを停止/削除した後に削除を行います.
まず,クラスタの一覧とクラスタに所属するインスタンスを表示します.

dashost > asadmin list-clusters
cluster2 実行していません
cluster1 実行していません
コマンド list-clusters は正常に実行されました。
dashost > asadmin list-instances
instance1 実行していません
instance2 実行していません
instance3 実行していません
instance4 実行していません
コマンド list-instances は正常に実行されました。

次に,cluster1に属するinstance1,instance2を削除します.

dashost > asadmin delete-instance instance1
コマンド delete-instance は正常に実行されました。
dashost > asadmin delete-instance instance2
コマンド delete-instance は正常に実行されました。

最後にcluster1を削除します.

dashost > asadmin delete-cluster cluster1
コマンド delete-cluster は正常に実行されました。

また,管理コンソールから左ペインの「クラスタ」を選択し右ペイン中より対象のクラスタにチェックを付け「削除」ボタンを押すことによってクラスタを削除することができます.管理コンソールから削除を実行すると,クラスタ内に属する全てのインスタンスも同時に削除する事ができます.

クラスタの削除

クラスタの削除

2010年2月5日 at 3:31 午後

GlassFish スタンドアローンインスタンス管理(作成、削除、起動、停止)

スタンドアローンサーバインスタンスの作成

スタンドアローンサーバインスタンスを追加するためにはcreate-instanceコマンドを実行します.サーバインスタンスが稼働するノードエージェント名を指定して作成します.複数のインスタンスを作成する際は,必ずノードエージェントの指定が必要です.そこで,開発者プロファイルを利用している場合,もしくはノードエージェントを作成していない場合は,新たにサーバインスタンスを作成することができませんので,ご注意ください.

dashost > asadmin create-instance –nodeagent nodeagent1 instance1
コマンド create-instance は正常に実行されました


上記のようにサーバインスタンスで使用する各種ポート番号を明示的に指定せずにサーバインスタンスを作成する場合は,極力既存の全てのサーバインスタンスを起動している状態で作成作業を行ってください.ポート番号を指定せずに実行した場合,コマンド内部で自動的に未使用のポート番号を探し出して新規インスタンス用に割り当てます.他のサーバインスタンスが停止している状態でコマンドを実行した場合,他で使用しているポート番号と競合する可能性があり,正常にサーバインスタンスが起動できない場合があります.作成するインスタンスで使用する各種ポート番号を指定したい場合は,下記のように–systempropertiesを付加して各種ポート番号を指定する事もできます.

dashost > asadmin create-instance –user clusterAdmin –host sw-103 –port 5048 –nodeagent nodeagent1 –systemproperties HTTP_LISTENER_PORT=5180:HTTP_SSL_LISTENER_PORT=51443:IIOP_LISTENER_PORT=5138:IIOP_SSL_LISTENER_PORT=5137:IIOP_SSL_MUTUALAUTH_PORT=5139:JMX_SYSTEM_CONNECTOR_PORT=5140 instance1
コマンド create-instance は正常に実行されました。


また,管理コンソールから左ペインの「スタンドアロンインスタンス」を選択し右ペインの「新規…」ボタンを押すことによって新規インスタンスを追加することができます.

新規スタンドアローンインスタンスの追加

新規スタンドアローンインスタンスの追加

サーバインスタンスの一覧表示

サーバインスタンスの一覧を確認するためにはlist-instancesコマンドを使用します.コマンドを実行すると一覧表示の他インスタンスの稼働状態も表示します.

dashost > asadmin list-instances
instance1 実行しています
instance2 実行していません
コマンド list-instances は正常に実行されました。


また,管理コンソールから左ペインの「スタンドアロンインスタンス」を選択して確認できます.

インスタンスの一覧表示

インスタンスの一覧表示

サーバインスタンスの起動

サーバインスタンスの起動はstart-instanceコマンドを使用します.実行時にインスタンス名を指定して起動します.

dashost > asadmin start-instance instance2
コマンド start-instance は正常に実行されました。


また,管理コンソールから左ペインの「スタンドアロンインスタンス」を選択し右ペインの「起動」ボタンを押すことによってインスタンスを起動することができます.

サーバインスタンスの起動

サーバインスタンスの起動

もしくは,管理コンソールから左ペインから対象の「スタンドアロンインスタンス」を選択し右ペインの「インスタンスの起動」ボタンを押すことによってインスタンスを起動することができます.

サーバインスタンスの起動

サーバインスタンスの起動

サーバインスタンスの停止

サーバインスタンスの停止はstop-instanceコマンドを実行します.コマンド引数にインスタンス名を指定して停止します.

dashost > asadmin stop-instance instance1
コマンド stop-instance は正常に実行されました


また,管理コンソールから左ペインの「スタンドアロンインスタンス」を選択し右ペインの「停止」ボタンを押すことによってインスタンスを停止することができます.

サーバインスタンスの停止

サーバインスタンスの停止

もしくは,直接左ペインから対象の「スタンドアロンインスタンス」を選択して右ペインの「インスタンスの停止」ボタンを押すことによってインスタンスを停止することができます.

サーバインスタンスの停止

サーバインスタンスの停止

サーバインスタンスの削除

インスタンスの削除はdelete-instanceコマンドを実行します.コマンド引数にインスタンス名を指定して削除します.

dashost > asadmin delete-instance –user clusterAdmin –host sw-103 –port 5048 instance1
コマンド delete-instance は正常に実行されました。


また,管理コンソールから左ペインの「スタンドアロンインスタンス」を選択し右ペインの「削除」ボタンを押すことによってインスタンスを削除することができます.

サーバインスタンスの削除

サーバインスタンスの削除

2010年2月5日 at 2:40 午後

GlassFish ノードエージェント管理(作成、削除、起動、停止、ログ設定)

ノードエージェントの作成

ノードエージェントを作成するためには,ドメイン管理サーバ上で create-node-agent-config コマンドを実行しノードエージェント(参照情報のみ)を作成します.下記の例では2つのノードエージェントを作成しています.

dashost > asadmin create-node-agent-config nodeagent1
コマンド create-node-agent-config は正常に実行されました。
dashost > asadmin create-node-agent-config nodeagent2
コマンド create-node-agent-config は正常に実行されました


次にノードエージェントを稼働させるマシン上でそれぞれ create-node-agent コマンドを実行します.この時ドメイン管理サーバ上で指定したノードエージェント名と同一のエージェント名を指定する必要があります.

nodeagent1 > asadmin create-node-agent –user clusterAdmin –host dashost –port 5048 –savemasterpassword=true nodeagent1
コマンド create-node-agent は正常に実行されました。

nodeagent2 > asadmin create-node-agent –user clusterAdmin –host dashost –port 5048 –savemasterpassword=true nodeagent2
コマンド create-node-agent は正常に実行されました。


便宜上ノードエージェントを稼働させるマシン上で create-node-agent コマンドを実行すると,「参照情報」と,「ノードエージェントの実体」の両方が同時に生成されます.しかし内部的には参照情報の設定とノードエージェントの実体は別々に作成されていることに注意してください.
このように,参照情報とノードエージェントの作成が別々に行われる理由は,ノードエージェントをオフラインで管理ができるようにするためです.例えば,実体であるノードエージェントが停止状態でも,ドメイン管理サーバ上で管理しているノードエージェントの参照情報に対してインスタンスを追加することができます.そしてノードエージェントの実体を起動した時にドメイン管理サーバで保持するノードエージェントの参照(設定)情報と同期をとりインスタンスの実体が生成されます.
管理コンソールからは,ドメイン管理サーバで管理する参照情報のみ作成することができます.参照情報を作成した後,別途ノードエージェントが稼働するマシン上でノードエージェントの実体を作成してください.
管理コンソールの左ペインから「ノードエージェント」を選択し、右ペインより「新規…」ボタンを押すことによってノードエージェントの参照情報を作成することができます.

ノードエージェントの参照情報の作成

ノードエージェントの参照情報の作成

ノードエージェントの一覧表示

ノードエージェントの一覧を確認するためにはlist-node-agentsコマンドを使用します.コマンドを実行すると一覧表示の他ノードエージェントの稼働状態も表示します.

dashost > asadmin list-node-agents
nodeagent1 実行しています
nodeagent2 実行していません
コマンド list-node-agents は正常に実行されました。


また,管理コンソールからは,左ペインの「ノードエージェント」を選択して確認できます.

ノードエージェントの一覧表示

ノードエージェントの一覧表示

ノードエージェントの起動

ノードエージェントを起動するためには,ノードエージェントが稼働するマシン上で start-node-agent コマンドを実行します.

nodeagent1 > asadmin start-node-agent nodeagent1
出力を /export/home/appserv/nodeagents/nodeagent1/agent/logs/server.log にリダイレクトしていますアプリケーション出力を /export/home/appserv/nodeagents/nodeagent1/agent/logs/server.log にリダイレクトします
コマンド start-node-agent は正常に実行されました。

ノードエージェントの停止

ノードエージェントを停止するためには,ノードエージェントが稼働するマシン上で stop-node-agent コマンドを実行します.

nodeagent1 > asadmin stop-node-agent nodeagent1
コマンド stop-node-agent は正常に実行されました

ノードエージェントのログ設定

ノードエージェントのログに関する設定を行う前に,現在設定されているログの設定情報を get コマンドを実行して確認します.

dashost > asadmin get “domain.node-agent.nodeagent1.log-service.*”
domain.node-agent.nodeagent1.log-service.alarms = false
domain.node-agent.nodeagent1.log-service.file = ${com.sun.aas.instanceRoot}/logs/server.log
domain.node-agent.nodeagent1.log-service.log-filter =
domain.node-agent.nodeagent1.log-service.log-handler =
domain.node-agent.nodeagent1.log-service.log-rotation-limit-in-bytes = 500000
domain.node-agent.nodeagent1.log-service.log-rotation-timelimit-in-minutes = 0
domain.node-agent.nodeagent1.log-service.log-to-console = false
domain.node-agent.nodeagent1.log-service.retain-error-statistics-for-hours = 5
domain.node-agent.nodeagent1.log-service.use-system-logging = false


ここで例えば、set コマンドを実行しログローテーションのファイルサイズを 500Kb から 1Mb に変更してみます。
下記を実行してください.

dashost > asadmin set domain.node-agent.nodeagent1.log-service.log-rotation-limit-in-bytes=1000000
domain.node-agent.nodeagent1.log-service.log-rotation-limit-in-bytes = 1000000


上記の設定内容を確認するため get コマンドを実行します.

dashost > asadmin get domain.node-agent.nodeagent1.log-service.log-rotation-limit-in-bytes
domain.node-agent.nodeagent1.log-service.log-rotation-limit-in-bytes = 1000000


また,ノードエージェントに関する各種設定は,管理コンソールからも行えます.

ノードエージェントの各種設定

ノードエージェントの各種設定

ノードエージェントの削除

ノードエージェントを削除する前に,ノードエージェント上で稼働している全てのインスタンス,全てのアプリケーションを停止していることを確認してください.ノードエージェント上にリソースが残っている場合,ノードエージェントの削除に失敗します.
全てのリソースを削除した後に,ノードエージェントが稼働するマシン上で delete-node-agent コマンドを実行し実体を削除します.下記のコマンドを実行するとファイルやディレクトリを全て削除します.

nodeagent1 > asadmin delete-node-agent nodeagent1
コマンド delete-node-agent は正常に実行されました。


次に、delete-node-agent-configコマンドを実行し,ドメイン管理サーバ上で保持するノードエージェントの参照情報を削除します.

dashost > asadmin delete-node-agent-config –user clusterAdmin –host dashost –port 5048 nodeagent1
コマンド delete-node-agent-config は正常に実行されました。


ノードエージェントの参照情報は管理コンソールからも削除できます.管理コンソールの左ペインから「ノードエージェント」を選択し,右ペインより削除対象のノードエージェントにチェックを付け,削除ボタンを押す事により削除できます.

ノードエージェントの参照情報の削除

2010年2月5日 at 1:35 午後

GlassFish サーバインスタンス

サーバインスタンス

サーバインスタンスはエンドユーザ向けにサービスを提供するJava EE 5の 仕様に完全準拠したJava EEのプロセスです.1つのドメ イン内には複数のサーバインスタンスを作成する事ができます.また物理的にハードウェアが異なる環境上でインスタンスを作成する事もできます.ドメイン内 で複数のサーバインスタンスを作成する場合,それぞれのサーバインスタンスを識別するために,異なる名前を設定する必要があります.

サーバインスタンスは下記の2種類のいずれかの方法で作成できます.

  1. クラスタに所属しないインスタンス
  2. クラスタに所属しないインスタンス

クラスタについては別途,詳細に説明しますが,複数のサーバインスタンスを作成する環境では,クラスタへの所属の有無に応じて,アプリケーションの配備やリソース設定等の管理方法が大幅に異なってきます.具体的に はクラスタに属する全てのインスタンスは,クラスタに対する設定情報が各インスタンスに完全に引き継がれるため,たった1度のクラスタに対する操作で全て のインスタンスに対して反影されます.このようにクラスタに所属するインスタンスは,同じアプリケーションを負荷分散や高化用性を実現するために複数台の マシンで実行したいような場合に有効です.一方,クラスタに所属しないインスタンスは,各インスタンス間で設定情報を独立に設定するため,リソース設定を 個別に管理したい場合,単一のアプリケーションを別のJava VMプ ロセスで稼働させたい場合,もしくは異なるアプリケーションをそれぞれ別のJava VMの プロセスで稼働させたいような場合に有効です.

サーバインスタンスのアーキテクチャを「図5:サーバインスタンスのアーキテク チャ」に示します.のようにプロセス内にEJBコンテナやWebコンテナ等を含み,各種クライアントからの要求を受け 付けます.

図 5:サーバインスタンスのアー キテクチャ

サーバインスタンス単位,もしくはクラスタ構成単位に「図6: インスタンス毎の設定項目」に示す項目の設定が可能です.

図 6:インスタンス毎の設定項目

2010年2月5日 at 10:01 午前


Java Champion & Evangelist

Translate

ご注意

このエントリは個人の見解であり、所属する会社の公式見解ではありません

カレンダー

2010年2月
1234567
891011121314
15161718192021
22232425262728

カテゴリー

Twitter

  • RT @satyanadella: GitHub Copilot is the first at-scale developer tool, and today we're going further—bringing the power of Copilot past the… 9 hours ago
  • RT @seanjmullan: JDK 20 was released yesterday! Highlights of this release include further improvements that strengthen the default securit… 15 hours ago
  • RT @mkheck: Can’t get enough Spring content? Neither can I! That’s why I'm presenting "Build Better, Deploy Faster: Spring Boot + Spring C… 15 hours ago
  • RT @yuhattor: やばいのきました これからはエディターの外でも開発者の効率を爆上げします。まずはウェイトリスト登録! GitHub Copilot X👇 ●GPT4を採用 ●チャット/音声サポートでエディタでもChatGPTに似た体験 ●プルリクエストの文章自動生… 1 day ago
  • RT @github: GitHub Copilot is already helping developers code faster in their IDEs. But what’s next? Our answer is GitHub Copilot X. It’s… 1 day ago

clustermap

ブログ統計情報

  • 1,263,278 hits

RSSフィード

アーカイブ