Oracle RAC能用ocfs嗎 ？

       ocfs1, ocfs2 在生產系統俺們也有在用， 用了4年多，沒有碰到過什麼ocfs方面的問題 。 下面的文章說到ocfs2有多麼脆弱， 奇怪沒有感覺到 。 Oracle自己開發出來的東西， 而且一直在改進， 沒有理由被自己這樣放棄吧 。

 

------------------------------------------------------------------------------------------------------------------------------------------  

 

轉載自     

ocfs 只能在RAC當中用.
ocfs2的開發方向有了重大調整,目的是成為通用的 cluster filesystem.

我相信oracle和ocfs2 開發團隊的實力和未來的發展,軟體發展都有從幼稚到成熟,混亂到清晰,脆弱到穩定的過程,如果目前你有生產系統要考慮叢集檔案系統, ocfs2就不要考慮了.

因為目前的RAC環境，看不出有任何理由在生產環境用ocfs2的必要.

RAC涉及到儲存的就是2個個地方，一個是OCR和voting(以及他們的redundant config),另外一塊就是Oralce Data和Flashback recovery area.
   現在Oracle的RAC配置一般是兩種  raw(ocr+voting)+ASM(data+flashback recovery area),另外一種是 ocfs2+ASM.OCR和 voting 佔用的空間很小，根本沒有必要在用了ocfs2的下面用一個OS的LVM來支援，就算你那樣做了，也是錯誤的，因為目前OCR和voting 都需要儲存是clusterware的，這也是用raw或ocfs2的原因，你用lvm+ocfs2的話，底下的OS LVM不是clusterware的，所以就會把你的資料破壞掉，這個話題是一個很老的話題了，你到oracle forum去搜，或者有metalink賬號的話你看看就知道了，沒有意義多討論.

如果你用 OS LVM+ocfs2 用來放 Data+Flashback Recovery Area,我建議你還是不要這麼幹，不是說不可以，只不過ocfs2實在是很脆弱，你有訂閱 ocfs2的maillist 麼？ 去看看吧.
Data+FRA用ASM 或RAW都很好，無論是效能上還是管理上，還是可靠性上

既然都不好,為何oracle RAC的安裝還推薦使用ocfs2?

你有看到哪個軟體從開發之初就是好的？ 一個開發中的軟體有各種現階段的問題，難道就停止開發而放棄?

RAC安裝從來沒有推薦過用ocfs2, 你看Oracle RAC的產品經理在oracleworld上的發言了麼？說得很清楚.RAC系統離開clusterwide filesystem，節點failed之後，儲存部分的切換延遲就會很大，這個道理和RHCS Vs RHCS+GFS一樣的.

會安裝RAC不難，難的是知道什麼時候應該部署RAC,怎麼部署，部署什麼部分，那些現在可以放心用，那些不能，用了會有什麼可能的風險，怎麼防止和解決?

一點補充，RAC環境，如果不是用raw, 在生產環境還是應該選擇ASM.

我在RHEL4 update4上裝的ocfs2；
node01 ，node02當把node02的網線或者node01的網線拔了之後，node02就會當機；而node1沒有問題.首先強烈推薦使用RAW裝置.
拔掉網線當機的話，第二個節點正常是會重啟，而不應該當機.
你試一下拔CRS　的幾個服務停掉再拔網線看看.
估計這樣就不會當機了.
為什麼會死一個節點？
根據我的理解是：因為RAC是同時使用兩個節點都使用，再用兩個Virtual IP 設兩個主機上面，
而ORACLE client同時連線到你的兩個VIP.
正常情況下，一個節點出現問題的時候，會把他的VIP設到活的節點的機器上.這樣才能保證客戶端可以訪問兩個VIP.
而你他們兩臺主機之間的通訊靠的是Private的網路卡，RAC靠兩個網路卡來共享記憶體池，同樣他們的流量是相當大的.－－－－這個概念跟我們以前在MSCS上做OFS是不一樣的！！！！
而你拔掉網線的話，他們就沒有辦法做到共享記憶體池，而客戶端如果還是同時使用兩臺主機的話，ORACLE就會出問題.所以，網線拔掉的話，必然要有一臺要接管全部的VIP，而另一個一直處於無修止的重啟，直到網線拔好.

而你的問題就是為什麼不是重啟而是當機.
估計你查一下，你的model裡面的設定是不是按方檔的來做，還有就是系統本身的設定.　
估計是CRS程式在重啟機器的時候沒有導致SYSTEM hung.

asm在oracle的官方網站一般都採用是oracle10g，由於特殊原因我們採用的是9204的oracle，如果採用raw那麼分割槽是有限制的最多255個所以採用ocfs2檔案系統，這也是oracle官方網站建議的。現在我已經做好了

oracle 沒有說best practise 建議你用ocfs2, 實際上在社群沒有一個oracle得人敢出來說ocfs2 你們放心用在生產環境把.既然是RAC這個前提，我的建議就偏安全考慮.既然解決的是Data部分的問題，而且又不用ASM,就沒有選擇了，只能用  LVM+OCFS了.

不過ocfs R1很麻煩的，不但和R2 一樣不支援online resizing, 而且如果要resize ，操作起來需要一定的步驟的.

現在的麻煩就是 array 可以online resize, lun可以online hot add,  pv可以online add, vg 可以online extend, lv 可以online extend，唯獨你 resize ocfs on  lv 的時候，不能online做. 必須要把ocfs 從所有node上卸下來.

ocfs1不能直接升級到ocfs2, 如果以後要升級，需要做DB的匯入匯出操作.

昨天為了確認我給你的回覆，順便又搜了一下，ocfs1的 bug在網上比比皆是，觸目驚心. 說白了，你們這樣的架構的選擇，最後就是給施工單位/人員和客戶自找麻煩，痛苦的還在後面呢..

我昨天看到ocfs2的maillist有ocfs2 的 developer回答了類似問題:

我在重複一下:  ocfs2是一個clusteraware 的檔案系統，在每個RAC node上都有instance執行，並透過網路通訊+lock的機制,確保不同的node對同一個儲存區域的讀寫是在控制下進行並且所有的node透過ocfs2 instance知道誰寫了/誰讀了. 所以ocfs2 filesystem的完整性是有保障底線的.

當你把ocfs2建立在LVM上的時候，LVM的 control在不同的node上是各管各的，由每個node的OS和LVM module自己來控制，node之間的LVM 並不通訊，他們都是獨立的，不排斥不加鎖得去訪問/操作共享儲存上的區域，雖然你可以從每個node上用lvm工具scan到共享盤陣上的pv/vg/lv,但是一旦涉及到讀寫操作，所有的node便完全孤立來做了.所以LVM metadata 的讀寫就變成一個嚴重的問題.
所以 ocfs2+LVM 用在RAC的資料共享上是不可取的.
gfs 和ocfs2是一種東西,  和ocfs, gpfs不是一種東西. ocfs 和當中的任何一種都不一樣.

IXDBA.NET技術社群

gfs/ocfs2 使得多個節點訪問共享儲存的同一個位置成為可能，他們透過普通網路建立不同節點上檔案系統快取的同步機制，透過叢集鎖，杜絕多個節點的不同應用操作同一個檔案產生的競爭關係從而破壞檔案的可能性，透過普通網路交換節點之間的心跳狀態. 這是功能上的類似。從成熟度，效能來考慮，目前ocfs2還遠不能和gfs相提並論， 能夠用ocfs2的地方都可以用gfs來替代，但是反之就不行.  gfs在 HA叢集環境，擔當了一個"廉價縮水版"的polyserv.   至少目前來看，我個人的觀點是gfs在技術，成熟度，開發力量投入，效能上都要領先ocfs2 差不多3年左右的時間.而且這種差距可能進一步拉大.

ocfs是隻能for oracle的，也是oracle把叢集檔案系統納入發展視線的第一個版本，之前我也說過，這個版本當時並沒有定位在通用叢集檔案系統上，無論是質量，效能，穩定性等等在oracle使用者圈子，反面的意見佔大多數.

即便是在今天ocfs2的階段，oracle mailing list, forum上大量充斥對於ocfs2質量，效能和可靠性的投訴.

ASM 是Oracle 在 linux, HP-UX, Solaris 等多個商用高階Unix平臺採用的新一代儲存管理系統，在Oracle公司的產品地位，開發的投入，使用者範圍，適用的層次和領域都是ocfs2專案無法比的.

ASM在功能上，相當於 RAW+LVM. 在資料量和訪問量的線性增長關係上，表現也很出色，在實際的真實測試環境中，ASM的效能基本接近RAW, 因為還有Volume 開銷，所以效能上有一點點地開銷，也是很容易理解的. CLVM+OCFS2的效能線上性增長的測試中，明顯低於ASM和RAW. 前天我一個朋友給我發來了他在歐洲高能實驗室一個年會上作的slide,他們實驗室的IT部門統計了一下，整個實驗室各種單資料庫和叢集加起來，現在有540多個TB的資料跑在ASM上面，經過重負荷的使用和測試，他們對於ASM是表現是相當滿意的. 他們大部分的系統是IA64+linux和AMD Opteron+Linux.