2.1 トポロジ
各主要サブシステムのインスタンス数が非常に多く、それらを接続する方法も多数あるという場合でも、可能なレイアウトがすべてサポートされるわけではありません。何が可能かということだけではなく、どういった理由でどの構成を優先するのかといったことを理解することが重要です。
2.1.1 最小設計
ユーザアプリケーションの最も簡単な論理構成は「すべてを1つずつ」インストールする方法です。1つのアイデンティティボールトツリー、Identity Managerエンジンとドライバに1インスタンス、ユーザアプリケーションの1インスタンスを実行するJBossに1インスタンスで構成されます。物理的な実装の観点から考えると、論理的にはこのすべてを1台のコンピュータで実行できます。しかし実際にはさまざまな理由(セキュリティ、メンテナンス性、特にパフォーマンス)から、この実装はお勧めできません。実用的な実際のインストールで必要なコンピュータの台数を決めるときには、最低限次の点を考慮してください。
- Novell Auditサーバ: 実行時、ユーザアプリケーション環境からのイベント情報(他の情報が含まれている場合も多い)の取得を担当します。社内の他のアプリケーションの永続ストアとして二重の役割を果たす場合もあります。さまざまな理由から、Identity Managerシステムの他の主要部分(JBossやアイデンティティボールトなど)を、Novell Auditサーバと同じコンピュータに置くことはお勧めできません。
- アイデンティティボールト: アイデンティティボールトは、非常に大量のトラフィックが発生するコンポーネントのため、高いパフォーマンスとスケーラビリティが求められます。アイデンティティボールトは専用のコンピュータで実行することもできます。つまり、ユーザアプリケーションが展開されるJBossなど、トラフィックの多い他のシステムが、アイデンティティボールトと同じコンピュータ上で同時に実行されないようにすることができます。
- データベース: MySQL (またはサポートされている他のデータベース)のこのインスタンスがNovell Auditデータベースでもある場合、このインスタンスを専用のコンピュータで実行することもできます。データベースは、ユーザアプリケーションによって次のように使用されます。
- ポータル設定データの永続ストア
- 処理中のワークフローに関する状態情報の永続ストア(プロビジョニングモジュールがインストールされている場合)
- Novell Auditのログストア(オプション)
- JBoss: パフォーマンスおよび容量上の理由から、このシステムを専用のコンピュータで実行することもできます。
以上を考慮した結果、最小設計として次の3台のコンピュータから成る構成が考えられます。
2.1.2 高可用性の設計
クラスタリングにより可用性を高めたり容量を大きくしたりする方法については、この章後半の節で詳しく説明しています。ここでは、次の点について理解してください。
- Identity Managerはマルチノードインストールおよび共有ストレージメカニズムを使用してアイデンティティボールト、エンジン、およびドライバの高可用性をサポートしています。詳細については、『Identity Manager管理ガイド』の「高可用性」を参照してください。SUSE Linuxを使用してシステムをセットアップする場合の詳細については、次のURLの記事を参照してください。
http://support.novell.com/cgi-bin/search/searchtid.cgi?/10093317.htm
- ユーザアプリケーションの高可用性は、JBossクラスタリングにより実現できます。各ノードが1つのユーザアプリケーションインスタンスを実行するようにJBossクラスタを設定できます。インスタンス間の関係はすべて同等(ピア)です。ただし、インスタンス間でのセッションレプリケーションは行われません。各インスタンスはそれ自体の作業を担当し、同等の別のノードによって開始されたセッションを終了させることはありません。
- 自動フェールオーバーはサポートされていません(直前に説明した理由により)。ただし、クラスタノードが失われた後でも、ダウンしたノードと同じワークフローエンジンIDで新しいノードがオンラインになると、中断したワークフローを再開できます(この場合、新しいワークフローエンジンが開始されると、中断したワークフローは自動的に再開されます)。
詳細については、セクション 2.4, クラスタリングを参照してください。
2.1.3 設計上の制約
一般に、アーキテクチャ上の最も重要な制約は次の2つです。
- ユーザアプリケーションインスタンスは、複数のユーザコンテナに対して、処理(検索、クエリ、およびユーザの追加など)を行うことはできません。また、あるユーザコンテナがいったんアプリケーションに関連付けられると、その関連付けが変更されることはありません。
- ユーザアプリケーションドライバを複数のユーザアプリケーションに関連付けることはできません。ただし、複数のユーザアプリケーションが同じJBossクラスタにある同等の複数のノードにインストールされている場合は例外です。つまり、ドライバとユーザアプリケーション間において1対多のマッピングはサポートされていません。
1番目の制約により、ユーザアプリケーションの設計には高度なカプセル化が求められます。
たとえば、次のような組織構造があるとします。
ユーザアプリケーションのインストール時、アイデンティティボールト内でユーザアプリケーションの検索対象となる最上位のユーザコンテナを指定するよう求められます。この場合、ou=Marketing,o=ACME、またはou=Finance,o=ACMEのように指定できます。両方を指定することはできません。ユーザアプリケーションの検索とクエリ(および管理者ログイン)はすべて、指定したコンテナのいずれかを検索範囲にして実行されます。
メモ:理論上は、o=ACMEを検索範囲に指定すればMarketingとFinanceの両方を網羅できます。しかし大規模な組織では、(MarketingとFinanceに関係する2つのコンテナだけではなく)多数のouコンテナが存在する可能性があるため、実用的ではありません。
もちろん、(リソースを共有しない) 2つの独立したユーザアプリケーションのインストールを作成し、1つをマーケティング用、もう1つを財務用として使用することもできます。各インストールは、それぞれ独自のデータベース、および適切に設定されたユーザアプリケーションドライバを持ちます。各ユーザアプリケーションは別々に管理され、独自のテーマを持つこともあります。
どうしても、1つのユーザアプリケーションインストールの同じ検索範囲にマーケティングと財務を設定する必要がある場合には、2つの方法が考えられます。1つの方法としては、2つの同等ノードの上位に新しいコンテナオブジェクト(ou=MarketingAndFinanceなど)を挿入し、その新しいコンテナを検索範囲のルートとしてポイントする方法があります。もう1つの方法は、元のACMEツリー上の必要な部分を組み合わせた、フィルタリングされたレプリカ(特殊なタイプのeDirectoryツリー)を作成し、そのレプリカのルートコンテナをポイントするという方法です(フィルタリングされたレプリカの詳細については、『Novell eDirectory管理ガイド』を参照してください)。
特定のシステムレイアウトについてご質問がある場合には、Novellの担当者までお問い合わせください。