2.1 トポロジ

各主要サブシステムは多数のインスタンスを持つことができ、さまざまな接続手段があります。可能なレイアウトがすべてサポートされるわけではありません。この節は、一部の設定方法が他の設定方法に比べて広く使われているかを説明する3つのサブセクションに分かれています。

2.1.1 最小設計

ユーザアプリケーションの最も簡単な論理構成は「すべてを1つずつ」インストールする方法です。1つのアイデンティティボールトツリー、Identity Managerエンジンとドライバに1インスタンス、ユーザアプリケーションの1インスタンスを実行するApplication Serverの1インスタンスで構成されます。物理的な実装の観点から考えると、論理的にはこのすべてを1台のコンピュータで実行できます。しかし実際にはさまざまな理由(セキュリティ、メンテナンス性、パフォーマンスなど)から、この実装はお勧めできません。実用的な実際のインストールで必要なコンピュータの台数を決めるときは、最低限次の点を考慮してください。

Novell Auditサーバ: このアプリケーションは、ランタイム時にユーザアプリケーション環境からのイベント情報の取得を担当します(他の多数の情報も取得することがあります)。社内の他のアプリケーションの永続保存ストアとして二重の役割を果たす場合もあります。さまざまな理由から、Identity Managerシステムの他の主要部分(アプリケーションサーバやアイデンティティボールトなど)を、Novell Auditサーバと同じコンピュータに置くことはお勧めできません。

識別ボールト: アイデンティティボールトは、非常に大量のトラフィックが発生するコンポーネントのため、高いパフォーマンスとスケーラビリティが求められます。アイデンティティボールトは専用のコンピュータに置くことを検討してください。アプリケーションサーバなどのトラフィックが多いシステムと同じコンピュータにアイデンティティボールトを置くことはお勧めできません。

データベース: サポートするデータベースのこのインスタンスがNovell® Auditデータベースでもある場合、このインスタンスを専用のコンピュータで実行することもできます。ユーザアプリケーションは、このコンポーネントを次の目的で使用します。

  • ポータル設定データの永続ストア

  • 処理中のワークフローに関する状態情報の永続保存ストア(Provisioning Moduleがインストールされている場合)

  • Novell Auditのログストア(オプション)

アプリケーションサーバ: パフォーマンスおよび容量上の理由から、このシステムは専用のコンピュータで実行してください。

これらの検討事項では、最小3台構成の環境を提案しています。

2.1.2 高可用性の設計

クラスタリングによる高可用性と高容量については、セクション 2.7, クラスタリングを参照してください。ここでは、次の点に留意してください。

  • Identity Managerはマルチノードインストールおよび共有ストレージメカニズムを使用してアイデンティティボールト、エンジン、およびドライバの高可用性をサポートしています。詳細については、『Identity Manager管理ガイド』の「高可用性」を参照してください。SUSE® Linuxを使ってこのようなシステムを設定する手順の概要は、次の項目を参照してください。

    http://support.novell.com/cgi-bin/search/searchtid.cgi?/10093317.htm

  • ユーザアプリケーションの高可用性は、JBossクラスタリングにより実現できます。各ノードが1つのユーザアプリケーションインスタンスを実行するようにJBossクラスタを設定できます。これらのインスタンスは、すべて同等(ピア)です。

  • 自動フェイルオーバーがサポートされています。割り込みされたワークフローは、クラスタノードがなくなった後に再開できます。

詳細については、セクション 2.7, クラスタリングを参照してください。

2.1.3 設計上の制約

設計上、次の2つの重要な制約があります。

  • ユーザアプリケーションインスタンスは、複数のユーザコンテナを処理する(検索、クエリ、およびユーザの追加などを行う)ことはできません。また、アプリケーションとコンテナの関係は永続的なものと見なされます。

  • ユーザアプリケーションドライバを複数のユーザアプリケーションに関連付けることはできません。ただし、複数のユーザアプリケーションが同じJBossクラスタにある同等の複数のノードにインストールされている場合は例外です。つまり、ドライバとユーザアプリケーション間において1対多のマッピングはサポートされていません。

1番目の制約により、ユーザアプリケーションの設計には高度なカプセル化が求められます。

たとえば、次のような組織\'8d\'5c造があるとします。

図 2-1 サンプルの組織構造

図

ユーザアプリケーションのインストール時、アイデンティティボールト内でユーザアプリケーションの検索対象となる最上位のユーザコンテナを指定するよう求められます。この場合、「ou=Marketing,o=ACME」や「ou=Finance,o=ACME」のように指定できます。 両方を指定することはできません。ユーザアプリケーションの検索とクエリ(および管理者ログイン)はすべて、指定したコンテナのいずれかを検索範囲にして実行されます。

メモ:理論上は、o=ACMEを検索範囲に指定すればMarketingとFinanceの両方を網羅できます。しかし大規模な組織では、(MarketingとFinanceに関係する2つのコンテナだけではなく)多数のouコンテナが存在する可\'94\'5c性があるため、実用的ではありません。

もちろん、(リソースを共有しない) 2つの独立したユーザアプリケーションのインストールを作成し、1つをマーケティング用、もう1つを財務用として使用することもできます。各インストールは、それぞれ独自のデータベース、および適切に設定されたユーザアプリケーションドライバを持ちます。各ユーザアプリケーションは別々に管理され、独自のテーマを持つこともあります。

1つのユーザアプリケーションインストールの同じ検索範囲にMarketingとFinanceを設定する必要がある場合は、2つの方法が考えられます。1つの方法としては、2つの同等ノードの上位に新しいコンテナオブジェクト(ou=MarketingAndFinanceなど)を挿入し、その新しいコンテナを検索範囲のルートとしてポイントする方法があります。もう1つの方法は、フィルタリングされたレプリカ(特殊なタイプのeDirectoryツリー)を作成して元のACMEツリーで必要な部分を組み合わせ、そのレプリカのルートコンテナでユーザアプリケーションをポイントする方法です。(フィルタリングされたレプリカの詳細については、『Novell eDirectory Administration Guide』を参照してください)。

特定のシステムレイアウトについて質問がある場合は、Novellの担当者までお問い合わせください。