大话 ORACLE RAC
第一部分
集群理论篇
第三章：
Oracle Clusterware
Clusterware 和 RAC 的关系：
在整个RAC集群中，实际上有两个集群环境存在。一个是由Clusterware软件组成的集群，另一个是由
Database组成的集群。
其中，Clusterware集群负责管理整个集群环境中的硬件资源，并为上层的Database集群提供基础服务。
二者之间的关系非常类似单机环境下应用程序和OS的关系。可以把这个Clusterware集群看作是OS Kernel
,那么RAC就是其上的Database应用。
严格意义上说，RAC特指借助于"某种集群件产品"搭建出来的一个"多实例,单一数据库"的环境,也就
是上面提到的第二个集群环境.
Oracle Clusterware 环境的组成：
Oracle Clusteware 是一个单独的安装包，一旦安装部署好后，每个节点上的Oracle Clusterware
会自动启动。Oracle Clusterware的运行环境由两个磁盘文件夹，若干后台进程及网络元素组成。
磁盘文件：
Oracle Clusterware 在运行过程中，需要两个文件，分别叫做OCR和Voting Disk，这两个文件必须
放在共享存储上。从前面的基础知识中已经知道，集群环境需要解决一两个问题----脑裂和健忘。
这两个文件就是用于针对这两个问题的。
这两个文件必须放在裸设备上，每个文件分配100MB大小就足够了。 ？？？？？
OCR：
(1)OCR Keys
解决脑裂的问题，Oracle采用的方法就是把这个配置文件放在共享的存储上，这个文件就是OCR Disk.
OCR中保存整个集群的配置信息，配置信息以"Key-value"的形式保存其中。
用户在安装过程中指定的OCR的路径会被记录在/etc/oracle/ocr.loc(LINUX)文件中。Oracle Clusterware
在启动时，会根据这里的内容从指定位置读入OCR内容，ocr.loc文件内容如下：
ocrconfig_loc=/dev/raw/raw130
local_only=FALSE
整个OCR的信息是个树形结构，有三大分支，分别是SYSTEM，DATABASE和CRS.
(2)OCR Process
在Oracle Clusterware的运行过程中，并不是每个节点都能操作OCR Disks的。
具体地说，每个节点在内存中都有一份OCR内容的拷贝，这份内存叫做OCR Cache。每个节点都有一个
OCR Process来读写OCR Cache内容。但只有一个节点的OCR Process能够读写OCR Disk中的内容，这个
节点叫做OCR Master节点。这个节点的OCR Process负责更新本地和其他节点的OCR Cache内容。
所有需要OCR内容的其他进程，比如OCSSD，EVM等都叫做Client Process,这些进程不会直接访问OCR
Cache，而是向OCR Process发送请求，借助OCR Process获得内容，如果想要修改OCR内容，也是由
该节点的OCR Process向Master node的OCR Process提交请求，由Master OCR Process完成物理读写，
并同所有节点的OCR Cache中的内容。
Voting Disk:
Voting Disk 这个文件主要用于记录节点中成员状态，在出现"脑裂"时,仲裁哪个partition
获得集群的控制权，而其他 Partition必须从集群中剔除。
$ crsctl query css votedisk
0 0 /dev/raw/raw2
这里显示votedisk存放在/dev/raw/raw2上
Clusterware后台进程：
主要是：CRSD，CSSD，EVMD。
1，OCSSD
OCSSD这个进程是Clusterware最关键的进程，如果这个进程出异常，会导致系统重启。这个进程提供
CSS服务。CSS服务通过多种心跳机制，实时监控集群健康状态，提供脑裂保护等基础集群服务功能。
CSS服务有两种心跳机制：一种是通过私有网络的Network Heartbeat(MC,MisCount),另一种是通过Voting Disk的
Disk Heartbeat.(IOT)
$ crsctl get css disktimeout
200
$ crsctl get css misscount
60
2,CRSD
CRSD是实现"高可用性（HA)"的主要进程，它所提供的服务叫做CRS服务。
Oracle Clusterware 是位于集群层的组件，它要为应用层资源（CRS Resource)提供"高可用性"服务。
因此，Oracle Clusterware必须要监控这些资源，并在这些资源运行异常时进行干预，包括关闭，重启
进程或者转移服务。而CRSD进程提供的就是这些服务。
默认情况下，CRS会自动重启资源五次，如果还是失败，则放弃尝试。
3，EVMD
EVMD这个进程负责发布CRS产生的各种事件。这些事件可以通过两种方式发布给客户----ONS和Callout Script
用户可以自定义回调脚本，放在特定的目录下，这样当某些事件发生时，EVMD会自动扫描该目录，并调回用户的
脚本，这种调用是通过racgevt进程来完成的。
EVMD进程除了负责发布事件之外，它还是CRSD和CSSD两个进程之间的桥梁。
CSS和CRS两个服务之间的通信都是是通过EVMD进程来完成的。
4，RACGIMON
RACGIMON这个进程负责检查数据库的健康状态，负责Service的启动，停止，故障转移（Failover).
这个进程会建立到数据库的持久连接，定期检查SGA中的特定信息，该信息由PMON进程定时更新。
5，OPROCD
IO隔离的功能。在非LINUX平台上，并且没有使用第三方的集群件时，会看到这个进程。
在LINUX平台上，是利用hangcheck-timer模块来实现"IO隔离"功能的。
网络组件：
私有连路专门用于节点间的通信，通信内容包括Network Heartbeat和Cache Fusion.这所以
要开辟一条单独的链路，是因为这些通信内容特点是：大数据量，低迟延。
如果和对外链路混在一起，会占用对外服务的带宽，并且集群的可靠性得不到保证。Oracle
支持多种方式实现Private Network,其中最为廉价常用的地G级以太网。
TCP/IP模型：
IP层
TCP层
VIP原理：
如果没有VIP，Oracle客户端是靠"TCP/IP"协议栈超时来判断服务器故障的，而TCP/IP协议栈是
作为OS Kernel的一部分实现的，不同的OS会有不同的阈值，用户获知数据库异常的时间完全取
决于OS Kernel的实现。因此，ORACLE RAC引入了VIP，从而避开了对TCP协议栈超时的依赖。
VIP和IP最大的不同是:
IP 是固定的，而VIP是浮动的。
节点1上的监听器只监听VIP1,Public IP1 两个IP地址，并没有监听VIP2
这个地址。也就是说，在应用层没有对应的程序接收这个数据包，这个错误能够被立即捕获。
IP利用的是TCP层超时，而VIP利用的是应用层的立即响应。
VIP特点：
1，VIP是在Clusterware 安装最后阶段，通过脚本VIPCA创建的。
2，VIP作为一个Nodeapps类型的CRS Resource注册到OCR中，并由CRS维护状态
3，VIP会绑定到节点的Public网卡上；那么Public 网卡上就有两个地址了；
4，当某个节点发生故障时，CRS会把故障节点的VIP转移到其他节点上；
5，每个节点的LISTENER会同时在Public 网卡的Public IP和VIP两个地址上监听
6，客户端的tnsname.ora一般人配置指向节点的VIP。
Clusterware 的日志体系：
Oracle Clusterware不像数据库那样，有丰富的视图，工具可以用来辅助诊断，它的日志
和trace文件是唯一的选择。
目录：$CRS_HOME/log/[node]
1，alert.log 类似于数据库的alert.log,一般应当作为检查的起点
2，crsd,cssd,evmd,分别为三个目录，分别对应着CRS三个同名的进程日志。crsd.log,cssd.log,evmd.log
3,racg,这是个目录，这里面放置的是所有的nodeapp的日志，包括ONS和VIP;eg,ora.dbp.ons.log
4,client,这个目录放置的是工具执行日志，Oracle Clusterware 提供了许多命令得工具，
比如：ocrchec,ocrconfig,ocrdump,oifcfg和clscfg,eg:ocrconfig_6836.log
