インストールおよびアップグレード > 高度な展開の検討事項 > クラスタ Windchill 環境のインストールと設定
  
クラスタ Windchill 環境のインストールと設定
このセクションでは、ファイルボルト、データのロードに留意しながら、クラスタ Windchill システムのインストールと設定の詳細について説明します。
サーバークラスタ設定の概要
クラスタはコンピュータの集合で、個別にアクセスすることも、1 つのマシンとしてアクセスすることもできます。クラスタでは、HTTP リクエストまたは RMI メソッド呼び出しとして定義される 1 つの作業単位を処理し、多くの Windchill サーバーのいずれかに配布できます。
1 台のサーバーに比べて、クラスタは、パフォーマンス、スケーラビリティ、および信頼性において優れています。パフォーマンスが向上する理由は、特定のノードで Windchill サーバープロセスが競合しなくなることにあります。システムは拡張可能で、負荷の増加に伴い、Windchill サーバーを追加できます。このスケーラビリティにより、システムの信頼性も向上します。Windchill サーバーに障害が発生した場合は、リクエストをほかのサーバーに誘導できます。
通常のサーバークラスタの設定
以下の図は通常のクラスタ設定を示します。この図では、5 台のコンピュータ (A、B、C、D、および E) が連携してパフォーマンス、スケーラビリティ、および信頼性を向上させます。
通常の Windchill クラスタは、以下の 3 つのセグメントから構成されます。
負荷分散ルータ (A)
永続的ストレージサーバーまたはメインキャッシュ (D)
1 つまたは複数の追加の Windchill サーバーまたはキャッシュクライアント (B と C)
図に示すように、Windchill クラスタは物理ボルトが維持されているサーバーと対話します (E)。ファイルサーバーとの Windchill の対話のセットアップについてはこの一連のトピックでは説明していません。セットアップの詳細については、ファイルサーバーアドミニストレータを参照してください。
負荷分散ルータはクライアントのリクエストを受信して、多数の Windchill サーバーのいずれかに配布します。周囲のネットワークからは、このルータが 1 台の Windchill サーバーのように見えます。ロードバランサーの詳細については、セクション「負荷分散ルータの設定」を参照してください。
クラスタに属する Windchill サーバーは、データベースとキャッシュメカニズムをクラスタのほかのメンバーと共有する点を除き、単純な独立した Windchill サーバーと類似しています。キャッシュには最上位レベルのメインキャッシュの更新が適用されるので、これらのサーバーノードはキャッシュクライアントとも呼ばれます。これらのノードは DNS 名を共有し、後続のリクエスト用に、個々の Windchill サーバーではなくクラスタにクライアントを誘導します。
永続的ストレージサーバーマシンには、Windchill のメインキャッシュサーバーとバックグラウンドメソッドサーバーだけでなく、リレーショナルデータベースも含まれます。あらゆる配置で、1 つのデータベースを使用して、データベースがクラスタ化されている場合でも、クラスタ全体の永続的データを保存します。クラスタ化された環境では、個別のサーバーマネージャを展開し、"メインキャッシュ" として指定する必要があります。すべてのクライアントキャッシュでキャッシュを同期させるのは、このサーバーの責任です。
キャッシュは、クラスタ内の各ノードのサーバーマネージャプロセスにより管理されます。前の図で、永続的ストレージサーバーで動作するサーバーマネージャは、クラスタのメインキャッシュとしても機能します。追加のプロパティを wt.properties ファイルに設定して、分散したキャッシュメカニズムを適切に設定する必要があります。
* 
Windchill プロパティファイルを編集するには、xconfmanager ユーティリティを使用します。詳細については、xconfmanager ユーティリティについてを参照してください。
* 
クラスタシステムでは、製品表現の作成ウィンドウでローカルディスクのファイルを使用して、製品表現を作成できます。詳細については、製品表現の表示を参照してください。
メインサーバーマネージャのフェイルオーバー
キャッシュメインサーバーマネージャは常に 1 つ存在します。デフォルトでは、ほかのサーバーマネージャとのネゴシエーションを通じて、このメインサーバーマネージャが初期選択されます。一般的に、これは起動した最初のクラスタノードのサーバーマネージャです。クラスタがメインキャッシュノードを選択した後、このサーバーマネージャが引き続きメインキャッシュとなります。ただし、このサーバーマネージャが到達不能となった場合は、別のサーバーマネージャが自動的にメインサーバーマネージャになります。メインキャッシュノードの切り替え後に、前のメインサーバーマネージャが到達可能になると、セカンダリキャッシュステータスに戻ります。
負荷分散ルータの設定
負荷分散ルータはクライアントのリクエストを受信して、使用可能な Windchill サーバーに配布します。このルータはファイアウォールとして動作する場合もあり、Windchill クラスタを周囲のネットワークから分離します。周囲のネットワークからは、このルータが 1 台の Windchill サーバーのように見えます。
* 
前に説明したロードバランサーの設定は、Alteon ロードバランサーという特定のタイプのロードバランサーのものです。ほかのロードバランサーでは手順が異なる場合があります。また、PDS リファレンスアーキテクチャのロードバランサーは Web サーバーに対するトラフィックのみを負荷分散します。PDS リファレンスアーキテクチャは、分割した Web サーバーシステムを実装しているので、Web サーバーからサーブレットエンジンおよびメソッドサーバーへのトラフィックの負荷分散は、AJP13 負荷分散を使用して処理されます。
アフィニティの設定
エンドユーザーは、通常、負荷分散ルータを介して Windchill クラスタにアクセスします。負荷分散ルータは、作業負荷を均等に配布するために、複数のマシンにリクエストを送信します。ただし、ロードバランサー内でのアフィニティの設定は、サーブレットエンジンのセッションキャッシュと、複数ステップ操作の処理を利用できます。この設定によって、後続の関連リクエストは、同じサーブレットエンジンとメソッドサーバーに送られ、処理されます。
負荷分散ルータでは、この境界で許可されるすべての TCP トラフィックと IP トラフィックの負荷を分散する必要があります。そのため、HTTP または HTTPS へのトラフィック (HTTP または HTTPS による RMI のトンネル化など) を制限する場合は、HTTP または HTTPS を処理する負荷分散ルータのみが必要になります。この境界でほかの TCP 通信と IP 通信 (直接 RMI トラフィックなど) を許可する場合は、その通信も負荷分散する必要があります。
HTTP または HTTPS により RMI をトンネル化する場合、メソッドサーバーにはアフィニティ要件が追加されません。ただし、ロードバランサーが HTTP トラフィックと HTTPS トラフィックにアフィニティを正しく適用することが依然として必要です。これには、トンネル化されたトラフィックも含まれます。直接 RMI ポートがルータによって負荷分散されている場合、ロードバランサーはこれらのポートにアフィニティを適用する必要があります。RMI は Cookie などのタグをアフィニティ目的で処理できるプロトコルではないので、通常、アフィニティの適用は、クライアントホストアフィニティを使用して一定の期間行われます。
しかし、Windchill のサーブレットエンジンにもアフィニティ要件があり、クライアントホストアフィニティまたはセッションアフィニティのいずれかが必要です。クライアントホストアフィニティでは、一定期間内の特定のホストからのすべてのリクエストを同じサーブレットエンジン JVM にマッピングして、ホストのすべてのセッションデータをその JVM に保存します。セッションアフィニティはより正確に、サーブレットエンジンの実際の要求を満たします。
IP 負荷分散ルータがこのアフィニティの確保を行うかどうかは、アーキテクチャによって異なります。たとえば、IP 負荷分散ルータを使用して複数のマシンで負荷分散し、各マシンで mod_jk を使用して Apache ベースの Web サーバーを実行し、すべてのマシンのサーブレットエンジンで負荷分散するとします。この設定を正しく行うと、mod_jk によりセッションアフィニティが確保され、IP ロードバランサーはアフィニティを確保する必要がなくなります。ただし、受信リクエストは任意の Web サーバーに送られ、初期処理が行われる場合があります。その場合、リクエストは別のマシン上のサーブレットエンジンに送られ、後続の処理が行われます。
また、Apache ベースの Web サーバーと mod_jk をロードバランサーとして使用し、「ロードバランサー」マシンに 1 つの Web サーバーのみを実装し、クラスタノードのサーブレットエンジンにリクエストを送信することもできます。この方法では、すべての HTTP(S) 以外のトラフィックを HTTP(S) でトンネル化する必要があります。
最も簡単な方法は、すべての TCP 接続と IP 接続にホストアフィニティを使用して負荷分散ルータを設定することです。これにより、特定のクライアントホストからのすべてのリクエストは、一定期間、クラスタの同じノードによって処理されます。
* 
設定は、負荷分散ソフトウェアおよびハードウェアによって大きく異なります。この一連のトピックでは、Windchill サーバーシステムの設定についてのみ説明します。
ロードバランサーまたはファイアウォールに必要なポートの決定
クライアントシステムでは、通常、負荷分散ルータを介して Windchill クラスタサーバー環境にアクセスします。ポートのセキュリティ上の問題や制限により、クラスタ環境で Workgroup Manager と Windchill Visualization を統合する場合、ユーザーは、ロードバランサーに使用する TCP ポートと IP ポートを決める必要があります。
クライアントとサーバー間の通信要件は、可能な通信環境が多数あることで複雑になります。クライアントとサーバー間の通信に使用するポートの要件を簡素化するために、この説明では次のように仮定します。
クライアントサイトとサーバーサイト間の通信ラインは 1 つのみである。
クライアントサイトは、HTTP クライアントと HTTPS クライアントのみで構成される。
Web サーバー、サーブレットエンジン、LDAP、Oracle などの Windchill サーバーコンポーネントはすべてサーバーサイトにある。
クライアントサイトとサーバーサイト間には 1 つのロードバランサーとファイアウォールが設定されている。
HTTP または HTTPS によって RMI をトンネル化する場合、ロードバランサーでは HTTP ポートまたは HTTPS ポートのみを開く必要があります。それ以外の場合、開くポートはユーザー環境に応じて、以下のようになります。
デフォルトのコア Windchill の場合は、以下のポートを開く必要があります。
HTTP ポートまたは HTTPS ポート
wt.properties に定義されている wt.manager.port および wt.method.minPort から wt.method.maxPort まで
Workgroup Manager の場合は、製品に応じてほかのポートも開く必要があります。Pro/E 2001、CADDS 5、および CATIA V4 の Windchill Workgroup Manager では、Windchill サーバーと連動するレジストリサーバー (RS) を使用します。レジストリサーバーは 2 つのポートを使用します。レジストリサーバーは、起動するたびに、registryserver.ini ファイルに指定されたポートと、別のランダムポートを使用します。Windchill Workgroup Manager が機能するには、両方のポートのアクセス権限が必要です。
ポートを手動で割り当てるには、<Windchill>/codebase/cfg/siteregistryclient.ini および registryserver.ini に定義された "registry_port" を使用します。
Workgroup Manager for Creo Parametric および大半のワークグループマネージャによって使用される Windchill Workgroup Manager のフレームワークは、通常の HTTP クライアントです。したがって、すべての HTTP クライアント (Web ブラウザなど) に適用するサーバー設定は、Workgroup Manager for Creo Parametric およびその他の大半のワークグループマネージャにも適用されます。
PTC Solution Installer (PSI) によるポート設定の詳細については、必要条件チェックリストを参照してください。
Windchill 環境のクラスタ化の設定
PTC では、個々のニーズに応じて、2 つのクラスのクラスタ設定をお勧めしています。最初のクラスのクラスタ設定では、クラスタ内のすべてのノードを同じにします。クラスタ内の各ノードは、ネゴシエーションによりメインキャッシュノードになることができます。このタイプのクラスタを、同一ノードクラスタと呼びます。2 番目のクラスのクラスタ設定では、セカンダリノードとメインノードを別に設定します。この場合、専用メインキャッシュノードと専用フォアグラウンドセカンダリキャッシュノードがそれぞれ存在することになります。このタイプのクラスタを、専用メインクラスタと呼びます。
Windchill のすべてのクラスタノードを同様に設定し、いずれのサーバーも同じリクエストに同じレスポンスで応答できるようにします。バックグラウンドでリクエストに複数のサーバーが応答する場合でも、クライアントは 1 つのサーバーとしてこのシステムにアクセスします。
Windchill 環境のクラスタ化を設定するには、以下のセクションを確認し、使用する環境に該当するセクションの手順を実行してください。
同一ノードクラスタの設定
専用メインノードがあるクラスタの設定
クラスタ設定における Windchill アダプタの設定 (オプション)
* 
可用性の高いキュー処理の設定を考慮する場合は、高可用性 Windchill クラスタでの Worker Agent の設定で詳細を参照してください。
同一ノードクラスタの設定
設定例では、すべてのクラスタノードが同じように設定されています。適切に設定された 1 つのクラスタノードをほかのノードに同期化し、修正を行うことなく、クラスタ内で実行できます。
設定では、すべての HTTP アクセスが主要 IP ロードバランサーを経由する必要があります。次の「プロパティの例」セクションに、最小の設定プロパティを示します。これらのプロパティの詳細な説明については、セクション「例で使用しているプロパティについて」を参照してください。
プロパティの例
すべてのクラスタノードに次のプロパティ (wt.properties ファイルを参照) が必要です。
wt.rmi.server.hostname=A
wt.cache.master.slaveHosts=B, C, D
専用メインノードがあるクラスタの設定
設定例では、すべてのクラスタノードが同じように設定されています。ただし、クラスタノードになることができるのは、特定のノードのみです。適切に設定された 1 つのクラスタノードをほかのノードに同期化し、修正を行うことなく、クラスタ内で実行できます。
設定では、すべての HTTP アクセスが主要 IP ロードバランサーを経由する必要があります。次の「プロパティの例」セクションに、最小の設定プロパティを示します。これらのプロパティの詳細な説明については、セクション「例で使用しているプロパティについて」を参照してください。
プロパティの例
すべてのクラスタノードに次のプロパティ (wt.properties ファイルを参照) が必要です。
wt.rmi.server.hostname=A
wt.cache.master.slaveHosts=B, C, D
wt.cache.master.hostname=D
例の図では、ホスト D がメインキャッシュになることができます。メインキャッシュになれるホストが複数ある場合、それらのホスト名を wt.cache.master.hostname プロパティの値に追加できます。
例で使用しているプロパティについて
次の表に、前の例で使用しているプロパティとその使用方法をまとめます。
プロパティ
説明
wt.rmi.server.hostname=A
クラスタ内の各ノードは、全体としてクラスタのように動作する必要があります。クラスタ内の個々のノードに対するリクエストは、ほかのすべてのノードと同じレスポンスを生成する必要があります。共通名が現在のノードになるように、ローカルマシンのホスト照会を設定します。次のエントリを、サーバーのホストファイル (UNIX ホストファイルは /etc/hosts、Windows ホストファイルは <WNNT>/system32/drivers/etc/hosts) に追加します。
127.0.0.1 A
クライアントが 1 つのサーバークラスタとしてのこれらのノードにアクセスするには、RMI ホスト名を、クラスタ全体で共通の既知の名前に設定する必要があります。ここではホスト A です。このプロパティはインストール時に設定されています。
wt.cache.master.slaveHosts=B, C, D
JMX 管理コンポーネントが各ノードから通信できるようにするには、すべてのクラスタノードにこのプロパティが必要です。このプロパティは、プロパティ内のホストが信頼されており、セカンダリノードへのアクセスを許可されていることを Windchill クラスタノードにも指示します。
wt.cache.master.hostname=D
このプロパティは、メインキャッシュになることができるホスト名を定義します。このプロパティが定義されていない場合、クラスタ内の任意のホストがメインキャッシュになることができます。このプロパティが設定されている場合、すべてのクラスタノードに設定する必要があります。
クラスタ設定における Windchill アダプタの設定 (オプション)
Windchill アダプタは、Windchill セカンダリキャッシュノードで実行されているフォアグラウンドメソッドサーバーに対して自動的に設定されます。インストールフェーズでは、1 つの Windchill アダプタが設定されます。Windchill アダプタが起動すると、設定されているポート範囲が Windchill RMI で使用されているポート範囲 (wt.method.minPort および wt.method.maxPortwt.property の値により設定) と比較されます。設定されているポート範囲が Windchill RMI で使用されているポート範囲より小さい場合、同じサイズになるように自動的に拡大されます。
Windchill アダプタの設定の詳細については、Windchill アダプタのセクションを参照してください。
クラスタノードでのメソッドサーバーおよびバックグラウンドメソッドサーバーの設定
各クラスタノードで使用できる MethodServer および BackgroundMethodServer インスタンスの数に制限はありません。専用メインノードがあるクラスタでは、バックグラウンドキュー処理を、メインノードの BackgroundMethodServer インスタンス専用にすることをお勧めします。詳細については、以下のセクションを参照してください。
追加の MethodServer インスタンスの設定については、高度な Windchill 設定のセクション「複数のメソッドサーバーの Windchill プロパティの設定」を参照してください。
バックグラウンドメソッドサーバーの設定については、バックグラウンドメソッドサーバーの設定のセクション「バックグラウンドメソッドサーバーの設定」を参照してください。