ORACLE rac 的一些基本概念

集羣件的組件
oracle的集羣件包括以下後臺進程：cluster synchronization service（css）
cluster ready services（crs） event manager （evm）


CSS：This component manages the cluster configuration by controlling which nodes are members of the
cluster. When a node joins or leaves the cluster, CSS notifies the other nodes of the change in configuration.
If this process fails, then the cluster will be restarted. Under Linux, CSS is implemented
by the ocssd daemon, which runs as the root user.（通過管理集羣中節點成員身份完成整個集羣的配置工作，每當有新節點加到集羣或者有節點離開時，css負責通知集羣的所有節點變更進羣配置信息）


CRS:This component manages high availability operations within the cluster. Objects managed by CRS
are known as resources and can include databases, instances, services, listeners, virtual IP addresses,
and application processes. By default, CRS manages four application process resources: Oracle Net
listeners, virtual IP addresses, the Global Services Daemon (GSD), and the Oracle Notification Service
(ONS). Configuration information about each resource is stored in the Oracle Cluster Registry
(OCR). When the status of a resource changes, CRS generates an event.
CRS monitors resources, such as instances and listeners. In the event of the failure of a resource,
CRS will attempt to automatically restart the component. By default, CRS will attempt to restart the
resource five times before giving up.
Under Linux, CRS is implemented as the crsd daemon, which runs as the root user. In the
event of a failure, this process restarts automatically.（負責集羣的高可用性。被crs管理的對象叫做集羣資源，這些資源包括數據庫、實例、服務、監聽器、vip地址以及應用程序
默認情況下crs 管理4個應用程序進程：監聽器、vip地址、GSD、ONS，這些資源都保存在ocr中。每當某個資源發生了變化，crs就會生成一個事件）


EVM:The EVM component publishes events created by Oracle Clusterware. Under Linux, EVM is implemented
as the evmd daemon, which runs as the root user.
You can specify callout scripts, which will be executed by EVM when a specified event occurs.
These callouts are managed by the racgevt process.
In addition to the background processes, Oracle Clusterware also communicates with the
Oracle Notification Service (ONS), which is a publish and subscribe service that communicates FAN
events to clients.（負責對外發布crs生成的事件。我們可以指定回調腳本，當有事件發生時，EVM就可以調用我們自己的腳本，這種調用時通過racgevt進程進行的。）




ORACLE Cluster Registry（OCR）;:The Oracle Cluster Registry (OCR) maintains cluster and database configuration information for
RAC and Oracle Clusterware resources, including information about nodes, databases, instances,
services, applications, and listeners.
The OCR is similar in many ways to the Windows registry. Information is stored in a hierarchy
of key-value pairs within a directory tree structure. The OCR can be updated using EM, the Server
Control Utility (SRVCTL), and DBCA.
The OCR must be located on shared storage and must be accessible from all nodes. On each
node, the location of the OCR is specified in the file /etc/oracle/ocr. loc:
ocr 負責維護整個集羣的配置信息，包括rac以及clusterware資源，包括的信息有節點成員、數據庫、實例、服務、監聽器、應用程序等。




Voting Disk
The voting disk, which must reside on shared storage, manages cluster membership information. It
is used by RAC to determine instances that are members of the cluster. It is also used to arbitrate
cluster ownership between the remaining instances in the event of a network failure.
In Oracle 10.2 and above, you can to create multiple voting disks. Oracle recommends configuring
an odd number of voting disks (e.g., three or five). By default in Oracle 10.2, the OUI will
create three voting disks, although you can specify a single voting disk if your storage provides mirroring
at the hardware level. The voting disk is critical to the operation of Oracle Clusterware and of
the database. Therefore, if you choose to define a single voting disk or you are still using Oracle 10.1,
you should use external mirroring to provide redundancy.


voting disk: oracle clusterware 利用這個文件管理集羣的節點成員的身份，根據這裏的記錄判斷哪個節點數據集羣的成員。
並在出現"腦裂"時，仲裁哪個partition 獲得集羣的控制權而其他partition必須從集羣中剔除


Administering Oracle Clusterware
CRSCTL: Performs various administrative operations for Oracle Clusterware
CRS_STAT: Reports the current state of resources configured in the OCR
OCRCONFIG: Performs various administrative operations on the OCR
OCRCHECK: Verifies the integrity of the OCR
OCRDUMP: Dumps the contents of the OCR to a text file


CRSCTL :must be run as root






rac的網絡
public  網絡 用於對外提供數據查詢等服務
private 網絡  用於rac心跳網絡和cache fusion
virtual 網絡 是在clusterware最後安裝階段，通過vipca創建的；作爲一個nodeapps類型的crsresource註冊到ocr中，並由crs維護狀態；
vip會綁定到節點的public 網卡上；那麼public 網卡就有兩個地址；相對於vip，這塊網卡的原地址叫做public ip
當某個節點發生故障時，crs會把故障節點的vip轉移到其他節點上；每個節點的listener會同時在public網卡的public網卡的public  ip 和 vip兩個地址上監聽；
客戶端的tnsnames.ora一般會配置指向節點的VIp




VIP原理：
假設是一個兩個節點的rac環境，正常運行時每個節點都會有一個VIP，節點1叫做VIP1，節點2叫做VIP2。現在節點2發生了故障，比如異常關機。


1、crs在檢測到節點2的異常後，會觸發clusterware的重構，最後把節點2剔除集羣。由節點1組成新的集羣
2、節點2的VIP 轉移到節點1,；這是節點1的public NIC就會有vip1，vip2兩個VIP和public ip1 三個ip地址；這時節點1的vip所在的網卡就會處於混雜模式（promiscuous mode）,
併發出ARP包通知其他節點，vip2對應的MAC地址已經改變了。
3、用戶對VIP2的連接請求會被ip層（ip層的主要功能是確定路由，而不負責數據傳送完整性，不關心數據的成功送達與否）路由到節點1.
4、因爲節點1現在有了vip2地址，所以數據包會順利的通過鏈路層、網絡層、傳輸層。
5、但是節點1上的監聽器值監聽vip1和public ip1兩個ip地址，並沒有監聽vip2這個地址，也就是說，在應用層沒有對應的應用程序接受這個歌數據包，這個錯誤能夠立即被捕獲。所以
連接請求雖然來到了節點1，但是節點1會立即返回一個錯誤消息給客戶端。
6、客戶端能夠立刻收到這個錯誤，客戶端會立即做failover，使用另一個vip地址，也就是客戶端會重新發起向vip1的連接請求


rac的後臺進程
1、LMSn：這個進程是cache fusion的主要進程，負責數據塊在實例間的傳遞，對應的服務叫做GCS（Global Cache Service），這個進程的名稱來源於Lock Manager Service
   此進程的數量通過參數 GCS_SERVER_PROCESSES來控制 默認是2個，取值範圍0-9.
2、LMD：這個進程負責的是Global Enqueue Service（GES）.具體來說，這個進程在多個實例之間協調對數據塊的訪問順序，保證數據的一致性訪問。他和前面的LMSN進程的GCS服務和GRD
構成RAC最核心的功能cache fusion
3、LCK 這個進程負責non-cache fusion資源的同步訪問，每個實例有一個lck進程
4、LMON：各個實例的LMON進程會定期通信，以檢查集羣中各節點的健康狀態，當某個節點出現故障時，負責集羣重構，GRD恢復等操作，它提供的服務叫做Cluster Group Services（CGS）
  LMON 被賦予了自檢功能，這個功能就是LMON提供的CGS服務。這個服務有以下幾個要點
  a、LMON提供了節點監控功能：這個功能是用來記錄應用層各個節點的健康狀態，節點的健康狀態時通過保存在GRD中的位圖來記錄的。每個節點1位，0代表節點關閉，1代表節點正常運行。
    各個節點的LMON會互相通信，確認這個位圖的一致性。
  b、節點上的LMON進程間會定期進行通信，這個通信可以通過CM層完成也可以不通過cm，直接通過網絡層。
  c、lmon可以好下層的clusterware合作也可以單獨合作。當lmon檢測到實例級別的”腦裂時“，Lmon會先通知下層的clusterware，但是lmon不會無盡等待clusterware層的處理結果。如果發生
  等待超時，lmon會自動觸發IMR（instance membership reconfiguration）。lmon進程提供的IMR功能能夠看做是oracle在數據庫層提供的”腦裂“、”io隔離機制“
  d、lmon主要藉助兩種心跳機制來完成健康監測。
  1、節點間的網絡心跳（network heartbeat）：可以想象成節點間定時發送ping包，檢測節點狀態
  2、通過控制文件的磁盤心跳（controlfile heartbeat）：每個節點的CKPT進程每3秒鐘更新一次控制文件一個數據塊，這個數據塊叫做checkpoint progress record；控制文件時共享的
  ，因此是李健可以相互檢查對方是否及時更新以判斷狀態。
5、DIAG :監控實例的健康狀態，並在實例運行時錯誤收集診斷數據記錄到Alert.log日誌中。
6、GSD負責從客戶端工具接受用戶命令。爲用戶管理提供接口  


 RAC Split-Brain決議的投票算法


        獲知“裂腦”是治療“癲癇”病的一種手術。醫生們認爲癲癇病發作是由於大腦“異常放電”所至。
        爲了阻止“異常放電”波及整個大腦（左、右半腦），就用手術來割斷病人左右腦的連接神經。
        使今後病人在發病時至少還有半個大腦正常、能控制行爲。但施行過手術的所謂“裂腦人”在術後有一段不適應期，
        表現得行爲分裂，彷彿體內存在着2個人，時常要發生衝突。
        例如，右腦想讓一隻手去臉上撓癢癢，左腦卻不認同、以爲是誰的手要“登鼻子上臉”就讓另一隻手去阻止，
        於是明明是自己的2隻手，卻互不相讓、扭在一起扳起了手腕
        
        計算機的行爲和人的行爲存在相同之處
        
        在集羣裏，節點間通過心跳（也就是，人左右腦的連接神經）瞭解彼此的健康狀況，以確保協同作業
        如果只是心跳出了狀況，但各節點還可以正常運行（也就是，人左右腦還是ok的）
        這時，每個節點都認爲其他的節點宕機了， 自己是整個集羣環境中的"唯一建在者"
        自己應該獲得共享磁盤即資源）的控制權
        於是明明是共享盤的子節點，卻互不相讓、扭在一起扳起了手腕
      
         
        集羣重構時，所有的active節點和正在加入集羣的節點都會參與到reconfig中，
        那些沒有應答(ack)的節點都將不再被歸入新的集羣關係中。
        集羣重構包括多個階段:
          1.初始化階段 — reconfig manager(由集羣成員號最低的節點擔任)向其他節點發送啓動reconfig的信號
          2.投票階段 — 節點向reconfig manager發送該節點所瞭解的成員關係
          3.腦裂檢查階段 — reconfig manager檢查是否腦裂
          4.驅逐階段 — reconfig manager驅逐非成員節點
          5.更新階段 — reconfig manager向成員節點發送權威成員關係信息
      
        在腦裂檢查階段，Reconfig Manager會找出那些沒有Network Heartbeat而有Disk Heartbeat的節點，
        並通過Network Heartbeat(如果可能的話)和Disk Heartbeat的信息來計算所有競爭子集羣(subcluster)內的節點數目，
        並依據以下2種因素決定哪個子集羣應當存活下去:
          1.擁有最多節點數目的子集羣
          2.若子集羣內數目相等則爲擁有最低節點號的子集羣，比如在一個2節點的RAC環境中總是1號節點會獲勝
          
        注意：這裏說的低節點號不是指 RAC節點(1號 節點 ,2號節點)這樣的節點號， 而是實際 上下文的節點號， olsnodes -n 獲得的節點號
          
        所以，投票只是對“健康狀況”的報道，而不是用來決定誰應該留下來 
        
        假設集羣中共有3個節點，其中1號實例沒有被啓動，集羣中只有2個活動節點(active node)，發生2號節點的網絡失敗的故障，因2號節點的member number較小故其通過voting disk向3號節點發起驅逐 
        
        若沒有vote disk，在network heartbeat不可用的情況下， cluster分裂成多個 subcluster時， 
        它們如何知道對方的subcluster中node的數量呢？
        它們如何發送killblock 以實現evictee的驅逐通知呢？
        votedisk都是讀的
        
        
 其實VOTE DISK的個數和票數沒關係
        幾個都是1票
        只不過對於VOTE DISK它是多數可用的工作原理，我們冗餘這個只是保證當VOTE DISK出問題的時候所有節點可以繼續工作
          當你有 1 個vote disk，並且它損壞了，則集羣停止工作
          當你有 2 個並且有 1 個損壞，則集羣停止工作，因爲，可用1/2沒有>不可用1/2；注意是>;而不是>=
          當你有 3 個並且有 1 個損壞，則集羣還是好的，因爲，2/3 > 1/3
           當你有 4 個並且有 1 個損壞，則集羣也還是好的，因爲，3/4 > 1/4
           當你有 3 個並且有 2 個損壞，則集羣停止工作，因爲，1/3 < 2/3
           當你有 4 個並且有 2 個損壞，則集羣停止工作，因爲，可用1/2沒有>不可用1/2
          由上可知，oracle推薦vote disk爲奇數個，3個votedisk ，那麼其中一個節點只要能訪問其中2個就 ok，
          而如果共有2個votedisk 那麼節點需要能正常訪問所有的vote disk，如果是 4個ok嗎？ 當然，4個也可以，
          但4個和3個在出故障時是一樣的，這樣你便浪費了一個disk。