通过处理器虚拟化实现技术和业务收益

因服务器 “可能” 需要处理器而为它分配专用处理器的时代已经过去了 — 至少应该过去了。微分区和共享处理器池 的 IBM Power™ 处理器虚拟化技术使从 CFO 到系统管理员的所有人都受益。企业可以回收超过一半的 CPU 容量，这会节约大量资金；同时，管理员只需几次鼠标单击即可添加或删除处理资源。本文介绍 University of Pittsburgh Medical Center (UPMC) 如何从专用处理器战略转换到虚拟化处理器战略，同时改进对最终用户的服务质量，从而实现财务和运营双重收益。除了收益之外，本文还解释了处理器虚拟化的风险和过程以及为管理这种动态环境而开发的工具。

简介

University of Pittsburgh Medical Center 是一家资产高达 80 亿美元的全球性医疗企业，它使用 IBM Power Systems 服务器和 AIX® 运行许多业务关键型数据库和应用程序。UPMC 在硬件和软件两方面都使用了 IBM 的最新产品，尤其是虚拟化技术。这包括 I/O 虚拟化 (VIO)、存储虚拟化 (SVC) 和 CPU 虚拟化。

Power 服务器上的微分区、共享和不封顶的 CPU 等技术已出现很多年了，且对该技术的使用限度随客户而有所不同。

UPMC 的所有 CPU 都放在共享处理器池中。通过最大限度地降低 CPU 标称（然而这对虚拟 CPU 设置比较激进），UPMC 在它的许多 Power 服务器上实现或接近了 80% 的 CPU 利用率。这差不多是虚拟服务器上行业平均值（据报告为 40% 到 50%）的两倍。

处理器虚拟化让 UPMC 能够在不增加成本的情况下非常快速、高效地提供容量。如果一个应用程序出乎意外地需要增加两个 CPU，处理器会立即分配 CPU 而无需人工干预。如果计划外的业务功能或应用程序需要联机，支持它所需的基础设施会在同一天得到创建。

Paul Sikora（负责 IT 改革的 UPMC 副总裁）说：“虚拟化的基础设施能够灵活地调整以满足处理高峰；工作人员可以更快地对 UPMC 的需求做出反应。我们的生产效率更高了，更敏捷，更可靠，而且成本更低。”

这种灵活性已经改变了 UPMC IT 专业人员的工作方式，让他们能够把时间和注意力集中于开发、服务改进和解决复杂的问题。CPU 供应不再是大事了；它是一个标准的过程。

UPMC 取得的重大技术和业务收益表明了其他人可能悟出的道理，即：该技术应发扬光大！

当然，CPU 虚拟化也会带来风险。本文讨论 UPMC 转换 CPU 战略的原因、取得的成果以及在管理这种技术时面对的挑战。

催化剂 —— 为什么要虚拟化？

UPMC 拥有 20 家医院、400 个门诊所、长期健康设备和一个大型保险计划。UPMC 使用大量型号不同的 IBM Power 服务器，从基于 POWER6® 的 595 到 BladeCenters®。大约三年前，UPMC 遇到了容量问题 — 由于业务增长加速，CPU 需求超过预期，CPU 不够用了。由于增长没有放慢的迹象，UPMC 工程团队需要找到一个能够用现有设备支持业务运营的解决方案。

这个解决方案就是采用微分区和 CPU 共享。在当时，我们很保守地使用了微分区，但是还没有采用不封顶特性。在发现容量问题之后的三个月内，UPMC 对 90% 的 LPAR 采用了不封顶设置，回收了 50% 的处理器。

配置

UPMC 拥有多种 Power 服务器，包括基于 POWER5® 和 POWER6 的 595、570、550 和 blade。本文主要讨论一台基于 POWER6 的 595，它有 56 颗 CPU。规格说明见表 1。

表 1. POWER6 595 规格说明

这台 Power 595 上驻留 60 个 LPAR。这些 LPAR 涵盖 UPMC 中的各种环境和应用程序类型。这包括 Oracle 数据库、应用服务器和 Web 服务器，它们提供一些对于企业最重要的计算功能。根据设计，UPMC 要把生产和非生产环境放在同一台服务器上，从而尽可能提高资源利用率。通过研究和了解应用程序工作负载的时间规律，UPMC 发现开发和测试工作负载常常出现在生产工作负载高峰之间。根据这一分析结果，我们认为把这些环境放在一起有助于实现更好的全天资源利用率。

另外，这个设计为负载水平变动提供了应变机制。当一台 Power 服务器的利用率接近它的最大容量时，UPMC 工程师开始寻找可以迁移到替代硬件的 LPAR，从而释放 CPU 和内存资源。当需要迁移时，让开发或测试 LPAR 在工作时间停机比安排在生产应用程序停机更容易。

监视、警报、调整、重复

在虚拟化环境中，比较有挑战性的任务之一是监视和警报。如果在有 56 颗 CPU 的服务器上将 LPAR 配置为使用 210 颗 CPU，那么当利用率达到 56 时应该怎么做？答案很简单：不要让它达到 56 。

UPMC 使用一套工具和技术确保任何 Power 服务器上的 CPU 利用率不会接近最大可用 CPU 数量。它开发和应用了大量虚拟监视器和自动化警报工具，帮助确保总是有容量可用。

UPMC 使用 Ganglia 监视它的 Power 和 AIX 基础设施。尽管这个工具的基本功能非常强大，但是 UPMC 决定进一步定制它，“围绕” Ganglia 及其他容量和性能监视工具开发了自己的 Web 门户，让它们能够创建定制的视图。它为 UPMC 提供的众多视图之一是 Power Server Overview。这个概况视图显示所有 UPMC Power 系统的服务器级 CPU 利用率。图 1 显示 UPMC 的一台 Power 595 服务器上的典型 CPU 利用率。

图 1. Power 服务器概况

查看原图（大图）

创建这个视图的原因之一是为 CPU 利用率建立缓冲、警告 和危险 阈值。这些阈值都是软限制，都与 Power 服务器概况 视图和 UPMC 的自动监视和警报解决方案相关联。

缓冲阈值

在 UPMC，“缓冲” 是 CPU 利用率的一个逻辑阈值，它向 Power 服务器管理员和 UPMC IT 管理层表明服务器满负载。换句话说，如果 CPU 利用率经常达到缓冲阈值，就认为服务器满负载了并禁止构建新的 LPAR。留出 20% 的 CPU 以应对预期的利用率波动。这些使用量波动是某些业务过程造成的，比如月底的结帐和报告。除了应对常规的业务周期之外，留出 20% 还可以让 LPAR 处理器在出现计划外负载增加时有增长空间。

警告阈值

当 Power 服务器利用率略微超过缓冲阈值时（准确地说，超过两个 CPU），就会触及警告阈值（在图形上没有显示）。这个事件触发一个警报，这个警报自动进入 UPMC 事件管理系统，进而通知所有 Power 服务器管理员。

应该检查警告，但是不一定要采取措施。受过培训的管理员会在服务器触发警告之后密切监视它。管理员会检查一个或多个 LPAR 上是否出现了 CPU 利用率快速增加的趋势。希望 LPAR 只是偶尔出现高峰，因此导致 CPU 利用率超过缓冲阈值并达到警告阈值。但是，如果管理员发现利用率增加的趋势是持续的，就需要采取进一步的措施。这些措施包括：

联系使用这个 LPAR 的应用程序团队，了解是否增加了新的进程或负载。查明是否可以减少负载。

登录 LPAR 并搜索失控的进程。如果找到了，就停止或调整有问题的进程。

把这个 LPAR 迁移到利用率低的 Power 服务器上。

临界阈值

当 Power 服务器处理器利用率大于或等于可用物理处理器总数的 88% 时，一个危险警报自动进入 UPMC 事件管理系统并通知所有 Power 服务器管理员。

临界警报需要立即采取措施。受过培训的管理员把这种警报看作紧急情况，会采取适当措施降低 CPU 利用率。如果警报的原因是一个或多个 LPAR 出现短时间负载高峰，系统常常可以自己处理。但是，与警告警报一样，UPMC IT 人员会与 LPAR 的用户联系，了解使用量超过正常水平的原因。

如果 CPU 利用率长时间保持在临界阈值水平，而且没有下降的趋势，就应该关闭不重要的生产 LPAR 及其进程，从而防止 Power 服务器达到 100% CPU 利用率。

分析警报

Ganglia 门户（见图 2）是对 UPMC 的 CPU 警告和临界警报进行分析的首选工具。原因很简单，它可以在几秒内提供 “Server to LPAR” 视图。更具体地说，在 Ganglia 屏幕上，可以简单看到整个画面中每个 LPAR 使用的物理 CPU 数量。

图 2. Ganglia cpu_used 视图：服务器级

这个简单的视图的效果非常好，有助于很快地找到问题。Power 管理员可以快速地查明哪些 LPAR 的 CPU 利用率增加了，哪些没有。了解这些信息之后，可以使用其他工具判断造成利用率增加的原因。

权值的作用

权值是一个与不封顶 CPU 结合使用的设置。当有多个 LPAR 争用可用的处理周期时，虚拟机监控程序根据权值分配这些周期。权值越高，LPAR 获得的周期比例越大。

尽管 UPMC 使用权值（见 表 2 和 表 3），但是并不依靠权值确保 LPAR 的服务水平。UPMC 只是考虑到允许 Power 服务器上的所有处理器都被占用太危险了，因此让虚拟机监控程序根据权值分配处理器周期。

多个共享处理器池

到撰写本文时，UPMC 的实验室仍然在测试多个共享处理器池特性。这种技术看起来有助于 UPMC 改进使用共享处理器的方式。UPMC 没有非生产 Power 服务器。生产、测试和开发 LPAR 在所有 Power 服务器上混合部署。当 UPMC 实现多个共享处理器池时，它将集成在生产环境中。因此，必须先在实验室环境中进行非常仔细的规划和充分的测试。

标准：确保系统不失控

随着虚拟化成为 UPMC 中的常规活动，对虚拟资源的请求越来越常见。当内部客户认识到实现请求是多么简单之后，构建 LPAR、添加 CPU 和内存等请求成了家常便饭。业务实践方式的这种变化暴露出 IT 部门的一个弱点：对分配多少资源和分配给谁缺乏控制能力。随着资源日益紧张，分配决策的制定越来越困难，显然必须开发新的过程来增强责任意识。

这一需求催生出了新规则和新文档。这包括 CPU 和内存的预算模型、标准文档（详细描述客户会得到什么以及谁负责支持它）等许多内容。

Power AIX 管理员设计了他们的 Gold Image LPAR 并编写了文档（表 2 和 表 3）。这定义了 “模板” LPAR 和其他标准，大多数客户在请求构建新的 LPAR 时会默认接受这种标准的 LPAR。这意味着，除非通过应用程序规模审查 发现需要更多资源，一般情况下使用标准的 LPAR CPU 设置。

表 2. Gold Image CPU 设置

表 3. Gold Image 权值设置

通过使用 Dynamic Logical Partitioning (DLPAR)，可以经济高效地对每个 LPAR/应用程序进行 load and see 基准测试。如果 UPMC 标准 LPAR 模板无法满足应用程序的 CPU 需求，Power 管理员可以在发现需求后的几分钟内通过 DLPAR 简便地在 LPAR 中添加更多资源，确保分配适当的 CPU 数量。

通过应用这种 CPU 规模调整方法，UPMC 发现许多应用程序并不需要应用程序所有者或应用程序厂商最初请求的 CPU 资源量。建议的资源量常常超过实际需要量 30%。CPU 虚拟化很适合应付这种情况，因为它允许管理员灵活地配置虚拟 CPU 设置，不需要把应用程序可能根本不使用的资源与应用程序绑定在一起。

结束语

人人都知道 Power 处理器虚拟化有许多好处，包括提高利用率、降低成本和提高灵活性。但是，这种技术的限制不太为人所知。这些限制有多严重？到什么程度会抵消掉收益？

UPMC 仍然在研究并与 IBM 探讨这些问题。无论最终答案是什么，目前已经确定运行共享的不封顶微分区处理器环境是正确的选择。

显然，需要以全新的方式管理 CPU 资源。定制的监视和警报是关键：知道您有什么，充分使用所有资源，避免资源耗尽。

后续努力方向

处理器虚拟化只是 UPMC IT 转换计划的一小部分。UPMC 还在几个方面使用了虚拟化，包括存储 (SVC) 和 I/O (VIO)。这显著降低了 IT 成本并提高了效率。

以后要采用哪些技术？Active Memory Sharing，它支持在多个 LPAR 之间共享物理内存；高级的虚拟监视系统，这让 UPMC 能够查看所有虚拟和物理设备之间的关系，包括服务器、磁盘、网络、电源等等；以及我们最喜欢的 Live Partition Mobility。在 2008 年，UPMC 把 400 个 LPAR 从基于 POWER5 的服务器迁移到了基于 POWER6 的服务器，每次迁移需要不到一小时的停机时间。在 2011 年，UPMC 还要再做一次迁移，到那时根本不需要停机了。

UPMC 和 IBM 建立了战略伙伴关系，利用他们各自的经验共同为医疗行业开发和推广新技术。