更換 GFS 集群的建議？
我有幾個使用光纖通道 SAN 中的共享磁碟的 CentOS GFS 集群（GFS 在全域文件系統中）。它們現在已經成熟，是時候開始計劃更換它們了。
它們是奇數個節點（3 個或 5 個），帶有故障節點的柵欄，設置有 APC (PDU) 電源開關。這些節點都是活動的，並且在同一個共享文件系統上同時讀寫。文件系統很小，目前不到 TB，並且永遠不會增長到超過商品硬碟驅動器的大小。
我有兩個獨占的 IP 地址資源，它們在節點關閉時重新定位。（1 在 3 節點集群上）。一切都很好，但是當有很多活動時性能不是很好。
那麼，在我的下一代集群中我可以做些什麼不同的事情呢？
**我需要的是服務正常執行時間和數據可用性。**也可能具有可擴展性，但可能不是。我預計負載不會增長太多。我還需要能夠像正常文件系統上的正常文件一樣讀寫文件。不需要配額或 ACL。只是正常的 unix 權限、所有權、mtime、以字節為單位的大小，以及以
ln一種在除 1 個節點之外的所有節點上都失敗的方式製作鎖定文件的能力，如果他們同時嘗試的話。我不想增加物理伺服器的數量（這意味著我想使用實際伺服器本身的儲存）。
這不是強制性的，但我認為如果我不依賴共享磁碟會很好。在過去的 5 年中，我經歷了兩次企業級 SAN 儲存不可用的事件，因此無論多麼不可能，我都希望領先一步。
由於正常執行時間非常重要，1 個執行核心的物理伺服器太少了。虛擬機依賴於我們環境中的 SAN。
到目前為止我的想法：
- 所有節點都可以是普通的 NFSv3 客戶端（會
ln按我預期的方式工作嗎？那麼 NFS 伺服器會是什麼？）- Ceph和 CephFS（FS 什麼時候可以投入生產？）
- XtreemFS（與 Ceph 相比，為什麼寫得這麼少？）
如您所見，我對分佈式儲存感興趣，但需要經驗豐富的專家的建議。特別歡迎有關 Ceph 或 XtreemFS 的建議或建議。這不是具有瘋狂頻寬需求的 HPC。只需要我的舊解決方案的可用性和可靠性，並希望具有靈活性，理想情況下是比目前“更好”的配置。
編輯（見 Nils 評論）我考慮更換這個解決方案的主要原因是我想看看是否有可能消除 SAN 儲存櫃所存在的單點故障。還是應該改用 LVM 鏡像將數據保存在同一 SAN 結構中的兩個不同儲存系統上？我認為兩個 FC-HBA 和雙開關應該足夠了。
Ceph 和 GlusterFS 是集群 FS 技術目前的發展方向。由於我對 GlusterFS 不熟悉，所以我將談談 Ceph 的特性。
Ceph 水平擴展；添加的低端節點越多，性能就越好。與 GlusterFS 不同，這是 Ceph 的主要優勢，因為它將數據分片。
然而，Ceph 正在積極開發中（除了 Ceph FS 外，它已準備好生產）並且需要現代核心（在我寫這篇文章時，即使 CentOS 6.5 預設核心也無法利用 RBD/CephFS 功能）。為了解決這個問題，我安裝了 ELRepo
kernel-lt。為您分解：
- Cephs RBD 是集群 SAN 的替代品；您可以創建集群中的“虛擬”設備，並且可以安裝在伺服器上。注意：一次只能安裝一台伺服器的 RBD 映像（您不希望多個作業系統安裝一個 SATA 驅動器嗎？）。然後，您將像平常一樣格式化 RBD 磁碟，
mount然後讓 NFS/CIFS 使其可用。如果提供 NFS/CIFS 的伺服器出現故障，則不會失去任何數據。- Ceph FS 是集群 NAS 的替代品（儘管尚未準備好生產）；它提供了在伺服器（例如 Web 伺服器）之間共享的集群 FS 所需的文件鎖定功能。
RBD 在核心空間中執行；所以沒有保險絲性能命中。Ceph FS 也可以在核心空間中執行，但可以與 FUSE 一起執行。
Ceph 也很容易部署：
pip install ceph-deploy在管理節點（您的桌面/工作站）上。- 添加 Inktank RPM 儲存庫並
ceph-deploy install node1 node2 ... nodeN在所有節點上安裝 ceph。