Oracle RAC的机制与测试方法

 

Oracle RAC的机制与测试方法

标签： rac 机制 测试

2016-05-25 09:54 1150人阅读 评论(0) 收藏 举报

 分类：

oracle（2） 

 

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 地址： VIP一、VIP二、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可以自动切换到另一个节点上，无单点故障问题。