内容


大型共享拓扑中的策略及折衷方法

面向基础设施架构师和管理员的事实和建议

Comments

引言

管理任何规模的业务关键系统都需要有专用和正规的流程。单单将它们摆放在一起,就是一个不小的任务。管理由数百或数千个应用程序构成的大型业务关键型系统则更加困难。管理并成功地运行一个这样规模的环境需要极高的技巧和规程,还要针对许多全异的主题进行大量的准备工作和可靠的决策。大型拓扑在这种环境下通常是唯一的,出现问题的规模会因为各种层面间的连锁效应而扩大。临时方法是行不通的并会导致业务中断(如系统意外停机)。

为了帮助您准备、构建和维护大型拓扑,本文确定并讨论了在创建和管理大型共享环境时必须解决的最关键问题。我们的经验表明,最成功的组织常常主动预防性地解决这些问题,而那些不重视这些问题的组织常常会出现严重问题。因此,本文是根据后一情况的经验撰写的:即根据由于不能提前解决这些问题而遇到的实际问题撰写的。

尽管不可能解决每一个方面和场景中可能出现的问题,但希望这里介绍的信息和建议能帮助您为正在计划的环境制定必要的决策和分割点。

共享

大型拓扑的目标之一就是尽可能多地共享资源。共享的资源可能包括 Web 服务器、应用服务器、操作系统、物理服务器、网络等等。共享资源能够潜在地降低整体运营成本,并且在一定程度上还可简化管理任务。然而,共享也存在与非功能性需求相关的不足,这些非功能性需求在共享资源的应用程序之间可能存在巨大差异。高容量、业务关键型应用程序可能具有服务水平协议 (SLA),这些协议要求专用的硬件和软件环境。低容量、非关键型应用程序通常更适合共享资源。在确定某个应用程序是否足够关键,以至于要求使用专用的硬件之前,几乎没有简单的方法能够定义该应用程序是否适合共享资源环境。这是一个特定于每个企业的业务和运作决策。

组织也可以决定在离散和单个业务单位中共享环境。如果具有不同优先级和目标的多个业务单位尝试占用同一环境,而某个经授权的人有时候必须作出影响特定共享环境中所有应用程序的运营决策(受欢迎的或不受欢迎的),这时就可能存在潜在的问题。因此,沿组织边界分割、并与同等环境相比具有不同配置的环境没有什么不正常。

其他的共享障碍包括:

  • 当需要部署某个特定的维护版本(如修复包、操作系统级补丁、共享库升级等等)时,在共享环境中测试所有应用程序非常困难。大多数企业并不具有无限的测试资源,所以,那些对底层升级敏感的应用程序不适用于共享环境。(如果企业很灵活,能够快速补救与维护级别更改相关的应用程序问题,则使用共享更可取一些。)

  • 现有的 WebSphere Application Server 应用程序仍然运行于旧版 WebSphere Application Server 上,这些应用程序需要迁移到一个较新的版本。最终,正在使用的 WebSphere Application Server 的级别或者某些其他基础设施组件将变为“不受支持”的产品。从一个非常低的 WebSphere Application Server 版本迁移会花费大量时间。在迁移过程中,这些应用程序不能与较新的应用程序共享基础设施。由于应用程序与各种旧基础设施组件“粘和”在一起,几乎不存在共享,因此企业仍在使用独有的低级环境。

一致性

大型拓扑中的一致性使事情变得较为简单。但出现更改时,环境将变得更加复杂。事实上,没有任何大型拓扑可以在整个企业中保持同构。这些环境之间将存在差异。企业必须理解团队涉及到的责任和执行这些流程的难度,才能成功管理这些环境。

大型拓扑需要处理的其他难题是,环境中存在数以千计的可以更改的变量这一事实。从网络层一直到环境的每一层,存在许多可以影响环境的配置项。

更改控制

无论是大型环境还是小型环境,都需要无一避免地严格遵守更改控制过程。环境越大,更改控制对该环境的成功或失败的影响也越大。当出现生产环境(或其他任何测试环境)意外停机事件时,管理员可以有效地从更改控制工具提取有关环境中发生了何种更改的信息。没有功能强大的更改控制的组织在意外停机时会拖延很长时间,因为管理员需要尝试并确定哪些变量发生了更改以及何时发生了更改。

更改控制的执行必须使用特定于更改控制流程的工具。这取消了单独使用电子表格和文本文档,但用来向基本更改提供附加信息除外。更改应从某些授权机构提交和批准的工作通知开始。每一次更改都通过标识谁进行了更改和何时更改的工作命令进行跟踪。

配置管理

在许多情况下,管理员有时可能几个星期都不接触某个特定的环境,因此,期望他们能够记清每一个具体环境的每一次细微变动是不合理的。对每个环境进行某种形式的记录是必要的,这也是配置管理工具的用武之地。它通常与更改管理工具集成,配置管理存储库存储着管理员了解自己的环境配置所需的关键信息(请参阅参考资料)。

人员安排

在任何具有大型 IT 基础设施的组织或企业中,有许多角色是必须安排的。在大型环境中,让合适的人担任这些职位变得非常关键。有些角色需要由一个专门人员担任。在其他情况下,一些人可以担当多个角色。某个角色没人担任或让某个人担任太多角色是常见的策略错误。下面提供了这些关键角色的列表。当然,这不是一个适合每个组织的全面列表,因为大多数组织都有一些同样重要的其他角色,如数据库管理员、网络管理员等等。此处列出的角色对大型拓扑的成功至关重要,并且这些角色通常都被忽略了。

  • 企业架构师

    “企业架构师”对应用程序开发和系统基础设施非常了解,并且可以确保结合这些原则作出的决策具有高效性、构思良好和能够正确实施。“企业架构师”应:

    • 具有基础设施和应用程序背景,理解关于围绕拓扑作出的决策的潜在含意(例如,让测试环境和生产环境共享一个部署管理器的缺陷、一个计算单元对多个计算单元等等)。
    • 理解安全的潜在含意(不一定要求是安全架构师)。
    • 能够执行对应用程序体系结构决策和更改的分析(例如,切换到分布式缓存对基础设施有何影响)。
    • 能够作出应用程序架构决策(例如,购买/实施、具有何种功能等等)。
    • 能够创建应用程序编码标准文档,包括实现最佳性能的编码最佳实践。
    • 能够执行应用程序体系结构、设计、文档等任务的审查和核准。
    • 能够执行基础设施的审查和核准。

    除了这些任务外,“企业架构师”另一个非常重要但常常被忽略的活动是,需要审查更改控制请求。任何非常规的更改都应由企业架构师审查。经常发生意外的体系结构更改就是由于无人审查造成的。审查更改对防止这种情况非常重要。

  • 基础设施架构师

    此人员是 IT 组织的服务提供方的技术领导,能够根据业务需求和约束构建基础设施。基础设施架构师对总领导负责并指导企业架构师,确保基础设施满足给定应用程序的需求,还需要与安全架构师密切协作,确保从安全角度对运营环境进行适当加强。

  • 应用程序架构师

    此角色专注于应用程序(或应用程序套件),并需要有丰富的开发经验。应用程序架构师需要理解许多设计和实现决策的权衡,定义编码标准,决定使用哪些开源项目,并制定许多其他战略开发决策。

  • 安全架构师

    担当此角色的人员需要有渊博的安全背景,理解开发方面的安全最佳实践,并可以从安全角度执行代码审核,同时理解安全基础设施最佳实践以及如何减少威胁。此人员负责制定总体安全策略和标准,并与企业架构师密切协作,确保该策略的执行。

  • 构建团队

    软件开发的最后是以构建流程结束的,即从源代码构建有控制和自动执行的应用程序流程。一个典型的构建流程是从软件存储库中提取源代码,使用自动化工具(如 ANT 脚本)构建应用程序,然后,在将构建的应用程序提升到正式的、非开发测试环境之前,测试构建的应用程序,确保基本功能的正确运行。还要作为构建测试流程的一部分测试用于部署应用程序的部署脚本。具有许多应用程序的大型组织会发现,通过具有专业构建经验的团队集中进行构建流程非常有用。通过集中化该流程,可以开发统一的流程和过程,并可以在所有应用程序上重用。这不仅提高了构建的一致性,而且不断提高的共同性还有助于减少部署问题。

  • 性能领导

    性能测试是一个强制性规定,有其本身的一套独特的做法。性能团队领导的职责是:

    • 制定性能测试标准。
    • 从性能角度参与设计和代码审查。
    • 与测试经理一起领导性能测试流程。
    • 评估和推荐用于性能测试和监视的工具。
  • 测试经理或测试协调员

    此人员管理整个测试工作,包括确定基础设施团队,并与之协作构建适当规模的测试环境集,以支持从开发过渡到生产的所有测试功能。此角色还涉及:

    • 制定测试计划和用例。
    • 与测试开发人员一起实施计划和执行用例。
    • 记录历史数据、测试结果、应用程序监视工具数据等。
    • 与企业架构师一起规划测试环境用途。
  • WebSphere 管理员

    此角色经常人手不足,特别是在一次准备了多个测试环境,并且正式流程又进入开发和代码提升流程时更是捉襟见肘。WebSphere 管理员必须:

    • 根据企业架构师或基础设施架构师的决策执行管理任务。
    • 尽管 WebSphere 管理员不进行基础设施决策,但他需要与企业和基础设施架构师一起协作并对其负责。
    • 能够开发一些开发脚本,以尽可能减少在生产环境中使用 WebSphere 管理控制台,使实际开发工作更快、更准确和更具重复性。
    • 具有基本的主机操作系统(Linux®、AIX®、Solaris™ 等)管理技能。
  • 故障诊断师

    尽管这一般不是正式指定的角色,但也需要具有高级技能的高级技术人员才能担任这一角色的领导,以便解决在测试和生产环境中遇到的任何问题(希望没有问题)。此人员必须:

    • 具有应用程序和基础设施方面的双重背景。
    • 能够使用应用程序监视工具(如 IBM Tivoli® Composite Application Manager)进行诊断和分析根本原因。(不使用应用程序监视工具的组织倾向于使用操作系统级别的命令(如 kill -3),这会对最终用户的体验造成严重的负面影响。此外,应用程序监视工具还能够比操作系统级别的工具提供更细粒度的数据(如进程对 CPU 的使用率),并可以记录历史数据,以便在事后检查分析中使用。使用应用程序监视工具提供的数据还可以进行容量规划,但这不是故障诊断师的职责范围。)
    • 能够与测试协调员协作,收集用于分析的关键度量数据。
    • 能够与企业架构师协作,共同处理环境中出现的问题,并提供必要的反馈,促进代码或基础设施方面的改进。
    • 能够指导和培训其他技术人员在故障诊断方面的技能。与其说故障诊断是一门技术,还不如说它是一门艺术,因此,要想在这方面做得出色,最好是通过亲身体验从他人那里学习。因此,指导是故障诊断角色的关键部分。
  • 测试团队

    此团队必须能够开发进行负载测试和功能测试的自动测试脚本(这两个可能是不同的脚本)、执行测试并听取测试协调员的指导。所有测试脚本均由应用程序的业务用例驱动。这里之所以强调功能和负载测试脚本的自动化,是因为手动测试大量应用程序每个更改的成本极其高昂。自动化是频繁进行应用程序测试的唯一可行方法。

术语

在尝试为大型拓扑开发基础设施环境时可能遇到的第一个问题就是基本术语。从事大型拓扑部署的每个组织需要充分的时间定义要部署的组件、片段和部分,以确保所有参与人员对总体的理解达成共识。同样,下面几段介绍将在本篇其余部分中使用的一些常见术语。由于每个企业各不相同,各个企业对这些常见术语可能有自己的一套定义。因此,这里以提问形式引入了这些术语,以便激起讨论,引导您的组织为自身定义这些术语。无论具体形式如何,所有涉及的人员都理解这些术语并达成共识是最重要的。

  • 什么是应用程序?

    尽管这个问题从表面看好像是老生常谈,但它对最终部署具有极其重要的意义。对于企业架构师而言,应用程序可能是在较高层次定义的一些描述,如金融、研究、在线处理、人力资源等。但是,在这些高级描述的每个描述中都有一些执行互不相关的功能的应用程序(或一套应用程序),这些应用程序实际上共同构成了所谓的“应用程序”。因此,重要的是需要弄清您的组织是如何定义的,将什么称作应用程序。

  • 什么是服务?服务是应用程序吗?

    服务是面向服务的体系结构 (SOA) 的一个组件。服务提供应用程序可以重用的接口,以便远程执行一些功能。对于您的环境而言,您需要知道 :

    • 是否将服务视为应用程序,它们是应用程序的一部分吗?
    • 服务的新版本是新应用程序吗?
  • 什么是模块和库?

    说得模糊一些,一个离散的应用程序(在此上下文中,是指部署到应用服务器的特定应用程序 EAR 文件)由各种应用程序“模块”和打包的“库”构成。模块可以由内部开发人员编写,也可以是第三方或开源软件库。这些组件在打包和部署中是重点考虑的因素。

  • 什么是版本?

    软件具有不同的版本。一个环境中不同计算机上的操作系统可以是不同的版本。WebSphere Application Server 具有不同的版本。一个应用程序的各个组件(包括模块和库)可以是不同的版本。您必须详细记录支持的软件和组件之间的版本依赖性(也就是说,应用程序 X 需要运行于 AIX v5.3 版本维护 6 上的 WebSphere Application Server V6.1 Fixpack 5 等)。一个新应用程序版本是否意味着就是一个新应用程序?同一应用程序的多个版本是否可以同时运行,或者新版本是否会取代旧版本?

  • 什么是节点和服务器?

    对于某些情况而言,一个“节点”就是一个物理服务器。对于类似于 LPAR 技术的情况而言,一个“节点”就是一个操作系统的实例,而且多个 LPAR 可以驻留在单一物理框架中。尽管通常不是一个较大的障碍,但清楚地定义硬件会更好一些,这样,当有人说“我们需要 100 台服务器”时,每个人都知道它的意思是需要四个框架,每个物理框架上有 25 个 LPAR,从而避免意外购买 100 个物理框架。说起来好笑,这事还真发生过。

    类似地,在讨论“应用服务器”或“物理服务器”时,最好养成使用完整、明确的术语。从分层术语上说,“服务器”是一个物理硬件,但对于 WebSphere Application Server 管理员而言,它却表示一个 JVM。简单清楚地说明可以避免许多潜在的误解。

  • 哪些被认为是敏感的数据?

    有的组织有一些规定,明确定义被视为“敏感数据”的术语,如社会保险号。其他术语,如通过公共记录(如母亲的娘家姓、地址、电话号码等)很容易确定的个人信息就不太容易分类。分类这些数据元素是一项重要任务,这可以确定应用程序是否在访问被您的组织(或行业)认为是敏感信息的数据。

体系结构决策

一个组织作出的每项决策(与应用程序体系结构、基础设施体系结构、管理、打包部署相关)必须明确记录,并且应将这些文档存档,随时可供所有负责业务成功的任何部门的团队成员查看。当今世界有大量的技术可供使用,从文档管理系统到 wiki,这使得能够相对便捷和方便地达到目的。存档系统体系结构和对体系结构所作的决策的主要原因是为了提供历史记录和上下文,以便对环境进行不断维护和改进。任何基础设施的最大成本都是不断进行维护。由于人员通常会移动到新项目和职位,因此维护环境的人员通常不是创建该环境的人员。如果很好地记录了体系结构的设计方式、特定环境保持原貌的原因等,则持续维护任务就会变得比较简单。如果执行增强的人员理解该环境,则对该环境的后续维护工作就会更加顺利。

任何体系结构决策文档均应至少包含以下信息:

  • 问题陈述

    每个问题陈述都应明确定义企业面临的问题和后果。一个良好的问题陈述应附有多个可选解决方案。问题陈述应包括一个抓住问题实质的问题,例如:“我们应在 Web 服务器后使用 SSL 吗?”

  • 假设和影响

    任何问题陈述都应有具体的假设和影响,陈述这些内容可以让阅读决策文档的任何人都能够清楚地了解决策时的环境。假设和影响可能在数年后随着企业的成熟和发展而改变。

  • 业务需求

    与问题相关的业务需求(如果有)应清楚地标明主题,如服务水平协议和非功能性需求。企业必须能够定义这些需求,否则作出的决策就会有缺陷。在前面的示例中,使用 SSL 的决策可能由业务安全需求驱动,因此应在这里引用。

  • 可能的解决方案

    每个问题都会有多个可能的解决方案,应将每个解决方案记录在案,至少应列出摘要。这包括对应用程序代码的更改、操作更改、硬件更换、基础设施体系结构更改等。如果没有研究所有可能的解决方案,很可能会作出片面选择,有可能使用比所需更昂贵的解决方案。当然,另一方面是必须避免“分析停滞”和实际生成决策。因此,尽管应慎重考虑所有可能的决策,但也没有必要从最底层详细检查每个决策,毕竟这是一个归档的文档。

    最后也是最重要的一点是,记录所有被认为是可能的解决方案可以形成一个历史记录,以便未来的读者了解考虑了哪些情况以及没有考虑哪些情况。当业务需求或技术更改时,这些历史记录可以帮助确定原来的决策,并有助于指导新决策。

  • 选择的解决方案

    从所有可能的解决方案中,最终会决定选择一个实施的解决方案。此部分应解释某个解决方案如何满足或如何无法满足业务需求。

  • 论证

    选择的解决方案必须经过充分论证,说明该解决方案如何能够最好地满足业务需求。此部分必须明确解释所选解决方案如何满足业务需求,它为何是最好的解决方案。

  • 审查期限

    每个解决方案都应包括一个强制性的审查期限。业务需求可能会改变,这些改变可能是应用程序的功能、体系结构、非功能性需求、服务水平协议等。在应用程序的整个生命周期中,制定定期审查计划非常重要。审查期限可以基于时间,也可以由基础设施更改或重要事件触发。例如,审查 Java™ EE 体系结构决策的一个显而易见的时间是在应用服务器升级到一个更高的主要版本,并且该版本可能包括更改以前决策基础的新功能时。至少应能够在更改发生时识别更改,并能够生成新的体系结构文档。(对体系结构文档的更改意味着更改对文档的控制。)

安全注意事项

安全性是每个体系结构决策中的首要标准。不考虑安全性会导致作出错误的决策,从而造成不可挽回的损失;错误决策后再加强安全措施会变得非常困难甚至不可能。不幸的是,安全性是一个常被忽略的主题,或者是在发生安全事故之后才想到的事情。应用程序隔离是与共享基础设施相关的安全的一个方面。

信任在任何关系(无论是人员还是技术)中都是一个重要因素。如果一个应用程序与另一应用程序共处在同一安全域或同一硬件之上,则这两个应用程序之间具有某个级别的信任关系。如果在任一点上都不能建立信任关系,则需要应用适当的分离。

应用程序代码可能来自各种来源,它可能是内部开发的,也可能来自第三方供应商等。无论如何,对于处在同一信任域中的两个应用程序而言,它们必须相互信任。WebSphere Application Server 没有在一个计算单元中提供安全应用程序隔离,因此,如果两个应用程序共享同一个计算单元,则它们必须完全相互信任。尽管可以通过一些代价昂贵和复杂的步骤在管理上部分隔离一个计算单元中的应用程序,但不一定能够完成。(请参见参考资料

在许多情况下,一个应用程序的可信性只能通过彻底的代码审查确定;这意味着需要对部署到环境的应用程序的每个版本进行彻底的代码审查。由于研究表明,代码审查可以通过提高质量来降低成本,因此这不应被视为一种负担。但是,如果是这样,则必须将应用程序放置在单独的计算单元中,或者作为一种需求必须取消应用程序隔离。

您可能会争辩说,Java 2 安全性可以单独保护应用程序,但这不是那种情况。首先,会产生与向启用 Java 2 安全性的环境部署应用程序相关的大量其他管理开销。为应用程序配置策略文件以便与 Java 2 安全性一起运行需要精通应用程序知识并特别了解运行时环境的知识,这在许多组织中是没有的。任何策略文件错误定义或采用快捷方式都是一个不容易发现的漏洞。管理这些文件会成为一个很大的负担。

敏感性威胁可能是对大多数应用程序共享计算单元,但将最敏感的应用程序放在自己的应用了其他“昂贵”需求的高安全计算单元中,如强制代码检查和使用 Java 2 安全性。

性能注意事项

性能和最终用户体验是任何企业最终的主要驱动因素之一。如果最终用户体验在响应时间和可访问性方面都非常差,将意味着客户可能会转向竞争对手的更高性能的网站,从而造成销售损失;或者如果用户转而使用运营成本更高的呼叫中心而不使用在线应用程序,则会造成现金损失。

高容量的应用程序也是独有的,因为它们一般消耗大量的 CPU 或内存资源。具有高容量应用程序的应用场景通常更适于从其他环境进行隔离,因为其资源消耗需求而使它们与其他应用程序几乎不能很好地共存。通常情况下,高容量的应用程序可以提供核心业务功能。因此,必须让其使用任何可用的资源,并应对其隔离。

不太常用的或根据计划使用的低容量应用程序可能是(也可能不是)用于隔离的优先备选项。这实际上取决于应用程序对业务的价值和资源需求。例如,报告应用程序通常要占用大量的资源。即使报告应用程序可能不经常使用(例如在月末进行财务报表时才使用)也需要将其隔离,这是因为此类应用程序要消耗大量的资源。与此相反,那些没有大量资源需求并且也不是业务关键型的内部应用程序可能是与其他类似应用程序共存的优先备选项。

团队成员(包括运营和业务部门代表)需要对应用程序的放置作出这些主观决策。其他硬件成本和运营支持也是每个决策考虑的因素。

解决方案

在开发周期之初,必须对应用程序的性能进行彻底的测试。这通常意味着最初的性能测试(类似于“存根代码”测试)应在项目完成 1/3 之前开始。为了保证成功,应确定所有用例,编写适当的脚本在预期的生产负载下运行这些用例,并且构建的测试环境应有足够的资源来反映生产环境,但在规模上可能要小一些。实际情况是,性能测试在刚开始时经常被忽略,直到流程快结束时才开始考虑,这确实是一个很大的不足之处。

最佳性能环境是能够同时在中间层 WebSphere Application Server 和后端(如数据库、大型机等)复制生产的环境。尽管这不一定对每个组织都切实可行,但每个尝试都应创建一个能够代表真实情况的性能测试环境。生产中的测试是一个记录良好的反模式,但遗憾的是,这成为排查错误的一种常见方法;在生产中排查错误代价一般非常高,创建脆弱的环境常常导致负面的最终用户体验。

除环境之外,测试还需要测试团队、协调员、计划人员,并在可能时还需要有专用的硬件和网络。确定用例的团队通常为测试团队提供输入内容。测试团队然后采用这些用例,构建测试脚本并执行测试计划人员制定的测试计划。系统管理员提供测试环境的相关管理任务,以确保尽可能接近地模仿生产环境。

有关性能测试的信息,请参阅参考资料

版本控制

企业中的每个组件都有版本控制,它是更具挑战性的管理任务之一。在某些情况下,已经计划了版本控制;例如,预期在三个月内发布的应用程序的新版本。在其他情况下,版本控制是没有计划的,有时是在紧急情况下执行的;例如,在向操作系统或应用服务器应用修复程序时。强有力的版本控制流程可以保证生产环境的完整性。

由于存在版本渐变的事实,因此,应尽一切努力尽可能保持环境之间的一致性。差别越少,管理员需要记录的特定于环境的信息就越少,这样可以在大型拓扑中充分管理所有环境。不过,对于管理员工作而言,管理员一开始就需要了解有关每个环境中部署了什么内容以及更改了什么内容之类的信息,这就谈到了下一个主题:更改控制。

更改控制

更改控制以及围绕更改控制的流程可以帮助企业成功管理大型拓扑环境。系统性更改控制流程,从开票到个人审核再到工作通知和最后到打包的应用程序解决方案是管理更改的最好方法。为了节省资金尝试结合使用电子表格和非集成式工作流通知机制(例如电子邮件)不能提供必要的控制。

  • 备份策略

    备份是一项关键的更改控制功能。在进行任何更改之前,创建备份环境然后在还原的操作环境中测试来验证备份是否损坏至关重要。最让人痛苦的极端情况是物理服务器崩溃并发现备份不能用,然后不得不从裸机开始重新构建环境。

  • 库存

    任何更改控制流程的先决条件都需要有最新的硬件和软件库存。正确的 IT 库存可以在发生问题和在需要应用更新或修补程序时帮助评估风险。库存应涵盖整个 IT 基础设施,其中包括:

    • 生产系统
    • IP 地址
    • 修补程序状态
    • 修补程序级别
    • 漏洞
    • 修补程序的物理位置
    • 修补程序的管理人
    • 修补程序的功能。

硬件版本控制

理想情况下,大型拓扑环境中的所有硬件都从一个主映像构建。在需要对硬件应用修补程序时,主映像也会更新。这样,可以将新硬件仅作为其他计算机的副本引入环境。

软件版本控制

软件版本控制存在许多方面。无论软件版本控制对环境的影响如何,软件版本都应在测试环境应用一段时间。修补程序首先应在开发测试环境中应用(也可能在将更改引入开发之前,在用于测试更改的系统管理计算机上应用)。在通过测试并认为可靠之后,可以将更改移动到系统集成测试环境中,接着移动到性能测试环境,然后移动到 QA 和过渡环境,最后到生产环境。当然,必须在每个阶段通过测试才能进入下一阶段。这一过程可能需要数天到数周的时间,具体取决于更改的范围以及在各个测试阶段是否遇到了问题。

应给予安全修复程序最高的优先级;这些修复程序应被视为“热修复程序”。当供应商发布安全修复程序警告时,不但管理员要了解此安全威胁,而且尝试利用此类漏洞的人员也要了解该问题(如果他们尚不知道)。

  • 操作系统

    操作系统需要定期更新。可以计划操作系统级别的修复程序,并应作为年度化项目规划的一部分存在,至少应每季度一次。

  • WebSphere Application Server

    WebSphere Application Server 相当于一个操作系统,它为应用程序提供功能。像一个操作系统一样,应在全年中定期部署更新。当然,在每个最新更新可用时就立即部署并不可行,但至少应每六个月执行和完成更新周期;最好是每季度一次。不过,由于应用程序和应用程序服务器之间的一些独特交互,有时应在计划之外应用一些热修复程序。

  • IBM 堆栈产品

    有些 IBM 产品安装在 WebSphere Application Server 上,如 WebSphere Portal、WebSphere Process Server、WebSphere Enterprise Bus 和 ITCAM for WebSphere 等等。IBM 堆栈产品的管理方式应与任何其他第三方供应商应用程序的管理方式相同。

    请记住,IBM 堆栈产品对 WebSphere Application Server 的版本要求越来越严格;一种产品可能需要 V6.0.2 fixpack 11,而另一种产品可能需要 fixpack 21。如果堆栈产品位于同一个共享环境中,这可能给管理带来困难。与此类似,堆栈产品的主要版本更新(例如从 V6.0 更新到 V6.1)可能会同时对堆栈产品和 WebSphere Application Server 级别造成明显更改。将堆栈产品隔离在它们单独的计算单元中可能是需要采取的一个较好步骤,但是,除非涉及高容量需求,共享物理资源通常更可取一些。

  • 应用程序

    无论“应用程序”在您的环境中是如何定义的,但通常有两种类型的应用程序更新:计划内版本更新和计划外热修复程序。在项目计划中准备和安排已知候选版本涉及到开发与操作团队之间的沟通。此外,WebSphere Extended Deployment 提供的功能还可以帮助管理生产环境中的应用程序版本(请参阅参考资料)。

  • 服务版本控制

    部署并向应用程序提供的可重用服务在不断更改。当发生更改时,您必须考虑对可重用服务的更改以及这些更改对使用该服务的每个应用程序的影响。这些更改可能是:

    • 行为更改:必须作出业务决策来实施行为更改。如果此服务的客户端对企业非常重要,则服务中的更改需要重新测试客户端的功能。
    • 引入新接口:不对现有接口引入行为更改的新接口通常不需要由客户端进行彻底测试。当然,如果服务的性能特征由于新接口而发生更改,则需要由非常重要的客户端重新测试性能。
    • 弃用或删除旧接口:这是一个很难实现的事情,特别是在企业中已经提供服务,而服务提供商实际上并不知道其客户端的环境中。

堆栈组件侦听

在考虑应用程序共存时,一些堆栈组件的侦听条件可能是一个重要因素。与购买每个应用程序并安装这些许可“应用程序”本身的副本相比,使用共享许可驱动程序的应用程序可以让您节省大量的成本。此类“应用程序”的范围可以从堆栈产品到企业的应用程序和服务使用的小型运行时库。

可靠性和糟糕的应用程序

可靠性是任何生产环境的圣杯。“糟糕的”应用程序在任何生产环境中都可能造成严重破坏,而在大型共享拓扑中造成的问题尤其明显。因此,对可用资源有某种负面(坏)影响的任何应用程序应从常规生产环境中隔离出去。从高 CPU 和内存需求的角度看,高容量应用程序比较糟糕。

在部署到生产环境之前,使用性能测试应用程序确定哪些应用程序比较糟糕是一个正确的方法。另一种方法是不经过测试就将应用程序部署到生产环境,当然这种方法会问题百出,因为这种应用程序必定会造成生产问题。

在能够管理大型拓扑环境并提供稳定性之前,您必须能够深入到应用服务器并监视应用程序是如何运行的。每个生产环境和性能测试环境都必须具有某些应用程序监视策略,并应使用一些监视工具,如 ITCAM for WebSphere。有关应用程序监视的详细信息,请参阅参考资料

打包和部署

打包应用程序 EAR

尽管一般不考虑打包应用程序对共享环境的影响,但是,如果将应用程序打包或以奇怪的方式部署,则打包在某些环境中会造成一些问题。打包应用程序的常见做法是将所有代码组件、模块和库打包在同一个独立的 EAR 文件中。以此方式打包的应用程序更便于部署和管理。应用程序套件应作为多个 EAR 文件进行部署。(如果对接口进行更改,您可能会遇到服务版本控制问题,但这超出了本文的范围。)

多个部署单元

不作为独立 EAR 文件部署应用程序的一个常见问题是,管理员所拥有的所谓“多部署单元”需要作为单一组件进行管理。多部署单元的复杂性可能给管理员造成困难,因为它们一般是作为共享库(共享类加载器中的库)部署的。在这些库下部署的应用程序可能需要这些库的不同版本。当新版本应用程序需要的新版本库不向后兼容时,此方法就会遇到问题。在同一组库中作为多部署单元部署的任何其他应用程序现在也必须更新;该应用程序或者环境现在必须重新拆分。从管理方面而言,多部署单元难以管理,并且在引入新库版本时可能出现问题。另外,尽管可能对打包在单一 EAR 文件中的应用程序执行“热替换”,但此类多部署单元替换在实现起来要困难得多。

脚本

为满足业务需求,部署的应用程序可以提供自动和可重复的流程。脚本为应用程序和环境管理提供了相同的自动化和重复功能。在大型拓扑中脚本是必不可少的。由于脚本可以提供可重复的操作,即使是小环境也可以从脚本中获益。标准更改控制机制应该应用于脚本。在进入生产环境之前,还应该在开发、系统集成、性能、QA 和过渡阶段测试脚本。

资源脚本

最近对 JNDI 命名空间的更改之一是能够在环境(服务器、集群、节点或计算单元)的各个级别上界定资源定义的范围。在计算单元级别中,由于仅需要对资源定义一次并且每个应用服务器都可以看到它,因此界定所有内容似乎非常容易。但是,在大型环境中,在许多应用服务器不实际使用资源的命名空间中,这可能导致不必要的资源定义,即所谓的命名空间“污染”。这可能造成命名空间冲突,更有可能使 JNDI 问题的确定和解决更加困难。为避免命名空间污染,应在集群范围定义您的资源,并保持资源定义仅在实际使用这些资源的服务器中可视。

结束语

管理大型拓扑环境涉及大量的选择和相应的决策点。首次使用 WebSphere Application Server 或计划大型拓扑的组织可以使用本文指导未来的战略和规划。应对企业中不断增长的大型拓扑这一挑战的最好办法是花时间记录所有决策点和可接受的折衷方法。这些已经管理的大型拓扑可能会认可这里提到的一些折衷方法和策略。希望本文提供的信息能帮助您验证对这些环境所作的策略是否正确。还有人可能会发现其中一些信息为解决同一基本问题提供了另外一种方法。管理任何规模的拓扑(特别是大规模拓扑)的难题可以通过规划、主动预防措施和决策很好地解决,这与以被动的响应方式进行部署和管理不同。我们希望本文提供的内容能够帮助您按前一种方法积极主动地解决问题,而不是按后一种方法被动地响应问题。

致谢

作者真诚感谢 Paul Ilechko 和 Steve Linn 对本文提供的帮助。


相关主题


评论

添加或订阅评论,请先登录注册

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=WebSphere
ArticleID=295288
ArticleTitle=大型共享拓扑中的策略及折衷方法
publish-date=03172008