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 应用程序的布局。
有关该场景的更多细节，请参阅?使用 TSAM 扩展来部署 J2EE 应用程序。
现在，让我们来探讨一下负载平衡和网络防火墙规则。
?
负载平衡简介
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）。
图 1. 负载均衡器策略属性
?对于本文及姊妹篇中定义的标准化业务应用程序，可以通过下面的内容设置一个负载均衡器策略：
- 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 对来处理外部访问。
现在，让我们看看如何在工作负载增加时添加应用服务器，并在工作负载减少时移除它们。
?
添加和移除应用服务器
随着对应用服务器的请求逐渐增加，客户端会发现响应时间变慢。您可以通过运行定期的趋势分析报告并及时添加应用服务器来解决这个问题。
您的业务应用程序的管理员可以通过使用下面的服务产品实现这一目标：
- TSAM Add Server to Project 服务：使用该服务为业务应用程序项目请求另一个应用服务器。
- Modify Load Balancer Policy 服务：TSAM 提供了新应用服务器后，使用该服务将服务器添加到负载均衡器。在 Create Load Balancer Policy 窗口中，向新服务器的主机名添加一个勾号（参见图 2）。
图 2. 虚拟服务器的负载均衡器策略池?
?当出现相反的情况（您的趋势分析报告表明业务应用程序的利用率下降），您可能希望释放资源，将它们用于 IT 环境中的其他用途，或降低数据中心的功耗。您可以决定是否关闭某些应用服务器或释放它们，这样做也可以释放虚拟机管理程序 (hypervisor) 的数据存储中的空间。
如果业务应用程序的管理员决定关闭应用服务器，那么会使用 TSAM Stop Server 服务，负载均衡器很快就会检测到服务器没有响应（通过监视器）并停止传递连接。它会在服务器重启后开始重新传递连接。
如果管理员决定彻底从业务应用程序项目中移除应用服务器，则会使用下面这些服务：
- Modif Load Balancer Policy 服务：使用该服务从负载均衡器中移除应用服务器。直接转到第二个屏幕（参见图 2），去掉服务器主机名的勾号。
- TSAM Remove Server from Project 服务：使用该服务解除服务器的配置。
TSAM 用于简化云计算的最佳特性之一就是能够根据工作负载的变化自动执行管理任务，包括配置/解除配置服务器。我们稍后将详细讨论这方面的内容。
?
自动应用服务器配置和解除配置
这个部分很有趣，它类似前一节的内容，但是管理员不需要在每次工作负载变化时进行操作。生产 Web 应用程序所需的计算资源会经常变化（包括改变频率和所需资源的数量），资源量取决于所提供的服务器的类型。下面是一些示例场景。
- 一个在线的电子设备商店应用程序在圣诞期间会迎来交易高峰，而一年中的其他时间的工作负载则比较稳定，即使每年的工作负载都会增加。
- 一个企业应用程序发现雇员在每个月的头几天出勤率达到高峰，而在每个月的其余时间出勤率几乎没有变化。
- 一个在线图书馆通常会在夏季遇到图书借阅急剧减少的情况。
- 一个国际在线新闻网站在全球发售重要事件时会面临不可预测的高峰访问量。
系统及时、准确地进行响应，提供可用的计算资源来满足应用程序的实际需求，这种能力对于维持与客户的服务水平协议 (SLA) 并优化资源的使用至关重要。
如前面的小节所述，TSAM 和 BIG-IP F5 Load Balancer 的 TSAM Extension 提供了相应的服务，可以响应工作负载的变化；然而，这些服务并没有提供自动的或自调优的解决方案，从而在无管理员人为干预的情况下重新配置业务应用程序。这些内容必须由客户专门创建。
本节的目标是解释使用公共 TPAE（Tivoli Process Automation Engine）和 TSAM API 以及其他工具可以实现多大程度的自动化。本节介绍了将自调优功能添加到 TSAM 解决方案的几种方法，但是本文不会对解决方案的细节进行深入探讨，相反，本文指出了一些不同的可用技术和一个通用的架构。
首先，我们将描述解决方案的方法和实现所需的组件。然后将这种一般方法转化为两种不同的具体实现，这两种实现采用了不同的技术。
图 3 列出了解决方案的组成部分：
图 3. 实现工作负载平衡的自调优解决方案的组成
?- 控制器驱动系统执行自调优操作，将业务应用程序要求的 SLA 与当前观察到的行为进行比较，并决定要执行的操作：它将决定何时配置或解除配置应用服务器，何时启用休眠的应用服务器，以及何时关闭空闲的服务器。?
- 资源监视器是收集 Web 应用程序及底层虚拟服务器的状态的组件。这些是启动控制器处理的关键输入数据。为控制器提供数据的模式可以基于定期的资源检查，或可以由事件驱动；具体将根据监视器所采用的技术进行选择。?
- 资源管理器是一个制动装置 (actuator)，该组件负责配置/解除配置应用服务器并更新负载均衡器策略。本文讨论的场景中将使用 TSAM 和 BIG-IP F5 Load Balancer 的扩展。
下面提出了两种解决方案，都需要 TPAE 定制和集成技巧 (Maximo Enterprise Adapter) 和基于 TSAM REST 的 API 技能：
- 第一个解决方案利用 BIG-IP 设备监视器收集的数据实现控制器。该解决方案还要求具备获得 BIG-IP 监视器数据的开发技能。
- 第二个解决方案是一个事件驱动式控制器示例，基于 IBM Tivoli Monitoring (ITM) 产品。它也需要 ITM 技能来处理事件（TEC 或 Omnibus）。
让我们详细了解这两个解决方案。
利用 BIG-IP
图 4 描述了在这种情况下如何实现通用解决方案。
图 4. 工作负载平衡自调优解决方案：利用 BIG-IP 监视器数据
?控制器在 TPAE 平台上实现，该平台使用预调度的任务（图中的 TPAE Cron Task）定期检查资源的状态，然后采取相应的操作。将对资源的检查发送给 BIG-IP 负载均衡器，并在控制器中包含一个支持库，用它来访问设备的 IControl 接口。
IControl 接口可以支持各种编程环境（如 Java?、.NET?、Python、Perl），并允许以较为灵活的方式实现该解决方案。对于 Java 编程语言，支持库为 JAR 文件。
当控制器检测到所监视的应用程序的统计数据出现报警值时，它会确定后续操作以维持系统的效率和可用性。然后将调用 TSAM 的 REST API 接口并提交服务请求，完成配置任务。
利用 IBM Tivoli Monitoring
如图 5 所示，解决方案依赖 ITM 代理监视应用服务器的状态。
图 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. 针对业务应用程序项目配置的防火墙策略?
?防火墙规则允许源子网发起特定的协议流量并到达目标子网。源和目标子网（图 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/子网进行限制。