GlassFish ドメイン管理(作成、削除、起動、停止)
ドメインの作成
ドメインを作 成するためには create-domain コマンドを 実行して作成します.下記にプロファイルごとのドメイン作成方法を示します.
開発者 用プロファイルを使用したドメインの作成方法
デフォルトで 作成されるドメイン(domain1)以外に開発者用プロファイ ルを利用した新規ドメイン(devDomain)を作成する方法を下記 に示します.
| dashost > asadmin create-domain –profile developer –adminport 14848 –instanceport 10080 –savemasterpassword=true –savelogin=true devDomain Admin のポート 14848 を使用しています。 HTTP Instance のポート 10080 を使用しています。 JMS のデフォルトポート 7676 を使用しています。 IIOP のデフォルトポート 3700 を使用しています。 HTTP_SSL のデフォルトポート 8181 を使用しています。 IIOP_SSL のデフォルトポート 3820 を使用しています。 IIOP_MUTUALAUTH のデフォルトポート 3920 を使用しています。 JMX_ADMIN のデフォルトポート 8686 を使用しています。 コマンド行または環境で の指定どおりにプロファイル developer を使用してドメインを作成しています。 指定されたロケール [ja_JP] のファイルが [/sun/glassfish-v2.1.1/lib/install/templates/locales/ja_JP/index.html] に見つかりませんでした。デフォルト (en_US) の index.html を使用します。 使用するセキュリティーストア: JKS ドメイン devDomain が作成されました。 このドメイン [devDomain] の管理ユーザー名 [devAdmin] に関連するログイン情報が [/export/home/appserv/.asadminpass] に正常に格納されました。 このファイルが保護されたままであることを確認します。このファイルに格納された情報 は、このドメインを管理するために asadmin コマンドによって使用されます dashost > cat .asadminpass # Do not edit this file by hand. Use “asadmin login” command instead. asadmin://devAdmin@localhost:14848 YWRtaW5hZG1pbg== |
クラスタプロファイルを使用したドメインの作成方法
クラスタプロファイルを使用したドメインの作成方法を下記に示します.下記の例では,ベースとなるポート番号(portbase)を指定して実行します.このオプションは 指定したポート番号を基に自動的に各種ポート番号を割り当てドメインを作成します.ポート番号の把握が容易になるため,複数ドメインを構築する場合などに 適しています.
| dashost > asadmin create-domain –user clusterAdmin –profile cluster –portbase 5000 –savemasterpassword=true –savelogin=true clusterDomain (省略) ドメイン clusterDomain が作成されました。 |
上記はいずれも —savemasterpassword,–savelogin を有効にして設定を行いました.これらのオプションを指定してドメインを作成すると, 管理者のパスワード,管理者のパスワードがローカルファイルシステム(.asadminpass/master-password)に保存され,次回コマン ド実行時に管理者パスワードの入力を省略できます。一方 –savemasterpassword,–savelogin を指定せずに作成したドメインは asadmin コマンドの実行時に毎回管理者パスワードを問い合わせされます.
不正使用を防ぎたい場合は,毎回パスワードの入力を求めるように–savemasterpassword,–saveloginの 設定を無効にし,環境変数も設定しないようにしてください.
ドメインの一覧表示
作成されているドメインの一覧を表示するためにはlist-domainsコ マンドを実行します.コマンドを実行すると一覧表示以外にドメインの稼働状態も確認できます.
| dashost > asadmin list-domains devDomain 実行していません clusterDomain 実行しています コマンド list-domains は正常に実行されました。 |
ドメインとドメイン管理サーバインスタンスの起動
ドメイン管理サーバを起動するためには,start-domainコマンドを実行します.
| dashost > 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://dashost:5086/jmxrmi] に接続できます。 ドメインは少なくとも次のポートで接続を待機しています: [5080 5081 5048 5037 5038 5039 5086 ]。 ドメインはアプリケーションサーバークラスタおよびその他のスタンドアロンインスタン スをサポートします。 |
ドメインとドメイン管理サーバインスタンスの停止
ドメイン管理サーバを停止するためには,stop-domainコマンドを実行します.
| dashost > asadmin stop-domain clusterDomain ドメイン clusterDomain が停止しました |
開発者プロファイルを使用して作成したドメインの場合,管理コンソールの左ペインから「アプリケーションサーバ」を選択し右ペインの「一般」タブか ら「インスタンスの停止」ボタンを押すことによってドメイン管理サーバのインスタンスを停止する事ができます.

図 7:開発者プロファイルを利用 したドメイン管理サーバの停止方法
クラスタプロファイルを使用して作成したドメインの場合,管理コンソールから左ペインの「スタンドアロンインスタンス」を選択し右ペインの「一般」 タブから「インスタンスの停止」ボタンを押すことによってドメイン管理サーバのインスタンスを停止する事ができます.

図 8:クラスタプロファイルを利 用したドメイン管理サーバの停止方法
クラスタプロファイルへの変更方法
開発者プロファイルで作成したドメインをクラスタプロファイルに変更することができます.クラスタプロファイルへの変更は、asadminコマンドは利用できず,GUIの管理コンソールを使用した場合のみ可能です.
クラスタプロファイルへ変更するためには,管理コンソールの左ペインから「アプリケーションサーバ」を選択し右ペインの「一般」タブから「クラスタ サポートを追加…」ボタンを押すことによってクラスタ 構成を組むことのできるクラスタプロファイルへ変更できます.

図 9:クラスタプロファイルへの 変更方法
ドメインの削除
ドメインを削除する前に,ドメインが管理する全てのノードエージェント,全てのインスタンス,全てのアプリケーションが停止/削除されていることを確認して下さい.ドメイン上の各種リ ソースが残っている場合,削除に失敗します.
ドメインを削除するためには,delete-domainコマンドを実行します.
| dashost > asadmin delete-domain devDomai |
GlassFish ドメインとドメイン管理サーバ
ドメインとは
「ドメイン」とは,アプリケーションサーバの管理を行う上で必要なプロセスや,設定情報等をグループ化した管理用の構成単位です. ドメインは「ドメイン管理サーバ」,「サーバインスタンス」,「ノードエージェント」,「各種リソース(JDBC, JMS, JNDI)」等のさまざまなコンポー ネントや設定情報から構成されています.GlassFishをインストールすると, デフォルトで一つのドメイン(domain1)を生成しますが,必要に応 じて複数のドメインを作成することができます.管理を行うためには,サーバ管理者は,管理者ユーザ名,管理者パスワード,証明書データベースの管理用パス ワードを入力したのち管理を行います.複数のドメインを作成する場合,それぞれのドメインに対して個別に管理者ユーザ名,管理者パスワード,認証用データ ベース管理用パスワードを設定する必要があります.
複数のドメインの作成は,ASP (Application Service Provide) サービスの提供や SaaS(Software as a Service), またクラウドといったサービスにおいて,サービス提供単位,組織単位毎に独立して管理を行いたい場合等に適しています.各ドメイン間を独立して管理でき各 種設定情報はドメイン間では共有されないためこのような環境で安全に利用できます。

図 1:複数ドメインの構成例
| 補足:GlassFish v2.1 では 単一ドメインにおいて,単一のサーバ管理者が必要でしたが,GlassFish v3で は単一ドメインに対して,複数の管理者を設定できるようになります.これにより各管理者に対してあらかじめ権限を設定しておく事で複数の管理者で安心して 管理ができるようになります. |
ドメイン管理サーバ
ドメイン管理サーバは,ドメインを管理するための管理機能アプリケーションを含んだ,Java EE 5仕 様完全準拠のサーバインスタンス(※1)です.このドメイン管理サーバは,GlassFishのインストール時に作成される唯一のサー バインスタンスで,Java EEアプリケーションを配備して 稼働させる事もできるため,デフォルトサーバと呼ぶこともあります.通常開発時はこのデフォルトサーバのインスタンスに対してアプリケーションを配備した り,デバッグ等を行います.また本番環境において,複数のサーバインスタンスでサービスを提供している場合,一度このデフォルトサーバに対してアプリケー ションを配備し,動作確認後問題がない場合に本番環境を有効にするといった運用にも使うことができます(※2).
このドメイン管理サーバは,サーバ管理者の認証を行った後,ドメイン内のすべての管理,たとえばアプリケーションの配備やリソース設定,サーバイン スタンスの起動/停止等といった管理機能を提供します.
また,物理的に異なるハードウェア上のリソースも管理できます.
各ドメインは必ず一つのドメイン管理サーバのインスタンスを持ち,各ドメイン管理サーバには任意のネットワークポート番号を設定します.基本的に(※3)全ての管理操作はドメイン管理サーバが稼働している状態で行 いますので,ドメイン管理サーバが稼働していない状態では各種設定変更を行うことはできません.
※1 サーバインスタンスの詳細は別途紹介します.
※2 配備済みのアプリケーション設定で「ターゲットの管理」から利用可能 対象のインスタンス/クラスタを設定できます.
※3 一部の管理操作(インスタンスの起動,停止等)はドメイン管理サーバ が起動していない状態でも実行できます.

開発者ドメイン
図 2:開発時におけるドメインと ドメイン管理サーバの構成
サーバ管理者がドメインの管理を行うために,GlassFishで はいくつかの管理ツールを容易しています。代表的な管理操作はコマンドラインツール,もしくはWebベー スのGUI管理コンソールを使用して行います. また,サーバ管理者が独自に管理機能を拡張したい場合,AMX (AppServer Management Extensions)(※4)と呼ぶJMX MBeansベー スの管理拡張用APIを提供していますので,AMX APIを実装した独自管理機能を通じて管理すること もできます.
※4 AMX (Appserver Management Extensions)
https://glassfish.dev.java.net/javaee5/amx/
| #asadmin help #asadmin command_name [–help | ?] |
asadminで指定可能なコマンド一覧はhelpコマンドを実行することで確認できます.また、各種 コマンドの引数の詳細は,コマンド入力後 –help を付加して実行する事で確認で きます。

図 3:管理コンソールの表示例
ドメイン管理サーバ導入の利点は,セキュアな環境を構築したい場合に便利です.たとえば,ドメインを管理するための管理サービスとエンドユーザに対 して提供するサービスを独立して運用/管理ができるため,安心して管理を行うこ とができるようになります.

図 4:セキュアなサーバ管理が可 能なドメイン構成例
GlassFish プロファイル
今日は GlassFish 管理の基本概念について紹介します.まず,GlassFishを管理する上で,プロファイルと呼ばれる種類が存在する事を理解してください。また選択するプロファイルに応じて管理できる内容が異なることにも注意してください.GlassFish v2.x で提供される各プロファイルの差異を「表1:各プロファイルで使用できる機能」に記載します.種類としては「開発者プロファイル」,「クラスタプロファイル」,「エンタープライズプロファイル」の3種類が存在しています.この内で「エンタープライズプロファイル」は,オープンソースコミュニティ上のサイトでは提供されず,Sunから提供される製品「Sun GlassFish Enterprise Server v2.1.1 with HADB」を入手した場合のみ利用可能です.この製品以外は,「開発者プロファイル」もしくは「クラスタプロファイル」の何れかを利用する事ができます.たとえばインストール後も必要に応じて,「開発者プロファイル」から「クラスタプロファイル」へアップグレードすることも可能です.
| 製品名/機能差異 | 開発者プロファイル | クラスタプロファイル | エンタープライズプロファイル |
| セキュリティストア | JKS(Java Key Store) 証明書データベース:keystore.jks,cacerts.jks 証明書データベースの管理にkeytoolを使用 |
JKS(Java Key Store) 証明書(鍵)データベース:keystore.jks,cacerts.jks 証明書データベースの管理にkeytoolを使用 |
NSS
(Network Security Services) |
| 高速起動 | 可能 | 不可 | 不可 |
| クラスタ化 | 不可 | 可能 | 可能 |
| セキュリティマネージャ | 無効 | 有効 | 有効 |
| セッションレプリケーション | 不可 | インメモリレプリケーション | HADB |
| 負荷分散 | 不可 | 可能 | 可能 |
| ノードエージェント | 不可 | 可能 | 可能 |
| オープンソース 版の入手先 | https://glassfish.dev.java.net/
GlassFish v2.1.1 設定時setup.xmlを使用 |
https://glassfish.dev.java.net/
GlassFish v2.1.1 設定時setup-cluster.xmlを使用 |
入手不可(商用版のみ) |
| 製品版の入手先 | http://www.sun.com/appserver
Sun GlassFish Enterprise Server v2.1.1 |
http://www.sun.com/appserver
Sun GlassFish Enterprise Server v2.1.1 |
http://www.sun.com/appserver
Sun GlassFish Enterprise Server v2.1.1 with HADB |
表 1:各プロファイルで使用できる機能
システムを構築する環境で,どのプロファイルを選択すればよいかは下記の基準に従って選択して下さい.
- 開発者プロファイル:このプロファイルは開発環境に適しています.再起動等が頻繁に発生する開発環境においては高速起動が有効になっていますので統合開発環境との連携に有効です.
- クラスタプロファイル:このプロフィルは複数台のハードウェアでサービスを提供する,クラスタ環境の構築時に有効です.セッション高可用性の実現にはインメモリレプリケーションを使用するため,HADBの利用に比べパフォーマンスがよく,かんたんにクラスタ環境の構築,高可用性環境を構築できます.
- エンタープライズプロファイル:ミッションクリティカルな環境においては,HADBは最適です.HADBは99.999%の高可用性を実現するために専用のデータベース内にセッション情報を格納します.HADB内で冗長構成が取られているため,インメモリレプリケーションの構成に比べより安心して利用することができます.
GlassFish v3.x に関する補足:
GlassFIsh v3 からは上記のプロファイルの概念が若干変わってきます.GlassFish v3 では Java EE 6 で提供される Web Profile と Enterprise Platform 版のいずれかを入手することができます.GlassFish v2.1 でいう所のクラスタ機能は GlassFish v3.x の最初のリリースである GlassFish v3.0 では提供されず、GlassFish v3.1 以降で利用可能になる予定です.Web Profile, Enterprise Platform で提供される機能一覧を下記に示します.
| Java EE Standard | Java Specification Request (JSR) | Sun GlassFish Enterprise Server v3 Full Platform Profile | Sun GlassFish Enterprise Server v3 Web Profile |
|---|---|---|---|
| Java Platform, Enterprise Edition 6 | JSR 316 | 可能 | 可能 |
| Java Servlet Technology 3.0 | JSR 315 | 可能 | 可能 |
| JavaServer Pages 2.2 | JSR 245 | 可能 | 可能 |
| Expression Language 2.2 | JSR 245 | 可能 | 可能 |
| Debugging Support for Other Languages 1.0 | JSR 45 | 可能 | 可能 |
| Standard Tag Library for JavaServer Pages 1.2 | JSR 52 | 可能 | 可能 |
| JavaServer Faces 2.0 | JSR 314 | 可能 | 可能 |
| Common Annotations for the Java Platform 1.1 | JSR 250 | 可能 | 可能 |
| Java Transaction API 1.1 | JSR 907 | 可能 | 可能 |
| Java Persistence API 2.0 | JSR 317 | 可能 | 可能 |
| Enterprise JavaBeans 3.1 Lite | JSR 318 | 可能 | 可能 |
| Managed Beans 1.0 | JSR 316 | 可能 | 可能 |
| Interceptors 1.1 | JSR 318 | 可能 | 可能 |
| Dependency Injection for Java 1.0 | JSR 330 | 可能 | 可能 |
| Enterprise JavaBeans 3.1 Full API | JSR 318 | 可能 | 可能 |
| Contexts and Dependency Injection for Java EE 1.0 | JSR 299 | 可能 | 可能 |
| Java API for RESTful Web Service (JAX-RS) 1.1 | JSR 311 | 可能 | 可能 |
| Bean Validation 1.0 | JSR 303 | 可能 | 可能 |
| Java EE Connector Architecture 1.6 | JSR 322 | 可能 | 不可 |
| Java API for XML-Based Web Services (JAX-WS) 2.2 | JSR 224 | 可能 | 不可 |
| Java Architecture for XML Binding (JAXB) 2.2 | JSR 222 | 可能 | 不可 |
| Implementing Enterprise Web Services 1.3 | JSR 109 | 可能 | 不可 |
| Web Services Metadata for the Java Platform 2.1 | JSR 181 | 可能 | 不可 |
| Java Message Service API 1.1 | JSR 914 | 可能 | 不可 |
| JavaMail 1.4 | JSR 919 | 可能 | 不可 |
| Java Authorization Contract for Containers 1.4 | JSR 115 | 可能 | 不可 |
| Java Authentication Service Provider Interface for Containers 1.1 | JSR 196 | 可能 | 不可 |
| Java EE Application Deployment 1.2 | JSR 88 | 可能 | 不可 |
| J2EE Management 1.1 | JSR 77 | 可能 | 不可 |
| Java API for XML-Based Remote Procedure Calls (JAX-RPC) 1.1 | JSR 101 | 可能 | 不可 |
| Java API for XML-Based Registries (JAXR) 1.0 | JSR 93 | 可能 | 不可 |
GlassFish ドメイン管理の基本
さて、ブログサイトを移動して初エントリですが、実は昨年
GlassFish に関する本を出版するかもしれないということで、
出版用に書きためた物があります。それを、そのまま削除するのも
もったいないので、こちらに数回に分けて投稿する事にしました。
まず、はじめに GlassFish のドメイン管理を行う前に事前に準備します。
-
ホスト名とインストール場所について
-
アプリケーションサーバ実行ユーザの作成
-
管理操作を容易にする環境変数の設定
-
管理ツールの紹介
-
管理コンソール
GUIの管理コンソールを使用してGlassFishの管理を行うことができます.管理コンソールは洗練されたデザインであるため,初めてGlassFishを扱うサーバ管理者も感覚的に管理操作ができるため非常に便利です.

-
asadminコマンドユーティリティ
asadmin コマンドユーティリティは,GUIベースの管理コンソールが提供する管理機能のほとんどを行うことができる便利なユーティリティコマンドです.このコマンドを把握するとスクリプトを書いて管理の自動化を行ったり,ブラウザを開かずに管理ができるためちょっとした管理にもとても便利です.asadminユーティリティの使用方法は,–helpを付加して確認します.実行すると利用可能なコマンドの一覧を表示します.
dashost > asadmin –help
Administration Commands help(1)
NAME
help – displays the asadmin utility commands
SYNOPSIS
help [command_name]
command_name [–help | -?]さらに利用可能なコマンド一覧からコマンドを選択し,引数に–help をつけて実行して下さい.実行するとコマンドの詳細なマニュアルが表示されます.
dashost > asadmin create-domain –help
Administration Commands create-domain (1)
NAME
create-domain – creates a domain with the given name
SYNOPSIS
create-domain [–user user] [–passwordfile passwordfile]
[(–adminport port_number | –portbase portbase)]
[(–profile developer | cluster | enterprise ] –template domain_template)]
[–domaindir domain_directory/domains]
[–instanceport port_number] [–savemasterpassword=false]
[–domainproperties (name=value)[:name=value]*
]
[–savelogin=false] [–terse=false]
[–echo=false] [–interactive=true]
domain_nameまた,asadminユーティリティのコマンドの中でもget,setコマンドを使用すると現在設定されている内容の参照や更新ができます.下記の例ではアスタリスク(*)を指定し全ての設定情報を参照しています.また特定のプロパティに対してsetコマンドを実行し設定変更を行うことができます.
dashost > asadmin get “*”
dashost > asadmin set server-config.http-service.http-listener.admin-listener.server-name=dashost
server-config.http-service.http-listener.admin-listener.server-name = dashost
dashost > asadmin get server-config.http-service.http-listener.admin-listener.server-name
server-config.http-service.http-listener.admin-listener.server-name = dashost -
以降で紹介するホスト名は下記の通りです.それぞれのホストで実行するコマンドを区別するため,コマンド実行時はコマンドプロンプトを付加します.たとえば dashost > と記載されたコマンドはドメイン管理サーバ上で実行していることを意味します.
| 役割 | ホスト名 | コマンドプロンプト |
| ドメイン管理サーバ | dasohst.japan.sun.com | dashost > |
| ノードエージェント | nodeagent1.japan.sun.com | nodeagent1 > |
| ノードエージェント | nodeagent2.japan.sun.com | nodeagent2 > |
| 認証局(CA)サーバ | ca-admin.sun.com | ca-server > |
ドメイン管理サーバ,ノードエージェントはそれぞれ下記のディレクトリにインストールします.
GlassFish のインストールは root 権限で行い,インストールしたライブラリ等は全て root 権限のままにします.
またドメインの実行や管理などは全て一般ユーザ (appserv) で行います.
| /sun/glassfish-v2.1.1 |
認証局(CA)サーバはOpenSSL/0.9.8kを利用していますが,紙面の都合上認証局サーバの構築方法は省略します.
ドメイン管理サーバと全てのノードエージェント上で実行ユーザとグループを作成します。
| # groupadd -g 300 appserv # useradd -u 300 -g appserv -d /export/home/appserv -s /bin/tcsh -m appserv 64 ブロック |
次に,アプリケーションサーバのデフォルトのドメインディレクトリパスを変更します.この変数を変更すると全てのドメイン管理は指定したディレクトリ配下で行われるようになります.ここで指定したディレクトリは実行ユーザ,実行グループで読み書きができるディレクトリでなければなりません.
| # vi /sun/glassfish-v2.1.1/config/asenv.conf AS_DEF_DOMAINS_PATH=”/export/home/appserv/domains” |
上記で指定したディレクトリがない場合は作成してください.
| dashost >cd /export/home/appserv dashost > mkdir domains dashost > ls -l 合計 2 drwxr-xr-x 2 appserv appserv 512 12 月 2日 20:48 domains |
あらかじめ環境変数に,管理者ユーザ名,パスワードなどを設定しておくことでコマンド入力引数を省略できます.下記の設定をドメイン管理サーバ,ノードエージェントの全てで設定してください.
sh 用環境変数の設定例
| PATH=/sun/glassfish-v2.1.1/bin JAVA_HOME=/usr/jdk/jdk1.6.0_17 AS_HOME=/sun/glassfish-v2.1.1 AS_ADMIN_USER=clusterAdmin AS_ADMIN_PASSWORDFILE=~/.passwordfileAS_ADMIN_HOST=dashost.japan.sun.com AS_ADMIN_PORT=5048 |
csh 用環境変数の設定例
| set path=(/sun/glassfish-v2.1.1/bin $path) setenv JAVA_HOME /usr/jdk/jdk1.6.0_17 setenv AS_HOME /sun/glassfish-v2.1.1 setenv AS_ADMIN_USER clusterAdmin setenv AS_ADMIN_PASSWORDFILE ~/.passwordfile setenv AS_ADMIN_HOST dashost.japan.sun.com setenv AS_ADMIN_PORT 5048 |
AS_ADMIN_PASSWORDFILE で指定するパスワードファイルは任意の場所に置くことができます.パスワードファイルには高い機密性を要する情報が含まれるため,ファイルを隠しファイルにしたり,パーミッションを読み込み可能モードにするなどして管理に十分注意してください.
パスワードファイル中に記載する AS_ADMIN_PASSWORD は管理サーバにログインする際に使用するパスワードを指定します。また AS_ADMIN_MASTERPASSWORD には SSL のサーバ証明書や認証局証明書を扱う,証明書データベースを操作するために必要なパスワードを指定します.GlassFish はドメインを作成時,自動的で設定ディレクトリ配下に自己署名証明書(ニックネーム:s1as)を作成します.証明書データベースを操作する際にこのパスワードが必要になります.
~/.passwordfile の内容
| AS_ADMIN_PASSWORD=adminadmin AS_ADMIN_MASTERPASSWORD=changeit |
ニュース記事一覧
ここ数日のニュース記事一覧です。
NikkeiNet:
米オラクル、サンの買収手続きを完了
ITpro 情報システム:
「[速報]「1社ですべてを提供できるのは当社だけ」、サン統合戦略発表会で
オラクル社長が断言」
ITpro 情報システム:
「[続報]「全スタックを提供し大きな価値をもたらす」オラクルのエリソンCEO」
ITmedia エンタープライズ:
「Sun統合の向こうに「うまい」「はやい」「やすい」はあるのか?」
@IT:
「オラクルがサン買収を完了、『業界標準のシステムでIBMを再現する』」
@IT:
「Javaは? MySQLは? 買収完了でサンの事業はどうなる」
COMPUTERWORLD.jp:
「オラクル幹部、サン製品のサポートに意欲 不景気でも好調なサポート事業の
拡大を目指す」
マイコミジャーナル エンタープライズ:
「Sunの墓標にたたずむDukeとTuxが意味するものは…
– ゴスリング氏のブログ」
CNET Japan 経営一般:
「オラクル、サンの買収完了を発表」
ZDNet Japan:
「オラクル、サンの買収完了を発表」
YOMIURI ONLINE CNETニュース:
「オラクル、サンの買収完了を発表」
ITmedia News:
「Oracle、Sunの買収完了を発表」
EnterpriseWatch:
「米oracle、米Sunの買収を完了」
SOURCEFORGE.JP:
「米OracleがSun買収を完了、OpenOffice.orgは独立事業部に」
The Wall Street Journal 日本語版:
「米オラクル、研究開発費15億ドル増額へ」
ITpro:
サン共同創設者S・マクニーリ氏、従業員向けメッセージで別れを告げる
REUTERS:
「米オラクル、販売・技術部門で2000人の雇用を計画─CEO=WSJ」
CNET Japan 経営一般:
「サン共同創設者S・マクニーリ氏、従業員向けメッセージで別れを告げる」
ZDNet Japan:
「サン共同創設者S・マクニーリ氏、従業員向けメッセージで別れを告げる」
YOMIURI ONLINE CNETニュース:
「サン共同創設者S・マクニーリ氏、従業員向けメッセージで別れを告げる」
マイコミジャーナル 経営:
「マクネリ氏とシュワルツ氏、Sun Microsystemsトップ2名が同社を去る」
マピオンのエンジニアさんとの対談記事

昨年末、マピオンさんと合同セミナーを開催しました。
イベント後、マピオンのエンジニアの方々と対談を行い、
対談内容が下記にて公開されました。
マピオン開発部門×サンJavaスペシャリスト 特別対談
なぜ、GlassFish を採用したのか、実運用を開始してからの
どのような事を感じていらっしゃるか等、実際に本番環境で
利用しているお客様の生の声が記載されています。
GlassFish の導入をご検討中の方、また Tomcat, JBoss 等
他のオープンソースアプリケーションサーバをご利用中の方は
是非、本資料をご覧ください。
Oracle の今後のソフトウェア戦略について
本日、夜中2時に開催された Oracle の今後の製品戦略について、
特にソフトウェア関連の発表資料の画面ダンプを本ブログにて
公開します。
速報として若干補足します。
今日の発表内で、アプリケーションサーバ、統合開発環境について説明がありました。
GlassFish は今後も Java EE 6 の参照実装として継続的に開発/投資を
継続していき、企業環境における製品として WebLogic を押していきます。
また、統合開発環境においては、NetBeans は今後も投資し Java の軽量な
開発環境として開発/投資をしていきます。JDeveloper は Oracle の戦略的な
開発ツールとして今後も利用されます。さらに Oracle は Eclipse への投資も
引き続き行っていきます。
今まで NetBeans について Oracle から発表が無く不安に思われていた方も
いらっしゃるかと思いますが、今日は NetBeans についても明言され今後も
投資されるので利用者の皆様には安心材料を提供できたかと思います。
この度の発表で Oracle/Sun のソフトウェア製品についてはかなりクリアになったかと
思います。
ソフトウェア関連製品の発表資料(PDF)
WebCast
















































【速報】EU が Oracle の Sun 買収を承認
EU が Oracle の Sun 買収を承認をしたようです。
Mergers: Commission clears Oracle’s proposed acquisition of Sun Microsystems
発表後、本当に長かったですね。
これからどんな風に変わっていくのか楽しみです。
Java Champion による Java パフォーマンスチューニングのトレーニング開催予定
今年の2月と3月に、Java Champion による Java パフォーマンス
チューニングに関するトレーニングが開催されます。
日頃、Java のパフォーマンスチューニングでお悩みの方は、
是非、この機会に受講されてみては如何でしょうか?
ちなみに、余談ですが、
Java Champion はJava におけるリーダシップの役割を持つ方々で、
Java の技術に関する啓蒙活動等を行う、世界中から厳選された(約 90 名) Java のスペシャリストです。
日本からは唯一櫻庭 祐一さんが選ばれています。
今回は、この Java Champion のメンバーの中からパフォーマンスチューニングに強い方を日本サンのエデュケーション部が招待し開催する運びとなった貴重なトレーニングです。
ちょっと値段は高いですが、海外からまた社外から招待していることもぜひご考慮頂き、ぜひご検討ください。
以下、トレーニングの案内文
この度サンは、世界的に有名な Java エキスパートを講師にお迎えし、
「Java エキスパートトレーニング」を開催致します。
本トレーニングは米国において、連日満員の人気コースとなっており、
Java トップエンジニアの育成に大きな成果を上げています。
また、Java の最前線で活躍する世界的に著名なエキスパートから、
直接技術を習得できる貴重な機会として、中・上級エンジニアから、
ご好評を頂いております。
東京品川にといての、日本語通訳付きでのコース開催は、
日本のエンジニアの方にとって大変貴重な機会となります。
◇開催コース◇
——————————————————
「プロフェッショナルによる真の Java プログラミングとは?」
日 程:2010年2月23日(火)- 26日(金)
コース:Java Specialist Master Course (JP-EXL-3500)
講 師:Maurice Naftalin
——————————————————-
「究極の Java パフォーマンスチューニングとは?」
日 程:2010年3月2日(火)- 5日(金)
コース:Java Performance Tuning Workshop (JP-EXL-2025)
講 師:Kirk Pepperdine
—————————————————
※コースの詳細、講師のプロフィールは以下をご参照下さい
http://jp.sun.com/training/news/2009/exl/
本コースの受講により、彼らの持つスキル、経験、洞察力を学び取り、
一回り、二回りの成長へとつなげて頂くことを期待しております。
上を目指すエンジニアの方は、この絶好の機会をお見逃し無く!
GlassFishのロードバランサプラグインで Apache と動作確認 Part2 (GlassFish 設定編)
GlassFishのロードバランサプラグインで Apache と連携 Part1 (Apache 設定編)
に引き続きGlassFish の設定と動作確認をしてみます。
GlassFish の設定と動作確認
実際に GlassFish 上でクラスタ構成を設定し、動作を確認してみましょう。
ドメインの起動
Part 1 で作成したドメインを起動してください。
| dashost > 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://dashost:5086/jmxrmi] に接続できます。 ドメインは少なくとも次のポートで接続を待機しています: [5080 5081 5048 5037 5038 5039 5086 ]。 ドメインはアプリケーションサーバークラスタおよびその他のスタンドアロンインスタンスをサポートします。 |
ノードエージェントの作成
次に、ドメインに所属するノードエージェントを2つ作成してください。
それぞれのノードエージェントが稼働するマシン上でコマンドを実行してください。
nodeagent1 の作成と起動
| nodeagent1 > asadmin create-node-agent nodeagent1 コマンド create-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 は正常に実行されました。 |
nodeagent2 の作成と起動
| nodeagent2 > asadmin create-node-agent nodeagent2 コマンド create-node-agent は正常に実行されました。 nodeagent2 > asadmin start-node-agent nodeagent2 出力を /export/home/appserv/nodeagents/nodeagent2/agent/logs/server.log にリダイレクトしています アプリケーション出力を /export/home/appserv/nodeagents/nodeagent2/agent/logs/server.log にリダイレクトします コマンド start-node-agent は正常に実行されました。 |
クラスタとインスタンスの作成
ドメイン管理サーバでクラスタを1つ作成してください。
クラスタ作成後、各ノードエージェント上にそれぞれ1つずつ
クラスタに所属するインスタンスを作成してください。
| dashost > asadmin create-cluster cluster1 コマンド create-cluster は正常に実行されました。 dashost > asadmin create-instance –nodeagent nodeagent1 –cluster cluster1 instance1 コマンド create-instance は正常に実行されました。 dashost > asadmin create-instance –nodeagent nodeagent2 –cluster cluster1 instance2 コマンド create-instance は正常に実行されました |
クラスタの起動
作成したクラスタを起動してみましょう。
| dashost > asadmin start-cluster cluster1 クラスタ化されたインスタンス instance1 の起動に成功しました。 クラスタ化されたインスタンス instance2 の起動に成功しました。 コマンド start-cluster は正常に実行されました。 |
サンプルアプリケーションのデプロイ
次に、作成したクラスタに対してサンプルのアプリケーションをデプロイします。
| dashost > asadmin deploy –target cluster1 –availabilityenabled=true /sun/glassfish-v2.1.1/samples/quickstart/clusterjsp/clusterjsp.ear コマンド deploy は正常に実行されました。 |
ロードバランサプラグインの設定と設定ファイルのエクスポート
続いて、ロードバランサの設定を作成しデプロイしたアプリケーションに対して
負荷分散を行う設定をします。
| dashost > asadmin create-http-lb-config –target cluster1 lb-config コマンド create-http-lb-config は正常に実行されました。 dashost > asadmin enable-http-lb-server cluster1 コマンド enable-http-lb-server は正常に実行されました。 dashost > asadmin enable-http-lb-application –name clusterjsp cluster1 コマンド enable-http-lb-application は正常に実行されました。 dashost > asadmin create-http-health-checker –interval 10 –config lb-config cluster1 コマンド create-http-health-checker は正常に実行されました。 dashost > asadmin export-http-lb-config –config lb-config /tmp/loadbalancer.xml 生成されたファイルの場所: /tmp/loadbalancer.xml コマンド export-http-lb-config は正常に実行されました。 |
ここで,出力されたloadbalancer.xmlファイルを Apache 上にコピーする事で
負荷分散機能を利用することができるようになります。
しかし、手動でファイルをコピーする方法は古い方法ですので、
手動でファイルをコピーするのではなく、下記の方法を利用してください。
| apache > cp /tmp/loadbalancer.xml /usr/local/apache2.2.14/conf/loadbalancer.xml |
autoapplyenabled機能の有効化
下記コマンドを実行すると Web Server にログインして loadbalancer.xml を
直接編集したり、手動でコピーしなくても、asadmin コマンドから直接
設定変更内容を更新する事ができるようになります.
| dashost > asadmin create-http-lb –target cluster1 –autoapplyenabled=true –devicehost apache.japan.sun.com –deviceport 443 lb-config コマンド create-http-lb は正常に実行されました。 dashost > asadmin apply-http-lb-changes lb-config コマンド apply-http-lb-changes は正常に実行されました。 dashost > |
apply-http-lb-changes を実行すると、直ちに loadbalancer.xml が
更新されるようになります。
Apache 上で更新された loadbalancer.xml は下記の通りです。
| apache > cat /usr/local/apache2.2.14/conf/loadbalancer.xml <?xml version=”1.0″ encoding=”UTF-8″?> <!DOCTYPE loadbalancer PUBLIC “-//Sun Microsystems Inc.//DTD Sun Java System Application Server 9.1//EN” “sun-loadbalancer_1_2.dtd”> <loadbalancer> <cluster name=”cluster1″ policy=”round-robin”> <instance disable-timeout-in-minutes=”30″ enabled=”true” listeners=”http://nodeagent1.japan.sun.com:38080 https://nodeagent1.japan.sun.com:38181″ name=”instance1″ weight=”100″/> <instance disable-timeout-in-minutes=”30″ enabled=”true” listeners=”http://nodeagent2.japan.sun.com:38080 https://nodeagent2.japan.sun.com:38181″ name=”instance2″ weight=”100″/> <web-module context-root=”/clusterjsp” disable-timeout-in-minutes=”30″ enabled=”true”/> <health-checker interval-in-seconds=”30″ timeout-in-seconds=”10″ url=”/”/> </cluster> <property name=”response-timeout-in-seconds” value=”60″/> <property name=”reload-poll-interval-in-seconds” value=”60″/> <property name=”https-routing” value=”false”/> <property name=”require-monitor-data” value=”false”/> <property name=”active-healthcheck-enabled” value=”false”/> <property name=”number-healthcheck-retries” value=”3″/> <property name=”rewrite-location” value=”true”/> <property name=”rewrite-cookies” value=”false”/> </loadbalancer> <!– This file was generated on: [Fri Dec 25 18:00:39 JST 2009]. Debugging Tips: By default, instances and web-modules are not enabled. Please enable them manually if you have not done that using asadmin. –> apache > |
動作確認1: 高可用性のテスト
ブラウザから Apache の稼働するマシンへアクセスしてください。
| ブラウザで Apache が稼働するマシンへ接続
http://apache.japan.sun.com/clusterjsp/ Served From Server instance: instance1 |
表示された画面から”Served From Server instance“のエントリを
確認してください。この例ではinstance1でアプリケーションが
稼働していることが分かります。
続いて、
Enter session attribute data:
にセッション情報を追加してください。
セッション情報を追加した後、稼働中のサーバインスタンス(instance1)
を停止します。
| dashost > asadmin stop-instance instance1 コマンド stop-instance は正常に実行されました. |
ブラウザをリロードするか,[Reload Page]ボタンを押してください。
“Served From Server instance:”のエントリが instance1からinstance2に
変更されているかと思います。また同時にセッション情報も引き継がれていること
が確認できるかと思います。
ここまでくれば、高可用性テストは完了です。
動作確認2:ドメイン管理サーバから Apache の負荷分散設定を変更するテスト
ここでは、asadmin コマンドだけを使って Apache が稼働するシステムに
ログインすることなく、負荷分散設定を変更するテストを行います。
まず、ドメイン管理サーバから instance2 に対するリクエストを送信しないように
設定します。
| dashost > asadmin set “cluster1.server-ref.instance2.lb-enabled=false” cluster1.server-ref.instance2.lb-enabled = false dashost > asadmin apply-http-lb-changes lb-config コマンド apply-http-lb-changes は正常に実行されました。 |
コマンドを実行すると、loadbalancer.xml の instance2 に該当する
設定箇所が変更されます。 (enabled が false)
| apache > cat loadbalancer.xml|grep nodeagent2 <instance disable-timeout-in-minutes=”30″ enabled=”false” listeners=”http://nodeagent2.japan.sun.com:38080 https://nodeagent2.japan.sun.com:38181″ name=”instance2″ weight=”100″/> |
instance2 に対する負荷分散を再会させたい場合,下記を実行してください。
| dashost > asadmin set “cluster1.server-ref.instance2.lb-enabled=true” cluster1.server-ref.instance2.lb-enabled = true dashost > asadmin apply-http-lb-changes lb-config コマンド apply-http-lb-changes は正常に実行されました。 |
再度、Apache の loadbalancer.xml を確認してみます。
instance2 に該当する設定箇所の enabled が true に変更されている事を確認できます。
| apache > cat loadbalancer.xml | grep nodeagent2 <instance disable-timeout-in-minutes=”30″ enabled=”true” listeners=”http://nodeagent2.japan.sun.com:38080 https://nodeagent2.japan.sun.com:38181″ name=”instance2″ weight=”100″/> |
動作確認3:新規インスタンス追加時の負荷分散振り先の追加テスト
最後に、インスタンスを追加してクラスタ構成を変更し負荷分散の対象を増やすテストを行います。
まず、クラスタに対して新規インスタンスを追加して起動してください。
起動したのち、apply-http-lb.-changes を実行してください。
コマンドを実行すると、負荷分散の振り先が追加されます。
| dashost > asadmin create-instance –nodeagent nodeagent1 –cluster cluster1 instance3 HTTP_LISTENER_PORT の代わりに 38,081 を使用します。 HTTP_SSL_LISTENER_PORT の代わりに 38,182 を使用します。 IIOP_SSL_LISTENER_PORT の代わりに 33,821 を使用します。 JMS_PROVIDER_PORT の代わりに 37,677 を使用します。 IIOP_LISTENER_PORT の代わりに 33,701 を使用します。 JMX_SYSTEM_CONNECTOR_PORT の代わりに 38,687 を使用します。 IIOP_SSL_MUTUALAUTH_PORT の代わりに 33,921 を使用します。 コマンド create-instance は正常に実行されました。 dashost > asadmin create-instance –nodeagent nodeagent2 –cluster cluster1 instance4 HTTP_LISTENER_PORT の代わりに 38,081 を使用します。 HTTP_SSL_LISTENER_PORT の代わりに 38,182 を使用します。 IIOP_SSL_LISTENER_PORT の代わりに 33,821 を使用します。 JMS_PROVIDER_PORT の代わりに 37,677 を使用します。 IIOP_LISTENER_PORT の代わりに 33,701 を使用します。 JMX_SYSTEM_CONNECTOR_PORT の代わりに 38,687 を使用します。 IIOP_SSL_MUTUALAUTH_PORT の代わりに 33,921 を使用します。 コマンド create-instance は正常に実行されました。 dashost > asadmin start-instance instance3 コマンド start-instance は正常に実行されました。 dashost > asadmin start-instance instance4 コマンド start-instance は正常に実行されました。 dashost > asadmin apply-http-lb-changes lb-config コマンド apply-http-lb-changes は正常に実行されました。 |
コマンドを実行後、loadbalancer.xml を確認してみましょう。
追加したインスタンスに対する振り先設定が追加されています。
| apache > cat loadbalancer.xml <?xml version=”1.0″ encoding=”UTF-8″?> <!DOCTYPE loadbalancer PUBLIC “-//Sun Microsystems Inc.//DTD Sun Java System Application Server 9.1//EN” “sun-loadbalancer_1_2.dtd”> <loadbalancer> <cluster name=”cluster1″ policy=”round-robin”> <instance disable-timeout-in-minutes=”30″ enabled=”true” listeners=”http://nodeagent1.japan.sun.com:38080 https://nodeagent1.japan.sun.com:38181″ name=”instance1″ weight=”100″/> <instance disable-timeout-in-minutes=”30″ enabled=”true” listeners=”http://nodeagent2.japan.sun.com:38080 https://nodeagent2.japan.sun.com:38181″ name=”instance2″ weight=”100″/> <instance disable-timeout-in-minutes=”30″ enabled=”true” listeners=”http://nodeagent1.japan.sun.com:38081 https://nodeagent1.japan.sun.com:38182″ name=”instance3″ weight=”100″/> <instance disable-timeout-in-minutes=”30″ enabled=”true” listeners=”http://nodeagent2.japan.sun.com:38081 https://nodeagent2.japan.sun.com:38182″ name=”instance4″ weight=”100″/> <web-module context-root=”/clusterjsp” disable-timeout-in-minutes=”30″ enabled=”true”/> <health-checker interval-in-seconds=”30″ timeout-in-seconds=”10″ url=”/”/> </cluster> <property name=”response-timeout-in-seconds” value=”60″/> <property name=”reload-poll-interval-in-seconds” value=”60″/> <property name=”https-routing” value=”false”/> <property name=”require-monitor-data” value=”false”/> <property name=”active-healthcheck-enabled” value=”false”/> <property name=”number-healthcheck-retries” value=”3″/> <property name=”rewrite-location” value=”true”/> <property name=”rewrite-cookies” value=”false”/> </loadbalancer> <!– This file was generated on: [Fri Dec 25 18:22:35 JST 2009]. Debugging Tips: By default, instances and web-modules are not enabled. Please enable them manually if you have not done that using asadmin. –> apache > ※ 新しく追加したインスタンスの設定が enabled=”false”になっている場合、 dashost > asadmin set “cluster1.server-ref.instance3.lb-enabled=true” |
このように、ロードバランサプラグインを利用し、自動適用の設定を行うと、
アプリケーションサーバ側のクラスタ内の変更に対して、前段の Web サーバ側に
一切ログインせずに、振り先を自由に変更できるため、導入時には若干面倒ですが、運用時はとても楽になります。
また、お気づきの事と思いますが1度設定を行うと、Apache のサーバにログインする必要がないばかりか、負荷分散設定を変更した際に、Apache の再起動なども必要としていないことがわかるかと思います。
これは、loadbalancer.xml の更新をチェックする内部プログラムが別途稼働しており、更新があった場合に、動的に設定を有効にする仕組みが導入されているためです。これで、Web サーバ側の管理が随分楽になるのではないかと思います。
ぜひ、上記を参考にお試しください。
最後に、今回は GlassFish のロードバランサプラグインを Apache にインストールしていますが、Sun Java System Web Server でも autoapply の機能は使うことができますのでご安心ください。
追記:
正直、ちょっと面倒という方は、Sun GlassFish Enterprise Server with HADB を使ってみるのもいいかもしれません、with HADB 版ではインストーラからロードバランサプラグインのインストールもかんたんにできるようになっていますので、試す価値はあるかもしれません。
with HADB 版を利用しない場合は、上記の方法をご利用ください。
