WebSphere Application Server Network Deployment, Version 6.0.x   
             オペレーティング・システム: AIX , HP-UX, Linux, Solaris, Windows

             目次と検索結果のパーソナライズ化

デプロイメント・マネージャー・プロファイルの作成

このトピックでは、デプロイメント・マネージャーのランタイム環境の作成について説明します。

始める前に

プロファイル管理ツールを使用する前に、コア・プロダクト・ファイルをインストールします。

プロファイル管理ツールは、manageprofiles コマンドのグラフィカル・インターフェースです。詳しくは、wasprofile コマンド の説明を参照してください。

プロファイルを作成するための十分な一時スペースをシステムに用意する必要があります。 要件について詳しくは、プロファイル: ファイル・システム要件 のトピックを参照してください。

このタスクについて

Network Deployment 製品のコア・プロダクト・ファイルをインストール後、 プロファイルを作成する必要があります。作成するプロファイルは、デプロイメント・マネージャー・プロファイル、 アプリケーション・サーバー・プロファイル、またはカスタム・プロファイルの場合があります。

この手順では、プロファイル管理ツールによって提供されるグラフィカル・ユーザー・インターフェースを使用して、デプロイメント・マネージャー・プロファイルを作成する方法について説明します。デプロイメント・マネージャーは、1 つ以上のマシン上にある アプリケーション・サーバーの論理グループに、単一の管理インターフェースを提供します。

応答ファイルによって、グラフィカル・ユーザー・インターフェースを使用せずに、 サイレント・モードでプロファイル管理ツールを使用することができます。 サイレント・モードでのプロファイル管理ツールの使用例については、responsefile.pct.NDdmgrProfile.txt を参照してください。

また、manageprofiles コマンドを使用して、デプロイメント・マネージャーを作成することができます。詳細については、manageprofiles コマンドの説明を参照してください。

プロシージャー

  1. プロファイル管理ツールを開始して新しいランタイム環境を作成します。

    このタスクでは、ファースト・ステップ・コンソールからプロファイル管理ツールを選択します。

    1. コマンド・ウィンドウをオープンします。
    2. インストール・ルート・ディレクトリーの firststeps ディレクトリーに移動します。
      インストール・ルートは、以下のように、プラットフォームによって異なります。
      • [AIX] /usr/IBM/WebSphere/AppServer/firststeps
      • [HP-UX] [Linux] [Solaris] /opt/IBM/WebSphere/AppServer/firststeps
      • [Windows] C:¥Program Files¥IBM¥WebSphere¥AppServer¥firststeps
    3. firststeps コマンドを実行して、コンソールを開始します。
      • [Linux] [HP-UX] [Solaris] [AIX] ./firststeps.sh
      • [Windows] firststeps.bat
    4. コンソールでプロファイル管理ツール・オプションを選択します。

      プロファイル管理ツールは、マルチプラットフォーム・アプリケーション用の InstallShield です。ウィザードは、Java 2 SDK をロードして、ウェルカム・パネルを表示します。

    詳しくは、firststeps コマンド の説明を参照してください。

    ウィザードを開始する方法

    ウィザードを開始する方法はいくつかあります。
    • インストールの最後に、プロファイル管理ツールを開始するチェック・ボックスを選択します。
    • コマンド行からコマンドを直接実行します。

      コマンドは install_root/bin/ProfileCreator ディレクトリーにあります。 コマンド名は、以下のようにプラットフォームごとに異なります。
      • [AIX] pctAIX.bin
      • [HP-UX] pctHPUX.bin
      • [HP-UX] 64 ビット・プラットフォーム: pctHPUXIA64.bin
      • [Linux] pctLinux.bin
      • [Linux] 64 ビット・プラットフォーム: pct.bin S/390 プラットフォーム: pctLinux390.bin
      • [Linux] Power プラットフォーム: pctLinuxPPC.bin
      • [Solaris] pctSolaris.bin
      • [Windows] pctWindows.exe
      • [Windows] 64 ビット・プラットフォーム: pctWindowsIA64.exe
    • ファースト・ステップ・コンソールからプロファイル管理ツールを選択します。
    • [Windows] 「スタート」メニューを使用してプロファイル管理ツールにアクセスします。 例えば、「スタート」>「プログラム」または「すべてのプログラム」>「IBM WebSphere」 >「your_product」>「プロファイル管理ツールとクリックします。
  2. ウェルカム・パネルで「次へ」をクリックします。

    ウィザードは、「プロファイル・タイプの選択」パネルを表示します。

  3. デプロイメント・マネージャーを 作成するためのオプションを選択し、「次へ」をクリックします。

    「プロファイル名」パネルが表示されます。

  4. プロファイル・ディレクトリーの名前を指定するか、デフォルトを受け入れて、「次へ」をクリックします。
    プロファイル名のガイドライン: 2 バイト文字がサポートされています。プロファイル名は、次の制限を満たす固有の名前とすることができます。 プロファイルの名前を付ける際には、以下の文字を使用しないでください。
    • スペース
    • *&? など、ご使用のオペレーティング・システムのディレクトリー名にサポートされていない無効な特殊文字
    • スラッシュ (/) または (¥)

    デフォルト・プロファイル

    マシンで作成する最初のプロファイルは、デフォルト・プロファイルです。 デフォルト・プロファイルは、製品インストール・ルートの bin ディレクトリーから実行されるコマンドのデフォルトのターゲットです。 マシンにプロファイルが 1 つしかない場合、 すべてのコマンドは構成内のサーバー・プロセスに対してのみ動作します。

    マルチプロファイル環境におけるプロファイルのアドレッシング

    マシンに複数のプロファイルが存在する場合、特定のコマンドでは、コマンドが適用するプロファイルを指定する必要があります。 これらのコマンドでは、-profileName パラメーターを使用して、処理するプロファイルを識別します。 各プロファイルの bin ディレクトリーにあるコマンドを使用する方が効果的な場合があります。

    これらのコマンドは、以下の場所にあります。 コマンドは、2 行からなります。最初の行は、コマンド・ウィンドウの WAS_USER_SCRIPT 環境変数を設定します。 この変数は、プロファイルを処理するためにコマンド環境をセットアップします。 2 行目は、以下のディレクトリーにある実際のコマンドを呼び出します。

    実際のコマンドは、コマンド・シェルを照会して、 呼び出しプロファイルを判別し、呼び出しプロファイルに対するコマンドを自動的に処理します。

    ウィザードは、「プロファイル・ディレクトリー」パネルを表示します。

  5. デフォルトのディレクトリーを受け入れるか、デフォルト以外のロケーションを指定するか、または 「参照」をクリックして別のロケーションを選択します。「次へ」をクリックします。

    戻る」をクリックしてプロファイル名を変更する場合は、 このパネルが再表示されたときに、名前を手動で変更する必要があります。

    ウィザードは、「ノード名、ホスト名、セル名」パネルを表示します。

  6. 「ノード名、ホスト名、セル名」パネルで、 固有のノード名、マシンの実際のホスト名、 および固有のセル名を指定します。「次へ」をクリックします。

    デプロイメント・マネージャー・ノードには、以下の特性があります。

    フィールド名 デフォルト値 制約 説明
    ノード名 ご使用のマシンの名前、 またはマシン名の固有の導出。 デプロイメント・マネージャーの固有の名前を使用します。 この名前は、デプロイメント・マネージャー・セル内での管理に使用されます。
    ホスト名 ご使用のマシンの DNS 名。 ホスト名は、ご使用のネットワークを介してアドレス可能でなければなりません。

    ホスト名の考慮事項を参照してください。

    ご使用のマシンの実際の DNS 名または IP アドレスを使用して、ご使用のマシンとの通信を可能にします。 この表の後にある、ホスト名に関する追加情報を参照してください。
    セル名 デプロイメント・マネージャー・セルの任意の名前。セルは、デプロイメント・マネージャーの制御下にある、 管理対象ノードの論理グループです。 デプロイメント・マネージャー・セルに固有の名前を使用します。 V5 デプロイメント・マネージャー・セルをこの V6 デプロイメント・マネージャーにマイグレーション する場合は、V5 デプロイメント・マネージャーと同じセル名を使用してください。セル名は、同じ物理マシンまたはマシンのクラスター (SYSPLEX など) 上の、製品が稼働する環境では、どこでも固有でなければなりません。またセル名は、エンティティー間のネットワーク接続が、セル間で、または各セルとの通信が必要なクライアントから要求されるような環境では、どこでも固有でなければなりません。更に、セル名のネーム・スペースが統合されるような場合も、セル名が固有である必要があります。セル名が固有でないと、javax.naming.NameNotFoundException のような症状が起こり、固有名を持つセルの作成が必要になる可能性があります。 統合されたすべてのノードは、 このパネルで名前を付けた、デプロイメント・マネージャー・セルのメンバーになります。
    予約名: フィールド値として予約済みのフォルダー名を使用しないでください。 予約済みフォルダー名を使用すると、予測不能な結果が起こる可能性があります。 以下のワードは、予約されています。
    • cells
    • nodes
    • servers
    • clusters
    • applications
    • deployments

    ディレクトリー・パスの考慮事項

    [Windows] 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 アドレスを使用するとアドレスが固定化されるということです。 マシンの IP アドレスを変更したら、Express 構成文書の hostName プロパティーの 設定も必ず変更しなければなりません。 したがって、DHCP を使用するか、 あるいは IP アドレスを定期的に変更する場合は、数値 IP アドレスを使用しないでください。 もう一方の形式の欠点としては、ホストがネットワークから切断されるとノードを使用できないということがあります。

    デプロイメント・マネージャー特性の指定後に、ウィザードは、 「ポート値割り当て」パネルを表示します。

  7. デプロイメント・マネージャーに指定されたポートが固有であることを確認し、「次へ」をクリックします。
    次の場合、ポートは使用中とみなされます。
    • 現在のユーザーが実行するインストールでプロファイルに割り当てられた場合。
    「ポート値割り当て」パネルにアクセスすると、ポートの妥当性検査が行われます。 ポートはプロファイル作成が完了するまで割り当てられないので、「ポート値割り当て」パネルと「Profile Creation Complete」パネルの間でも競合が発生することがあります。
  8. dmgr プロセスを Windows プラットフォームで Windows サービスとして実行するかどうかを選択し、「次へ」をクリックします。

    [Windows] WebSphere Application Server では、startManager コマンドにより開始される dmgr プロセスの Windows サービスの開始を試行します。 例えば、デプロイメント・マネージャーを Windows サービスとして構成し、startManager コマンドを 実行すると、wasservice コマンドは定義されたサービスの開始を試行します。

    ローカル・システム・サービスをインストールするよう選択した場合、 ユーザー ID またはパスワードを指定する必要はありません。 指定されたユーザー・タイプのサービスを作成する場合は、サービスを実行するユーザーのユーザー ID およびパスワードを指定する必要があります。 ユーザーは、サービスを適切に実行するために、「サービスとしてログオン」権限を持っている必要があります。

    このインストール・タスクを実行するには、 ユーザー ID の名前にスペースが含まれていてはいけません。 また、この ID は管理者グループに属していなければならず、 拡張ユーザー権限「オペレーティング・システムの一部として機能」および「サービスとしてログオン」を備えている必要もあります。ユーザー ID が管理者グループに属しており、まだ拡張ユーザー権限がない場合は、 インストール・ウィザードはこれを認可します。

    インストール完了後にその他の Windows サービスを作成して、 別のサーバー・プロセスを開始することもできます。 詳しくは、サーバー・プロセスの自動再始動 を参照してください。

    IPv6 の考慮事項

    サービスがローカル・システム として実行されるように構成されている場合、IPv6 を使用すると、Windows サービスとして実行されるように作成されたプロファイルの開始は 失敗します。ユーザー固有の環境変数を作成して IPv6 を使用可能にします。この環境変数は、ローカル・システム 変数ではなくユーザー変数であるため、 その特定のユーザーとして実行される Windows サービスからのみアクセスできます。デフォルトで、 新規プロファイルが Windows サービスとして実行されるように作成および構成された場合、 サービスはローカル・システム として実行されるように設定されます。dmgr プロセスの Windows サービスで実行が試行された場合、 サービスは、IPv6 を指定するユーザー環境変数にアクセスできず、IPv4 として開始が試行されます。この場合、サーバーは正しく始動されません。 この問題を解決するには、 プロファイルを作成するときに、dmgr プロセスの Windows サービスが、ローカル・システム として実行されるのではなく、IPv6 を指定する環境変数が定義されているのと同じユーザー ID として実行されることを 指定します。

    ウィザードは、 「プロファイル作成サマリー」パネルを表示します。

  9. 次へ」をクリックしてデプロイメント・マネージャーを作成するか、または 「戻る」をクリックしてデプロイメント・マネージャーの特性を変更します。

    ウィザードは、プロファイルの作成中に「Status」パネルを表示します。インストールが完了すると、 ウィザードは「プロファイル作成が完了しました」パネルを表示します。

  10. 終了」をクリックして終了します。 アプリケーション・サーバー・プロファイルを作成するには、 ファースト・ステップ・コンソールでプロファイル管理ツールをクリックして、 ウィザードを再度開始します。

結果

デプロイメント・マネージャー・プロファイルが作成されました。プロファイル内のノード には、dmgr というデプロイメント・マネージャーがあります。

ウィザードではなく、コマンドを使用してプロファイルを作成する方法を確認するには、wasprofile コマンド を参照してください。

次の作業

アプリケーション・サーバー・プロファイルを作成し、 セルにノードを追加します。 これで、アプリケーションのデプロイ準備が整いました。

アプリケーションをデプロイして、開始します。

アプリケーションのデプロイを開始するには、WebSphere Application Server のファースト・パス を参照してください。




サブトピック
responsefile.pct.NDdmgrProfile.txt
関連タスク
wasprofile コマンド
ノード・ホスト名の変更
グラフィカル・ユーザー・インターフェースによるプロファイルの作成
関連資料
プロファイル: ファイル・システム要件
タスク・トピック    

ご利用条件 | フィードバック

最終更新: Jan 21, 2008 10:13:28 PM EST
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/index.jsp?topic=/com.ibm.websphere.nd.doc/info/ae/ae/tpro_instancesdmgr.html