亚洲日本免费-啊轻点灬太粗太长了三男一女-麻豆av电影在线观看-日韩一级片毛片|www.grbbt.com

　　一、高級功能

　　1、副本

　　副本，在MFS中也被稱為目標（Goal），它是指文件被復制的份數，設定目標值后可以通過mfsgetgoal命令來證實，也可以通過mfssetgoal命令來改變設定。

　　[root@mfs-client ~]# cd /mfsdata/

　　[root@mfs-client mfsdata]# dd if=/dev/zero of=/mfsdata/test.file bs=1M count=200

　　200+0 records in

　　200+0 records out

　　209715200 bytes (210 MB) copied， 9.1094 s， 23.0 MB/s

　　[root@mfs-client mfsdata]# mfsgetgoal test.file

　　test.file： 1

　　[root@mfs-client mfsdata]# mfssetgoal 3 test.file

　　test.file： 3

　　[root@mfs-client mfsdata]# mfsgetgoal test.file

　　test.file： 3

　　補充：

　　用mfsgetgoal –r和mfssetgoal –r同樣的操作可以對整個樹形目錄遞歸操作

　　[root@mfs-client mfsdata]# mkdir dir/dir1/dir2/dir3 -p

　　[root@mfs-client mfsdata]# touch dir/file1

　　[root@mfs-client mfsdata]# touch dir/dir1/file2

　　[root@mfs-client mfsdata]# touch dir/dir1/dir2/file3

　　[root@mfs-client mfsdata]# mfsgetgoal -r dir

　　dir：

　　files with goal 1 ： 3

　　directories with goal 1 ： 4

　　[root@mfs-client mfsdata]# mfssetgoal -r 3 dir

　　dir：

　　inodes with goal changed： 7

　　inodes with goal not changed： 0

　　inodes with permission denied： 0

　　實際的拷貝份數可以通過mfscheckfile 和 mfsfileinfo 命令來證實，例如：

　　[root@mfs-client mfsdata]# mfscheckfile test.file

　　test.file：

　　chunks with 1 copy： 4

　　[root@mfs-client mfsdata]# mfsfileinfo test.file

　　test.file：

　　chunk 0： 00000000000000D2_00000001 / (id：210 ver：1)

　　copy 1： 172.16.100.6：9422

　　chunk 1： 00000000000000D3_00000001 / (id：211 ver：1)

　　copy 1： 172.16.100.7：9422

　　chunk 2： 00000000000000D4_00000001 / (id：212 ver：1)

　　copy 1： 172.16.100.6：9422

　　chunk 3： 00000000000000D5_00000001 / (id：213 ver：1)

　　copy 1： 172.16.100.7：9422

　　需要注意的是，一個包含數據的零長度的文件，盡管沒有設置為非零的目標（the non-zero goal），但是在使用命令查詢時將返回一個空值

　　[root@mfs-client mfsdata]# touch a

　　[root@mfs-client mfsdata]# mfscheckfile a

　　a：

　　[root@mfs-client mfsdata]# mfsfileinfo a

　　a：

　　2、回收

　　一個刪除文件能夠存放在一個“垃圾箱”的時間就是一個隔離時間，這個時間可以用 mfsgettrashtime 命令來驗證，也可以用 mfssettrashtime 命令來設置。例如：

　　[root@mfs-client mfsdata]# mfsgettrashtime test.file

　　test.file： 86400

　　[root@mfs-client mfsdata]# mfssettrashtime 0 test.file

　　test.file： 0

　　$ mfsgettrashtime /mnt/mfs-test/test1

　　/mnt/mfs-test/test1： 0

　　這些工具也有個遞歸選項-r，可以對整個目錄樹操作，例如：

　　[root@mfs-client mfsdata]# mfsgettrashtime -r dir

　　dir：

　　files with trashtime 86400 ： 3

　　directories with trashtime 86400 ： 4

　　[root@mfs-client mfsdata]# mfssettrashtime -r 0 dir

　　dir：

　　inodes with trashtime changed： 7

　　inodes with trashtime not changed： 0

　　inodes with permission denied： 0

　　[root@mfs-client mfsdata]# mfsgettrashtime -r dir

　　dir：

　　files with trashtime 0 ： 3

　　directories with trashtime 0 ： 4

　　時間的單位是秒(有用的值有：1小時是3600秒，24 – 86400秒，1 – 604800秒)。就像文件被存儲的份數一樣， 為一個目錄 設定存放時間是要被新創建的文件和目錄所繼承的。數字0意味著一個文件被刪除后， 將立即被徹底刪除，在想回收是不可能的

　　刪除文件可以通過一個單獨安裝 MFSMETA 文件系統。特別是它包含目錄 / trash (包含任然可以被還原的被刪除文件的信息)和 / trash/undel (用于獲取文件)。只有管理員有權限訪問MFSMETA(用戶的uid 0，通常是root)。

　　在開始mfsmount進程時，用一個-m或-o mfsmeta的選項，這樣可以掛接一個輔助的文件系統MFSMETA，這么做的目的是對于意外的從MooseFS卷上刪除文件或者是為了釋放磁盤空間而移動的文件而又此文件又過去了垃圾文件存放期的恢復，例如：

　　mfsmount -m /mnt/mfsmeta

　　需要注意的是，如果要決定掛載mfsmeta，那么一定要在 mfsmaster 的 mfsexports.cfg 文件中加入如下條目：

　　*                       .       rw

　　原文件中有此條目，只要將其前的#去掉就可以了。

　　否則，你再進行掛載mfsmeta的時候，會報如下錯誤：

　　mfsmaster register error： Permission denied

　　下面將演示此操作：

　　$ mfssettrashtime 3600 /mnt/mfs-test/test1

　　/mnt/mfs-test/test1： 3600

　　從“垃圾箱”中刪除文件結果是釋放之前被它站用的空間(刪除有延遲，數據被異步刪除)。在這種被從“垃圾箱”刪除的情況下，該文件是不可能恢復了。

　　可以通過mfssetgoal工具來改變文件的拷貝數，也可以通過mfssettrashtime工具來改變存儲在“垃圾箱”中的時間。

　　在 MFSMETA 的目錄里，除了trash和trash/undel兩個目錄外，還有第三個目錄reserved，該目錄內有已經刪除的文件，但卻有一直打開著。在用戶關閉了這些被打開的文件后，reserved目錄中的文件將被刪除，文件的數據也將被立即刪除。在reserved目錄中文件的命名方法同trash目錄中的一樣，但是不能有其他功能的操作。

　　3、快照

　　MooseFS系統的另一個特征是利用mfsmakesnapshot工具給文件或者是目錄樹做快照，例如：

　　$ mfsmakesnapshot source … destination

　　Mfsmakesnapshot 是在一次執行中整合了一個或是一組文件的拷貝，而且任何修改這些文件的源文件都不會影響到源文件的快照， 就是說任何對源文件的操作，例如寫入源文件，將不會修改副本(或反之亦然)。

　　文件快照可以用mfsappendchunks，就像MooseFS1.5中的mfssnapshot一樣，，作為選擇，二者都可以用。例如：

　　$ mfsappendchunks destination-file source-file …

　　當有多個源文件時，它們的快照被加入到同一個目標文件中（每個chunk的最大量是chunk）。五、額外的屬性文件或目錄的額外的屬性(noowner， noattrcache， noentrycache)，可以被mfsgeteattr，mfsseteattr，mfsdeleattr工具檢查，設置，刪除，其行為類似mfsgetgoal/mfssetgoal or或者是mfsgettrashtime/mfssettrashtime，詳細可見命令手冊。

　　二、綜合測試

　　1、破壞性測試

　　a、模擬MFS各角色宕機測試

　　b、mfs 災難與恢復各種場景測試

　　2、性能測試

　　針對 MooseFS 的性能測試，我這邊也沒有詳細去做。通過偉大的互聯網，我找到了幾位前輩，針對 MooseFS 所做的詳細性能測試，這里我就貼出來展示一下。

　　1、基準測試情況：

　　隨機讀

　　

　　隨機寫

　　

　　順序讀

　　

　　順序寫

　　

　　小文件性能測試情況：

　　

　　

　　

　　　

如果想看更多有關 MooseFS 性能方面的測試報告，可以去參考如下鏈接：

　　http：//blog.liuts.com/post/203/          MooseFS性能圖表[原創]

　　三、監控

　　1、mfs內置的監控工具mfscgiserv

　　針對 Moosefs 每個組件的監控，Moosefs自帶了一個監控工具 mfscgiserv，它是一個 python 編寫的 web 監控頁面，監聽端口為9425。該監控頁面為我們提供了 Master Server、Metalogger Server、Chunk Servers以及所有Client掛載的狀態信息及相關性能指標圖示。

　　在我們安裝好 Master Server 時，它就已經默認安裝上了，我們可以在/usr/local/mfs/share/mfscgi/  目錄下看到這個監控頁面的文件。

　　[root@mfs-master-1 mfs]# ll /usr/local/mfs/share/mfscgi/         # 這個 mfscgi 目錄里面存放的是master圖形監控界面的程序

　　total 136

　　-rwxr-xr-x. 1 root root 1881 Dec 29 00：10 chart.cgi

　　-rw-r–r–. 1 root root 270 Dec 29 00：10 err.gif

　　-rw-r–r–. 1 root root 562 Dec 29 00：10 favicon.ico

　　-rw-r–r–. 1 root root 510 Dec 29 00：10 index.html

　　-rw-r–r–. 1 root root 3555 Dec 29 00：10 logomini.png

　　-rwxr-xr-x. 1 root root 107456 Dec 29 00：10 mfs.cgi

　　-rw-r–r–. 1 root root 5845 Dec 29 00：10 mfs.css

　　我們可以通過執行如下命令啟動該監控程序。

　　1

　　/moosefs_install_path/sbin/mfscgiserv start

　　啟動完畢之后，我們可以通過訪問http：//IP：9425來訪問該監控頁面。

　　下面，我列出啟動 mfscgiserv 監控工具的操作：

　　[root@mfs-master-1 mfs]# /usr/local/mfs/sbin/mfscgiserv start   # 啟動mfs圖形控制臺

　　lockfile created and locked

　　starting simple cgi server (host： any ， port： 9425 ， rootpath： /usr/local/mfs-1.6.27/share/mfscgi)

　　[root@mfs-master-1 mfs]# netstat -lantup|grep 9425

　　tcp 0 0 0.0.0.0：9425 0.0.0.0：* LISTEN 7940/python

　　tcp 0 0 172.16.100.1：9425 172.16.100.100：50693 ESTABLISHED 7940/python

　　tcp 0 0 172.16.100.1：9425 172.16.100.100：50692 ESTABLISHED 7940/python

　　[root@mfs-master-1 mfs]# lsof -i tcp：9425

　　COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME

　　python 7940 root 3u IPv4 27066 0t0 TCP *：9425 (LISTEN)

　　python 7940 root 7u IPv4 27136 0t0 TCP 172.16.100.1：9425->172.16.100.100：50693 (ESTABLISHED)

　　python 7940 root 8u IPv4 27124 0t0 TCP 172.16.100.1：9425->172.16.100.100：50692 (ESTABLISHED)

　　下面是訪問的頁面：

　　spacer.gifwKiom1Szsl2Cl8fyAAUfoEFIMdM006.jpg

　　2、使用zabbix監控mfs

　　1、監控要點

　　根據 MooseFS 中各個組件的特點，我們所需要監控的要點主要有如下幾點：

　　a、Master Server的9420、9421端口，Chunk Server 的9422端口

　　b、Chunk Server 的磁盤空間

　　2、實施步驟

　　通過在各個組件的對應服務器上部署好zabbix監控的代理端，然后分別添加端口監控和磁盤監控即可！

　　操作過程略！

　　四、維護

　　1、常用管理命令

　　mfsgetgoal              # 獲取mfs目錄、文件的副本數

　　mfssetgoal              # 設置mfs目錄、文件的副本數

　　mfscheckfile            # 查看副本數簡單

　　mfsfileinfo             # 查看詳細的副本數，chunks/分片

　　mfsdirinfo              # 以數量的方法顯示mfsfileinfo

　　mfsgettrashtime         # 獲取垃圾箱的定隔時間

　　mfssettrashtime         # 設置垃圾箱的定隔時間（和memcached類）

　　mfsmakesnapshot         # 快照

　　2、可能存在的問題

　　A、mfscgiserv的訪問安全問題

　　mfscgiserv只是一個非常簡單的HTTP服務器，只用來編寫運行MooseFS CGI腳本。它不支持任何的附加功能，比如HTTP認證。如果公司出于對監控界面的安全訪問需求，我們可以使用功能豐富的HTTP服務器，比如apache、nginx等。在使用這些更強大的HTTP服務器時，我們只需要將CGI和其它數據文件（index.html、mfs.cgi、chart.cgi、mfs.css、logomini.png、err.gif）存放到選擇的站點根目錄下。我們可以創建一個新的虛擬機，來設定特定的主機名和端口來進行訪問。

　　B、Master Server 的單點問題

　　Master server的單點問題，在前面介紹 MooseFS 的優缺點時已經提到過了。由于官方提供的解決方案，在恢復的時候還是需要一定時間的，因此我們建議使用第三方的高可用方案（heartbeat+drbd+moosefs）來解決 Master Server 的單點問題。

　　3、性能瓶頸的解決辦法

　　由于 MooseFS 的高可擴展性，因此我們可以很輕松的通過增加 Chunk Server 的磁盤容量或增加 Chunk Server 的數量來動態擴展整個文件系統的存儲量和吞吐量，這些操作絲毫不會影響到在線業務。

　　4、安全開啟/停止MFS集群

　　1、啟動 MooseFS 集群

　　安全的啟動 MooseFS 集群（避免任何讀或寫的錯誤數據或類似的問題）的步驟如下：

　　1、啟動 mfsmaster 進程

　　2、啟動所有的 mfschunkserver 進程

　　3、啟動 mfsmetalogger 進程（如果配置了mfsmetalogger）

　　4、當所有的 chunkservers 連接到 MooseFS master 后，任何數目的客戶端可以利用 mfsmount 去掛載被 export 的文件系統。（可以通過檢查 master 的日志或是 CGI 監控頁面來查看是否所有的chunkserver 被連接）。

　　2、停止 MooseFS 集群

　　安全的停止 MooseFS 集群的步驟如下：

　　1、在所有的客戶端卸載MooseFS 文件系統（用umount命令或者是其它等效的命令）

　　2、用 mfschunkserver –s命令停止chunkserver進程

　　3、用 mfsmetalogger –s命令停止metalogger進程

　　4、用 mfsmaster –s命令停止master進程

　　5、增加塊設備（會自動平均）

　　針對增加塊設備的情況，其實就是說針對chunk server 有變化（增加或減少）的情況。

　　為了增加一個案例說明，這里就以 UC 在使用 MooseFS 中遇到的一個問題為案例，講解新增加 chunk server 時，MooseFS集群發生的變化，其實也就是 Master Server 發生的變化。

　　UC在使用 MooseFS 集群的過程中，有次一臺 Chunk Server 掛了，于是就涉及到了后期的恢復問題。在問題Chunk Server修復之后，就從新加入到了集群當中。此時，新增加的 chunk server 啟動之后會向 Master 匯報 Chunk 的信息，Master接收到 Chunk 信息之后會逐個檢查 Chunk_id是否存在。如果不存在，就表示該chunk_id其實已經刪除了（chunk_id過期），然后會調用chunk_new()創建該chunk，并設置lockedio屬性為7天后。這些操作都是屬于內存操作，并且Master是單線程的進程，并不存在全局鎖，因此不會導致 Master 阻塞無響應。因此，針對增加chunk server的情況，是不會對MooseFS集群產生什么大的影響的。

　　以上就是新增加 Chunk Server 后的，MooseFS 集群中 Master Server 的變化。而針對各個Chunk Server，Master Server會重新去調整塊文件的磁盤空間，然后全部重新動態分配塊文件。如果遇到空間不夠的磁盤，Master Server會自動調整塊文件的分布，從不夠的磁盤里動態的把塊服務移動到有大的磁盤塊服務器里

　　當然，如果按照上面的情況這次就不會是故障了，因此并不會對 MooseFS 集群產生什么大的影響。由于他們當時因為資源緊張，就把 Master Server 放到了虛擬機上，而虛擬機的磁盤是掛載的iscsi磁盤。并且他們的MooseFS使用的版本并不是最新的1.6.27，而是1.6.19。在1.6.19版本中，會把chunk的匯報過程寫入磁盤，這樣就導致了幾十萬條的磁盤寫入，由于磁盤是前面提到的網絡盤，就最終釀成了 Master Server 恢復時無響應幾十分鐘。

　　因此，我們在生產環境中，針對Master Server的選型一定不能使用虛擬機，而是使用大內存量的物理機。

    文章來源：http://nolinux.blog.51cto.com/4824967/1602616