基于生产环境虚拟化资源池如何进行核心数据库的架构设计探讨 活动总结

在建设Power小型机虚拟化资源池过程中，需要考虑Oracle关键数据库集群的应用场景，传统使用物理机搭建Oracle关键数据库集群，心跳数据流量、存储IO需求、业务类型等之间都是独立分散的，彼此之间不存在直接的资源竞争。在虚拟化场景中，如果搭建Oracle数据库集群，需要从以上几个方面进行考虑，并在架构设计阶段满足相应的需求，以便让Oracle关键数据库集群在虚拟化环境中运行更加稳定高效。需要从以上三个方面出发，充分调研现状，分析业务类型、场景，合理规划架构设计，保持架构弹性，满足业务发展需求。
通过本篇文章，大家对Oracle数据库在PowerVM虚拟化环境中应用和实践有很多新的观点和认识。一些关键性的问题得到进一步清晰和明了，为大家在进行Oracle架构设计的过程提供参考。

在虚拟化环境中部署Oracle数据库集群，从架构规划设计上需要考虑哪些要素？有哪些原则？

需要考虑以下问题：
1、 不同RAC集群节点间的心跳交互数据流量会叠加；
2、 主机CPU、内存的资源较其他分区消耗更大
3、 对不同业务类型分区在同一台物理机上的分布，导致对存储IOPS和吞吐量要求大大提高，同一存储路径难以同时满足两种需求。
设计上要满足以下需求：
1、 在Power虚拟化环境中部署Oracle数据库，建议要充分考虑生产、心跳网络带宽需求，尽可能采用万兆网络，做好冗余，避免网络带宽不足或高可用性不足；
2、 要预估存储IO的类型及量的大小，根据不同存储访问类型，设计更多的存储路径满足需求，将vscsi与npiv的物理HBA卡分开，并为npiv保留更多的通道，增加冗余，减少拥堵，满足各业务分区对IOPS或者吞吐量的不同需求；
3、 将不同业务特性的分区进行分布、搭配，如应用分区与数据库分区搭配，OLTP业务与OLAP业务搭配，重要系统与非重要系统搭配，形成错峰资源使用，平衡利用单台物理机的资源。

虚拟化环境中部署核心数据库，是否对数据库性能有影响？

首先影响肯定是有的，具体的主要是网络、存储IO、CPU三个方面，因为虚拟化的平台，主要就是为了提高资源的利用率，需要用到资源共享，所以就较难以做到资源的独享分配。有些虚拟化平台可以直接接入存储，有些则不行，Power虚拟化就可以将存储通过NPIV方式直接分配给VIOC，在虚拟化环境中可以提高存储IO性能。
数据库一向是网站架构中最具挑战性的，瓶颈通常出现在这里。数据库是一个对IO高度敏感的软件，在架构设计中是考虑的重点，而虚拟化环境的IO性能又一直是一个瓶颈。所以虚拟化环境能否满足需要运行Oracle数据库需求，首先看产品的指标，如果指标满足要求，再进行压力测试，如果压力测试验证，确实能够满足要求，就放心的去用，否则不要随便改变环境。如果是像数据仓库类的，建议不要放在虚拟化环境中，其他交易类的系统根据业务情况，结合测试验证情况，可以考虑放在虚拟化环境中。从我们目前运行情况看来，除数据仓库外，其他都运行在Power虚拟化资源池中，整体运行稳定，未碰到性能问题。
当前，按照文中的设计原则，我们的Oracle数据库环境在由传统物理机方式改造迁移至Power虚拟化环境后，由于基础网络环境配置的优化，基本消除了由于心跳网络时延、拥堵等造成的节点宕机情况，RAC集群稳定性较传统物理机方式大大提高。存储的IO尽可能的进行了流量分类、分散，也未发现有IO瓶颈的存在。对于虚拟化环境运行好坏与否，关键在于监控是否到位，管理是否尽职尽责。

在Power虚拟化中应用Oracle数据库该场景的硬件选型有哪些考虑？

对硬件选型的建议，尽量选择高型号的主机，尽可能高配，硬件冗余性、稳定性相对会好些。在进行硬件选型时，我们有几点基本的准则需要知道。这些准则都是基于特定的元素的，比如CPU性能、I/O以及平均数据吞吐量等。然而，首先需要考虑的是我们的操作系统是什么，以及是否需要用到虚拟化技术。
　　举个例子，虚拟化服务器环境对高性能和多核CPU的反馈良好。需要高性能I/O的Oracle产品，更适合能够运行多线程的系统，这样的系统需要有64比特数据通路和高速互联。这些高速互联包含了针对SAN(存储域网络)的光线通道、高速通讯10 GB以太网以及一个针对智能机架系统的高性能面板。
　　当然，进行硬件选择的时候，我们不应该仅仅考虑到服务器性能这一点。实用性、集成、扩展以及管理等因素对于Oracle环境来说都是非常重要。这些因素决定了最终的投资回报率(ROI)和总拥有成本(TCO)，这些都会影响一个企业的整体预算情况。那些易于升级的产品经过长时间的证明，往往会拥有更低的TCO并能增加投资回报率。
当为Oracle环境选择硬件的时候，遵循上文的提到的原则将会对您有所帮助。这些原则并不仅仅针对性能方面，更重要的是成本考虑、利用率、预计增长以及硬件的生命周期。

不同的业务类型对存储IO需求不同，如何同时满足IOPS和吞吐量的需求？

需要结合不同的业务类型、存储服务级别，配置更多的存储路径，将不同业务类型的数据流量分配到不同的存储路径。如将vscsi方式与npiv方式分离，并为npiv保留更多的通道，在满足不同业务类型的同时，还能避免单个路径流量过大，将不同数据流量分布在不同的存储路径中，保证数据库对存储的访问性能，避免出现路径流量拥堵的情况。
设计更多的存储路径满足需求，将vscsi与npiv的物理HBA卡分开，并为npiv保留更多的通道，增加冗余，减少拥堵，满足各业务分区对IOPS或者吞吐量的不同需求；将不同业务特性的分区进行分布、搭配，如应用分区与数据库分区搭配，OLTP业务与OLAP业务搭配，重要系统与非重要系统搭配，形成错峰资源使用，平衡存储IO的压力。
现在一般存储都支持开启QoS，当然前提是存储本身的性能足够，也可以在存储层面做好优先保障。

Oracle数据库集群的心跳网络如何设计？

一、硬件及参数

从Oracle官方的推荐来看，他们首先推荐使用万兆以太网，至少使用千兆以太网，负载如果很高那么私网可以采用infiniband。当然这个完全取决于客户生产环境的具体业务量及负载情况。这个仅仅是个参考，有条件的情况下可以按照推荐进行配置。私网的连接需要使用交换机，Oracle集群安装并不支持私网的直连架构。网卡及交换机的双攻击速率参数保持正确一致。

二、网卡绑定

各种平台都有自己的网卡绑定工具，而且提供负载均衡和主备模式的绑定。首先为了提高公网和私网的网络高可用，网卡需要绑定。对于Linux平台我们需要在配置文件 “/etc/modprobe.d/dist.conf” 中将数mode来控制网卡绑定的具体策略：
mod=0，即：(balance-rr)Round-robin policy（平衡抡循环策略）。
mod=1，即： (active-backup)Active-backup policy（主-备份策略）。
mod=2，即：(balance-xor)XOR policy（平衡策略）。
mod=3，即：broadcast（广播策略）。
mod=4，即：IEEE 802.3ad Dynamic link aggregation（IEEE802.3ad 动态链接聚合）。
mod=5，即：(balance-tlb)Adaptive transmit load balancing（适配器传输负载均衡）。
mod=6，即：(balance-alb)Adaptive load balancing（适配器适应性负载均衡）。
对于私网网卡绑定方式mode=3&6会导致ORA-600，公网网卡绑定方式mode=6会导致BUG9081436。对于具体的绑定模式，对于平台版本低而且网络架构非常复杂的场合，还是建议主备模式，因为主备模式更稳定，不容易产生数据包路径不一致的问题。如果是负载均衡模式的场合，如果网络参数设置不是很科学的情况下，很容易出现从一个物理网卡发送报文，但是回报文却回到另外一个物理网卡上，网络链路再加入防火墙的规则之后，非常容易导致丢包问题发生。
而对于AIX平台来讲，将参数mode修改为NIB或者Standard值。Standard是根据目标IP地址来决定用哪个物理网卡来发送报文，是基于IP地址的负载均衡，也不易产生上述的丢包问题。

三、SCAN IP

Oracle RAC，从11gr2之后增加了SCAN（Single ClientAccess Name）的特性。SCAN是一个域名，可以解析至少1个IP，最多解析3个SCAN IP，客户端可以通过这个SCAN 名字来访问数据库，另外SCAN ip必须与public ip和VIP在一个子网。启用SCAN 之后，会在数据库与客户端之间，添加了一层虚拟的服务层，就是SCAN IP和SCAN IP Listener，在客户端仅需要配置SCAN IP的tns信息，通过SCANIP Listener，连接后台集群数据库。这样，不论集群数据库是否有添加或者删除节点的操作，均不会对客户端产生影响，也就不需要修改配置。对于SCAN相关的配置，有以下一些配置注意事项：
（1）主机的默认网关必须与SCAN以及VIP在同一个子网上。
（2）建议通过 DNS，按round-robin方式将 SCAN 名称（11gR2 和更高版本）至少解析为 3 个 IP 地址，无论集群大小如何。
（3）为避免名称解析出现问题，假设我们设置了三个SCAN地址，那么HOSTs文件当中不能出现SAN的记录，因为HOSTs文件当中的记录是静态解析，与DNS动态解析相悖。

四、网络参数

操作系统平台上关于网络的内核参数非常重要，直接决定私网公网数据传输的稳定性和性能。不过针对不同的操作系统，相关的参数设置也各有差异。
1、Linux。对于Linux平台的内核参数，有两个非常重要（net.core.rmem_default、net.core.rmem_max）。具体功能解释如下：
net.ipv4.conf.eth#.rp_filter：数据包反向过滤技术。
net.ipv4.ip_local_port_range：表示应用程序可使用的IPv4端口范围。
net.core.rmem_default：表示套接字接收缓冲区大小的缺省值。
net.core.rmem_max：表示套接字接收缓冲区大小的最大值。
net.core.wmem_default：表示套接字发送缓冲区大小的缺省值。
net.core.wmem_max：表示套接字发送缓冲区大小的最大值。
为了获得更好的网络性能，我们需要根据具体情况把以上两个参数从其默认值适当调整为原来的2-3倍甚至更高，关闭或者设置反向过滤功能为禁用0或者宽松模式2。
2、AIX。对于AIX平台的内核参数，以下设置是从Oracle官方文档摘出的最佳配置：
tcp_recvspace = 65536；
tcp_sendspace = 65536；
udp_sendspace = ((db_block_size *db_multiblock_read_count) + 4096) ；
udp_recvspace = 655360；
rfc1323 = 1；
sb_max = 4194304；
ipqmaxlen = 512；
第1、2个参数表示TCP窗口大小，第3、4个参数表示UDP窗口大小。rfc1323启用由 RFC 1323（TCP 扩展以得到高性能）指定的窗口定标和时间图标。窗口定标允许 TCP 窗口大小（tcp_recvspace 和 tcp_sendspace）大于 64KB（65536）并且通常用于大的 MTU 网络。默认为0(关)，如果试图将 tcp_sendspace 和 tcp_recvspace 设为大于 64 KB则需要先修改此值为1。ipqmaxlen 表示指定接收包的数目，这些包可以列在 IP 协议输入队列中。sb_max指定一个 TCP 和 UDP 套接字允许的最大缓冲区大小。

数据库服务器全部虚拟化部署与虚拟机物理机混合部署的优劣势比较？

1、 这种物理机和虚拟机结合的思路很好，对于重要系统，第一次准备上到虚拟化，总是有很大的担心，这可以是一个逐步适应的过程，根据实际运行情况，慢慢转向虚拟化；
2、 我们在进行虚拟化迁移改造过程中，对于Oracle数据库集群的迁移，采用的方案就是“虚实结合”，先将其中一个物理节点迁移改造成虚拟化节点，稳定运行1至2周后，再将另一个物理节点迁移改造至虚拟化节点；
3、 绝大部分的Oracle数据库目前都运行在Power虚拟化资源池中，与传统使用物理机环境相比较，从标准统一性、资源利用率、维护工作量等都有更多的改善，对于虚拟化环境运行Oracle数据库的管理、运维等方面也都在逐步提升；
4、 从我们目前运行情况来看，可靠性和性能上暂时还没有出现过大问题，如果在虚拟化环境运行数据库，建议对物理CPU、内存资源池保留一定的余量，防止系统突发性能需要在线扩展相关资源。