新機能と変更された機能 › 修正点 › 高可用性設定の考慮事項

高可用性設定の考慮事項

高可用性設定の実装を決定する前に、以下の点を考慮することをお勧めします。

一般的な注意事項

標準設定の計画に関する考慮事項はすべて、高可用性設定にも有効です。 標準設定の計画の詳細については、「実装ガイド」を参照してください。

• 1 つのバックグラウンド サーバ、少なくとも 1 つのスタンバイ サーバ、および 1 つ以上のアプリケーション サーバが必要になるため、追加のハードウェア コストが予測されます。 スタンバイ サーバとバックグラウンド サーバの設定は同じである必要があります。
• リモート データベース サーバと、Knowledge Tools インデックス ファイル、Knowledge Tools インポート/エクスポート ファイル、アーカイブ パージ出力ファイル、および添付ファイル リポジトリを共有するためのサーバが必要になります。 バックグラウンドおよびスタンバイ サーバからこれらのファイルにアクセスできるようにするには、共有された場所が必要です。 Linux および UNIX インストールでは、NFS マウントを使用できます。 Windows インストールには、UNC サポートが追加されています。
• バックグラウンドおよびスタンバイ動作のためにサーバが追加された場合でも、CA SDM のパフォーマンスは同じままになると予測されます。 展開するアプリケーション サーバが増えた場合は、パフォーマンスが向上する可能性があります。
• 各サーバはデータベースに直接接続するため、DBMS レベルでのリソース競合が増加します。 DBMS サーバのハードウェア構成を増やすことをお勧めします。 詳細については、システム情報を参照してください。
• 標準設定の高可用性設定への変換は、手作業で行われます。 通常、実装の規模が大きいほど複雑になるため、CA サービスに支援を求めることが必要になる可能性があります。
• 高可用性設定にマイグレートするには、標準設定で CA SDM r12.9 にアップグレードしてから、高可用性設定に変換します。
• 各アプリケーション サーバの 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 を選択してください。
• pdm_isql ユーティリティはアプリケーション サーバでのみ動作します。

システム構成、管理、および操作

• 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 サービスを停止します。 変更を有効にするには、サーバの再設定が必要です。
• 設定ユーティリティを実行することによって、サーバを標準設定と高可用性設定の間で変更できます。 必ず、実装内のすべてのサーバを変更してください。 データは影響を受けずに残りますが、設定を変更するには手動の更新が必要になります。
• CA SDM r12.9 へのマイグレート時は、最新の pdm_startup ファイルを使用します。 以前のバージョンの CA SDM のファイルを使用しないでください。 たとえば、pdm_edit ユーティリティによって生成されたファイルなどです。
• 高可用性をサポートするために NX.env に新しい環境変数が追加されています。これらの変数値はシステムによって自動的に管理されます。

  重要： 指示がない限り、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 を使用して、スキーマをカスタマイズする方法」、および「Web Screen Painter を使用して、Web インターフェースをカスタマイズする方法」を参照してください。
• すべてのサーバ上で実行される仮想データベース層デーモン。 CA SDM データベースのカスタマイズとオブジェクト定義をすべてのサーバにインストールします。

レポートの考慮事項

• CA Business Intelligence は、代替アプリケーション サーバからデータを自動的に取得できます。 この機能を設定すると、CA SDM レポートの可用性を向上させることができます。
• BOXI は、バックグラウンド サーバに統合されていません。 このため、バックグラウンド サーバの Web UI からはレポートを表示できません。 バックグラウンド サーバの Web UI から［レポート］タブを選択すると、エラー メッセージが表示されます。

オプション マネージャに関する考慮事項

• オプション マネージャからオプションをインストールまたはアンインストールできるのは、バックグラウンド サーバの 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 サービスも使用できなくなります。 アプリケーション サーバの可用性を向上させるためにロード バランサを展開して、異なるアプリケーション サーバ間でリクエストをルーティングできます。
• IP アドレスが関係するため、NSM は 1 つのアプリケーション サーバにしか統合できません。 そのサーバがダウンしているときは、NSM 統合を使用できません。
• アプリケーション サーバのいずれかに CA Workflow をインストールする必要があります。 そのアプリケーション サーバがダウンすると、CA Workflow 統合は使用できなくなります。

変換における注意事項

• バックグラウンド サーバは、プライマリ サーバにのみ変換できます。
• プライマリ サーバは、バックグラウンド サーバにのみ変換できます。
• セカンダリ サーバは、スタンバイ サーバまたはアプリケーション サーバにのみ変換できます。
• スタンバイ サーバまたはアプリケーション サーバは、セカンダリ サーバにのみ変換できます。

統合検索に関する考慮事項

• 統合検索機能を有効にして使用するには、アプリケーション サーバの設定時に統合検索オプションを選択します。