3. WebSphere Portalシステム構成 ビジネス・ユニットの名前 1. 基本的なトポロジー 2. 冗長構成
by user
Comments
Transcript
3. WebSphere Portalシステム構成 ビジネス・ユニットの名前 1. 基本的なトポロジー 2. 冗長構成
ビジネス・ユニットの名前 3. WebSphere Portalシステム構成 1. 基本的なトポロジー 2. 冗長構成 3. バックアップ・リカバリー PSU_temp_0522 2008/12/168/3/05 この文書のデータの利用または公開には、 最終ページに記載されている制限事項が適用されます。 © 2008 IBM Corporation ビジネス・ユニットの名前 1. 基本的なトポロジー コンポーネントの種類 WebSphere Portalを構成するコンポーネントには、以下のようなものがあります。 – HTTP サーバー • – Web Application Server • – • 2 IBM DB2 9.1/8.1, Oracle 10g/9i, Microsoft SQL Server Enterprise Edition2005をサ ポート Derby 10.1はWPインストール時に自動的にインストールされるが、本番環境では、 Derbyのデータを他のDB Serverに移行することを推奨 LDAP サーバー • PSU_temp_0522 WebSphere Portal Server 本体 DB サーバー • – WebSphere Portal が稼動するアプリケーションサーバーとして、WebSphere Application Server 6.1.0.15を同梱 Portal サーバー • – IBM HTTP Server をはじめ、Apache Server 、Microsoft Internet Information Service、 IBM Lotus Domino、Sun Java System Web Serverをサポート • • IBM Tivoli Directory Server, Lotus Domino Enterprise Server, Novell eDirectory, Sun Java System Directory Server, Microsoft Windows Active Directory, IBM z/OS Security Server, z/OS e Security Serverなどをサポート WPインストール時には、Derbyにユーザー情報を格納 Lotus Companion製品を使用する場合は、Lotus Domino LDAPを利用することを推奨 © 2006 IBM Corporation この文書のデータの利用または公開には、最終ページに記載されている制限事項が適用されます。 ビジネス・ユニットの名前 2. 基本的なトポロジー トポロジーの種類 WebSphere Portalの基本的なトポロジーは以下の3つの種類があります。 1Tier 構成 – HTTP サーバー/Application サーバー/Portal サーバー/LDAP/DB サーバーの全てのコンポー ネントが1台のサーバーに含まれています。 – 通常は、本番稼動には推奨されず、デモや小規模の検証環境などに利用されます。 – All in ONE構成と呼ぶ場合もあります。 2Tier 構成 – HTTP サーバー＋Application サーバー＋Portal サーバーとDB サーバー＋LDAPが別筐体とな ります。 – DB サーバーとLDAPサーバーは同じ筐体でも別筐体でも構いません。 3Tier 構成 – HTTP サーバー、Application サーバー＋Portal サーバー、DB サーバー＋LDAPがそれぞれ別 筐体となります。 PSU_temp_0522 3 – DB サーバーとLDAPサーバーは同じ筐体でも別筐体でも構いません。 © 2006 IBM Corporation この文書のデータの利用または公開には、最終ページに記載されている制限事項が適用されます。 ビジネス・ユニットの名前 2. 基本的なトポロジー 1Tier構成（検証向け） すべてのコンポーネントが1台に構成されています 開発やデモ、小規模なテスト検証環境向けになります 【メリット】 【デメリット】 9 サーバー台数が少なくてすみます 9 2-Tier構成や高可用性の構成に拡張できませ ん 9 管理・運用費用が抑えられます 9 問題の切り分けに時間を要します WP WAS HTTP Server LDAP Webブラウザー DB2 ポータルサーバー PSU_temp_0522 4 © 2006 IBM Corporation この文書のデータの利用または公開には、最終ページに記載されている制限事項が適用されます。 ビジネス・ユニットの名前 2. 基本的なトポロジー 2Tier構成 ポータルサーバーとリポジトリサーバーのコンポーネントが、それぞれ別サーバーに構 成されています 【メリット】 【デメリット】 9 ポータルとリポジトリを分離しているため、将 来的な拡張が可能です 9 同時ユーザー数が多い場合やSSL通信を行う 場合、HTTPコンポーネントに大きな負荷がかか るため、ポータルサーバー全体に負荷がかかり ます 9 管理・運用費用が比較的抑えられます WP WAS LDAP HTTP Server DB2 Webブラウザー ポータルサーバー リポジトリサーバー PSU_temp_0522 5 © 2006 IBM Corporation この文書のデータの利用または公開には、最終ページに記載されている制限事項が適用されます。 ビジネス・ユニットの名前 2. 基本的なトポロジー 3Tier構成 HTTP サーバー、Application サーバー＋Portal サーバー、DB サーバー＋LDAPがそ れぞれ別サーバーに構成されています 高いセキュリティが要求されるWebサイトでの利用に適しています 【メリット】 【デメリット】 9 HTTPサーバーとアプリケーションサーバーを 分離することで、アプリケーションサーバーの 負荷を抑えることができます 9 サーバーの台数が多くなります 9 システム構成がより複雑になります 9 各サーバー間にファイヤーウォールを置くこと で非常に高いセキュリティを実現できます HTTP Server WP LDAP WAS DB2 Webブラウザー Webサーバー PSU_temp_0522 6 アプリケーション サーバー リポジトリサーバー © 2006 IBM Corporation この文書のデータの利用または公開には、最終ページに記載されている制限事項が適用されます。 ビジネス・ユニットの名前 2.冗長構成 冗長構成の意義 ポータル・システムの可用性向上や障害対策のために、ポータル・システムの各コンポーネントを複 数配置することで冗長化を行えます。 冗長化の意義としては、以下のものが考えられます。 • • • スループットの向上 – 多数のリクエストを複数のサーバーで処理できます。 フェイルオーバー – 1つのサーバーに異常が発生しても、他のサーバーでサービスの継続が可能です。 スケーラビリティー – リクエストの増加に対して、サーバーを増やして対応できます。 また、冗長化を行うにあたって必要とされる要件としては、以下のものが考えられます。 • • • • 各サーバーが簡単に一元管理ができること 要件に応じて柔軟に構成変更ができること １サーバーがダウンしてもTake Overが可能であること（耐障害性が高い） 高パフォーマンスを維持できること WebSphere Portalでは、上記要件を満たすためのクラスタリング構成をサポートしています。 PSU_temp_0522 7 © 2006 IBM Corporation この文書のデータの利用または公開には、最終ページに記載されている制限事項が適用されます。 ビジネス・ユニットの名前 2.冗長構成 冗長構成とは ポータルシステムにおける冗長化の方式の例として、各コンポーネントによって以下のような対応を 取ることが可能です。 コンポーネント 多重化の方式 分散方式 OSによる違い 負荷分散サーバー Edge Componentの機能による HA構成 Active-Standby Edge ComponentのHAについては、 OS依存は特になし ポータルサーバー WASの水平クラスター構成 Active-Active WASのクラスタリングのため、OS依 存は特になし （障害発生時は縮退） LDAPサーバー *1 OSの機能を利用したHA構成 AIX：HACMP Active-Standby Windows：MSCS リポジトリサーバー*2 Linux：3rdパーティー製品（Cluster Perfect/Lifekeeper） *1 マスター/スレーブで構築し、負荷分散サーバーで振り分ける方法もあります。 *1,*2 HWの機能で振り分けも可能です。 【凡例】 Take Over Take Over 通常の経路 障害時の経路 PSU_temp_0522 Webブラウザー 8 負荷分散サーバー ポータルサーバー LDAP/リポジトリサーバー © 2006 IBM Corporation この文書のデータの利用または公開には、最終ページに記載されている制限事項が適用されます。 ビジネス・ユニットの名前 2.冗長構成 ポータルサーバーのクラスタリングの種類 WebSphere Application Serverのクラスタリングについて記述します – その他コンポーネントの多重化手順については、それぞれの製品資料をご参照ください WebSphere Application Serverでは、下記2種類のクラスター構成方法があります – クローンでない複数WPインスタンスを同一OSにインストールすることはサポートされていません 水平クラスター 垂直クラスター – マシンの台数を増やし、プロセス数を増加す ることでパフォーマンスを向上させるものです。 – マシンのスペックをUpし、プロセス数を増やす ことでパフォーマンスを向上させます。 – CPU使用率とリソースは独立しています。 – CPUや他の資源を競合して使用します。 複数のマシンに プロセスが存在 Web Server PSU_temp_0522 Webブラウザ 9 1台のマシンに複数 のプロセスが存在 Application Server Client Web Server Application Server © 2006 IBM Corporation この文書のデータの利用または公開には、最終ページに記載されている制限事項が適用されます。 ビジネス・ユニットの名前 2.冗長構成 WASクラスタリング：セルの考え方 セルの考え方 – WP V6.1は、WAS V6.1.0.15上で動作します。そのため、WAS V6.1のクラスタリングの考え方を理 解しておく必要があります。 – WAS V5.0以降、WASのクラスタリングは「セル」という考えをしていますが、セルとは、ノードの集 まりで、論理的な管理の単位です。 – また、セルを構成するすべてのノードをノード・エージェント経由で管理するDeployment Manager (DM)という機能があり、WPでもクラスタリング構成にする場合は、DMコンポーネントが必要となり ます。 シングル・ノード構成 アプリケーション・サーバー ノード – 1つのJVMプロセス上で稼動します。 プロセスA プロセスB – Web/EJBコンテナー、Namingサービス、リソース アプリケーション・サーバー 管理などが含まれます。 ノード – 通常は物理的な1つのマシンに対応します。 しかし、1つのマシン上に複数のノードを構成 することも可能です。 – アプリケーション・サーバーの集まりです。 セル – ノードの集まりです。論理的な管理の単位です – Deployment Managerはセルを構成するすべて のノードをノード・エージェント経由で管理します。 PSU_temp_0522 10 マルチ・ノード構成 セル ノードA DM ノードB ノードC Node agent プロセスC プロセスD アプリケーション・サーバー Node agent プロセスE プロセスF アプリケーション・サーバー © 2006 IBM Corporation この文書のデータの利用または公開には、最終ページに記載されている制限事項が適用されます。 ビジネス・ユニットの名前 2.冗長構成 WPのクラスター構成 WPでは、ConfigEngineタスクを利用してクラスタリングを構成できます。（そのとき、WASのaddNodeコ マンドを利用してクラスタリングを構成しています。） WPのクラスタリングは、WASのクラスター構成を基にしています クラスタリング構成にする際には、Deployment Manager(DM) が必要となります。Deployment Managerのライセンスについては別途ライセンス情報をご確認ください。 WPのリポジトリーとして導入時に使われているDerbyは、リモート・アクセスをサポートしておりませ んので、DB2もしくは別のDB製品に移行する必要があります シングル・ノード構成 マルチ・ノード構成 セル ノード ノード JVMプロセス server1 DM JVMプロセス WebSphere_Portal Node agent JVMプロセス addNodeコマンド ノード ノード server1 JVMプロセス WebSphere_Portal Node agent JVMプロセス JVMプロセス server1 WebSphere_Portal PSU_temp_0522 11 © 2006 IBM Corporation この文書のデータの利用または公開には、最終ページに記載されている制限事項が適用されます。 ビジネス・ユニットの名前 2.冗長構成 2-Tierでの負荷分散/高可用構成例 WP LDAP WAS HA構成 HTTP Server Active-Standby 構成 Deployment Mgr LDAP クラスター構成 Webブラウザー WP 負荷分散サーバー WAS （ロード・バランサー） HTTP Server ・・・・・・・ ポータル・サーバー LDAPサーバー Repository HA構成 負荷状況に合わせて機器追加 WP WAS HTTP Server PSU_temp_0522 12 ポータル・サーバー Repository リポジトリ・サーバー © 2006 IBM Corporation この文書のデータの利用または公開には、最終ページに記載されている制限事項が適用されます。 ビジネス・ユニットの名前 2.冗長構成 3-Tierでの負荷分散/高可用構成例 WP LDAP WAS HTTP Server Active-Standby 構成 HA構成 Deployment Mgr LDAP クラスター構成 WP Webブラウザー 負荷分散サーバー LDAPサーバー WAS （ロード・バランサー） HTTP Server Webサーバー Repository アプリケーション サーバー HA構成 負荷状況に合わせて機器追加 WP WAS Repository PSU_temp_0522 13 リポジトリ・サーバー © 2006 IBM Corporation この文書のデータの利用または公開には、最終ページに記載されている制限事項が適用されます。 ビジネス・ユニットの名前 3.バックアップ・リカバリー バックアップ対象 WebSphere Portalにおけるバックアップ対象は、以下の3種類に分類されます バックアップシナリオ WP ＜ポータルサーバー＞ テーマ、スキン、ポートレットの追加によっ て追加/変更されるディレクトリー/ファイ ルをOSのコピーコマンドでバックアップ・リ カバリー ＜LDAPサーバー＞ LDIFのexport,import ＜リポジトリ・サーバー＞ Wpsdbのexport,import WAS LDAP Repository PSU_temp_0522 14 © 2006 IBM Corporation この文書のデータの利用または公開には、最終ページに記載されている制限事項が適用されます。 ビジネス・ユニットの名前 3.バックアップ・リカバリー バックアップとリストアの方法 ポータル・サーバーについて – ポータル構成終了後、システム・バックアップを取得します – 日常のポータル・サーバーのバックアップは、以下のイベント発生時に取得します • • • ポートレットの導入・更新 テーマ・スキンの導入・更新 WASやWebSphere Portalへのfix適用 – システムを停止し、再度システム・バックアップを取得します LDAPサーバーについて – LDAPにより異なりますが、ユーザー・グループデータについては、LDIF形式でのエクスポートに よるバックアップが一般的です – リストアについても、LDAPにより異なりますが、LDIFファイルをインポート方法が一般的です リポジトリ・サーバーについて – リポジトリ・サーバーには、アクセス制御情報・構成情報・ページ情報・カスタマイズ情報が格納さ れています – 通常は、データベースを停止し、ポータルのデータベース内容をフルエクスポートします – エクスポートしたデータベースをインポートすることで、リストアする事ができます PSU_temp_0522 15 © 2006 IBM Corporation この文書のデータの利用または公開には、最終ページに記載されている制限事項が適用されます。 ビジネス・ユニットの名前 3.バックアップ・リカバリー リポジトリサーバーに格納されるデータの種類 Release Data – ポータル上のコンテンツを定義するためのデータ（ページ、ポートレット、テーマ、テンプレート、 クレデンシャルスロット、パーソナライズルール、ポリシーなど）です – 基本的に管理者が編集するものであり、通常運用時に修正が入ることはありません Community Data – 通常運用時、一般ユーザーによって編集されるデータ（共有ドキュメント、アプリケーションリ ソース）です Customization Data – 特定のユーザーにひもづく共有されないデータ（ポートレットデータや個人用ページ）です PSU_temp_0522 16 © 2006 IBM Corporation この文書のデータの利用または公開には、最終ページに記載されている制限事項が適用されます。