macos准备安装失败



编者注：
本文的“监视”部分已于2016年10月10日更新，以包括有关WebSphere Application Server V8.5和更高版本的指南。



计划成功的恢复

首先，我并不是要建议您计划失败，而是建议您在发生故障（尤其是应用程序基础结构某些部分的故障）时做好准备。 此外，由于不可避免会发生故障或停机，因此您需要计划和实践故障，以便为发生故障或停机做好准备。 否则，John Wooden短语“准备失败就是准备失败”将适用于您。

特别是，您应该在中断或中断环境中进行练习或模拟中断，最好是在测试环境中进行练习，不仅要确定如何以最佳方式调整应用程序基础结构以进行恢复，还要确保问题通知和问题解决程序有效。 正如我在与客户交谈时经常说的那样：您不想在停电期间边做边学，这就是为什么必须进行练习的原因。

基础

IBM Knowledge Center中的IBM®WebSphere®Application Server的排队网络主题概述了需要调整和测试性能的组件。 本主题也是组件的良好入门清单，如果发生故障，您还需要测试和调整组件以最大程度地减少影响。 但是，IBM Knowledge Center中的列表（和图）并不一定列出所有组件，也没有提及每一层的组件数量，这在采用集群实现高可用性时很常见。 尽管不打算全部包含在内，但图1为硬件和软件组件的多个维度以及必须考虑的几个硬件或软件组件实例增加了更多的粒度。

图1.典型集群环境中的WebSphere Application Server组件和队列





如果为您的环境绘制类似的图表，则需要考虑的测试和调整应显而易见。 例如：

  • 如果其中一台HTTP服务器发生故障，那么其余HTTP服务器是否具有足够的容量来处理平均生产工作负载？ 高峰生产工作量如何？ 连接超时和请求超时需要什么操作系统调优，以使故障识别和“上游”组件（在这种情况下为IP Sprayer）请求重定向尽可能无缝？
  • 同样，如果应用程序服务器出现故障，其余的应用程序服务器实例是否具有处理平均和峰值工作负载的能力？ HTTP服务器插件需要进行哪些调整才能最大程度地减少请求故障转移到其余应用程序服务器时的延迟？
  • 如果数据库失败，则需要执行哪些OS调整，WebSphere Application Server连接池调整和JDBC提供程序调整？ 如果使用数据库的硬件群集，例如HACMP或Veritas Cluster Server，则需要对群集软件执行哪些调优？ 如果涉及数据库复制（例如IBMDB2®HADR或Oracle®RAC），那么又应采用哪种特定的调整和配置来使故障转移方案尽可能地无缝？

监控方式

上一节中暗含的要求是监视当前的生产环境以及收集当前的响应时间和资源利用率指标。 这样，可以采用代表性负载（复制生产平均负载和峰值负载的负载）进行测试和调整。

表1列出了我通常用于此目的的WebSphere Application Server PMI统计信息。 如果您熟悉WebSphere Application Server，或更具体地说，是WebSphere Application Server PMI，您会注意到该列表不是WebSphere Application Server V8和更早版本的PMI统计信息的缺省列表。 我之所以使用以下列表，是因为它为我提供了确定实际资源使用情况的数据，而不仅仅是池大小。

表1. WebSphere Application Server PMI统计信息

连接池

JVM运行时

HTTP会话管理器

系统资料

JDBC

  • 分配计数
  • ReturnCount
  • CreateCount
  • 关闭计数
  • FreePoolSize
  • 泳池大小
  • JDBC时间
  • 使用时间
  • 等待时间
  • WaitingThreadCount
  • PrepStmtCacheDiscardCount

JMS

  • JMS队列
  • 连接工厂
  • 连接池
  • 泳池大小
  • 最大百分比
  • 使用百分比
  • 等待时间
  • 堆大小
  • 使用的内存

可选的

  • GC后释放的百分比
  • ％在GC上花费的时间
  • ActiveCount
  • CreateCount
  • InvalidateCount
  • LiveCount
  • 一生
  • TimeSinceLastActivated
  • TimeoutInvalidationCount

可选的

  • SessionObjectSize *

*仅在测试中

  • ProcessCpu用法

线程池

Web容器

讯息引擎

  • ActiveCount
  • 活动时间
  • CreateCount
  • 销毁数量
  • 泳池大小
  • 宣告ThreaHungCount
  • ActiveCount
  • 活动时间
  • CreateCount
  • 销毁数量
  • 泳池大小
  • 宣告ThreaHungCount
  • BufferedReadBytesCount
  • BufferedWriteBytesCount
  • CacheStoredDiscardCount **
  • CacheNotStoredDiscardCount **

可选的

  • AvailableMessageCount
  • LocalMessageWaitTime

**不在日志中的PMl中

要启用表1中显示的PMI设置，如果您正在运行WebSphere Application Server V8和更早版本，请遵循IBM知识中心中“ 启用定制PMI集合”主题中的指示信息。 如果您正在运行WebSphere Application Server V8.5或更高版本，则不需要自定义，因为PMI的缺省值随着WebSphere Application Server V8.5中添加智能管理而更改，除非您想要添加更多度量。 还请注意，列出的几个指标不是PMI统计信息。 而是，它们在应用程序服务器的SystemOut.log中可用。 此外，由于SessionObjectSize会对性能产生重大影响，因此应仅在测试中使用，然后谨慎使用。

调音

如果在每个级别上都有关于当前资源使用和响应时间的准确数据，则可以继续进行性能和故障转移的调整，然后通过测试进行验证。 在最大化性能和吞吐量方面，我通常首先观察峰值时的实际池使用情况（例如，Web容器线程池或JDBC连接池）。 然后， 在性能测试之前 ，我将实际池使用量乘以1.2来确定池的大小 。 为了测试故障转移，观察值发挥作用，以正确设置WebSphere Application Server组件用来检测下游组件故障，然后将请求定向到备用（群集）组件的各种队列深度和超时。

例如，您在Web层或数据访问层上的请求运行时间很长（例如几秒钟）。 在这种情况下，您需要将连接超时或请求超时设置为足够长的时间，以允许正常请求进行处理而不会发出失败信号。 不利的一面是，在请求停止运行后，将在几秒钟内继续向该请求发送可能是无响应的组件。 也就是说，请求将在故障组件的上游排队，从而消耗在重定向请求之前等待故障的套接字或线程和连接池。


高可用性说明

在分布式计算环境中，组件之间的高可用性和故障转移检测通常取决于通信连接故障：连接的过早关闭，无法打开连接或现有连接上的请求超时。 这是针对组件和其他针对分布式计算环境的高可用性和故障转移的产品之间的WebSphere Application Server Network Deployment高可用性架构的重要部分的基础。 此类产品可能包括群集产品，例如HACMP，MC / Serviceguard和Veritas Cluster Server。


我对调优HTTP Server插件的想法与先前的文章相同 ，因此，我将重点介绍连接池和JDBC提供程序的调优。 根据观察到的连接池使用时间的值，将连接池连接超时设置为对您的环境和应用程序而言尽可能小的数值。 这样，您不会因为一个长期运行的请求而将数据库错误地标记为不可用。 假设您观察到平均使用时间为500毫秒。 可以考虑将超时设置为少于10秒，这比默认的180秒要短得多。 降低多少？ 好吧，您要测试的应用程序是否代表所有应用程序，或者是存在一个（或多个）应用程序定期运行长时间查询的情况？ 如果是这样的话，这些运行时间较长的应用程序的连接池平均使用时间乘以某个“安全系数”（例如前面提到的池大小的1.2）应该代表设置连接超时的最小值。 我要补充一点，在更高版本的WebSphere Application Server中，EntirePool的连接池清除策略是缺省的。 建议使用此清除策略，因此如果您的环境中不是默认策略，则应采用该策略。

调整连接池时，还需要调查并设置JDBC提供程序的超时属性，因为WebSphere Application Server连接池依赖JDBC提供程序来管理连接和请求超时。 通常，此信息将记录在数据库文档中，而不是在IBM WebSphere Application Server知识中心中。 反过来，JDBC提供程序依赖于操作系统的TCP / IP实现，因此您也需要对其进行调整。 IBM Knowledge Center中提供了一些关键操作系统和TCP / IP参数的快速参考。

（ 提示：对于DB2，用于调整JDBC提供程序的连接行为的两个关键属性是blockingReadConnectionTimeout和loginTimeout ，它们分别控制现有连接保持打开状态的时间长度和等待新连接所花费的时间。额外提示：Oracle这两个属性的相似之处是oracle.jdbc.ReadTimeout和setLoginTimeout（请参见参考资料 ）。

此外，在WebSphere Application Server中，每个数据源都有一个预填充的定制属性列表，对于DB2和Oracle，WebSphere Application Server定制属性loginTimeout控制着等待新连接所花费的时间。）

测试中

初始设置值后，您将需要进行测试。 在正常的性能测试中，您通常会通过将一个或多个组件运行到100％CPU（或可能是网络饱和）来尝试最大化吞吐量。 但是，与正常性能测试不同，您将模拟代表生产平均峰值和生产峰值的工作负载。 达到稳定状态后，您将诱发或模拟组件的故障。 一种常用的技术是拉动网络电缆或停止网络适配器，尽管这些技术可能经常使用，但它们可能无法准确地模拟许多中断。

例如，您的一个组件由于负载而减慢了速度，并继续接受请求，并且实际上并未关闭连接（这只是缓慢而没有死机）。 导致网络故障不会模拟这种特定类型的故障。 实际上，模拟网络故障应该是“轻而易举的事”，因为如前所述，检测拒绝的连接请求或定时请求是大多数分布式计算HA的核心。 如果您想“准备失败”，则需要执行更多测试。 例如，您可以编写一个运行服务器循环的shell脚本，编写输出以消耗CPU和内存，有效地挂起OS，但保持现有的连接和请求打开直到超时（如果有的话）。 另一个替代方案是编写一个Servlet，该Servlet可以添加到正在测试的应用程序中，以实现长时间的睡眠。 同样，目的是消耗一组或多组资源以最终引发故障转移。 另一种选择是采用“挂起”进程的功能，这通常是由系统监视和调试工具提供的。

在通过模拟一个集群成员的故障进行测试的过程中，您将需要观察排队的请求数以及进行故障转移所需的时间。 然后，您需要开始调整超时和池大小，以便上游组件（例如，用于Web容器的HTTP服务器插件，或用于数据源的Web容器）提供更早的识别。 同时，如果发生故障，您将尝试不降低通过爬网的吞吐量。

通常，增加超时或池大小的值将延迟对下游组件故障的识别，但是对于池大小，如果发生故障，则较大的值还可以提供一定的缓冲。 如您所见，进行调整以防止网站在故障期间停滞将需要在增加和减少各种参数之间进行权衡。 要达到您的环境的最佳值，就需要对各种设置和故障情况进行迭代测试。 这样，您（或至少您的计算机系统）已准备好发生故障，这反过来又可以帮助确保您的成功（以及继续工作）。