dlp与sla区别:Oracle在VMware上完美运行的10大理由

Oracle在VMware上完美运行的10大理由 2007-11-28 10:03:07标签：Oracle 虚拟化 VMware 原创作品，允许转载，转载时请务必以超链接形式标明文章 原始出处 、作者信息和本声明。否则将追究法律责任。http://virtualman.blog.51cto.com/200540/52530 看到外界非常关注 Oracle 在虚拟环境中的表现，我们感到十分高兴。Oracle 在 VMware ESX 上的优越表现一直是我们的秘诀之一。这种优越表现绝非偶然，因为我们对 VMware ESX Server 体系结构做了大量功能和性能优化工作，特别是在数据库支持方面。在此，我将向大家介绍一下确保我们获得最佳数据库性能的 10 大重要因素。以下是其中几项性能优势：

• 接近本机系统的性能：Oracle 数据库与物理系统的性能几近相似
• 超强的数据库 I/O 扩展性：VMware ESX Server 的精简虚拟化管理程序层每秒能够驱动 63,000 次数据库 I/O 操作
• 多核扩展：使用 SMP 虚拟机和多个数据库实例进行纵向扩展
• 巨大的内存容量：可扩展的内存容量 - 每个数据库 64 GB；每台主机 256 GB

我们一直持续地下大气力优化 Oracle 在 VMware 产品上的性能，因为它已是最常用的虚拟化应用程序之一。融合了多项先进优化措施的 ESX 3.5 版本即将发行，这是我们迄今为止推出的最棒的数据库平台。在本篇博客文章中，我将为大家介绍数据库应用程序（如 Oracle 产品）的独特和专有特性，并向大家展示 ESX Server 在此类工作负载下的运行能力。数据库的本质数据库具有多种独特的属性，例如较大的内存占用空间。这样，数据库要进行顺畅的虚拟化就略显复杂了。然而，实践证明这也是一种机会，因为我们可以专门针对这些特定的属性进行优化。

• 巨大的内存容量：数据库使用大量的内存来对其存储数据进行高速缓存。大容量高速缓存是衡量数据库性能极为重要的一个标准，因为它通常可使物理 I/O 操作的次数减少 10-100 倍。
• 高性能数据块 I/O：数据库使用固定大小的数据块写入和读取数据。这些 I/O 通常较小，频繁发生于少量文件或设备中。
• 以吞吐量为中心：数据库通常会有大量的用户同时进行操作，因此具有多个逻辑或物理处理器的系统便可以使这些用户自然并存并充分受益。

理解和量化虚拟性能量化虚拟系统的性能时，首先应衡量延迟和吞吐量，其次是资源的使用率。例如，如果一个物理系统正在以每分钟 10000 个事务、每个事务 500 毫秒的延迟运行，则与该物理系统性能相同的虚拟系统也应该以可接受的延迟标准提供同样水平的吞吐量。其次应该是资源使用率的衡量指标，通过这一指标可以衡量要取得同样水平的性能需要额外使用多少物理资源。有些时候我们过于简单地仅去考虑 CPU 资源，然而现实中我们需要配备的内存和 I/O 却是更加昂贵的资源。随着时间的推移，内存和 I/O 资源的使用率变得越来越重要，原因是多核 CPU 会使每个处理器内核的成本继续降低，而内存的成本却一直居高不下。对于 Oracle 而言，更重要的一点是纵向扩展能力，即通过虚拟化管理程序充分利用多核 CPU、大容量内存以及 I/O 吞吐量来支持后端存储阵列中大量的磁盘。数据库性能认识误区对于虚拟化数据库，通常存在以下几点认识误区：

• 虚拟数据库具有很高的系统开销：就延迟和吞吐量而言，虚拟数据库的运行速度能等于或接近物理系统。对于常见的数据库而言，虚拟化开销很小 – 在 VMware ESX Server 中所测量到的 CPU 开销低于 10%。

• 数据库的 I/O 操作过多无法进行虚拟化：通常情况下，数据库会产生大量小的、随机的 I/O 操作，其理论值可能达到虚拟化管理程序层的 I/O 数量极限。然而，VMware ESX 的精简虚拟化管理程序层每秒可以驱动 63,000 多次数据库 I/O 操作，等同于 600 多个硬盘的 I/O 吞吐量。这样的 I/O 极限值，即使是用于 x86 系统上最大的数据库也绰绰有余。

• 虚拟化只能用于较小的、无关紧要的应用程序：ESX 虚拟化管理程序非常强健 - 很多客户的基于 ESX 的系统已经连续正常运行了两年多的时间。此外，ESX 虚拟化管理程序一直非常稳定，即便在资源过度使用时亦是如此。

我们不能奢望通过一个快速的解决方案使数据库与很多种实际的应用程序完美兼容 – 只有通过长时间地致力于研究众多用户在实际数据库工作中获得的教训，并且在虚拟化管理程序体系结构中应用这些教训，才能获取优异的性能。下面让我们简要了解一下虚拟化管理程序中可确保数据库获得优异性能的一些特性。
1. VMware ESX 的高性能 I/OI/O 系统的吞吐量和延迟对于在线事务处理系统的性能来说至关重要。由于事务数据库系统是针对数据集中随意位置的不同小数据项进行操作的，因此应测量随机 I/O 吞吐量（以每秒钟的 I/O 操作数为测量标准），而非带宽（MB/s）。 图 1：VMware ESX I/O 驱动程序模型由于逻辑上虚拟化管理程序驻留在客户虚拟机数据库和后端存储之间，因此很重要的一点就是虚拟化管理程序的 I/O 能力可以纵向扩展且不会超出任何性能限额，并且不能产生可察觉延迟。如图 1 所示，VMware ESX 的 I/O 子系统使用直接的驱动程序模型，以使由虚拟堆栈引起的延迟最小化。这是可能的，因为 I/O 请求可以由同一个处理器（相对于发出请求的虚拟机）进行内处理。在其他体系结构中，当 I/O 由一个重量级域 0 或父分区进行代理时，会产生大量的延迟和 CPU 开销。
 在随机存取模式下，Oracle 数据库通常会产生许多 4 KB 或 8 KB 的小型 I/O 操作。对于这类 I/O 操作，一个典型的磁盘每秒可处理的 I/O 操作数介于 100 到 200 之间（具体值取决于磁盘的转速）。然而在实际操作中，最好不要使一个驱动器每秒处理的 I/O 数超过 100 个。VMware ESX 3.5 虚拟化管理程序的吞吐量已经得到了显著的提升，可持续以每秒 60,000 多个 I/O 操作数的速度运行，相当于 600 多个磁盘的吞吐量。                            图 2：随机 I/O 吞吐量
4-CPU 数据库平均量对比 VMware ESX 3.5VMware 对其客户的 15,000 个 Oracle 服务器进行的调查研究结果表明：对于加载的 4 处理器系统，每秒的平均 I/O 数为 1280 个，大约是 15 个磁盘的吞吐量。由于一些工作负载吞吐量要求比其他工作负载高，有些工作负载的吞吐量要求是突发性的，因此必须要备有充足的预留量。即便是对于要求最高的数据库，ESX I/O 子系统的吞吐量能力也是绰绰有余的。2. 使用 Virtual SMP 进行纵向扩展VMware ESX 可以通过两种方式来利用多个物理处理器：通过多个虚拟机进行横向扩展；通过纵向扩展每个虚拟机来使用多个物理处理器。VMware ESX 提供的 Virtual SMP 功能允许每个客户虚拟机最多有 4 个处理器，物理系统最多有 64 个处理器。
图 3：Virtual SMP 由于数据库工作负载通常会有大量的用户同时进行操作，这些用户是完全并行的，并且可以毫不费力地同时处理多个任务。Oracle 能够利用 VMware Virtual SMP 扩展性能，从而超出每个虚拟机单处理器的能力。为了说明这一点，我们通过 Oracle Database 10g 版本 2 进行了几个基准测试，使用的是流行的 SwingBench 在线事务处理工作负载。图 5 显示的是在单个虚拟机上增加处理器时 Oracle 的吞吐量。基准测试测量了事务的吞吐量，结果表明随着额外处理器的增加，吞吐量提高了 94%。恰巧，这与我们在本机系统上看到的扩展量完全一致，这很可能是硬件和数据库扩展带来的结果。
图4：VMware Virtual SMP 针对单个 Oracle 10g R2 实例的扩展情况 进行整合的关键要求之一是对于多个数据库实例的良好扩展性。为了显示这一点，我们在 VMware ESX Server 3.5 上运行了多个 Oracle 10G 实例。图 4 显示了在运行开放源 DVDstore 数据库基准测试时，VMware ESX 平台的扩展情况。该基准测试是以客户端－服务器模式运行的，因此我们可以专注于数据库层。在此研究中，我们在 7 个双处理器 SMP Linux 虚拟机（每个虚拟机皆具有自己的数据库实例）中运行了该基准测试。我们很快将在 Vroom 中发布该基准测试的详细信息。  图 5：16 核 Sun x4600 M2 上 VMware ESX 中多个数据库实例的扩展情况3. 利用大容量内存进行纵向扩展Oracle 数据库会消耗大量内存。主要是在内存中缓存预编译的 SQL 查询和来自磁盘的数据块。 数据库设计者花费了极大的精力来尽量避免进行排?I/O。这是因为一个磁盘 I/O 的延迟要远远长于 CPU 处理一个事务的时间。例如，一个磁盘 I/O 需要等待 10 毫秒，而典型的事务只需占用 CPU 几毫秒。如果一个到磁盘的 I/O 能够被高速缓存在内存中，则可以在不到 1 毫秒的时间内调用。此外，由于磁盘很贵，通常情况下用于数据库的存储系统的成本更多地受其每秒所执行的 I/O 操作数的影响，而不是单纯的存储空间的影响。降低整体的磁盘吞吐量便意味着大幅降低系统的成本。更大的内存空间可以帮助 Oracle 在内存中高速缓存更多的磁盘数据块。请看一个简单的例子：如果数据库系统正在使用内存来高速缓存其磁盘 I/O，并且高速缓存命中率达到 90%，这就意味着每 10 次访问操作，只有一次会导致物理 I/O。如果每秒的访问次数为 10,000，我们将会看到每秒 1,000 次 I/O 操作。如果增加内存将高速缓存命中率提高至 99%，则可以将 I/O 的发生率降低到 1%，从而使每秒的物理 I/O 数减至十分之一，即每秒仅 100 次 I/O 操作。通常，在客户操作系统所使用的内存中，有 80% 以上是由 Oracle 磁盘数据块高速缓存占用的。基本的经验原则是数据库高速缓存大小应该是数据库大小的 5-10%，将内存容量增加一倍会使吞吐量大约提高 20%。显然这还与工作负载的多少有很大关系，但是您可以看到较大的内存可以帮助提高系统中其他区域的资源效率，因而就整体而言，内存越大越好。综合上述原因，大容量内存对于数据库来说非常重要。VMware ESX 3.0 允许每个客户操作系统拥有 16 GB RAM，而 VMware ESX 3.5 则将此限制提高到了每个客户操作系统 64 GB。 由于通过工作负载整合可以从内部提高处理器利用率，因此我们可以将更多工作负载压缩到单个系统中。这意味着平均而言，每个物理处理器的平均内存要求将是传统未虚拟系统的两倍。为了适应这些不断增长的要求，我们在 ESX 3.5 中大幅提高了内存扩展量，现在对于 Sun、IBM 和 Unisys 的最新高端系统，最高可以支持 256 GB RAM。4. ESX 3.5 虚拟化管理程序的大页面功能Oracle 数据库在 CPU 的 MMU 中使用大页面来优化内存性能已经有一段时日了。这一功能与操作系统的大页面功能配合使用，通常用于容纳数据库磁盘数据块高速缓存的较大共享内存分段。 Linux、Windows 和 Solaris 客户操作系统均支持大页面。通过大页面，Oracle 的性能一般会提高 5-20%，具体取决于处理器的类型和所配置内存的大小。其他的 x86 虚拟化管理程序不提供虚拟的大页面功能，因此当数据库被虚拟化后无法使用该优化功能。ESX 3.5 虚拟化管理程序提供先进的大页面支持，允许数据库充分利用 CPU 的大页面功能。5. ESX 针对不同内存体系结构系统进行的优化当今许多备受关注的新硬件系统都是使用不同的内存体系结构实现的。这意味着并不是所有的内存都具有相同的速度，对比拓扑结构与处理器相近的内存和拓扑结构与处理器差异较大的内存，访问前者要比访问后者更快。为确保最佳性能，VMware ESX 虚拟化管理程序在为客户操作系统分配内存时，将从与运行客户操作系统的 CPU 拓扑结构接近的物理内存中进行分配。6. 高性能的半虚拟化网络连接半虚拟化是一个专有名词，指的是客户操作系统具有虚拟化管理程序的一些知识，并且能够利用这些知识对虚拟化管理程序的执行进行优化。VMware ESX 虚拟化管理程序在客户操作系统中使用半虚拟化网络连接驱动程序来提供高性能的网络连接。在客户操作系统首次启动时，这些驱动程序会通过 VMware 工具包被自动安装。不同于 CPU 半虚拟化，半虚拟化驱动程序不需要对客户操作系统进行任何更改，它们只是作为透明的新驱动程序进行安装。
6 - 多 NIC 的扩展情况
ESX 能够以线速驱动千兆位以太网，如文章多个虚拟机中的网络连接性能中所述。通过集成新的无状态卸载功能，例如大分段卸载 （large-segment-offload, LSO） 和巨型框架，ESX 3.5 的网络连接性能得到了很大提升，现在在 10 千兆位以太网上已接近线速（9.9 千兆位/秒）。通过在多个 NIC 之间扩展，网络连接的性能可以提高从而超过一个 NIC 的性能。图 6 显示了添加多个 NIC 后千兆位以太网性能的扩展情况。
7. 利用 VMware ESX 的页面共享功能来减少内存使用量通过一个被称作透明页面共享的功能，ESX 虚拟化管理程序可以安全地共享具有相同内容的物理内存。通过页面共享，虚拟化管理程序会分配一个单独的物理内存页面来对应客户系统中的多个页面，这样仅有一份数据副本驻留在内存中。使用这一技术，所耗用的内存总量就会少于各部分的总和。虚拟化管理程序会确保绝对的安全性隔离，即如果一个客户操作系统修改了一个页面，则该客户操作系统就会获得自己的专有副本。 可以通过多种方式使用此功能有效地节省 Oracle 所用的内存。如果有多个数据库实例在运行，则页面共享功能会自动共享操作系统和 Oracle 实例的代码部分。通常情况下，这会为每个虚拟机节省好几百 MB 内存。当多个数据库正在共享相似的数据（如一个共享的参考表或者多个用于开发目的的数据库副本）时，ESX 可自动检测 Oracle 磁盘数据块高速缓存中相同的磁盘数据块，并安排对其进行共享。如此一来，各数据库实例以及各虚拟机之间就可以透明地共享数据库高速缓存内存映像。这会进一步节省几十 MB（至少系统表会是相同的）到几 GB 的内存，具体取决于实例间相同磁盘数据的数量。 页面共享的另一个好处是，某些内存还可以在每个实例内部进行共享。这通常适用于零页面。8：半虚拟化 CPU
图 7： 虚拟化技术有多种技术可以用来虚拟化 x86 指令集，包括二进制转换、半虚拟化和硬件辅助。长期以来 VMware 虚拟化管理程序就一直使用二进制转换来为多种工作负载提供接近本机性能的虚拟化。CPU 半虚拟化或硬件辅助这两种方法可以用来为具有多个系统调用的工作负载提供小的优化，以及特定的内存优化。没有哪个方法是适用于所有工作负载的，在 VMware ESX 中，不同的方法被用于不同的工作负载。Ole Agesen 和 Keith Adams 在他们的论文（关于虚拟化性能）中解释了不同的技术。 VMware ESX 可以针对一些客户操作系统类型选择性地使用半虚拟化技术。在最近的研究中，我们在半虚拟化的 Linux 客户操作系统上使用 Swingbench 在线事务处理工作负载对 Oracle 10g R2 进行了测试。测试结果表明，采用半虚拟化 CPU 接口可使该数据库的性能提高 10%。 9. 最佳的 Oracle-Windows 性能由于所有关键的 CPU、内存和 I/O 虚拟化功能都处在虚拟化管理程序的可移植层中，因此 Windows 客户操作系统中 Oracle 的性能与 Linux 客户操作系统中 Oracle 的性能是相同的。Windows 上的 Oracle 能够利用大页面、SMP、I/O 扩展性以及高性能半虚拟化网络连接驱动程序。对于 Linux、Solaris 和 Unix 管理员，这就意味着您可以根据最适合自己部署的工具而自由选择操作系统。对于 Windows 管理员，这意味着您可以完全放心地在 Windows 中运行 Oracle 数据库，您会获得同样水平的性能和可扩展性。10. 通用的 32 位和 64 位客户操作系统支持为了在客户操作系统中使用超过 3.5 GB 的内存，需要将数据库配置为 64 位应用程序，并使用支持 64 位的操作系统。VMware ESX 允许 32 位和 64 位客户操作系统并存，这可以在需要时简化 64 位客户操作系统的部署。 总结各位数据库管理员们，欲知 Oracle 在 VMware 产品上的性能表现，敬请关注 VROOM 中更多相关文章，最新的 Oracle portal 也值得期待，您可以在其中获取大量有关 Oracle 虚拟化的有用资料。此外，一个全新的 Oracle Discussion Forum 即将面世，您可以在论坛中畅谈您对 Oracle 性能的看法。虚拟数据库实现了前所未有的高性能！

本文出自 “云界漫步” 博客，请务必保留此出处http://virtualman.blog.51cto.com/200540/52530