Tivoli Service Automation Manager 7.2.2 引入了擴充套件 的概念，該擴充套件是一組 TSAM 軟體元件，可以向 TSAM 平臺新增更多功能。一個擴充套件通常（但不限於）可以實現以下功能：

• 可以實現一個新的 IT 服務自動化解決方案，該解決方案在 TSAM 中稱為服務定義；例如，一個儲存即服務解決方案可以為一所大學的學生提供主目錄。
• 可以向現有服務定義新增功能；例如，將開箱即用 TSAM 擴充套件為一個服務解決方案，使它能夠將除啟動磁碟以外的更多磁碟連線到虛擬機器中。

這些擴充套件是由 IBM 或客戶服務團隊在 TSAM 開發週期以外開發併發布的。由 IBM 開發的擴充套件是在為 TSAM 客戶免費提供的 Integrated Service Management Library 中釋出的；它們附帶了安裝和配置文件，以及一個符合 IBM 標準的使用者指南。IBM Tivoli Service Automation Manager Information Center 是獲取 IBM 釋出的這些擴充套件的線上文件的入口點（參見 

在 IBM 釋出的諸多擴充套件中，有兩個擴充套件允許管理網路裝置的配置，可以向使用 TSAM 建立的虛擬伺服器專案新增安全性、可擴充套件性和冗餘性：

• 面向 Juniper SRX Firewall 的 IBM Tivoli Service Automation Manager 7.2.2 擴充套件
• 面向 F5 BIG-IP Load Balancer 的 IBM Tivoli Service Automation Manager 7.2.2 擴充套件

Juniper SRX Firewall 擴充套件的功能是在由 Juniper SRX 企業防火牆保護的 VLAN/子網中，通過一組預設規則自動限制 TSAM 專案中配置的虛擬伺服器。在專案的生命週期內，雲管理員可以通過 Modify Firewall Rules 擴充套件提供的一個服務進一步優化防火牆規則。在擴充套件的初始設定期間，可以根據客戶的需求對預設規則進行定製。

F5 BIG-IP Load Balancer 的擴充套件能夠將一個 “虛擬負載均衡器” 放入 TSAM 專案中已配置好的虛擬伺服器中，從而增強伺服器上安裝的應用程式可擴充套件性和冗餘性：通過建立一個 Load Balancer Policy，可以在 TSAM 專案的 VLAN/子網的公共 Virtual IP 地址 (VIP) 中釋出應用程式。Load Balancer Policy 可以通過與應用程式相連的 VIP:Port 來識別，或者通過執行該應用程式的 TSAM 專案的虛擬伺服器叢集來識別。

這些特性使企業客戶能夠向其分支辦事處、業務合作伙伴和客戶提供分層式業務應用程式（如 J2EE 應用程式），並且這一過程非常迅速、安全，具有可重複、可擴充套件和冗餘性。

在 使用 TSAM 擴充套件來部署 J2EE 應用程式 中定義了一個場景，目標是將一個三層式 J2EE 應用程式安全地部署到雲中，並演示如何在 TSAM 中設定和配置擴充套件，從而完成部署；我們建議您閱讀本文，更加全面地瞭解其中介紹的方法。

本文將介紹如何根據您的系統要求調整負載均衡器的策略；如何在業務應用程式的工作負載發生變化時新增和移除應用伺服器；如何修改防火牆規則，以及您需要這樣做的原因。

客戶 ABC 是一家執行私有（企業內部）雲解決方案的企業，基於 TSAM 7.2.2、Juniper SRX Firewall 擴充套件和 BIG-IP F5 Load Balancer 擴充套件。ABC 通過 TSAM 平臺為分公司、業務合作伙伴和客戶提供服務。ABC 特別倚重該平臺的開箱即用功能，通過 http/https 標準協議向客戶提供 Web 應用程式。

ABC 使用的一個典型 Web 應用程式是一個帶有 http 伺服器、應用伺服器和資料庫伺服器的 J2EE 應用程式。在傳統部署中，這些伺服器在邏輯上是通過路由器和防火牆彼此隔離，路由器和防火牆限制網路的連線和對伺服器的訪問。資料庫伺服器通常從一個安全的儲存區訪問資料。

如果不下載 Firewall and Load Balancer 擴充套件的話，ABC 將不得不建立自己的流程來隔離不同網段上的伺服器，以及平衡對應用伺服器的請求，這些伺服器通常被部署為一個叢集。但是 ABC 是一家明智的客戶，由於它已經具備 BIG-IP F5 和 Juniper SRX 網路裝置，因此決定設定 TSAM 擴充套件來標準化其 Web 應用程式的佈局。

現在，讓我們來探討一下負載平衡和網路防火牆規則。

BIG-IP F5 Load Balancer 的 TSAM 擴充套件提供了一些在業務應用程式的應用伺服器之間平衡工作負載的服務。本文的姊妹篇描述了初始部署期間實現這一目的所需的步驟（位於 使用 TSAM 擴充套件來部署 J2EE 應用程式）；不過，該文章並沒有詳細介紹負載均衡器策略的屬性。

雖然您在自己的測試實驗室中部署業務應用程式時保留了預設值，但是在將它部署到客戶端時，需要更好地理解這些屬性的含義，因為選擇合適的負載均衡器策略會對效能和資源消耗產生重要的影響。

因此，讓我們開始學習如何自定義負載均衡器策略。

完成初始部署後，您可以使用 Modify Load Balancer Policy 服務隨時修改負載均衡器管理工作負載的方式，該服務實際上需要使用與 Create Load Balancer Policy 相同的引數（不同的是策略的 name 和 VIP:port 屬性不能修改）。

負載均衡器策略是由 BIG-IP F5 Load Balancer TSAM 擴充套件定義的內部工件，包含為 BIG-IP 裝置實現最佳配置所需的資訊。它的職責是儘可能地簡化業務應用請求者的任務，然後將 BIG-IP 裝置的複雜性隱藏到幾個直觀的引數中，這些引數允許擴充套件程式碼自動執行 BIG-IP 配置步驟。

考慮到業務應用程式的請求者需要在不使用負載均衡器策略抽象的情況下執行操作，所以可以將配置檔案看作是一個設定容器，這些設定用於定義 BIG-IP 裝置中網路流量的行為（例如 http），每個設定支援一個特定的特性。這些特性的例子包括：

• 向 HTTP 請求中插入標頭
• 壓縮 HTTP 伺服器響應
• 應用程式身份驗證
• 連線池，等等

負載均衡器策略抽象根據以下內容自動識別出最適合 BIG-IP 裝置的配置檔案：

• 流量型別（圖 1 中的協議 1）：HTTP、HTTPS、TCP 和 UDP。
• 虛擬 IP 地址的型別（圖 1 中的虛擬伺服器型別）：Standard 和 Performance。Performance 指定了一個 VIP，您需要為其提高 HTTP 或第 4 層請求的處理速度。
• 您是否希望重用 BIG-IP 和平衡後的虛擬伺服器（圖 1 中的連線池）之間的連線，這將通過最小化連線設定和拆除來降低虛擬伺服器負載（啟用這一選項將啟用 F5 Networks OneConnect 特性，該特性將開啟伺服器端連線並形成連線池以進行重用，從而優化網路連線的使用）。
• 您是否希望客戶端請求在會話生命週期內或後續會話期間傳遞到專案中的同一個虛擬伺服器（圖 1 的 Session Persistence）。

對於本文及姊妹篇中定義的標準化業務應用程式，可以通過下面的內容設定一個負載均衡器策略：

• Protocol：HTTP。
• Virtual Server Type：在測試應用程式時使用 Standard 型別；在將其部署到客戶端時使用 Performance 型別。
• Connection Pool：如果選擇的是 Performance VIP，則將自動選擇該選項，如果選擇的是 Standard VIP，則可以決定是否使用該選項。
• Session Persistence：該引數取決於業務應用程式的特徵。如果需要設定，記住擴充套件程式碼在 BIG-IP 裝置上配置了 cookie 永續性檔案，BIG-IP 裝置使用客戶端計算機上儲存的 HTTP cookie 將客戶端重新連線到某個網站中此前訪問的均衡虛擬伺服器。

如圖 1 所示，負載均衡器策略傳遞了額外的資訊：

• BIG-IP 裝置用於在虛擬伺服器之間平衡工作負載的路由演算法（圖 1 中的演算法）可以是 round robin（迴圈）、least connection（最少連線）或 predictive（預測式）。對於任何客戶端請求，BIG-IP 都會執行該演算法來選擇合適的虛擬伺服器以向其傳送請求。為此，它需要獲得有關平衡後的虛擬伺服器的監視資訊和可用性資訊，這些資訊由所謂的監視器定期收集。
  
  
• 擴充套件程式碼使用健康檢查引數（圖 1 中的 Probe Protocol、Check Interval 和 Timeout）配置 BIG-IP 監視器。Check Interval（檢查間隔）指定了 BIG-IP 對虛擬伺服器進行探測的頻率，而 Timeout（超時）指定了虛擬伺服器響應監視器請求的秒數；如果超過這一時間，則認為虛擬伺服器停止執行，並且不會作為新連線的目標。

您可能會問，哪一種演算法最適合本文定義的業務應用程式？這取決於應用程式的特徵。

• 最簡單的演算法是 round robin；BIG-IP 將從響應監視器的虛擬伺服器的迴圈列表中選擇下一個伺服器。
• 一種更高效的演算法是 least connections；按照這種演算法，BIG-IP 將保留每個均衡後的虛擬伺服器處理的連線的統計資料，然後向連線數最少的池成員傳遞一個新連線。
• 最佳演算法是 predictive；按照這種演算法，BIG-IP 將使用相同的分級方法，但是仍將進行趨勢分析，以確定節點效能是否改進或退化。

使用的演算法越好，用於執行計算所需的 BIG-IP 資源就越多。因此，您可能希望在測試業務應用程式時選擇 round robin 演算法，在將其部署到客戶端時，則將負載均衡器策略改為 predictive。

負載均衡器策略屬於一個單一的 TSAM 專案，可以從一個專案中擴充套件到多個虛擬伺服器。可以在一個專案中部署多個策略，但是每個策略都需要一個專門的 VIP:port 對來處理外部訪問。

現在，讓我們看看如何在工作負載增加時新增應用伺服器，並在工作負載減少時移除它們。

隨著對應用伺服器的請求逐漸增加，客戶端會發現響應時間變慢。您可以通過執行定期的趨勢分析報告並及時新增應用伺服器來解決這個問題。

您的業務應用程式的管理員可以通過使用下面的服務產品實現這一目標：

1. TSAM Add Server to Project 服務：使用該服務為業務應用程式專案請求另一個應用伺服器。
2. Modify Load Balancer Policy 服務：TSAM 提供了新應用伺服器後，使用該服務將伺服器新增到負載均衡器。在 Create Load Balancer Policy 視窗中，向新伺服器的主機名新增一個勾號（參見圖 2）。

當出現相反的情況（您的趨勢分析報告表明業務應用程式的利用率下降），您可能希望釋放資源，將它們用於 IT 環境中的其他用途，或降低資料中心的功耗。您可以決定是否關閉某些應用伺服器或釋放它們，這樣做也可以釋放虛擬機器管理程式 (hypervisor) 的資料儲存中的空間。

如果業務應用程式的管理員決定關閉應用伺服器，那麼會使用 TSAM Stop Server 服務，負載均衡器很快就會檢測到伺服器沒有響應（通過監視器）並停止傳遞連線。它會在伺服器重啟後開始重新傳遞連線。

如果管理員決定徹底從業務應用程式專案中移除應用伺服器，則會使用下面這些服務：

1. Modif Load Balancer Policy 服務：使用該服務從負載均衡器中移除應用伺服器。直接轉到第二個螢幕（參見圖 2），去掉伺服器主機名的勾號。
2. TSAM Remove Server from Project 服務：使用該服務解除伺服器的配置。

TSAM 用於簡化雲端計算的最佳特性之一就是能夠根據工作負載的變化自動執行管理任務，包括配置/解除配置伺服器。我們稍後將詳細討論這方面的內容。

這個部分很有趣，它類似前一節的內容，但是管理員不需要在每次工作負載變化時進行操作。生產 Web 應用程式所需的計算資源會經常變化（包括改變頻率和所需資源的數量），資源量取決於所提供的伺服器的型別。下面是一些示例場景。

1. 一個線上的電子裝置商店應用程式在聖誕期間會迎來交易高峰，而一年中的其他時間的工作負載則比較穩定，即使每年的工作負載都會增加。
2. 一個企業應用程式發現僱員在每個月的頭幾天出勤率達到高峰，而在每個月的其餘時間出勤率幾乎沒有變化。
3. 一個線上圖書館通常會在夏季遇到圖書借閱急劇減少的情況。
4. 一個國際線上新聞網站在全球發售重要事件時會面臨不可預測的高峰訪問量。

系統及時、準確地進行響應，提供可用的計算資源來滿足應用程式的實際需求，這種能力對於維持與客戶的服務水平協議 (SLA) 並優化資源的使用至關重要。

如前面的小節所述，TSAM 和 BIG-IP F5 Load Balancer 的 TSAM Extension 提供了相應的服務，可以響應工作負載的變化；然而，這些服務並沒有提供自動的或自調優的解決方案，從而在無管理員人為干預的情況下重新配置業務應用程式。這些內容必須由客戶專門建立。

本節的目標是解釋使用公共 TPAE（Tivoli Process Automation Engine）和 TSAM API 以及其他工具可以實現多大程度的自動化。本節介紹了將自調優功能新增到 TSAM 解決方案的幾種方法，但是本文不會對解決方案的細節進行深入探討，相反，本文指出了一些不同的可用技術和一個通用的架構。

首先，我們將描述解決方案的方法和實現所需的元件。然後將這種一般方法轉化為兩種不同的具體實現，這兩種實現採用了不同的技術。

圖 3 列出瞭解決方案的組成部分：

• 控制器驅動系統執行自調優操作，將業務應用程式要求的 SLA 與當前觀察到的行為進行比較，並決定要執行的操作：它將決定何時配置或解除配置應用伺服器，何時啟用休眠的應用伺服器，以及何時關閉空閒的伺服器。 
  
  
• 資源監視器是收集 Web 應用程式及底層虛擬伺服器的狀態的元件。這些是啟動控制器處理的關鍵輸入資料。為控制器提供資料的模式可以基於定期的資源檢查，或可以由事件驅動；具體將根據監視器所採用的技術進行選擇。 
  
  
• 資源管理器是一個制動裝置 (actuator)，該元件負責配置/解除配置應用伺服器並更新負載均衡器策略。本文討論的場景中將使用 TSAM 和 BIG-IP F5 Load Balancer 的擴充套件。

下面提出了兩種解決方案，都需要 TPAE 定製和整合技巧 (Maximo Enterprise Adapter) 和基於 TSAM REST 的 API 技能：

1. 第一個解決方案利用 BIG-IP 裝置監視器收集的資料實現控制器。該解決方案還要求具備獲得 BIG-IP 監視器資料的開發技能。
2. 第二個解決方案是一個事件驅動式控制器示例，基於 IBM Tivoli Monitoring (ITM) 產品。它也需要 ITM 技能來處理事件（TEC 或 Omnibus）。

讓我們詳細瞭解這兩個解決方案。

圖 4 描述了在這種情況下如何實現通用解決方案。

控制器在 TPAE 平臺上實現，該平臺使用預排程的任務（圖中的 TPAE Cron Task）定期檢查資源的狀態，然後採取相應的操作。將對資源的檢查傳送給 BIG-IP 負載均衡器，並在控制器中包含一個支援庫，用它來訪問裝置的 IControl 介面。

IControl 介面可以支援各種程式設計環境（如 Java®、.NET®、Python、Perl），並允許以較為靈活的方式實現該解決方案。對於 Java 程式語言，支援庫為 JAR 檔案。

當控制器檢測到所監視的應用程式的統計資料出現報警值時，它會確定後續操作以維持系統的效率和可用性。然後將呼叫 TSAM 的 REST API 介面並提交服務請求，完成配置任務。

如圖 5 所示，解決方案依賴 ITM 代理監視應用伺服器的狀態。

要實現此目的，您需要在應用伺服器上安裝 ITM 代理並進行相應地配置。可以在請求業務應用程式的 TSAM Project 時完成該配置，或通過在用於例項化應用伺服器的虛擬映象中嵌入 ITM 代理來完成該配置。統計資料隨後被上傳到 ITM 伺服器並轉發給 OMNIbus，以便進行事件處理。

當事件到達 OMNIbus 後，可以通過一個定製的退出程式呼叫 TSAM REST API；甚至可以利用 OMNIbus-Service Request 管理器整合來提交配置請求。

現在，讓我們看看另一個主要的問題：在需要為給定的企業應用程式修改安全設定時，如何修改防火牆規則。

當您根據預設規則（在 TSAM Extensions 配置期間設定網路模板時定義）部署業務應用程式時，TSAM Extension for Juniper SRX Firewall 將自動設定防火牆規則。您不需要再次處理防火牆規則。

當然，這種場景符合實際情況嗎？許多情況下，您需要為給定的業務應用程式專案修改安全設定。因此，您希望檢視當前的設定，不是嗎？

TSAM Extension for Juniper SRX Firewall 提供了一個 Modify Firewall Policy 服務，它類似於負載均衡器策略。防火牆策略是由擴充套件定義的一個內部元件，包括應用於 TSAM 虛擬伺服器專案，更確切地說，該專案的子網/VLAN 的防火牆規則。每個專案都有自己的防火牆策略，您可以新增、修改或移除各個防火牆規則，如圖 6 所示。

防火牆規則允許源子網發起特定的協議流量併到達目標子網。源和目標子網（圖 6）通常是使用 CIDR 符號（子網地址/識別子網的 IP 地址的位數）指定的完整子網。不過，如果希望允許特定主機的流量，某個 IP 地址可以被同時指定為某個防火牆規則的源子網和目標子網。

您可能會注意到，您無法指定規則來拒絕流量。擴充套件的一些要點是它具備以下能力：

• 簡化業務應用程式的請求者的工作
• 儘可能減少安全風險。

因此，防火牆策略始終包含一條無法改變的潛規則：拒絕所有流量。因此，您的管理員只能夠以例外的方式允許流量。這是這一特性的一種簡單、低風險的實現。

為了進一步簡化管理員的工作，可以使用以下三種防火牆規則：

• From Internet 規則：這將允許從 DMZ 發起並流向專案子網/VLAN 的特定協議流量。您可以使用符號 0.0.0.0/0 表示任意地址；從 0.0.0.0/0 到 192.168.0.0/16 的 From-Internet 規則即表示 DMZ 中的任何 IP 地址都可以發起到子網 192.168.0.0/16 的連線。
  
  
• To Internet 規則：這允許從專案的某個應用伺服器到 DMZ 的特定協議流量。 
  
  
• From Other Project(s) 規則：這使您能夠開啟一個專案，與其他專案進行通訊，比如託管共享服務的專案。如果在共享服務專案中將 From-Other-Project(s) 規則設定為 0.0.0.0/0 到 192.170.0.0/16，那麼這意味著任何其他專案都可以發起連線並可以使用共享服務。在需要訪問共享服務（子網為 192.168.0.0/0）的專案上，要將 From-Other-Project(s) 規則設定為從 192.168.0.0/16 到 192.170.0.0/16 才能完成配置。

結束語

在本文中，我們解釋瞭如何藉助 Juniper SRX Firewall 和 BIG-IP F5 Load Balancer 的 TSAM 擴充套件來處理在雲中部署的 J2EE 業務應用程式的生命週期管理問題。我們特別解釋瞭如何恰當地調優負載均衡器來處理業務應用程式的工作負載，如何通過新增和移除應用伺服器來響應業務應用程式的利用率變化，最後我們介紹瞭如何高效使用防火牆來鎖定對您的伺服器的訪問。

使用 TSAM 擴充套件來部署 J2EE 應用程式 中描述了對業務應用程式的初始配置。您可以瞭解如何建立由虛擬伺服器組成的 TSAM Project，這些虛擬伺服器隱藏在 BIG-IP F5 負載均衡器背後，並通過由 Juniper SRX 防火牆管理的 VLAN/子網進行限制。