针对运行在 IBM Power Systems 服务器上 AIX 系统的企业级维护策略

系统维护在每一个企业中都发挥着至关重要的作用,可以确保支持能力和系统可靠性,最大程度地提高构成技术环境的服务的可用性。因为要考虑多个组件(IBM® AIX®、数据库、应用程序,等等),复杂的系统维护需求与服务水平协议 (SLA) 之间可能会产生冲突,但通过调整活动的时间表,可以降低计划内中断的频率。本文将了解将服务视为一个实体的重要性,并利用它创建企业维护策略,最大程度地提高系统的可用性。

Nathan Edwards, 高级顾问, Advent One

Nathan Edwards 是一名 IBM AIX 和 IBM PowerVM 专家,他居住在澳大利亚墨尔本。他的 AIX 虚拟化经验可追溯到 2001 年 IBM POWER4 处理器发布,一直到最新的高端 POWER7 处理器体系结构。



2013 年 6 月 03 日

引言

系统软件维护类似于 “绘画第四座大桥”(用于表示一直在持续、循环的工作)。在一轮更新结束的时候,就到了开始下一轮更新的时候。

在几乎每天都发布软件更新,而且平均故障间隔时间 (MTBF) 实际上就是在硬件中断之前的一种等待游戏的世界里,规划和修复的无尽循环中看起来很可能永远存在。

通常情况下,当涉及到技术时,闪电般快速的性能和全天候服务已无一例外成为一种期望。

等待鼠标点击的响应或等待脚本或作业完成都是令人沮丧的,系统不可用让人无法容忍。对于任何企业,这意味着必须向着正常运行时间的乌托邦进发,争取实现无缝的、即时的、无尽的可用性。

不论什么原因的中断都会带来一定的影响。“100% 正常运行时间” 的理想受到侵害,业务成本可以用大量金钱和声誉来衡量。

许多企业都依赖其 IT 系统,以致于长时间的断电可能会给企业带来可怕的后果。停机时间 一词具有不可思议的能力,让一个又一个月的正常运行时间 和​​可靠性都显得不那么重要。

在发生中断时,您可能立刻会想到是有些东西坏了、系统发生故障、应用程序崩溃等。在现实中,计划性中断在停机时间中占了相当大的比例,因此,应该尽可能地减少所有计划中的中断。

有很多文章已列出了系统维护的重要性,以及不解决这个问题的危险性。Anthony English 编写了一个很好的 示例

有时不太明显的是,我们不仅要管理 AIX 或 Virtual I/O Server (VIOS),还要管理服务 的各个部分,并考虑一些其他的因素。

本文将展开对其他 因素和条件的讨论,帮助定义一个针对 Power Systems™ 服务器上的 AIX 的企业维护策略。

该策略的主要目标是:

  • 尽量减少服务 的计划性中断
  • 通过周密的规划,提高系统的可用性

有效的企业维护

定义服务

IBM Power 服务器上的企业级环境由多个组件组成。典型的示例如下:

图 1:企业级环境示例
图 1

无论应用程序的功能是托管公司网站还是处理关键的夜间批处理任务,为了交付成果,每一个组件都是必需的。

就像没有发动机的汽车没有多大用处一样,没有汽车的发动机也难以发挥作用,如果 AIX 正常运行,但应用程序中断,功能也将受到影响。

每一个组件都需要进行与之有关的某种形式的维护,该维护可能与软件、硬件有关,也可能与两者都有关。大型组织经常让多个团队负责特定组件,从经验上讲,每个团队都有自己的维护策略,这并不少见。

这样带来的结果是,在全年的过程中,可能由于有多个维护时间表而造成服务被多个计划性中断的影响。

最大限度地减少计划性中断的次数,这样可以提高服务的可用性。为了实现这一点,每一个团队都需要将服务 视作一个实体,而不是将其视为团队管理的特定组件。

要为 Power 上的 AIX 开发企业维护策略(它解决关键目标),需要了解与每个组件有关的维护计划和时间表。其结果是根据特定的业务需要来组合或重新安排活动,以制定有限中断次数的时间表。

一个简单的示例

以下内容涉及到使用非常大型的 IBM Power 环境时会遇到的情况。

该环境包括多个 Power 服务器,每个服务器都运行多个 AIX 逻辑分区 (LPAR),以支持大量不同的业务部门。

影响 Power 服务器的计划性中断会影响多个业务部门,因此,非常难以安排中断。

每个应用程序所有者代表一个业务部门,该代表负责管理服务 的可用性。其中一个应用程序所有者代表该公司最大、最重要的应用程序,在某一个会议上,该代表特意强调指出,最近的一次中断包括以下中断:

  • IBM Power Systems™ 固件升级:完整的 Power Systems 停止/启动:中断 LPAR 和服务。
  • 应用程序发布:中断应用程序和服务。
  • AIX 更新:需要重启:中断 LPAR 和服务。
  • 数据库更新:中断应用程序和服务。

世界各地都在不间断地使用应用程序,计划内或计划外的任何中断都会产生显著的影响。

这促使其他应用程序所有者对中断对其服务的影响进行评估,得到的结果是类似的:有多个计划性中断,每一个都涉及到不同的组件。

在每一种情况下,在接到通知后,系统会要求应用程序所有者在短时间内停机,这让他们难以与业务社区进行协商。

一个综合策略的开始

没过多久,IT 服务经理就与技术团队安排了一次会议,讨论在今年余下的计划性中断。

随着会议的进行,有一点变得很明确:几乎所有团队都对影响服务的工作进行了规划,而且在大多数情况下,各团队之间是彼此完全隔离的。会议中设定了一个目标:设计一个基于日历的时间表,以规划服务核心组件的更新和维护。

在时间表中建立沟通,尽量提前完成针对中断服务的请求。这消除了在短时间内安排中断的无奈。

时间表具有一定的灵活性,使企业能够在 4 个月的窗口内为计划性中断选择一个合适的时间。

创建了一个年度性全系统停机窗口,将该停机窗口预留给 Power 固件升级或更换不支持热插拔的硬件(如处理器更换,等等)等破坏性的任务。应该只在有需要时才使用该停机窗口,但是,如果产生了停机的需求,则必须应付这类维护。

在可能的情况下,在维护窗口之前使用 PowerHA 故障转移最大限度地减少停机时间:集群的 LPAR 被 “故障转移” 到故障转移节点,使服务经历与故障转移有关的较短时间中断,而不是与维护相关的较长时间中断。从 IBM POWER6® 开始,IBM PowerVM® Live Partition Mobility (LPM) 成为让关键 应用程序保持正常运行时间的一个附加工具,因为它可以将 LPAR 从安排了维护任务的 Power 服务器中移出。

在制定策略后,就有可能为企业提供将多个组件整合到每年的单一计划性停机窗口,并理解如果因技术原因而应用修复,可能必须执行第二次停机。

附件的电子表格中定义了面向 Power 上的 AIX 的企业维护策略:

下载电子表格

电子表格从最上面一行开始,从 1 月开始,一直到 12 月。

列 A 包含共同形成服务的组件,以及贯穿全年发生的活动的时间表。为了最大限度地减少组件数量,AIX Image PackagingDelivering AIX Package 中包含了其他软件(如 PowerHA)。

维护策略包括在企业环境中管理服务可用性的重要方面:沟通的周期、修复的评估、更新的测试和打包,以及最后的部署。

已知的破坏性停机被定义如下:

  • Power Systems 停机,2 月是计划的惟一一个破坏性升级,所执行的必要任务需要中断 Power 服务器。例如,破坏性的固件升级,但优先执行并发更新。计划的破坏性中断也是修正全年中所发生的非可热插拔 硬件故障(处理器故障,等等)的时间。
  • AIX 更新:Technology Level 更新和可能的服务包更新,可以选择与其他任何停机相结合。
  • 数据库应用程序更新:可以选择与其他任何停机相结合。
  • 应用程序更新:可以选择与其他任何停机相结合。

从 AIX 和 VIOS 的角度来看,该策略每年应用一个更新,而且有可能一年中出现第二次(服务包或重要补丁)更新。用户可以提前规划年中的停机窗口,但仅在从技术角度认为有必要时才这样做。

协调多个团队的维护活动,这意味着延长测试时间,为应用程序提供更灵活的基础。

发布企业维护策略也为业务社区提供了好处。每个业务部门都可以配合任何其他计划性停机窗口来规划自己的应用程序测试和发布。

在实施企业维护策略后,从企业的角度来看,基础架构很明显得到无缝的管理,而不再只是一个基于孤立的服务器组件的视图。

定义维护策略的过程

拥有企业维护策略的好处包括,通过组合维护任务提高服务的可用性,通过定期维护提高可靠性,以及积极提高负责管理环境的技术团队的能力。

本节将重点介绍帮助为 Power 上的 AIX 定义企业维护策略的流程和主题。

定义一个维护策略所有者

基于日历的时间表可能导致每月发生一个或多个活动。定义一个维护策略所有者(由管理层和业务社区支持他)可以确保时间表仍在正轨上。

维护策略所有者负责下列活动:

  • 确保提前与业务部门计划停机的问题。
  • 提前一个月与业务人员沟通,确认计划性停机所带来的影响。
  • 与技术团队保持联系,确保如期完成测试和打包阶段。
  • 跟踪每个服务和 LPAR 的更新进度,确保每个 LPAR 都按时更新。
  • 每年审查企业策略,使之保持相关性和可实现性。

规划现实的场景

在制定策略时,应考虑与 IBM AIX 发布策略有关的业务需求。

IBM 每年发布一个 AIX Technology Level,每年大约发布 4 个服务包,AIX Technology Level 可获得三年的补丁。

请参考 AIX 发布和服务交付策略,了解有关的更多信息。

作为指南:

  • 每年至少计划一次停机,并认识到其他停机有时是不可避免的
    保持现实:影响任何一个关键组件(AIX、数据库、应用程序和固件)的紧急重要补丁可能需要在收到通知后的短时间内被应用到环境。
  • 告知 “更多正常运行时间” 比请求 “更多停机时间” 更容易
    这是很重要的!如果决定不必再有年中的计划停机,可以根据时间表提前与业务进行沟通。
  • 将计划性停机视为提供稳定性的一个重要部分
    在某些情况下,必须安排停机时间,以执行计划中的破坏性软件维护,并更换非预期的故障硬件。随着共享的基础架构变得更复杂,对可管理的维护策略的需求也在增加。

沟通是至关重要的

  • 为已知的服务中断定义中断窗口,并提前沟通
    附件的电子表格显示,计划性中断是提前 6 个月安排的,其中有 4 个月的窗口来计划中断的日程。例如,在 6 月将通信发送到每个业务,让他们选择在次年 4 月至 7 月之间的任意时间执行中断。

    有些业务选择一次过更新一切(每年一次计划性中断),而其他业务部门为需要单独更新的每个组件规定在单独的停机要求。让每个业务部门进行选择,并且他们理解同时更改多个组件时会增加与问题分析有关的复杂性。

    提前规划也可以协助调度技术资源来执行维护。对于试图在星期五下午找到技术资源并在周六执行升级,这并不是一个提前规划!

    主动遵从维护战略可以让技术环境保持一致(一切都在同一软件水平上实现)和最新(由供应商支持)。
  • 为潜在的服务中断定义中断窗口,并提前进行沟通
    电子表格显示了一个用于年中服务包更新的窗口,它被定义为应用计划外的补丁。

    在年中服务包更新之前的一个月,评估是否必须中断。在不需要服务包或关键补丁的情况下,提前一个月向企业发送不必中断的通知。

    同样,告知企业请求 “更多正常运行时间” 比请求 “更多停机时间” 更容易。

企业组件的测试和打包

  • 打包 VIOS、AIX 和数据库组件
    维护策略应包括用于扩展测试和彻底测试的时间。这可以通过减少技术问题提高对解决方案的信心,并通过在测试 LPAR 上调优、排练和自动化更新流程来最大限度地减少停机时间。
  • 主机总线适配器 (HBA) 和以太网微码:
    虽然经常被忽视,但将适配器微代码添加到维护计划中,可以确保针对供应商的互操作性矩阵进行定期检查,从而执行保障性修复和重要修复。
  • 实现 - AIX、数据库和固件:
    实现窗口被定义为实现以下任务:
    • 实现必要的更新,并且让每个企业可以选择组合使用组件来减少计划性中断的次数,或者为每个组件安排单独的中断。
    • 引入一个严格管理的环境。在定义和遵从维护策略后,通过确保所有服务都在所定义的受支持 水平,让技术环境可以作为一个整体接受严格的管理。管理更少的软件水平所需的测试和开发时间会更短,因为需要测试的组合更少。

保持现实

  • 要认识到,会有一些例外情况
    一个或多个 LPAR 将不会获得更新,这是必然的,原因很多,比如应用程序代码将 LPAR 限制于特定的数据库或 AIX,或因为不可预见的商业原因,企业无法执行预先安排的中断。这些 LPAR 应作为例外 接受管理,可以用视图报告这种例外情况,以便尽快更新它们。

保持消息灵通

IBM 不断提高在 IBM Power 服务器上运行的服务的可靠性,频繁地为组件发布软件和固件更新,这些软件和固件包括 Hardware Management Console (HMC)、VIOS、AIX、PowerHA、Power 服务器、适配器微代码,等等。有些更新支持对特性进行更新,而另外一些更新则是修正已知错误。

定期检查可用的软件更新,对于有效的企业维护策略,这是一个重要的考虑因素,您可以利用 IBM My Notifications 订阅服务简化此操作。

该服务有多个配置选项,允许以适合您的频率接收与特定环境有关的主题更新。

例如,通过使用订阅服务,可以为特定服务器类型( Power 770、Power 780 等)的新系统固件设置每天或每周的电子邮件警报,还可以为特定的 AIX 和 VIOS 版本设置电子邮件警报。在有新的更新可用时,就会有电子邮件发送到您的收件箱里。

当 IBM 发布软件或固件时,通常会提供 “严重性” 说明(指示了该更新的重要性)和问题说明。

需要注意的事项如下:

首字母缩写解释定义
HIPERHigh Impact/PERvasive 应尽快安装。
SPESPEcial Attention 应在方便的时候尽早安装。修正不太可能发生但影响较大的问题。
ATTATTention 应在方便的时候尽早安装。修正不太可能发生、影响程度为低到中等的问题。

如有需要,请参考 定义的完整列表

您可以利用 IBM 在发布软件更新时提供的信息来评估您环境的风险,并了解定期维护中需要包括的更新。

请参考 My Notifications 网站


结束语

人们普遍承认,基于保障性和稳定性的原因,系统维护是管理环境的一个不可分割的组成部分。

随着对 IT 系统的依赖性越来越大以及可用性需求的增长,可以通过引入企业维护策略(其中包括服务组件)最大限度地减少中断次数和降低中断频率。

检查最新的软件和固件更新,这是企业管理策略的重要组成部分。IBM 通过提供对 My Notifications 订阅服务的访问,配置了一个简单的方法来获得与环境相关的最新信息,从而简化了这一过程。

利用 IBM PowerVM® Live Partition Mobility 将正在运行的服务迁移到备用 Power 服务器,这样做可以避免服务中断。高可用性解决方案可以在执行安排好的维护任务之前的很短的计划时间窗口内移动聚集在一起的 LPAR,从而减少计划内停机时间。这些因素可以纳入与您的环境相关的企业维护策略。

参考资料

条评论

developerWorks: 登录

标有星(*)号的字段是必填字段。


需要一个 IBM ID?
忘记 IBM ID?


忘记密码?
更改您的密码

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件

 


在您首次登录 developerWorks 时,会为您创建一份个人概要。您的个人概要中的信息(您的姓名、国家/地区,以及公司名称)是公开显示的,而且会随着您发布的任何内容一起显示,除非您选择隐藏您的公司名称。您可以随时更新您的 IBM 帐户。

所有提交的信息确保安全。

选择您的昵称



当您初次登录到 developerWorks 时,将会为您创建一份概要信息,您需要指定一个昵称。您的昵称将和您在 developerWorks 发布的内容显示在一起。

昵称长度在 3 至 31 个字符之间。 您的昵称在 developerWorks 社区中必须是唯一的,并且出于隐私保护的原因,不能是您的电子邮件地址。

标有星(*)号的字段是必填字段。

(昵称长度在 3 至 31 个字符之间)

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件.

 


所有提交的信息确保安全。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=AIX and UNIX
ArticleID=932411
ArticleTitle=针对运行在 IBM Power Systems 服务器上 AIX 系统的企业级维护策略
publish-date=06032013