【Oracle 集群】ORACLE DATABASE 11G RAC 知識圖文詳細教程之RAC 特殊問題和實戰經驗(五)


概述:寫下本文檔的初衷和動力,來源於上篇的《oracle基本操作手冊》。oracle基本操作手冊是作者研一假期對oracle基礎知識學習的匯總。然后形成體系的總結,一則進行回顧復習,另則便於查詢使用。本圖文文檔亦源於此。閱讀Oracle RAC安裝與使用教程前,筆者先對這篇文章整體構思和形成進行梳理。由於閱讀者知識儲備層次不同,我將從Oracle RAC安裝前的准備與規划開始進行整體介紹安裝部署Oracle RAC。始於唐博士指導,對數據庫集群進行配置安裝,前后經歷2,3個月的摸索。中間遇到不少問題。此文檔也將一一記錄整理。(本文原創/整理,轉載請標注原文出處: RAC 特殊問題和實戰經驗(五))

 本文極客學院入口:Oracle-RAC 體驗

白寧超

2015年7月18日10:28:41

在需要將一個 LUN (邏輯單元號)映射給多個節點、為集群提供一個共享的存儲卷時,同一個存儲 LUN 在各個主機端的 LUNID 必須是相同的。比如:

 (一) 在為多個 ESX 節點創建一個 VMFS 卷的時候

(二) 在雙機 HA 集群創建共享存儲的時候

時間一致性

集群模式下,各個節點要協同工作,因此,各主機的時間必須一致。因此,各主機的時間必須一致。各個節點之間的時間差不能超時,一般如果超過 30s,節點很可能會重啟,所以要同步各節點的時間。例如,需要配置一個 ntp 時鍾服務器,來給 RAC 的各個節點進行時間同步。或者讓節點之間進行時間同步,保證各個節點的時間同步,但是無法保證 RAC 數據庫的時間的准確性。

互聯網絡(或者私有網絡、心跳線)

集群必須依賴內部的互聯網絡實現數據通訊或者心跳功能。因此,采用普通的以太網還是其他的高速網絡(比如 IB),就很有講究,當然了,還有拿串口線實現心跳信息傳遞。此外,采用什么樣的網絡參數對集群整體的性能和健壯性都大有關系。

案例:

XX 市,4 節點 Oracle 10g RAC

操作系統采用的是 RHEL 4,按照默認的安裝文檔,設置網絡參數為如下值:

net.core.rmem_default = 262144

net.core.rmem_max = 262144

執行一個查詢語句,需要 11 分鍾,修改參數:

net.core.rmem_default = 1048576

net.core.rmem_max = 1048576

再次執行僅需 16.2 秒。

固件、驅動、升級包的一致性

案例:

XX 市,HPC 集群,運行 LS-DYNA(通用顯示非線性有限元分析程序)。

集群存儲系統的環境說明:存儲系統的 3 個 I/O 節點通過 FC SAN 交換機連接到一個共享的存儲。

    1. 節點使用的 FC HBA 卡為 Qlogic QLE2460;
    2. 光纖交換機為 Brocade 200E
    3. 磁盤陣列為 Dawning DS8313FF

故障現象

集群到貨后發現盤陣與機器直連能通,兩個設備接 200E 交換機不通。后經測試交換機 IOS 版本問題導致不能正常認出盤陣的光纖端口,與交換機的供貨商聯系更新了兩次 IOS,盤陣的端口能正常識別,但盤陣與機器相連還是無法找到盤陣。經過今天的測試發現三台 I/O 節點采用的 HBA 卡 firmware 版本不一致。最早接光纖交換機及與盤陣直連的的 I/O1 的 firmware 為 v4.03.02,今天又拿出來的兩台 I/O 節點 firmware 為 v4.06.03。用后兩台測試后盤陣、機器、交換機之間可以正常通信,到今天晚上為止沒有發現異常情況。從目前的情況判斷是QLE2460 firmware 為 v4.03.01 的 HBA 卡與 200E IOS V5.3.1 有沖突者不兼容導致的故障。至於新的 HBA 卡 firmware為 v4.06.03 與 200E IOS V5.3.1 連接的穩定性如何還要做進一步測試。

診斷處理結果

I/O 1 節點 HBA 卡的 fimware 升級到 v4.06.03 后連接 200E 找不到盤陣的故障已經得到解決。其實是一個 FCHBA 卡的固件版本不一致引起的問題。

共享文件 OCR 及 Voting Disk

Oracle Cluster Registry(OCR):記錄 OCR 記錄節點成員的配置信息,如 database、ASM、instance、 listener、VIP 等 CRS 資源的配置信息,可存儲於裸設備或者群集文件系統上。Voting disk : 即仲裁盤,保存節點的成員信息,當配置多個投票盤的時候個數必須為奇數,每個節點必須同時能夠連接半數以上的投票盤才能夠存活。初次之外包含哪些節點成員、節點的添加和刪除信息。

安裝

在 Oracle RAC 中,軟件不建議安裝在共享文件系統上,包括 CRS_HOME 和 ORACLE_HOME,尤其是 CRS 軟件,推薦安裝在本地文件系統中,這樣在進行軟件升級,以及安裝 patch 和 patchset 的時候可以使用滾動升級(rolling upgrade)的方式,減少計划當機時間。另外如果軟件安裝在共享文件系統也會增加單一故障點。如果使用 ASM 存儲,需要為 asm 單獨安裝 ORACLE 軟件,獨立的 ORACLE_HOME,易於管理和維護,比如當遇到 asm 的 bug 需要安裝補丁時,就不會影響 RDBMS 文件和軟件。

腦裂症(split brain)

在一個共享存儲的集群中,當集群中 heartbeat 丟失時,如果各節點還是同時對共享存儲去進行操作,那么在這種情況下所引發的情況是災難的。ORACLE RAC 采用投票算法來解決這個問題,思想是這樣的:每個節點都有一票,考慮有 A,B,C 三個節點的集群情形,當 A 節點由於各種原因不能與 B,C 節點通信時,那么這集群分成了兩個 DOMAIN,A 節點成為一個 DOMAIN,擁有一票;B,C 節點成為一個 DOMAIN 擁有兩票,那么這種情況B,C 節點擁有對集群的控制權,從而把 A 節點踢出集群,對要是通 IO FENCING 來實現。如果是兩節點集群,則引入了仲裁磁盤,當兩個節點不能通信時,請求最先到達仲裁磁盤的節點擁用對集群的控制權。網絡問題(interconnect 斷了),時間不一致;misscount 超時 等等,才發生 brain split,而此時為保護整個集群不受有問題的節點影響,而發生 brain split。oracle 采用的是 server fencing,就是重啟有問題的節點,試圖修復問題。當然有很多問題是不能自動修復的。比如時間不一致,而又沒有 ntp;網線壞了。。。這些都需要人工介入修復問題。而此時的表現就是有問題的節點反復重啟。

集群軟件

從 Oracle10g 起,Oracle 提供了自己的集群軟件,叫做 Oracle Clusterware,簡稱 CRS,這個軟件是安裝 oraclerac 的前提,而上述第三方集群則成了安裝的可選項 。同時提供了另外一個新特性叫做 ASM,可以用於 RAC 下的共享磁盤設備的管理,還實現了數據文件的條帶化和鏡像,以提高性能和安全性 (S.A.M.E: stripe and mirroreverything ) ,不再依賴第三方存儲軟件來搭建 RAC 系統。尤其是 Oracle11gR2 版本不再支持裸設備,Oracle 將全力推廣 ASM,徹底放棄第三方集群組件支持。

Oracle Clusterware 的心跳

Oracle Clusterware 使用兩種心跳設備來驗證成員的狀態,保證集群的完整性。

  • l   一是對 voting disk 的心跳,ocssd 進程每秒向 votedisk 寫入一條心跳信息。
  • l   二是節點間的私有以太網的心跳。

兩種心跳機制都有一個對應的超時時間,分別叫做 misscount 和 disktimeout:

  • l   misscount 用於定義節點間心跳通信的超時,單位為秒;
  • l   disktimeout ,默認 200 秒,定義 css 進程與 vote disk 連接的超時時間;

reboottime ,發生裂腦並且一個節點被踢出后,這個節點將在reboottime 的時間內重啟;默認是 3 秒。用下面的命令查看上述參數的實際值:

  • l  # crsctl get css misscount
  • l  # grep misscount $CRS_HOME/log/hostname/cssd/ocssd.log

在下面兩種情況發生時,css 會踢出節點來保證數據的完整,:

(一) Private Network IO time > misscount,會發生 split brain 即裂腦現象,產生多個“子集群”(subcluster) ,這些子集群進行投票來選擇哪個存活,踢出節點的原則按照下面的原則:節點數目不一致的,節點數多的 subcluster 存活;節點數相同的,node ID 小的節點存活。

(二) VoteDisk I/O Time > disktimeout ,踢出節點原則如下:失去半數以上 vote disk 連接的節點將在 reboottime 的時間內重啟。例如有 5 個 vote disk,當由於網絡或者存儲原因某個節點與其中>=3 個 vote disk 連接超時時,該節點就會重啟。當一個或者兩個 vote disk 損壞時則不會影響集群的運行。

如何查看現有系統的配置

對於一個已經有的系統,可以用下面幾種方法來確認數據庫實例的心跳配置,包括網卡名稱、IP 地址、使用的網絡協議。

 最簡單的方法,可以在數據庫后台報警日志中得到。使用 oradebug

SQL> oradebug setmypid

Statement processed.

SQL> oradebug ipc

Information written to trace file.

SQL> oradebug tracefile_name

/oracle/admin/ORCL/udump/orcl2_ora_24208.trc

找到對應 trace 文件的這一行:socket no 7 IP 10.0.0.55 UDP 16878

 從數據字典中得到:

SQL> select * from v$cluster_interconnects;

                       

SQL> select * from x$ksxpia;

 

心跳調優和設置

為了避免心跳網絡成為系統的單一故障點,簡單地我們可以使用操作系統綁定的網卡來作為 Oracle 的心跳網絡,以 AIX 為例,我們可以使用 etherchannel 技術,假設系統中有 ent0/1/2/3 四塊網卡,我們綁定 2 和 3 作為心跳:在 HPUX 和 Linux 對應的技術分別叫 APA 和 bonding

UDP 私有網絡的調優當使用 UDP 作為數據庫實例間 cache fusion 的通信協議時,在操作系統上需要調整相關參數,以提高 UDP傳輸效率,並在較大數據時避免出現超出 OS 限制的錯誤:

(一) UDP 數據包發送緩沖區:大小通常設置要大於(db_block_size * db_multiblock_read_count )+4k,

(二) UDP 數據包接收緩沖區:大小通常設置 10 倍發送緩沖區;

(三) UDP 緩沖區最大值:設置盡量大(通常大於 2M)並一定要大於前兩個值;

各個平台對應查看和修改命令如下:

Solaris 查看 ndd /dev/udp udp_xmit_hiwat udp_recv_hiwat udp_max_buf ;

修改 ndd -set /dev/udp udp_xmit_hiwat 262144

ndd -set /dev/udp udp_recv_hiwat 262144

ndd -set /dev/udp udp_max_buf 2621440

AIX 查看 no -a |egrep “udp_|tcp_|sb_max”

修改 no -p -o udp_sendspace=262144

no -p -o udp_recvspace=1310720

no -p -o tcp_sendspace=262144

no -p -o tcp_recvspace=262144

no -p -o sb_max=2621440

Linux 查看 文件/etc/sysctl.conf

修改 sysctl -w net.core.rmem_max=2621440

sysctl -w net.core.wmem_max=2621440

sysctl -w net.core.rmem_default=262144

sysctl -w net.core.wmem_default=262144

HP-UX 不需要

HP TRU64 查看 /sbin/sysconfig -q udp

修改: 編輯文件/etc/sysconfigtab

inet: udp_recvspace = 65536

udp_sendspace = 65536

Windows 不需要

 

 

參考文獻


  1. Oracle的三種高可用集群方案
  2. 集群概念介紹:栢圖教育 Oracle 高級課程——理論教材
  3. Oracle 11 RAC生存指南
  4. Oracle 11gR2 RAC管理與性能優化

相關文章


【MySql集群搭建】   真機環境下MySQL-Cluster搭建文檔

【Hadoop集群搭建】Hadoop集群的配置(一)

【Hadoop集群搭建】Hadoop集群的配置(二) 


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM