請(qǐng)教：光纖連接存儲(chǔ)沒有安裝共享軟件情況下磁盤文件的同步問題

zdcdcz

      項(xiàng)目中存儲(chǔ)最初規(guī)劃了nfs，但是隨著用戶的逐漸增多，并發(fā)訪問增大，經(jīng)常出現(xiàn)遠(yuǎn)程nfs目錄反映慢的問題。iostat發(fā)現(xiàn)磁盤陣列達(dá)到瓶頸。
      存儲(chǔ)原本有配有光纖，通過光交和兩臺(tái)流媒體服務(wù)器相連，因?yàn)閚fs達(dá)到了瓶頸，于是采取不走nfs,直接走光纖，負(fù)載下去了（項(xiàng)目之初原本想做GFS的，
因?yàn)槟承┰�因沒有做，做了NFS）。
      產(chǎn)生的新問題就是：三臺(tái)主機(jī)直接掛載光纖連接的分區(qū)，一臺(tái)寫，兩臺(tái)讀。其他兩臺(tái)對(duì)于第一臺(tái)寫入的新的文件并不能實(shí)時(shí)讀取到。
查了一些資料，了解到“多主機(jī)共享一個(gè)lun，數(shù)據(jù)是不同步的，各有各的緩存，也沒有鎖的機(jī)制”，“nfs的傳輸時(shí)文件級(jí)的，而fc san是塊級(jí)的”。

      由于是生產(chǎn)環(huán)境，不能重新部署GFS，OCFS，SANergy，ImageSAN等共享軟件，我的問題是：

1）既然各主機(jī)各有各的緩存，這個(gè)緩存是在主機(jī)還是存儲(chǔ)控制器上的？如果是在主機(jī)上，能否像Oracle一樣，通過checkpoin強(qiáng)制把緩存的數(shù)據(jù)寫入磁盤陣列？
2) 但是對(duì)1）仍有疑問，因?yàn)閽燧d分區(qū)后，兩臺(tái)讀的主機(jī)三天了還沒有能看到寫主機(jī)三天前寫的新的數(shù)據(jù)。好像重新mount可以看到？生產(chǎn)環(huán)境在跑，還沒試驗(yàn)。
3）對(duì)于當(dāng)前需求，一臺(tái)寫，兩臺(tái)主機(jī)讀，有什么辦法在不安裝共享軟件的情況下，實(shí)時(shí)讀取寫主機(jī)上更新的數(shù)據(jù)嗎？（另兩臺(tái)只需要讀取，不需要寫）
4）如果以上皆不可行，對(duì)nfs能做何優(yōu)化使之能承受越來越大的并發(fā)訪問壓力？

    本人對(duì)存儲(chǔ)方面經(jīng)驗(yàn)，了解都很有限，還請(qǐng)各位大牛指教......

dengbao2001

最可靠的方法是用支持共享讀寫的文件系統(tǒng)和相關(guān)軟件，否則會(huì)發(fā)生讀寫不一致性

我記得某些存儲(chǔ)可以可以NAS的，也就是用SAN存儲(chǔ)實(shí)現(xiàn)NAS的功能，如果你無法使用基于共享的文件系統(tǒng)的話

鍋鐵做

zdcdcz 發(fā)表于 2015-05-05 16:05
項(xiàng)目中存儲(chǔ)最初規(guī)劃了nfs，但是隨著用戶的逐漸增多，并發(fā)訪問增大，經(jīng)常出現(xiàn)遠(yuǎn)程nfs目錄反映慢的問題 ...

非常遺憾的告訴你：針對(duì)流媒體業(yè)務(wù)，以你目前的架構(gòu)，不做很大的改動(dòng)很難解決你的痛處。
SAN是專有的“塊”級(jí)訪問模式，效率高但具有唯一性，你說的寫入后無法反映在讀取的另外節(jié)點(diǎn)，數(shù)據(jù)應(yīng)該是臨時(shí)被緩沖在主機(jī)的文件系統(tǒng)了。
NFS或其它的NAS協(xié)議屬于文件級(jí)訪問，可以共享，不過就像你說的效率低，尤其文件到達(dá)一定的數(shù)量，幾萬，十幾萬，幾百萬的時(shí)候就下降十分厲害。

那，最好的方式就是，你必須改造目前的架構(gòu)，在磁盤上方搭建一套分布式文件系統(tǒng)，可以集合所有節(jié)點(diǎn)性能，同時(shí)提供多個(gè)系統(tǒng)同時(shí)讀/寫。
往常這種系統(tǒng)可以用SAN的方式發(fā)布空間，比如iSCSI，高性能同時(shí)還提供文件鎖，寫入數(shù)據(jù)實(shí)時(shí)反映在讀—節(jié)點(diǎn)上。

zdcdcz

回復(fù) 2# dengbao2001
你是說基于光纖的NAS？但是從定義上來說，基于光纖的就不是NAS了

這個(gè)倒是沒有聽說過？您有資料嗎？


   

zdcdcz

回復(fù) 3# 鍋鐵做

謝謝兄弟指點(diǎn)，看來不經(jīng)過文件系統(tǒng)的改造，很難取得性能上的提高，所以項(xiàng)目初期就應(yīng)該規(guī)劃好啊......

又或是，nas使用萬兆網(wǎng)卡，部署集群，不知能否改善nfs的性能，適應(yīng)流媒體的高負(fù)載？

   

鍋鐵做

zdcdcz 發(fā)表于 2015-05-06 11:29
回復(fù) 3# 鍋鐵做

謝謝兄弟指點(diǎn)，看來不經(jīng)過文件系統(tǒng)的改造，很難取得性能上的提高，所以項(xiàng)目初期就應(yīng)該規(guī) ...

可以試一下，不過有兩點(diǎn)需要注意：

第一：到底是帶寬瓶頸還是磁盤的響應(yīng)速度跟不上？你開篇第一句話說的是磁盤響應(yīng)速度跟不上，如果是這樣，擴(kuò)展帶寬對(duì)改善問題幫助不大。
第二：保留目前的架構(gòu)，只能回到NAS（用SAN不合理），使用NFS，這是一種文件協(xié)議和鏈路沒關(guān)系，不要混淆。用NAS的話鏈路可以是1或10Gb的網(wǎng)卡，也可以是10Gb的光纖以太網(wǎng)，并不是說光纖就必須是SAN。但光的延遲總會(huì)小于雙絞線吧。
我之前計(jì)劃用SAN去替換客戶已有的流媒體業(yè)務(wù)，發(fā)現(xiàn)越到后期問題越多，也包括閣下目前遇到的所有問題，所以最好是專有的分布式文件系統(tǒng)才合理。

dengbao2001

到了現(xiàn)在才知道你用了流媒體形式，不知可否用分布式+緩存這種部署方式

zdcdcz

回復(fù) 6# 鍋鐵做
多謝回復(fù)。

1）應(yīng)該是鏈路上的瓶頸。存儲(chǔ)做了raid，23塊硬盤并發(fā)寫入，應(yīng)該不至于有問題。而且現(xiàn)在暫時(shí)采用的方案是一臺(tái)流媒體采用nfs，兩臺(tái)直接走光交連接存儲(chǔ)，目前
     iostat顯示的await  svctm  %util等參數(shù)都正常了，流媒體也沒有出現(xiàn)過讀取不到文件的情況。只是有前述的問題，光纖連接的讀取不到新寫入的文件。

2）改用光纖以太網(wǎng)應(yīng)該會(huì)改善一點(diǎn)性能，但不知道能不能頂住目前流媒體的壓力。事實(shí)上，目前生產(chǎn)環(huán)境已經(jīng)在跑業(yè)務(wù)，而且是電子政務(wù)，做大的改動(dòng)比較困難。所以說，
     項(xiàng)目初期就要做好規(guī)劃，預(yù)留壓力空間。

     我要么把情況上報(bào)領(lǐng)導(dǎo)，之前的想在不動(dòng)現(xiàn)有環(huán)境的情況下解決估計(jì)可能性不大。還是看領(lǐng)導(dǎo)意思吧，哈

   

zdcdcz

回復(fù) 7# dengbao2001

我們另一個(gè)較大的項(xiàng)目用到了分布式，以及CDN來分擔(dān)壓力，但這個(gè)項(xiàng)目已經(jīng)在運(yùn)營(yíng)，不能做大的改動(dòng)了，當(dāng)然，這也涉及成本，呵呵