Hyper-V
使用ONTAP QoS进行Oracle数据库性能管理
建议更改
PDF
安全高效地管理多个Oracle数据库需要有效的QoS策略。原因在于现代存储系统的性能不断提高。
具体而言、随着全闪存存储的采用率不断提高、工作负载得以整合。由于旧旋转驱动器技术的IOPS功能有限、依赖旋转介质的存储阵列往往仅支持数量有限的I/O密集型工作负载。早在存储控制器达到其限制之前、一两个高度活跃的数据库就会使底层驱动器饱和。这种情况已经改变。即使是功能最强大的存储控制器、数量相对较少的SSD驱动器的性能也可能会饱和。这意味着、可以充分利用控制器的全部功能、而不必担心随着旋转介质延迟峰值而导致性能突然崩溃。
作为一个参考示例、一个简单的双节点HA AFF A800系统能够在延迟超过1秒之前提供高达100万次随机IOPS。只有极少数单个工作负载才能达到此级别。要充分利用此AFF A800系统阵列、需要托管多个工作负载、而安全地执行此操作、同时确保可预测性、则需要QoS控制。
ONTAP中有两种类型的服务质量(QoS)：IOPS和带宽。QoS控制可应用于SVM、卷、LUN和文件。
IOPS QoS
IOPS QoS控制显然基于给定资源的总IOPS、但IOPS QoS的许多方面可能并不直观。最初、一些客户对达到IOPS阈值时延迟明显增加感到很不明白。限制IOPS自然会导致延迟增加。从逻辑上讲、它的功能类似于令牌系统。例如、如果包含数据文件的给定卷具有10000 IOPS限制、则到达的每个I/O都必须先接收令牌才能继续处理。只要在给定的一秒内使用的令牌不超过10000个、就不会出现延迟。如果IO操作必须等待接收其令牌、则此等待将显示为额外的延迟。工作负载越难超过QoS限制、每个IO在队列中等待处理的时间就越长、这在用户看来是延迟越高。
|
对数据库事务/重做日志数据应用QoS控制时要小心。虽然重做日志记录的性能需求通常要比数据文件低很多、但重做日志活动会变得突发。IO会以短暂的脉冲发生、并且似乎适合平均重做IO级别的QoS限制对于实际要求可能过低。结果可能会造成严重的性能限制、因为QoS会与每个重做日志突发事件结合使用。通常、重做和归档日志记录不应受QoS的限制。 |
带宽QoS
并非所有I/O大小都相同。例如、数据库可能会执行大量小块读取、从而导致达到IOPS阈值、 但是、数据库可能还会执行完整的表扫描操作、其中包含非常少量的大型块读取、占用的带宽非常大、但IOPS相对较少。
同样、VMware环境可能会在启动期间产生大量随机IOPS、但在外部备份期间执行的IO会更少、但会更大。
有时、有效管理性能需要IOPS或带宽QoS限制、甚至两者都需要。
最低/有保障的QoS
许多客户都希望解决方案能够提供有保障的QoS、而这种服务质量比看起来更难实现、而且可能会造成大量浪费。例如、如果要将10个数据库放置在10000 IOPS保证下、则需要对系统进行规模估算、以应对所有10个数据库同时以10000 IOPS运行的情形、总共需要100K IOPS。
最低QoS控制的最佳用途是保护关键工作负载。例如、假设一个ONTAP控制器的最大可能IOPS为50万次、并混合了生产和开发工作负载。您应将最大QoS策略应用于开发工作负载、以防止任何给定数据库独占控制器。然后、您可以对生产工作负载应用最低QoS策略、以确保它们在需要时始终具有所需的可用IOPS。
自适应 QoS
自适应服务质量(QoS)是指ONTAP功能、其中服务质量(QoS)限制基于存储对象的容量。它很少用于数据库、因为数据库大小与其性能要求之间通常没有任何关联。大型数据库可能几乎处于无活动状态、而小型数据库则可能是IOPS密集型最高的数据库。
自适应QoS对于虚拟化数据存储库非常有用、因为此类数据集的IOPS要求往往与数据库的总大小相关。包含1 TB VMDK文件的较新数据存储库所需的性能可能是2 TB数据存储库的一半左右。自适应QoS允许您在数据存储库中填充数据时自动增加QoS限制。