test

Sun Identity Manager の概要

第 3 章 クラスタ化と高可用性

この章では、高可用性と耐障害性 (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 が停止した場合のコストを次のように評価できます。

人時生産性 

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 の高可用性機能セットについて

Identity Manager は、HA インフラストラクチャーを利用できる場合、これを利用するように設計されています。たとえば、Identity Manager は高可用性の達成にアプリケーションサーバークラスタを必要としませんが、クラスタが存在する場合はこれを利用できます。

次の図は、非冗長アーキテクチャーに配備された Identity Manager の主要コンポーネントを示しています。次の節からは、Identity Manager リポジトリ、アプリケーションサーバー、およびゲートウェイを高可用性化する方法について説明します。

図 3–1 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 はデータベースを使用して、常にこれらのタスクが最後まで実行されることを保証します。

アプリケーションサーバーノードでの Active Sync クラスタ化の設定

Waveset.properties ファイルの sources.hosts の設定は、複数インスタンス環境で Active Sync 要求の実行にどのホストを使用するかを制御します。この設定では、ソースアダプタを実行できるホストのリストを提供します。この設定に localhost または null を指定すると、ソースアダプタは Web ファームの任意のホストで実行できます (デフォルト)。リストに 1 つまたは複数のホストを指定すると、アダプタの実行をリストの内容に制限できます。特定のホストを使用するように、別のシステムから更新を受け取った場合は、sources.hosts 設定を使用してホスト名を記録します。

また、sources. resourceName.hosts という名前のプロパティーを定義して、リソースの Active Sync タスクをどこで実行するかを制御できます。resourceName は、指定するリソースオブジェクトの名前で置き換えてください。

Gateway の高可用性化

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 で障害が発生した場合、プロセスは自動的に再起動します。

推奨される HA アーキテクチャーについて

次の図は、既存の Web アプリケーションインフラストラクチャーがない場合に、Sun が推奨する Identity Manager アーキテクチャーを示しています。

図 3–2 Identity Manager の高可用性アーキテクチャー

推奨される Identity Manager の高可用性アーキテクチャーを示す論理図。

実際の配備では、できるだけ既存の冗長アプリケーションサーバーインフラストラクチャーを利用してください。このアーキテクチャーで注目すべき点は、アプリケーションサーバーの冗長性を実現するためにロードバランサだけを使用していることです。セッションアフィニティーを有効にしたロードバランサは、障害が発生したアプリケーションサーバーのインスタンスを検出し、アクティブなインスタンスにフェイルオーバーします。ロードバランサは、ユーザーの要求をクラスタ内のサーバーに分散することで、Web 環境に水平方向の拡張を提供するためにも利用できます。

これは簡単なアーキテクチャーですが、稼働時間の特性はより複雑な配備と比較しても劣りません。単純であるため、保守および監視すべきソフトウェアや、障害が発生する可能性のあるソフトウェアがわずかしかありません。もっとも多いダウンタイムの原因は人為的な誤りであるため、相対的に単純なソリューションは複雑なソリューションよりも優れた稼働時間特性を達成できます。普遍的に正しい答えはありません。ダウンタイムの原因をすべて理解し、投資に対して最高の可用性を得られるアーキテクチャーを選択することが重要です。

注 –

Identity Manager のような Web アプリケーションで設定できる HA アーキテクチャーをすべて説明することは不可能です。

Identity Manager はさまざまな組み合わせで配備可能であるため、Identity Manager を配備するときに既存のインフラストラクチャーを識別して、それらをできるだけ利用するともっとも経済的です。

推奨される Service Provider の HA アーキテクチャーについて

Identity Manager Service Provider 機能を利用する場合は、ユーザー層とアプリケーション層の間に Web 層を追加することを推奨します。Web 層は、ファイアウォールによってアプリケーション層から分離された非武装ゾーン (DMZ) に設置される、1 つ以上の Web サーバーで構成されます。

Service Provider 機能を利用する場合は、LDAP リポジトリが必要です。Identity Manager でエクストラネットのクライアントのみをサポートする場合は、標準の Identity Manager リポジトリの使用をお勧めしますが、これは必須ではありません。また、Identity Manager がイントラネットユーザーとエクストラネットユーザーの両方をサポートする場合は、LDAP リポジトリと標準の Identity Manager リポジトリが必要です。

図 3–3 Identity Manager Service Provider の高可用性アーキテクチャー

Service Provider の実装で推奨される Identity Manager 高可用性アーキテクチャーを示す論理図。

障害のシナリオについて

この節では 8 つの障害のシナリオを示し、セッション持続性が有効な配備とセッション持続性が無効な配備を比較します。

シナリオ 1: ワークフローなし

シナリオの説明

エンドユーザーまたは管理者は、ワークフローの一部でないフォームを編集しています。ユーザーがセッションを確立していたインスタンスが停止します。

セッション持続性が無効な場合

ユーザー体験: 非透過的なフェイルオーバー。フォームを送信すると、ユーザーはログインページに戻されます。

回復手順: ユーザーは自分のユーザー名とパスワードを再入力します。Identity Manager はフォームを処理して、ログイン直後のページに結果を表示します。

セッション持続性が有効な場合

ユーザー体験: ユーザーのフォームは送信され、結果が返されます。ユーザーはログオフせず、再ログインの必要はありません。

回復手順: ユーザーのアクションは必要ありません。

その他のシナリオの例

シナリオ 2: ワークフローの実行中

シナリオの説明

エンドユーザーまたは管理者が、ワークフローをトリガーするフォームを送信しています。ワークフローを実行しているインスタンスと、ユーザーのセッションが存在するインスタンスは、一部の定期タスクで別にできる場合を除いて、通常は同じになります。このインスタンスが、ワークフローの実行中に停止します。

セッション持続性が無効な場合

ユーザー体験: 非透過的なフェイルオーバー。フォームの送信により、ユーザーはログインページに戻されます。実行中のワークフロータスクのインスタンスはリポジトリにあるべきですが、実行のノードが停止しているため、ワークフローの状態は「終了」になります。

回復手順: ワークフローをもう一度送信する必要があります。再送信を行うには、ノードで障害が発生する前にワークフローのトリガーに使用したフォームに戻り、同じ情報を入力する必要があります。

同じ要求データを送信することで、動作する場合もありますが、動作しない場合もあります。ワークフローの実行中に複数のリソースに対してプロビジョニングが実行され、これらのリソースの一部が障害発生前にプロビジョニングされている場合、ユーザーからのワークフローの再送信では、「すでにプロビジョニングされた」リソースを考慮する必要があります。終了したワークフローは、TaskInstance オブジェクトで resultLimit が期限切れになるまで、リポジトリで待機しています。

セッション持続性が有効な場合

ユーザー体験: 非透過的なフェイルオーバー。ユーザーのセッションは維持され、新しいインスタンスで再確立されるため、ユーザーのログアウトは発生しません。ただし、ワークフローが終了するため、フォームの送信はエラーになる可能性があります。このフェイルオーバーは、回復アクションが必要であるため非透過的です。

回復手順: セッション持続性が無効な場合と同じです。ユーザーは、前回のワークフローをトリガーした要求を、同じパラメータまたは修正したパラメータを使用して再送信する必要があります。

その他のシナリオの例

シナリオ 3: ワークフローが一時休止中またはスリープ中

シナリオの説明

このシナリオは、ワークフローが開始されているが、承認者による手動アクションを待機中である場合です。

セッション持続性が無効な場合

ユーザー体験: 承認者がまだログインしていない場合、承認者に関しては透過的なフェイルオーバー。ノードで障害発生したあと、承認者がログインすると、現在ダウンしているノードからトリガーされた要求であっても、承認要求は承認者の受信箱に表示されます。

回復手順: ユーザーのアクションは必要ありません。

セッション持続性が有効な場合

ユーザー体験: セッション持続性が無効な場合と同じです。

回復手順: セッション持続性が無効な場合と同じです。

その他のシナリオの例

シナリオ 4: 作業項目の編集中

シナリオの説明

このシナリオは、ユーザーが作業項目を編集中で、ユーザーがセッションを確立していたノードが作業項目を送信する前に停止する場合です。

セッション持続性が無効な場合

ユーザー体験: 非透過的なフェイルオーバー。作業項目の編集フォームを送信すると、ユーザーはログオフし、ログインページに戻されます。

回復手順: ログイン資格を再送信すると、ユーザーの作業項目が「完了」にマークされ、ワークフローはそこから再開されます。ワークフローは、ユーザーの手動アクションが「完了」にマークされた場所から、新しい実行モードによって取得されます。

セッション持続性が有効な場合

ユーザー体験: 作業項目の編集フォームを送信すると、ユーザーには送信の結果が表示されます。たとえば、カスタムワークフローの次のフォームや成功のメッセージが表示されます。

回復手順: ユーザーのアクションは必要がありません。

その他のシナリオの例

シナリオ 5: スケジュールタスクの実行中

シナリオの説明

このシナリオは、調整の実行中やレポートの実行中に、ノードで障害が発生した場合です。

セッション持続性が無効な場合

ユーザー体験: スケジュールタスクが途中で終了します。

回復手順: 実行中に終了したスケジュールタスクは、再起動する必要があります。タスクは最初から実行されます (障害が発生した場所から再開されるのではありません)。新しいタスクを作成および開始する場合と同様です。

セッション持続性が有効な場合

ユーザー体験: セッション持続性が無効な場合と同じです。

回復手順: セッション持続性が無効な場合と同じです。

その他のシナリオの例

シナリオ 6: スケジュールタスクが一時休止中

シナリオの説明

このシナリオは、ユーザーのカスタムワークフローに、後日、特定のノードで実行するスケジュールタスクが含まれている場合です。予定日になる前に、タスクがスケジュールされたノードで障害が発生します。

セッション持続性が無効な場合

ユーザー体験: このタスクを予定時刻に実行することを保証するために必要な回復アクションに関して、フェイルオーバーは透過的です。

回復手順: スケジュールタスクは、予定時刻になったときに有効なノードに引き継がれます。

セッション持続性が有効な場合

ユーザー体験: セッション持続性が無効な場合と同じです。

回復手順: セッション持続性が無効な場合と同じです。

その他のシナリオの例

シナリオ 7: Web サービスのワークフロー要求が Identity Manager でまだ受信されていない

シナリオの説明

このシナリオは、Identity Manager の GUI を使用せずにプロビジョニングを開始する場合です。SPML やその他のカスタム Web サービスインタフェースを使用して Identity Manager を内部的に呼び出すアプリケーションによって、ユーザーインタフェースが提供されています。この場合、UI を使用するユーザーに関連するユーザーセッションは、呼び出し元のアプリケーションを通して管理されます。Identity Manager では、要求はすべて「soapadmin」として開始されます。

このようなユースケースで、Identity Manager エンドポイントを経由して要求をまだ受信していないときに、対象のノードで障害が発生する場合を考えます。

セッション持続性が無効な場合

ユーザー体験: 透過的なフェイルオーバー。SOAP 管理者の資格は、ネットワーク経由で、または Identity Manager の Waveset.properties 設定で各 SOAP 要求に渡されます。この SOAP 要求を受信するノードが、停止前に要求を受信していなければ、セッション持続性の状態にかかわらずフェイルオーバーは透過的です。

回復手順: 必要なアクションはありません。SOAP 要求は、それを実行する有効なノードに送信されます。

セッション持続性が有効な場合

ユーザー体験: セッション持続性が無効な場合と同じです。

回復手順: セッション持続性が無効な場合と同じです。

シナリオ 8: Web サービスワークフロー要求が Identity Manager で実行中

シナリオの説明

このシナリオはシナリオ 7 に似ています。唯一の違いは、ノードで障害が発生したときに、ワークフローが実行中である (ノードが SOAP 要求をすでに受信している) ことです。

セッション持続性が無効な場合

ユーザー体験: このシナリオは、シナリオ 2 (ワークフローの実行中) と同様です。ワークフローは「終了」とマークされ、ユーザーには SOAP 要求の結果としてエラーが表示されます。

回復手順: ユーザーは他社アプリケーションのユーザーインタフェースを使用して、ワークフローのどこで障害が発生したかに応じて、同じパラメータまたは修正したパラメータを指定してフォームを再送信する必要があります。

セッション持続性が有効な場合

ユーザー体験: セッション持続性が無効な場合と同じです。

回復手順: セッション持続性が無効な場合と同じです。

セッションアフィニティーとセッション持続性に関する FAQ

アプリケーションサーバーを水平方向に拡張する場合は、セッションアフィニティーを有効にするべきですか。

はい。

アプリケーションサーバーを水平方向に拡張する場合は、セッション持続性を有効にするべきですか。

ごく一部の状況ではセッション持続性の有無によって透過的なフェイルオーバーができるかどうかが決まりますが、こうした状況での透過的なフェイルオーバーをビジネス要件で重視している場合を除いて、セッション持続性の使用はお勧めしません。セッション持続性によってパフォーマンスのオーバーヘッドが発生するため、ビジネス要件で透過的なフェイルオーバーが絶対に必要な場合を除いて、セッション持続性を無効のままにしてください。

「障害のシナリオについて」で説明している障害のシナリオでは、8 つのシナリオのうち 6 つは、セッション持続性が有効であるかどうかにかかわらず、エンドユーザーの体験や必要な回復アクションに違いはありませんでした。シナリオ 1 と 4 のみで、セッション持続性が有効なシナリオとセッション持続性が無効なシナリオで違いがありました。

これらの 2 つのシナリオでは、セッション持続性によりフェイルオーバーの透過性が提供されますが、これによりパフォーマンスに影響が出ます。セッションオブジェクトのサイズ、セッション持続性に使用されているリポジトリ、および特定のアプリケーションサーバーのセッション管理コードの最適化に基づいて、パフォーマンスのオーバーヘッドは 10 % から 20% の範囲またはそれ以上になります。

水平方向に拡張する場合、クラスタ内に複数のアプリケーションサーバーインスタンスを設定するべきですか。

セッション持続性が必要でなければ、複数のアプリケーションサーバーインスタンスは必ずしも必要ではありません。セッション持続性が有効でないフェイルオーバーは、すべてのアプリケーションサーバーノードが 1 つのクラスタにない場合でも設定できます。