アプリケーション・サーバー、クラスター、またはその他の Java™ プロセス (メッセージング・サーバーなど) を空のノードに組み込めるように、カスタム・プロファイルを作成します。
プロファイル管理ツール を使用して、カスタム・プロファイルを作成することができます。
始める前に
プロファイル管理ツールを使用する前に、製品ファイルをインストールします。
サポートされる構成: プロファイル管理ツール は、
manageprofiles コマンド用のグラフィカル・ユーザー・インターフェースであり、AIX®、Linux、および Windows 上でのみサポートされます。HP-UX、IBM® i、および Solaris では、代わりに
manageprofiles コマンドを使用してください。
sptcfg
プロファイルを作成するための十分な一時スペースをシステムに用意する必要があります。
詳しくは、プロファイルのファイル・システム要件を参照してください。
重要: プロファイル管理ツール を起動すると、以下の状況では、非 root ユーザーであると判定してツールがロックする場合があります。マシンに root としてログインし、SetPermissions ユーティリティーを使用してユーザーを x から y に変更します。読者がユーザー x であり、マシンに再びログインすると想定します。
プロファイル管理ツール を起動し、「プロファイル管理ツール」をクリックしてから、「作成」をクリックします。「作成」をクリックした後の次のクリック操作で、ツールがロックすることがあります。
このタスクについて
WebSphere® Application Server Network Deployment 製品のコア・プロダクト・ファイルをインストール後、プロファイルを作成する必要があります。この項目では、プロファイル管理ツールを使用したカスタム・プロファイルの作成について説明します。カスタム・プロファイルは、アプリケーション・サーバー、クラスター、またはその他の Java プロセス (メッセージング・サーバーなど) を組み込むようにカスタマイズできる空のノードです。
また、manageprofiles コマンドを使用して、カスタム・プロファイルを作成することもできます。詳しくは、manageprofiles コマンドの説明を参照してください。
各プロファイルのテンプレートは、app_server_root/profileTemplates ディレクトリーにあります。
このディレクトリー内には、さまざまなプロファイル・タイプに対応し、インストールされた製品のタイプによって異なる、複数のディレクトリーがあります。
これらのディレクトリーは、
-templatePath オプションを指定して manageprofiles コマンドを実行する場合に指定するパスです。profileTemplates ディレクトリー以外の場所にプロファイル・テンプレートがあれば、それを指定することもできます。
manageprofiles コマンドに -templatePath パラメーターを指定すると、使用可能なテンプレートの説明を取得できます。
これらのテンプレートについては、『プロファイルの概念』トピックでも説明されています。
カスタム・プロファイルを作成した場合、デフォルトで、プロファイル管理ツールにより、
カスタム・ノードが統合されます。ノードを統合すると、
ノードが操作可能になります。ノードを統合するには、
実行中のデプロイメント・マネージャーにアクセスする必要があります。それ以外の場合、接続エラーが表示されます。実行中のデプロイメント・マネージャーにアクセスできない場合や、他の理由がある場合は、ノードを後で統合することもできます。
カスタム・プロファイルがデプロイメント・マネージャーのないマシン上にある場合、
デプロイメント・マネージャーは
ノードの統合をサポートするために、ネットワークを介してアクセス可能でなければなりません。
プロファイル管理ツールでは、標準プロファイル作成プロセスまたは拡張プロファイル作成プロセスで、プロファイルを作成できます。
標準プロファイル作成プロセスでは、デフォルトの設定を使用し、固有のポート値を割り当てます。許可される値を設定することもできます。拡張プロファイル作成プロセスでは、デフォルト値を受け入れることも、独自の値を指定することも可能です。
手順
- 製品をインストールして、コア・プロダクト・ファイルを作成します。
- プロファイル管理ツールを開始して新しいランタイム環境を作成します。
このツールを開始するには、以下のいずれかの方法を使用します。
- インストールの最後に、プロファイル管理ツールを開始するチェック・ボックスを選択します。
- コマンドを発行してコマンド・プロンプトから WebSphere Customization Toolbox を直接開き、その後、プロファイル管理ツールを開きます。
- ファースト・ステップ・コンソールから「WebSphere Customization Toolbox」オプションを選択し、その後、プロファイル管理ツールを開きます。
「スタート」メニューを使用して WebSphere Customization Toolbox にアクセスし、その後、プロファイル管理ツールを開きます。
プログラムの開始に使用される Linux オペレーティング・システム・メニューを使用して WebSphere カスタマイズ・ツールボックスを開始し、その後、プロファイル管理ツールを開きます。
- 新規プロファイルを作成するには、 「プロファイル」タブで「作成」をクリックします。
「プロファイル」タブには、マシンで既に作成されているプロファイルのリストが表示されます。プロファイルを選択しても、そのプロファイルを拡張できない場合は、何の操作も実行できません。選択したプロファイルを拡張できる場合以外は、「拡張」ボタンもぼかし表示になります。
「環境の選択」パネルがツールによって表示されます。
- カスタム・プロファイルを選択して、「次へ」をクリックします。
プロファイル作成オプションのパネルが表示されます。
- 「標準プロファイル作成」または「拡張プロファイル作成」を選択し、
「次へ」をクリックします。
「標準プロファイル作成」オプションでは、デフォルトの構成設定を使用したプロファイルを作成します。
「拡張プロファイル作成」オプションでは、プロファイルに独自の構成値を指定できます。
- 「標準プロファイル作成」を選択した場合は、
ノードの統合についての
ステップに進みます。
- 「拡張プロファイル作成」を選択した場合、
「プロファイル名およびロケーション」パネルで、カスタム・プロファイル名およびプロファイル・ディレクトリーを指定するか、
またはデフォルトを受け入れ、「次へ」をクリックします。
プロファイル名のガイドライン: 2 バイト文字がサポートされています。プロファイル名は、次の制限を満たす固有の名前とすることができます。
プロファイルの名前を付ける際には、以下の文字を使用しないでください。
- スペース
- *&? など、ご使用のオペレーティング・システムのディレクトリー名
にサポートされていない特殊文字
- スラッシュ (/) または (¥)
デフォルト・プロファイル
マシンで作成する最初のプロファイルは、デフォルト・プロファイルです。
デフォルト・プロファイルは、製品インストール・ルートの bin ディレクトリーから実行されるコマンドのデフォルトのターゲットです。
マシンにプロファイルが 1 つしかない場合は、すべてのコマンドが構成内のその唯一のサーバー・プロセスで動作します。
プロファイルの作成時に、そのプロファイルをデフォルト・プロファイルにするには、「拡張プロファイル作成」パスの「プロファイル名およびロケーション」パネルで「このプロファイルをデフォルトにする」をクリックします。プロファイルの作成後に、manageprofiles コマンドを使用して、そのプロファイルをデフォルト・プロファイルにすることもできます。
マルチプロファイル環境におけるプロファイルのアドレッシング
一部のコマンドでは、マシンに複数のプロファイルが存在する環境でデフォルト・プロファイル以外のプロファイルを対象にする場合に、コマンドの適用対象となるプロファイルを指定する必要があります。これらのコマンドでは、-profileName パラメーターを使用して、処理するプロファイルを識別します。
各プロファイルの bin ディレクトリーにあるコマンドを使用する方が効果的な場合があります。
それらのコマンドを使用してコマンド・シェルを照会することによって、呼び出し側のプロファイルを判別し、その呼び出し側のプロファイルをそれらのコマンドの対象にすることもできます。
デフォルト・プロファイル情報
デフォルト・プロファイル名は
<profile_type><profile_number> です。
- <profile_type> の値は、AppSrv、Dmgr、Custom、AdminAgent、JobMgr、または SecureProxySrv です。
- <profile_number> は、固有のプロファイル名を作成するために使用される連続番号です。
![[AIX]](../images/aixlogo.gif)
デフォルト・プロファイル・ディレクトリーは app_server_root/profiles (app_server_root はインストール・ルート) です。
デフォルト・プロファイル・ディレクトリーは app_server_root¥profiles (app_server_root はインストール・ルート) です。
「ノード名およびホスト名」パネルがツールによって表示されます。
- カスタム・プロファイルのノードおよびホスト特性を指定し、
「次へ」をクリックします。
WebSphere Application Server Network Deployment の以前のインストール済み環境を バージョン 9.0 にマイグレーションする計画の場合、以前のバージョンのセルに使用していたのと同じセル名を バージョン 9.0 デプロイメント・マネージャーに使用してください。セル名は、同じ物理マシンまたはマシンのクラスター (SYSPLEX など) 上の、製品が稼働する環境では、どこでも固有でなければなりません。またセル名は、エンティティー間のネットワーク接続が、セル間で、または各セルとの通信が必要なクライアントから要求されるような環境では、どこでも固有でなければなりません。さらに、
セル名の名前空間が統合される場合も、セル名が固有である必要があります。
セル名が固有でないと、javax.naming.NameNotFoundException エラーのような症状が起こり、
その場合には、固有名を持つセルを作成する必要があります。
セルのマイグレーション後には、以前のバージョンの管理対象ノードは、互換モードで バージョン 9.0 デプロイメント・マネージャーによって管理されるようになります。
セルの個々の管理対象ノードを バージョン 9.0 にマイグレーションすることができます。
そのためには、バージョン 9.0 プロファイルを、以前のバージョンの管理対象ノードと同じノード名で作成する必要があります。
予約名: フィールド値として予約済みのフォルダー名を使用しないでください。
予約済みフォルダー名を使用すると、予測不能な結果が起こる可能性があります。
以下の用語は、予約されたフォルダー名です。
- cells
- nodes
- servers
- clusters
- applications
- deployments
表 1. カスタム・プロファイルの特性. 以下の表に、カスタム・プロファイルの特性を示します。
フィールド名 |
デフォルト値 |
制約 |
説明 |
ノード名 |
shortHostName
Node
NodeNumber
各部の意味は、次のとおりです。 - shortHostName は短縮ホスト名です。
- NodeNumber は 01 から始まる連続番号です。
|
予約語を使用しないでください。 デプロイメント・マネージャー・セル内で固有の名前を使用します。
旧バージョンの管理対象ノードをマイグレーションする場合は、この バージョン 9.0 カスタム・プロファイルに同じノード名を使用します。
|
この名前は、カスタム・プロファイルが追加されるデプロイメント・マネージャー・セル内で管理のために使用されます。デプロイメント・マネージャー・セル内で固有の名前を使用します。
デプロイメント・マネージャー・セルの以前のバージョンを バージョン 9.0 デプロイメント・マネージャーにマイグレーションした後には、バージョン 9.0 デプロイメント・マネージャーにおいて互換モードで稼働している以前のバージョンのカスタム・プロファイルをマイグレーションすることができます。
|
ホスト名 |
ドメイン・ネーム・サーバー (DNS) 名の長い形式。
|
ホスト名は、ご使用のネットワークを介してアドレス可能でなければなりません。 |
ご使用のマシンの実際の DNS 名または IP アドレスを使用して、ご使用のマシンとの通信を可能にします。
この表の後にある、ホスト名に関する追加情報を参照してください。 |
- ディレクトリー・パスの考慮事項:
profiles_directory_path¥profile_name ディレクトリー内の文字数は、80 文字以下でなければなりません。
- ホスト名の考慮事項:
ホスト名は、ノードがインストールされている物理マシンのネットワーク名です。
ホスト名は、サーバー上の物理ネットワーク・ノードに解決する必要があります。
サーバーが複数のネットワーク・カードを備えている場合は、
ホスト名または IP アドレスは、そのネットワーク・カードのいずれか 1 つに解決されなければなりません。
リモート・ノードは、ホスト名を使用して、このノードに接続および通信します。
その他のマシンがネットワーク内でアクセスできるホスト名を選択することが重要です。
この値に汎用 ID である localhost を使用しないでください。
また、2 バイト文字セット (DBCS) の文字を使用したホスト名を持つマシンに WebSphere Application Server 製品をインストールしないでください。
ホスト名に使用される DBCS 文字はサポートされません。
同一コンピューター上で共存している複数のノードを固有の IP アドレスで定義する場合は、ドメイン・ネーム・サーバー (DNS) の検索・テーブルで個々の IP アドレスを定義してください。
スタンドアロン・アプリケーション・サーバーの構成ファイルでは、ネットワーク・アドレスが 1 つだけ存在するマシンに複数の IP アドレスがある場合に、ドメイン・ネームを解決できません。
ホスト名に指定する値は、スタンドアロン・アプリケーション・サーバーの構成文書で hostName プロパティーの値として使用されます。次のいずれかの形式で、
ホスト名の値を指定してください。
- 完全修飾のドメイン・ネーム・サーバー (DNS) ホスト名ストリング。例えば xmachine.manhattan.ibm.com など。
- デフォルトの DNS 短縮ホスト名ストリング。例えば xmachine など。
- 数値 IP アドレス。例えば 127.1.255.3 など。
完全修飾 DNS ホスト名には、あいまいなところがなく、柔軟性が高いという利点があります。この柔軟性により、ユーザーは、ホスト・システムの実際の IP アドレスを変更しても、
アプリケーション・サーバー構成を変更する必要がありません。ホスト名のこの値は、
動的ホスト構成プロトコル (DHCP) を使用して IP アドレスを割り当てる際に頻繁に IP アドレスを変更することが予定されている場合には、特に有用です。この形式の欠点は、DNS に依存するということです。DNS が使用できないと、接続に支障を来します。
短縮ホスト名も、
動的に解決可能です。ショート・ネーム形式には、
ネットワークから切断されたときでもシステムがアプリケーション・サーバーを実行できるように、
ローカル・ホスト・ファイルで再定義されるという機能もあります。
切断状態で実行するには、ホスト・ファイルでショート・ネームをループバック・アドレス、127.0.0.1 として定義します。この形式の欠点は、リモート・アクセスで DNS に依存するということです。DNS が使用できないと、接続に支障を来します。
数値 IP アドレスには、DNS によって名前を解決する必要がないという利点があります。
リモート・ノードは、DNS が使用できなくても、数値 IP アドレスを使用して名付けられたノードに接続できます。
この形式の欠点は、数値 IP アドレスを使用するとアドレスが固定化されるということです。
カスタム・プロファイル特性を指定すると、ツールによって「フェデレーション」パネルが表示されます。
- デプロイメント・マネージャーで管理セキュリティーが有効になっている場合は、デプロイメント・マネージャーのホスト名、SOAP ポート、ユーザー名、パスワードを指定します。「次へ」をクリックします。
フェデレーション後のカスタム・プロファイルのプロセスは、ノード・エージェント・プロセスです。
ノード・エージェント・プロセスは、カスタム・ノードのためのデプロイメント・マネージャーのエージェントです。
ノード・エージェントは、デプロイメント・マネージャーからのコマンドに応答し、以下のアクションを含むタスクを実行します。
- アプリケーション・サーバー・プロセス、クラスター、およびクラスター・メンバーの作成
- アプリケーション・サーバー・プロセスの開始と停止
- デプロイメント・マネージャーの現行エディションとノードに存在するコピーの間の構成の同期化
- アプリケーション・サーバー・プロセスの削除
ノード・エージェントとそれらのタスクについての詳細は、
インフォメーション・センターのシステム管理セクションを参照してください。
ノードを統合する必要があるか ?
この時点でカスタム・ノードを統合することをお勧めします。
「フェデレーション」パネルでカスタム・ノードを統合するために「次へ」をクリックする時点で、デプロイメント・マネージャーが実行中で、かつアクセス可能な状態になっている必要があります。
カスタム・プロファイルがデプロイメント・マネージャーのないマシン上にある場合、ノードのフェデレーションを可能にするために、デプロイメント・マネージャーは実行中であり、しかもネットワークを介してアクセス可能でなければなりません。
「次へ」をクリックする前にデプロイメント・マネージャーが実行中でないかアクセス可能でない状態であるが、この時点でデプロイメント・マネージャーを開始し、アクセス可能にすることができる場合は、そのようにします。
そうでない場合は、「後でノードをフェデレートします」チェック・ボックスを選択します。
デプロイメント・マネージャーが実行中であるかどうかが不確実な場合は、統合しないでください。
デプロイメント・マネージャーが使用可能であることが確認できれば、ノードをフェデレートします。
デフォルトではないリモート・メソッド呼び出し (RMI) を優先 Java Management Extensions (JMX) コネクターとして使用するようデプロイメント・マネージャーが再構成されている可能性があります。デプロイメント・マネージャーの管理コンソールで「システム管理」>「デプロイメント・マネージャー」>「管理サービス 」をクリックして、優先コネクター・タイプを確認します。
RMI が優先 JMX コネクターである場合は、後で addNode コマンドを使用して、カスタム・プロファイルを統合する必要があります。JMX コネクター・タイプおよび RMI ポートを指定できるように、addNode コマンドを使用します。
デプロイメント・マネージャーがデフォルトの SOAP JMX コネクター・タイプを使用している場合は、ホスト名および SOAP ポートを指定し、すぐにノードを統合して、カスタマイズ可能な機能ノードを作成します。
デプロイメント・マネージャーが使用不可の場合の統合
デプロイメント・マネージャーが実行中でないか、またはアクセス可能でない場合、カスタム・ノードを統合すると、エラー・メッセージが表示されます。
プロファイル作成プロセス中にデプロイメント・マネージャーが使用不可になると、ログ内のインストール・インディケーターは完全な失敗を示す INSTCONFFAIL となります。 結果として、カスタム・プロファイルは使用することができません。
プロファイルを削除する必要があります。
詳しくは、『プロファイルの削除』を参照してください。
「拡張プロファイル作成」を選択していた場合に、すぐに統合するためのオプションを選択すると、「セキュリティー証明書」パネルが次に表示されます。
証明書の作成と
インポートのステップに進みます。
それ以外の場合は、一般的なプロファイル作成オプション用の「プロファイル作成サマリー」パネルが表示されます。カスタム・プロファイルの作成のステップに進みます。
- デフォルトの個人証明書とルート署名証明書を作成するか、個人証明書とルート署名証明書を鍵ストア・ファイルからインポートして、「次へ」をクリックします。
両方の証明書を作成することも、両方の証明書をインポートすることも、片方の証明書を作成してもう片方の証明書をインポートすることもできます。
ベスト・プラクティス: 個人証明書をデフォルトの個人証明書としてインポートする場合は、個人証明書に署名したルート証明書もインポートします。
そうしない場合、
プロファイル管理ツール は個人証明書の署名者を trust.p12 ファイルに追加します。
bprac
デフォルトの個人証明書またはルート署名証明書をインポートする場合は、インポートする証明書ごとにパスとパスワードを指定し、鍵ストアのタイプと鍵ストアの別名を選択します。
- 証明書の情報が正しいことを確認し、「次へ」をクリックします。
証明書を作成する場合は、デフォルト値をそのまま使用することも、デフォルト値を変更して新しい証明書を作成することもできます。デフォルトの個人証明書は、デフォルトの有効期間が 1 年で、ルート署名証明書によって署名されます。
ルート署名証明書は自己署名証明書で、デフォルトで 15 年間有効です。ルート署名証明書のデフォルトの鍵ストア・パスワードは WebAS です。パスワードは変更してください。一部の鍵ストア・タイプ (PKCS12 など) では、2 バイト文字セット (DBCS) の文字がサポートされていないので、パスワードに DBCS 文字を組み込むことはできません。どの鍵ストア・タイプがサポートされるかは、java.security ファイルで記述されているプロバイダーによって異なります。
いずれかまたは両方の証明書を作成するか、いずれかまたは両方の証明書をインポートすると、key.p12、trust.p12、root-key.p12、default-signers.p12、deleted.p12、ltpa.jceks の各鍵ストア・ファイルが作成されます。証明書の作成時またはインポート時に、これらのファイルのパスワードは、デフォルトのパスワードであれ、指定したパスワードであれ、すべて同じパスワードになります。
key.p12 ファイルには、デフォルトの個人証明書が格納されます。trust.p12 ファイルには、デフォルトのルート証明書に由来する署名者証明書が格納されます。
root-key.p12 ファイルには、ルート署名証明書が格納されます。default-signer.p12 ファイルには署名者証明書が格納されていて、それらの証明書は、サーバーがインストールされ、実行されるようになった後に作成する、新しい鍵ストア・ファイルに追加されます。デフォルトでは、デフォルトのルート証明書の署名者証明書と DataPower® の署名者証明書が default-signer.p12 鍵ストア・ファイルに格納されます。deleted.p12 鍵ストア・ファイルには、deleteKeyStore タスクによって削除された証明書が格納されます。したがって、必要に応じてリカバリーが可能になります。ltpa.jceks ファイルには、サーバーのデフォルトの Lightweight Third-Party Authentication (LTPA) 鍵が格納されます。環境内に含まれている各サーバーは、その鍵を使用して互いに通信します。
インポートした証明書は、key.p12 ファイルまたは root-key.p12 ファイルに追加されます。
いずれかの証明書をインポートしたものの、その証明書に必要な情報が含まれていない場合は、「戻る」をクリックして、別の証明書をインポートします。
「拡張プロファイル作成」を選択していた場合は、「セキュリティー証明書」パネルが表示された後に、「ポート」パネルがツールによって表示されます。
- カスタム・プロファイルに含まれているポートが固有のポートであるか、競合があってもそれが意図的な競合であることを確認し、「次へ」をクリックします。
ポートの競合解決
ポートの競合が疑われる場合は、
プロファイルの作成後、ポートの競合を調査することができます。
以下のファイルを調べて、プロファイル作成中に使用されたポートを確認します。
![[AIX]](../images/aixlogo.gif)
profile_root/properties/portdef.props ファイル
profile_root¥properties¥portdef.props ファイル
このファイルには、ポートの設定に使用された鍵と値が組み込まれています。ポートの競合が見つかった場合は、ポートを手動で再割り当てすることができます。
ポートを再割り当てするには、ws_ant スクリプトを使用して updatePorts.ant ファイルを実行します。
「プロファイル作成サマリー」パネルが表示されます。
- 「作成」をクリックしてカスタム・プロファイルを作成するか、
または「戻る」をクリックしてカスタム・プロファイルの特性を変更します。
「フェデレーション」パネルでカスタム・ノードの統合を選択した時点では、デプロイメント・マネージャーは実行中でアクセス可能な状態になっていたはずです。ここで「作成」をクリックする場合は、デプロイメント・マネージャーが実行中でアクセス可能な状態になっている必要があります。デプロイメント・マネージャーが実行中でなくなっていたりアクセス不能な状態になっていたりする可能性があると思う場合は、デプロイメント・マネージャーを始動してアクセス可能な状態にするか、既に実行中になっていればアクセス可能な状態にしてください。
実行中の構成コマンドを示す「Profile creation progress」パネルが表示されます。
プロファイルの作成が完了すると、「プロファイル作成の完了」パネルがツールによって表示されます。
- (オプション) 「ファースト・ステップ・コンソールの起動」を選択します。「終了」をクリックして終了します。
ファースト・ステップ・コンソールでは、追加のプロファイルを作成し、アプリケーション・サーバーを始動できます。
タスクの結果
カスタム・プロファイルが作成されました。プロファイル内のノードは、
ノードを統合し、デプロイメント・マネージャーを使用してノードをカスタマイズするまでは空です。
ディレクトリー構造は、
profiles ディレクトリー内に新規プロファイル・フォルダーを表示します。プロファイル・フォルダーは、
作成するプロファイルと同じ名前になります。
プロファイル管理ツールではなくコマンドを使用してプロファイルを作成する方法については、manageprofiles コマンドの説明を参照してください。
プロファイル管理ツールは、プロファイル作成中にログを作成します。
ログは install_dir/logs/manageprofiles ディレクトリーにあります。ファイルは manageprofiles_create_profile_name.log というパターンで命名されます。
次のタスク
ノードを作成したときに、ノードをデプロイメント・マネージャー・セルに統合していない場合は、
統合します。その後、デプロイメント・マネージャーを使用して、アプリケーション・サーバーをノードに作成します。
アプリケーションをデプロイして、開始します。
アプリケーションのデプロイを開始する方法については、製品のファスト・パスを参照してください。