luanshaotong / sealfs-cpp-old

backup

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

SEALFS

丝滑,高性能的分布式文件存储

为什么要为云原生构建新的分布式文件存储

使用本地存储

  • 单点故障
    云原生应用使用本地持久化存储带来的最大问题是单点故障,由于数据位于某个特定的节点,节点宕机会导致数据不可用,受绑定的应用无法重启,也难以迁移到其他节点。此外单节点磁盘故障甚至会出现数据丢失的问题。
    目前对于一些数据可靠性要求高的应用,都在应用层实现了分布式架构,本质上是将复杂性交给了应用,对于复杂的应用而言,成本过高。
  • 存储规划与扩容
    应用本地存储意味着需要对每个节点进行容量规划,在节点故障时还需要对原本的分布式架构进行额外的迁移配置,带来了巨大的工作量和出错概率。
    另一方面,原本的容量不足时,进行节点扩容也是本地存储无法解决的难题。
  • 性能效率低下 由于磁盘设备IO,本地存储的性能是存在瓶颈的,多应用共享磁盘时尤其明显。

使用现有分布式存储

  • 性能 尽管理论上分布式存储的数据性能随着节点增多可以不受限制,但实际上还是受到几方面的影响。一是集群一致性带来的瓶颈,使用raft等协议的分布式方案存在的问题;二是数据调用流程延长带来的内存拷贝成本,采用fuse的众多文件系统带来的问题;三是元数据请求的瓶颈,典型的是GFS,大规模集群下目录遍历的成本非常高。

  • 配置 配置复杂,特别的节点扩容,许多限制要求十分苛刻。典型为GFS扩容极其复杂。cephfs的稳定性较差。

  • 价格 高性能的商业分布式存储价格昂贵,开源产品又大多无法相提并论。

适用场景

性能极致方案×可靠数据体验

  • 高性能的网络数据访问
    • 无分布式元数据的方案
    • intercept
    • 完整posix请求(link、rename、delete的高效实现)
  • 丝滑
    • 数据可靠性
    • 数据服务高可用性
    • 存储节点可扩展

Install

  mkdir build
  cd build
  cmake ..
  make

Quick start

start deamon

  cd build
  src/deamon/fuse_deamon

mount fs

  cd build
  src/client/fuse_client your_mount_dir

test

  echo "test" >> your_mount_dir/test.log
  ls -l your_mount_dir

About

backup


Languages

Language:C 74.7%Language:C++ 24.1%Language:CMake 1.1%