WEB开发网
开发学院数据库DB2 DB2 最佳实践: 使用虚拟化来提高数据服务器利用率... 阅读

DB2 最佳实践: 使用虚拟化来提高数据服务器利用率和对数据服务器的管理

 2009-11-05 00:00:00 来源:WEB开发网   
核心提示:内容提要本文描述了在 IBM System p 上部署 IBM DB2 Version 9 产品的最佳实践,当你在 System p 平台上运行 DB2 产品,DB2 最佳实践: 使用虚拟化来提高数据服务器利用率和对数据服务器的管理,选择合适的混合虚拟功能和它们的配置达到商业目标,同时提高 IT 资源的利用率是一个很大

内容提要

本文描述了在 IBM System p 上部署 IBM DB2 Version 9 产品的最佳实践。当你在 System p 平台上运行 DB2 产品,选择合适的混合虚拟功能和它们的配置达到商业目标,同时提高 IT 资源的利用率是一个很大的挑战。可以达到的商业目的是减少管理、电力、冷却、或者室内面积成本、巩固数据库服务器。例如通过优化 DB2 产品性能来增加资源利用率、增加处理器利用率、分享系统资源、在不重启的情况下使用动态资源分配,以及使用工作负载管理。

本文描述了 System p 的主要虚拟化技术,关注选择的逻辑分区类型,磁盘 I/O,和网络接口,都是工作负载管理。以下简要描述的主要考虑因素,在本文中讨论了在这方面的主要考虑以及它们如何能够让你的业务受益。

逻辑分区类型

由于基于预测的活动高峰值,大多数硬件系统严重的利用率不足,今天的企业不断面临的挑战是使系统处理器的平均使用率更高以最大化投资回报率(ROI)。企业能高效巩固多个数据库共存在不同的物理服务器,或者在单台物理机器上共享处理器分区上的专用分区。这共享了处理器资源,平衡了高峰和平均操作情况下的处理器请求,降低总的拥有成本(TCO)。可以为每一个处理器分区分配服务质量来保证在较低优先级的工作负载可以获得最优基础资源时,更为重要的工作负载在需要的时候总能得到处理器资源。在不同的共享处理器分区处理测试和生产应用程序,也能有助于提高测试结果质量像测试环境如实的模拟生产环境。

磁盘 I/O 类型

对于创建多个共享分区的能力,如果给每个逻辑分区分配一个专用的 I/O 槽(每个分区有分数的权利)这可能耗尽这台机器的所有物理槽。同样,在很多有多个数据库都是逻辑分区的生产环境,在多个应用程序之间 I/O 性能需求变化非常明显。在这种情况下,虚拟 I/O 服务器(VIOS)在多个应用程序间启用共享磁盘适配器和 I/O 资源,以优化整个存储架构的利用和满足各种性能需求来最大化 ROI。VIOS 功能也提供额外的附加能力,像动态分区迁移(Live Partition Mobility)- 一个 POWER6 处理器家族的功能 – 允许没有任何应用程序停机时间的情况下把一个正在运行分区从一个 POWER6 服务器移动到另为个 POWER6 服务器,结果就是更好的系统利用率,提高了应用程序的可用性和节约了能源。

网络类型

类似于已经提到过的共享存储的理由,VIOS 同样管理共享网络适配器,也在一个系统中多个分区间共享网络带宽。这同时最大化了系统资源利用率和 ROI。

在工作负载管理上的考虑

该类型的工作负载管理能力有 System p 虚拟技术,这对于企业管理客户关系(CRM)或在正常时间的强化 CPU 批量作业的工作负载和高峰时间的事务系统的 CPU 活动非常重要。这些能力同样适用于类似零售的行业,它们通常在一年中某些特定的日子对数据系统要求常高,像在感恩节后的第一天或者圣诞节后第一天,比起其他日子。有效的工作负载管理最大化了系统资源利用率和 ROI,同时降低了 TCO。

在把它们在你生产系统中实施之前,在你的测试系统中实验这些最佳实践指导。

介绍

虚拟化是一个广义的概念包含一批服务器部署和管理功能。根据定义,虚拟化是用于抽象一个系统资源的物理特征的技术,与其它系统、应用程序、或者用户与这些资源的互动。

虚拟化非常有用,因为你可以用它让一个物理资源被看作多个逻辑资源,或者多个物理资源被看作一个逻辑资源;例如,一个处理器内核可以被看作多个虚拟处理器,或者为了增加可用存储空间的使用率多个存储设备可以统一到一个逻辑池中。因此虚拟化让服务器的部署和利用更加富有弹性。你也可以通过虚拟化来巩固服务器以减少管理成本、电源、和面积。作为附加的好处,你能使用虚拟化明显的增加服务器利用率并提高整体性能效率。

这个 DB2 最佳实践文章描述了如何选择正确的 System p 虚拟化功能和配置组合来帮助你达到你所期望的商业目标(除非另有说明,DB2 版本 9 包括了 DB2 版本 9.1 和 DB2 版本 9.4)。

本文在一下范围提供了指导:

了解在一个虚拟环境中 DB2 性能和扩展性

在 System p 上使用高级 Power 虚拟化

通过考虑下面两个主要因素来为你的 DB2 环境选择正确的虚拟化方法:

逻辑分区类型

磁盘 I/O 类型

网络类型

工作负载管理

计划和评估

作为其他的虚拟技术,如 VMware ESX 和 Windows Hypervisor,在以后变得可以利用,本文将扩展合并最佳实践以适用于它们。需要提醒的是,在本文中出现的概念和技术主要适用于 Systme p 平台。

DB2 9 和 System p 虚拟化概要

System p 虚拟化技术在硬件和固件上提供了丰富的虚拟化功能实施。这些功能范围从简单的资源隔离到一组最先进和强大的功能,包括服务器资源分区,自动化动态资源重分配和工作复杂度管理。IBM System p 家族服务器已经在多个 IBM POWER 处理器家族中的多款处理器和多个支持的操作系统上逐步提供了虚拟化的功能。现在 System p 平台拥有成熟、完善的服务器虚拟化功能。

不像传统的宿主环境,操作系统实例控制了服务器的所有的硬件资源(例如,处理器,内存,和 I/O 设备),虚拟化,以它的基本形式,允许服务器资源分区(逻辑分区)。虚拟化是由于一个被称为 IBM POWER Hypervisor(PHYP)的层而成为可能的,PHYP 向共享处理器分区的操作系统提供了一个系统硬件资源的抽象的视图。

虚拟化功能,比如 IBM Micro-Partitioning、虚拟 I/O(VIO)、还有虚拟以太网,通过提供价值的方法,例如资源共享、工作负载管理、和不需要操作系统实例重启的动态资源分配(动态逻辑分区),VIO 让你只需要少量命令来完成存储分区和共享 。在分区环境中运行,VIO 也可以通过提供一个集中的焦点来减少存储管理开销。DB2 产品与 VIO 工作不需要任何额外的包或者驱动安装。

System p 硬件支持 IBM AIX,IBM i,SuSE Linux Enterprise Server(SLES),和 Red Hat Enterprise Linux(RHEL) 操作系统。本文主要集中在 AIX 操作系统,但是你能把相同的指导微调或者直接扩展到其他支持的基于 POWER 处理器操作系统。

DB2 9 数据服务器是 IBM 提供的增长最快的旗舰级数据库。它装备了主机动态资源认识,自动化功能像自调整内存管理(STMM)和增强的自动存储,它们极大的减少了在调整和维护方面的管理开销。这些功能使 DB2 产品可以很好的匹配虚拟化环境,使它能够利用 System p 虚拟化技术。

DB2 产品在 System p 虚拟化环境中无缝的工作。DB2 识别并对任何 LPAR 事件做出反应,比如运行时更改技术按和物理内存资源的主机分区。STMM 功能自动化地判断并重新分配 DB2 堆内存以应对分区内的内存和工作负载情况的动态改变。

你能从‘参考资源’部分的列表中的很多网站中获得额外信息。

虚拟化术语和概念

这个章节主要描述了虚拟化组件和功能并提供虚拟化环境的快速参考。读者如果熟悉虚拟化术语和概念,可以略过这一节。

术语
描述
逻辑分区(LPAR)或分区
一个逻辑分区是一个隔离的计算域,有自己资源(处理器、内存、和 I/O接口)和操作系统实例。受支持的操作系统包括 AIX,Linux(RedHat,SLES),he IBM i操作系统。每个 LPAR能运行不同类型、版本或级别的操作系统。例如,在一个 LPAR中可以运行 AIX5L v5.2,第二个 LPAR能运行 AIX5L 5.3 TL06,第三个 LPAR能运行 AIX 6,第四个 LPAR能运行 Linux操作系统。

除了处理器和内存资源,每个 LPAR需要有它自己的根磁盘,网络接口和存储。这有一个方法可以通过虚拟 I/O来简化并共享网络和存储适配器,在后面会后更多细节。

有两种类型的 LPARs:

专用的处理器

共享处理器(使用 IBM微分区功能)

  
动态逻辑分区(DLPAR)或动态重配置
DLPAR服务让你在运行时可以更改一个分区的资源,无需重启操作系统。例如一个你可以更改的条目是专用分区的处理器数目;虚拟处理器的数目和共享处理器分区的能力;以及任何分区类型的虚拟 I/O适配器槽的数目和物理内存总量。DLPAR功能通过尽量分配它们需要的资源提高了资源利用率。
你能通过硬件管理控制台(HMC)手动访问这个工具,或者你能使用工作负载管理工具自动化地访问。DLPAR服务是工作负载管理工具的精华,类似 IBM企业工作负载管理(EWLM)。
  
POWER 管理程序(PHYP)
PHYP像是系统硬件和 LPAR之间的提取层,允许多个操作系统运行在基于 POWER处理器系统。PHYP是 IBM虚拟化技术的核心组件,它允许微分区、共享处理器池、动态 LPAR、虚拟 I/O、和虚拟 LANs。在 PHYP运行的许多任务中通过 LPAR上下文切换来保存和恢复所有处理器状态信息。
专用处理器分区
一个专用处理器分区 PHYP为它排他的保留一个或多个分配的处理器。(你可以指定处理器每次递增一个)当这个分区活动的时候其他处理器不能使用空闲的处理器能力。PHYP使用相同的物理内核来安排分区以从活跃的高速缓存中获得好处。

通过处理器和内存亲和力专用处理器分区可以提高 LPAR吞吐量,并确保最高处理器的高速缓存层次性能。这个功能应用在了 POWER5[1]处理器家族。
  
共享处理器分区
你能以每次增加 1/100或 1%物理处理器来把处理器能力分配给一个共享处理器分区。但是每个分区最小需要每次 1/10或 10%物理处理器能力。结果就是一个物理处理器最多能有 10个分区。

共享处理器分区需要 IBM高级 Power虚拟化(APV)功能和使用 IBM微分区功能。
  
赋权能力
赋权能力取决于处理器分配给共享处理器分区的能力

这个能力保证了处理能力的总量。PHYP把物理处理器时间切片以管理零碎的处理器分配。
  
受限共享处理器分区

赋权能力是对受限共享处理器分区的硬限制(也就是说,当需求增高的时候它也不能超过它的赋权能力,即使共享池中有闲置的处理器能力可用)。受限共享处理器分区让你可以更好的管理共享池处理器资源。
  
非受限共享处理器分区
一个非受限共享处理器分区不仅能使用它自己的赋权能力也能使用共享池中的空闲处理能力。当一个分区需要超过他自己赋权能力的时候,空闲共享池处理器能力在高峰时间即时满足工作负载需求。非受限共享分区对于不可预知的工作负载非常灵活有用。
如果非受限共享处理器分区不止一个,共享池处理器能根据它的分配非受限权重来分配给共享处理器分区
  
非受限权重
非受限权重是一个数字,在有不止一个超负荷的共享处理器分区的时候,通过指定共享池空闲处理器能力的一部分(平均权重)来分配给一个共享处理器分区。

非受限权重是 0到 255之间的一个数字;默认的非受限共享权重是 128。权重越高就有越多的空闲共享池处理器资源授予,根据分区工作负载优先权,你能给多个共享处理器分区设置非受限权重,为最高优先级的工作负载设置最高的非受限权重。
  
虚拟处理器
这个概念只和共享处理器分区有关。一个虚拟处理器是操作系统分派应用线程(或者进程)的实体。你能看到虚拟处理器如同一个传统的非分区环境中的处理器。

例如,假设共享处理器分区有 1.50赋权能力和两个虚拟处理器运行的 AIX 5L。AIX内核调度程序像他有两个物理处理器一样操作。假设此时多线程被关闭了,操作系统也可以同时调度最多两个线程。

你可以把虚拟处理器想成虚拟内核。SMT虚拟处理器的数目是自然的。
  
虚拟 I/O(VIO)
虚拟 I/O是一个广义的概念涉及到一批存储和网络虚拟化功能:

虚拟以太网

共享以太网适配器(SEA)

虚拟存储

虚拟以太网。不需要额外的硬件或电缆,在一个运行 AIX、Linux、以及其他的操作系统上的多个分区间上,一个虚拟的 LAN(VLAN)能实现高速虚拟以太网通讯路径。你可以动态创建虚拟的以太网段,并限定一个 VLAN段的访问来达到安全和通讯隔离需求。一个虚拟以太网有相同的特性像高速带宽、物理以太网络和支持多个网络协议,比如 IPv4、IPv6、和 ICMP。PHYP提供了这个功能。
虚拟 I/O服务器(VIOS)。这是一个专用分区,它向分区客户端提供了虚拟的 I/O资源。VIOS拥有物理适配器。你能通过把它分配给多个分区客户端来共享一个物理适配,这最小化了你每个客户端所需要的物理适配器的数目。因此,VIOS能通过减少网络和磁盘适配器的需求来降低成本。VIOS提供了两个主要的功能:

一个虚拟以太网桥。共享一台适配器(SEA)设在 VIOS 作为内部虚拟和外部物理网络的两层桥接。SEA 使分区和系统外部的通讯在没有专门物理 I/O 槽和物理网络虚拟器的情况下和客户端分区相连。

一个虚拟 SCSI适配器。是一个虚拟接口,物理存储(在这种情况下的设备支持)和逻辑卷(在这种情况下的逻辑卷支持),你从虚拟 I/O 分区创建和导出在客户端分区作为 SCSI 磁盘展现。


VIOS 需要 APV 功能

  
空闲共享能力
空闲共享能力包括总的可用于非受限共享处理器分区的空闲处理能力。你能通过增加为分配处理能力(即使它不能保证任何 LPAR使用处理器权利,或者凭借一个专用的 LPAR)来对所有系统中活跃的共享处理器分区的未使用权利求和以计算空闲共享能力的总量。

选择虚拟化功能

现在你已经熟悉了 System p 虚拟化概念,考虑如何在 DB2 环境中应用将虚拟化。关于虚拟化环境你必须做出四个主要决定:

逻辑分区类型:专用或者共享处理器分区

磁盘 I/O类型:本地连接的 I/O或者虚拟 I/O

网络类型: 物理或者虚拟

工作负载管理设置

某些情况下,后来再改变决定非常容易。例如,把分区类型从专用分区改成共享处理器分区非常简单。然而,在虚拟 I/O 和本地连接 I/O 之间切换磁盘 I/O 类型,则需要数据备份和恢复。因此,一个生产系统在上线之前需要有周密的计划。

注意共享处理器分区和 VIOS 功能不是标准虚拟化的一部分。这些功能是 APV 功能。

接下来的章节显示你如何才能把 System p 的主要虚拟化技术应用到你 DB2 环境中,以建立一个全面的 IT 架构能长期满足你所期望的商业目标。基本的假设是有在每个逻辑分区有一个单独的 DB2 产品实例运行,并且每个实例有一个数据库。最佳的结果、最佳实践、和这个章节的其他信息应该让你做判断的过程更容易。要用图形来展示这个结果,参考在“更多阅读”列表中的“DB2 和 System p 虚拟化”白皮书。

如果没有其他提示,接下来讨论的是, 分区意思指的是 System p 逻辑分区(LPAR)。不要把这个称呼同一个 DB2 数据库分区功能(DPF)创建的数据库分区混淆了。

逻辑分区类型

关于是否使用专用共享处理器这个问题,对于一个特定工作负载和系统环境的正确的逻辑分区类型有大量的因素需要考虑,比如性能、整个系统利用率等,并要考虑多个工作负载共存在一个服务器上,以提高电源使用和冷却效率。下面的子章节针对这些因素。

分区类型:专用处理器和共享处理器的比较

对 DB2 产品使用一个共享处理器分区。这种分区类型提供了很多好处,包括灵活性和更好的处理器利用率。

理论上来说,由于底层处理器和内存的关系,在某些条件下一个专门的分区应该提供最佳的性能。然而,最近这被确认在实际情况中并不正确。这部分的测试结果显示对于下面的测试系统(详细系统描述请查看附录)在专用和共享处理器分区之间没有明显的性能差异。表 1 是对这个测试环境的总结。


表 1. DB2 和 System p 虚拟化测试环境

  分区数目  
  1 2 4  
  分区类型 Partition type
分区类型
Partition type
分区类型
 
  专用 共享 专用 共享 专用 共享  
处理能力 8 8.00 4 4.00 2 2.00  
虚拟处理器 NA 8 NA 4 NA 2  
数据库大小 ~200 GB ~100 GB ~50 GB  
内存 128 GB 64 GB 32 GB  
数据磁盘数目 192 96 48  
I/O类型 本地连接 本地连接 本地连接

我们运行了 6 个性能测试:两个性能测试分别在一个单分区上、两个分区同时运行、和四个分区同时运行。我们对每一个分区类型和每一个分区都运行一次。分区类型的改变都是非破坏性的(没有数据丢失);唯一的要求就是重启分区。所有测试都使用本地连接 I/O,数据也在正确的规模。

结果显示在这两种类型的性能没有明显的不同。共享处理器分区的性能(也就是累计吞吐量)和专用处理器分区性能一样。这种情况验证了 PHYP 对共享处理器分区使用了非常有效的调度算法。对于这样的共享处理器分区,PHYP 尝试每次调度在同一个物理内核虚拟处理器上以保护处理器高速缓存亲缘性,类似于专用处理器分区的功能。

线性扩展性

使用共享处理器分区,你能因此得到它在增加处理器利用率方面的好处。

当我们在考虑我们测试中的每个逻辑分区平均吞吐量的时候,我进行了一次有趣的观察:对任何分区类型的分区扩展性没有任何开销。也就是 8 个专用处理器 LPAR(或者有 8.00 赋权能力和 8 颗虚拟处理器的共享处理器 LPAR)完成的工作总量是 4 处理器 LPAR(或有 4.00 赋权能力和 4 颗虚拟处理器的共享处理器 LPAR)的两倍,相反它又是 2 处理器 LPAR(或有 2.00 赋权能力和两个虚拟处理器的共享处理器 LPAR)。另外我们发现在专用处理器和共享处理器分区之间,每个 LPAR 的正常平均吞吐量没有明显区别。

通常的指导原则是不浪费分区中的处理器能力。这能通过对一个分区基于实施的虚拟处理器个数进行正确的评估来有效降低这个分区中闲置的处理器能力。这样做能在系统层面内提高物理处理器的利用率。

因此,专用和共享处理器分区在扩展性和平均吞吐量上已经相等,使用共享处理器分区可以获得提高处理器利用率的好处。

受限和非受限处理器分区

使用非受限共享处理器分区,在应付不可预知的工作量时非常有效。然而也要小心地使用它们:通过正确地设置它们非受限权重来设置分区优先级来管理工作负载。

共享处理器分区最大的特点是它能使用空闲处理器能力,加上它的授权能力。一个专用处理器分区在定义中设置了上限:那就是,它不能在分配的处理器上使用超过他授权能力,即使系统中有闲置的处理器能力也不能。如果使用正确,一个非受限共享处理器分区在处理高度动态和不可预知工作量时非常有效。非受限权重设置是用来在竞争非受限共享处理器分区间分配空闲共享能力。

例如,考虑一个由 DB2 服务器作为后端、IBM WebSphere 作为应用程序服务器的多层架构。它们都对它们自己在 System p 服务器上的非受限共享处理器分区做主。

由于它非受限全重设置得比 WebSphere 分区高,DB2 分区被分配了更高的优先级。在一个峰值需求范围内,两个服务器都超过了他们的授权能力并且被允许使用空闲共享的处理器能力(如果有的话)。然而,由于 DB2 有更高的非受限权重设置,他比 WebSphere 分区得到更多的空闲共享处理能力。

使用一个非受限共享处理器分区对动态、小粒度、和自动化的管理空闲处理器能力来应付一个虚拟环境中不可预知的工作负载。为了详细了解类似工作负载管理解决方案,这里提供了一个概念的证明,参考“工作负载管理”文章,在“更多阅读”章节列出了这些文档。

一个共享处理器分区中的虚拟处理器个数

为了最佳的平衡性能,设置虚拟处理器的个数不得高于每 1.00 授权能力两颗虚拟处理器。

为了最大化整个系统的处理器利用率,把虚拟处理器的个数设到可以达到可用授权能力的值。

使用共享处理器分区需要设置合理的虚拟处理器的数目。虚拟处理器较低的配置数会导致浪费处理能力或者不能使用空闲共享处理周期(一个非受限分区的最大授权能力收到虚拟处理器个数的限制)。虚拟处理器配置数目过高没有问题,因为在默认情况下 AIX 操作系统不会调度没有使用的虚拟处理器(参见 AIX schedo命令和 vpm_xvcpus配置参数信息)。我们做了一个测试来测量虚拟处理器的折叠能力,这是一个机制负责调度分区请求的最小数目的虚拟处理器,变化一个共享处理器分区(在表 1 中,一共有 4 个分区)的虚拟处理器数目,这个分区有 1.85 个授权处理器能力。在第一次测试中我们运行 3 次,把虚拟处理器设置到达到授权能力 2 的个数,然后在后来的测试中我们设置更多的虚拟处理器个数。的确如我们所期望的,相对更高的虚拟处理器数目并没有带来任何对性能的负面影响。

对于在 DB2 环境中的受限分区而言,设置虚拟处理器的数目等于最高授权能力。对于非授权分区,设置虚拟处理器的个数在下面公式结果范围内。

RVP = {round up (CEC + [UW/TUW] * FPC) , round up (CEC + FPC)} 

RVP显示虚拟处理器的最大范围。

CEC是当前授权能力。

UW是共享处理器分区的非受限权重。默认值是 128,并且范围是 0-255。

TUW是所有非受限共享处理器分区的非受限权重总量。

FPC是空闲共享能力(空闲未分配的处理器能力)。

例如,假设你有一个 16 核的 IBM POWER 570 系统。你创建一个有 4 颗处理器的专用处理器分区,而且你打算在剩下的 12 颗处理器上创建 6 个非受限共享处理器分区。你把非受限权重设为 128(默认值)。

为了运行 DB2 实例,假设你想创建了一个赋权能力是 2.5 非受限的处理器分区。请使用前面介绍的共识来判断你需要为这个分区分配的虚拟处理器的个数范围,如下面计算所显示的。简单来讲,假设所有分区都是非受限并拥有相同的非受限权重。

RVP = { round up (2.5 + [128 / (128 *6)] * (12-2.5)) , round up (2.5 + (12-2.5))} 
RVP = { round up (4.08) , round up (12)} 
RVP = { 5 , 12 } 

这未受限共享处理器分区公式计算了一个范围值在分配恰当的虚处理器的时候以供选择。这个范围横跨极端的工作负载目标:最佳平衡性能和最大整个系统处理器利用率。

一个一般的指导是基于你工作负载目标来设置虚拟处理器的数目。如果工作复杂相对稳定而性能是最重要的,使用较低的范围值(5,在前面的例子)。如果最大化系统处理器使用率是最重要的,使用最大范围值(12,前面的例子)。更大的范围值确保有充足的处理器数来使用空闲共享处理能力。通常,最好的折中方案是把虚拟处理器的数目设置为计算出来的范围的最低和最高值之间的某一个值,基于你在性能和处理器利用率某种程度的平衡需求。如果你遇到发生不可预知工作负载相对比较频繁这种设置能带来明显的好处。它能从利用共享池中的处理器资源中得到好处。

其他的处理器类型考虑

对于专用处理器分区,处理器分配的增量是整个处理器。因此处理器能力空闲经常发生在专用处理器分区上。例如,一个有 3 颗处理器的专用分区运行的 DB2 系统使用了等价与 2.10 个处理器(也就是,vmsta 显示 70% 分区利用率)结果导致浪费 0.90(30%)颗处理器能力。

在不重启 AIX 操作系统或者 DB2 的情况下,改变专用分区处理器分配的唯一的办法是使用 DLPAR 选项。比起接近即时授权能力改变,DLPAR 选项是相对比较慢(根据工作负载,要慢几秒),它能在一个非受限共享处理器分区上运行。

之前的信息大多数是和 POWER6 之前的处理器相关。从 POWER6 处理器开始,就有选项来把未使用的处理能力从专用处理器分区贡献出来。这个功能消除了在专用处理器分区内的空闲处理周期,进一步增强了 System p 提供的虚拟能力。

逻辑分区类型决策树流程图

基于功能性和非功能性的要求,下面决策树流程图指导你通过这个流程判断为你的 DB2 环境逻辑分区类型。


图 1. DB2 环境中的逻辑分区类型判断树
DB2 最佳实践: 使用虚拟化来提高数据服务器利用率和对数据服务器的管理

图片看不清楚?请点击这里查看原图(大图)。

磁盘 I/O 类型

DB2 性能严重依赖于子系统的 I/O 性能。为了达到最佳的 I/O 吞吐量,尤其要注意数据库表数据规划。你选择的 I/O 类型直接影响存储设备的可管理性和扩展性。因此,它是考虑工作负载优先权和在各个 I/O 之间折衷的关键。你能在分区中选择本地 I/O、虚拟 I/O,或两个都是。

虚拟 I/O 实践

你必须安装并运行一个 VIOS 来使用虚拟磁盘 I/O。

虚拟 I/O 通过使用少量的物理资源来增强、服务多个分区,并能明显减少在硬件和管理上的成本。

虚拟 I/O 对许多 DB2 环境都很有用。 例如,每个分区需要最少一个根磁盘。没有虚拟 I/O, 分区的数目将受限于可用的 PCI 公共插槽,或者本地 I/O 设备的物理磁盘适配器,因为每个分区需要一个适配器来访问磁盘。共享一个磁盘适配器的唯一办法是使用虚拟 I/O 和逻辑卷管理器(LVM),它允许多个逻辑分区共享一个磁盘,即使节省适配器成本不是优先考虑的。

磁盘技术的发展增强了存储的能力,磁盘大小和带宽的比率随着时间的推移越来越大,造成 DB2 环境中非常大的磁盘空空闲,一般来说,比起用磁盘空间,通过磁盘驱动个数来计算更好。

在使用整个磁盘存储能力或在交错的工作负载之间共享磁盘 I/O 带宽的时候,磁盘共享可以非常有效。例如,白天在线事务处理(OLTP)工作负载和晚间的批量任务可以共享存储系统的带宽。

所有虚拟 I/O 请求都提交到了 VIOS,由它执行磁盘 I/O 操作并向分区直接返回数据(没有虚拟 SCSI 情况下的双倍缓冲)。

下面是一个额外虚拟 I/O 功能的简要列表。更多虚拟 I/O 以及实现的信息参见 System p5 高级 POWER 虚拟化介绍和配置参考。

低成本,LVM 层存储冗余与本地连接 I/O 设备和虚拟 I/O 设备的组合

支持双重 VIOSs 来消除单点故障

SEA,或主适配器

快速内部分区连接,使用 VLAN

虚拟磁盘 I/O 扩展

VIOS 自己需要的资源非常有限,它的内存需求是固定的。VIOS 的主要处理器需求来自于磁盘 I/O 操作。

记住虚拟 I/O 启动是一个特定分区,这个分区叫 VIOS。它运行一个特殊的操作系统 VIOS 来使用处理器和内存资源(类似正常的操作系统)。然而,它对处理器和内存需求是适度的,就算有非常高的 I/O 请求。

VIOS 在需要运行 VIOS 操作系统外没有更多的内存需求,它也不需要内存来响应客户端分区磁盘请求。这是因为虚拟 SCSI 是零内存复制操作:就是,书籍是直接复制到 LPAR 上的应用程序或客户端文件系统空间

我们使用表 1 表述的相同环境进行测试,但是我们把了 I/O 类型从本地连接改成虚拟 I/O。表 2 总结了虚拟 I/O 测试环境。所有测试使用的设备为虚拟存储。对于 DB2 存储,我们使用数据库管理表空间(DMS),并用 NO FILESYSTEM CHACHING 选项来创建。表中显示了 VIOS 客户端分区运行 DB2 产品的处理性能。测试使用了 8 个处理器:客户端分区使用了 7.40 个处理器,剩下的 0.60 个处理器分配给 VIOS 分区。


表 2. DB2 和虚拟 I/O 测试环境

  分区数  
  1 2 4 VIOS
  分区类型 分区类型 分区类型 分区类型
  共享 共享 共享 共享
授权能力 7.40 3.70 1.85 0.60
受限或非受限 非受限 非受限 非受限 非受限
虚拟处理器 8 4 2 1
数据库大小 ~200 GB ~100 GB ~50 GB NA
内存 128 GB 64 GB 32 GB 512MB
磁盘数 192 96 48 NA
I/O类型 虚拟 I/O 虚拟 I/O 虚拟 I/O NA

这个测试被设计来展示虚拟 I/O 的扩展能力以和 DB2 产品以及 System p 虚拟化解决方案总的扩展能力。在这个场景中,处理器和磁盘 I/O 的使用都基于虚拟化技术。

结果显示虚拟 I/O 的在 VIOS 客户端分区处理能力和当前 VIOS 客户端分区的增长上市线性扩展的。虚拟 I/O 的使用也是客户端分区类型无关的:就是说,虚拟 I/O 并不依赖于客户端分区是专用分区还是共享处理器分区。

虚拟 I/O 和 VIOS 调优

把一个非受限共享处理器分区或者有最高非受限权重分区设置为 VIOS 分区类型,以使 VIOS 得到它需要的任何处理器能力。

在 DB2 产品上使用虚拟 I/O 你只需要做很少的调优。不过第一个也是最常见的问题是“VIOS 需要多少内存和处理器?”

VIOS 的内存需求并不明显。因为一个来自客户端分区的 I/O 请求对 VIOS 来说不需要内存,VIOS 的内存需求并不依赖于像 I/O 操作数目或客户端分区数这样的因素。我们在本文里进行的所有测试使用的一个 VIOS 内存都是一个常量 512M。

VIOS 处理器需求也是不明显的。虽然有非常高的磁盘操作,我们所有的测试结果显示 VIOS 处理器使用大约在 0.55 个处理器。VIOS 处理器需求随 I/O 操作次数增长。

在判断处理器需求之后,就要考虑工作负载的最大和最小值,而不仅仅考虑平均值。

为了有帮助对 VIOS 进行正确的测量(能看到不可预知的工作负载)需要要使用下面的方法:

为了获得相当数量的初始处理能力,设置 VIOS 分区类型为非受限共享处理器分区。

对工作负载的峰值运行一个测试,并记录 VIOS 赋权能力利用率(使用 VIOS 的 viostat 命令)。

给你记录的高峰授权能力增加 10% 的额外能力利用率,并像 VIOS 赋权能力一样使用总能力。

设置 VIOS 分区类型为高非受限权重的非授权共享处理器分区。

在基于 POWER6 处理器的服务器上使用一个有共享专用 VIOS 能力的专用处理器分区。一个基于 POWER6 服务器的新功能,可以共享专用能力。可以使专用处理器分区贡献多余的处理器周期给专用处理器分区共享池,并因此提高整个系统的性能。那些贡献了处理器周期的专用分区有使用这些周期的优先权;而共享只有当专用分区没有使用它的全部资源的时候才发生。

经常监视 VIOS 处理器需求,尤其在 DB2 改变了 I/O 或者存储特征,像缓冲池大小和表空间页大小后。不同程度的改变 DB2 I/O 或存储特征会对存储系统带来不同的压力,也可能造成 VIOS 需要更多或更少处理器能力。

通常情况下,对任何分区而言一个虚拟处理器不能跨多个物理处理器:也就是,一个虚拟处理器不能使用超过一个物理处理器。对 VIOS 也是一样。在这种情况下 VIOS 需要比当前的配置虚拟处理器数目更多授权能力,你可以通过使用 DLPAR 服务,分配一个额外的虚拟处理器给 VIOS 分区。

虚拟 I/O 客户端分区通过使用虚拟 SCSI 适配器完成 I/O。和实际的物理适配器一样,你能通过使用 AIX 5Lv5.3 TL05 或以后版本中的 queue_depth参数调来整虚拟 SCSI 适配器。请对虚拟 SCSI 客户端分区适配器设置正确的 queue_depth值。为了在 VIOS 给一个物理适配器设置正确的 queue_depth 值,我们对在客户端分区和 VIOS 中的多个虚拟 SCSI 适配器上进行测试(包括对 DB2 事务日志使用专用虚拟 SCSI 适配器以及每个表空间使用专用虚拟 SCSI 适配器),结果显示使用一个虚拟适配器和多个虚拟适配器在性能上没有区别。

网络类型

虚拟 I/O 支持两种类型的虚拟网络结构。SEA(SEA 需要一个 VIOS),或者干线适配器这适合很多使用单个物理以太网适配器来连接公共网络的客户端分区。其他虚拟网络接口类型叫做虚拟以太网,它提供了系统分区间的快速通信。例如,你可以使用虚拟以太网来提供系统分区间的快速连接。例如,你能使用虚拟以太网在 n 层工作负载、DB2 产品、和 WebSphere 应用服务器之间提供快速连接。虚拟以太网接口不需要物理适配器、电缆,甚至不需要 VIOS。虚拟以太网那个是 PHYP 提供服务并使用 PHYP 内存。

通常,高速、无损、在内存中的连接、通过虚拟网络接口来使用客户端分区处理器周期来进行网络通讯会更快。但是,这两种类型虚拟网络接口都需要使用客户端分区的处理器周期来进行网络通讯。我们设计了下面的测试,对于已经在表 1 中勾画出了使用测试环境的轮廓,比起客户端工作负载产生器运行在同一个分区,我们在分区间进行交叉连接,这样他们就像两个分区和 4 跟分区情况下的多个客户端工作负载产生器。我们从客户端连接 DB2 服务器时使用任何一个物理千兆以太网适配器或一个虚拟以太网接口,并且我们计算了每个分区的吞吐量。

物理网卡和虚拟以太网接口在事务吞吐量方面没有任何差别。注意,这个测试没有涉及 VIOS,因为虚拟以太网不需要它。

工作负载管理设置

为了在不使其负担过重的情况下降低管理 IT 设施的成本,工作负载管理涉及 了一个非常复杂的 IT 策略(用来处理工作负载需求的动态性质)。工作负载管理的关键是平衡工作负载并给高优先级的应用程序分配资源以达到服务层面协议(SLAs)

虚拟化提供了很多级别的工作负载管理功能。你能改变内存总量、非受限权重、赋权能力、和使用 DLPAR 服务动态使用的虚拟处理器数目,不需要重启操作系统或 DB2 服务器。你可以通过 HMC 访问 DLPAR 服务,要么直接使用 WebSM,或者来自网络任何一个地方的一个远程 shell 调用。当你启用了 DB2 STMM 功能与 DLPAR 服务,STMM 功能自动理性地改变内存使用并能调整 DB2 堆以最大化性能。更多关于 STMM 以及它带来的好处信息请参见“最佳实践:工作负载管理”。

另外,如前面提到的,一个非受限共享处理器分区能非常有效的处理高度动态或不可预知的工作负载。当这个运行 DB2 产品的分区的非受限权重设置高于其他分区时,这个分区具有在分配空闲处理器能力的最高优先权。

在刚刚提到的工作负载管理能力之外,IBM 提供了 IBM Tivoli Intelligent Orchestrator 工作流以提供和优化 IT 基础设施。另外还提供了,IBM Enterprise Workload Management (EWLM), 一个端到端的 IT 资源优化解决方案。更多关于对 DB2 产品使用 EWLM 信息参见“工作负载管理”文章。

总结

建议和最佳实践

逻辑分区类型选择

使用共享处理器分区来增加处理器利用率并提供更多的弹性。如果工作负载不可预知,使用非受限共享处理器分区将非常有效。

为了最佳的平衡性能,虚拟处理器的数目不要高于每 1.00 授权能力 2 个虚拟处理器。不要改变 schedo 配置参数 vpm_xvcpus 的默认值为 0。

为了最大化整个系统的处理器利用率,把虚拟处理器的数目设置为授权能力可用值。可用的授权能力是当前分区的授权能力(CEC)和符合条件的空闲共享能力(FPC)的总和。

为了管理不可预知工作负载,通过把非受限权重设置高于其他分区来确定非授权共享处理器分区优先级。

通过 DLPAR 服务你可以改变内存总量、非受限权重、赋权能力、和虚拟处理器的数目。你能通过一些工作负载提供工具自动化这些设置,包括 Tivoli Intelligent Orchestrator。

磁盘 I/O 的类型选择

虚拟 I/O 使其能有比物理槽和适配器多的分区。

一个虚拟 SCSI 客户端适配器对于任何数目的磁盘 I/O 操作来说都足够了。测试结果显示仅使用一个虚拟适配器和使用多个虚拟适配器在性能上没有任何区别。

虚拟 I/O 使用较少物理资源来固化、服务于多个分区并能明显的降低硬件和管理成本。

要使用虚拟磁盘 I/O 你必须安装并运行一个 VIOS。VIOS 本身需要的资源不多,内存的需求非常固定。VIOS 主要的处理器需求来自于磁盘 I/O 操作的个数。

给一个非受限共享处理器分区设置具有最高非受限权重的 VIOS 分区类型,VIOS 将因此而得到它所请求的任何处理器能力,甚至在不可预知的动态工作负载情况下也是如此。

虚拟网络选择

你可以使用 SEA 功能来在多个客户端分区之间只共享一个物理网络适配器。SEA 需要一个 VIOS 和最少一个物理以太网络适配器来连接公网。

你能使用虚拟以太网络适配器接口来高速、无损、可靠的进行分区见连接。虚拟以太网络接口不需要物理网络适配器、网线、也不需要 VIOS。

在事务中没有发现在物理网络接口和虚拟网络接口之间在吞吐量上有任何不同。

工作负载管理设置

使用 DLPAR 服务可以在不需要重启操作系统或 DB2 服务器的情况下动态改变内存总量、非受限权重、赋权能力、和虚拟处理器的个数。

使用一个非受限共享处理器分区以有效处理高度动态或不可预知的工作负载。给 DB2 运行的分区设置比其他分区更高的非受限权重。


System p 虚拟化提供了一批分区和管理功能,像 LPARs、DLPAR 服务、以及虚拟 I/O、在它之下你能试试 SEA、虚拟网络、虚拟 SCSI、或 VLAN。共享处理器分区让你能创建一个 LPAR 让它只使用 0.10 个处理器。DLPAR 服务让你能在运行时更改 LPAR 资源(处理器、内存、和 I/O 槽)而不需要重启操作系统。

DB2 数据库服务器的多功能性和可能的与 System p 虚拟功能的多种组合帮助 DB2 应用程序在很多情况下以最佳的方式运行。System p 虚拟化技术能配置为同时兼顾计算机系统和商业利益,这包括在低成本情况下的高性能、工作负载隔离、资源分区、最大化资源利用率、以及高可用性。这个技术降低总拥有成本(TCO)同时增强可扩充能力、可扩展性、可靠性、可用性和耐用性。

本文中最精华的一课我们已经通过我们自己的测试学习过了。这些最佳实践为我们使用有 System p 虚拟化的 DB2 产品提供了一个非常好的起点。你可以利用它们帮助你避免常见的错误,并更好调整你的基础架构以达到你 IT 环境和商业利益的目标。在把它们应用到你的生产系统中之前,请先验证这些最佳实践的适用性,建立一个底线并对多个虚拟化功能进行充分的测试。

Tags:DB 最佳 实践

编辑录入:爽爽 [复制链接] [打 印]
赞助商链接