z/OS 移行管理ツールを使用したデプロイメントマネージャー移行のための構成変数
WebSphere® Application Server を z/OS® に移行する前に、移行中に z/OS 上で実行するジョブ制御言語(JCL)ジョブ(CNTLおよびDATAデータセット)を作成する必要があります。 z/OS 移行管理ツールを使用して、移行定義を作成し、適切な移行ジョブをアップロードできます。 z/OS 移行管理ツールでは、デプロイメントマネージャーを移行するための定義を作成する際に、一連の設定変数が提示されます。
このトピックでは、プロファイル構成のマイグレーションについて説明します。 アプリケーションを最新バージョンに移行するには、 WebSphere Application Server Migration Toolkit を使用してください。
マイグレーション・ノード・タイプの選択
- マイグレーション・ノード・タイプ
- 移行するノード WebSphere Application Server の種類
- 複製マイグレーション
- 既存のプロファイルの複製マイグレーションを実行するには、このオプションを選択します。 複製マイグレーションを行うと、既存の環境と新しい環境を並行して稼働できます。 デプロイメント・マネージャーを複製した場合は、それが管理するすべての統合ノードを複製する必要があります。 しかし、デプロイメント・マネージャーを複製していない場合は、統合ノードを複製することはできません。
マイグレーション定義名
このセクションでは、 WebSphere Application Server の z/OS ノードを移行するために使用されるバッチジョブと手順を格納する移行定義名とディレクトリパスを特定します。- マイグレーション定義名
- z/OS 移行定義の名前。
この名前は、生成されるマイグレーションのジョブと命令を識別するために、ワークステーションで単独で使用されます。 選択された名前は、 z/OS の設定における WebSphere Application Server には影響しません。
- 応答ファイル・パス名 (オプション)
- ツールでプリインストールされるデフォルト値を含む応答ファイルの絶対パス名。
z/OS マイグレーション定義が 1 つ作成されるたびに 1 つの応答ファイルが書き込まれます 応答ファイルには、マイグレーション定義を作成するのに使用するすべての変数データが含まれ、同様のマイグレーション定義を定義する際にデフォルト値をプリインストールするのに使用することができます。 指定されたマイグレーション定義のための応答ファイルは、マイグレーション定義のルート・ディレクトリー内の migration_definition_name.responseFile ファイルに書き込まれます。
通常、定義しようとするマイグレーション定義と同じタイプのマイグレーション定義から応答ファイルを指定する必要があります。
注:z/OS ターゲットシステムにアップロードする移行定義に含まれるデータセットには、応答ファイルのコピーが含まれています。 この応答ファイルは z/OS システムでは使用されませんが、参考のために存在しています。 データ・セットのメンバー名は ZMMTDMGR です。
ターゲット・データ・セット
- 高位修飾子 (HLQ)
- ターゲット z/OS データセットに対する高レベルな修飾子であり、生成されたジョブと指示を含みます。z/OS の移行定義がターゲットの z/OS システムにアップロードされると、移行ジョブとファイルはパーティション化されたデータセットのペアに書き込まれます。 これらのデータセットを再利用することは可能ですが、移行対象となる各 z/OS システムごとに個別のデータセットを作成するのが最も安全です。注: データ・セットの高位修飾子として、マルチレベルの高位修飾子を指定することができます。
- HLQ.CNTL - マイグレーション・ジョブを含める、80 バイト固定ブロック・レコードをもつ区分データ・セット。
- HLQ.DATA - マイグレーション定義に含まれる他のデータを含める、可変長データをもつ区分データ・セット。
構成ファイル・システム
構成ファイル・システムは、マイグレーションされるノードの構成が物理的に保管される場所です。 移行対象ノードに適切なファイルシステムが既に存在する場合、既存のバージョン 9.0 ファイルシステムを使用することを選択できます。 既存の 9.0 ファイルシステムを使用する場合、このツールを使用して作成される移行ユーティリティ(BBOMDHFS、BBOMDZFS、BBOMDCPなど)を実行する前に、ここで指定するマウントポイントが存在していることを確認する必要があります。 移行対象ノードに新しい 9.0 ファイルシステムを作成する場合、実際のファイルシステム作成は、移行プロセス中にオプションのBBOMDHFSまたはBBOMDZFSジョブを実行するまで行われません。 いずれの場合にも、ここで、マウント・ポイントの正確な値を指定する必要があります。
構成マウント・ポイントでの正確な所有権および権限の設定に関する具体的な情報については、このツールにより生成されるカスタマイズ命令を参照してください。 生成された手順と「 z/OS デプロイメントマネージャーの移行 」を参照し、これらの変数の指定方法について詳細を確認してください。
- マウント・ポイント
- アプリケーション・データおよび環境ファイルが書き込まれる、読み取り/書き込みファイル・システム・ディレクトリー・マウント・ポイント。
このマウント・ポイントが存在していない場合、マイグレーション・プロセスはオプションのジョブ BBOMDHFS または BBOMDZFS を実行する際にマウント・ポイントを作成します。
- 名前
- マウント・ポイントで作成してマウントするファイル・システム・ データ・セット。
- SMS のボリュームまたは「*」
- データ・セットを格納する DASD ボリューム通し番号または「*」のどちらかを指定して、SMS にボリュームを選択させます。
「*」を使用する場合は、 ボリュームを選択できるように SMS 自動クラス選択 (ACS) ルーチンが準備されている必要があります。 SMS がデータ・セット割り振りを自動的に処理するようにセットアップされていない場合は、ボリュームを明示的にリストしてください。
- シリンダーの 1 次割り振り
- 構成ファイル・システムのデータ・セットに対するシリンダーでの
初期サイズ割り振り。
アプリケーション・サーバーでは、このデータ・セットに必要な総スペースは、 インストールされたアプリケーションのサイズと数に従って増えます。
推奨事項: 最小推奨サイズは420シリンダーです。 - シリンダーの 2 次割り振り
- シリンダーの個々の 2 次エクステントのサイズ。推奨: 最小推奨サイズは 100 シリンダーです。
- ファイル・システムのタイプ
- 階層ファイル・システム (HFS)
- HFS を使用して構成ファイル・システムを割り当ててマウントします。
- zSeries ファイルシステム (ZFS)
- ZFS を使用して構成ファイル・システムを割り当ててマウントします。
- ストレージ・クラス名 (オプション)
- 構成ファイル・システムの SMS ストレージ・クラスの名前。 名前を割り当てないと、値はストレージ管理者が確立した自動クラス選択ルーチンによって決定されます。
- 管理クラス名 (オプション)
- 構成ファイル・システムの SMS 管理クラスの名前。 名前を割り当てないと、値はストレージ管理者が確立した自動クラス選択ルーチンによって決定されます。
- データ・クラス名 (オプション)
- 構成ファイル・システムのデータ・クラスの名前。 名前を割り当てないと、値はストレージ管理者が確立した自動クラス選択ルーチンによって決定されます。
データ・セット名および製品ディレクトリー
- JCL プロシージャー・ライブラリーのデータ・セット名
- 既存のプロシージャライブラリ。ここに、` z/OS ` カタログのプロシージャに対する ` WebSphere Application Server ` をコピーする。
- WebSphere Application Server 製品ディレクトリ
- WebSphere Application Server バージョン 9.0 のインストール済み製品ファイルシステムの場所。
- 中間シンボリック・リンク
- 中間シンボリック・リンクをセットアップする場合にこのオプションを選択します。選択した場合は、該当リンクのパス名を指定します。
中間シンボリック・リンクを指定した場合、 シンボリック・リンクは構成ファイル・システムから中間シンボリック・リンクに作成されます。 指定しない場合は、製品ファイル・システムに直接作成されます。
中間シンボリック・リンクのパス名を指定するには、このオプションを選択します。 このリンクは、カスタマイズ・ジョブによって作成され、製品ファイル・システム・ディレクトリーを指します。- 中間シンボリック・リンクのパス名
- 中間シンボリック・リンクのパス名。
サーバーのカスタマイズ (パート 1)
- 構成ロケーションから
- マウント・ポイント
- マイグレーション元の構成のマウント・ポイント。
- ホーム・ディレクトリー
- マイグレーション元の構成のホーム・ディレクトリー。
- 構成ロケーションへ
- マウント・ポイント
- マイグレーション先の構成のマウント・ポイント。
これは、先に「構成ファイル・システム」パネルで指定したものです。
- ホーム・ディレクトリー
- マイグレーション先の構成のホーム・ディレクトリー。
- デーモン・プロシージャー名
- マイグレーションされたデーモンを開始するのに使用する JCL 開始済みプロシージャーの名前。
バージョン 9.0 に移行する際には、JCL開始プロシージャをアップグレードする必要があります。 新規の開始済みプロシージャーは、マイグレーション中に生成されます。 デーモン・プロシージャーに新しい名前を指定するか、または古いデーモン・プロシージャーを使用することができます。
- コントローラー・プロシージャー名
- マイグレーションされたコントローラーを開始するのに使用する JCL 開始済みプロシージャーの名前。
バージョン 9.0 に移行する際には、JCL開始プロシージャをアップグレードする必要があります。 新規の開始済みプロシージャーは、マイグレーション中に生成されます。 コントローラー・プロシージャーに新しい名前を指定するか、または古いコントローラー・プロシージャーを使用することができます。
- サーバント・プロシージャー名
- マイグレーションされたサーバントを開始するのに使用する JCL 開始済みプロシージャーの名前。
バージョン 9.0 に移行する際には、JCL開始プロシージャをアップグレードする必要があります。 新規の開始済みプロシージャーは、マイグレーション中に生成されます。 サーバント・プロシージャーに新しい名前を指定するか、または古いサーバント・プロシージャーを使用することができます。
- 開始済みプロシージャーのコマンド名の置き換え
- JCLプロシージャに新しい名前を指定した場合、設定 WebSphere Application Server 内の対応するSTARTコマンドは、新しいプロシージャ名に合わせて更新する必要があります。 構成の更新を実行するにはこのオプションを選択します。
同じプロシージャー名を使用する場合は、 このオプションを選択しないでください。 マイグレーション中のノードの特定プロセス・タイプ (例えば、すべてのサーバント) のすべてのサーバーに一貫して同じプロシージャー名を使用しない場合は、このオプションを選択しないことをお勧めします。 この場合、同じ START コマンドのままで、マイグレーション中にテンプレートとして生成されたプロシージャーを使用して、 手動でプロシージャーを置き換える必要があります。
注:- 9.0 バージョンの設定では、 7.0 バージョンで使用されているものとは異なるJCLプロシージャを使用する必要があります。 移行プロセスは、ここで指定されたプロシージャ名を使用して、新しいバージョン 9.0 のJCLプロシージャを作成します。
- バージョン 7.0 の構成で使用したものと同じ名前を使用する場合、マイグレーション・プロセスは既存のプロシージャーをオーバーレイします。 同じ名前を使用している場合は、後でロールバックが必要となる場合に備えて、マイグレーション・ジョブを実行する前に、バージョン 7.0 の既存のプロシージャーを必ずバックアップするようにしてください。
- 複製マイグレーションを実行するオプションを選択した場合、このオプションは使用できません。
- WebSphere 管理者のユーザーID
- マイグレーション・プロセスでは、管理クライアントを使用することを要求されます。 ソースプロファイルで管理セキュリティが有効になっている場合、「 管理セキュリティが有効 」オプションを選択し、管理クライアントが認証に使用できる有効な WebSphere 管理者のユーザーIDを指定します。 それ以外の場合は、 「管理セキュリティーが使用可能である場合」オプションを選択解除します。
ユーザー ID の入力を据え置き、後で手動により BBOWMG3D、BBOWDPRO、BBOWDPRE、または BBOWDPOS の各ジョブを編集することもできます。 これを行うには、「管理セキュリティーが使用可能である場合」オプションを選択解除し、ジョブを実行依頼する前に、正しいユーザー ID で
TO_AdminUserid変数を更新します。 - WebSphere 管理者パスワード
- マイグレーション・プロセスでは、管理クライアントを使用することを要求されます。 ソースプロファイルで管理セキュリティが有効になっている場合は、 [管理セキュリティが有効 ] オプションを選択し、管理クライアントが認証に使用できる有効な WebSphere 管理者パスワードを指定してください。 それ以外の場合は、 「管理セキュリティーが使用可能である場合」オプションを選択解除します。
パスワードの入力を据え置き、後で手動により BBOWMG3D、BBOWDPRO、BBOWDPRE、または BBOWDPOS の各ジョブを編集することもできます。 これを行うには、「 管理セキュリティが有効 」オプションの選択を解除してください。 ジョブを送信する前に、変
TO_AdminPassword数を適切なパスワードで更新してください。
サーバーのカスタマイズ (パート 2)
- 前のデプロイメント・マネージャーを使用不可にします
マイグレーション中に以前のデプロイメント・マネージャーを使用不可にするかどうかを指定します。 複製マイグレーションを実行するオプションを選択した場合、このオプションは使用できません。
ソース・デプロイメント・マネージャーが使用不可にされていない場合、マイグレーションの実行中でも使用を継続できます。注意:このオプションは慎重に使用してください。 WebSphere Application Server のデプロイメントマネージャーが通常停止および無効化される理由は、複数のデプロイメントマネージャーが同一ノードを管理することを防止するためです。 Version 9.0 デプロイメント マネージャーを使用する前に、ソース デプロイメント マネージャーを停止する必要があります。 このオプションの選択を解除すると、マイグレーション中に旧構成で行われたいずれの構成変更もマイグレーションされません。- アプリケーションのマイグレーション設定
- インストール済みのアプリケーションのマイグレーション方法を指定します。注記: ここで設定された値にかかわらず、 WebSphere Application Server システムアプリケーションは移行されます。
- アプリケーションをマイグレーションし、デフォルトのアプリケーション・インストール・ディレクトリーを使用します
- マイグレーションの一部として、ユーザー・エンタープライズ・アプリケーションをデフォルトのアプリケーション・インストール・ディレクトリーにインストールします。
- アプリケーションをマイグレーションし、指定されたアプリケーション・インストール・ディレクトリーを使用します
- マイグレーションの一部として、ユーザー・エンタープライズ・アプリケーションを指定されたアプリケーション・インストール・ディレクトリーにインストールします。
- アプリケーションのインストール・ディレクトリー
- WebSphere Application Server がエンタープライズアプリケーションをインストールする場所。
アプリケーションをアプリケーションのマイグレーション設定に従ってマイグレーションおよびインストールしたいことを指定する際にこのロケーションを使用します。 環境に合わせてカスタマイズしたロケーションを選択するか、デフォルトのロケーションを使用できます。
- アプリケーションを後でインストールするための管理スクリプトのマイグレーションと生成
- 移行中にインストールせずに、 WebSphere Application Server バージョン 9.0installableApps ディレクトリへのインストール用にユーザー企業アプリケーションを準備します。これらのアプリケーションをインストールする際に使用できるスクリプトが生成され、マイグレーション・バックアップ・ディレクトリーに保存されます。 z/OS の場合 WebSphere Application Server、このバックアップディレクトリの位置は、同じパネルで指定する一時ディレクトリからの相対パスとなります。 バックアップ・ディレクトリーのロケーションは、派生マイグレーション ID およびマイグレーションされるノードのタイプによって決定されます。 例えば、一時ディレクトリーとして /tmp/migrate を指定したとき、派生したマイグレーション ID が 55449 だとすれば、生成されたスクリプトのロケーションは次のようになります。
ここで、nodetype は、マイグレーションされるノードのタイプによって、dmgr、fed、または base です。/tmp/migrate/55449/nodetype_backup/これらのファイルは、マイグレーション完了後に任意の時点および任意の組み合わせで実行することができます。 また、アプリケーションのインストールをより効率的に行うために、これらのファイルを再編成して結合することもできます。 追加情報については、資料の『wsadmin ツール』の項目を参照してください。
- アプリケーションをマイグレーションし、前のアプリケーション・インストール・ディレクトリーを使用します
- マイグレーションの一部として、ユーザー・エンタープライズ・アプリケーションをインストールして、以前のバージョンと同じアプリケーション・インストール・ディレクトリーを保持します。制限事項: このオプションを選択すると、既存の WebSphere Application Server インストールと Version 9.0 インストールでロケーションが共有されます。 マイグレーションされたアプリケーションを以前のバージョンのアプリケーションと同じロケーションに保持する場合は、以下の制約事項が適用されます。
- WebSphere Application Server バージョンにおける 9.0 の混合ノードサポートの制限事項を遵守する必要があります。 つまり、wsadmin コマンドを呼び出す場合に以下のサポートは使用できません。
- JSP のプリコンパイル
- バイナリー構成の使用
- EJB のデプロイ
- 後になって、古いインストール済み環境を管理する (例えば、アンインストール) ときにこれらのロケーションからアプリケーションを削除すると、マイグレーションされたアプリケーションを意図せずに失う危険性があります。
- ソースリリース内の変数に関連付けられてインストールされるアプリケーションは、 Version 9.0 でその変数に割り当てられた場所に関連付けられてインストールされます。 つまり、絶対ロケーションは保持されません。 アプリケーションは、新しいバージョン 9.0 環境内の相対的な場所へ移行されます。移行 deployment.xml 対象アプリケーションのファイル内の binariesURL が、 WebSphere Application Server に対する相対パス(つまり、 $(APP_INSTALL_ROOT)`/ $(WAS_INSTALL_ROOT)`、`/`などで始まるパス)を指定している場合、アプリケーションが新しい場所にインストールされると、新しい WebSphere Application Server 変数の値が使用されてパスが解決されます。 このオプションを選択する場合は、以下の結果になります。
- WebSphere Application Server 変数に対する相対ディレクトリ位置にインストールされたアプリケーションは、 Version 9.0 において、その変数値の下にインストールされます。
- 変数 WebSphere Application Server に対して相対的なディレクトリ位置にインストールされていないアプリケーションは、同じディレクトリ内で移行および上書きされます。 アプリケーションが /employee_records/retrieval_Apps ディレクトリー内にインストールされた場合は、例えば、アプリケーションは /employee_records/retrieval_Apps ディレクトリーにマイグレーションされ、上書きされます。
- WebSphere Application Server バージョンにおける 9.0 の混合ノードサポートの制限事項を遵守する必要があります。 つまり、wsadmin コマンドを呼び出す場合に以下のサポートは使用できません。
- アプリケーションをマイグレーションしない
- ユーザー・エンタープライズ・アプリケーションに関して何も行わないでください。
- 管理コンソール・カスタマイズの「マイ・タスク」設定のマイグレーション
- 「マイタスク」は、 WebSphere Application Server バージョン 7.0 以降でのみサポートされています。
- デフォルトのワークスペース・ユーザー・ルート・ロケーション (wstemp) に保存されている「マイ・タスク」の設定のマイグレーション
- ユーザー定義のワークスペース・ルート・ロケーションに保存されている「マイ・タスク」の設定のマイグレーション
- ユーザー定義のワークスペース・ルート・ロケーション
サーバーのカスタマイズ (パート 3)
- ショート・ネーム
- セルのショート・ネーム
- バージョン 9.0 セルの新規ショート・ネームを指定します。
- ノードのショート・ネーム
- バージョン 9.0 ノードの新規ショート・ネームを指定します。
- サーバーのショート・ネーム
- バージョン 9.0 サーバーの新規ショート・ネームを指定します。
- クラスター・ショート・ネームの接頭部
- ショート・ネームの接頭部を最大 3 文字で指定します。 これは、バージョン 9.0 セルの固有のクラスター・ショート・ネームを生成するために使用されます。
- サーバー・ショート・ネームの接頭部
- ショート・ネームの接頭部を最大 3 文字で指定します。 これは、バージョン 9.0 セルの固有のサーバー・ショート・ネームを生成するために使用されます。
- デーモンのジョブ名
- 新しい環境でのロケーション・サービス・デーモンのジョブ名を指定します。 この名前は、古い環境内のデーモンとは異なるものでなければなりません。
マイグレーション・プロセスのオプション
- マイグレーション・トレースのオプション
トレースの使用可能化を選択する場合、 すべてのマイグレーション・プロセスの間、トレースは使用可能のままです。
- スクリプトのトレースを使用可能にする
- Home の作成、プロファイルおよびマイグレーション・ツールの呼び出し、およびマイグレーションの最終処理段階のトレースを使用可能にするかどうかを指定します。
- プロファイル作成のトレースを使用可能にする
- プロファイル作成中のトレースを使用可能にするかどうかを指定します。
- アップグレード前のトレースを使用可能にする
- WASPreUpgrade プロセス中のトレースを使用可能にするかどうかを指定します。
- アップグレード後のトレースを使用可能にする
- WASPostUpgrade プロセス中のトレースを使用可能にするかどうかを指定します。
- マイグレーション・プロセスの JVM オプション
- 初期ヒープ・サイズ (MB)
- JVM ヒープ用に割り振られる初期メモリー。
- 最大ヒープ・サイズ (MB)
- JVM ヒープ用に割り振ることができる最大ヒープ・サイズ。
- 一時ディレクトリーの位置
- 前の構成のバックアップとマイグレーション・トレースが書き込まれるディレクトリー。
マイグレーション中に、前バージョンの構成のバックアップ・コピーが必要になります。 このバックアップのデフォルト・ロケーションは /tmp/migrate です。 /tmp ファイル・システムに、バックアップ構成を保管するのに十分なスペースがない場合は、別のロケーションを指定することができます。 バックアップ・コピーのデフォルト・ロケーションの オーバーライドを選択する場合のベスト・プラクティスは、同じ命名規則を保持し、 /tmp 部分を /myTemp/migrate などの別のパスに 置き換えることです。
- マイグレーション定義 ID
- 一時ディレクトリーの下にディレクトリーを作成する際に使用される ID。 作成されるディレクトリーには、一時的なマイグレーション・データ・セットとバックアップ構成データが格納されます。
- Java™ 一時ディレクトリ
- 移行中にJava仮想マシンが一時ファイルの作成と保存に使用するJava一時ディレクトリを指定できます。
- Javaの一時ディレクトリを設定する
- Java 一時ディレクトリー・ロケーション
ポート値
新しいプロファイルで使用するポート値と、ポート競合をどのように処理するのかを定義します。 古いプロファイルからのポート値を再使用する場合、 ポート競合のため、新しいプロファイルを古いプロファイルと同時に実行することはできません。 同時に両方のプロファイルを実行する予定の場合、 各プロファイルが異なるポートを使用するようにしてください。
- 古いプロファイルが使用していたのと同じポートを使用する (Use the same ports that the old profile used)
- ソース・プロファイルに定義されているポート値を再使用します。注: クローン移行のオプションを選択した場合、このオプションは表示されません。
- 手動でポートを選択する (Select ports manually)
- 次のパネルでターゲット・プロファイル中の各ポートに対してカスタム値を設定します。
- 共通の開始ポート値から増分して新しいポートを生成する (Generate new ports, incrementing from a common starting port value)
- 指定したポート値から新規ポートを生成します。 競合するポートは自動的に解決されます。
- ポートの競合解決
- ポート競合をどのように解決するのかを選択します。
- 競合ポート値から増分する (Increment from the conflicted port value)
- ポートの競合が検出された場合、競合するポートから始めて、次に使用可能なポート値になるまでポート値が増やされます。
- 共通開始ポート値から増分する (Increment from a common starting port value)
- ポートの競合が検出された場合、指定された値から始めて、次に使用可能なポート値になるまでポート値が増やされます。
JOB ステートメント定義
調整されるすべてのマイグレーション・ジョブでは JOB ステートメントが必要です。インストール済み環境に有効な JOB ステートメントを入力します。 マイグレーションの作成プロセスによって、すべての生成されたジョブでジョブ名が更新されます。そのため、JOB ステートメントのその部分に関して気にかける必要はありません。 継続行が必要であれば、コメント行を継続行で置き換えます。