共用方式為


硬體容量規劃

主機整合伺服器的容量規劃,SNA 閘道必須考慮幾個因素。 它們可以分成四個區域;會話總數、伺服器負載、容錯和部署模型。

會話總數

一般而言,IBM Host 的獨立和相依會話必須硬式編碼。 使用相依會話 (3270 Display、Printer 或 LUA) 這特別正確,因為每個 LU 定義只能支援一個會話。 此外,大部分的客戶仍然需要大量的相依會話。 執行容量規劃時,必須考慮會話總數,因為它們必須在每部伺服器上明確設定。

每個主機整合伺服器最多可支援 60,000 個相依會話。 雖然一部伺服器可以支援此數目,但會話通常會分成多部伺服器以提供容錯。 大部分的客戶最多支援 7,000-10,000 個顯示或 LUA 會話,以及每部伺服器的 2000 個列印機會話。

另一個因素是連接到伺服器的唯一用戶數目。 每部伺服器都可以支援8,000個唯一的使用者。 一般而言,客戶會針對每個桌面執行多個會話。 如果客戶案例是 1:1 比率,則每部伺服器的會話總數應維持低於 8,000。

替代策略是使用 LU 集區。 這可讓 Display 和 LUA 工作階段群組在一個名稱下,稱為「集區」。 從用戶的觀點來看,會使用集區名稱,而不是 LU 名稱。 伺服器會在集區中提供下一個可用的 LU。 在間歇性地使用會話的情況下,共用可允許較少的會話服務較大的使用者群組。 例如,一次可能有10,000位使用者,但一次使用中的會話永遠不會超過5,000個。 在此情況下,可以使用 5,000 個會話來建立集區,以容納尖峰負載。 當使用者和應用程式未系結至特定 LU 時,此策略最適合使用。

用於模擬列印機會話的相依 RU 遵循與顯示 & LUA 會話相同的限制,但有額外的限制。 操作系統可能會限制同時列印會話的數目。 在舊版 Windows 上,主機整合伺服器預設為 500 個並行會話的限制。 此外,由於與 Windows 列印系統的互動,列印機會話會產生比 Display 或 LUA 會話更多的額外負荷。 使用多處理器系統會增加並行列印效能。 一般而言,每個伺服器最多支援 2000 個設定的工作階段。

下表提供元件的一些限制。

元件 最大值
HIS Connections - 1:1 對應至主機 PU

- 255 個相依的 RU

- 每個 SNA 服務 250 Connections
SNA 服務 (節點) - 15,000 個相依 RU

- 每部伺服器四個
HIS 伺服器 - 60,000 個相依 RU

- 1000 Connections

- 每個子域 15 個

伺服器負載

除了會話總數之外,伺服器所完成的工作量必須納入容量規劃中。

其中一個因素是用戶端所產生的需求。 數據流會影響工作負載的速率。 間歇性螢幕存取,例如貸款履行應用程式,會產生比常用的通知應用程式少的工作負載。 數據流的數量也會影響工作負載。 通常以 3270 螢幕為基礎的應用程式會產生少量的數據,其中作為檔案傳輸或列印作業會傳送完整的數據封包。

另一個因素是伺服器提供的其他服務。 如果伺服器透過 TN3270 服務公開會話,工作負載將會增加中度。 其他資源應該視為 (,例如額外的 CPU) 或減少總會話。 如果伺服器透過 SNA 列印服務提供列印會話模擬,這可大幅增加工作負載。 列印設定為使用 PDT 檔案的工作階段,可建立少量的工作負載。 針對 GDI 設定的列印會話將會建立大量工作負載增加。 一般而言,客戶會將列印會話隔離至專用伺服器。

除了主機整合伺服器服務之外,伺服器還可以執行其他服務和功能,例如裝載資料庫或提供 Windows 列印服務。 很難精確預測執行多個伺服器應用程式所需的處理能力。 在許多情況下,符合特定回應時間或交易速率層級的需求會指出您環境的特定硬體需求。

下表提供硬體需求的一般指導方針。

每部伺服器 指導方針
1000-5000 位使用者

15,000 個會話
- 具有至少 8 GB RAM 的多處理器系統

- Gb 乙太網路連線

- 多個 LAN 適配卡以減少瓶頸
200-1000 位使用者

5,000 個會話
- 至少具有 4 GB RAM 的雙重處理器系統

- Gb 乙太網路連線
1-200 位使用者

1,000 個會話
- 至少具有 2 GB RAM 的單一處理器系統

- Gb 乙太網路連線

容錯

每部伺服器的會話總數和伺服器總數都必須考慮容錯需求。 主機整合伺服器支援稱為子域的伺服器邏輯群組。 客戶端是針對特定子域設定的,而且可以存取該子網域中任何伺服器上的資源。 藉由增加會話分散的伺服器數目,您可以減少一部伺服器失敗時遺失的容量量。 例如,如果您需要支援 10,000 個會話,在兩部伺服器之間分割它們表示如果一部伺服器失敗,就會遺失 50% 的容量。 如果這些會分散到四部伺服器,則一部伺服器的遺失只會減少 25% 的容量。

這些伺服器可以多載以提供備援。 使用上述範例,您可以在兩部伺服器上放置 7,500 個會話。 在此情況下,遺失一部伺服器只會減少 25% 的容量。 透過此策略,您可以提供 100% 的備援。

部署模型

最後,伺服器部署所在的位置也會考慮容量規劃。 如果您的伺服器位於數據中心,則一組核心伺服器可以服務所有分支位置。 如果您的伺服器已部署分支,則通常只會在該分支上服務會話。 一般而言,分支部署需要容量較低的伺服器總數,因為中央部署可以在較高的容量使用較少的伺服器。 透過每個 CPU 授權模型,這兩個部署模型可能會影響授權成本 (例如 4 個四進程伺服器與 16 部單一程式伺服器) 。