存储世界最近发生了很大变化。十年前，Fibre Channel SAN 文件管理器是企业存储的标准。而在目前的环境中，受到基础架构即服务云的影响，数据存储需要更加灵活。
近日，有关存储系统选型的问题在微信群里讨论的火热，CSDN在这里稍微将各位专家的问答总结了一下，分享给大家。 文章内容来源大数据基础设施微信群，参与讨论的专家有中国科学院软件研究所工程师，C3核心成员李明宇，国防科学技术大学教授，CCF大数据专家委员会委员李东升，云人科技联合创始人兼CEO吴朱华，Memblaze技术顾问刘爱贵等等。 以下是问答实录： Q：有一个场景：每天有近百GB数据增加，数据内容有WORD文档和图像等多种类型。用什么存储或文件系统比较合适？ A: HDFS、HBase、Hive不太适合存
综上所述，Ceph和GlusterFS在架构、可用性、性能、可扩展性、数据一致性以及管理和维护等方面都有不同的特点。
glusterfs、ceph、minio在开源界，属于比较流行应用较广的三个分布式存储系统。现在重点介绍下，这三个分布式系统的架构以及和raid的类比，让大家把存储明明白白的搞透彻。
https://blog.fleeto.us/post/kubernetes-storage-performance-comparison/
如果你正在运行 Kubernetes，你可能正在使用，或者准备使用动态供给的块存储卷，而首当其冲的问题就是为集群选择合适的存储技术。这个事情并不能用一个简单的测试来做出简单的回答，告诉你目前市面上最好的技术是什么。存储技术的选择过程中，集群上运行的负载类型是一个重要的输入。对于裸金属集群来说，需要根据实际用例进行选择，并集成到自己的硬件之中。公有云中的托管 K8s，例如 AKS、EKS 或者 GKE，都具有开箱可用的块存储能力，然而这也不见得就是最好的选择。有很多因素需要考虑，比如说公有云的 StorageClass 的故障转移时间太长。例如在 一个针对 AWS EBS 的故障测试中，加载了卷的 Pod 用了超过五分钟才成功的在另一个节点上启动。Portworx 或者 OpenEBS 这样的云原生存储产品，正在尝试解决这类问题。
Proxmox VE是一个完整的企业虚拟化开源平台。借助内置的Web界面，您可以轻松管理VM和容器，软件定义的存储和网络，高可用性集群以及单个解决方案上的多个开箱即用工具。
容器存储的选择 时至今日，企业客户运行容器的，编排工具大多数选择K8S。 因此，我们先到社区里看看，目前K8S支持的持久存储，其实也就是PV支持的存储类型。 https://kubernetes.i
我们的YRCloudFile是一款面向云时代的分布式文件系统，它的主要特点是支持海量小文件的高性能数据访问，对Kubernetes平台的无缝支持，混合云场景下的数据支撑。我们在开发YRCloudFile时，也会去了解业界主流的分布式文件系统，学习其优点，避免其缺点。本文讨论几个我们曾调查过的主流的分布式文件系统，它们都是开源系统，因为这样能收集到丰富的资料，能看到代码，使得了解及讨论更为清晰。
最近几年，我的工作内容始终围绕着客户 Kubernetes 集群的建设。如何为客户的 Kubernetes 集群选择一款稳定可靠、性能表现优异的存储解决方案，这样的问题一直困扰着我。
块存储一般体现形式是卷或者硬盘（比如windows的c盘），数据是按字节来访问的，对于块存储而言，对里面存的数据内容和格式是完全一无所知的。好比上面图中，数据就像玉米粒一样堆放在块存储里，块存储只关心玉米粒进来和出去，不关心玉米粒之间的关系和用途。
总的来说，Ceph作为一个开源、分布式和可扩展的存储平台，在云存储、大规模数据存储和备份、虚拟化环境及内容分发网络等领域有着广泛的应用。与竞争对手的差异化点在于其全球性的社区支持和强大的可扩展性。
ceph作为新一代的PB级高可靠性分布存储系统已经流行很长时间了，在研究了glusterfs之后，一直想找个机会研究一下它，这周终于抽出来时间了。 概念 相对于其它分布式存储系统，它开创性地用统一的系
随着项项目的增多，对测试环境的需求越来越大，今天研发要几台测试环境，明天测试也要几台测试环境，连产品都要测试环境了，咱们运维也得有自己的测试环境，之前搭建的exsi已经满足不了需求了。
GPL:不允许修改后和衍生的代码做为闭源的商业软件发布和销售，修改后该软件产品必须也采用GPL协议；
因此，业界也出现了一系列其他分布式存储系统，最常见的是HDFS、GlusterFS和Openstack Swift。
当谈到云原生开源项目时，Kubernetes 受到了很多关注。这个容器编排平台彻底改变了应用程序的开发、部署和扩展。虽然快速向上和向下扩展服务的能力是 Kubernetes 的最大卖点之一，但在这种动态环境中管理持续存储可能非常具有挑战性。在本文中，我将向您介绍排名前五的开源云原生存储供应商。
干货巨献：Openshift3.9的网络管理大全.加长篇---Openshift3.9学习系列第二篇
上一篇文章给大家简单介绍了GlusterFs(查看),今天再给大家来一个目前最流行的分布式存储系统Ceph的介绍，Ceph是开一个开源的项目，它的创始人是Sage Weil，作为当时的博士论文一部分，目前Ceph已经得到很多厂商的支持，具有很好的生态系统，它同时具有自己的开源社区，活跃度极高。闲话不多说，以下内容是本人自己学习整理，如有不当之处请指正。
今天跟大家分享的是平安科技使用Ceph构建高效的分布式存储平台，之前的文章对Ceph进行了简单介绍，包括Intel公司对Ceph的支持介绍，下面我们看一下如何来使用Ceph,真正做一个云存储平台。
Apache HDFS：Hadoop分布式文件系统（HDFS）提供了一种在多个机器上存储大文件的方法。 Hadoop和HDFS衍生自Google文件系统（GFS）这篇论文。在Hadoop 2.0.0之前，NameNode是HDFS集群中的单点故障（SPOF）。 使用Zookeeper，HDFS高可用性功能通过在具有热备份的主动/被动配置中提供在同一群集中运行两个冗余NameNode的选项来解决此问题。
glusterfs集群中每个进程服务都是由一组xlator来做对应的功能，每个请求都是从每个进程的中最上面一个xlator顺序执行到最后一个xlator,来实现本进程的工作,上图中的每个进程仅仅罗列了部分的xlator.glusterfs实现中客户端实现最重，体现在比较核心的三个模块，cluster/distribute、cluster/ec、cluster/replicate这三块，分别在客户端实现了哈希卷、EC卷、多副本卷的逻辑。每个客户端在使用mount时候会和glusterd通信获取到当前集群的拓扑信息，客户端通过弹性哈希算法来决定数据存储的位置，后续直接和对应的glusterfsd通信来完成IO
软件定义存储(SDS)是一个软件层，在物理存储设备和数据请求之间提供个抽象层，实现存储虚拟化功能，将底层存储设备和服务器汇集到虚拟存储空间中。这些虚拟空间通过各种冗余方式，提供恢复能力和容错能力。软件定义存储解决方案可以按照业务或基础设施的发展速度进行扩展,使用通用硬件，基于分布式环境构建存储。
同方有云日前已正式将Ceph系统独立为产品线UDS（Unitedstack Distributed Storage），开始为市场提供分布式存储服务——就像公有云巨头们所做的那样。
从用户角度看，存储就是一块盘或者一个目录，用户不关心盘或者目录如何实现，用户要求非常“简单”，就是稳定，性能好。为了能够提供稳定可靠的存储产品，各个厂家推出了各种各样的存储技术和概念。为了能够让大家有一个整体认识，本文先介绍存储中的这些概念。
作为一名专注于大数据存储与处理技术的博主，我深知Hadoop Distributed File System（HDFS）作为一款广泛应用的分布式文件系统，在大数据生态系统中的基石地位。本篇博客将结合我个人的面试经历，深入剖析HDFS的底层原理、关键特性及其故障排查方法，分享面试必备知识点，并通过示例进一步加深理解，助您在求职过程中自信应对与HDFS相关的技术考察。
**分布式存储：**通过网络使用企业中的每台机器上的磁盘空间，并将这些分散的存储资源构成一个虚拟的存储设备，数据分散的存储在企业的各个角落。
GlusterFSFS恢复数据都是基于副本卷来说的，GlusterFSFS复制卷是采用镜像的方式做的，并且是同步事务性操作。简单来说就是，某一个客户要写文件时，先把这个文件锁住，然后同时写两个或多个副本，写完后解锁，这个操作才算结束。那么在写某一个副本时发生故障没有写成功，或者运行过程中某一个节点断电了，造成数据丢失了，等等，就能通过另一个副本来恢复。 现在这里说一个疑问： 就是GlusterFS写副本时同步写的，就是客户端同时写两份数据，这样就会产生两倍的流量，测2副本的分布式复制卷性能时，能明确看到性能
最近因工作需要研究了一下分布式文件系统，主要用来解决文件存储的问题，今天给大家简单介绍一下Glusterfs(后面还将介绍另外一个开源软件CEPH)它是一个基于文件的开源的具有高性能的一款分布式存储软件，话不多说，直奔主题。如有说的不对的地方，欢迎指正。
Kubernetes v1.11 中，持久卷扩容能力升级为 Beta 阶段。这个功能让用户可以轻松的通过编辑 PVC 对象的方式修改现有卷的容量。没有这一功能之前，要对卷容量进行修改，需要要和存储后端进行手工交互，或者对 PV 以及 PVC 进行删除重建操作。持久卷不支持缩容操作。
最近看到ReadHat在搞Ceph的培训，而且是收费的，真的是吓了一跳。难道真要搞这么复杂这么强大的存储方案么？有了MinIO，我知道我永远和Ceph无缘了。
工作中经常发现公司机房里有些服务器上的硬盘空间不足，但还存在一些服务器上有很多空余空间，所以一直在想如何高效利用这些硬盘空间的问题。最初的解决方案是NFS，即在有空余空间的服务器上开启NFS服务器，然后需要硬盘空间的服务器通过NFS挂载过去。用过一段时间后发现存在以下问题： 有空余空间的服务器数量还很多，得作好记录哪个服务器由于什么用途export了哪些目录出去了，export的目录被谁挂载了。 NFS文件共享方式不存在数据冗余存储，主要依靠底层的存储技术如RAID来保证数据的安全。 后来在深度实践KVM这
分布式文件系统 分布式文件系统（Distributed File System）是指文件系统管理的物理存储资源并不直接与本地节点相连，而是分布于计算网络中的一个或者多个节点的计算机上。目前意义上的分布式文件系统大多都是由多个节点计算机构成，结构上是典型的客户机/服务器模式。流行的模式是当客户机需要存储数据时，服务器指引其将数据分散的存储到多个存储节点上，以提供更快的速度，更大的容量及更好的冗余特性。 目前流行的分布式文件系统有许多，如MooseFS、FastDFS、GlusterFS、Ceph、Mogile
支持FUSE，相对比较轻量级，对master服务器有单点依赖，用perl编写，性能相对较差，国内用的人比较多，易用，稳定，对小文件很高效。 + 支持文件元信息 + mfsmount 很好用 + 编译依赖少，文档全，默认配置很好 + mfshdd.cfg 加 * 的条目会被转移到其它 chunk server，以便此 chunk server 安全退出 + 不要求 chunk server 使用的文件系统格式以及容量一致 + 开发很活跃 + 可以以非 root 用户身份运行 + 可以在线扩容 + 支持回收站 + 支持快照 - master server 存在单点故障 - master server 很耗内存 测试性能还不错。吞吐量在15MB/秒以上
rdma The RDMA I/O engine supports both RDMA memory semantics (RDMA_WRITE/RDMA_READ) and channel semantics (Send/Recv) for the InfiniBand, RoCE and iWARP protocols. falloc IO engine that does regular fallocate to simulate data transfer as fio ioengine. DDIR_READ does fallocate(,mode = keep_size,) DDIR_WRITE does fallocate(,mode = 0) DDIR_TRIM does fallocate(,mode = punch_hole) e4defrag IO engine that does regular EXT4_IOC_MOVE_EXT ioctls to simulate defragment activity in request to DDIR_WRITE event rbd IO engine supporting direct access to Ceph Rados Block Devices (RBD) via librbd without the need to use the kernel rbd driver. This ioengine defines engine specific options. gfapi Using Glusterfs libgfapi sync interface to direct access to Glusterfs volumes without options. gfapi_async Using Glusterfs libgfapi async interface to direct access to Glusterfs volumes without having to go through FUSE. This ioengine defines engine specific options. libhdfs Read and write through Hadoop (HDFS). The 'filename' option is used to specify host, port of the hdfs name-node to connect. This engine interprets offsets a little differently. In HDFS, files once created cannot be modified. So random writes are not possible. To imitate this, libhdfs engine expects bunch of small files to be created over HDFS, and engine will randomly pick a file out of those files based on the offset generated by fio backend. (see the example job file to create such files, use rw=write option). Please note, you might want to set necessary environment variables to work with hdfs/libhdfs properly. mtd Read, write and erase an MTD character device (e.g., /dev/mtd0). Discards are treated as erases. Depending on the underlying device type, the I/O may have to go in a certain pattern, e.g., on NAND, writing sequentially to erase blocks and discarding before overwriting. The w
随着云原生概念在业界的推广，传统应用部署的方式被容器化部署所取代。基于云原生的容器化部署和运维，给开发和运维人员带来DevOps快速部署和自动化运维等诸多便利的同时，对于基础架构服务也提出了更高的要求，其中存算分离就是保障云原生应用故障快速转移、算力负载均衡的基石。因此云原生存储的概念也在云原生的基础上应运而生，接下来本文将会逐步梳理云原生存储的概念、工具的选型，最后会选择一个代表性的云原生存储工具来演示如何使用。
**MooseFS(MFS)** **Ceph** **GlusterFS** **Lustre** **Metadata server** 单个MDS。存在单点故障和瓶颈。 多个MDS，不存在单点故障和瓶颈。MDS可以扩展，不存在瓶颈。 无，不存在单点故障。靠运行在各个节点上的动态算法来代替MDS,不需同步元数据,无硬盘I/O瓶颈。 双MDS(互相备份)。MDS不可以扩展，存在瓶颈。 **FUSE** 支持 支持 支持 支持 **访问接口** POSIX POSIX POSIX POSIX/MPI **
最近有朋友问到我基于K8s & Spring Cloud的PaaS云平台的相关问题，正好之前在卓望数码 时专门做这个的。考虑到技术选型本身并不涉及业务，也不涉及商业机密，索性整理一下，分享出来。
目前流行的软件定义存储相关的开源项目主要有GlusterFS、Swift、Lustre和Ceph。这四个项目各有各的特点：GlusterFS提供文件存储，Swift提供对象存储，Lustre主要用在高性能计算，Ceph则基于一套系统提供块、对象及文件功能。
软件正在吞噬整个世界，而开源软件则正吞并整个软件行业。这一点同样适用于看似传统的存储领域，也正影响着存储的使用方和存储厂商。有些存储厂商使用开源代码并对其进行增强，从而提供开源存储所无法提供的企业级特性；而有些厂商基于他们原有的商业软件甚至发起开源项目，以促进开发，例如DellEMC发起的CoreHD（开源软件）是基于该公司私有的ViPR控制器软件的代码。
Facebook's Haystack design paper. https://www.usenix.org/legacy/event/osdi10/tech/full_papers/Beaver.pdf
docker本身设计之初是用来执行一个app，抑或是一个应用程序，在其运行结束后，将销毁一切数据，但是这明显不是我们想要的，docker也 想到了这个，因此其本身提供一个-v的参数，用来将外部的存储挂载到container中，用来保存我们的持久化的数据。kubernetes最为其集群 管理工具，自然也想到了这些，而且还提供了更强大的功能，基于其插件化的设计，kubernetes针对volume的driver支持是十分丰富的。本 文就简单描述几个driver的设计思想和使用方法：
前言 作者是国内研究超融合相当早的专家，有非常强的理论基础和实战经验，以下是超融合分析系列前面几篇，已经阅读过的同学可以跳过。 超融合分析系列： 超融合概述 超融合产品分析系列（1）：nutanix方案 超融合方案分析系列（2）：VSAN的超融合方案分析 非常深入的超融合分析系列，希望大家会喜欢，另外文章最后附有作者的微信，有兴趣的同学可以加作者做更深入的交流。下面是本系列第4篇正文： 整体方案 深信服的超融合一体机以及超融合方案目前在各个地方都推的比较猛，从官网看，他们的客户也有不少了。今天我们一起
文件系统是最常用的数据存储形式，所以，常用Linux操作系统的用户必然知道ext4、xfs等单机文件系统，用Windows操作系统的用户也都知道NTFS单机文件系统。各种业务场景下，不同的数据都存储于文件系统之上，大量业务逻辑就是基于文件系统而设计和开发的。提供最常用的存储访问方式，这是我们做文件系统的出发点之一。
4月23日，以“软件定义存储未来”为题的首届软件定义存储峰会在深圳正式召开，会上，中国开源云联盟秘书长、Ceph中国社区联合创始人、腾讯云TVP耿航作为大会首位演讲嘉宾发表了《中国开源软件的发展趋势》主题演讲。
什么是cinder？ cinder是一个openstack的组件，用来给云主机提供硬盘的一个服务 还可以对卷进行管理，允许对卷、卷的类型、卷的快照、卷备份进行处理。 它的容量都是通过cinder中实现的驱动对接来自于后端的储存,比如iscsi,glusterfs,nfs,ceph Cinder中的模块 Cinder API：对客户端的操作请求进行解析，并寻找相应的处理方法。包括了卷、快照的增删改查，卷的挂载卸载等。 Cinder Scheduler：根设定的算法，对新建卷指定一个合适的后端储存 Cinder
今天分享的内容分为两部分，前面一部分为携程网Ceph的具体实践讲解，后面一部分为携程工程师在Ceph中国社区针对Ceph应用的一系列问答
如今，互联网企业依靠技术优势，深刻影响和改变着人们的生活和工作，其中，开源技术孕育了互联网企业发展。在云计算、大数据、AI、IoT的背后，是OpenStack、容器、Hadoop等开源技术的支撑，在开源技术支撑下，互联网企业如鱼得水。
Red Hat Ceph是一个分布式的数据对象存储，系统设计旨在性能、可靠性和可扩展性上能够提供优秀的存储服务。分布式对象存储是存储的未来，因为它们适应非结构化数据，并且客户端可以同时使用当前及传统的对象接口进行数据存取。例如：
分布式存储是近几年的热门话题之一，它和传统SAN/NAS存储的区别是，分布式存储使用标准硬件（比如x86服务器和10GbE网络），而传统SAN/NAS存储使用的是专有硬件。使用标准硬件的好处是通用，不会受限于产商，而且成本上也更便宜，还可以做到按需扩容。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
实时音视频
对象存储
即时通信 IM
