高可用性の考慮事項

CA SDM 高可用性設定により、可用性が向上し、ダウンタイムが削減され、ローリング メンテナンスがサポートされます。 CA SDM 環境で以下のいずれかの要因に当てはまる場合は、高可用性設定の選択を検討してください。
casm173
CA SDM 高可用性設定により、可用性が向上し、ダウンタイムが削減され、ローリング メンテナンスがサポートされます。 CA SDM 環境で以下のいずれかの要因に当てはまる場合は、高可用性設定の選択を検討してください。
  • CA SDM に高い可用性が必要である。
  • CA SDM サーバをより独立させ、障害に対するより高い回復性を持たせる必要がある。
  • CA SDM のインストール全体をダウンさせることなく、CA SDM サーバを削除してサービスに戻す機能が必要である。
  • ローリング メンテナンス中のダウンタイムをほぼゼロにする必要がある。
標準(
プライマリ
/
セカンダリ
)と高可用性(
バックグラウンド
スタンバイ
アプリケーション サーバ
)の最大の違いは、標準設定ではプライマリ サーバのみがデータベースと通信することです。 一方、高可用性環境では、各サーバは単独でデータベースと通信し、パフォーマンス向上のために独自の仮想データベース プロセスとデータベース エージェントを備えています。
CA SDM 高可用性設定は、サーバの停止に対する回復性やアプリケーションの可用性を向上させると共に、ローリング メンテナンスをサポートすることによってエンド ユーザの中断を最小限に抑えます。 この設定では、以下のサーバ タイプが必要です。
  • MDB 用のデータベース サーバ
  • 1 つのバックグラウンド サーバ
    バックグラウンド サーバは、標準モードのプライマリ サーバの機能を果たします。 このサーバは、すべてのバックグラウンド トランザクション(イベントと通知のトリガ、条件の確認など)を処理します。
  • 1 つ以上のスタンバイ サーバ
    スタンバイ サーバは、スタンバイの目的で使用されます。 サーバの障害および中断時、元のバックグラウンド サーバを復旧および修復するときにスタンバイ サーバがバックグラウンド サーバとして昇格します。
  • 1 つ以上のアプリケーション サーバ
    エンド ユーザ トラフィックは、アプリケーション サーバのみに到達します。アプリケーション サーバでは、F5 ロード バランサを使用して 2 つ(またはそれ以上)のアプリケーション サーバ間の負荷を分散します。 エンド ユーザ トラフィックの負荷は、バックグラウンド サーバまたはスタンバイ サーバには影響しません。 スタンバイ サーバとアプリケーション サーバを設定するには、バックグラウンド サーバを使用して CA SDM コンソールにログインします。
CA SDM の高可用性モードを選択した場合は、以下のインストール タスクを実行します。
  1. バックグラウンド サーバのインストール
  2. アプリケーション サーバのインストール
  3. xFlow インターフェースのインストール
  4. 検索サーバのインストール
CA SDM 高可用性設定をインストールする前に、以下の計画に関する考慮事項を確認してください。
ログイン権限
以下の手順に従います。
  • (Windows) 管理者としてログインし、完全な管理者権限を取得します。
  • (Windows 以外) root ユーザとしてログインし、root アカウントへの適切な権限を取得します。
  • インストールを開始する前に、
    CA Service Desk Manager サーバ特権
    ユーザを作成します。
インストール ホーム ディレクトリ
以下の手順に従います。
  • 製品をインストールするホーム ディレクトリを決定します。 製品のデフォルトのホーム ディレクトリは
    C:\Program Files\CA\Service Desk Manager
    です。
  • 製品(Java Runtime Environment (JRE)や Apache Tomcat など)が使用する共有コンポーネントをインストールするホーム ディレクトリを決定します。 共有コンポーネントのデフォルトのホーム ディレクトリは
    C:\Program Files\CA\SC
    です。
データベースに関する考慮事項
CA Service Management
では、Microsoft SQL Server と Oracle データベースの両方がサポートされています。 環境の要件に応じてデータベースを選択します。
  • Windows プラットフォームでは、Microsoft SQL Server のみがネイティブにサポートされています。 たとえば、実装が Windows や Linux などの異種のオペレーティング システムを含むサーバで構成されている場合は、Linux では Microsoft SQL Server がサポートされていないため、DBMS として Oracle を選択してください。 以下の情報を取得します。
    • Microsoft SQL Server を実行しているサーバの名前付きインスタンス。
    • Microsoft SQL Server データベースのユーザ名およびパスワード。
    • Microsoft SQL Server データベースのポート番号。
  • Oracle で製品とコンポーネントを設定できるように、以下の情報を取得している。
    • Oracle データベースはローカルかリモートか
    • 表領域の作成は必要か
    • ネット サービス名
    • DBA ユーザ名およびパスワード
    • データ表領域名およびインデックス表領域名
    • 表領域の完全パス
    • システム識別子(SID)やリスナ ポートなどの JDBC 接続情報
  • 64 ビット コンピュータで 64 ビット Oracle 11g データベースを設定する場合、以下の操作を行います。
    • サーバに 32 ビット Oracle Client をインストールし、システム ライブラリ パスが 32 ビット Oracle ライブラリを指すようにデータベースを設定します
      この手順は、構成とランタイムの両方に必要です。 また、Oracle クライアントにネット サービス名を作成し、Oracle データベース サーバ インスタンスを指定します。
    • システムに 64 ビット実行可能ファイルをインストールし、そのインストールに 32 ビット ライブラリおよびデフォルトの 64 ビット ライブラリ(Oracle 11g R2 より前)の両方が含まれる場合、
      $ORACLE_HOME/lib32
      構造が存在します。 64 ビット ライブラリは、
      $ORACLE_HOME/lib
      に配置され、32 ビットは、
      $ORACLE_HOME/lib32
      ディレクトリに配置されます。
    • Oracle データベース 11g R2 以降では、32 ビット ライブラリは 64 ビット Oracle データベース サーバまたは 64 ビット Oracle データベース クライアントのメディアに付属していません。 そのため、Oracle データベース 11g R2 をインストールすると、
      $ORACLE_HOME
      に lib32 フォルダは存在しません。 32 ビット ライブラリが必要な場合は、別個のメディアとして提供される 32 ビット クライアントをインストールする必要があります。 これは、新しい Oracle ホームにインストールする必要があります。 64 ビット サーバまたは 64 ビット クライアントのホームにインストールしないでください。
  • Oracle データベースを使用しており、既存の表領域を使用する場合、以下の操作を行います。
    • CA SDM を環境設定する前に、少なくとも 400 MB のデータ表領域と 100 MB のインデックス表領域をそれぞれ用意しておく必要があります。
    • DBMS サーバのハードウェア設定を増加します。 各サーバはデータベースに直接接続するため、DBMS レベルでのリソース競合が増加します。
高可用性設定に関する考慮事項
計画の考慮事項
チェックリスト
高可用性の一般的な考慮事項
  • 1 つのバックグラウンド サーバ、少なくとも 1 つのスタンバイ サーバ、および 1 つ以上のアプリケーション サーバが必要になるため、追加のハードウェア コストが予測されます。 スタンバイ サーバとバックグラウンド サーバの設定は同じである必要があります。
  • リモート データベース サーバと、Knowledge Tools インデックス ファイル、Knowledge Tools インポート/エクスポート ファイル、アーカイブ パージ出力ファイル、および添付ファイル リポジトリを共有するためのサーバが必要になります。 バックグラウンドおよびスタンバイ サーバからこれらのファイルにアクセスできるようにするには、共有された場所が必要です。 Linux インストールでは、NFS マウントを使用できます。 Windows インストールには、UNC サポートが追加されています。
  • バックグラウンドおよびスタンバイ動作のためにサーバが追加された場合でも、 CA SDM のパフォーマンスは同じままになると予測されます。 展開するアプリケーション サーバが増えた場合は、パフォーマンスが向上する可能性があります。
  • 各サーバはデータベースに直接接続するため、DBMS レベルでのリソース競合が増加します。 DBMS サーバのハードウェア構成を増やすことをお勧めします。
  • 標準設定の高可用性設定への変換は、手作業で行われます。 実装の規模が大きいほど複雑になるため、CA サービスに支援を求めることが必要になります。
  • 各アプリケーション サーバの ping の時間や待ち時間を同じレベルにするために、バックグラウンドおよびスタンバイ サーバを同じネットワーク サブネットにインストールします。
  • バックグラウンドおよびスタンバイ サーバを、すべてのユーザが良好にネットワーク接続できる中央の場所に配置することを検討してください。 アプリケーション サーバは集中的に配置することも、世界中に分散させることもできます。
  • 高可用性設定には、常に、
    1 つのバックグラウンド サーバ
    と少なくとも
    1 つのスタンバイ サーバ
    が必要です。
  • (推奨)バックグラウンド サーバとその他のすべてのスタンバイ サーバの両方が同じ設定になっていることを確認してください。 フェールオーバ中にスタンバイ サーバが新しいバックグラウンド サーバになったとき、スタンバイ サーバが古いバックグラウンド サーバと同様に機能します。
  • スタンバイ サーバは、任意の数だけ設定できます。 CA SDM の可用性を向上させるために、バックアップ データ センターまたは惨事復旧サイトに 1 つのスタンバイ サーバを配置することを検討してください。
  • 高可用性実装には、最低 1 つのアプリケーション サーバが必要です。 可用性を向上させるために 2 つのアプリケーション サーバを、また Web トラフィックを制御するためにロード バランサを配置することをお勧めします。
  • CA SDM 管理者以外のユーザは、バックグラウンド サーバへのログインを許可されていません。 また、スタンバイ サーバへのログインが許可されたユーザはいません。
  • すべての CA SDM サーバから電子メール通知を送信できます。 このオプションを制限するか、または設定する方法はありません。 高度可用性構成のすべてのサーバは、メール サーバに接続をしている必要があります。
  • エンド ユーザ インタラクションに起因する電子メール通知は、ユーザが接続されているアプリケーション サーバから送信されます。
  • バックグラウンド プロセス(添付イベントを処理するアニメータなど)に起因する電子メール通知は、バックグラウンド サーバで実行中の
    pdm_mail_nxd
    ユーティリティによって送信されます。
  • バックグラウンド サーバの故障中に、バックグラウンド サーバがスタンバイ サーバとしてアップ状態になった場合、キュー内の電子メールが送信されます。
フェールオーバに関する考慮事項
バックグラウンド サーバからスタンバイ サーバへのフェールオーバ時には、以下の点を考慮します。
  • 新規ユーザは、フェールオーバ プロセス中にログインできません。
  • すでに接続されているユーザの場合は、フェールオーバ中に以下のアクションは動作しません。 フェールオーバが完了した後、これらのアクションを繰り返す必要があります。
    • 添付ファイルを使用したチケットの作成。
    • 添付ファイルのダウンロード。
    • ナレッジ ドキュメントの検索。
    • 新しいナレッジ ドキュメントのインデックス作成。
    • 電子メールの受信。
    • フェールオーバが完了するまでトリガされない SLA イベント。
CA SDM サーバの自動フェールオーバを有効にするようにサードパーティ ツールが設定されている場合、ローリング メンテナンスを実行する前に、そのツールを無効にする必要があります。
データベースに関する考慮事項
  • 直接接続は、各サーバからほかのサーバに対してだけでなく、各サーバからデータベースに対しても存在します。 CA SDM サーバが DMZ 内にある場合は、この接続用に、ファイアウォール ポートを開くか、トンネルプロキシテクノロジを実装する必要があります。 また、DBMS ベンダーとのライセンス契約も考慮してください。
  • すべての CA SDM サーバにデータベース クライアントをインストールするようにしてください。
  • 高可用性設定では、すべてのサーバが 1 つのデータベースに接続します。 データベースは単一障害点になる場合があるため、DBMS の可用性を向上させるためにデータベース クラスタリングを利用することを検討してください。
  • Windows プラットフォームでは、Microsoft SQL Server のみがネイティブにサポートされています。 たとえば、実装が Windows や Linux などの異種のオペレーティング システムを含むサーバで構成されている場合は、Linux では Microsoft SQL Server がサポートされていないため、DBMS として Oracle を選択してください。
システム構成、管理、および操作
  • SOAP Web サービスと RESTful Web サービスは、アプリケーション サーバでのみサポートされます。 WebDirector は、すべての CA SDM サーバ上で設定できます。
  • アプリケーション サーバは互いに独立しているため、WebDirector は、同じアプリケーション サーバ上で実行されている Web エンジンにしかサービスを提供できません。 WebDirector は、アプリケーション サーバにわたる Web エンジンにはサービスを提供できません。
  • 高可用性設定でのサーバの独立性は高いため、ほとんどのコマンド ライン ユーティリティはローカル サーバでのみ機能します。
    たとえば、
    pdm_status
    では、このコマンドを実行しているサーバ上で実行されている CA SDM プロセスのみが表示されます。
    pdm_webcache
    ユーティリティでは、それが発行されたサーバ上のフォーム キャッシュしか更新されません。
  • プライマリ サーバで動作する
    pdm_d_mgr
    によって CA SDM プロセスを起動および停止する標準設定とは異なり、高可用性設定では各サーバ上のプロセスが個別に制御されます。
  • アプリケーション サーバをシャットダウンするには、pdm_halt コマンドの代わりに新しい pdm_server_control を使用することをお勧めします。 シャットダウンの前に、アクティブなユーザに別のアプリケーション サーバに移動するよう求めることができます。
    休止
    オプションを使用してユーザに通知することができます。
  • pdm_edit ユーティリティが新しいグラフィカル ユーザ インターフェースに置き換えられため、以前は必要だった設定ファイルの手動による変更の多くが必要なくなりました。
  • 標準設定とは異なり高可用性設定では、バックグラウンド サーバの Web UI の[オプション マネージャ]から bopauth_host オプションを使用して、認証サーバの詳細を指定できます。 高可用性設定のために、pdm_edit でこの設定変更を行う必要はありません。 認証サーバが使用できない場合、ユーザはログインできません。
    標準設定では、セカンダリ サーバを使用して、CA SDM を別のシステムや別のハードウェア プラットフォーム上で実行されている認証システムに統合させることができます。
  • 不正なサーバが高可用性設定に参加できないようにするために、サーバはすべて、設定する前にバックグラウンド サーバの Web UI で定義する必要があります。
  • 高可用性設定でのサーバの役割やその他の情報は、[管理]タブで変更できます。 サーバ定義を変更する前に、CA SDM サービスを停止します。 変更を有効にするには、サーバの再設定が必要です。
  • 設定ユーティリティを実行することによって、サーバを標準設定と高可用性設定の間で変更できます。 必ず、実装内のすべてのサーバを変更してください。 データは影響を受けずに残りますが、設定を変更するには手動の更新が必要になります。
  • 最新のリリース バージョンにマイグレートするときは、最新の
    pdm_startup
    ファイルを使用します。 以前のバージョンの CA SDM のファイルを使用しないでください。 たとえば、
    pdm_edit
    ユーティリティによって生成されたファイルなどです。
    指示がない限り、
    Nx.env
    変数を手動で変更しないでください。
  • 新しい機能によって、チケット番号および数値レコード キーが生成されます。 データベースが破損する可能性を回避するために、
    Key_Control
    テーブルをロードしたり、手動で変更したりしないでください。
  • 高可用性設定では、Knowledge Tools デーモンを別のサーバに移動することはできません。
    kt_daemon
    は現在、すべてのサーバ上で実行されます。 その他のすべての Knowledge Tools デーモンは、バックグラウンド サーバ上でシングルトンとして実行されます。
  • Knowledge Tools は現在、ナレッジ エクスポート/インポート機能によって使用される EBR インデックス ファイルおよび入出力ファイルの場所への Windows 上の UNC ファイル パスをサポートしています。 この機能は、高可用性設定と標準設定の両方に使用できます。
    EBR インデックス ファイルのパスと KEIT ファイルのパスは、同じ UNC 認証情報を参照する必要があります。また、同じサーバ上にパスが存在する必要があります。
  • バージョン管理により、
    server_secondary_custom.ver
    ファイルで設定されるファイル(
    htmpl
    、.
    maj
    、.
    mod
    、.
    sch
    など)がバックグラウンド サーバから配布されます。 起動時、スタンバイまたはアプリケーション サーバは、更新されたファイルをバックグラウンド サーバから取得するためにバージョン管理クライアントを実行します。
  • アーカイブ/パージは、バックグラウンド サーバ上で実行され、出力ファイルへの Windows 上の UNC ファイル パスをサポートします。 この機能は、高可用性設定と標準設定で使用できます。
  • リポジトリがリモート サーバ上に存在する場合、受信電子メールの添付ファイルは、
    pdm_maileater
    によって格納されます。
  • デーモン マネージャが
    procsets
    を変更できるようにし、このアクションに対して
    pdm_dmnmode
    コマンドを実行しないようにします。
一般的な Web ユーザ インターフェースに関する考慮事項
  • Web サーバは、高可用性設定のすべてのサーバ上で必要です。
  • フェールオーバのためにバックグラウンド サーバが使用できない場合は、[遅延したサーバ応答]フォームが Web ユーザに表示されます。 スタンバイ サーバがバックグラウンド サーバに昇格されると、ユーザは自分の作業の再開を許可されます。
  • web_cgi_url オプションの値は、以下を指している必要があります。
  • 複数のアプリケーション サーバが存在する場合は、ロード バランサ。
  • アプリケーション サーバが 1 つしか存在しない場合は、アプリケーション サーバ。
添付ファイルに関する考慮事項
  • 共有ファイル リポジトリにアクセスするためのドキュメント リポジトリ プロセスを複数設定することによって、添付ファイルの可用性を向上させることができます。
Web Screen Painter に関する考慮事項
Web Screen Painter(WSP)は、バックグラウンド サーバ上でのみ使用できます。
  • WSP のフォーム変更を発行して、更新されたフォームがインストール内のすべてのサーバに配布されるようにするには、推奨される手順に従ってください。 詳細については、「Web Screen Painter を使用してスキーマを変更する方法」を参照してください。
  • すべてのサーバ上で実行される仮想データベース層デーモン。 CA SDM データベースのカスタマイズとオブジェクト定義をすべてのサーバにインストールします。
レポートの考慮事項
CABI Jaspersoft は、代替アプリケーション サーバからデータを自動的に取得できます。 この機能を設定すると、CA SDM レポートの可用性を向上させることができます。 詳細については、「CA Service Management での CABI JasperReports Server r6.4.3 のインストールおよび設定」を参照してください。
オプション マネージャに関する考慮事項
  • オプション マネージャからオプションをインストールまたはアンインストールできるのは、バックグラウンド サーバの Web UI からだけです。 変更を設定内のすべてのサーバに伝播するには、ローリング メンテナンスの手順を使用します。 ローリング メンテナンスの実行の詳細については、CA SDM サーバでのローリング メンテナンスの実行のシナリオを参照してください。
Web サービスに関する考慮事項
  • Web サービスは、アプリケーション サーバ上でのみ設定できます。
  • webservices_domsrvr オプションは、オプション マネージャには存在しなくなりました。 NX.env を変更することによって、各アプリケーション サーバ上で NX_WEBSERVICES_DOMSRVR 変数を独立して設定できます。
一般的な統合に関する考慮事項
  • CA SDM Web ユーザ インターフェースへの URL は、正しく設定されたアプリケーション サーバを指している必要があります。 ca_application_registration には、ほかの CA 製品によって使用される CA SDM のインストールへの URL が含まれています。 この URL は、最初に設定される CA SDM サーバ(最も一般的にはバックグラウンド サーバ)を指しています。 管理機能を使用してこの値を変更できるのは、CA SDM 管理者だけです。 ロード バランサを使用している場合は、この URL が単一のアプリケーション サーバではなく、ロード バランサを指すようにします。
  • ほとんどのエンド ユーザ インタラクション、およびほかのソフトウェア製品との統合は、アプリケーション サーバ レベルで実行されます。 アプリケーション サーバのフェールオーバはありません。 アプリケーション サーバが使用できなくなると、そのアプリケーション サーバの Web サービスも使用できなくなります。 アプリケーション サーバの可用性を向上させるためにロード バランサを展開して、異なるアプリケーション サーバ間でリクエストをルーティングできます。
  • CA Process Automation は、どのアプリケーション サーバにもインストールできます。 そのアプリケーション サーバがダウンすると、ワークフローは使用できなくなります。
統合検索に関する考慮事項
  • 統合検索機能を有効にして使用するには、アプリケーション サーバの設定時に統合検索オプションを選択します。
CA SDM 設定変換に関する考慮事項
CA SDM サーバの設定モードを変換する際は、以下の事項を考慮してください。
  • バックグラウンド サーバは、プライマリ サーバにのみ変換できます。
  • プライマリ サーバは、バックグラウンド サーバにのみ変換できます。
  • セカンダリ サーバは、スタンバイ サーバまたはアプリケーション サーバにのみ変換できます。
  • スタンバイ サーバまたはアプリケーション サーバは、セカンダリ サーバにのみ変換できます。