この記事は下記サイトを参考にしています。
概要
このページは、「Standard Topologies Overview」を補足するもので、ELMデプロイメント・トポロジーで特定の目的に応じて利用できる主要な構成パターンを図と説明付きで紹介しています。以下では、それぞれのパターンを説明するために必要なコンポーネントのみを示しており、実際の環境で展開されるその他のノードは省略しています。
中規模から大規模の環境では、Db2またはOracleによる複数のデータベースサーバー構成、もしくはデータベースクラスタリングを強く推奨します。特に以下は専用のデータベースサーバーに配置することが推奨されます。
- LQE RS のデータベース
- 利用率の高いアプリケーション（一般的には RM または QM）のデータベース
Modified Departmental パターン
ELM環境は部門向け（Departmental）トポロジーから開始されることが多いですが、利用規模の拡大に伴い、必ずしも完全なEnterpriseトポロジーに移行する必要はないものの、より拡張性の高い構成が必要になります。
Modified Departmental パターンは、その中間的な構成として位置付けられます。
特に以下の場合に有効です。
- Global Configuration Management の利用が広がった場合
- 特定アプリケーションの利用負荷が増大した場合
同一製品の複数アプリケーションサーバー
ELM 7.xでは、同一製品の複数アプリケーションサーバーを配置する構成が可能です。
関連ガイド:
Planning for multiple Jazz server instances
Multiple CCM Applications - A User Perspective
クラスタリングの活用
分散型ELM環境では、各種サーバーをクラスタリングすることで以下を実現できます。
- システム耐障害性の向上
- スループット向上
ELMアプリケーションクラスタリング
このパターンはEWM（CCM）のクラスタリング例を示しています。ELM 7.xではETM（QM）もクラスタリング可能です。
重要
ELMアプリケーションをクラスタリングする場合、Jazz Authorization Server (JAS) が必須です。
Distributed Cache Microservice (DCM)
ELM 6.0.5以降のクラスタ環境では、Distributed Cache Microservice (DCM) の構成が必要です。
要件:
- クラスタ内の全ノードからアクセス可能なサーバーに配置
- デフォルトではJTSサーバー上にインストール
推奨事項:
- クラスタごとにDCMを1つ配置
- 複数クラスタで共有しない
- 性能向上のため専用サーバーへの配置を推奨
参考スペック:
| 利用規模 | 推奨構成 |
|---|---|
| 小規模 | 2コア / 4GB RAM / 100GB Disk |
| 500ユーザー程度 | 4コア / 8GB RAM / 200GB Disk |
IBM HTTP Server (IHS) と JAS のクラスタリング
Application Delivery Controller (ADC) は、データセンターで負荷分散やWebアクセラレーションを行うネットワーク機器です。
代表例:
- F5 BIG-IP
- Citrix NetScaler
- A10
多くのELM環境では、
- ADC
- IHS リバースプロキシ
を組み合わせて利用しています。
さらに、
- 複数ADC
- クラスタ化されたIHS
を組み合わせる事例もあります。
JASクラスタリング
JSA（Jazz Security Architecture）によるSSO環境では、JASを複数ノードでクラスタ化できます。
- 単一JASの場合、JASが停止すると認証要求がすべて失敗します。
- JASクラスタの場合、認証要求は稼働中のJASへ自動フェイルオーバーされるため、ログインを継続できます。
Eclipse Amlen MQTT ブローカークラスタリング
詳細は Eclipse Amlen の公式ドキュメントを参照してください。
セキュリティ構成（OIDC / SCIM / SAML）
Jazz Authorization Server を OpenID Connect Provider として利用
JSA SSOはELM 7.xで利用できる認証方式です。
特徴:
- 認証処理は各Jazzアプリケーションでは実施しない
- 認証処理はJASへ委譲
- JASがOpenID Connect Provider(OP)として機能
JASは IBM WebSphere Liberty ベースで動作します。
OIDC構成
JASをOpenID Connect Providerとして使用し、CE/CLMを認証する構成です。
SCIM（System for Cross-domain Identity Management）
JASはSCIMをサポートしています。
SCIMは、
- クラウド環境向けID管理標準
- RESTベースのプロトコル
です。
制約
SCIM利用時は、
- EWM
- ETM
- DOORS Next
の電子署名機能を利用できません。
理由:
電子署名機能はLDAPへの直接接続を必要とするためです。
サードパーティ OIDC Provider
JASは Liberty Social Login 機能を利用して、企業標準のOIDCプロバイダーへ認証を委譲できます。
制約
利用できるのはブラウザクライアントのみです。
以下はLDAP連携が必要です。
- Eclipseクライアント
- Visual Studioクライアント
- コマンドラインユーティリティ
SAML Identity Provider
JASはSAML SSOにも対応しています。
SAMLは、
- OASIS標準
- XMLベース認証トークン
を利用する方式です。
制約
- OIDC委譲と同様に、ブラウザクライアントのみが利用可能です。
- Rich ClientやCLIはLDAP接続が必要です。
LQE RS の配置パターン
既存ELM環境
既存データを持つ環境では、
- IBM推奨
- 既存LQE Jenaを維持
- 新しくLQE RSを追加
という並行運用方式です。
メリット:
- リスクを最小化
- Report Builderで両方のクエリーを利用可能
- 結果や性能の比較が可能
移行完了後はLQE Jenaを廃止できます。
新規ELM環境
新規導入の場合、
- IBM推奨
- LQE RSのみを導入
Modified Federated Topology における複数LDXサーバー
高負荷環境では単一のLDXサーバーでは十分な性能を確保できない場合があります。
その場合、
- 各事業部ごとにLDXを配置
- その事業部が利用するアプリケーションだけを索引化
する構成が可能です。
メリット
- 負荷分散
- インデックス量の削減
- パフォーマンス向上
これはFederated Topologyで各事業部ごとに独立したLDXを配置する方式と同様の考え方です。
詳細は、「Multiple Distributed LDX instances in a Modified Federated Topology Configuration」を参照してください。
