CA SDM サーバにわたるシステム カスタマイズのバージョン管理方法

CA SDM のバージョン管理は、すべての CA SDM サーバにわたる(クライアントおよびサーバ)システム カスタマイズを管理するのに役立ちます。 CA SDM の設定に応じて、以下のクライアントおよびサーバが使用されます。
casm173
CA SDM のバージョン管理は、すべての CA SDM サーバにわたる(クライアントおよびサーバ)システム カスタマイズを管理するのに役立ちます。 CA SDM の設定に応じて、以下のクライアントおよびサーバが使用されます。
  • 標準設定
    • クライアント: セカンダリ サーバ
    • サーバ: プライマリ サーバ
  • 高可用性設定
    • クライアント: アプリケーション サーバおよびスタンバイ サーバ
    • サーバ: バックグラウンド サーバ
例: システム管理者として、CA SDM の detail_usp_server.htmpl ページにフィールドを追加しました。 ここで、クライアントとサーバにわたってこの変更を同期します。 この例は、カスタマイズがどのように同期されるかを説明するために、シナリオ全体にわたって使用されます。
以下の図は、CA SDM サーバにわたってシステム カスタマイズのバージョン管理を行う方法を示しています。
CA SDM サーバにわたるシステム カスタマイズのバージョン管理方法を示す図
以下の手順に従います。
  1. CA SDM で変更を加えます。 この例では、CA SDM の HTMPL ページに新しいフィールドに追加します。
前提条件の確認
以下の前提条件を確認します。
  • ver_ctl オプションに
    アップグレード
    値が設定されていることを確認します。 バージョンの相違が検出されると、影響を受けたコンポーネントのアップグレードがクライアントで試行されます。 アップグレードが成功すると、サーバとクライアントの接続が継続されます。失敗すると、接続は終了します。 ver_ctl オプションの詳細については、
    オンライン ヘルプ
    を参照してください。
  • (CA SDM の設定に応じて)プライマリ サーバまたはバックグラウンド サーバの $NX_ROOT\site\mods ディレクトリに server_secondary_custom.ver ファイルが作成されることを確認します。 バージョン管理コンポーネントへのカスタマイズを、すべてこのファイルで実行する必要があります。 ファイルが存在しない場合は、同じ場所にそれを確実に作成します。
サーバ バージョン管理ファイルの変更
カスタマイズ(HTMPL ページでのフィールドの追加など)を完了した後、サーバ バージョン管理ファイルでバージョン管理コンポーネントを追加または更新します。 バージョン管理コンポーネントは、ファイル、ディレクトリ、または client_nx.env 環境変数ファイルを表すことができます。
以下の手順に従います。
  1. CA SDM の設定に応じて、以下のサーバにログインします。
    • 標準: プライマリ サーバ
    • 高可用性: バックグラウンド サーバ
  2. 以下のディレクトリに移動します。
    $NX_ROOT\site\mods
  3. server_secondary_custom.ver ファイルを開きます。
  4. 以下のコンポーネントを追加します。
    [ MY_USP_SERVERS_HTMPL ] directory="$NX_ROOT/site/mods/www/htmpl/web/analyst/Analyst" filename="detail_usp_servers.htmpl" version="2.0 , 20121119" o_mode="RW" g_mode="RW" w_mode="RW" file_ctl
    バージョン管理コンポーネントの追加または更新の詳細については、「バージョン管理コンポーネント」を参照してください。
  5. server_secondary_custom.ver ファイルを保存します。
    バージョン管理コンポーネントが、バージョン管理ファイルに追加されます。
バージョン管理コンポーネント
新しいコンポーネントを定義するには、
  • 以下の構文を使用します。
    斜体
    の項目は管理者が指定するデータを表しています。
    コンポーネント名
    とバージョン パラメータは、常に必須です。 その他のパラメータは、
    control-type
    の値によっては必須です。 その他の項目はすべてキーワードを表しており、以下の例のとおり正確に入力する必要があります。
    [ component-name ] version = "x.x, yyyymmdd" control-type filename = "filename" directory = "directory" link = "link-directory" source = "source-directory" effectivity = "effect-spec" checksum min_release = "release" max_release = "release" component_type = "file-type" o_mode = "owner-mode" g_mode = "group-mode" w_mode = "world-mode"
    パラメータの詳細については、「バージョン管理のパラメータ」を参照してください。 バージョン管理ファイルの構造と構文の詳細については、$NX_ROOT\site ディレクトリにインストールされている .ver ファイルを参照してください。 これらのファイルには、役に立つコメントと設定例が含まれています。
既存のコンポーネント エントリを更新するには、
  • パラメータを変更します。 たとえば、バージョン番号を変更します。
コンポーネントからコントロールを削除するには、
  • 以下のようにコンポーネントを編集します。
    ! uncontrol component-name
バージョン管理のパラメータ
Version Controlでは以下のパラメータを使用します。
  • [ コンポーネント名 ]
    Version Controlでの項目の名前を指定します。 名前は、角かっこで囲まれた一意の文字列である必要があります。
    コンポーネント名
    の大文字と小文字は区別されません。 このパラメータは、コンポーネント定義を開始するのに必須のパラメータです。
  • version="x.x. yyymmd"
    コンポーネントのバージョンを定義するバージョン番号(
    x.x
    )と日付(
    yyyymmdd
    )を指定します。 このパラメータは必須で、二重引用符で囲む必要があります。 Version Controlは、サーバとクライアントのバージョン番号と日付を比較してコンポーネントのバージョンを確認します。 クライアントとサーバ間でコンポーネントが同期されていると見なされるためには、バージョン番号と日付の両方が一致している必要があります。 また、checksumプロパティが有効な場合、ファイルが更新される前にチェックサムの確認が行われます。
  • control-type
    このコンポーネントのVersion Controlのタイプを指定します。 control-type の有効な設定は以下のとおりです。
設定
説明
dir_ctl
コンポーネントがディレクトリを表すことを指定します。 ディレクトリへのパスを指定するには、ディレクトリ パラメータを指定する必要があります。 ファイル名パラメータを指定して、ディレクトリ内の一連のファイルをフィルタするファイル名パラメータを指定することもできます。 UNIXでもWindowsでもサブディレクトリはアップグレードされません。
file_ctl
コンポーネントがファイルを表していることを指定します。 ファイルへのパスを指定するには、ディレクトリおよびファイル名パラメータを指定する必要があります。
nxenv_ctl
このコンポーネントが client_nx.env ファイルを表していることを指定します。このファイルは、内部の CA SDM 環境変数を保存するのに使用されます。 CA SDM のバージョン管理およびオプション マネージャは、このファイルを自動的にメンテナンスします。 nxenv_ctl コンポーネントは 1 つだけで、コンポーネント名は CLIENT_NXENV にする必要があります。
ver_ctl
これが初期設定のControlタイプです。 コンポーネントが汎用である(つまり、特定の外部オブジェクトに関連付けられていない)ことを指定します。 汎用コンポーネントを使用して、クライアント全体のVersion Control、または自動アップグレードには大きすぎるファイルまたはディレクトリのVersion Controlを提供することができます。 Controlタイプがver_ctlのコンポーネントはアップグレードできません。サーバがUPGRADEモードのときにver_ctlコンポーネントのバージョンが一致しないと、クライアントの接続が失敗します。
  • filename = "ファイル名"
    Version Controlでのファイルの名前を指定します。 ディレクトリの仕様は含まれていません。 このパラメータは、file_ctlコンポーネントで必須ですが、ディレクトリ(dir_ctl)管理コンポーネントではオプションです。 ディレクトリ コンポーネントと共に使用した場合、ファイル名パラメータはdir_ctlコンポーネントに関連付けられているファイルを制限するファイル マスクとして機能します。 たとえば、dir_ctlコンポーネントのファイル名が*.READMEの場合、そのディレクトリでアップグレードされるファイルにはファイル名が「.README」で終了しているファイルだけが含まれるようになります。
  • directory = "ディレクトリ"
    dir_ctlコンポーネントのディレクトリへのパスを指定します。または、file_ctlコンポーネントのファイルが含まれているディレクトリへのパスを指定します。 このパラメータは、ver_ctlおよびnxenv_ctlコンポーネントでは無視されます。 ディレクトリ パスは、引用符で囲む必要があります。先頭に$が付いている環境変数への参照を含むことができます。
    Windows サーバの場合でも、必ず円記号ではなくスラッシュを使用してパス名のサブディレクトリを区切ってください。
  • link = "リンクディレクトリ"
    前述したディレクトリ パラメータと同じ形式で、クライアント上のリンク ディレクトリを指定します。 このパラメータは、file_ctlおよびdir_ctlコンポーネントではオプションで、ver_ctlおよびnxenv_ctlコンポーネントでは無視されます。 指定した場合、Linuxクライアントがアップグレードされると、ディレクトリ パラメータによって指定されたロケーションにコピーされた実際のファイルを指すシンボリック リンクがリンク ディレクトリに配置されます。 Windowsクライアントがアップグレードされると、リンク ロケーションとディレクトリ ロケーションの両方に実際のファイルがコピーされます。
  • source = "ソースディレクトリ"
    (オプション パラメータ)サーバが配布するファイルを取得可能な、サーバ上の異なるディレクトリを指定します。 このパラメータの形式は、前述したディレクトリ パラメータの形式と同じです。 このパラメータは、クライアントに配布するファイルが、サーバ上のディレクトリ ロケーションにある同じファイルと異なる場合に役立ちます。 このパラメータは、
    ソースディレクトリ
    からファイルを取得して、それをディレクトリ パラメータによって指定されたクライアント上のロケーションに配布することをサーバに通知するのに使用します。 ソース パラメータを指定した場合は、ディレクトリ パラメータを指定する必要があります。
  • effectivity = "有効性の仕様"
    (オプション)クライアントがこのコンポーネントを取得するかどうかを指定します。 これにより、一部のクライアントへのダウンロードを除外することができます。 クライアントが有効性の仕様に含まれていない場合、クライアントはコンポーネントを取得しません。 このパラメータを指定しなかった場合、すべてのクライアントがコンポーネントを受け取ります。 有効性の仕様では、以下の記号を使用します。
    • +(プラス記号)
      クライアント グループを追加することを示します。
    • -(マイナス記号)
      クライアント グループを除外することを示します。
有効なクライアント グループは、以下のとおりです。
  • SUN4SOL
  • AIX
  • LINUX
  • LINUX390
  • HP
  • WINDOWS_CLIENTS
  • UNIX_CLIENTS
たとえば、以下の仕様は、UNIXクライアントだけがファイルを取得することを示します。
effectivity = "+ UNIX_CLIENTS"
  • checksum
    クライアント上のコンポーネントのチェックサムがサーバ上の対応するチェックサムと一致しなかった場合に、コンポーネントをアップグレードすることを指示します。 ディレクトリに適用した場合、チェックサムは各ファイルに適用されます。
  • min_release = "リリース"およびmax_release = "リリース"
    このコンポーネントの配布先にする最も古いクライアントと最も新しいクライアントを指定します。 server_default.verファイル内のステートメントは、リリースを定義します。 これらのパラメータは、以下の形式になっています。Ga
    xx
    はリリースを示し、それに続く値はリリースに関連付けられている genlevel です。
    ! Release GA50 50MVV000900 50W7T000900 ! Release GA45 45MW000900 50WTT000900
    順番は、GA50の方がGA45よりも新しいことを示しています。
  • component_type
    使用するコンポーネントのタイプを指定します。 以下のタイプのコンポーネントが使用されます。
設定
説明
ファイル
これは初期設定のコンポーネント タイプです。 クライアントにコピーしたファイルを、ディレクトリ パラメータで示されているサーバ上のロケーションから直接取得することを指定します。
exe_file
クライアントにコピーするファイルを、クライアントのオペレーティング システムに依存する以下のサーバ上のロケーションから取得することを指定します。
windows(Windows)
sun4Sol(Solaris)
hp(HP-UX)
aix -- AIX)
linux(Linux)
linux390(Linux390)
これらのサブディレクトリのロケーションは、ディレクトリ パラメータ設定に依存します。 このパラメータを設定した場合、サブディレクトリは指定した
ディレクトリ
の下に配置されます。 それ以外の場合、メインの CA SDM インストール ディレクトリの bin ディレクトリに配置されます。
  • o_mode = "所有者モード"
    ファイルの所有者に対してファイル アクセス許可を指定します。
  • g_mode = "グループモード"
    ファイル所有者のグループに属しているユーザのファイル アクセス許可を指定します(UNIXクライアントでのみ使用されます)。
  • w_mode = "ワールドモード"
    ファイル所有者のグループに属していないユーザのファイル アクセス許可を指定します(UNIXクライアントでのみ使用されます)。
    3つのモード パラメータを使用して、サーバ上で同じ実行可能ファイルの異なるバージョンを管理できます。 これらは、クライアントにコピーしたときにファイルのアクセス制御を指定します。 これらのパラメータは、アップグレード操作中にだけ使用されます。 これらは以下の意味を持つ1~3個の文字で構成されます。
設定
説明
R
読み取り
W
書き込み
X
Execute
PCクライアントは書き込み許可と実行許可を無視します。
1つ以上のファイル アクセス モードを任意の組み合わせで指定できます。 UNIXクライアントの場合、ファイルには指定したアクセス モードが与えられます。 PCクライアントの場合、w_modeを指定したかどうかにより、ファイルは書き込み可能または読み取り専用になります。
クライアントでの CA SDM の再起動
クライアント サーバで CA SDM を再起動して、カスタマイズでクライアント バージョン管理ファイルを更新します。
[スタート]
-
[設定]
-
[コントロール パネル]
-
[管理ツール]
-
[サービス]
を選択します。 [
CA SDM Server
]を右クリックし、[
開始
]を選択してサーバを再起動または開始します。
以下の手順に従います。
  1. 標準設定では、セカンダリ サーバを再起動します。
  2. 高可用性設定では、以下の手順に従います。
    1. すべてのスタンバイ サーバを再起動します。
    2. アクティビティの少ないアプリケーション サーバを再起動します。
    3. アプリケーション サーバを起動します。
    4. ほかのアプリケーション サーバに対して手順 d および e を実行します。
    クライアントは、サーバに接続して、管理されているコンポーネントのリストを送信します。 サーバは、そのリストとサーバに保存されているマスタ リストを比較します。 クライアント上の影響を受けるコンポーネントがアップグレードされます。
アクティビティの少ないアプリケーション サーバの選択
ユーザ アクティビティが最も少ないアプリケーション サーバを選択します。 各アプリケーション サーバに対して以下のコマンドを実行し、アクティブなセッションが最少または存在しないサーバを選択します。
pdm_webstat
: このコマンドでは、SOAP または REST Web サービス セッションはキャプチャされません。
ほかのアプリケーション サーバの停止
アプリケーション サーバを停止する前に、アプリケーション サーバ上のすべてのアクティブなユーザに対して、アクティビティの少ないアプリケーション サーバに移動するように通知します。 アクティビティの少ないアプリケーション サーバにすべてのユーザを移動する前に、そのサーバを再起動したことを確認します。
以下の手順に従います。
  1. (推奨)停止するアプリケーション サーバ上のすべてのアクティブな アナリストに対して、そのセッション情報を使用して CA SDM のチケットを作成するように通知します。 このプロセスにより、セッション情報が失われないようになります。 たとえば、 サポート オートメーション アナリストが、ハードウェアの問題を解決するために顧客とセッション中だとします。 このような場合、アプリケーション サーバがシャット ダウンする前に、サポート オートメーション アナリストは、そのセッション情報を使用して CA SDM で問題を作成できます。
  2. アプリケーション サーバ上のすべてのアクティブなユーザに対して、再起動したアクティビティの少ないアプリケーション サーバに移動するように、通知(電子メール通知など)を送信します。 この通知には、更新されたアプリケーション サーバの詳細を含めることができます。
  3. アプリケーション サーバ上で、以下のコマンドを実行します。
    pdm_server_control [-h] -q interval -s server_name
    • -h
      ヘルプ ページを表示します。
    • -q interval -s server_name
      ローカルまたはリモート アプリケーション サーバに指定された時間間隔内に休止するよう通知します。 この間隔は、サーバがオフラインになるまでの秒数です。 server_name を指定せずにこのオプションを使用すると、ローカル サーバに休止するよう通知されます。 このオプションは、バックグラウンドまたはスタンバイ サーバには使用できません。
    アプリケーション サーバ上のすべてのアクティブなユーザにポップアップ メッセージが表示され、サーバのシャットダウンとシャットダウンまでに残された時間が通知されます。 ユーザは自分の作業を保存し、その時間内にログアウトする必要があります。 アプリケーション サーバは指定された時間の後に停止します。 ユーザが自分の作業を再開するには、ほかのアプリケーション サーバにログオンします。 サポート オートメーション アナリストは、チケットを参照して自分の作業を再開できます。
    アプリケーション サーバが正常に停止されます。
クライアントでのカスタマイズの確認
カスタマイズがすべて同期されたか確認するために、クライアントのバージョン管理ファイルを確認します。
以下の手順に従います。
  1. CA SDM の設定に応じて、以下のクライアントにログインします。
    • 標準: セカンダリ サーバ
    • 高可用性: スタンバイ サーバおよびアプリケーション サーバ
  2. 以下の場所にある stdlog ファイルを開きます。
    $NX_ROOT\log
  3. サーバで実行したすべてのカスタマイズが、クライアントに適用されているかどうかを確認します。