在企業集羣架構的工做場景中,NFS網絡文件系統通常被用來存儲共享視頻,圖片,附件等靜態資源文件,一般網站用戶上傳的文件都會放到NFS共享裏,例如:BBS產品的圖片,附件,頭像(注意網站BBS程序不要放NFS共享裏),而後前端全部的節點訪問這些靜態資源時都會讀取NFS存儲上的資源。NFS是當前互聯網系統架構中最經常使用的數據存儲服務之一,前面說過,中小型網站公司應用頻率更高,大公司或門戶除了使用NFS外,還可能會使用更爲複雜的分佈式文件系統,好比Moosefs(mfs),GlusterFS,FastDFS等css
在企業生產集羣架構中,NFS做爲全部前端Web服務的共享存儲,存儲的內容通常包括網站用戶上傳的圖片,附件,頭像等,注意,網站的程序代碼不要放NFS共享裏,由於網站程序是開發運維人員統一發布的,不存在發佈延遲問題,直接批量發佈到Web節點提供訪問比共享到NFS裏訪問效率更高。前端
這裏經過圖解給你們展現如下集羣架構須要共享存儲服務的理由。例如:A用戶上傳圖片到Web1服務器,而後讓B用戶訪問這張圖片,結果B用戶訪問的請求分發到了Web2,由於Web2上沒有這張圖片,這就致使它沒法看到A用戶上傳的圖片,若是此時有一個共享存儲,A用戶上傳圖片的請求不管是分發到Web1仍是Web2上,最終都會存儲到共享存儲上,而在B用戶訪問圖片時,不管請求分發到Web1仍是Web2上,最終也都會去共享存儲上找,這樣就能夠訪問到須要的資源了。這個共享存儲的位置能夠經過開源軟件和商業硬件實現,互聯網中小型集羣架構會用普通PC服務器配置NFS網絡文件系統實現。node
當及集羣中沒有NFS共享存儲時,用戶訪問圖片的狀況以下圖所示。linux
上圖是企業生產集羣沒有NFS共享存儲訪問的示意圖。下圖是企業生產集羣有NFS共享存儲的狀況ios
當訪問程序經過NFS客戶端向NFS服務端存取文件時,其請求數據流程大體以下:vim
- 首先用戶訪問網站程序,由程序在NFS客戶端上發出存取NFS文件的請求,這時NFS客戶端(即執行程序的服務器)的RPC服務(rpcbind服務)就會經過網絡向NFS服務器端的RPC服務(rpcbind服務)的111端口發出NFS文件存取功能的詢問請求。
- NFS服務端的RPC服務(rpcbind服務)找到對應的已註冊的NFS端口後,通知NFS客戶端的RPC服務(rpcbind服務)
- 此時NFS客戶端獲取到正確的端口,並與NFS daemon聯機存取數據
- NFS客戶端把數據存取成功後,返回給前端訪問程序,告知給用戶存取結果,做爲網站用戶,就完成了一次存取操做。
- 由於NFS的各項功能都須要向RPC服務(rpcbind服務)註冊,因此只有RPC服務(rpcbind服務)才能獲取到NFS服務的各項功能對應的端口號(port number),PID,NFS在主機所監聽的IP等信息,而NFS客戶端也只能經過向RPC服務(rpcbind服務)詢問才能找到正確的端口。也就是說,NFS須要有RPC服務(rpcbind服務)的協助才能成功對外提供服務。從上面的描述,咱們不難推斷,不管是NFS客戶端仍是NFS服務器端,當要使用NFS時,都須要首先啓動RPC服務(rpcbind服務),NFS服務必須在RPC服務啓動以後啓動,客戶端無需啓動NFS服務,但須要啓動RPC服務。
注意: NFS的RPC服務,在CentOS5.X下名稱爲portmap,在CentOS6.x下名稱爲rpcbind
windows
- nfs-utils: NFS服務的主程序,包括rpc.nfsd,rpc.mountd這兩個daemons和相關文檔說明,以及執行命令文件等。
- rpcbind: CentOS6.X下面RPC的主程序。NFS能夠視爲一個RPC程序,在啓動任何一個RPC程序以前,須要作好端口和功能的對應映射工做,這個映射工做就是由rpcbind服務來完成的。所以,在提供NFS服務以前必須先啓動rpcbind服務才行。
exports
配置文件相關參數應用領域的詳細解釋 (NFS精華重點)
詳細說明:centos
- rw或者ro,主要控制的是全部客戶端用戶(包含root)的讀寫權限。若是設置成ro,就算root也只有讀權限。它是NFS權限設置的第一道總閘閥門。
- sync:同步傳輸,實時進行。
- async:異步傳輸:攢一會在傳輸。
root_squash
:將root帳戶在共享目錄裏的身份下降爲匿名者(默認nfsnobody)身份no_root_squash
:不下降root帳戶在共享目錄的身份,身份仍是rootall_squash
:將全部訪問用戶在共享目錄裏的身份都下降爲匿名者(默認nfsnobody)身份詳細說明:緩存
- 匿名者身份默認狀況下就是NFS服務器端的虛擬帳戶角色,也就是nfsnobody。這是最低的身份,全部NFS客戶端共享目錄的訪問者都被附加了這個身份,這也就意味者,若是文件的屬主屬組是nfsnobody的話,全部訪問者對該文件都擁有所有全部權。
- 所謂身份並非訪問權限,而是用戶在共享目錄裏建立的文件的屬主和屬組。
- 一旦身份被下降那麼在共享目錄裏建立的文件的屬主和屬組就是變成了默認狀況下的nfsnobody。這也就意味着,權限系統對你所建立的文件不作任何保護(任何訪問者均可以查看,修改,刪除)
所謂root_squash:安全
- 使用這個參數意味着root在共享目錄裏建立的任何文件都不受保護,任何人(全部用戶)均可以讀取,修改,刪除)。
- 而非root用戶則不下降權限,在共享目錄裏建立的文件的屬主和屬組統一爲nobody(身份隱藏了),這種狀況下,全部普通用戶之間只能互相查看文件,並不能任意修改和刪除而且你還沒法知道是誰建立的文件,每一個普通用戶只能修改或刪除本身建立的文件。
- root用戶雖然被下降了身份,可是並無下降他的管理者權限,也就是說它仍舊能對全部共享目錄裏的全部文件進行查看,修改,刪除操做。
- 若是這類參數默認爲空的話,那麼NFS將默認使用這個參數。
所謂no_root_squash:
- 使用這個參數意味着不對root進行下降身份的操做,也就是說root在共享目錄裏建立的文件的屬主屬組仍舊爲root(不能被普通用戶修改和刪除)。
- 非root用戶同root_squash同樣,並不下降權限。
所謂all_squash:
- 使用這個參數意味着對全部訪問NFS共享目錄的用戶進行下降身份的操做。也就是說,全部用戶只要在共享目錄裏建立文件,那麼文件的屬主屬組就是默認狀況下的nfsnobody。
- 在這個模式下,任何nfs客戶端的任何訪問用戶均可以對共享目錄裏的任何文件進行查看,修改,刪除操做
這兩個參數主要用來修改NFS默認的虛擬帳戶nfsnobody。能夠經過指定虛擬帳戶的uid和gid的方式修改默認的虛擬帳戶的帳戶名稱和所屬組。
服務端
與客戶端
都安裝nfs-utils
和rpcbind
兩個安裝包[root@root ~]# yum -y install nfs-utils rpcbind
NFS
服務端配置文件路徑NFS服務的默認配置文件路徑爲:
/etc/exports
,而且默認是空的
解析:
(ro):只可看,不能寫
NFS
未啓動狀態下的rpcinfo
NFS
啓動狀態下的rpcinfo
注:
nfsnobody
爲NFS
的程序用戶
/etc/ssh/sshd_config
[root@yangwenbo /]# vim /etc/ssh/sshd_config
nfs-utils
和rpcbind
兩個安裝包問題:
(1)NFS客戶端掛載後,往共享目錄寫入數據時卡住了
(2)NFS服務端,重啓restart服務,客戶端若是寫入數據卡住了。
解答:
1.nfs
服務端重啓以後,共享文件夾進入grace time
(無敵時間)
2.客戶端在服務端重啓後寫入數據大概要等90秒
3.nfs
配置文件:/etc/sysconfig/nfs
在NFS服務端能夠經過cat /var/lib/nfs/etab 查看服務端配置參數的細節。在NFS客戶端能夠經過cat /proc/mounts查看mount的掛載參數細節。
經過以下命令在NFS客戶端測試掛載獲取的默認掛載參數:
NFS Client mount
掛載參數列表
mount -o
參數對應的選項:|參數|參數意義|系統默認值|
提問:在企業生產環境中,NFS客戶端掛載有沒有必需要加的參數,好比,加noexec,nosuid,nodev,bg,soft,rsize,wsize等參數。
解答:這個問題屬於mount掛載優化內容(有些參數也適合其餘文件系統),通常來講要適當加掛載參數,可是,最好是先作好測試,用數據來講話,才能更好的肯定究竟是掛載仍是不掛載。
在企業工做場景,通常來講,NFS服務器共享的只是普通靜態數據(圖片,附件,視頻),不須要執行suid,exec等權限,掛載的這個文件系統只能做爲數據存取之用,沒法執行程序,對於客戶端來說增長了安全性,例如:不少木馬篡改站點文件都是由上傳入口上傳的程序到存儲目錄,而後執行的。
所以在掛載的時候,用下面的命令頗有必要:mount -t nfs -o nosuid,noexec,nodev,rw 172.16.1.31:/data /mnt
mount
掛載性能優化參數選項下面介紹幾個在企業生產環境下,NFS性能優化掛載的例子
mount -t nfs -o noatime,nodiratime 172.16.1.31:/data /mnt
mount -t nfs -o nosuid,noexec,nodev,noatime,nodiratime,intr,rsize=131072,wsize=131072 172.16.1.31:/data /mnt
mount -t nfs 172.16.1.31:/data /mnt
mount /dev/sdb1 /mnt -o defaults,async,noatime,data=writeback,barrier=0
注意:若是本地文件系統掛載時,若是加入
nodiratime
會報錯
mount -t nfs -o noatime,nodiratime,nosuid,noexec,nodev,rsize=131072 172.16.1.31:/data /mnt
mount -t nfs 172.16.1.31:/data /mnt
注意:非性能的參數越多,速度可能會變慢
下面是優化選項說明:
- /proc/sys/net/core/rmem_default:該文件指定了接收套接字緩衝區大小的默認值(以字節爲單位),默認設置:124928 建議:8388608
- /proc/sys/net/core/rmem_max:該文件指定了接收套接字緩衝區大小的最大值(以字節爲單位) 建議:16777216
- /proc/sys/net/core/wmem_default:該文件指定了發送套接字緩衝區大小的默認值(以字節爲單位),默認設置:124928 建議:8388608
- /proc/sys/net/core/wmem_max:該文件指定了發送套接字緩衝區大小的最大值(以字節爲單位)。默認設置:124928. 建議:16777216
NFS服務可讓不一樣的客戶端掛載使用同一個共享目錄,也就是將其做爲共享存儲使用,這樣能夠保證不一樣節點客戶端數據的一致性,在集羣架構環境中常常會用到。若是是windows和Linux混合環境的集羣系統,能夠用samba來實現。
優勢:
- 簡單,容易上手,容易掌握
- NFS 文件系統內數據是在文件系統之上的,即數據是能看得見的。
- 部署快速,維護簡單方便,且可控,知足需求的就是最好的。
- 可靠,從軟件層面上看,數據可靠性高,經久耐用。數據是在文件系統之上的。
- 服務很是穩定
侷限:
- 存在單點故障,若是NFS Server宕機了,全部客戶端都不能訪問共享目錄。這個須要負載均衡及高可用來彌補
- 在大數據高併發的場合,NFS效率,性能有限(2千萬/日如下PV(page view)的網站不是瓶頸,除非網站架構設計太差。)
- 客戶端認證是基於IP和主機名的,權限要根據ID識別,安全性通常(用於內網則問題不大)。
- NFS數據是明文的,NFS自己不對數據完整性作驗證。
- 多臺客戶機器掛載一個NFS服務器時,鏈接管理維護麻煩(耦合度高)。尤爲NFS服務端出問題後,全部NFS客戶端都處於掛掉狀態(測試環境可以使用autofs自動掛載解決,正式環境可修復NFS服務或強制卸載)
- 涉及了同步(實時等待)和異步(解耦)的概念,NFS服務端和客戶端相對來講就是耦合度有些高。網站程序也是同樣,儘可能不要耦合度過高,系統及程序架構師的重要職責就是爲程序及架構解耦,讓網站的擴展性變得更好。
應用建議:大中小型網站(參考點2000萬/日PV如下)線上應用,都有用武之地。門戶站也會有應用,生產場景應該多把數據的訪問往前推,即儘可能把靜態存儲裏的資源經過CDN或緩存服務器提供服務,若是沒有緩存服務或架構很差,存儲服務器數量再多也是扛不住壓力的,並且用戶體驗會不好。
NFS客戶端實現fstab開機自啓動掛載
現象:在/etc/fstab中配置了nfs開機自動掛載,結果沒法開機自動掛載nfs
解答:
1.nfs客戶端掛載命令放在/etc/rc.local
實現自動掛載
2.開機自啓動netfs服務,而後才能實現fstab的開機自動掛載nfs文件系統(linux開機時在加載網絡以前就會加載/etc/fstab)
mount -o remount,rw/
的意思是將整個根目錄已可讀可寫rw的方式從新掛載一邊remount