如何搭建分布式存儲

Ⅰ 基於mogileFS搭建分布式文件系統--海量小文件的存儲利器

1.簡介

分布式文件系統（Distributed File System）是指文件系統管理的物理存儲資源不一定直接連接在本地節點上，而是通過計算機網路與節點相連。分布式文件系統的設計基於客戶機/伺服器模式。一個典型的網路可能包括多個供多用戶訪問的伺服器。另外，對等特性允許一些系統扮演客戶機和伺服器的雙重角色。例如，用戶可以「發表」一個允許其他客戶機訪問的目錄，一旦被訪問，這個目錄對客戶機來說就像使用本地驅動器一樣。

當下我們處在一個互聯網飛速發展的信息 社會 ，在海量並發連接的驅動下每天所產生的數據量必然以幾何方式增長，隨著信息連接方式日益多樣化，數據存儲的結構也隨著發生了變化。在這樣的壓力下使得人們不得不重新審視大量數據的存儲所帶來的挑戰，例如：數據採集、數據存儲、數據搜索、數據共享、數據傳輸、數據分析、數據可視化等一系列問題。

傳統存儲在面對海量數據存儲表現出的力不從心已經是不爭的事實，例如：縱向擴展受陣列空間限制、橫向擴展受交換設備限制、節點受文件系統限制。

然而分布式存儲的出現在一定程度上有效的緩解了這一問題，之所以稱之為緩解是因為分布式存儲在面對海量數據存儲時也並非十全十美毫無壓力，依然存在的難點與挑戰例如：節點間通信、數據存儲、數據空間平衡、容錯、文件系統支持等一系列問題仍處在不斷摸索和完善中。

2.分布式文件系統的一些解決方案

Google Filesystem適合存儲海量大個文件，元數據存儲與內存中

HDFS（Hadoop Filesystem）GFS的山寨版，適合存儲大量大個文件

TFS（Taobao Filesystem）淘寶的文件系統，在名稱節點上將元數據存儲與關系資料庫中，文件數量不在受限於名稱節點的內容空間，可以存儲海量小文件LustreOracle開發的企業級分布式系統，較重量級MooseFS基於FUSE的格式，可以進行掛載使用MogileFS

擅長存儲海量的小數據，元數據存儲與關系型資料庫中

1.簡介

MogileFS是一個開源的分布式文件系統，用於組建分布式文件集群，由LiveJournal旗下DangaInteractive公司開發，Danga團隊開發了包括 Memcached、MogileFS、Perlbal等不錯的開源項目：(註：Perlbal是一個強大的Perl寫的反向代理伺服器)。MogileFS是一個開源的分布式文件系統。

目前使用 MogileFS 的公司非常多,比如國外的一些公司,日本前幾名的公司基本都在使用這個.

國內所知道的使用 MogileFS 的公司有圖片託管網站 yupoo又拍,digg, 土豆, 豆瓣,1 號店, 大眾點評,搜狗,安居客等等網站.基本很多網站容量，圖片都超過 30T 以上。

2.MogileFS特性

1) 應用層提供服務，不需要使用核心組件

2）無單點失敗，主要有三個組件組成，分為tracker（跟蹤節點）、mogstore（存儲節點）、database（資料庫節點）

3）自動復制文件，復制文件的最小單位不是文件，而是class

4）傳輸中立，無特殊協議，可以通過NFS或HTTP實現通信

5）簡單的命名空間：沒有目錄，直接存在與存儲空間上，通過域來實現

6）不用共享任何數據

3.MogileFS的組成

1）Tracker--跟蹤器，調度器

MogileFS的核心，是一個調度器，mogilefsd進程就是trackers進程程序,trackers的主要職責有：刪除數據、復制數據、監控、查詢等等.這個是基於事件的( event-based ) 父進程/消息匯流排來管理所有來之於客戶端應用的交互(requesting operations to be performed), 包括將請求負載平衡到多個"query workers"中,然後讓 mogilefs的子進程去處理.

mogadm,mogtool的所有操作都要跟trackers打交道,Client的一些操作也需要定義好trackers,因此最好同時運行多個trackers來做負載均衡.trackers也可以只運行在一台機器上，使用負載均衡時可以使用搞一些簡單的負載均衡解決方案，如haproxy，lvs，nginx等，

tarcker的配置文件為/etc/mogilefs/mogilefsd.conf，監聽在TCP的7001埠

2）Database--資料庫部分

主要用來存儲mogilefs的元數據，所有的元數據都存儲在資料庫中，因此，這個數據相當重要，如果資料庫掛掉，所有的數據都不能用於訪問，因此，建議應該對資料庫做高可用

3）mogstored--存儲節點

數據存儲的位置，通常是一個HTTP（webDAV）伺服器，用來做數據的創建、刪除、獲取，任何 WebDAV 伺服器都可以, 不過推薦使用 mogstored . mogilefsd可以配置到兩個機器上使用不同埠… mogstored 來進行所有的 DAV 操作和流量,IO監測, 並且你自己選擇的HTTP伺服器(默認為 perlbal)用來做 GET 操作給客戶端提供文件.

典型的應用是一個掛載點有一個大容量的SATA磁碟. 只要配置完配置文件後mogstored程序的啟動將會使本機成為一個存儲節點.當然還需要mogadm這個工具增加這台機器到Cluster中.

配置文件為/etc/mogilefs/mogstored.conf，監聽在TCP的7500埠

4.基本工作流程

應用程序請求打開一個文件 (通過RPC 通知到 tracker, 找到一個可用的機器). 做一個 「create_open」 請求.

tracker 做一些負載均衡(load balancing)處理，決定應該去哪兒，然後給應用程序一些可能用的位置。

應用程序寫到其中的一個位置去 (如果寫失敗，他會重新嘗試並寫到另外一個位置去）.

應用程序 (client) 通過」create_close」 告訴tracker文件寫到哪裡去了.

tracker 將該名稱和域命的名空間關聯 (通過資料庫來做的)

tracker, 在後台, 開始復制文件，知道他滿足該文件類別設定的復制規則

然後,應用程序通過 「get_paths」 請求 domain+key (key == 「filename」) 文件, tracker基於每一位置的I/O繁忙情況回復(在內部經過 database/memcache/etc 等的一些抉擇處理), 該文件可用的完整 URLs地址列表.

應用程序然後按順序嘗試這些URL地址. (tracker』持續監測主機和設備的狀態，因此不會返回死連接,默認情況下他對返回列表中的第一個元素做雙重檢查，除非你不要他這么做..)

1.拓撲圖

說明：1.用戶通過URL訪問前端的nginx

2.nginx根據特定的挑選演算法，挑選出後端一台tracker來響應nginx請求

3.tracker通過查找database資料庫，獲取到要訪問的URL的值，並返回給nginx

4.nginx通過返回的值及某種挑選演算法挑選一台mogstored發起請求

5.mogstored將結果返回給nginx

6.nginx構建響應報文返回給客戶端

2.ip規劃

角色運行軟體ip地址反向代理nginx192.168.1.201存儲節點與調度節點1

mogilefs192.168.1.202存儲節點與調度節點2

mogilefs192.168.1.203資料庫節點

MariaDB192.168.1.204

3.資料庫的安裝操作並為授權

關於資料庫的編譯安裝，請參照本人相關博文http://wangfeng7399.blog.51cto.com/3518031/1393146，本處將不再累贅，本處使用的為yum源的安裝方式安裝mysql

4.安裝mogilefs. 安裝mogilefs，可以使用yum安裝，也可以使用編譯安裝，本處通過yum安裝

5.初始化資料庫

可以看到在資料庫中創建了一些表

6.修改配置文件，啟動服務

7.配置mogilefs

添加存儲主機

添加存儲設備

添加域

添加class

8.配置192.168.1.203的mogilefs 。切記不要初始化資料庫，配置應該與192.168.1.202一樣

9.嘗試上傳數據，獲取數據，客戶端讀取數據

上傳數據，在任何一個節點上傳都可以

獲取數據

客戶端查看數據

我們可以通過任何一個節點查看到數據

要想nginx能夠實現對後端trucker的反向代理，必須結合第三方模塊來實現

1.編譯安裝nginx

2.准備啟動腳本

3.nginx與mofilefs互聯

查看效果

5.配置後端truckers的集群

查看效果

大功告成了，後續思路，前段的nginx和資料庫都存在單點故障，可以實現高可用集群

Ⅱ 如何實現高性能分布式文件存儲

其實分布式文件存儲，最復雜的就是元數據的保存和處理，而我使用的XGFS文件存儲軟體只需要三個全快閃記憶體元數據高可用節點，就可以高效保存和處理 100 億文件規模的數據，可以靈活擴展，滿足公司不斷增長的業務對性能和容量的需求，XSKY星辰天合這款產品還是很有性價比的。

Ⅲ 如何配置ceph分布式存儲方案

1、對象存儲：即radosgw,兼容S3介面。通過rest api上傳、下載文件。
2、文件系統：posix介面。可以將ceph集群看做一個共享文件系統掛載到本地。
3、塊存儲：即rbd。有kernel rbd和librbd兩種使用方式。支持快照、克隆。相當於一塊硬碟掛到本地，用法和用途和硬碟一樣。

Ⅳ hadoop分布式部署（轉載）--賊靠譜

原文地址：https://blog.csdn.net/sjmz30071360/article/details/79889055

1. 集群搭建形式

Hadoop環境搭建分為三種形式：單機模式、偽分布式模式、完全分布模式

單機模式—— 在一台單機上運行，沒有分布式文件系統，而是直接讀寫本地操作系統的文件系統。

偽分布式—— 也是在一台單機上運行，但不同的是java進程模仿分布式運行中的各類節點。即一台機器上，既當NameNode，又當DataNode，或者說既是JobTracker又是TaskTracker。沒有所謂的在多台機器上進行真正的分布式計算，故稱為「偽分布式」。

完全分布式—— 真正的分布式，由3個及以上的實體機或者虛擬機組成的機群。一個Hadoop集群環境中，NameNode，SecondaryName和DataNode是需要分配在不同的節點上，也就需要三台伺服器。

前兩種模式一般用在開發或測試環境下，生產環境下都是搭建完全分布式模式。

從分布式存儲的角度來說，集群中的節點由一個NameNode和若干個DataNode組成，另有一個SecondaryNameNode作為NameNode的備份。

從分布式應用的角度來說，集群中的節點由一個JobTracker和若干個TaskTracker組成。JobTracker負責任務的調度，TaskTracker負責並行執行任務。TaskTracker必須運行在DataNode上，這樣便於數據的本地計算。JobTracker和NameNode則無須在同一台機器上。

2. 環境

    操作系統：CentOS7（紅帽開源版）

    機器：虛擬機3台，（master 192.168.0.104, slave1 192.168.0.102, slave2 192.168.0.101）

    JDK：1.8（jdk-8u162-linux-x64.tar）

    Hadoop：2.9.0（http://www.apache.org/dyn/closer.cgi/hadoop/common/hadoop-2.9.0/hadoop-2.9.0.tar.gz）

3. 搭建步驟

3.1 每台機器安裝&配置JDK（1台做好後，克隆出其它機器）

1) 創建目錄 mkdir /usr/java

2) 上傳jdk安裝包到 /usr/java/

3) 解壓 tar -xvf jdk-8u162-linux-x64.tar

4) 追加環境變數 vi /etc/profile

5) 使環境變數生效 source /etc/profile

6) 檢測jdk正確安裝 java -version

3.2 修改每台機器主機名(hostname)

hostnamectl set-hostname master  （立即生效）

hostnamectl set-hostname slave1    （立即生效）

hostnamectl set-hostname slave2    （立即生效）

確認修改

3.3 修改每台機器/etc/hosts文件

vi /etc/hosts

修改其中1台，然後scp到其它機器

scp 文件名 遠程主機用戶名@遠程主機名或ip:存放路徑

scp hosts [email protected]:/etc/

scp hosts [email protected]:/etc/

修改完之後，互ping其它機器，能互ping則說明修改OK

ping -c 3 slave1 （※ 3表示發送 3 個數據包）

3.4 配置ssh，實現無密碼登錄

無密碼登錄，效果也就是在master上，通過ssh slave1或者ssh slave2就可以登錄對方機器，而不用輸入密碼。

1） 每台機器執行ssh-keygen -t rsa，接下來一路回車即可

執行ssh-keygen -t rsa主要是生成 密鑰 和 密鑰的存放路徑

我們用的root用戶，公鑰私鑰都會保存在~/.ssh下

2） 在master上將公鑰放到authorized_keys里，命令：cat id_rsa.pub > authorized_keys

3） 將master上的authorized_keys放到其它機器上

scp authorized_keys root@slave1:~/.ssh/

scp authorized_keys root@slave2:~/.ssh/

4） 測試是否成功

3.5 上傳&配置hadoop（配置完master後，將/usr/hadoop/整個目錄內容到其它機器）

1） 創建目錄 mkdir /usr/hadoop

2） 上傳hadoop安裝包hadoop-2.9.0.tar.gz到 /usr/hadoop/

3） 解壓 tar -xvf hadoop-2.9.0.tar.gz

4） 追加環境變數 vi /etc/profile（其它機器也要相應配置一次hadoop環境變數）

5） 使環境變數生效 source /etc/profile

6） 確認環境變數配置OK

7） 創建HDFS存儲目錄

cd /usr/hadoop

mkdir hdfs

cd hdfs

mkdir name data tmp

/usr/hadoop/hdfs/name    --存儲namenode文件

/usr/hadoop/hdfs/data      --存儲數據

/usr/hadoop/hdfs/tmp      --存儲臨時文件

8） 修改/usr/hadoop/hadoop-2.9.0/etc/hadoop/hadoop-env.sh文件，設置JAVA_HOME為實際路徑

否則啟動集群時，會提示路徑找不到

9） 修改/usr/hadoop/hadoop-2.9.0/etc/hadoop/yarn-env.sh文件，設置JAVA_HOME為實際路徑

10） 配置/usr/hadoop/hadoop-2.9.0/etc/hadoop/core-site.xml

增加hadoop.tmp.dir 和 fs.default.name

11） 配置/usr/hadoop/hadoop-2.9.0/etc/hadoop/hdfs-site.xml

dfs.replication：默認值3

dfs.permissions：默認值為true，設置為true有時候會遇到數據因為許可權訪問不了；設置為false可以不要檢查許可權就生成dfs上的文件

12） 配置/usr/hadoop/hadoop-2.9.0/etc/hadoop/mapred-site.xml

cd /usr/hadoop/hadoop-2.9.0/etc/hadoop

cp mapred-site.xml.template mapred-site.xml

maprece.framework.name：指定maprece運行在yarn平台，默認為local

13） 配置/usr/hadoop/hadoop-2.9.0/etc/hadoop/yarn-site.xml

yarn.resourcemanager.hostname：指定yarn的resourcemanager的地址

yarn.nodemanager.aux-services：recer獲取數據的方式

yarn.nodemanager.vmem-check-enabled：意思是忽略虛擬內存的檢查，如果安裝在虛擬機上，這個配置很有用，配上去之後後續操作不容易出問題。如果是在實體機上，並且內存夠多，可以將這個配置去掉

14） 配置/usr/hadoop/hadoop-2.9.0/etc/hadoop/slaves文件，將裡面的localhost刪除，配置後內容如下：

15） 整個/usr/hadoop/目錄到其它機器

scp -r hadoop root@slave1:/usr/

scp -r hadoop root@slave2:/usr/

3.6 啟動Hadoop

1） 啟動之前需要格式化一下。因為master是namenode，slave1和slave2都是datanode，所以在master上運行

hadoop namenode -format

格式化成功後，可以看到在/usr/hadoop/hdfs/name目錄下多了一個current目錄，而且該目錄下有一系列文件，如下：

2） 執行啟動（namenode只能在master上啟動，因為配置在master上；datanode每個節點上都可以啟動）

執行 start-all.sh

master上執行jps，會看到NameNode, SecondaryNameNode, ResourceManager

其它節點上執行jps，會看到DataNode, NodeManager

3） 在wins上打開網頁，查看HDFS管理頁面 http://192.168.0.104:50070查看，提示無法訪問

在master上，執行以下命令關閉防火牆，即可訪問（為了能夠正常訪問node節點，最好把其它機器的防火牆也stop了）

systemctl stop firewalld.service

HDFS管理首頁

HDFS Datenodes頁

訪問Yarn管理頁： http://192.168.0.104:8088

4）通過主機名也可以訪問的設置

win7為例，需要將以下信息追加到C:\Windows\System32\drivers\etc\hosts文件中

192.168.0.104 master

192.168.0.102 slave1

192.168.0.101 slave2

Over！！！搭建成功！！！

4. 運行實例

cd /usr/hadoop/hadoop-2.9.0/share/hadoop/maprece

hadoop jar hadoop-maprece-examples-2.9.0.jar pi 5 10

。。。。。。

=====================================================

如果不關防火牆，子節點可能出現，輸入jps後只有jps一個進程，或者是缺進程的情況，關閉防火牆就好了。

Ⅳ 如何實現不同地區文件分布式存儲

一種方案是：架設Hadoop集群作為雲存儲，類似網路雲盤。Hadoop集群的每個節點要麼在公網要麼在內網，如果公網和內網混合就需要用四層交換機把每個節點的埠映射出來。其他的方案可以參考這種模式。

Ⅵ 分布式存儲極簡藝術Minio解析

 MinIO 對象存儲系統是為海量數據存儲、人工智慧、大數據分析而設計，基於
Apache License v2.0 開源協議的對象存儲系統，它完全兼容 Amazon S3 介面，單個對象的最大可達 5TB，適合存儲海量圖片、視頻、日誌文件、備份數據和容器/虛擬機鏡像等。作為一個開源服務，MinIO 在設計上汲取了Glusterfs的相關經驗不教訓，系統復雜度上作了大量簡化，目前大小隻有40+M，部署只需要一個命令即可完成！另外，minio舍棄了傳統分布式存儲擴容所需要的遷移流程，採用聯盟模式添加集群的方式，極大簡化了擴容流程；除此之外，minio還具有糾刪編碼、比特位保護、單寫多讀（worm)、下面來依次簡要解析一下Mioio的特點及具體實現：

  元數據和數據一起存放在磁碟上。元數據以明文形式存放在元數據文件里（xl.json）。假定對象名字為key_name, 它所在桶的名字是bucket_name, disk路徑就是/disk，那麼存儲路徑就是：/disk/bucket_name/key_name，windows下C盤存放桶名為test，對象名為minio.exe示例如圖：

其中part.1是實際存儲數據（單機模式為原生數據，分布式為糾刪碼分塊），xl.json是如下所示的json字元串：

  在同一集群內，MinIO 自己會自勱生成若干糾刪組，用於分布存放桶數據。一個糾刪組中的一定數量的磁碟發生的故障（故障磁碟的數量小於等於校驗盤的數量），通過糾刪碼校驗演算法可以恢復出正確的數據。MinIO 集成了 Reed-Solomon 糾刪碼庫，MinIO 存儲對象數據時，首先把它分成若乾等長的片段（對於大對象，默認按 5MB 切片)，然後每一個片段會糾刪演算法分成若干分片，包括數據分片不校驗分片，每個分片放置在一個糾刪組的某個節點上。對象的每一個數據分片、校驗分片都被「防比特位衰減」演算法所保護。

  MinIO 會根據對象名（類似於文件系統的全路徑名)，使用 crc32 哈希演算法計算出一個整數。然後使用這個整數除以糾刪組的個數，得到一個余數。這個余數，可以作為糾刪組的序號，這樣就確定了這個對象所在的糾刪組。MinIO 採用 CRC32 哈希演算法，不 glusterfs 的Davies Meyer哈希演算法（性能、沖突概率不md4, md5相近）不一樣的是，CRC32演算法的哈希值分布較不均勻，但運算速度極快，高出 md4 數倍。相對於容量均衡，MinIO 更看重數據的寫入速度。

糾刪組如何配置？
官方文檔說明如下：

 也就是說糾刪組的總大小隻能從這7中情況中根據你提供的盤的個數（或者說路徑個數）來自動選取最大值的，我們 不能靈活地配置m+k糾刪存儲格式。但這樣說又不是很准確 ，因為雖然不能配置任意的m+k，但是在系統已經選取好擦除編碼集的的個數後（也就是m+k），可以使用storage class存儲類來自定義m和k的數量，默認是1:1的。
存儲類：
 MinIO支持配置兩種存儲類別，精簡冗餘類別和標准類別，默認是標准類別（1：1），可以在啟動MinIO伺服器之前使用設置的環境變數來定義這些類。使用環境變數定義每個存儲類別的數據和奇偶校驗磁碟後，您可以 在上傳對象時通過請求元數據欄位設置對象的存儲類別x-amz-storage-class 。然後，MinIO伺服器通過將對象保存在特定數量的數據和奇偶校驗磁碟中來兌現存儲類。具體配置和使用可以參考官方文檔 https://github.com/minio/minio/tree/master/docs/erasure/storage-class

傳統的擴展方式的劣勢
  通過增加節點來擴展單集群，一般需要進行數據均衡，否則群集內各存儲節點會因負載不均而出現新的瓶頸。除了數據均衡操作的時機這個問題以外，在均衡過程中一般需要仍存儲使用率高的節點吐使用率低的節點遷移數據。當集群擴容後，大量已經寫入的文件落點會出現改變，文件需要遷移到真實的落點。當存儲系統容量比較大時，則會發生大量的文件/對象進行遷移,遷移過程可能由於佔用大量資源而導致上層應用性能下降。而且當文件/對象遷移過程中，機器故障可能會導致一些意想不到的情冴,尤其是有大量業務的時候。當然針對此類問題，Gluterfs之類的文件系統有一些比較復雜的處理辦法。
不支持擴展優勢

Ⅶ 區塊鏈分布式存儲：生態大數據的存儲新模式

區塊鏈，當之無愧的2019最靚的詞，在 科技 領域閃閃發亮，在實體行業星光熠熠。

2019年的1024講話，讓區塊鏈這個詞煥然一新，以前它總是和傳銷和詐騙聯系在一起，「區塊鏈」這個詞總是蒙上一層灰色。但是如今，區塊鏈則是和實體經濟融合緊密相連，成為國家的戰略技術， 這個詞瞬間閃耀著熱情的紅色和生意盎然的綠色 。

「產業區塊鏈」在這個時代背景下應運而生， 是繼「互聯網」後的又一大熱門詞彙，核心就是區塊鏈必須和實體產業融合，脫虛向實，讓區塊鏈技術找到更多業務場景才是正道。

區塊鏈的本質就是一個資料庫，而且是採用的分布式存儲的方式。作為一名區塊鏈從業者，今天就來講講 區塊鏈的分布式存儲和生態大數據 結合後，碰撞產生的火花。

當前的存儲大多為中心化存儲，存儲在傳統的中心化伺服器。如果伺服器出現宕機或者故障，或者伺服器停止運營，則很多數據就會丟失。

比如我們在微信朋友圈發的圖片，在抖音上傳的視頻等等，都是中心化存儲。很多朋友會把東西存儲在網上，但是某天打開後，網頁呈現404，則表示存儲的東西已經不見了。

區塊鏈，作為一個分布式的資料庫，則能很好解決這方面的問題。這是由區塊鏈的技術特徵決定了的。 區塊鏈上的數字記錄，不可篡改、不可偽造，智能合約讓大家更高效地協同起來，從而建立可信的數字經濟秩序，能夠提高數據流轉效率，打破數據孤島，打造全新的存儲模式。

生態大數據，其實和我們每天的生活息息相關，比如每天的天氣預報，所吃的農產品的溯源數據等等，都是生態大數據的一部分。要來談這個結合，首先咱們來看看生態大數據存儲的特點。

伴隨著互聯網的發展，當前，生態大數據在存儲方面有具有如下特點：

從數據規模來看，生態數據體量很大，數據已經從TB級躍升到了PB級別。

隨著各類感測器技術、衛星遙感、雷達和視頻感知等技術的發展，數據不僅來源於傳統人工監測數據，還包括航空、航天和地面數據，他們一起產生了海量生態環境數據。近10年以來，生態數據以每年數百個TB的數據在增長。

生態環境大數據需要動態新數據和 歷史 數據相結合來處理，實時連續觀測尤為重要。只有實時處理分析這些動態新數據，並與已有 歷史 數據結合起來分析，才能挖掘出有用信息，為解決有關生態環境問題提供科學決策。

比如在當前城市建設中，提倡的生態環境修復、生態模型建設中，需要大量調用生態大數據進行分析、建模和制定方案。但是目前很多 歷史 數據因為存儲不當而消失，造成了數據的價值的流失。

既然生態大數據有這些特點，那麼它有哪些存儲需求呢？

當前，生態大數據面臨嚴重安全隱患，強安全的存儲對於生態大數據而言勢在必行。

大數據的安全主要包括大數據自身安全和大數據技術安全，比如在大數據的數據存儲中，由於黑客外部網路攻擊和人為操作不當造成數據信息泄露。外部攻擊包括對靜態數據和動態數據的數據傳輸攻擊、數據內容攻擊、數據管理和網路物理攻擊等。

例如，很多野外生態環境監測的海量數據需要網路傳輸，這就加大了網路攻擊的風險。如果涉及到軍用的一些生態環境數據，如果被黑客獲得這些數據，就可能推測到我國軍方的一些信息，或者獲取敏感的生態環境數據，後果不堪設想。

生態大數據的商業化應用需要整合集成政府、企業、科研院所等 社會 多來源的數據。只有不同類型的生態環境大數據相互連接、碰撞和共享，才能釋放生態環境大數據的價值。

以當前的智慧城市建設為例，很多城市都在全方位、多維度建立知識產權、種質資源、農資、農產品、病蟲害疫情等農業信息大數據中心，為農業產供銷提供全程信息服務。建設此類大數據中心，離不開各部門生態大數據的共享。

但是，生態大數據共享面臨著巨大挑戰。首先，我國生態環境大數據包括氣象、水利、生態、國土、農業、林業、交通、 社會 經濟等其他部門的大數據，涉及多領域多部門和多源數據。雖然目前這些部門已經建立了自己的數據平台，但這些平台之間互不連通，只是一個個的數據孤島。

其次，相關部門因為無法追蹤數據的軌跡，擔心數據的利益歸屬問題，便無法實現數據的共享。因此，要想挖掘隱藏在生態大數據背後的潛在價值，實現安全的數據共享是關鍵，也是生態大數據產生價值的前提和基礎。

生態大數據來之不易，是研究院所、企業、個人等 社會 來源的集體智慧。

其中，很多生態大數據涉及到了知識產權的保護。但是目前的中心化存儲無法保證知識產權的保護，無法對數據的使用進行溯源管理，容易造成知識產權的侵犯和隱私數據的泄露。

這些就是生態大數據在存儲方面的需求。在當前產業區塊鏈快速發展的今天，區塊鏈的分布式存儲是可以為生態大數據存儲提供全新的存儲方式的。 這個核心前提就是區塊鏈的分布式存儲、不可篡改和數據追蹤特性 。

把區塊鏈作為底層技術，搭建此類平台，專門存儲生態大數據，可以設置節點管理、存儲管理、用戶管理、許可管理、業務通道管理等。針對上層業務應用提供高可用和動態擴展的區塊鏈網路底層服務的實現。在這個平台的應用層，可以搭建API介面，讓整個平台的使用靈活可擴展。區塊鏈分布式存儲有如下特點：

利用區塊鏈的分布式存儲，能夠實現真正的生態大數據安全存儲。

首先，數據永不丟失。這點對於生態大數據的 歷史 數據特別友好，方便新老數據的調用和對比。

其次，數據不易被泄露或者攻擊。因為數據採取的是分布式存儲，如果遭遇攻擊，也只能得到存儲在部分節點里的數據碎片，無法完全獲得完整的數據信息或者數據段。

區塊鏈能夠實現生態數據的存儲即確權，這樣就能夠避免知識產權被侵害，實現安全共享。畢竟生態大數據的獲取，是需要生態工作者常年在野外駐守，提取數據的。

生態大數據來之不易，是很多生態工作者的工作心血和結晶，需要得到產權的保護，讓數據體現出應用價值和商業價值，保護生態工作者的工作動力，讓他們能夠深入一線，採集出更多優質的大數據。

同時，利用區塊鏈的數據安全共享機制，也能夠打破氣象、林業、濕地等部門的數據壁壘，構建安全可靠的數據共享機制，讓數據流轉更具價值。

現在有部分生態工作者，為了牟取私利，會將生態數據篡改。如果利用區塊鏈技術，則沒有那麼容易了。

利用加密技術，把存儲的數據放在分布式存儲平台進行加密處理。如果生態大數據發生變更，平台就可以記錄其不同版本，便於事後追溯和核查。

這個保護機制主要是利用了數據的不可篡改，滿足在使用生態大數據的各類業務過程中對數據的安全性的要求。

區塊鏈能夠對數據提供安全監控，記錄應用系統的操作日誌、資料庫的操作日誌數據，並加密存儲在系統上，提供日誌預警功能，對於異常情況通過區塊鏈瀏覽器展示出來，便於及時發現違規的操作和提供證據。

以上就是區塊鏈的分布式存儲能夠在生態大數據方面所起的作用。未來，肯定會出現很多針對生態大數據存儲的平台誕生。

生態大數據是智慧城市建設的重要基礎資料 ，引用區塊鏈技術，打造相關的生態大數據存儲和管理平台，能夠保證生態大數據的安全存儲和有效共享，為智慧城市建設添磚加瓦，推動產業區塊鏈的發展。

作者：Justina，微信公眾號：妙譯生花，從事於區塊鏈運營，擅長內容運營、海外媒體運營。

題圖來自Unsplash, 基於CC0協議。

Ⅷ B站分布式KV存儲實踐

在B站的業務場景中，存在很多種不同模型的數據，有些數據關系比較復雜像：賬號、稿件信息。有些數據關系比較簡單，只需要簡單的kv模型即可滿足。此外，又存在某些讀寫吞吐比較高的業務場景，該場景早期的解決方案是通過MySQL來進行數據的持久化存儲，同時通過redis來提升訪問的速度與吞吐。但是這種模式帶來了兩個問題，其一是存儲與緩存一致性的問題，該問題在B站通過canal非同步更新緩存的方式得以解決，其二則是開發的復雜度，對於這樣一套存儲系統，每個業務都需要額外維護一個任務腳本來消費canal數據進行緩存數據的更新。基於這種場景，業務需要的其實是一個介於Redis與MySQL之間的提供持久化高性能的kv存儲。此外對象存儲的元數據，對數據的一致性、可靠性與擴展性有著很高的要求。

基於此背景，我們對自研KV的定位從一開始就是構建一個高可靠、高可用、高性能、高拓展的系統。對於存儲系統，核心是保證數據的可靠性，當數據不可靠時提供再高的可用性也是沒用的。可靠性的一個核心因素就是數據的多副本容災，通過raft一致性協議保證多副本數據的一致性。

分布式系統，如何對數據進行分片放置，業界通常有兩種做法，一是基於hash進行分區，二是基於range進行分區，兩種方式各有優缺點。hash分區，可以有效防止熱點問題，但是由於key是hash以後放置的，無法保證key的全局有序。range分區，由於相鄰的數據都放在一起，因此可以保證數據的有序，但是同時也可能帶來寫入熱點的問題。基於B站的業務場景，我們同時支持了range分區和hash分區，業務接入的時候可以根據業務特性進行選擇。大部分場景，並不需要全局有序，所以默認推薦hash分區的接入方式，比如觀看記錄、用戶動態這些場景，只需要保證同一個用戶維度的數據有序即可，同一個用戶維度的數據可以通過hashtag的方式保證局部有序。

整個系統核心分為三個組件:
Metaserver用戶集群元信息的管理，包括對kv節點的健康監測、故障轉移以及負載均衡。

Node為kv數據存儲節點，用於實際存儲kv數據，每個Node上保存數據的一個副本，不同Node之間的分片副本通過raft保證數據的一致性，並選出主節點對外提供讀寫，業務也可以根據對數據一致性的需求指定是否允許讀從節點，在對數據一致性要求不高的場景時，通過設置允許讀從節點可以提高可用性以及降低長尾。

Client模塊為用戶訪問入口，對外提供了兩種接入方式，一種是通過proxy模式的方式進行接入，另一種是通過原生的SDK直接訪問，proxy本身也是封裝自c++的原生SDK。SDK從Metaserver獲取表的元數據分布信息，根據元數據信息決定將用戶請求具體發送到哪個對應的Node節點。同時為了保證高可用，SDK還實現了重試機制以及backoff請求。

集群的拓撲結構包含了幾個概念，分別是Pool、Zone、Node、Table、Shard 與Replica。

基於不同的業務場景，我們同時支持了range分區和hash分區。對於range場景，隨著用戶數據的增長，需要對分區數據進行分裂遷移。對於hash分區的場景，使用上通常會根據業務的數據量做幾倍的冗餘預估，然後創建合適的分片數。但是即便是幾倍的冗餘預估，由於業務發展速度的不可預測，也很容易出現實際使用遠超預估的場景，從而導致單個數據分片過大。

之所以不在一開始就創建足夠的分片數有兩個原因：其一，由於每一個replica都包含一個獨立的engine，過多的分片會導致數據文件過多，同時對於批量寫入場景存在一定的寫扇出放大。其二，每一個shard都是一組raftgroup，過多的raft心跳會對服務造成額外的開銷，這一點後續我們會考慮基於節點做心跳合並優化減少集群心跳數。

為了滿足業務的需求場景，我們同時支持了range和hash兩種模式下的分裂。兩種模式分裂流程類似，下面以hash為例進行說明。

hash模式下的分裂為直接根據當前分片數進行倍增。分裂的流程主要涉及三個模塊的交互。

metaserver
分裂時，metaserver會根據當前分片數計算出目標分片數，並且下發創建replica指令到對應的Node節點，同時更新shard分布信息，唯一不同的是，處於分裂中的shard狀態為splitting。該狀態用於client流量請求路由識別。當Node完成數據分裂以後上報metaserver，metaserver更新shard狀態為normal從而完成分裂。

Node
node收到分裂請求以後，會根據需要分裂的分片id在原地拉起創建一個新的分片。然後對舊分片的數據進行checkpoint，同時記錄舊分片checkpoint對應的logid。新分片創建完成後，會直接從舊分片的checkpoint進行open，然後在非同步復制logid之後的數據保證數據的一致性。新分片載入完checkpoint後，原來的舊分片會向raftgroup提交一條分裂完成日誌，該日誌處理流程與普通raft日誌一致。分裂完成後上報分裂狀態到metaserver，同時舊分片開始拒絕不再屬於自己分片的數據寫入，client收到分片錯誤以後會請求metaserver更新shard分布。
完成分裂以後的兩個分片擁有的兩倍冗餘數據，這些數據會在engine compaction的時候根據compaction_filter過濾進行刪除。

Client
用戶請求時，根據hash(key) % shard_cnt 獲取目標分片。表分裂期間，該shard_cnt表示分裂完成後的最終分片數。以上圖3分片的分裂為例:
hash(key) = 4, 分裂前shard_cnt為3，因此該請求會被發送到shard1. 分裂期間，由於shard_cnt變為6，因此目標分片應該是shard4， 但是由於shard4為splitting，因此client會重新計算分片從而將請求繼續發送給shard1. 等到最終分裂完成後，shard4狀態變更為Normal，請求才會被發送到shard4.
分裂期間，如果Node返回分片信息錯誤，那麼client會請求metaserver更新分片分布信息。

類似於MySQL的binlog，我們基於raftlog日誌實現了kv的binlog. 業務可以根據binlog進行實時的事件流訂閱，同時為了滿足事件流回溯的需求，我們還對binlog數據進行冷備。通過將binlog冷備到對象存儲，滿足了部分場景需要回溯較長事件記錄的需求。

直接復用raftlog作為用戶行為的binlog，可以減少binlog產生的額外寫放大，唯一需要處理的是過濾raft本身的配置變更信息。learner通過實時監聽不斷拉取分片產生的binlog到本地並解析。根據learner配置信息決定將數據同步到對應的下游。同時binlog數據還會被非同步備份到對象存儲，當業務需要回溯較長時間的事件流的時候，可以直接指定位置從S3拉取歷史binlog進行解析。

基於上述提到的binlog能力，我們還基於此實現了kv的多活。learner模塊會實時將用戶寫入的數據同步到跨數據中心的其他kv集群。對於跨數據中心部署的業務，業務可以選擇就近的kv集群進行讀取訪問，降低訪問延時。

kv的多活分為讀多活和寫多活。對於讀多活，機房A的寫入會被非同步復制到機房B，機房B的服務可以直接讀取本機房的數據，該模式下只有機房A的kv可以寫入。對於寫多活，kv在機房A B 都能同時提供寫入並且進行雙向同步，但是為了保證數據的一致性，需要業務上做數據的單元化寫入，保證兩個機房不會同時修改同一條記錄。通過將用戶劃分單元，提供了寫多活的能力。通過對binlog數據打標，解決了雙向同步時候的數據回環問題。

對於用戶畫像和特徵引擎等場景，需要將離線生成的大量數據快速導入KV存儲系統提供用戶讀取訪問。傳統的寫入方式是根據生成的數據記錄一條條寫入kv存儲，這樣帶來兩個問題。其一，大批量寫入會對kv造成額外的負載與寫入帶寬放大造成浪費。其次，由於寫入量巨大，每次導入需要花費較長的時間。為了減少寫入放大以及導入提速，我們支持了bulk load的能力。離線平台只需要根據kv的存儲格式離線生成對應的SST文件，然後上傳到對象存儲服務。kv直接從對象存儲拉取SST文件到本地，然後直接載入SST文件即可對外提供讀服務。bulk load的另外一個好處是可以直接在生成SST後離線進行compaction，將compaction的負載offload到離線的同時也降低了空間的放大。

由於LSM tree的寫入特性，數據需要被不斷的compaction到更底層的level。在compaction時，如果該key還有效，那麼會被寫入到更底層的level里，如果該key已經被刪除，那麼會判斷當前level是否是最底層的，一條被刪除的key，會被標記為刪除，直到被compaction到最底層level的時候才會被真正刪除。compaction的時候會帶來額外的寫放大，尤其當value比較大的時候，會造成巨大的帶寬浪費。為了降低寫放大，我們參考了Bitcask實現了kv分離的存儲引擎sparrowdb.

sparrowdb 介紹

用戶寫入的時候，value通過append only的方式寫入data文件，然後更新索引信息，索引的value包含實際數據所在的data文件id，value大小以及position信息，同時data文件也會包含索引信息。與原始的bitcask實現不一樣的是，我們將索引信息保存在 rocksdb。

更新寫入的時候，只需要更新對應的索引即可。compaction的時候，只需將索引寫入底層的level，而無需進行data的拷貝寫入。對於已經失效的data，通過後台線程進行檢查，當發現data文件里的索引與rocksdb保存的索引不一致的時候，說明該data已經被刪除或更新，數據可以被回收淘汰。

使用kv存儲分離降低了寫放大的問題，但是由於kv分離存儲，會導致讀的時候多了一次io，讀請求需要先根據key讀到索引信息，再根據索引信息去對應的文件讀取data數據。為了降低讀訪問的開銷，我們針對value比較小的數據進行了inline，只有當value超過一定閾值的時候才會被分離存儲到data文件。通過inline以及kv分離獲取讀性能與寫放大之間的平衡。

在分布式系統中，負載均衡是繞不過去的問題。一個好的負載均衡策略可以防止機器資源的空閑浪費。同時通過負載均衡，可以防止流量傾斜導致部分節點負載過高從而影響請求質量。對於存儲系統，負載均衡不僅涉及到磁碟的空間，也涉及到機器的內存、cpu、磁碟io等。同時由於使用raft進行主從選主，保證主節點盡可能的打散也是均衡需要考慮的問題。

副本均衡
由於設計上我們會盡量保證每個副本的大小盡量相等，因此對於空間的負載其實可以等價為每塊磁碟的副本數。創建副本時，會從可用的zone中尋找包含副本數最少的節點進行創建。同時考慮到不同業務類型的副本讀寫吞吐可能不一樣導致CPU負載不一致，在挑選副本的時候會進一步檢查當前節點的負載情況，如果當前節點負載超過閾值，則跳過該節點繼續選擇其他合適的節點。目前基於最少副本數以及負載校驗基本可以做到集群內部的節點負載均衡。
當出現負載傾斜時，則從負載較高的節點選擇副本進行遷出，從集群中尋找負載最低的節點作為待遷入節點。當出現節點故障下線以及新機器資源加入的時候，也是基於均值計算待遷出以及遷入節點進行均衡。

主從均衡
雖然通過最少副本數策略保證了節點副本數的均衡，但是由於raft選主的性質，可能出現主節點都集中在部分少數節點的情況。由於只有主節點對外提供寫入，主節點的傾斜也會導致負載的不均衡。為了保證主節點的均衡，Node節點會定期向metaserver上報當前節點上副本的主從信息。
主從均衡基於表維度進行操作。metaserver會根據表在Node的分布信息進行副本數的計算。主副本的數量基於最樸素簡單的數學期望進行計算: 主副本期望值 = 節點副本數 / 分片副本數。下面為一個簡單的例子:
假設表a包含10個shard，每個shard 3個replica。在節點A、B、C、D的分布為 10、5、6、9. 那麼A、B、C、D的主副本數期望值應該為 3、1、2、3. 如果節點數實際的主副本數少於期望值，那麼被放入待遷入區，如果大於期望值，那麼被放入待遷出區。同時通過添加誤差值來避免頻繁的遷入遷出。只要節點的實際主副本數處於 [x-δx,x+δx] 則表示主副本數處於穩定期間，x、δx 分別表示期望值和誤差值。
需要注意的是，當對raft進行主從切換的時候，從節點需要追上所有已提交的日誌以後才能成功選為主，如果有節點落後的時候進行主從切換，那麼可能導致由於追數據產生的一段時間無主的情況。因此在做主從切換的時候必須要檢查主從的日誌復制狀態，當存在慢節點的時候禁止進行切換。

3.7 故障檢測&修復
一個小概率的事件，隨著規模的變大，也會變成大概率的事件。分布式系統下，隨著集群規模的變大，機器的故障將變得愈發頻繁。因此如何對故障進行自動檢測容災修復也是分布式系統的核心問題。故障的容災主要通過多副本raft來保證，那麼如何進行故障的自動發現與修復呢。

健康監測
metaserver會定期向node節點發送心跳檢查node的健康狀態，如果node出現故障不可達，那麼metaserver會將node標記為故障狀態並剔除，同時將node上原來的replica遷移到其他健康的節點。
為了防止部分node和metaserver之間部分網路隔離的情況下node節點被誤剔除，我們添加了心跳轉發的功能。上圖中三個node節點對於客戶端都是正常的，但是node3由於網路隔離與metaserver不可達了，如果metaserver此時直接剔除node3會造成節點無必要的剔除操作。通過node2轉發心跳探測node3的狀態避免了誤剔除操作。
除了對節點的狀態進行檢測外，node節點本身還會檢查磁碟信息並進行上報，當出現磁碟異常時上報異常磁碟信息並進行踢盤。磁碟的異常主要通過dmesg日誌進行採集分析。

故障修復
當出現磁碟節點故障時，需要將原有故障設備的replica遷移到其他健康節點，metaserver根據負載均衡策略選擇合適的node並創建新replica， 新創建的replica會被加入原有shard的raft group並從leader復制快照數據，復制完快照以後成功加入raft group完成故障replica的修復。
故障的修復主要涉及快照的復制。每一個replica會定期創建快照刪除舊的raftlog，快照信息為完整的rocksdb checkpoint。通過快照進行修復時，只需要拷貝checkpoint下的所有文件即可。通過直接拷貝文件可以大幅減少快照修復的時間。需要注意的是快照拷貝也需要進行io限速，防止文件拷貝影響在線io.

過期數據淘汰
在很多業務場景中，業務的數據只需要存儲一段時間，過期後數據即可以自動刪除清理，為了支持這個功能，我們通過在value上添加額外的ttl信息，並在compaction的時候通過compaction_filter進行過期數據的淘汰。level之間的容量呈指數增長，因此rocksdb越底層能容納越多的數據，隨著時間的推移，很多數據都會被移動到底層，但是由於底層的容量比較大，很難觸發compaction，這就導致很多已經過期的數據沒法被及時淘汰從而導致了空間放大。與此同時，大量的過期數據也會對scan的性能造成影響。這個問題可以通過設置periodic_compaction_seconds 來解決，通過設置周期性的compaction來觸發過期數據的回收。

scan慢查詢
除了上面提到的存在大批過期數據的時候可能導致的scan慢查詢，如果業務存在大批量的刪除，也可能導致scan的時候出現慢查詢。因為delete對於rocksdb本質也是一條append操作，delete寫入會被添加刪除標記，只有等到該記錄被compaction移動到最底層後該標記才會被真正刪除。帶來的一個問題是如果用戶scan的數據區間剛好存在大量的delete標記，那麼iterator需要迭代過濾這些標記直到找到有效數據從而導致慢查詢。該問題可以通過添加 CompactOnDeletionCollector 來解決。當memtable flush或者sst compaction的時候，collector會統計當前key被刪除的比例，通過設置合理的 deletion_trigger ，當發現被delete的key數量超過閾值的時候主動觸發compaction。

delay compaction
通過設置 CompactOnDeletionCollector 解決了delete導致的慢查詢問題。但是對於某些業務場景，卻會到來嚴重的寫放大。當L0被compaction到L1時候，由於閾值超過deletion_trigger ,會導致L1被添加到compaction隊列，由於業務的數據特性，L1和L2存在大量重疊的數據區間，導致每次L1的compaction會同時帶上大量的L2文件造成巨大的寫放大。為了解決這個問題，我們對這種特性的業務數據禁用了CompactOnDeletionCollector 。通過設置表級別參數來控製表級別的compaction策略。後續會考慮優化delete trigger的時機，通過只在指定層級觸發來避免大量的io放大。

compaction限速
由於rocksdb的compaction會造成大量的io讀寫，如果不對compaction的io進行限速，那麼很可能影響到在線的寫入。但是限速具體配置多少比較合適其實很難確定，配置大了影響在線業務，配置小了又會導致低峰期帶寬浪費。基於此rocksdb 在5.9以後為 NewGenericRateLimiter 添加了 auto_tuned 參數，可以根據當前負載自適應調整限速。需要注意的是，該函數還有一個參數 RateLimiter::Mode 用來限制操作類型，默認值為 kWritesOnly,通常情況該模式不會有問題，但是如果業務存在大量被刪除的數據，只限制寫可能會導致compaction的時候造成大量的讀io。

關閉WAL
由於raft log本身已經可以保證數據的可靠性，因此寫入rocksdb的時候可以關閉wal減少磁碟io，節點重啟的時候根據rocksdb里保存的last_apply_id從raft log進行狀態機回放即可。

降副本容災
對於三副本的raft group，單副本故障並不會影響服務的可用性，即使是主節點故障了剩餘的兩個節點也會快速選出主並對外提供讀寫服務。但是考慮到極端情況，假設同時出現兩個副本故障呢？ 這時只剩一個副本無法完成選主服務將完全不可用。根據墨菲定律，可能發生的一定會發生。服務的可用性一方面是穩定提供服務的能力，另一方面是故障時快速恢復的能力。那麼假設出現這種故障的時候我們應該如何快速恢復服務的可用呢。
如果通過創建新的副本進行修復，新副本需要等到完成快照拷貝以後才能加入raft group進行選舉，期間服務還是不可用的。那麼我們可以通過強制將分片降為單副本模式，此時剩餘的單個健康副本可以獨自完成選主，後續再通過變更副本數的方式進行修復。

RaftLog 聚合提交
對於寫入吞吐非常高的場景，可以通過犧牲一定的延時來提升寫入吞吐，通過log聚合來減少請求放大。對於SSD盤，每一次寫入都是4k刷盤，value比較小的時候會造成磁碟帶寬的浪費。我們設置了每5ms或者每聚合4k進行批量提交。該參數可以根據業務場景進行動態配置修改。

非同步刷盤
有些對於數據一致性要求不是非常高的場景，服務故障的時候允許部分數據丟失。對於該場景，可以關閉fsync通過操作系統進行非同步刷盤。但是如果寫入吞吐非常高導致page cache的大小超過了 vm.diry_ratio ,那麼即便不是fsync也會導致io等待，該場景往往會導致io抖動。為了避免內核pdflush大量刷盤造成的io抖動，我們支持對raftlog進行非同步刷盤。

透明多級存儲，和緩存結合，自動冷熱分離，通過將冷數據自動搬遷到kv降低內存使用成本。
新硬體場景接入，使用SPDK 進行IO提速，使用PMEM進行訪問加速。

參考文獻
[1] Bitcask A Log-Structured Hash Table for Fast Key/Value Data
[2] Lethe: A Tunable Delete-Aware LSM Engine

Ⅸ 分布式存儲有哪些

問題一：當前主流分布式文件系統有哪些?各有什麼優缺點 目前幾個主流的分布式文件系統除GPFS外，還有PVFS、Lustre、PanFS、GoogleFS等。
1.PVFS(Parallel Virtual File System)項目是Clemson大學為了運行Linux集群而創建的一個開源項目,目前PVFS還存在以下不足：
1）單一管理節點:只有一個管理節點來管理元數據，當集群系統達到一定的規模之後，管理節點將可能出現過度繁忙的情況，這時管理節點將成為系統瓶頸;
2）對數據的存儲缺乏容錯機制:當某一I/O節點無法工作時，數據將出現不可用的情況;
3）靜態配置:對PVFS的配置只能在啟動前進行，一旦系統運行則不可再更改原先的配置。
2.Lustre文件系統是一個基於對象存儲的分布式文件系統，此項目於1999年在Carnegie Mellon University啟動，Lustre也是一個開源項目。它只有兩個元數據管理節點,同PVFS類似,當系統達到一定的規模之後，管理節點會成為Lustre系統中的瓶頸。
3.PanFS(Panasas File System)是Panasas公司用於管理自己的集群存儲系統的分布式文件系統。
4.GoogleFS(Google File System)是Google公司為了滿足公司內部的數據處理需要而設計的一套分布式文件系統。
5.相對其它的文件系統，GPFS的主要優點有以下三點：
1)使用分布式鎖管理和大數據塊策略支持更大規模的集群系統,文件系統的令牌管理器為塊、inode、屬性和目錄項建立細粒度的鎖，第一個獲得鎖的客戶將負責維護相應共享對象的一致性管理，這減少了元數據伺服器的負擔;
2)擁有多個元數據伺服器,元數據也是分布式,使得元數據的管理不再是系統瓶頸;
3)令牌管理以位元組作為鎖的最小單位,也就是說除非兩個請求訪問的是同一文件的同一位元組數據,對於數據的訪問請求永遠不會沖突.

問題二：分布式存儲是什麼？選擇什麼樣的分布式存儲更好？ 分布式存儲系統，是將數據分散存儲在多 *** 立的設備上。傳統的網路存儲系統採用集中的存儲伺服器存放所有數據，存儲伺服器成為系統性能的瓶頸，也是可靠性和安全性的焦點，不能滿足大規模存儲應用的需要。分布式網路存儲系統採用可擴展的系統結構，利用多台存儲伺服器分擔存儲負荷，利用位置伺服器定位存儲信息，它不但提高了系統的可靠性、可用性和存取效率，還易於擴展。
聯想超融合ThinkCloud AIO超融合雲一體機是聯想針對企業級用戶推出的核心產品。ThinkCloud AIO超融合雲一體機實現了對雲管理平台、計算、網路和存儲系統的無縫集成，構建了雲計算基礎設施即服務的一站式解決方案，為用戶提供了一個高度簡化的一站式基礎設施雲平台。這不僅使得業務部署上線從周縮短到天，而且與企業應用軟體、中間件及資料庫軟體完全解耦，能夠有效提升企業IT基礎設施運維管理的效率和關鍵應用的性能

問題三：什麼是分布式存儲系統？ 就是將數據分散存儲在多 *** 立的設備上

問題四：什麼是分布式數據存儲 定義：
分布式資料庫是指利用高速計算機網路將物理上分散的多個數據存儲單元連接起來組成一個邏輯上統一的資料庫。分布式資料庫的基本思想是將原來集中式資料庫中的數據分散存儲到多個通過網路連接的數據存儲節點上，以獲取更大的存儲容量和更高的並發訪問量。近年來，隨著數據量的高速增長，分布式資料庫技術也得到了快速的發展，傳統的關系型資料庫開始從集中式模型向分布式架構發展，基於關系型的分布式資料庫在保留了傳統資料庫的數據模型和基本特徵下，從集中式存儲走向分布式存儲，從集中式計算走向分布式計算。
特點：
1.高可擴展性：分布式資料庫必須具有高可擴展性，能夠動態地增添存儲節點以實現存儲容量的線性擴展。
2 高並發性：分布式資料庫必須及時響應大規模用戶的讀/寫請求，能對海量數據進行隨機讀/寫。
3. 高可用性：分布式資料庫必須提供容錯機制，能夠實現對數據的冗餘備份，保證數據和服務的高度可靠性。

問題五：分布式文件系統有哪些主要的類別？ 分布式存儲在大數據、雲計算、虛擬化場景都有勇武之地，在大部分場景還至關重要。munity.emc/message/655951 下面簡要介紹*nix平台下分布式文件系統的發展歷史：
1、單機文件系統
用於操作系統和應用程序的本地存儲。
2、網路文件系統（簡稱：NAS）
基於現有乙太網架構，實現不同伺服器之間傳統文件系統數據共享。
3、集群文件系統
在共享存儲基礎上，通過集群鎖，實現不同伺服器能夠共用一個傳統文件系統。

4、分布式文件系統
在傳統文件系統上，通過額外模塊實現數據跨伺服器分布，並且自身集成raid保護功能，可以保證多台伺服器同時訪問、修改同一個文件系統。性能優越，擴展性很好，成本低廉。

問題六：分布式文件系統和分布式資料庫有什麼不同 分布式文件系統（dfs）和分布式資料庫都支持存入，取出和刪除。但是分布式文件系統比較暴力，可以當做key/value的存取。分布式資料庫涉及精煉的數據，傳統的分布式關系型資料庫會定義數據元組的schema，存入取出刪除的粒度較小。
分布式文件系統現在比較出名的有GFS（未開源），HDFS（Hadoop distributed file system）。分布式資料庫現在出名的有Hbase，oceanbase。其中Hbase是基於HDFS，而oceanbase是自己內部實現的分布式文件系統，在此也可以說分布式資料庫以分布式文件系統做基礎存儲。

問題七：分布式存儲有哪些 華為的fusionstorage屬於分布式 您好，很高興能幫助您，首先，FusionDrive其實是一塊1TB或3TB機械硬碟跟一塊128GB三星830固態硬碟的組合。我們都知道，很多超極本同樣採用了混合型硬碟，但是固態硬碟部分的容量大都只有8GB到32GB之間，這個區間無法作為系統盤來使用，只能作

問題八：linux下常用的分布式文件系統有哪些 這他媽不是騰訊今年的筆試題么
NFS（tldp/HOWTO/NFS-HOWTO/index）
網路文件系統是FreeBSD支持的文件系統中的一種，也被稱為NFS。
NFS允許一個系統在網路上與它人共享目錄和文件。通過使用NFS， 用戶和程序可以象訪問本地文件一樣訪問遠端系統上的文件。它的好處是：
1、本地工作站使用更少的磁碟空間，因為通常的數據可以存放在一台機器上而且可以通過網路訪問到。
2、用戶不必在每個網路上機器裡面都有一個home目錄。home目錄可以被放在NFS伺服器上並且在網路上處處可用。
3、諸如軟碟機、CDROM、和ZIP之類的存儲設備可以在網路上面被別的機器使用。可以減少整個網路上的可移動介質設備的數量。
開發語言c/c++,可跨平台運行。
OpenAFS（openafs）
OpenAFS是一套開放源代碼的分布式文件系統，允許系統之間通過區域網和廣域網來分享檔案和資源。OpenAFS是圍繞一組叫做cell的文件伺服器組織的，每個伺服器的標識通常是隱藏在文件系統中，從AFS客戶機登陸的用戶將分辨不出他們在那個伺服器上運行，因為從用戶的角度上看，他們想在有識別的Unix文件系統語義的單個系統上運行。
文件系統內容通常都是跨cell復制，一便一個硬碟的失效不會損害OpenAFS客戶機上的運行。OpenAFS需要高達1GB的大容量客戶機緩存，以允許訪問經常使用的文件。它是一個十分安全的基於kerbero的系統，它使用訪問控制列表(ACL）以便可以進行細粒度的訪問，這不是基於通常的Linux和Unix安全模型。開發協議IBM Public，運行在linux下。
MooseFs（derf.homelinux）
Moose File System是一個具備容錯功能的網路分布式文件統，它將數據分布在網路中的不同伺服器上，MooseFs通過FUSE使之看起來就 是一個Unix的文件系統。但有一點問題，它還是不能解決單點故障的問題。開發語言perl,可跨平台操作。
pNFS（pnfs）
網路文件系統(Network FileSystem,NFS)是大多數區域網(LAN）的重要的組成部分。但NFS不適用於高性能計算中苛刻的輸入書櫥密集型程序，至少以前是這樣。NFS標準的罪行修改納入了Parallel NFS(pNFS），它是文件共享的並行實現，將傳輸速率提高了幾個數量級。
開發語言c/c++,運行在linu下。
googleFs
據說是一個比較不錯的一個可擴展分布式文件系統，用於大型的，分布式的，對大量數據進行訪問的應用。它運行於廉價的普通硬體上，但可以提供容錯功能，它可以給大量的用戶提供性能較高的服務。google自己開發的。

問題九：分布式存儲都有哪些，並闡述其基本實現原理 神州雲科 DCN NCS DFS2000（簡稱DFS2000）系列是面向大數據的存儲系統，採用分布式架構，真正的分布式、全對稱群集體系結構，將模塊化存儲節點與數據和存儲管理軟體相結合，跨節點的客戶端連接負載均衡，自動平衡容量和性能，優化集群資源，3-144節點無縫擴展，容量、性能歲節點增加而線性增長，在 60 秒鍾內添加一個節點以擴展性能和容量。

問題十：linux 分布式系統都有哪些？ 常見的分布式文件系統有，GFS、HDFS、Lustre 、Ceph 、GridFS 、mogileFS、TFS、FastDFS等。各自適用於不同的領域。它們都不是系統級的分布式文件系統，而是應用級的分布式文件存儲服務。
GFS（Google File System）
--------------------------------------
Google公司為了滿足本公司需求而開發的基於Linux的專有分布式文件系統。。盡管Google公布了該系統的一些技術細節，但Google並沒有將該系統的軟體部分作為開源軟體發布。
下面分布式文件系統都是類 GFS的產品。
HDFS
--------------------------------------
Hadoop 實現了一個分布式文件系統（Hadoop Distributed File System），簡稱HDFS。 Hadoop是Apache Lucene創始人Doug Cutting開發的使用廣泛的文本搜索庫。它起源於Apache Nutch，後者是一個開源的網路搜索引擎，本身也是Luene項目的一部分。Aapche Hadoop架構是MapRece演算法的一種開源應用，是Google開創其帝國的重要基石。
Ceph
---------------------------------------
是加州大學聖克魯茲分校的Sage weil攻讀博士時開發的分布式文件系統。並使用Ceph完成了他的論文。
說 ceph 性能最高，C++編寫的代碼，支持Fuse，並且沒有單點故障依賴， 於是下載安裝， 由於 ceph 使用 btrfs 文件系統， 而btrfs 文件系統需要 Linux 2.6.34 以上的內核才支持。
可是ceph太不成熟了，它基於的btrfs本身就不成熟，它的官方網站上也明確指出不要把ceph用在生產環境中。
Lustre
---------------------------------------
Lustre是一個大規模的、安全可靠的，具備高可用性的集群文件系統，它是由SUN公司開發和維護的。
該項目主要的目的就是開發下一代的集群文件系統，可以支持超過10000個節點，數以PB的數據量存儲系統。
目前Lustre已經運用在一些領域，例如HP SFS產品等。

Ⅹ CentOS 7部署 Ceph分布式存儲架構

隨著OpenStack日漸成為開源雲計算的標准軟體棧，Ceph也已經成為OpenStack的首選後端存儲。Ceph是一種為優秀的性能、可靠性和可擴展性而設計的統一的、分布式文件系統。

Ceph是一個開源的分布式文件系統。因為它還支持塊存儲、對象存儲，所以很自然的被用做雲計算框架openstack或cloudstack整個存儲後端。當然也可以單獨作為存儲，例如部署一套集群作為對象存儲、SAN存儲、NAS存儲等。

前三台伺服器增加一塊硬碟/dev/sdb實驗, 創建目錄並掛載到/var/local/osd{1,2,3};

規范系統主機名添加hosts文件實現集群主機名與主機名之間相互能夠解析（host 文件添加主機名不要使用fqdn方式）可用 hostnamectl set-hostname [name] 設置分別打開各節點的 /etc/hosts 文件，加入這四個節點ip與名稱的對應關系:

在管理節點使用ssh-keygen 生成ssh keys 發布到各節點

第一步：增加 yum配置文件(各個節點都需要增加yum源) vim /etc/yum.repos.d/ceph.repo

或阿里的ceph源

復制配置文件到其它節點和客戶端

在ceph1更新軟體源並安裝ceph-deploy 管理工具

配置文件的默認副本數從3改成2，這樣只有兩個osd也能達到 active+clean 狀態，添加行 osd_pool_default_size = 2

(如果網路源安裝失敗，手工安裝epel-release 然後安裝yum –yinstall cep-release再yum –y install ceph ceph-radosgw)
錯誤參考： https://blog.csdn.net/yenai2008/article/details/72457463

添加osd節點 (所有osd節點執行)
我們實驗准備時已經創建目錄/var/local/osd{id}

（用ceph-deploy把配置文件和admin密鑰拷貝到所有節點，這樣每次執行Ceph命令行時就無需指定monitor地址和ceph.client.admin.keyring了）

以上基本上完成了ceph存儲集群的搭建。

其中： <pg_num> = 128 ,
關於創建存儲池
確定 pg_num 取值是強制性的，因為不能自動計算。下面是幾個常用的值：

隨著 OSD 數量的增加，正確的 pg_num 取值變得更加重要，因為它顯著地影響著集群的行為、以及出錯時的數據持久性（即災難性事件導致數據丟失的概率）。

創建好存儲池後，你就可以用 fs new 命令創建文件系統了
ceph fs new <fs_name> cephfs_metadata cephfs_data
其中： <fs_name> = cephfs 可自定義

在這里想起沒在/etc/fstab配置ceph1、ceph2、ceph3的sdb自動掛載。

ceph在開源社區還是比較熱門的，但是更多的是應用於雲計算的後端存儲。所以大多數在生產環境中使用ceph的公司都會有專門的團隊對ceph進行二次開發，ceph的運維難度也比較大。但是經過合理的優化之後，ceph的性能和穩定性都是值得期待的。

清理機器上的ceph相關配置

可以參考內容： http://blog.51cto.com/12270625/1887648