このセクションでは、ファイルボルト、データのロードに留意しながら、クラスタ Windchill システムのインストールと設定の詳細について説明します。

クラスタはコンピュータの集合で、個別にアクセスすることも、1 つのマシンとしてアクセスすることもできます。クラスタでは、HTTP リクエストまたは RMI メソッド呼び出しとして定義される 1 つの作業単位を処理し、多くの Windchill サーバーのいずれかに配布できます。

1 台のサーバーに比べて、クラスタは、パフォーマンス、スケーラビリティ、および信頼性において優れています。パフォーマンスが向上する理由は、特定のノードで Windchill サーバープロセスが競合しなくなることにあります。システムは拡張可能で、負荷の増加に伴い、Windchill サーバーを追加できます。このスケーラビリティにより、システムの信頼性も向上します。Windchill サーバーに障害が発生した場合は、リクエストをほかのサーバーに誘導できます。

以下の図は通常のクラスタ設定を示します。この図では、5 台のコンピュータ (A、B、C、D、および E) が連携してパフォーマンス、スケーラビリティ、および信頼性を向上させます。

通常の Windchill クラスタは、以下の 3 つのセグメントから構成されます。

図に示すように、Windchill クラスタは物理ボルトが維持されているサーバーと対話します (E)。ファイルサーバーとの Windchill の対話のセットアップについてはこの一連のトピックでは説明していません。セットアップの詳細については、ファイルサーバーアドミニストレータを参照してください。

負荷分散ルータはクライアントのリクエストを受信して、多数の Windchill サーバーのいずれかに配布します。周囲のネットワークからは、このルータが 1 台の Windchill サーバーのように見えます。ロードバランサーの詳細については、セクション「負荷分散ルータの設定」を参照してください。

クラスタに属する Windchill サーバーは、データベースとキャッシュメカニズムをクラスタのほかのメンバーと共有する点を除き、単純な独立した Windchill サーバーと類似しています。キャッシュには最上位レベルのマスターキャッシュの更新が適用されるので、これらのサーバーノードはキャッシュクライアントとも呼ばれます。これらのノードは DNS 名を共有し、後続のリクエスト用に、個々の Windchill サーバーではなくクラスタにクライアントを誘導します。

永続的ストレージサーバーマシンには、Windchill のキャッシュマスターサーバーとバックグラウンドメソッドサーバーだけでなく、リレーショナルデータベースも含まれます。あらゆる配置で、1 つのデータベースを使用して、データベースがクラスタ化されている場合でも、クラスタ全体の永続的データを保存します。クラスタ化された環境では、個別のサーバーマネージャを展開し、「マスターキャッシュ」として指定する必要があります。すべてのクライアントキャッシュでキャッシュを同期させるのは、このサーバーの責任です。

キャッシュは、クラスタ内の各ノードのサーバーマネージャプロセスにより管理されます。前の図で、永続的ストレージサーバーで動作するサーバーマネージャは、クラスタのマスターキャッシュとしても機能します。追加のプロパティを wt.properties ファイルに設定して、分散したキャッシュメカニズムを適切に設定する必要があります。

キャッシュマスターサーバーマネージャは常に 1 つ存在します。デフォルトでは、ほかのサーバーマネージャとのネゴシエーションを通じて、このマスターが初期選択されます。一般的に、これは起動した最初のクラスタノードのサーバーマネージャです。クラスタがキャッシュマネージャを選択した後、このサーバーマネージャが引き続きキャッシュマスターとなります。ただし、このサーバーマネージャが到達不能となった場合は、別のサーバーマネージャが自動的にマスターになります。キャッシュマスターの切り替え後に、前のマスターが到達可能になると、キャッシュスレーブステータスに戻ります。

負荷分散ルータはクライアントのリクエストを受信して、使用可能な Windchill サーバーに配布します。このルータはファイアウォールとして動作する場合もあり、Windchill クラスタを周囲のネットワークから分離します。周囲のネットワークからは、このルータが 1 台の Windchill サーバーのように見えます。

負荷分散ルータおよび負荷分散ソフトウェアの設定の詳細については、以下の URL にある Product Development System Configuration Notes を参照してください。

エンドユーザーは、通常、負荷分散ルータを介して 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 クラスタサーバー環境にアクセスします。ポートのセキュリティ上の問題や制限により、クラスタ環境で Workgroup Manager と Windchill Visualization を統合する場合、ユーザーは、ロードバランサーに使用する TCP ポートと IP ポートを決める必要があります。

クライアントとサーバー間の通信要件は、可能な通信環境が多数あることで複雑になります。クライアントとサーバー間の通信に使用するポートの要件を簡素化するために、この説明では次のように仮定します。

HTTP または HTTPS によって RMI をトンネル化する場合、ロードバランサーでは HTTP ポートまたは HTTPS ポートのみを開く必要があります。それ以外の場合、開くポートはユーザー環境に応じて、以下のようになります。

PTC Solution Installer (PSI) によるポート設定の詳細については、必要条件チェックリストを参照してください。

PTC では、個々のニーズに応じて、2 つのクラスのクラスタ設定をお勧めしています。最初のクラスのクラスタ設定では、クラスタ内のすべてのノードを同じにします。クラスタ内の各ノードは、ネゴシエーションによりキャッシュマスターになることができます。このタイプのクラスタを、同一ノードクラスタと呼びます。2 番目のクラスのクラスタ設定では、スレーブノードとマスターノードを別に設定します。この場合、専用キャッシュマスターノードと専用フォアグラウンドキャッシュスレーブノードがそれぞれ存在することになります。このタイプのクラスタを、専用マスタークラスタと呼びます。

Windchill のすべてのクラスタノードを同様に設定し、いずれのサーバーも同じリクエストに同じレスポンスで応答できるようにします。リクエストに複数のサーバーが応答する場合でも、クライアントは、1 つのサーバーであるかのようにシステムにアクセスします。

Windchill 環境のクラスタ化を設定するには、以下のセクションを確認し、使用する環境に該当するセクションの手順を実行してください。

設定例では、すべてのクラスタノードが同じように設定されています。適切に設定された 1 つのクラスタノードをほかのノードに同期化し、修正を行うことなく、クラスタ内で実行できます。

設定では、すべての HTTP アクセスが主要 IP ロードバランサーを経由する必要があります。次の「プロパティの例」セクションに、最小の設定プロパティを示します。これらのプロパティの詳細な説明については、セクション「例で使用しているプロパティについて」を参照してください。

すべてのクラスタノードに次のプロパティ (wt.properties ファイルを参照) が必要です。

設定例では、すべてのクラスタノードが同じように設定されています。ただし、クラスタマスターになることができるのは、特定のノードのみです。適切に設定された 1 つのクラスタノードをほかのノードに同期化し、修正を行うことなく、クラスタ内で実行できます。

設定では、すべての HTTP アクセスが主要 IP ロードバランサーを経由する必要があります。次の「プロパティの例」セクションに、最小の設定プロパティを示します。これらのプロパティの詳細な説明については、セクション「例で使用しているプロパティについて」を参照してください。

すべてのクラスタノードに次のプロパティ (wt.properties ファイルを参照) が必要です。

例の図では、ホスト D がマスターキャッシュになることができます。マスターキャッシュになれるホストが複数ある場合、それらのホスト名を wt.cache.master.hostname プロパティの値に追加できます。

次の表に、前の例で使用しているプロパティとその使用方法をまとめます。

Windchill アダプタは、Windchill キャッシュスレーブで実行されているフォアグラウンドメソッドサーバーに対して自動的に設定されます。インストールフェーズでは、1 つの Windchill アダプタが設定されます。Windchill アダプタが起動すると、設定されているポート範囲が Windchill RMI で使用されているポート範囲 (wt.method.minPort および wt.method.maxPortwt.property の値により設定) と比較されます。設定されているポート範囲が Windchill RMI で使用されているポート範囲より小さい場合、同じサイズになるように自動的に拡大されます。

Windchill アダプタの設定の詳細については、Windchill アダプタのセクションを参照してください。

各クラスタノードで使用できる MethodServer および BackgroundMethodServer インスタンスの数に制限はありません。専用マスタークラスタでは、バックグラウンドキュー処理を、マスターノードの BackgroundMethodServer インスタンス専用にすることをお勧めします。詳細については、以下のセクションを参照してください。