![](http://static.blog.csdn.net/images/category_icon.jpg)
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能够自动切换到另外一个节点上,无单点故障问题。