Oracle RAC的机制与测试方法

1.RAC原理

Oracle 数据库系统是美国Oracle公司（甲骨文股份有限公司）提供的以分布式数据库为核心的一组软件产品，是目前最流行的客户/服务器(CLIENT/SERVER)或B/S体系结构的数据库之一,至今仍在数据库市场上占有主要份额。

1.1 RAC原理

对于每个软件相关从业人员来说，都有必要了解一下Oracle数据库，下面我将对Oracle RAC原理做如下介绍。

Oracle RAC是Oracle Real Application Cluster的简写，官方中文文档一般翻译为“真正应用集群”。RAC集群是由若干物理机组成，每个物理机为一个节点，这些节点间通过网线连接（也叫心跳网络）。每个节点上都运行一个实例，这些实例通过CRS（CRS通过一系列的进程和服务来保证集群的运行，提供高可用性）的协助，共同操作一个数据库,是一个典型的“多实例，单数据库”架构，数据库被所有节点共享、并行访问。共享存储是RAC架构的核心。数据库的数据文件、控制文件、参数文件、重做日志文件等等都要放到共享存储上，各节点可以对这些文件进行并行访问。如果其中某个节点发生故障，RAC能够将连接自动切换到另外一个节点上，无单点故障问题，从而实现应用的无缝切换。

下图为基本的RAC拓扑图：

2.RAC 特性

依上文所说，RAC是一堆特性应用的集合，下面重点介绍几个特性：VIP漂移、脑裂和IO隔离。

2.1 VIP漂移特性

这里有必要解释下RAC为什么要使用VIP地址：在TCP/IP四层模型中，TCP header中最重要的信息是源端口和目标端口，IP header 中记录的最重要的信息是源IP和目标IP地址，而数据库监听中记录了IP地址和端口号，位于应用层，所以客户端的连接请求只有发现TCP层超时才能感知数据库或者是监听出了问题。TCP/IP协议栈超时，其时间阀值由OS内核决定，每个操作心跳的阀值不相同。为了解决TCP/IP协议栈超时问题，Oracle RAC引进了VIP。

VIP 和一般的IP不同的是：一般的IP是固定到物理网卡上的，VIP是浮动的。一旦某个节点出现了故障，其上运行的VIP会漂移到活着的节点上，但是活着的节点上的监听里找不到该VIP的地址。应用程序立马会感知到，并向其他VIP地址发起连接请求。捕获错误的时间大大缩短。

VIP漂移原理：假设有两个节点的RAC，分别是节点1和节点2。正常运行时节点1上有VIP1，节点2上有VIP2 ；当节点1发生故障，RAC 会做如下操作：

1） CRS 在检测到节点1异常后，会触发Clusterware 重构，最后把节点1剔除集群，由节点2组成新的集群。  

2）RAC的Failover 机制会把节点1的VIP转移到节点2上（也就是VIP漂移），这时节点2的PUBLIC 网卡上就有3个IP 地址： VIP1、VIP2、PUBLIC IP2。

3）用户对VIP1的连接请求会被IP层路由转到节点2。

4）因为在节点2上有VIP1的地址，所有数据包会顺利通过路由层、网络层、传输层。    

5）但是节点2上只监听VIP2和PUBLIC IP2的两个IP地址。并没有监听VIP1，故应用层没有对应的程序接收这个数据包，这个错误立即被捕获。

6）客户端能够立即接收到这个错误，之后客户端会重新发起向VIP2的连接请求。VIP2就自动接管交易处理。

2.2 脑裂

在集群环境中，节点间需要心跳机制了解彼此的健康状况，假如心跳出了故障，就会出现脑裂。这时每个节点还在正常运行，每个节点都会认为其他节点都不复存在，自己是唯一的幸存者，之后就会控制整个集群。数据是共享的，如果每个节点都想控制独享，势必会破坏共享数据的完整性和一致性。这样的状况就是脑裂。

为了解决这个脑裂问题，通过投票机制，获得高票数或是最早到达的获得投票，幸存，其他节点被踢出。Oracle RAC中的Voting Disk用来记录节点间成员状态，出现脑裂时，仲裁哪个节点获得控制权，其他的节点被剔除。

2.3 IO隔离

IO隔离是上一个问题的延伸，投票机制虽然已经判断出哪个成节点该获得集群掌控权，哪些节点被剔除，但仅仅这样做是不够的，还必须保证被剔除的节点不能操作共享数据。为了限制已踢出节点对共享数据的访问，必须进行IO隔离。Oracle RAC采取的是直接重启故障节点。

3.RAC测试案例

上文介绍了RAC的原理以及三个特性，下面我将重点讲解“如何在测试中测试RAC的有效性”。

3.1 测试案例1名称：RAC有效性测试-异常关机

测试目的：

验证系统数据库RAC中的一个节点发生故障后，另一个节点能否自动接管交易处理；以及故障恢复后，节点处理能力能否恢复正常。

测试方法：

1）使用HP LoadRunner模拟客户发压,按照混合模型的比例,以被测试系统最大处理能力的50%作为负载压力向被测试系统施压，待系统稳定运行5分钟；

2）在某一台数据库服务器上手工执行halt -q(不同OS命令有区别)，模拟异常宕机；

3）继续稳定运行5分钟；

4）恢复故障节点，同时启动该节点上的Oracle 实例；

5）继续稳定运行5分钟；

6）执行回切操作。

预期测试结果：

1）步骤3后被测试系统数据库RAC切换成功，切换过程中，交易响应时间延长

2）切换后VIP漂移到另一个实例；

3）交易在1分钟内能够100%恢复正常，交易错误率、响应时间均满足测试指标，各主机资源使用正常；

4）步骤5后故障节点恢复后，该节点实例不接管交易，连接也不恢复，该实例不处理交易；

5）步骤7后执行回切操作后，服务器状态恢复为初始状态，交易由原主机处理并稳定运行。

实际测试结果：

LoadRunner总体趋势图

节点1： CPU趋势图

节点2：CPU趋势图

查看VIP是否漂移，当节点1故障后，查看节点2的网卡上有节点1的VIP地址，说明节点1的VIP地址漂移到节点2的网卡上。

测试结果分析：

从上述测试结果的图表和日志截图可以清楚的看到：节点1模拟宕机后，RAC切换成功，节点1的VIP 漂移至节点2；TPS下降，交易有少量失败，40秒内TPS完全恢复。

恢复节点1后，交易由原主机节点1处理并稳定运行。

测试结果符合预期结果，测试结果通过。

3.2 测试案例2名称：RAC有效性测试-停实例(shutdown abort)

测试目的：

考察系统在一定并发下,手动异常停止一个数据库实例后，另一个数据库实例能否自动接管交易处理；以及故障恢复后，节点处理能力能否恢复正常。

测试方法：

1）使用测试工具LoadRunner发压，按照混合测试场景中交易的比例,以被测试系统最大处理能力的50%作为负载压力向被测试系统施压，稳定运行5分钟；

2）手动（shutdown abort）停止一个数据库实例，场景持续运行5分钟；

3）启动停止的数据库实例，场景持续运行5分钟；

4）执行回切操作，场景持续运行5分钟。

预期测试结果：

1.步骤2手动停止数据库实例后，另一节点实例会很快接收请求（Failover机制生效）。切换后停掉实例的节点，CPU、IO下降；正常接收交易实例的节点，CPU、IO上升。MTTR（平均失效恢复时间）小于1分钟，失效交易处理能力恢复水平99.99%；

2.步骤3重启停止节点实例后，连接正常，与切换后保持一致；

3.执行回切操作后，服务器状态恢复为初始状态，交易由原主机处理， 并稳定运行。

实际测试结果：

LoadRunner总体趋势图

节点1：128.196.36.22 CPU利用率图

节点2：128.196.36.25  CPU利用率图

测试结果分析：

1）手动停止节点1实例后，节点2实例会很快（2秒内）接收请求。停掉实例的节点1 ，CPU、IO下降，接收交易的节点2，CPU、IO上升；交易有少量失败，在20秒内TPS完全恢复；

2）重启节点1实例后，AP为长连接，该实例的连接不恢复；交易不受影响；

3）执行回切操作后，TPS下降，交易有少量失败，40秒内TPS完全恢复，交易由原主机节点1处理，并稳定运行；

4）实际测试结果符合预期结果，测试结果通过。

3.3 测试案例3名称：AC有效性测试-心跳网络异常

测试目的：

验证数据库RAC中的心跳网络（主备网卡置down）异常后，另一节点能否自动接管交易处理；以及故障恢复后，节点处理能力能否恢复正常。

测试方法：

1）使用测试工具LoadRunner发压，按照混合模型的比例以被测试系统最大处理能力的50%作为负载压力向被测试系统施压；

2）场景平稳运行5分钟时，将节点1的网卡置down，观察各交易错误率、处理能力、响应时间及各主机资源情况；验证VIP是否可以正常切换；

3）恢复该节点心跳主备网卡，重启CRS，交易稳定运行5分钟，观察被测试系统交易恢复情况；

4）场景结束，分析和记录测试结果。

预期测试结果：

1）步骤2后，实例名权重大的实例重启，主机不重启；

2）步骤3后，CRS能正常启动，数据库可正常启动并加入RAC。

实际测试结果：

TPS趋势图

节点1：CPU趋势图

节点2：CPU趋势图

测试结果分析

1）宕掉节点1的心跳主备网卡，出现脑裂，节点2实例重启，CRS重启，节点2的VIP漂移到节点1；TPS下降，交易有少量失败，在50秒内TPS完全恢复至100%。

2）节点1心跳主备网卡故障恢复后，VIP回漂，数据库可正常启动并加入RAC，交易不受影响。

3）实际测试结果符合预期结果，测试结果通过。

从以上三个案例可以看出：如果其中某个节点发生故障，RAC能够自动切换到另外一个节点上，无单点故障问题。