ハードウェアのキャパシティ プランニング

Host Integration Server、SNA Gateway の容量計画では、いくつかの要因を考慮する必要があります。 これらは 4 つの領域に分けることができます。セッションの合計数、サーバーの負荷、フォールト トレランス、デプロイ モデル。

セッションの合計数

一般に、IBM ホストに対する独立セッションと従属セッションはハードコーディングする必要があります。 依存セッション (3270 ディスプレイ、プリンター、または LUA) では、定義された各 LU では 1 つのセッションしかサポートできないので、これは特に当てはまります。 さらに、ほとんどのお客様は依然として多数の依存セッションを必要とします。 各サーバーで明示的に構成する必要があるため、容量計画を行うときに、セッションの合計数を考慮する必要があります。

各ホスト統合サーバーは、最大 60,000 個の依存セッションをサポートできます。 1 台のサーバーでこの数をサポートできますが、通常、セッションは複数のサーバーに分割され、フォールト トレランスが提供されます。 ほとんどのお客様は、サーバーあたり最大 7,000 から 10,000 のディスプレイ または LUA セッションと 2000 プリンター セッションをサポートします。

もう 1 つの要因は、サーバーに接続している一意のユーザーの数です。 各サーバーは、8,000 人の一意のユーザーをサポートできます。 通常、お客様はデスクトップごとに複数のセッションを実行します。 顧客シナリオが 1 対 1 の場合、サーバーあたりのセッションの合計数は 8,000 を下回る必要があります。

別の方法として、LU プールを使用します。 これにより、Display セッションと LUA セッションを、"プール" と呼ばれる 1 つの名前でグループ化できます。 ユーザーの観点からは、LU 名の代わりにプール名が使用されます。 サーバーは、プール内の次に使用可能な LU を提供します。 セッションが断続的に使用されるシナリオでは、プールを使用すると、より多くのユーザー グループにサービスを提供するセッションの数を減らすことができます。 たとえば、10,000 人のユーザーがいる可能性がありますが、一度に使用されるセッション数は 5,000 を超えることはありません。 この場合、ピーク負荷に対応するために 5,000 セッションのプールを作成できます。 この戦略は、ユーザーとアプリケーションが特定の LU に関連付けられていない場合に最適です。

プリンター セッションのエミュレーションに使用される依存 LU は、DISPLAY & LUA セッションと同じ制限に従いますが、追加の制約があります。 オペレーティング システムでは、同時に印刷するセッションの数が制限される場合があります。 以前のバージョンの Windows では、Host Integration Server の既定の同時セッション数は 500 です。 さらに、プリンター セッションでは、Windows 印刷システムとの対話により、ディスプレイまたは LUA セッションよりもオーバーヘッドが多くなります。 マルチプロセッサ システムを使用すると、同時印刷のパフォーマンスが向上します。 通常、お客様は、サーバーあたり最大 2000 個の構成済みセッションをサポートします。

次の表に、コンポーネントの制限事項をいくつか示します。

コンポーネント	最大値
HIS Connections	- ホスト PU への 1:1 マッピング - 255 依存 LU - SNA サービスあたり 250 Connections
SNA サービス (ノード)	- 15,000 個の依存 LU - サーバーごとに 4 つ
HIS サーバー	- 60,000 個の依存 LU - 1000 Connections - サブ ドメインあたり 15

サーバーの負荷

セッションの合計数に加えて、サーバーによって実行される作業の量を容量計画に組み込む必要があります。

1 つの要因は、クライアントによって生成される需要です。 データが流れる速度がワークロードに影響します。 ローンフルフィルメント アプリケーションなどの断続的な画面アクセスでは、一定の使用でテラー アプリケーションよりも少ないワークロードが生成されます。 フローするデータの量もワークロードに影響します。 通常、3270 画面ベースのアプリケーションでは少量のデータが生成されます。ファイル転送または印刷ジョブでは、データの完全なパケットが送信されます。

もう 1 つの要因は、サーバーによって提供される他のサービスです。 サーバーが TN3270 サービスを介してセッションを公開している場合は、ワークロードが適度に増加します。 追加のリソース (CPU の追加など) またはセッション全体の削減を考慮する必要があります。 サーバーが SNA Print サービスを介して印刷セッション エミュレーションを提供している場合、ワークロードが大幅に増加する可能性があります。 PDT ファイルを使用するように構成された印刷セッションでは、ワークロードが少し増加します。 GDI 用に構成された印刷セッションでは、ワークロードが大幅に増加します。 通常、お客様は印刷セッションを専用サーバーに分離します。

Host Integration Server サービスに加えて、データベースのホストや Windows 印刷サービスの提供など、サーバーによって実行されるその他のサービスと機能を使用できます。 複数のサーバー アプリケーションを実行するために必要な処理能力を正確に予測することは困難です。 多くの場合、特定のレベルの応答時間またはトランザクションレートを満たすための独自の要件は、お使いの環境に固有のハードウェア要件を示します。

次の表に、ハードウェア要件の一般的なガイドラインを示します。

サーバーごと	ガイドライン
1000 から 5000 ユーザー 15,000 セッション	- 8 GB 以上の RAM を搭載したマルチプロセッサ システム - ギガビット イーサネット接続 - ボトルネックを軽減するための複数の LAN アダプター
200 から 1000 ユーザー 5,000 セッション	- 4 GB 以上の RAM を搭載したデュアル プロセッサ システム - ギガビット イーサネット接続
1 から 200 ユーザー 1,000 セッション	- 2 GB 以上の RAM を搭載した単一プロセッサ システム - ギガビット イーサネット接続

フォールト トレランス

サーバーあたりのセッションの合計数とサーバーの合計数は、フォールト トレランスの要件を考慮する必要があります。 Host Integration Server では、サブドメインと呼ばれるサーバーの論理的なグループ化がサポートされています。 クライアントは特定のサブドメイン用に構成されており、そのサブドメイン内の任意のサーバー上のリソースにアクセスできます。 セッションが分散されるサーバーの数を増やすことで、1 台のサーバーで障害が発生したときに失われる容量を減らすことができます。 たとえば、10,000 個のセッションをサポートする必要がある場合、2 つのサーバー間でセッションを分割すると、1 台のサーバーで障害が発生した場合、容量が 50% 失われます。 これらが 4 台のサーバーに分散されている場合、1 台のサーバーが失われると容量が 25% 減少するだけです。

これらのサーバーは、冗長性を提供するためにオーバーロードできます。 上記の例を使用すると、2 つのサーバーに 7,500 セッションを配置できます。 この場合、1 台のサーバーの損失によって容量が 25% 減少するだけです。 この戦略では、100% の冗長性を提供できます。

デプロイメント モデル

最後に、サーバーがデプロイされる場所も、容量計画に影響します。 サーバーがデータ センターに一元的に配置されている場合、サーバーのコア セットは、すべてのブランチの場所にサービスを提供できます。 サーバーがブランチにデプロイされている場合、通常は、そのブランチのセッションのみをサービスします。 通常、ブランチデプロイでは、より低い容量でより多くの合計サーバーが必要です。中央展開では、より高い容量でより少ないサーバーを使用できます。 CPU ごとのライセンス モデルでは、これら 2 つのデプロイ モデルがオーバー ライセンス コストに影響しない可能性があります (たとえば、4 台の quad-proc サーバーと 16 台のシングルプロセス サーバー)。