RAC的基本概念

最新推荐文章于 2021-04-03 06:11:06 发布

cuizhan9589

最新推荐文章于 2021-04-03 06:11:06 发布

阅读量819

点赞数 1

文章标签：数据库运维人工智能

RAC的基本概念

集群分类

集群可以按照两种方式进行分类，根据组成集群系统的计算机体系结构是否相同。可以分为同构和异构两种；更常见的方法是跟踪不同的功能分为以下三类。

高性能计算集群：

高性能计算集群采用将计算任务分配到不同计算节点来提高整体计算能力，因此主要应用在计算科学领域。这个集群是并行计算的基础，其处理能力与真正超级并行机相等，并且具有优良的性价比。这个集群常见于科研机构，企业环境中很少会用到这种环境。

负载均衡计算集群（LB）：

这个集群系统会计算应用负载或者网络流量负载，非常适合于提供静态内容网站。每个节点都可以处理一部分负载，并且可以根据节点负载进行动态平衡，以保持负载平衡。对于网络流量，负载均衡算法还可以根据每个节点不同的可用资源或者网络的特殊环境进行优化。

高可用集群（HA）：

高可用性集群（HA）侧重于提高系统的可用性，它通过集成硬件和软件的容错性来实现整体服务的高可用。若果集群中的某个节点发生了障碍，那么将由另外的节点代替它。即使多个节点发生故障，整个系统环境也保证用户能够访问。

在实际应用的集群系统中，HA和LB这两种基本类型经常会发生混合与交杂。RAC就是同事具有HA和LB两种能力。

集群环境的特殊问题

并发控制：

在集群环境中，关键数据通常是共享存放的。比如放在共享磁盘上。儿集群内各个节点的身份是对等的，所有节点对数据有相同的访问权利。这时就必须有某种机制能访问控制节点对数据的访问。

在RAC中，是利用DLM（Distribute Lock Management）机制来进行多个实例间的并发控制。

健忘症：

这个问题的发生在集群环境的配置文件不是集中存放，而是每个节点都有一个本地副本。在集群正常运行时，用户可以在任何节点更改集群配置，并且这会更改为自动同步到其他节点。

但考虑这一种场景：两个节点的集群，节点1正常因为维护需要被关闭，然后在节点2修改了某些配置，然后关闭节点2，启动节点1。因为之前的节点2做的配置修改没用同步到节点1，所有节点1启动后，它仍然是旧的配置文件工作，这时会造成配置丢失，也就是所谓的“健忘症”。

脑裂

在集群里，节点间需要通过某种机制（心跳）了解彼此间的健康状况，以确保各个节点协调工作。假若只是“心跳”出现故障，但各个节点还在正常运行。这时，每个节点都认为其他节点宕机，自己是整个集群环境中的“唯一建在者”，自己应该获得整个集群的“控制权”。在集群环境中，存储设备都是共享的，这意味这数据灾难，这样的一种状况就是“脑裂”。

解决这个问题的解决办法是使用投票算法（Quorum Algorithm）。下面是这种算法的官方定义：

因为这里重点研究其现实意义，所以不仅在字面上分析其定义。下面通过一个简单例子来介绍一个这个算法机理。

集群中每个节点需要心跳机制来通报彼此的“健康状态”，假设没收到一个节点的“通报”代表一票。对于一个三节点的集群，正常运行时，每个节点都会有3票（自己和另外两个节点的通报）。假设节点1的心跳出现故障，但是节点1还在运行：这时整个集群就分裂成两个小得Partition。节点1自己是一个Partition，节点2和节点3是一个Partition。这时就必须剔除一个Partition，应该剔除那个Partition？

这时节点2和节点3组成的Partition，每个节点有两票；节点1自己一个Partition，节点1只有一票。按照这个算法，节点2和节点3组成的小集群获得控制权，而节点1被踢出，由节点2和节点3组成新的集群继续对外提供服务。

如果集群只有两个节点，则上面的算法就没有用了，因为每个节点只有一票，没有办法比较。这时，就必须引入第三个设备Quorum Device。

Quorum Device通常采用的是共享磁盘，这个磁盘也叫做Quorum Disk。这个Quorum Disk也代表一票。当心跳出现故障时，每个节点同时争取Quorum Disk这一票，最早到达的请求被最先满足，后到达的这个节点就无法获得这一票。这时，最先获得Quorum Disk的节点就获得两票，而另外一个节点只有一票，就会被踢出集群。

IO隔离：

这个问题是上一个问题的延伸。当集群系统出现“脑裂”时，必须要能够判断那个节点应该获得集群掌控权，哪些节点要被赶出集群，这就是“投票算法”要解决的问题，前一个部分已经做了解释。

但仅仅这样做不够的，还必须保证被赶出的节点不能操作共享数据。因为这时该节点还在运行中，如果不加限制还有可能会修改共享数据。这是IO隔离（IO Fencing）要解决的问题。

IO Fencing实现有硬件和软件方式。对于支持SCSI Reserve/Release命令的存储设备，可以用SG命令实现。正常节点使用SCSI Reserve命令“锁住”存储设备，故障节点发现存储设备被锁住后，就知道自己被赶出集群了，也就是说知道自己出现了异常状况，就要自己重启，以恢复到正常工作状态，这个机制也叫做suicide（自杀）。Sun和Veritas使用的是这种机制。

STONITH（Shoot The Other Node In The Head）是另一种实现方式，这种方式直接操作电源开关。当一个节点发生故障时，另一节点如果能侦测到，就会通过串行口发出命令，控制故障节点的电源开关，通过暂时断电，而后又上电的方式使得故障节点被重启动。这种方式需要硬件支持。

Oracle RAC采用的是软件方式，直接重启故障节点。无论采用哪种方式，IO Fencing目的都是相同，为了保证故障节点不能再继续访问共享数据。

在上图中，RAC集群是由若干个物理计算机组成（每个叫做一个节点），这些节点通过网线连接（心跳线）。每个节点都运行一个实例（Instance），这些实例通过一个特殊的软件（Clusterware，集群件）的协助，共同操作一个数据库。从外部用户视角来看，他们看到的只有一个数据库。从逻辑看，RAC集群由存储层，网络层，集群件层，应用层4层组成。

存储层

RAC是一个多实例，单数据库系统。数据文件，联机日志，控制文件等文件在集群中只有一份。不管有几个节点，这些节点都平等地使用这些数据文件。这份数据一般都是采用EMC等存储阵列，每个服务器通过HBA卡和光纤连接在存储上。虽然RAC中有多个数据库实例，但只有一个数据库，这个数据库就保存在共享磁盘上。

在Oracle的术语中，实例和数据库这两个概念是不同的。实例特指由SGA内存和Background Process组成的运行实时环境，是一个动态的概念：而数据库特指数据文件，控制文件，日志文件这些保存在存储上得永久文件，是一个动态的概念。

Oracle的实例和数据库是n：1的关系（n>=1），在单实例环境中，因为二者是1:1的关系，所以二者的区别没有被特别的提及，两个名词经常混用。但是在RAC集群环境中，会有很多的实例，而数据库只有一份，所以区分这两个概念有重要意义。

网络层

在整个RAC环境下，实际有3个网络存在。一个由Public网卡接入的网络，用于对外提供数据查询等服务；；另一个是由Private网卡组成的私有网络，用于RAC心跳和Cache Fusion；第三个是存储设备，光纤交换机，每个节点的HBA卡组成的存储网络。前两个网络上面传输的IP数据，而后一个网络传输的SCSI数据。

集群软件

在单机环境下，Oracle运行的OS Kernel之上。OS Kernel负责管理硬件设备，并提供硬件访问接口。Oracle不会直接操作硬件，而是由OS Kernel代替它来完成对硬件的调用要求。

到了集群环境下，存储设备是共享的。OS Kernel的设计都是针对单机的，只能控制单机上多个进程间的访问。如果还依赖OS Kernel的服务，就无法保证多个主机间的协调工作。这时就需要引入额外的控制机制，在RAC中，这个机制就是位于Oracle和OS Kernel之间的Clusterware，它会在OS Kernel之前截获请求，然后和其他节点上Clusterware协商，最终完成上层的请求。

Clusterware层位置示意图

具体到Clusterware的实现，在Oracle 10版本之前，RAC所需要的集群软件是依赖于硬件厂商的，Sun，HP都有自己的集群软件产品。还有许多第三方产品，如Veritas。在不同的平台上实施RAC需要先安装和配置厂商的集群软件。而Oracle自己只提供Linux，Windows两种平台上得集群软件，也叫做Oracle Cluster Manager。这种环境无论对DBA还是系统管理员都提出更大的挑战，也为责任的推诿提供了借口。

从Oracle 10开始，这种诸侯混战的局面终于平息（Oracle越来越倾向于提供一站式服务）。从10.1版本开始，Oracle推出了一个“平台中立”的集群软件Cluster Ready Service（CRS），从此RAC不在依赖于任何厂商的集群软件，但CRS也至此对其他集成件产品的集成。RAC的实施是由DBA单枪匹马就可以完成。从10.2版本开始，这个产品改名为Oracle Clusterware。并且Oracle官方文档中宣称；这个产品并不局限于数据库的集群，其他软件都可以借助于API轻易的实现集群功能。因此也可以看出Oracle公司一统江湖的气魄。