本版適用於：
除非在新版本中另外指出， 否則將適用於所有後續版本及修訂版。
您可以透過 IBM 業務代表或當地的 IBM 分公司訂購出版品。
本書（WebSphere(R) Application Server Edge Components 的概念、規劃與安裝）提供 WebSphere Application Server Edge Components 的簡介。 它提供高階的產品概觀、主要元件的詳細功能討論、網路邊緣實務、安裝與起始配置資訊、及示範網路。
WebSphere Application Server Edge Components 的概念、規劃與安裝是針對熟悉作業系統及提供網際網路服務之資深網路和系統管理員而撰寫。以前不必有使用 WebSphere Application Server 或 WebSphere Application Server Edge Components 的經驗。
協助工具特性可協助身體殘障的使用者（如行動不便或視力不佳的使用者）順利使用軟體產品。 以下是 WebSphere Application Server 6.0.1 版中的主要協助工具特性：
本文件使用以下的排版及輸入慣例。
| 慣例 | 意義 |
|---|---|
| 粗體 | 提到圖形式使用者介面 (GUI) 時，粗體字指出功能表、功能表項目、標籤、按鈕、圖示及資料夾。也可用來強調可能會與前後文字混淆的指令名稱。 |
| 等寬字體 | 指出您必須在命令提示字元之下輸入的文字。等寬字體也表示螢幕文字、程式碼範例及檔案摘錄。 |
| 斜體字 | 指出您必須提供的變數值（例如，您提供 fileName 的檔名）。斜體字也表示強調及書名。 |
| Ctrl-x | 其中 x 是按鍵的名稱，指出控制字元順序。例如，Ctrl-c 表示按住 Ctrl 鍵，同時按 c 鍵。 |
| Return | 指出標示為 Return、Enter 或左箭號的按鍵。 |
| % | 代表不需要 root 專用權之指令的 Linux 和 UNIX(R) command-shell 提示字元。 |
| # | 代表需要 root 專用權之指令的 Linux 和 UNIX command-shell 提示字元。 |
| C:\ | 表示 Windows 命令提示。 |
| 輸入指令 | 當指示您「輸入」或「發出」指令時，請輸入指令，然後按 Return。 比方說，「輸入 ls 指令」指示表示在命令提示字元之下輸入 ls，然後按 Return。 |
| [ ] | 在語法說明中含括選用性的項目。 |
| { } | 在語法說明中含括必須從中選擇一個項目的清單。 |
| | | 在語法說明中，以 { }（大括弧）括住選項清單中的個別項目。 |
| ... | 語法說明中的省略符號，表示前一個項目可重複一或多次。範例中的省略符號， 則表示為力求簡潔而省略範例資訊。 |
這部分介紹 WebSphere Application Server Edge Components、Caching Proxy 及 Load Balancer，並討論它們與應用程式伺服器的整合。同時還會定義 Caching Proxy 和 Load Balancer 元件。 另外，這一節還要介紹其他相關的 WebSphere 系列產品。
這部分包含下列各章：
WebSphere 是網際網路基礎結構軟體，可協助公司開發、部署及整合新一代電子商務應用程式，例如企業對企業電子商務。WebSphere 中介程式支援從簡單的 Web 發佈到全企業異動處理之商業應用程式。
WebSphere Application Server 是 WebSphere 平台的基礎，提供齊全的中介程式集，能讓使用者設計、實施、部署及管理商業應用程式。這些應用程式的範圍從簡單的網站店面，到組織計算基礎結構的完整修訂。
處理器密集的特性（例如個人化）為每一項電子商務提供競爭優勢。但是，習慣性地將這些特性放在中央伺服器上，將使寶貴的功能無法擴大至網際網路部分。因此，隨著新 Web 應用程式一直增加，企業的網際網路基礎結構範圍和影響都將擴大。此外，可靠性和安全性對電子商務也格外重要。即使最小的服務中斷，也會造成業務損失。
Edge Components（以前的 Edge Server）現在是 WebSphere Application Server 產品的一部分。Edge Components 可配合 WebSphere Application Server 一起使用，用來控制用戶端對 Web 伺服器的存取，並可讓企業為透過網際網路或公司內部網路來存取 Web 型內容的使用者提供更好的服務。使用 Edge Components 可以減少 Web 伺服器擁塞、增加內容可用性，以及改進 Web 伺服器效能。如同名稱所指出，Edge Components 通常是在靠近（以網路配置的概念來說）企業內部網路與網際網路之間的界限處之機器上執行。
WebSphere Application Server 包含 Caching Proxy 與 Load Balancer Edge 元件。
Caching Proxy 提供一或多部後端內容伺服器的單一窗口節點，以減少頻寬使用，並改進網站的速度與可靠性。Caching Proxy 可以快取及提供靜態內容和 WebSphere Application Server 動態產生的內容。
Proxy 伺服器會截取來自用戶端的資料要求，從裝載內容的機器擷取要求的資訊，再將該內容傳回用戶端。最常見的情況是，要求儲存在 Web 伺服器機器（也稱為來源伺服器或內容主機）上的文件，並使用超文件轉送通訊協定 (HTTP) 來傳遞。但是，您可以配置 Proxy 伺服器來處理其他通訊協定，例如檔案傳輸協定 (FTP) 和 Gopher。
Proxy 伺服器在將可快取的內容傳送給要求者之前，先將它儲存在區域快取記憶體中。可快取內容的範例包括靜態 Web 頁面，以及包含動態產生（但很少變更）之資訊的 JavaServer 分頁檔。 快取可直接從區域快取記憶體來遞送內容，讓 Proxy 伺服器 能夠滿足後續需要相同內容的要求，這樣會比再次從內容主機擷取內容來得快速。
Caching Proxy 的外掛程式可增加 Proxy 伺服器的功能。
您可以撰寫應用程式設計介面 (API) 的自訂外掛程式模組，更加延伸 Caching Proxy 的功能。API 具有彈性、使用容易，而且不依賴平台。Proxy 會為其處理的每一個用戶端要求執行一連串的步驟。外掛程式應用程式會修改或取代要求處理工作流程中的步驟，例如用戶端鑑別或要求過濾。例如，強大的「變換」(Transmogrigy) 介面就提供 HTTP 資料的存取，而且可以替代或變換 URL 與 Web 內容。外掛程式可以修改或取代指定的處理步驟，而且您可為特定的步驟呼叫多個外掛程式。
Load Balancer 會建立網路邊緣系統，導引網路資料傳輸流量、減少擁塞，以及平衡其他各種服務與系統的負載。Load Balancer 提供站台選項、工作量管理、階段作業親緣性及透通式錯誤替代。
Load Balancer 安裝在網際網路與企業後端伺服器（可以是內容主機或 Caching Proxy 機器）之間。即使企業由於大量內容的高度需求而使用多部後端伺服器，Load Balancer 仍然作為企業在網際網路上的單一窗口。 您也可以安裝備份 Load Balancer，如果主要負載平衡器暫時失效時就可以用它來接管，以保證高可用性。
Load Balancer 截取來自用戶端的資料要求，並將每一個要求轉送至目前最能夠滿足要求的伺服器。換言之，它在一組已定義為服務相同類型的要求之機器間平衡進入的要求負載。Load Balancer 可將要求分散至許多不同類型的伺服器，包括 WebSphere Application Server 和 Caching Proxy 機器。可以使用自行設定警告器，為特定的應用程式或平台自行設定平衡負載。特殊用途警告器可以取得平衡 WebSphere Application Server 負載的資訊。
如果「內容型遞送」元件與 Caching Proxy 一起安裝，還可以根據 URL 或其他管理員決定之性質來分送 HTTP 和 HTTPS 要求，不必在所有後端伺服器上儲存相同的內容。配送器元件也可以為 HTTP 要求提供相同的功能。
平衡負載會透通叢集內容伺服器，包括 HTTP 伺服器、應用程式伺服器及 Proxy 伺服器（代理內容伺服器），改進您網站的可用性和延展性。利用平行、平衡負載及錯誤替代支援來達到可用性。伺服器當機時，業務不會中斷。由於可以透通增加後端處理的能力，因此基礎結構延展性會明顯地改進。
Load Balancer 包含下列元件：
針對所有網際網路服務（例如 HTTP、FTP、HTTPS 及 Telnet），配送器元件會執行區域網路 (LAN) 或廣域網路 (WAN) 中之伺服器的平衡負載。針對 HTTP 服務，配送器可根據用戶端要求的 URL 內容，執行伺服器的平衡負載。
配送器元件可以穩定、有效地管理大型可縮放的伺服器網路。使用配送器，可以將許多個別伺服器鏈結到單一虛擬伺服器。因此，您的站台在外界看來就只有單一的 IP 位址。
針對 HTTP 及 HTTPS 服務，「內容型遞送」元件根據用戶端要求的內容， 執行伺服器的平衡負載。「內容型遞送」元件配合應用程式伺服器 Caching Proxy 元件使用。
網站選取器元件可讓平衡負載的系統當成網路的單一窗口節點，以及對映 DNS 名稱至 IP 位址以平衡負載送入的要求，以加強該系統。與度量伺服器一起使用，網站選取器可以監視伺服器上的活動層次、偵測伺服器負載最輕的時間，以及偵測失敗的伺服器。
Cisco CSS 控制器元件會產生伺服器加權測量單位，該測量單位會被傳送至 Cisco CSS 交換器，以進行伺服器選擇、負載最佳化及容錯。
Nortel Alteon 控制器元件會產生伺服器加權測量單位，測量單位會被傳送至 Nortel Alteon 交換器，以進行伺服器選擇、負載最佳化及容錯。
度量伺服器元件以平衡負載伺服器上之常駐程式形態執行，並為 Load Balancer 元件提供系統負載的相關資訊。
IBM WebSphere 系列的設計，是要協助使用者實現電子商務的希望。它是一組軟體產品，協助使用者開發及管理高效能網站，以及整合網站與新的或現有的非 Web 業務資訊系統。
WebSphere 系列由 WebSphere Application Server（包括 Edge Components）和其他 WebSphere 系列軟體所組成，這些軟體與 WebSphere Application Server 緊密整合，可加強其效能。如果需要 WebSphere Application Server 與其元件之概觀，請參閱 WebSphere Application Server Edge Components 簡介。
Tivoli Access Manager（早期稱為 Tivoli Policy Director）可分開使用。它可針對現有的 Web 應用程式提供存取控制和集中式的安全防護，並提供存取多重 Web 資源的一次鑑別功能。Caching Proxy 外掛程式利用了存取管理程式的安全組織架構，使得 Proxy 伺服器能夠使用存取管理程式的整合性權限或鑑別服務。
WebSphere Portal Server（另購）提供與入口網站相關聯之呈現、安全性、延展性及延展性等問題相符的組織架構。使用 Portal Server，各公司可以建置自行設定的入口網站，以滿足員工、事業夥伴及客戶的需求。 使用者可以登入入口網站，接收提供其所需之資訊、人員及應用程式之存取權限的個人化 Web 頁面。存取所要必要資源的個人化單一點能夠減少資訊超載、提高生產力及增加網站使用率。
WebSphere Portal Server 在 WebSphere Application Server 叢集中執行，以達到延展性和可靠性。應用程式伺服器 Load Balancer 元件也可用於提供額外的平衡負載和高可用性。
WebSphere Site Analyzer（另購）可協助企業預測容量和效能的問題。Site Analyzer、Caching Proxy 與 Load Balancer 日誌及其他可管理性輔助工具，可藉由監督、分析及報告您網站的使用情形，來預測對其他資源的需求。此外，Site Analyzer 可管理性元件可協助使用者進行安裝及升級 Edge Components、管理及儲存配置、遠端操作 Edge Components 以及檢視和報告事件。
WebSphere Transcoding Publisher（另購）可以轉換 Web 頁面，以便在機動裝置上（例如有網際網路功能的電話）檢視、將 Web 內容轉換為使用者偏好的國家語言（方法是呼叫 WebSphere Translation Server）以及轉換標註語言。Transcoding Publisher 加強 Caching Proxy 的功能，可讓它提供內容給不同的裝置和使用者。從 Web 伺服器存取內容後，可以配置 Caching Proxy 的「變換」(Transmogrigy) 介面以呼叫 Transcoding Publisher，進行轉換資料並加上標籤，以供變式快取和可能的重新使用。然後 Transcoding Publisher 會在 Caching Proxy 的後鑑別介面中，檢查 Proxy 伺服器，以查看是否有符合使用者和裝置需求的內容，如果發現內容符合，就從 Proxy 伺服器的快取提供內容。
您可以在 Edge Components 資訊中心取得 WebSphere Application Server Edge Components 專用的下列說明文件。
其他的 WebSphere Application Server 說明文件可從 WebSphere Application Server 程式庫網頁取得。
您可以從 WebSphere Application Server 支援頁面中，取得 Edge Components 的 Technote 支援資訊。
您可以從以下的網站清單中取得有關 Edge Components 及相關的資訊。
這部分詳細討論有關 Edge Components 部分可用的功能。如果需要應用程式伺服器之 Caching Proxy 元件的概觀，請參閱 WebSphere Application Server Edge Components 簡介。
這部分包含下列各章：
Caching Proxy 的快取功能可協助減少網路頻寬的使用率，並確保一般使用者得到更快、更可靠的服務。因為 Proxy 伺服器執行的快取會卸載後端伺服器和同層級鏈結，所以才能做到。Caching Proxy 可以快取靜態內容和 WebSphere Application Server 動態產生的內容。為了提供強化的快取，Caching Proxy 也會配合應用程式伺服器 Load Balancer 元件使用。如果需要這些系統的簡介，請參閱WebSphere Application Server Edge Components 簡介。
Caching Proxy 機器位於網際網路和企業內容主機之間。Proxy 伺服器作為代理者，會截取來自網際網路的使用者要求、將其轉送至適當的內容主機、快取傳回的資料、以及透過網際網路遞送該資料給使用者。快取可直接從快取記憶體中取得內容，讓 Caching Proxy 滿足要求相同內容的後續要求，這樣遠比再從內容主機中擷取來得快。資訊可以根據其到期時間、快取應有多大，以及何時應更新資訊來快取。快取命中的下載時間愈快，表示提供給客戶的服務品質愈好。『圖 1.』說明這項基本 Caching Proxy 功能。
圖註：1--用戶端 2--網際網路 3--路由器/閘道 4--Caching Proxy 5--快取記憶體 6--內容主機在這項配置中，Proxy 伺服器 (4) 會截取 URL 包含內容主機之主機名稱 (6) 的要求。當用戶端 (1) 要求 X 檔時，這個要求會經過網際網路 (2)，再透過企業的網際網路閘道 (3) 進入企業的內部網路。Proxy 伺服器會截取要求，產生以自己的 IP 位址作為原始位址的新要求，並將新要求傳送至內容主機 (6)。
內容主機會將檔案 X 傳回至 Proxy 伺服器，而非直接傳回給一般使用者。如果檔案可以快取，Caching Proxy 會先在其快取 (5) 中儲存一份複本，再將它傳遞給一般使用者。 可快取內容的最明顯範例是靜態 Web 頁面；不過，Caching Proxy 也提供快取及服務 WebSphere Application Server 動態產生之內容的能力。
如果要提供更進階的快取功能，請使用 Caching Proxy 並配合應用程式伺服器的 Load Balancer 元件使用。將快取與平衡負載功能整合，您就可以建立有效率、高度可管理 Web 效能的基礎結構。
『圖 2.』說明您可以如何合併 Caching Proxy 和 Load Balancer，即使在高需求的情況下也能有效地遞送 Web 內容。在這項配置中，Proxy 伺服器 (4) 配置為截取要求，該要求的 URL 包含了由 Load Balancer (6) 來平衡負載的內容主機 (7) 之叢集主機名稱。
圖註：1--用戶端 2--網際網路 3--路由器/閘道 4--Caching Proxy 5--快取記憶體 6--Load Balancer 7--內容主機當用戶端 (1) 要求 X 檔時，這個要求會經過網際網路 (2)，再透過企業的網際網路閘道 (3) 進入企業的內部網路。Proxy 伺服器會截取要求，以它自己的 IP 位址作為原始位址來產生新要求，然後將新要求傳送給位在叢集位址的 Load Balancer。Load Balancer 利用其平衡負載演算法來決定目前最能滿足對於 X 檔的要求之內容主機。這個內容主機會將 X 檔傳回給 Proxy 伺服器，而不是透過 Load Balancer。Proxy 伺服器決定是否快取它，並依照前述的相同方法傳遞給一般使用者。
Caching Proxy 的動態快取外掛程式也提供進階快取功能。配合 WebSphere Application Server 使用時，Caching Proxy 能快取、服務由 WebSphere Application Server 產生的 JavaServer Page (JSP) 和 Servlet 回應形式之動態內容，並使其失效。
一般來說，具有無限有效時間之動態內容必須標示為「勿快取」，因為標準時間型快取到期邏輯不能保證會及時除去這種內容。動態快取外掛程式的事件導向到期邏輯，可讓具有無限有效時間之內容由 Proxy 伺服器快取。在網路邊緣快取這類內容，可使內容主機不必重複呼叫「應用程式伺服器」來滿足來自用戶端的要求。這可以提供下列優點：
Servlet 回應快取很適合根據應用程式邏輯或事件（例如，來自資料庫的訊息）到期的動態產生之 Web 頁面。 雖然這種頁面的使用期限有限，不過由於無法事先知道到期觸發函式，因此不能在建立時設定 TTL（存活時間）值。這類頁面的 TTL（存活時間）設定為零時，內容主機在提供動態內容時會引起很不好的結果。
同步 Caching Proxy 和應用程式伺服器之動態快取的責任由兩個系統共同分擔。例如，由應用程式動態地建立以提供最新氣象預報的公用 Web 頁面，可由應用程式伺服器匯出，由 Caching Proxy 快取。然後 Caching Proxy 可以將應用程式的執行結果，重複提供給許多不同的使用者，直到收到頁面已經無效的通知為止。Caching Proxy Servlet 回應快取中的內容會一直保持有效，直到 Proxy 伺服器因為快取擁塞而移除項目、Caching Proxy 配置檔中之 ExternalCacheManager 指引設定的預設逾時到期，或 Caching Proxy 收到失效訊息，指示它清除快取中的內容為止。失效訊息是在擁有內容的 WebSphere Application Server 中產生，會傳達至每一個配置的 Caching Proxy。
Caching Proxy 提供其他主要的進階快取特性：
Caching Proxy 功能的使用會影響網路的效能。 您可以單獨使用 Caching Proxy 或搭配 Load Balancer 使用，來改進網路的效能。如果需要這些系統的簡介，請參閱WebSphere Application Server Edge Components 簡介。
您企業內的 Caching Proxy 效能取決於執行的硬體，以及套用這項功能之系統的整體架構。如果要最佳化網路效能，請依照 Proxy 伺服器性質來設定硬體和整體架構。
Caching Proxy 軟體的配置與管理以及作業系統層次的調整，也對 Caching Proxy 效能有很大的幫助。 許多軟體配置都可以變更，以產生加強的效能；包括且不限於調整日誌指引、對映規則、外掛程式、逾時值、快取配置值及作用中執行緒值。有關配置 Caching Proxy 軟體的詳細資訊，請參閱 Caching Proxy 管理手冊。
許多作業系統配置也可以變更，以產生加強的效能；包括且不限於調整 TCP 與 ARP、提高檔案描述子限制、同步系統計時器、調整網路介面卡 (NIC)，以及在執行系統管理作業時遵循良好的使用習慣。
本節討論在您的網路套用 Caching Proxy 功能時，應考慮的網路硬體問題。
Proxy 伺服器必須有大量專用的記憶體。Caching Proxy 在配置大型純記憶體快取時，可使用 2 GB 的虛擬位址空間。核心程式、共用程式庫及網路緩衝區也需要使用記憶體。因此，Proxy 伺服器可能會用到 3 至 4 GB 的實體記憶體。請注意，純記憶體快取的速度遠快於原始磁碟快取，單獨變更這項配置可視為效能的增進。
安裝 Caching Proxy 的機器上一定要有大量的磁碟空間。尤其在使用磁碟快取時更是這樣。 讀取和寫入硬碟是電腦上很密集的程序。 雖然 Caching Proxy 的 I/O 程序很有效率，不過在配置 Caching Proxy 以使用磁碟快取時，硬碟機的機械限制會限制效能。有些措施可以減輕磁碟 I/O 瓶頸，例如使用原始快取裝置和日誌檔之多部硬碟機，以及使用探查時間、轉速及傳送速率較快的硬碟機。
NIC 的速度、類型及數目，以及連接至 Proxy 伺服器的網路連線速度等網路需求，都會影響 Caching Proxy 的效能。 通常為了增進效能，最好在 Proxy 伺服器機器上使用兩個 NIC：一個處理送入的資料傳輸、一個處理送出的資料傳輸。如果使用單一 NIC，光是 HTTP 要求和回應資料傳輸就可能達到其最大限制。此外，NIC 至少要有 100 MB，而且一定要配置為全雙工操作。這是因為路由器與交換機之間的自動協議，很可能造成錯誤與妨礙產量。最後，網路連接的速度也很重要。例如，連接到 Caching Proxy 機器的連線如果是已飽和的 T1 載波，就不能期望服務大量的要求負載及達到最佳產量。
Caching Proxy 機器的中央處理裝置 (CPU) 也可能變更限制因子。CPU 功率會影響它處理要求所花費的時間，而網路中的 CPU 數量會影響延展性。Proxy 伺服器之 CPU 需求一定要符合環境，尤其在設定 Proxy 伺服器將要服務之尖峰要求負載時更為重要。
就整體效能而言，擴充整個架構通常較有幫助，而不是只新增個別硬體。不論您在單一機器新增多少硬體，硬體還是有最大的效能層次。
本節討論在您的網路中套用 Caching Proxy 功能時，應考慮的網路架構問題。
如果您企業的網站很受歡迎，對內容的需求可能遠大於單一 Proxy 伺服器能夠有效滿足的需求，則會造成回應時間很慢。如果要最佳化網路效能，可考慮包含叢集的平衡負載 Caching Proxy 機器，或在您的整體網路架構中使用「遠端快取存取」(Remote Cache Access, RCA) 的共用快取架構。
擴充架構的方式之一是將 Proxy 伺服器形成叢集，並使用 Load Balancer 元件平衡其中的負載。叢集 Proxy 伺服器是很有幫助的設計考量，不只因為效能和延展性的原因，也因為備用和可靠性的原因。單一 Proxy 伺服器代表單一的失敗點；如果因為網路發生問題而失敗或變成無法存取，使用者就無法存取您的網站。
也可考慮具有 RCA 的共用快取架構。共用快取架構會分散多台 Caching Proxy 伺服器之間的虛擬快取總量，這些伺服器通常使用快取間的通訊協定，例如「網際網路快取通訊協定」(Internet Cache Protocol, ICP) 或「快取陣列路由通訊協定」(Cache Array Routing Protocol, CARP)。RCA 的設計是提供大量的虛擬快取，使叢集快取命中率最高。
使用 Proxy 伺服器的 RCA 陣列所產生的效能利益優於單一獨立式 Caching Proxy，甚至優於獨立式 Caching Proxy 機器的叢集。其中最明顯的效能利益來自虛擬快取總大小增加，這能提高快取命中率並減少快取不一致和潛伏期。使用 RCA 時，快取中只會放置一份特定文件的複本。使用 Proxy 伺服器叢集時，快取總大小會增加，但是多部 Proxy 伺服器很可能會提取及快取相同的資訊。因此快取總命中率並未增加。
RCA 通常用於大型企業內容裝載的實務。但是，RCA 的用處不只限於極大型的企業部署。如果您網路的負載需要快取伺服器叢集，而且主要的要求都是快取命中，可考慮使用 RCA。 根據您的網路設定，RCA 不一定都能改進企業效能，因為配置 RAC 後，用戶端使用的 TCP 連線數目會增加。 這是因為 RCA 成員不只負責服務具有最高分的 URL，如果收到不是具有最高分的 URL 之要求時，還要將要求轉送給其他成員或叢集。這表示 RCA 陣列的任一指定成員，其開啟的 TCP 連線會比當成獨立式伺服器操作時還多。
Caching Proxy 的快取功能是效能改進的最大功臣。 但是，如果未正確地配置 Proxy 伺服器的快取，也可能變成瓶頸。如果要判斷最佳的快取配置，必須仔細分析資料傳輸性質。內容的類型、大小、數量及屬性，都會影響 Proxy 伺服器從來源伺服器擷取文件所花費的時間，以及伺服器上之負載等效能。在您瞭解 Caching Proxy 要從其快取 Proxy 或提供之資料傳輸類型後，就可以在配置 Proxy 伺服器時將這些性質納入考慮。比方說，如果是知道快取的物件中有 80% 是影像（*.gif 或 *.jpg），大小約為 200 KB，便能幫助您調整快取參數，並決定快取的大小。此外，瞭解大多數的內容都是不必快取的個人化動態頁面，也有助於調整 Caching Proxy。
分析資料傳輸性質可讓您判斷是使用記憶體或磁碟快取才能將您的快取效能最佳化。另外，熟悉網路資料傳輸性質也可讓您判斷使用 Caching Proxy 的動態快取特性是否能改進效能。
磁碟快取適合要快取大量資訊的站台。例如，站台內容如果很大（大於 5 GB），而且有 80% 至 90% 的快取命中率，則建議您使用磁碟快取。但是，使用記憶體 (RAM) 快取的速度比較快是眾所皆知的，而且在許多實務中，使用純記憶體快取較適合大型站台。比方說，如果 Caching Proxy 的快取命中率不是那麼重要，或者已使用共用快取配置，則記憶體快取就很實用。
Caching Proxy 可以快取由 WebSphere Application Server 動態快取（它提供應用程式伺服器的虛擬擴充快取至網路型的快取中）所產生的動態內容（JSP 與 Servlet 結果），並使其失效。有些動態產生之公用 Web 頁面會根據應用程式邏輯或事件（例如來自資料庫的訊息）而到期，如果環境中有許多對這類頁面的要求，則快取動態產生的內容，對網路效能很有幫助。頁面的使用期限有限，但是在建立時不能設定到期觸發函式；因此，沒有動態快取和失效特性的主機必須對這類頁面指定 TTL（存活時間）值為零。
如果這類動態產生的頁面在其使用期限內，會被一或多位使用者要求一次以上，則動態快取可提供很有用的卸載，減少您網路之內容主機上的工作負荷。 使用動態快取也可消除網路延遲、減少因為較少網際網路遍訪造成的頻寬使用，為使用者提供更快的回應，進而改進網路效能。
應用程式伺服器 Load Balancer 元件配合內容主機（例如 WebSphere Application Server）或應用程式伺服器 Caching Proxy 元件一起運作，可讓您加強網路的可用性及延展性。（如果需要這些 Edge Components 的簡介，請參閱WebSphere Application Server Edge Components 簡介）。Load Balancer 是供企業網路使用，安裝在網際網路與企業的後端伺服器之間。即使企業由於高需求量或大量內容而使用多部後端伺服器，Load Balancer 仍然作為企業在網際網路上的單一窗口。
可用性是透過平衡負載和錯誤替代支援來達成。
平衡負載會清楚地將 Proxy 伺服器和應用程式伺服器連接成叢集，以改進您網站的可用性及延展性。由於可以明確地新增後端處理能力，因此 IT 基礎結構的延展性會明顯改進。
您可以複製多台主機上的內容來符合高需求量， 但您需要一個平衡主機之間負載的方法。「網域名稱服務」(DNS) 可以提供基本的環繞式平衡負載，但會有一些它無法充分執行的情況。
較精密的平衡負載多台內容主機之解決方案之一，是依照『圖 3.』中的說明，使用 Load Balancer 的配送器元件。 在這項配置中，所有的內容主機（標示成 5 的機器）皆儲存相同的內容。 這些元件定義為形成平衡負載的叢集，而且為 Load Balancer 機器 (4) 的網路介面之一指定叢集專用的主機名稱和 IP 位址。在標示為 1 的其中一台機器上工作的使用者要求檔案 X 時，要求會越過網際網路 (2)，透過企業的網際網路閘道 (3)，進入企業的內部網路。配送器會截取要求，因為其 URL 對映至配送器的主機名稱和 IP 位址。配送器會決定目前叢集中最能夠服務要求的內容主機，並轉送要求給該主機，如果配置了 MAC 轉送方法，主機會直接將檔案 X 傳回給用戶端（亦即檔案 X 不會經過 Load Balancer）。
依預設，配送器使用像是 DNS 的環繞式平衡負載， 但即使如此，它也可以解決許多 DNS 不適當的問題。不同於 DNS 的是， 它追蹤內容主機是無法使用或無法存取，並且不繼續指引用戶端至無法使用的內容主機。 此外，它藉由追蹤新的、現行的完成的連線，考量內容主機上目前的負載。您可以啟動 Load Balancer 的選用性警告器和管理程式元件，進一步將平衡負載最佳化，它們會更準確地追蹤內容主機的狀態，並將其餘資訊納入平衡負載決策程序中。管理程式可讓您為決策程序中使用之不同因子指定不同的加權值，進一步自訂您站台的平衡負載。
Load Balancer 的配送器也可以執行多台 Caching Proxy 機器的平衡負載。如果您企業的網站很受歡迎，對其內容的需求可能大於單一 Proxy 伺服器能夠有效滿足的需求，這樣很可能降低 Proxy 伺服器的效能。
您可以讓多個 Caching Proxy 系統執行單一內容主機的 Proxy 功能（類似於『圖 1.』中說明的配置），但是如果您的站台實在太受歡迎，需要多台 Proxy 伺服器，則您可能也需要多台由 Load Balancer 來平衡負載的內容主機。『圖 4.』說明了這種配置。標示為 4 的配送器會進行有兩台 Proxy 伺服器 (5) 的叢集之平衡負載，標示為 7 的配送器則會進行有三台內容主機 (8) 的叢集之平衡負載。
圖註：1--用戶端 2--網際網路 3--路由器/閘道 4--配送器 5--Proxy 伺服器 6--快取 7--配送器 8--內容主機標示為 4 之配送器的叢集主機名稱是在企業的 Web 內容之 URL 中出現的主機名稱（也就是在網際網路上可見的網站名稱）。標示為 7 之配送器的叢集主機名稱在網際網路上看不見，因此可以是您喜歡的任何值。例如，對 ABC Corporation 而言，標示為 4 之配送器的適當主機名稱是 www.abc.com，而標示為 7 之配送器則可以取名為 http-balancer.abc.com。
假設當其中一部標示成 1 的用戶端機器上的瀏覽器欲存取檔案 X（該檔案儲存在標示成 8 的內容伺服器上）。該 HTTP 要求會經過網際網路 (2)， 然後於閘道 (3) 進入企業內部網路。路由器將要求傳給標示為 4 的配送器，後者再將它傳遞給 Proxy 伺服器 (5)，這是根據平衡負載演算法，目前最適合處理要求的方法。 如果 Proxy 伺服器的快取 (6) 中有檔案 X，它會直接將其傳回給瀏覽器，略過標示為 4 的配送器。
如果 Proxy 伺服器的快取中沒有檔案 X 的複本，它會在標頭原點欄位中建立有它自己主機名稱的新要求，並將要求傳送至標示為 7 的配送器。 Load Balancer 決定哪一個內容主機 (8) 目前最能夠滿足該要求，並將要求指引至那個主機。內容主機會從儲存體擷取檔案 X，並直接將它傳回 Proxy 伺服器，略過標示為 7 的配送器。如果適合，Proxy 伺服器會快取檔案 X，並將它轉送至瀏覽器，略過標示為 4 的配送器。
Load Balancer 作為您企業之內容主機的單一窗口。 這很有幫助，因為您在 DNS 中公布叢集主機名稱和位址（而非每一部內容主機的主機名稱和位址），這對不定期的入侵提供某種程度的保護，並提供一致的企業網站外觀。如果要進一步加強網站可用性，可以配置另一個 Load Balancer 當成主要 Load Balancer 的備份，如『圖 5.』中的說明。如果因為網路發生問題而造成某一個 Load Balancer 失敗或無法存取，一般使用者仍然可以存取內容主機。
圖註：1--用戶端 2--網際網路 3--路由器/閘道 4--主要配送器 5--備份配送器 6--內容主機在正常狀況下，在其中一台標示成 1 機器上執行的瀏覽器， 將其對檔案 X 的要求，指引至對映到主要 Load Balancer (4) 的叢集主機名稱。配送器傳遞要求至內容主機 (6)， 該主機是根據配送器的平衡負載為基準所選取的。內容主機直接將檔案 X 傳送至瀏覽器，越過網際網路 (2)，透過企業閘道 (3) 來遞送，但是會略過 Load Balancer。
只要主要配送器 (5) 可運作， 備份配送器就不會執行平衡負載。主要和備份配送器會定期交換訊息（稱為活動訊號 (heartbeat)），互相追蹤狀態。 如果備份配送器偵測到主要配送器已失敗， 則會截取被指引至主要的叢集主機名稱及 IP 位址的要求，自動接管平衡負載的責任。
也可以配置兩個配送器，以提供共同高可用性。在這個情況下，兩者都會主動執行個別之內容主機叢集的平衡負載，同時相互當成對方的備份。
配送器一般不使用許多處理程序或記憶體資源， 其他應用程式可在 Load Balancer 機器上執行。 如果減少設備成本極為重要，也可以在叢集的其中一部機器上執行備份配送器，其中，備份配送器正在為該叢集平衡負載。『圖 6.』說明這樣的配置，其中備份配送器在叢集的其中一台內容主機 (5) 上執行。
圖註：1--用戶端 2--網際網路 3--路由器/閘道 4--主要配送器 5--備份配送器和內容主機 6--內容主機應用程式伺服器 Load Balancer 元件配合應用程式伺服器 Caching Proxy 元件一起運作，可讓您將要求分散到裝載不同內容的多部後端伺服器。（如果需要這些 Edge Components 的簡介，請參閱WebSphere Application Server Edge Components 簡介）。
如果 Load Balancer 的內容型遞送 (CBR) 元件是和 Caching Proxy 一起安裝，可以根據 URL 或其他管理員決定之性質來分散 HTTP 要求，不必在所有後端伺服器上儲存相同的內容。
如果您的 Web 伺服器必須執行數個不同的功能或提供數種服務類型， 使用 CBR 會特別合適。例如，線上零售商的網站必須顯示其型錄（其中大部分是靜態的）並接受訂購，這表示執行互動式應用程式（例如，通用閘道介面 (CGI) Script），以接受項目號碼和客戶資訊。通常較有效率的方式是使用兩組不同的機器來執行不同的功能， 以及使用 CBR 將不同的資料傳輸類型傳遞給不同的機器。同樣地，企業也可以使用 CBR 對其網站的付費客戶提供比偶然出現的訪客還要好的服務， 方法是將已付費的要求傳遞至功能更強大的 Web 伺服器。
CBR 根據您撰寫的規則來傳遞要求。最常用的類型是內容規則， 這個類型的規則會根據 URL 中的路徑名稱來指引要求。例如，ABC 公司可以撰寫規則， 這個規則會將針對 URL http://www.abc.com/catalog_index.html 的要求指引至某一伺服器叢集， 並且將 http://www.abc.com/orders.html 的要求指引至另一個叢集。 另外有些規則是根據傳送要求的用戶端 IP 位址，或根據其他性質來傳遞要求。 相關的討論，請參閱 WebSphere Application Server Load Balancer 管理手冊中有關配置 CBR 及進階的 Load Balancer 與 CBR 功能之章節。如果要取得規則的語法定義，請參閱 WebSphere Application Server Load Balancer 管理手冊中有關 CBR 規則類型的附錄。
『圖 7.』說明簡式配置，其中 Load Balancer 的 CBR 元件和 Caching Proxy 一起安裝在標示為 4 的機器上，並傳遞要求到裝載不同內容的三部內容主機（6、7 及 8）。 當在其中一部標示成 1 的機器上工作的一般使用者要求檔案 X 時， 該要求會經過網際網路 (2) 然後透過企業的網際網路閘道 (3) 進入企業的內部網路。Proxy 伺服器會截取要求，並將它傳遞至同一部機器上的 CBR 元件，這個元件會解析要求中的 URL，並決定內容主機 6 裝載檔案 X。Proxy 伺服器會為檔案 X 產生新要求，而且如果啟用了其快取特性，還會在主機 6 傳回檔案時，判斷檔案是否適合快取。如果該檔案是可快取的，Proxy 伺服器會在傳遞該檔案至一般使用者之前，儲存一份複本在其快取中 (5)。其他檔案以相同的方式傳遞：如果要取得檔案 Y 的要求會送至內容主機 7，如果要取得檔案 Z 的要求會送至內容主機 8。
圖註：1--用戶端 2--網際網路 3--路由器/閘道 4--Caching Proxy 和 Load Balancer 的 CBR 元件 5--快取記憶體 6、7、8--內容主機『圖 8.』說明較為複雜的配置， 該配置可能適合線上零售商。Load Balancer 的 CBR 元件和 Proxy 伺服器一起安裝在標示為 4 的機器上，並傳遞要求至兩部 Load Balancer 機器。標示為 6 的 Load Balancer 機器會平衡負載裝載著大部分為零售商型錄的靜態內容之內容主機 (8) 叢集，而標示為 7 的 Load Balancer 則會平衡負載處理訂單的 Web 伺服器 (9) 叢集。
當在其中一部標示成 1 的機器上工作的一般使用者存取零售商型錄的 URL 時， 該要求會經過網際網路 (2)，然後透過企業的網際網路閘道 (3) 進入企業的內部網路。Proxy 伺服器會截取要求，並將它傳遞至同一部機器上的 CBR 元件，該 CBR 元件會解析 URL，並決定讓標示為 6 的 Load Balancer 機器處理該 URL。Proxy 伺服器會建立新的存取要求，並將它傳送至 Load Balancer，而 Load Balancer 可根據您所定義的基準來決定標示為 8 的內容主機，目前最能夠服務要求。該內容主機會直接將型錄內容傳遞給 Proxy 伺服器，略過 Load Balancer。如同上述範例，Proxy 伺服器會判斷內容是否能夠快取，如果能夠快取，則會將內容儲存在其快取 (5) 中。
一般使用者會存取零售商的訂購 URL（可能是透過型錄中的超鏈結）來下訂單。要求傳送的路徑與型錄存取要求相同，唯一不同的是機器 4 上的 CBR 元件會將其遞送至標示為 7 的 Load Balancer 機器。Load Balancer 將其轉送至標示為 9 之最適合的 Web 伺服器，由伺服器直接回應至 Proxy 伺服器。 由於訂購資訊一般以動態方式產生，Proxy 伺服器可能不會快取該資訊。
圖註：1--用戶端 2--網際網路 3--路由器/閘道 4--Caching Proxy 和 Load Balancer 的 CBR 元件 5--快取記憶體 6、7--Load Balancer 8--內容主機 9--Web 伺服器Load Balancer 的 CBR 功能支援 Cookie 親緣性。 這表示服務一般使用者首次要求的伺服器之識別，是記錄在內含於伺服器回應的特殊資料封包 (Cookie) 中。當一般使用者於您定義的期間內再次存取相同的 URL， 且該要求包括 Cookie 時，CBR 會將該要求傳遞至來源伺服器， 而非重新套用其標準規則。如果該伺服器已儲存一般使用者的資訊且不用重新取得（如信用卡號碼）， 這通常會改進回應時間。
這部分會討論使用 IBM WebSphere Application Server Edge Components 的商業實務。 這些解決方案具備健全的架構並通過測試，可提供極佳的效能、可用性、延展性及可靠性。
這部分包含下列各章：
基本電子商務網站是一種企業對消費者網路。在網際網路成長的第一階段，企業通常只著重在建立 Web 外觀的呈現。將公司資訊與產品型錄轉換為數位化格式，並在網站上提供。提供 E-MAIL 位址、電話及傳真號碼，甚至自動化表格，就能購物。但是還未提供真正的線上購物。所有交易都有固有的潛伏期，因為需由人力來處理訂單。
在第二階段，企業實行安全購物車以供直接線上購物，因而消除了這個潛伏期，並且將銷售作業系統化。 與倉儲資料庫同步，以及與銀行系統整合，對完成這些銷售交易來說是非常重要的。無法提供的產品就不能銷售，而且也不能就該項目向客戶的帳戶收費。 同樣地，要等到發生有效的財務交易後，才能從庫存取出產品，出貨給客戶。
在第三階段，公司的網站發展成動態呈現的站台，消費者開始有用戶端的觀點，並提供消費者個人化的內容。
『圖 9.』顯示為提供有效型錄瀏覽而設計的小型商務網站。所有用戶端要求都透過防火牆傳遞至配送器，再遞送至具有作用中快取，作為 Web 伺服器代理伺服器的 Proxy 伺服器叢集。測量伺服器與 Proxy 伺服器並存，為配送器提供平衡負載資料。這種排列可減少 Web 伺服器上的網路負載，並且避免其與網際網路直接接觸。
『圖 10.』顯示商務網站演進的第二階段，其設計是要為潛在客戶提供有效的型錄瀏覽，以及快速、安全的購物車。所有客戶要求都由配送器（根據網際網路通訊協定分離要求）遞送至網路的適當分支。HTTP 要求送至靜態網站；HTTPS 要求送至購物網路。主要的靜態網站還是由具有作用中快取的 Proxy 伺服器 叢集服務，這個叢集則當成 Web 伺服器的代理。網路的這一部分反映出第一階段的網路。
網站的電子商務部分也由 Proxy 伺服器 叢集提供服務。但是，Caching Proxy 節點則利用許多外掛程式模組來強化。SSL 訊息交換會卸載至加密硬體卡，而鑑別則透過存取管理程式（早期稱為 Policy Director）外掛程式來執行。 動態快取外掛程式會將常用的資料排序，減少 WebSphere Application Server 上的工作負荷。應用程式伺服器上的外掛程式會在必要時使 Dynacache 中的物件失效。
所有購物車應用程式皆繫結至用來鑑別使用者的客戶資料庫中。 這可以讓使用者免於在系統中輸入兩次個人資訊，其中一次是用於鑑別， 而一次用於購物。
這個網路根據用戶端的用法來切割資料傳輸， 並從主要的網站將佔用大量處理器資源的 SSL 鑑別及電子商務購物車加以移除。這個雙軌網站可讓網路管理者根據伺服器在網路中的角色，來調整各個伺服器，以提供優越的效能。
『圖 11.』顯示企業對消費者網路演進的第三階段，以靜態 Web 採用動態呈現法。Proxy 伺服器叢集已經過強化，可支援動態快取 Web 內容，以及遵循 Edge Side Includes (ESI) 通訊協定之撰寫的頁面片段之組譯。它並不是使用伺服器端併入機制，在內容伺服器上建置網頁，然後將這些用戶端特定的、不可快取的頁面傳達至整個網路；而是採用 ESI 機制，允許在網路邊緣利用快取內容組合頁面，減少頻寬使用量和回應時間。
第三階段的每一個用戶端都會收到來自網站的個人化首頁，因此 ESI 機制在這個階段的情節中非常重要。這些頁面的建置區塊是從一連串的 WebSphere Application Server 擷取。包含機密商業邏輯，且繫結至安全資料庫的應用程式伺服器隔離在防火牆後。
『圖 12.』顯示有效的線上銀行業務解決方案，類似於企業對消費者網路中所說明的企業對消費者網路。所要用戶端要求都透過防火牆傳遞至配送器，配送器根據網際網路通訊協定將資料傳輸分開。HTTP 要求傳遞至有作用中快取的 Proxy 伺服器叢集，這些快取當成 Web 伺服器的代理伺服器。測量伺服器與 Proxy 伺服器並存，為配送器提供平衡負載資料。這種排列減少 Web 伺服器上的網路負載，並在伺服器與網際網路之間建立更多的緩衝區。
HTTPS 要求會傳遞至一個安全網路，這個安全網路的設計，是要提供個人財務資訊給用戶端，並允許線上銀行業務交易。 一個強化的 Proxy 伺服器叢集會提供站台的延展性。這些 Proxy 伺服器支援快取動態 Web 內容，以及遵循 Edge Side Includes (ESI) 通訊協定之撰寫的頁面片段組譯。加密硬體卡會管理 SSL 訊息交換，如此可明顯減少 Proxy 伺服器主機所需的處理程序，而存取管理程式（早期稱為 Policy Director）則會導向用戶端的鑑別作業。
一組應用程式伺服器叢集，會將 EJB 元件中包含之商業邏輯與 Servlet 和 JSP 檔案中包含之呈現層分開，分散要求的處理。每一個這種叢集都由個別的階段作業伺服器管理。
『圖 13.』顯示為支援大量資料傳輸，並提供每一個用戶端個人化內容而設計的 Web 入口網站網路。為了減少各伺服器上的處理負載，網路中沒有任何部分載送 SSL 資料傳輸。由於入口網站不遞送機密資料，因此安全性並不是重要的問題。包含用戶端 ID、密碼及設定的資料庫，一定要保持適度的安全和不損毀狀態，不過這項要求並不會損及網站其餘部分的效能。
所有用戶端要求經過防火牆傳遞至配送器，配送器會平衡有作用中快取之 Proxy 伺服器叢集（作為 Web 伺服器的代理伺服器）的網路負載。測量伺服器與 Proxy 伺服器並存，為配送器提供平衡負載資料。
實際的動態網站是應用程式伺服器的叢集，伺服器會產生 ESI 片段，傳遞至 Proxy 伺服器進行組合。由於擔心會減少安全性，每一個應用程式伺服器會為建構網站執行所有必要的功能。所有應用程式伺服器都相同。 如果有一部應用程式伺服器停止服務，階段作業伺服器可將要求遞送至其他伺服器，提供整個站台的高度可用性。也可在發生過多的資料傳輸時（例如入口網站裝載特殊事件），使用這項配置，以快速地提升網站。可以很快地將其他 Proxy 伺服器與應用程式伺服器配置到站台中。
所有靜態內容（例如影像檔和現成文字）都儲存在個別的 Web 伺服器上，可在必要時更新，不會有毀損較複雜之應用程式伺服器的風險。
這部分會討論 Edge Components 的軟硬體需求，並提供安裝的程序。
這部分包含下列各章：
本主題提供 Edge Components 之軟硬體需求，以及使用 Web 瀏覽器檢視 Caching Proxy 配置與管理表格和 Load Balancer 線上說明的指引。
Java 2 SDK 會隨著 Load Balancer，從產品 CD 安裝在所有平台中。
重要事項：如果需要軟硬體需求的最新資訊， 請鏈結下列網頁：http://www.ibm.com/software/webservers/appserv/doc/latest/prereq.html。
本節說明 WebSphere Application Server 6.0.1 版 Edge Components 的軟硬體需求。
這一節說明在執行 AIX 作業系統的機器上安裝 Caching Proxy 時的軟硬體必備項目。
% lslpp -l file_set
這一節說明在執行 AIX 作業系統的機器上安裝 Load Balancer 元件時的軟硬體必備項目。
本節說明在執行 HP-UX 作業系統的機器上安裝 Caching Proxy 時的軟硬體需求。
您需要最新版的修正套件，也就是 HP-UX 11i Quality Pack (GOLDQPK11i)。您可在下列 HP Support Plus 網站上取得詳細資訊，以及如何取得最新 Quality Pack 的下載指示：http://www.software.hp.com/SUPPORT_PLUS/qpk.html。
本節說明在執行 HP-UX 作業系統的機器上安裝 Load Balancer 元件時的軟硬體需求。
您需要最新版的修正套件，也就是 HP-UX 11i Quality Pack (GOLDQPK11i)。您可在下列 HP Support Plus 網站上取得詳細資訊，以及如何取得最新 Quality Pack 的下載指示：http://www.software.hp.com/SUPPORT_PLUS/qpk.html。
本節會說明在執行 Linux 作業系統之機器上安裝 Caching Proxy 的硬體及軟體必備項目。
下表列出 Linux 支援的系統。如果需要軟硬體需求的更新內容和其他資訊， 請參閱以下網頁：http://www.ibm.com/software/webservers/appserv/doc/latest/prereq.html。
| 作業系統 | Linux for Intel | Linux for S/390 zSeries | Linux(TM) for PowerPC iSeries(TM) 或 pSeries(R) |
|---|---|---|---|
| Red Hat Enterprise Linux AS 3.0 Updates 2、3 或 4 | X | X | X |
| SuSE Linux Enterprise Server 8 SP3 | X | X | X |
| SuSE Linux Enterprise Server 9 | X | X | X |
compat-gcc-7.3-2.96* compat-libstdc++-7.3-2.96* compat-libstdc++-devel-7.3-2.96* compat-glibc-7.x-2.2.4.32* compat-gcc-c++-7.3-2.96* compat-db-4.0.14*下列套件必須安裝在 Red Hat Enterprise Linux v3 for S/390（z/VM 和 VM/ESA）平台中：
compat-db-4.0.14* compat-pwdb-0.62* compat-libstdc++-7.2-2.95*當沒有這些 rpms 時，不會啟動 Caching Proxy，將無法正確執行 IBM Runtime Environment for Linux, Java 2 Technology Edition。
本節會說明在執行 Linux 作業系統之機器上安裝 Load Balancer 元件的硬體及軟體必備項目。
下表列出 Linux 支援的系統。如果需要軟硬體需求的更新內容和其他資訊， 請參閱以下網頁：http://www.ibm.com/software/webservers/appserv/doc/latest/prereq.html。
| 作業系統 | Linux for Intel(TM) x86 （32 位元 JVM） | Linux for Intel Itanium 2 （64 位元 JVM） | Linux for S/390(R) zSeries(R) （31 位元 JVM） | Linux for PowerPC iSeries 或 pSeries （32 位元 JVM） | Linux for PowerPC iSeries 或 pSeries （64 位元 JVM） | Linux for AMD Opteron （64 位元 JVM） |
|---|---|---|---|---|---|---|
| Red Hat Enterprise Linux AS 3.0 Updates 2、3 或 4 | X | X | X | X | X | X |
| SuSE Linux Enterprise Server 8 SP3 | X | X | X | |||
| SuSE Linux Enterprise Server 9 | X | X | X | X | X | X |
本節會說明在執行 Solaris 作業系統之機器上安裝 Caching Proxy 的硬體及軟體必備項目。
如果是 Solaris 8，安裝精靈需要層次為 109147-16（或更高版本）的鏈結器， 以及層次為 108434-8（或更高版本）的 C++ 共用檔案庫。
如果要達到最高的一致性，請從 Sun Microsystems 的 http://sunsolve.sun.com 網站下載並套用最新的 Solaris 修補程式。
本節會說明在執行 Solaris 作業系統之機器上安裝 Load Balancer 元件的硬體及軟體必備項目。
如果是 Solaris 8，安裝精靈需要層次為 109147-16（或更高版本）的鏈結器， 以及層次為 108434-8（或更高版本）的 C++ 共用檔案庫。
如果要達到最高的一致性，請從 Sun Microsystems 的 http://sunsolve.sun.com 網站下載並套用最新的 Solaris 修補程式。
這一節說明在執行 Windows 作業系統的機器上安裝 Caching Proxy 時的軟硬體必備項目。
下表列出支援的 Windows 系統。 如果需要軟硬體需求的更新內容和其他資訊， 請參閱以下網頁：http://www.ibm.com/software/webservers/appserv/doc/latest/prereq.html。
| 作業系統 | Intel x86 |
|---|---|
| Windows 2000 Server SP4 Advanced Server SP4 | X |
| Windows Server 2003 Standard Edition | X |
| Windows Server 2003 Enterprise Edition | X |
| Windows Server 2003 Datacenter Edition | X |
這一節說明在執行 Windows 作業系統的機器上安裝 Load Balancer 元件時的軟硬體必備項目。
下表列出支援的 Windows 系統。 如果需要軟硬體需求的更新內容和其他資訊， 請參閱以下網頁：http://www.ibm.com/software/webservers/appserv/doc/latest/prereq.html。
| 作業系統 | Intel x86 | Intel Itanium 2（64 位元 JVM） |
|---|---|---|
| Windows 2000 Server SP4 Advanced Server SP4 | X | |
| Windows Server 2003 Standard Edition | X | |
| Windows Server 2003 Enterprise Edition | X | X |
| Windows Server 2003 Datacenter Edition | X |
瀏覽器的最小需求
如果要使用「配置與管理」表格來架構 Caching Proxy， 您的瀏覽器必須執行下列的動作：
Linux 和 UNIX 系統：建議的瀏覽器是 Mozilla 1.4 或 Mozilla 1.7。
Windows 系統：建議的瀏覽器是 Microsoft Internet Explorer 5.5 或更新的版本，或 Mozilla 1.4 或 Mozilla 1.7
限制：如果展開的元素數目太大，無法顯示在瀏覽器視窗中，瀏覽器可能不會顯示管理表單左側垂直捲軸。 這會將清單底端的展開元素推出瀏覽器現行檢視視窗之外，無法存取。 如果要解決這個問題，請限制左側功能表中的展開元素數目。 如果展開元素的數目太大，請收合部分元素，直到清單底端的元素會顯示在瀏覽器視窗內為止。
為了能適當地顯示表格，實際顯示表格的作業系統（瀏覽器所在的作業系統）必須含有撰寫表格之語言的適當字型組。 然而，瀏覽器介面不一定要與表格的語言相同。
比方說，中文版的 Proxy 伺服器是在 Solaris 9 系統上執行。Solaris 主機會載入英文介面的 Mozilla 瀏覽器。這個瀏覽器可以用在區域環境中編輯「配置與管理」表格。（表格是供 Proxy 伺服器所使用之字集的瀏覽器所使用 -- 本例中為中文；然而，如果未適當地配置瀏覽器及其基礎作業系統，以顯示 Proxy 伺服器所傳送的字集，則可能會無法正確顯示表格。）
另外，如果具有中文語言支援的 Windows 工作站能夠從遠端連接至 Proxy 伺服器，則可以將中文版的 Netscape 瀏覽器載入 Windows 工作站，並使用這個瀏覽器在表格中輸入值。 第二項解決方案的優點是管理者能維護一致的語言介面。
作業系統特定字型組會嚴重影響瀏覽器中各種語言的顯示，特別是雙位元組字元。 比方說，在 AIX 中特定的中文字型組與在 Windows 平台上的中文字型組看起來不完全一樣。 這會造成「配置與管理」表單中之 HTML 文字及 Java Applet 的外觀有一些不規則。 就最佳外觀而言，只建議您使用在 Windows 作業系統上執行的瀏覽器。
S/390 和 PowerPC 中的 Mozilla 1.4 瀏覽器附註
隨著 Mozilla 1.4 而安裝的 Java 外掛程式必須更新至 1.4.2 版或更新的版本，才能正確顯示管理表單。 請利用下列步驟來更新外掛程式：
如果要使用 Load Balancer 線上說明，您的瀏覽器必須支援下列各項：
使用不支援這些需求的瀏覽器，可能造成頁面格式錯誤和功能無法正確執行。下列瀏覽器支援這些需求：
本主題提供使用安裝程式安裝 Edge Components 的說明。
重要事項：在安裝之後，Caching Proxy 包裝內的 Script 會嘗試使用預設配置來啟動 Proxy 伺服器。如果埠 80 已在使用（例如由其他 Web 伺服器使用），Proxy 伺服器將無法啟動。
Java 2 SDK 會隨著 Load Balancer，從產品 CD 安裝在所有平台中。
使用安裝程式，將 Edge Components 安裝在您的 Windows(R) 系統上，如下所示：
使用安裝程式，將 Edge Components 安裝到您的 Linux 和 UNIX 系統，如下所示：
# ./install這時會開啟「歡迎使用」視窗。
安裝程式會開始安裝選取的 Edge Components 和必要的套裝軟體。
本主題提供使用系統包裝工具安裝 Caching Proxy 的說明。
重要事項：在安裝之後，Caching Proxy 包裝內的 Script 會嘗試使用預設配置來啟動 Proxy 伺服器。如果埠 80 已在使用（例如由其他 Web 伺服器使用），Proxy 伺服器將無法啟動。
使用您作業系統的套裝軟體安裝系統，依照『表 6.』中列出的順序來安裝套裝軟體。 下列程序詳述完成這項作業所需的一般步驟。
su - root
密碼：passwordcd mount_point/package_directory/在 AIX(R) 中：
installp -acXd ./packagename
在 HP-UX 中：
swinstall -s ./packagename
在 Linux 中：
rpm -i ./packagename
在 Solaris 中：
pkgadd -d ./packagename如果要解除安裝套件，請執行下列動作：
在 AIX：
installp -u packagename如果要解除安裝所有 Caching Proxy 套件，請使用下列指令：
installp -u wses
在 HP-UX 中：
swremove packagename如果要解除安裝所有 Caching Proxy 套件，請使用下列指令：
swremove wses
在 Linux 中：
rpm -e packagename如果要查詢已安裝的 Caching Proxy 套件，請使用下列指令：
rpm -qa |grep -i wses
這些套件應該依照安裝的相反次序來移除。
在 Solaris 中：
pkgadd -d ./packagename如果要查詢已安裝的 Caching Proxy 套件，請使用下列指令：
pkginfo | grep wses
這些套件應該依照安裝的相反次序來移除。
本主題說明在 Load Balancer 在 AIX、HP-UX、Linux 和 Solaris 系統中的安裝作業：
『表 9.』列出 Load Balancer 的 AIX 檔案集。
| Load Balancer 元件 | AIX 檔案集 |
|---|---|
| Load Balancer 元件（含訊息） | ibmlb.component.rte ibmlb.msg.lang.lb |
| 裝置驅動程式 | ibmlb.lb.driver |
| 基本程式 | ibmlb.base.rte |
| 管理（含訊息） | ibmlb.admin.rte ibmlb.msg.lang.admin |
| 文件（含訊息） | ibmlb.doc.rte ibmlb.msg.lang.doc |
| 授權 | ibmlb.lb.license |
| 度量伺服器 | ibmlb.ms.rte |
在您安裝 Load Balancer for AIX 之前，請確定下列各項：
installp -u ibmlb或者，要解除安裝先前的版本，請輸入下列指令：
installp -u ibmnd如果要解除安裝特定的檔案集，請具體地列出檔案集，而非指定資料包名稱 ibmlb。
當您安裝本產品時，您可以選擇安裝下列任一項或全部安裝：
建議您使用 SMIT 來安裝 Load Balancer for AIX，因為 SMIT 可確保所有訊息都自動安裝。
mkdir /cdrom mount -v cdrfs -p -r /dev/cd0 /cdrom
| 套裝軟體 | 指令 |
|---|---|
| Load Balancer 元件（含訊息）。包括：配送器、CBR、網站選取器、Cisco CSS 控制器及 Nortel Alteon 控制器 | installp -acXgd device ibmlb.component.rte ibmlb.msg.language.lb |
| 裝置驅動程式 | installp -acXgd device ibmlb.lb.driver |
| 文件（含訊息） | installp -acXgd device ibmlb.doc.rte ibmlb.msg.language.lb |
| 基本程式 | installp -acXgd device ibmlb.base.rte |
| 管理（含訊息） | installp -acXgd device ibmlb.admin.rte ibmlb.msg.language.admin |
| 授權 | installp -acXgd device ibmlb.lb.license |
| 度量伺服器 | installp -acXgd device ibmlb.ms.rte |
installp -ld device
如果要解除裝載 CD，請輸入下列指令：
unmount /cdrom
輸入下列指令，驗證確定產品已經安裝
lslpp -h | grep ibmlb
如果您安裝了完整的產品，這個指令會傳回下列內容：
ibmlb.admin.rte ibmlb.base.rte ibmlb.doc.rte ibmlb.ms.rte ibmlb.msg.language.admin.rte ibmlb.msg.language.doc ibmlb.msg.language.lb.rte ibmlb.lb.driver ibmlb.lb.license ibmlb.component.rte
Load Balancer 的安裝路徑如下：
本節說明如何使用產品 CD，在 HP-UX 中安裝 Load Balancer。
在開始安裝程序之前，請確定您具有可安裝軟體的 Root 權限。
如果您已安裝較舊的版本，則在安裝現行版本之前，必須先解除舊版的安裝。首先，請確定您已停止執行器及伺服器。接著，如果要解除安裝 Load Balancer，請參閱解除安裝套件的指示。
『表 11.』列出了 Load Balancer 的安裝套件名稱， 以及利用系統的套件安裝工具來安裝這些套件所需的次序。
以下程序詳述了完成這項作業必要的步驟。
su - root
密碼：password發出安裝指令
swinstall -s source/package_name
其中 source 是套件位置的目錄，package_name 則是套件的名稱。
比方說，如果您是從 CD 的根目錄進行安裝，則下列指令會安裝 Load Balancer 的基本套件 (ibmlb.base)
swinstall -s /lb ibmlb.base
發出 swlist 指令來列出您已安裝的所有套件。例如：
swlist -l fileset ibmlb
您可以使用 swremove 指令來解除安裝套件。 移除這些套件的次序應該和安裝的次序相反。比方說，發出下列指令：
swremove ibmlb如果要解除安裝個別套件（例如：Cisco CSS 控制器）
swremove ibmlb.cco
Load Balancer 的安裝路徑包括：
本節說明如何使用 Edge Components CD，在 Linux 中安裝 Load Balancer。
安裝 Load Balancer 之前，請確定下列各項：
rpm -e pkgname當解除安裝時，請依照套裝軟體安裝的相反順序執行，確定最後才解除安裝管理套裝軟體。
安裝壓縮檔是 lblinux-version.tar 格式的檔案。
tar -xf lblinux-version.tar結果會產生副檔名為 .rpm 的下列檔案集：
其中 --
rpm -i package.rpm 一定要依照下列每一種元件所需之套裝軟體清單的順序，來安裝套裝軟體。
rpm -i --nodeps package.rpmrpm -qa | grep ibmlb
安裝完整的產品會產生下列輸出：
Load Balancer 安裝路徑包含下列：
如果您需要解除安裝套裝軟體，請依照套裝軟體安裝的相反順序執行，確定最後才解除安裝管理套裝軟體。
本節會說明如何使用 Edge Components CD，在 Solaris 中安裝 Load Balancer。
開始安裝程序之前，請確定您是以 root 身分登入，而且已經解除安裝前一版的產品。
如果要解除安裝，請確定所有的執行器和伺服器都已停止。接著，輸入下列指令：
pkgrm pkgname
pkgadd -d pathname其中的 -d pathname 是光碟機的裝置名稱，或套裝軟體所在之硬碟機的目錄；例如：-d /cdrom/cdrom0/。
將會顯示下列的套裝軟體清單：
其中的變數 lang 會換成下列其中一個特定語言專用代碼： deDE、esES、frFR、itIT、jaJP、koKR、ptBR、zhCN、zhTW。 如果是英文，變數 lang 則會換成 doc。
如果您要安裝所有的套裝軟體，只要輸入 all，然後按 Return 鍵即可。如果要安裝部分元件，請輸入與要安裝之套裝軟體對應的一或多個名稱（使用空格或逗點隔開），然後按 Return。系統會提示您變更現有目錄或檔案上的許可權。只要按 Return 或回應 yes 即可。您必須安裝必要的套裝軟體（因為安裝是按字母順序執行，而非必備項目順序）。如果您輸入 all，對所有提示回應 yes，安裝就會順利完成。
所有套件都相依於共同套件 ibmlbadm。 這個共同套件必須和任何其他套件一起安裝。
比方說，如果您只要安裝配送器元件（含文件）以及度量伺服器，您必須安裝：ibmlbadm、ibmlbbase、ibmlblic、ibmdisp、ibmlbms 和 ibmlbdoc。
pkginfo | grep ibm
Load Balancer 安裝路徑包含下列：
這部分提供使用 Edge Components 建置基本示範網路的程序。這些網路並非要用於生產環境中。初始配置網路的程序，可幫助第一次接觸產品的管理者釐清許多網路邊緣的概念。如果需要所有元件特性的完整涵蓋面和深入的配置資訊，請參閱 Caching Proxy 管理手冊和 Load Balancer 管理手冊。
這個程序允許在任何節點使用之元件所支援的任何電腦系統。
這部分包含下列各章：
『圖 14.』顯示使用位於三個網路節點之三個電腦系統的基本 Proxy 伺服器網路。這個網路連結 Proxy 伺服器至專用的內容主機（IBM HTTP Server，位於伺服器 2），由 Proxy 伺服器為主機提供服務。這是由位於工作站和伺服器 1 之間的網際網路以視覺化的方式來呈現。
如果要建置 Caching Proxy 網路，請依照下列順序執行這些程序：
需要下列電腦系統及軟體元件：
安裝及配置 Caching Proxy，如下所示：
# htadm -adduser /opt/ibm/edge/cp/server_root/protect/webadmin.passwd
當提示時，對管理者提供 htadm 程式使用者名稱、密碼與實際的名稱。
安裝及配置 Caching Proxy，如下所示：
cd "Program Files\IBM\edge\cp\server_root\protect" htadm -adduser webadmin.passwd"
出現提示時，請將管理者的使用者名稱、密碼及實際姓名提供給 htadm 程式。
在工作站上，執行下列步驟：
在工作站上，執行下列步驟：
『圖 15.』顯示使用配送器元件的 MAC 轉送方法，且有三個區域連接工作站的基本 Load Balancer 網路，用以平衡兩部 Web 伺服器之間的 Web 資料傳輸之負載。這項配置類似任何其他 TCP 或無狀態 UDP 應用程式資料傳輸的平衡負載。
如果要建置 Load Balancer 網路，請依照下列順序執行這些程序：
需要下列電腦系統及軟體元件：
| 工作站 | 名稱 | IP 位址 |
|---|---|---|
| 1 | server1.company.com | 9.67.67.101 |
| 2 | server2.company.com | 9.67.67.102 |
| 3 | server3.company.com | 9.67.67.103 |
| 網路遮罩 = 255.255.255.0 | ||
Name= www.company.com IP=9.67.67.104
新增 www.company.com 的別名至 server2.company.com 和 server3.company.com 中的迴圈介面。
ifconfig lo0 alias www.company.com netmask 255.255.255.0
ifconfig lo0:1 www.company.com 127.0.0.1 up
您現在已完成兩部 Web 伺服器工作站上所有必要的配置步驟。
藉由配送器，您可以利用指令行、配置精靈或圖形式使用者介面 (GUI) 來建立配置。
如果您打算使用指令行，請遵循下列步驟：
dscontrol executor start
dscontrol cluster add www.company.com
dscontrol port add www.company.com:80
dscontrol server add www.company.com:80:server2.company.com
dscontrol server add www.company.com:80:server3.company.com
dscontrol executor configure www.company.com
dscontrol manager start
配送器 現在會根據伺服器效能執行平衡負載。
dscontrol advisor start http 80
配送器現在確定用戶端要求不會傳送至失敗的 Web 伺服器。
您現在已經完成本端連接伺服器的基本配置。
如果您打算使用配置精靈，請遵循下列步驟：
dsserver
精靈會引導您逐步執行建立配送器元件之基本配置的程序。它會詢問您網路的相關問題，並引導您設定配送器叢集，以平衡負載伺服器群組的資料傳輸。
配置精靈包含下列畫面：
如果要啟動 GUI，請遵循下列步驟：
dsserver
