この章では、高可用性と耐障害性 (HA/FT) を備えた Identity Manager 環境の実装方法について説明します。
Web サーバー、アプリケーションサーバー、およびデータベースプロバイダで高可用性配備を保証するためのベストプラクティスについては、各製品のマニュアルを参照してください。Web サーバーに関するベンダー独自の推奨事項がある場合は、このガイドよりも優先されます。
この節では、ユーザーに固有の配備で必要な可用性の規模を評価する方法を説明します。
Identity Manager は、一般ユーザーがすでにアクセスしているシステムおよびアプリケーションと、これらのユーザー間のトランザクションパス上に存在しないため、Identity Manager のダウンタイムはそれほど大きな問題にはなりません。Identity Manager を利用できなくても、エンドユーザーはプロビジョニングされたアカウントを通してリソースにアクセスできます。
Identity Manager のダウンタイムの主なコストは、生産性の損失です。Identity Manager が停止した場合、エンドユーザーはロックアウトされているシステムやプロビジョニングされていないシステムに、Identity Manager を使用してアクセスすることができません。
ダウンタイムのコストを計算するためにまず必要な項目は、エンドユーザーが企業内のコンピューターリソースにアクセスできないことによって生じる生産性損失の平均コストです。この値を「人時生産性」と呼んでいます。
その他の必要な項目は、Identity Manager を常に使用する必要があるエンドユーザーの、全ユーザーに対する割合です。この全ユーザーには、プロビジョニングが必要な新入社員や、自分のパスワードを忘れてしまったエンドユーザー (パスワード管理が配備されている場合) が含まれます。
次のような条件を仮定します。
従業員の総数 |
20,000 人 | |
1 日のパスワードリセット数 |
130 | |
1 日の新入社員の数 |
30 人 | |
1 日の勤務時間 |
8 時間 |
この場合、次のように計算できます。
Identity Manager を必要とする 1 時間あたりの従業員の数 = (130 + 30) / 8 = 20
Identity Manager を必要とする 1 時間あたりの従業員のパーセント = 20 / 20,000 = .1% (1000 人に 1 人)
これらの値を使用して、Identity Manager が停止した場合のコストを次のように評価できます。
人時生産性 |
100 ドル | ||
生産性の喪失 |
.5 |
(システムにアクセスできないことにより生産性が 50% 低下) |
|
影響を受ける従業員の数 |
20 人 | ||
小計 |
1,000 ドル | ||
機能停止の期間 |
2 時間 | ||
直接的な損失の合計 |
2,000 ドル |
この例は、Identity Manager で管理されているユーザーの数が多くても、システムにアクセスするために常に Identity Manager を必要とするユーザー数は通常少ないことを示しています。
また、Identity Manager のようなシステムを復元するために必要な時間は、Identity Manager で自動実行しているプロビジョニング処理を手動で実行するために必要な時間よりも、通常は短いということも考慮してください。したがって、Identity Manager のダウンタイムではコストが必要になりますが、通常そのコストは、リソースへのアクセス権を手動でユーザーに設定するコストよりも小さくなります。
Identity Manager の高可用性配備を計画するときに、ダウンタイムの原因を検討することは価値があります。
ダウンタイムの原因には次のようなものがあります。
オペレータの誤り
ハードウェアの障害
ソフトウェアの障害
計画されたダウンタイム (ハードウェアおよびソフトウェアのアップグレード)
不十分なパフォーマンス (知覚されるダウンタイム)
Identity Manager は、生産性の損失を自動的に処理して削減します。高可用性を備えた Identity Manager アーキテクチャーでは、ダウンタイムを最小化し、生産性の損失を回避することで投資利益を実現します。
ダウンタイムのコストを使用して、Identity Manager で最終的に必要な可用性の規模を判断できます。一般的には、Identity Manager が高可用性を備えるように適正な投資を行うことが目標です。
投資のコストを計算する際は、HA/FT ハードウェアおよびソフトウェアの購入のみで、利用可能なソリューションの実装が完了するわけではないことに注意してください。運用の知識を持つスタッフの費用も、別のコストとして必要です。
Identity Manager は、HA インフラストラクチャーを利用できる場合、これを利用するように設計されています。たとえば、Identity Manager は高可用性の達成にアプリケーションサーバークラスタを必要としませんが、クラスタが存在する場合はこれを利用できます。
次の図は、非冗長アーキテクチャーに配備された Identity Manager の主要コンポーネントを示しています。次の節からは、Identity Manager リポジトリ、アプリケーションサーバー、およびゲートウェイを高可用性化する方法について説明します。
遅延やネットワークの輻輳によって発生するパフォーマンスの問題を最小化するために、どのコンポーネントを近付けて配置するべきかについては、「システムの分離と物理的な近接性のガイドラインについて」を参照してください。
Identity Manager は、プロビジョニングと状態の情報をすべて Identity Manager リポジトリに格納します。
Identity Manager リポジトリを格納するデータベースインスタンスの可用性は、高可用性を備えた Identity Manager の配備でもっとも重要です。リポジトリは Identity Manager のインストール全体を表し、そこに含まれるデータは他の重要なデータベースアプリケーションと同様に保護する必要があります。最低でも、定期的なバックアップの実行が必要です。
パフォーマンス (1 秒あたりのトランザクション数) の大幅な低下につながるため、Identity Manager リポジトリを VMware 仮想マシンなどの仮想プラットフォームでホストしないでください。
作成できるリポジトリのイメージは 1 つだけです。Identity Manager 用に 2 つのデータベースを用意して、これらを夜間に同期することはできません。データベースのクラスタ化またはミラーリング機能を利用して、耐障害性を提供することをお勧めします。
Identity Manager をアプリケーションサーバークラスタ内で実行すると、クラスタで提供される可用性や負荷分散を利用することができます。ただし、Identity Manager はクラスタ化で必要な J2EE 機能を使用しません。
Identity Manager は、Servlet API を通して利用できる HTTP セッションオブジェクトを使用します。このセッションオブジェクトは、ユーザーがログインしたりアクションを実行したときに、ユーザーのアクセスを追跡します。クラスタ環境では、セッション中にユーザーの要求を複数のノードに処理させることもできます。ただし、通常はこのような処理を推奨しません。ほとんどのインストールでは、同一セッションにおけるユーザーの要求は、すべて同じサーバーに送信するように設定されます。
クラスタを設定しなくても、Identity Manager を実行するアプリケーションサーバーに可用性や機能を追加することができます。このためには、Identity Manager を実行する複数のアプリケーションサーバーをインストールし、これらのアプリケーションサーバーを同じリポジトリに接続して、すべてのアプリケーションサーバーの前に「セッションアフィニティー」を設定したロードバランサを配置します。
セッションアフィニティーについては、「セッションアフィニティーとセッション持続性に関する FAQ」を参照してください。
Identity Manager は、スケジュールされた調整タスクなど、特定のタスクをバックグラウンドで実行します。これらのタスクはデータベースに格納され、任意の Identity Manager サーバーによって実行可能です。別のノードへのフェイルオーバーが必要な場合でも、Identity Manager はデータベースを使用して、常にこれらのタスクが最後まで実行されることを保証します。
Waveset.properties ファイルの sources.hosts の設定は、複数インスタンス環境で Active Sync 要求の実行にどのホストを使用するかを制御します。この設定では、ソースアダプタを実行できるホストのリストを提供します。この設定に localhost または null を指定すると、ソースアダプタは Web ファームの任意のホストで実行できます (デフォルト)。リストに 1 つまたは複数のホストを指定すると、アダプタの実行をリストの内容に制限できます。特定のホストを使用するように、別のシステムから更新を受け取った場合は、sources.hosts 設定を使用してホスト名を記録します。
また、sources. resourceName.hosts という名前のプロパティーを定義して、リソースの Active Sync タスクをどこで実行するかを制御できます。resourceName は、指定するリソースオブジェクトの名前で置き換えてください。
Identity Manager は、サーバーから直接アクセスできないリソースを管理するために、軽量なゲートウェイを必要とします。これらのリソースには、プラットフォームに固有のクライアント側 API 呼び出しを必要とするシステムが含まれます。たとえば、Identity Manager が UNIX ベースのアプリケーションサーバーで動作している場合、管理対象の NT ドメインまたは Active Directory ドメインに対して NTLM または ADSI 呼び出しを行うことはできません。これらのリソースを管理するために Identity Manager はゲートウェイを必要とするため、Identity Manager Gateway が高可用性を備えていることは重要です。
Gateway がシングルポイント障害となることを避けるために、複数のマシンで Gateway インスタンスを実行することをお勧めします。メインの Gateway インスタンスに障害が発生したときにフェイルオーバーを提供するように、ネットワークルーティングデバイスを設定してください。フェイルオーバーデバイスではスティッキーセッションを設定し、単純なラウンドロビンスキーマを使用します。負荷分散を行うデバイスの背後には、Gateway を配置しないでください。これはサポートされていない設定で、Identity Manager の特定の機能で障害が発生します。
Gateway が管理するすべての Windows ドメインは、同じフォレストに所属している必要があります。フォレスト境界を越えるドメインの管理はサポートされていません。複数のフォレストがある場合は、各フォレストに少なくとも 1 つの Gateway をインストールしてください。
Win32 監視ツールを設定すると、Win32 ホスト上の gateway.exe プロセスを監視することができます。gateway.exe で障害が発生した場合、プロセスは自動的に再起動します。
次の図は、既存の Web アプリケーションインフラストラクチャーがない場合に、Sun が推奨する Identity Manager アーキテクチャーを示しています。
実際の配備では、できるだけ既存の冗長アプリケーションサーバーインフラストラクチャーを利用してください。このアーキテクチャーで注目すべき点は、アプリケーションサーバーの冗長性を実現するためにロードバランサだけを使用していることです。セッションアフィニティーを有効にしたロードバランサは、障害が発生したアプリケーションサーバーのインスタンスを検出し、アクティブなインスタンスにフェイルオーバーします。ロードバランサは、ユーザーの要求をクラスタ内のサーバーに分散することで、Web 環境に水平方向の拡張を提供するためにも利用できます。
これは簡単なアーキテクチャーですが、稼働時間の特性はより複雑な配備と比較しても劣りません。単純であるため、保守および監視すべきソフトウェアや、障害が発生する可能性のあるソフトウェアがわずかしかありません。もっとも多いダウンタイムの原因は人為的な誤りであるため、相対的に単純なソリューションは複雑なソリューションよりも優れた稼働時間特性を達成できます。普遍的に正しい答えはありません。ダウンタイムの原因をすべて理解し、投資に対して最高の可用性を得られるアーキテクチャーを選択することが重要です。
Identity Manager のような Web アプリケーションで設定できる HA アーキテクチャーをすべて説明することは不可能です。
Identity Manager はさまざまな組み合わせで配備可能であるため、Identity Manager を配備するときに既存のインフラストラクチャーを識別して、それらをできるだけ利用するともっとも経済的です。
Identity Manager Service Provider 機能を利用する場合は、ユーザー層とアプリケーション層の間に Web 層を追加することを推奨します。Web 層は、ファイアウォールによってアプリケーション層から分離された非武装ゾーン (DMZ) に設置される、1 つ以上の Web サーバーで構成されます。
Service Provider 機能を利用する場合は、LDAP リポジトリが必要です。Identity Manager でエクストラネットのクライアントのみをサポートする場合は、標準の Identity Manager リポジトリの使用をお勧めしますが、これは必須ではありません。また、Identity Manager がイントラネットユーザーとエクストラネットユーザーの両方をサポートする場合は、LDAP リポジトリと標準の Identity Manager リポジトリが必要です。
この節では 8 つの障害のシナリオを示し、セッション持続性が有効な配備とセッション持続性が無効な配備を比較します。
セッション持続性が「有効」な配備では、ロードバランサでセッションアフィニティーが有効です。配備には、セッションの変更が物理的に分離されているリポジトリノードに書き込まれるなど、何らかのセッション持続性が有効な同一クラスタの複数のインスタンスが含まれます。
セッション持続性が「無効」な配備では、ロードバランサでセッションアフィニティーが有効で、同じクラスタに属していない複数のインスタンスが含まれます。
シナリオの説明
エンドユーザーまたは管理者は、ワークフローの一部でないフォームを編集しています。ユーザーがセッションを確立していたインスタンスが停止します。
セッション持続性が無効な場合
ユーザー体験: 非透過的なフェイルオーバー。フォームを送信すると、ユーザーはログインページに戻されます。
回復手順: ユーザーは自分のユーザー名とパスワードを再入力します。Identity Manager はフォームを処理して、ログイン直後のページに結果を表示します。
セッション持続性が有効な場合
ユーザー体験: ユーザーのフォームは送信され、結果が返されます。ユーザーはログオフせず、再ログインの必要はありません。
回復手順: ユーザーのアクションは必要ありません。
その他のシナリオの例
インスタンスが停止したときに、エンドユーザーがログインしていて、ユーザーまたはその他のリポジトリオブジェクトの検索結果を取得していた。
インスタンスが停止したときに、管理者が管理者インタフェースを使用して「パスワードのリセット」または「ユーザーの編集」の要求を送信しようとしていた。
シナリオの説明
エンドユーザーまたは管理者が、ワークフローをトリガーするフォームを送信しています。ワークフローを実行しているインスタンスと、ユーザーのセッションが存在するインスタンスは、一部の定期タスクで別にできる場合を除いて、通常は同じになります。このインスタンスが、ワークフローの実行中に停止します。
セッション持続性が無効な場合
ユーザー体験: 非透過的なフェイルオーバー。フォームの送信により、ユーザーはログインページに戻されます。実行中のワークフロータスクのインスタンスはリポジトリにあるべきですが、実行のノードが停止しているため、ワークフローの状態は「終了」になります。
回復手順: ワークフローをもう一度送信する必要があります。再送信を行うには、ノードで障害が発生する前にワークフローのトリガーに使用したフォームに戻り、同じ情報を入力する必要があります。
同じ要求データを送信することで、動作する場合もありますが、動作しない場合もあります。ワークフローの実行中に複数のリソースに対してプロビジョニングが実行され、これらのリソースの一部が障害発生前にプロビジョニングされている場合、ユーザーからのワークフローの再送信では、「すでにプロビジョニングされた」リソースを考慮する必要があります。終了したワークフローは、TaskInstance オブジェクトで resultLimit が期限切れになるまで、リポジトリで待機しています。
セッション持続性が有効な場合
ユーザー体験: 非透過的なフェイルオーバー。ユーザーのセッションは維持され、新しいインスタンスで再確立されるため、ユーザーのログアウトは発生しません。ただし、ワークフローが終了するため、フォームの送信はエラーになる可能性があります。このフェイルオーバーは、回復アクションが必要であるため非透過的です。
回復手順: セッション持続性が無効な場合と同じです。ユーザーは、前回のワークフローをトリガーした要求を、同じパラメータまたは修正したパラメータを使用して再送信する必要があります。
その他のシナリオの例
エンドユーザーが Identity Manager アカウントを作成する自己登録要求を送信したときに、インスタンスが停止した。
管理者が処理中の「パスワードリセット」要求を送信したときに、インスタンスが停止した。
シナリオの説明
このシナリオは、ワークフローが開始されているが、承認者による手動アクションを待機中である場合です。
セッション持続性が無効な場合
ユーザー体験: 承認者がまだログインしていない場合、承認者に関しては透過的なフェイルオーバー。ノードで障害発生したあと、承認者がログインすると、現在ダウンしているノードからトリガーされた要求であっても、承認要求は承認者の受信箱に表示されます。
回復手順: ユーザーのアクションは必要ありません。
セッション持続性が有効な場合
ユーザー体験: セッション持続性が無効な場合と同じです。
回復手順: セッション持続性が無効な場合と同じです。
その他のシナリオの例
従業員の入社日または退社日までスリープする手動のアクションなど、ワークフローがスリープ状態である。
ユーザーの作成要求を送信した管理者が、承認者がログインして要求を承認するのを待機している。承認者が要求を承認する前に、要求の送信元であるノードで障害が発生した。
シナリオの説明
このシナリオは、ユーザーが作業項目を編集中で、ユーザーがセッションを確立していたノードが作業項目を送信する前に停止する場合です。
セッション持続性が無効な場合
ユーザー体験: 非透過的なフェイルオーバー。作業項目の編集フォームを送信すると、ユーザーはログオフし、ログインページに戻されます。
回復手順: ログイン資格を再送信すると、ユーザーの作業項目が「完了」にマークされ、ワークフローはそこから再開されます。ワークフローは、ユーザーの手動アクションが「完了」にマークされた場所から、新しい実行モードによって取得されます。
セッション持続性が有効な場合
ユーザー体験: 作業項目の編集フォームを送信すると、ユーザーには送信の結果が表示されます。たとえば、カスタムワークフローの次のフォームや成功のメッセージが表示されます。
回復手順: ユーザーのアクションは必要がありません。
その他のシナリオの例
エンドユーザーが、カスタムワークフローの手動アクションに関連付けられたフォームに入力している (たとえば、特定のリソースへのアクセスを要求している)。要求が送信される前に、ユーザーがセッションを確立していたノードで障害が発生する。
管理者が Identity Manager にログインして、承認要求を開いて編集している。要求が送信される前に、管理者がセッションを確立していたノードで障害が発生する。
シナリオの説明
このシナリオは、調整の実行中やレポートの実行中に、ノードで障害が発生した場合です。
セッション持続性が無効な場合
ユーザー体験: スケジュールタスクが途中で終了します。
回復手順: 実行中に終了したスケジュールタスクは、再起動する必要があります。タスクは最初から実行されます (障害が発生した場所から再開されるのではありません)。新しいタスクを作成および開始する場合と同様です。
セッション持続性が有効な場合
ユーザー体験: セッション持続性が無効な場合と同じです。
回復手順: セッション持続性が無効な場合と同じです。
その他のシナリオの例
Active Sync アダプタが、障害が発生したノードで実行するように設定されている。
シナリオの説明
このシナリオは、ユーザーのカスタムワークフローに、後日、特定のノードで実行するスケジュールタスクが含まれている場合です。予定日になる前に、タスクがスケジュールされたノードで障害が発生します。
セッション持続性が無効な場合
ユーザー体験: このタスクを予定時刻に実行することを保証するために必要な回復アクションに関して、フェイルオーバーは透過的です。
回復手順: スケジュールタスクは、予定時刻になったときに有効なノードに引き継がれます。
セッション持続性が有効な場合
ユーザー体験: セッション持続性が無効な場合と同じです。
回復手順: セッション持続性が無効な場合と同じです。
その他のシナリオの例
ユーザーのアカウント作成処理で、延期タスクスキャナを使用して、入社日にアカウントを有効にし、退社日にアカウントを無効にするように実装している。入社日および退社日になる前に、タスクがスケジュールされたノードで障害が発生する。
レポートをあとで実行するようにスケジュールしたり、調整を特定の日時に実行するようにスケジュールしたとき、予定の日時になる前に、タスクをスケジュールしたノードで障害が発生する。
シナリオの説明
このシナリオは、Identity Manager の GUI を使用せずにプロビジョニングを開始する場合です。SPML やその他のカスタム Web サービスインタフェースを使用して Identity Manager を内部的に呼び出すアプリケーションによって、ユーザーインタフェースが提供されています。この場合、UI を使用するユーザーに関連するユーザーセッションは、呼び出し元のアプリケーションを通して管理されます。Identity Manager では、要求はすべて「soapadmin」として開始されます。
このようなユースケースで、Identity Manager エンドポイントを経由して要求をまだ受信していないときに、対象のノードで障害が発生する場合を考えます。
セッション持続性が無効な場合
ユーザー体験: 透過的なフェイルオーバー。SOAP 管理者の資格は、ネットワーク経由で、または Identity Manager の Waveset.properties 設定で各 SOAP 要求に渡されます。この SOAP 要求を受信するノードが、停止前に要求を受信していなければ、セッション持続性の状態にかかわらずフェイルオーバーは透過的です。
回復手順: 必要なアクションはありません。SOAP 要求は、それを実行する有効なノードに送信されます。
セッション持続性が有効な場合
ユーザー体験: セッション持続性が無効な場合と同じです。
回復手順: セッション持続性が無効な場合と同じです。
シナリオの説明
このシナリオはシナリオ 7 に似ています。唯一の違いは、ノードで障害が発生したときに、ワークフローが実行中である (ノードが SOAP 要求をすでに受信している) ことです。
セッション持続性が無効な場合
ユーザー体験: このシナリオは、シナリオ 2 (ワークフローの実行中) と同様です。ワークフローは「終了」とマークされ、ユーザーには SOAP 要求の結果としてエラーが表示されます。
回復手順: ユーザーは他社アプリケーションのユーザーインタフェースを使用して、ワークフローのどこで障害が発生したかに応じて、同じパラメータまたは修正したパラメータを指定してフォームを再送信する必要があります。
セッション持続性が有効な場合
ユーザー体験: セッション持続性が無効な場合と同じです。
回復手順: セッション持続性が無効な場合と同じです。
アプリケーションサーバーを水平方向に拡張する場合は、セッションアフィニティーを有効にするべきですか。
はい。
アプリケーションサーバーを水平方向に拡張する場合は、セッション持続性を有効にするべきですか。
ごく一部の状況ではセッション持続性の有無によって透過的なフェイルオーバーができるかどうかが決まりますが、こうした状況での透過的なフェイルオーバーをビジネス要件で重視している場合を除いて、セッション持続性の使用はお勧めしません。セッション持続性によってパフォーマンスのオーバーヘッドが発生するため、ビジネス要件で透過的なフェイルオーバーが絶対に必要な場合を除いて、セッション持続性を無効のままにしてください。
「障害のシナリオについて」で説明している障害のシナリオでは、8 つのシナリオのうち 6 つは、セッション持続性が有効であるかどうかにかかわらず、エンドユーザーの体験や必要な回復アクションに違いはありませんでした。シナリオ 1 と 4 のみで、セッション持続性が有効なシナリオとセッション持続性が無効なシナリオで違いがありました。
これらの 2 つのシナリオでは、セッション持続性によりフェイルオーバーの透過性が提供されますが、これによりパフォーマンスに影響が出ます。セッションオブジェクトのサイズ、セッション持続性に使用されているリポジトリ、および特定のアプリケーションサーバーのセッション管理コードの最適化に基づいて、パフォーマンスのオーバーヘッドは 10 % から 20% の範囲またはそれ以上になります。
水平方向に拡張する場合、クラスタ内に複数のアプリケーションサーバーインスタンスを設定するべきですか。
セッション持続性が必要でなければ、複数のアプリケーションサーバーインスタンスは必ずしも必要ではありません。セッション持続性が有効でないフェイルオーバーは、すべてのアプリケーションサーバーノードが 1 つのクラスタにない場合でも設定できます。