Hyper-V
Oracle数据库虚拟化
建议更改
PDF
对于选择使用虚拟化来管理任务关键型数据库的NetApp客户来说、使用VMware、Oracle OLVM或KVM实现数据库虚拟化的做法越来越普遍。
可支持性
对于Oracle虚拟化支持策略、尤其是VMware产品支持策略、存在许多误解。听说Oracle完全不支持虚拟化、这种情况并不少见。这一概念是不正确的、会导致错失从虚拟化中获益的机会。Oracle文档ID 249212.1讨论了实际要求、客户很少考虑这些要求。
如果虚拟化服务器上出现问题、而Oracle支持先前并不知道该问题、则可能会要求客户在物理硬件上重现该问题。运行尖端产品版本的Oracle客户可能不想使用虚拟化、因为可能会出现可支持性问题、但对于使用通用Oracle产品版本的虚拟化客户来说、这种情况并不是现实情况。
存储表示
考虑将数据库虚拟化的客户应根据业务需求制定存储决策。虽然这对于所有IT决策来说都是一个普遍正确的说法、但对于数据库项目来说尤其重要、因为要求的大小和范围差别很大。
存储表示有三个基本选项：
-
虚拟机管理程序数据存储库上的虚拟化LUN
-
由虚拟机上的iSCSI启动程序(而不是虚拟机管理程序)管理的iSCSI LUN
-
虚拟机挂载的NFS文件系统(而不是基于NFS的数据存储库)
-
直接设备映射。客户不喜欢VMware VMM、但物理设备通常仍与KVM和OLVM虚拟化直接映射。
性能
向虚拟化子系统提供存储的方法通常不会影响性能。主机操作系统、虚拟化网络驱动程序和虚拟机管理程序数据存储库实施均经过高度优化、只要遵循基本最佳实践、通常可以占用虚拟机管理程序与存储系统之间的所有可用FC或IP网络带宽。在某些情况下、使用一种存储表示方法可能比使用另一种存储表示方法更容易获得最佳性能、但最终结果应该是可比的。
易管理性
决定如何向虚拟化子系统提供存储的关键因素是可管理性。方法没有对错之处。最佳方法取决于IT运营需求、技能和偏好。
需要考虑的因素包括：
-
*Transparency。*当VM管理其文件系统时，数据库管理员或系统管理员可以更轻松地确定其数据的文件系统源。访问文件系统和LUN的方式与使用物理服务器相同。
-
*一致性。*如果虚拟机拥有其文件系统、则使用或不使用虚拟机管理程序层会影响易管理性。配置、监控、数据保护等过程同样适用于整个资产、包括虚拟化和非虚拟化环境。
另一方面、在完全虚拟化的数据中心中、根据上述相同的原理(一致性、使用相同的配置、保护、监控和数据保护过程的能力)、在整个占用空间中使用基于数据存储库的存储可能更好。
-
*稳定性和故障排除。*当虚拟机拥有其文件系统时、由于虚拟机上存在整个存储堆栈、因此提供良好、稳定的性能和解决问题会更加简单。虚拟机管理程序的唯一角色是传输FC或IP帧。如果配置中包含数据存储库、则会引入另一组超时、参数、日志文件和潜在错误、从而使配置复杂。
-
*可移动性。*当VM拥有其文件系统时、移动Oracle环境的过程将变得更加简单。文件系统可以轻松地在虚拟化和非虚拟化子系统之间移动。
-
*受制于供应商。*将数据放入数据存储库后、使用不同的虚拟机管理程序或将数据完全从虚拟化环境中取出将变得非常困难。
-
*启用Snapshot。*由于带宽相对有限、虚拟化环境中的传统备份过程可能会成为一个问题。例如、四端口10GbE中继可能足以满足许多虚拟化数据库的日常性能需求、但此类中继不足以使用RMAN或其他需要流式传输完整大小数据副本的备份产品执行备份。因此、日益整合的虚拟化环境需要通过存储快照执行备份。这样、无需纯粹为了满足备份窗口中的带宽和CPU要求而过度构建虚拟机管理程序配置。
使用子系统拥有的文件系统有时可以更轻松地利用基于快照的备份和还原、因为需要保护的存储对象可以更轻松地确定目标。但是、越来越多的虚拟化数据保护产品能够与数据存储库和快照完美集成。在决定如何将存储提供给虚拟化主机之前、应充分考虑备份策略。
部分驱动程序
为了获得最佳性能、使用完全虚拟化的网络驱动程序至关重要。使用数据存储库时、需要使用一个虚拟化的SCSI驱动程序。与虚拟化驱动程序相比、超虚拟化设备驱动程序可以使子系统更深入地集成到虚拟机管理程序中、而在模拟驱动程序中、虚拟机管理程序会花费更多的CPU时间来模拟物理硬件的行为。
过量使用RAM
过量使用RAM意味着在不同主机上配置的虚拟化RAM要多于物理硬件上的虚拟化RAM。否则可能会出现发生原因意外的性能问题。对数据库进行虚拟化时、虚拟机管理程序不得将Oracle SGA的底层块交换到存储中。这样做会导致性能结果高度不稳定。
数据存储库条带化
将数据库与数据存储库结合使用时、需要考虑一个与性能相关的关键因素—条带化。
VMFS等数据存储库技术可以跨越多个LUN、但它们不是条带化设备。这些LUN会串联在一起。最终结果可能是LUN热点。例如、典型的Oracle数据库可能具有一个8-LUN ASM磁盘组。所有8个虚拟化LUN均可配置在一个8 LUN VMFS数据存储库上、但无法保证数据将驻留在哪些LUN上。得到的配置可能是所有8个虚拟化LUN都占用VMFS数据存储库中的一个LUN。这将成为性能瓶颈。
通常需要条带化。对于某些虚拟机管理程序(包括KVM)、可以按所述使用LVM条带化来构建数据存储库 "此处"。使用VMware时、架构看起来略有不同。每个虚拟化LUN都需要放置在不同的VMFS数据存储库上。
例如：
这种方法的主要驱动因素不是ONTAP、这是因为一个虚拟机或虚拟机管理程序LUN可并行处理的操作数存在固有限制。一个ONTAP LUN支持的IOPS通常远远超过主机可以请求的IOPS。单个LUN性能限制几乎是主机操作系统的结果。因此、大多数数据库需要4到8个LUN才能满足其性能需求。
VMware架构需要仔细规划其架构、以确保此方法不会遇到数据存储库和/或LUN路径最大值。此外、对于每个数据库、不需要一组唯一的VMFS数据存储库。主要需求是确保每个主机都有一组从虚拟化LUN到存储系统本身上后端LUN的干净的4到8 IO路径。在极少数情况下、即使数据存储库数量更多、也可能有利于满足真正的极致性能需求、但所有数据库中通常有95%的数据库需要使用4到8个LUN。在典型的OS/ONTAP /网络配置下、包含8个LUN的单个ONTAP卷最多可支持250、000次随机Oracle块IOPS。