45 个分布式存储典型问题解读，看完成半个高手
Posted twt企业IT社区
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了45 个分布式存储典型问题解读，看完成半个高手相关的知识，希望对你有一定的参考价值。
涉及分布式存储选型、架构、运维等。来自社区交流分享，汇总整理供大家参考。
1、分布式存储当前主要的应用场景有哪些？
@Garyy 某保险 系统工程师：
简单来说，就是存储设备分布在不同的地理位置，数据就近存储， 将数据分散在多个存储节点上，各个节点通过网络相连，对这些节点的资源进行统一的管理，从而大大缓解带宽压力，同时也解决了传统的本地文件系统在文件大小、文件数量等方面的限制。对于分布式存储，应用场景就很多了，如果你有以下需求：数据量大、高吞吐量、高性能、高扩展，那就推荐分布式存储。主要的应用场景：
1）块存储
类似传统存储IP San形式提供iSCSI接口，作为 虚拟化后端存储，
2）对象存储
视频，音频，图片类的存储，归档存储等，例如保险行业的“双录”系统，电子保单系统
3）文件存储
作为NFS，GPFS之类集群文件系统的替代品
@李静 XSKY 软件架构设计师：
1、分布式块存储：
（1）云平台，私有云建设，分布式存储非常适合云平台的场景，传统集中式存储，一般都是标准iscsi协议挂载卷到openstack端，每个lun都需要单独挂载。配置MPIO等。而分布式存储是通过rbd协议挂载存储池给OpenStack，OpenStack端直接在存储里划分和创建卷，调用快照等高级功能，分布式存储和OpenStack是天生适配，更加合适OpenStack的私有云的发展。
（2）容器场景：2018年12月发布Kubernetes 1.13版本，用于容器编排引擎的标准存储接口container storage interface（CSI）已普遍可用。在这些产品中，容器本地数据服务的需求对于支持微服务结构变得非常重要，这些需求包括硬件不可知性、API驱动、基于分布式架构，能够支持边缘、核心或公共云部署等。超过 70% 的容器应用需要有状态数据持久化保存，SDS可以解决：需要敏捷的数据迁移、从多个应用容器同时访问数据的需求。所以容器场景的弹性灵活的需求也是非常适合分布式存储。
2、分布式文件存储：分布式文件适合大容量文件存储场景，横向扩展灵活，性能优于双控存储，例如非线编，共享NAS，高性能计算等等都非常适合，文件存储也是现阶段三种存储中市场使用最高的，但有些也在慢慢转对象存储，对象存储接口协议在逐步开发中，会有一个过渡阶段。
3、分布式对象存储：海量小文件需求，检索需求，大数据方向，金融的影像平台，有互联网传输需求，和公有云整合，企业高校的网盘，监控等等非结构化场景都适合，包括一些医疗的PACS也在逐步过渡到对象存储，未来最有爆发潜力的存储。
文件和对象都针对的非结构化场景，文件往对象转是大势所趋，在于对象S3接口的逐步推广，对象存储支持文件和对象互操作（文件协议写入，对象方式读出，反之亦然）也是顺应市场需求的产物。
@qsg0720 深圳杉岩 CTO：
金融行业：影像系统、档案系统、容器、私有云、备份
医疗行业：超融合、PACS影像存储
安防行业：监控集中存储、智能安防
教育行业：私有云、校园网盘
@潇洒D鱼 XSKY 星辰天合 业务咨询顾问：
除了 OLTP 单一业务极限IOPS需求，和极低时延（微秒），大部分业务场景都可以通过SDS 满足，金融领域的开发测试，容器云，电子影像，双录，广电领域的媒资，CDN，等等，都是当前SDS能够应对的场景，简单来讲，SDS本身是分布式架构，通过 Scale Up 和 Scale Out 对标准化服务器和网络的排列组合，可以获得业务希望获得的存储能力。
2、和传统存储相比，分布式存储在哪些应用场景比较有优势？
@宁泽阳 中信银行信用卡中心 系统工程师：
分布式存储适用于虚拟化、云平台对接场景，海量非结构化数据保存场景（如图片、影音等）。
@priest 系统架构师：
数据量大、高吞吐量、高性能、高扩展 等场景。
@荣重实 XSKY 架构师：
分布式在整体架构设计上，可按需配置，灵活扩展；
分布式存储性能上限高，传统存储传输接口数量受限制有天花板；
分布式存储容量上限高，横向扩展能力强；
分布式存储硬件节点做替换对应用影响小；
综上所述，在私有云部署，海量非结构化数据，高性能计算，流媒体和视频监控场景有比较大的优势。
3、传统存储架构的局限性和分布式存储的优点？
@baimmi 某金融集团 架构师：
传统SAN存储设备一般采用双控制器架构，两者互为备份，配置两台交换机与前端的服务器进行连接，这种双控制器架构方式会有以下两个方面的缺点：
1． 网络带宽容易变成整个存储性能的瓶颈；
2． 如果一个控制器损坏，系统的性能将大幅下降，影响存储的正常使用。
传统存储架构的局限性主要体现在以下几个方面：
1、横向扩展性较差
受限于前端控制器的对外服务能力，纵向扩展磁盘数量无法有效提升存储设备对外提供服务的能力。同时，前端控制器横向扩展能力非常有限，业界最多仅能实现几个控制器的横向。因此，前端控制器成为整个存储性能的瓶颈。
2、不同厂家传统存储之间的差异性带来的管理问题
不同厂商设备的管理和使用方式各有不同，由于软硬件紧耦合、管理接口不统一等限制因素无法做到资源的统一管理和弹性调度，也会带来存储利用率较低的现象。因此，不同存储的存在影响了存储使用的便利性和利用率。
分布式存储往往采用分布式的系统结构，利用多台存储服务器分担存储负荷，利用位置服务器定位存储信息。它不但提高了系统的可靠性、可用性和存取效率，还易于扩展，将通用硬件引入的不稳定因素降到最低。优点如下：
1．高性能
一个具有高性能的分布式存户通常能够高效地管理读缓存和写缓存，并且支持自动的分级存储。分布式存储通过将热点区域内数据映射到高速存储中，来提高系统响应速度；一旦这些区域不再是热点，那么存储系统会将它们移出高速存储。而写缓存技术则可使配合高速存储来明显改变整体存储的性能，按照一定的策略，先将数据写入高速存储，再在适当的时间进行同步落盘。
2．弹性扩展
得益于合理的分布式架构，分布式存储可预估并且弹性扩展计算、存储容量和性能。分布式存储的水平扩展有以下几个特性：
1) 节点扩展后，旧数据会自动迁移到新节点，实现负载均衡，避免单点过热的情况出现；
2) 水平扩展只需要将新节点和原有集群连接到同一网络，整个过程不会对业务造成影响；
3) 当节点被添加到集群，集群系统的整体容量和性能也随之线性扩展，此后新节点的资源就会被管理平台接管，被用于分配或者回收。
3．支持分级存储
由于通过网络进行松耦合链接，分布式存储允许高速存储和低速存储分开部署，或者任意比例混布。在不可预测的业务环境或者敏捷应用情况下，分层存储的优势可以发挥到最佳。解决了目前缓存分层存储最大的问题是当性能池读不命中后，从冷池提取数据的粒度太大，导致延迟高，从而给造成整体的性能的抖动的问题。
4．多副本的一致性
与传统的存储架构使用RAID模式来保证数据的可靠性不同，分布式存储采用了多副本备份机制。在存储数据之前，分布式存储对数据进行了分片，分片后的数据按照一定的规则保存在集群节点上。为了保证多个数据副本之间的一致性，分布式存储通常采用的是一个副本写入，多个副本读取的强一致性技术，使用镜像、条带、分布式校验等方式满足租户对于可靠性不同的需求。在读取数据失败的时候，系统可以通过从其他副本读取数据，重新写入该副本进行恢复，从而保证副本的总数固定；当数据长时间处于不一致状态时，系统会自动数据重建恢复，同时租户可设定数据恢复的带宽规则，最小化对业务的影响。
5．容灾与备份
在分布式存储的容灾中，一个重要的手段就是多时间点快照技术，使得用户生产系统能够实现一定时间间隔下的各版本数据的保存。特别值得一提的是，多时间点快照技术支持同时提取多个时间点样本同时恢复，这对于很多逻辑错误的灾难定位十分有用，如果用户有多台服务器或虚拟机可以用作系统恢复，通过比照和分析，可以快速找到哪个时间点才是需要回复的时间点，降低了故障定位的难度，缩短了定位时间。这个功能还非常有利于进行故障重现，从而进行分析和研究，避免灾难在未来再次发生。多副本技术，数据条带化放置，多时间点快照和周期增量复制等技术为分布式存储的高可靠性提供了保障。
6．存储系统标准化
随着分布式存储的发展，存储行业的标准化进程也不断推进，分布式存储优先采用行业标准接口进行存储接入。在平台层面，通过将异构存储资源进行抽象化，将传统的存储设备级的操作封装成面向存储资源的操作，从而简化异构存储基础架构的操作，以实现存储资源的集中管理，并能够自动执行创建、变更、回收等整个存储生命周期流程。基于异构存储整合的功能，用户可以实现跨不同品牌、介质地实现容灾，如用中低端阵列为高端阵列容灾，用不同磁盘阵列为闪存阵列容灾等等，从侧面降低了存储采购和管理成本。
4、分布式存储与传统的SAN、NAS相比的优势和缺点？
@刘东 东软软件集团 咨询顾问：
分布式存储与传统的SAN、NAS相比，优势如下：
1、性能：在分布式存储达到一定规模时，性能会超过传统的SAN、NAS。大量磁盘和节点，结合适当的数据分布策略，可以达到非常高的聚合带宽。传统的SAN、NAS都会有性能瓶颈，一旦达到最大扩展能力，性能不会改变甚至降低。
2、价格：传统的SAN、NAS，价格比较高。特别是SAN网络设备，光纤网络成本比较高。而且，以后扩展还需要增加扩展柜。成本太高。分布式存储只需要IP网络，几台X86服务器加内置硬盘就可以组建起来，初期成本比较低。扩展也非常方便，加服务器就行。
3、可持续性：传统的SAN、NAS扩展能力受限，一个机头最多可以带几百个磁盘。如果想要个PB以上的共享存储，分布式存储是最好的选择。不用担心扩展能力问题。
缺点：
1、需要比较强的技术能力和运维能力，甚至有开发能力的用户。传统存储开箱即用，硬件由厂家提供，也有完善的文档和服务。而分布式很多是开源或者是有公司基于开源系统提供支持服务，版本迭代比较快，出问题后有可能需要自己解决。
2、数据一致性问题。对于Oracle RAC这一类对数据一致性要求比较高的应用场景，分布式存储的性能可能就稍弱了，因为分布式的结构，数据同步是一个大问题，虽然现在技术一直在进步，但是也不如传统存储设备数据存储方式可靠。
3、稳定性问题。分布式存储非常依赖网络环境和带宽，如果网络发生抖动或者故障，都可能会影响分布式存储系统运行。例如，一旦发生IP冲突，那么整体分布式存储可能都无法访问。传统存储一般使用专用SAN或IP网络，稳定性方面，更可靠一些。
5、分布式存储如何保证数据一致性？
@baimmi 某金融集团 架构师：
从服务端角度，如何尽快将更新后的数据分布到整个系统，降低达到最终一致性的时间窗口，是提高系统的可用度和用户体验非常重要的方面。对于分布式存储系统：
N — 数据复制的份数
W — 更新数据是需要保证写完成的节点数
R — 读取数据的时候需要读取的节点数
如果W+R>N，写的节点和读的节点重叠，则是强一致性。例如对于典型的一主一备同步复制的分布式存储系统，N=2,W=2,R=1，则不管读的是主副本还是从副本的数据，都是一致的。
如果W+R<=N，则是弱一致性。例如对于一主一备异步复制的分布式存储，N=2,W=1,R=1，则如果读的是从副本，就可能无法读取主副本已经更新过的数据，从而读到了脏数据所以是弱一致性。
对于分布存储式系统，为了保证高可用性，一般设置N>=3，且强制在主副本读取，也是通常说的分布式存储系统使用强一致性原则。
6、分布式存储的文件存储和对象存储有哪些区别？
@赵琳：
文件存储与对象存储区别主要可从三方面来进行比较：
1、展现模式：
文件存储：以盘符 / 目录的形式展现，优点是符合用户现有使用习惯，用户可以像使用本地硬盘一样使用存储系统，缺点是无法定制化存储元数据信息，对业务系统无优化；
对象存储：与应用系统相结合形式展现，优点是可按需调用存储接口，并为文件设置元数据以及标签属性，可满足业务系统定制化需求，缺点是需要业务系统直接调用存储，用户无法直接调用系统内数据。
2、访问协议
文件存储：NFS/CIFS 协议访问，优点是锁机制可支持多人同时对数据进行修改（锁机制由应用系统决定 , 缺点是为保证数据访问一致性，需要进行数据索引信息同步，对系统并发性能以及系统规模存在较大影响。
对象存储：HTTP 传输协议以及 RESTful 接口访问，优点是通过算法存放文件元数据信息，无元数据同步限制，系统可无限制扩展，且性能随着存储系统规模扩展而线性提升，缺点是采用 RESTful 接口 Put 、 Get 、 Delete ，不支持多人同时对同一文件修改。
3、数据结构
文件存储：采用树形目录结构，读取和存储数据要经过更长路径才能到达目标位置。随着数据越来越多，目录结构会越来越繁杂，查找以及调取文件的速度会越来越慢（操作系统对目录字节数存在限制）； 如若出现设备损坏或者扩容时，需要将巨型目录树中的数据重新分配均衡，效率较差。
对象存储：采用扁平目录结构，抛弃了嵌套的文件夹，避免维护庞大的目录树，只保留二级（或三级）目录结构。根下直接就是桶，桶中直接存放对象，桶中不能再建桶（禁止多层文件夹）。 每个对象文件都只需要一个 ID 就能获取对象。
适用场景总结：
文件存储：数百 TB-PB 级数据并行计算类应用；亿级别以内小文件存储类应用；需要在线修改数据类应用系统，如：非编系统。
对象存储：PB- 数百 PB 级数据存储存储类应用；千亿级海量小文件数据存储以及海量并发。
7、关于主流分布式文件存储的适用场景？
【问题描述】主流分布式文件存储，比如Ceph、MogileFS、TFS、FastDFS、GlusterFS 的适用场景有什么区别？哪些适合单集群，哪些适合跨集群？
@宁泽阳 中信银行信用卡中心 系统工程师：
分布式文件存储的功能、架构设计大同小异，适用场景也基本一致，如何选择更大程度上还是取决于社区的活跃度，一般用户很少有能力去做代码级别的研究，因此社区中安装、部署、运维文档的完整度，社区的活跃度是选择产品时重要的决策点。
8、各大分布式文件系统优劣势对比，读写对比，性能对比，数据安全性对比，使用场景对比？
@宁泽阳 中信银行信用卡中心 系统工程师：
各分布式文件系统数据安全性、使用场景区别不大，读写性能更取决于硬件配置，各产品区别主要在于发展过程不同带来的使用场景倾向不同，如Ceph之于OpenStack，Glusterfs之于OpenShift，建议根据不同用途选择该用途下使用最多的产品，一般这种常见的坑都被踩过了，更稳定、性能更好一些。
@刘东 东软集团 IT技术咨询顾问：
在以上几种分布式存储技术中，每一种存储技术都有各自的特点和应用场景。其中HDFS、Ceph和Swift应用比较多，这也和它们的技术发展比较快和应用场景比较多相关。下面分别介绍：
一、HDFS
主要用于大数据的存储场景，是Hadoop大数据架构中的存储组件。HDFS在开始设计的时候，就已经明确的它的应用场景，就是为大数据服务。主要的应用场景有：
1、对大文件存储的性能比较高，例如几百兆，几个G的大文件。因为HDFS采用的是以元数据的方式进行文件管理，而元数据的相关目录和块等信息保存在NameNode的内存中， 文件数量的增加会占用大量的NameNode内存。如果存在大量的小文件，会占用大量内存空间，引起整个分布式存储性能下降，所以尽量使用HDFS存储大文件比较合适。
2、适合低写入，多次读取的业务。就大数据分析业务而言，其处理模式就是一次写入、多次读取，然后进行数据分析工作，HDFS的数据传输吞吐量比较高，但是数据读取延时比较差，不适合频繁的数据写入。
3、HDFS采用多副本数据保护机制，使用普通的X86服务器就可以保障数据的可靠性，不推荐在虚拟化环境中使用。
二、Ceph
是一个开源的存储项目，是目前应用最广泛的开源分布式存储系统，已得到众多厂商的支持，许多超融合系统的分布式存储都是基于Ceph深度定制。而且Ceph已经成为LINUX系统和OpenStack的“标配”，用于支持各自的存储系统。Ceph可以提供对象存储、块设备存储和文件系统存储服务。同时支持三种不同类型的存储服务的特性，在分布式存储系统中，是很少见的。
Ceph没有采用HDFS的元数据寻址的方案，而且采用CRUSH算法，数据分布均衡，并行度高。而且在支持块存储特性上，数据可以具有强一致性，可以获得传统集中式存储的使用体验。对象存储服务，Ceph支持Swift和S3的API接口。在块存储方面，支持精简配置、快照、克隆。在文件系统存储服务方面，支持Posix接口，支持快照。但是目前Ceph支持文件的性能相当其他分布式存储系统，部署稍显复杂，性能也稍弱，一般都将Ceph应用于块和对象存储。
Ceph是去中心化的分布式解决方案，需要提前做好规划设计，对技术团队的要求能力比较高。特别是在Ceph扩容时，由于其数据分布均衡的特性，会导致整个存储系统性能的下降。
三、GFS
GFS是google分布式文件存储，是为了存储海量搜索数据而设计的专用文件系统。和HDFS 比较类似，而且HDFS系统最早就是根据 GFS的概念进行设计实现的。 GFS同样适合大文件读写，不合适小文件存储。适合处理大量的文件读取，需要高带宽，而且数据访问延时不敏感的搜索类业务。同样不适合多用户同时写入。GFS 是最早的推出分布式存储概念的的存储系统之一，后来的大部分的分布式式文件系统或多或少都参考了 GFS 的设计。HDFS和 GFS 的主要区别是，对GFS 中关于数据的写入进行了一些改进，同一时间只允许一个客户端写入或追加数据。而GFS 是支持并发写入的。这样会减少同时写入带来的数据一致性问题，在写入流程上，架构相对比较简单，容易实现。
四、GPFS
GPFS是 IBM 的共享文件系统，它是一个并行的磁盘文件系统，可以保证在资源组内的所有节点可以并行访问整个文件系统。GPFS 允许客户共享文件，而这些文件可能分布在不同节点的不同硬盘上。GPFS提供了许多标准的 UNIX 文件系统接口，允许应用不需修改或者重新编辑就可以在其上运行。
GPFS和其他分布式存储不同的是，GPFS是由网络共享磁盘（NSD）和物理磁盘组成。网络共享磁盘（NSD）是由物理磁盘映射出来的虚拟设备，与磁盘之间是一一对应的关系。所以，使用两台传统的集中式存储设备，通过划分不同的网络共享磁盘，也可以部署GPFS，不一定部署在X86设备上。GPFS文件系统允许在同一个节点内的多个进程使用标准的UNIX文件系统接口并行的访问相同文件进行读写，性能比较高。GPFS支持传统集中式存储的仲裁机制和文件锁，保证数据安全和数据的正确性，这是其他分布式存储系统无法比拟的。GPFS主要用于IBM 小型机和UNIX系统的文件共享和数据容灾等场景。
五、Swift
Swift也是一个开源的存储项目，但是主要面向的是对象存储。和Ceph提供的对象存储服务类似。主要用于解决非结构化数据存储问题。它和Ceph的对象存储服务的主要区别是。
1、客户端在访问对象存储系统服务时，Swift要求客户端必须访问Swift网关才能获得数据。而Ceph使用一个运行在每个存储节点上的OSD（对象存储设备）获取数据信息，没有一个单独的入口点，比Swift更灵活一些。
2、在数据一致性方面，Swift的数据是最终一致，在海量数据的处理效率上要高一些，但是主要面向对数据一致性要求不高，但是对数据处理效率要求比较高的对象存储业务。而Ceph是始终跨集群强一致性。
主要的应用场景，在在OpenStack中，对象存储服务使用的就是Swift，而不是Ceph。
10、Ceph、MogileFS、TFS、FastDFS、GlusterFS，是否都支持跨集群同步？
@宁泽阳 中信银行信用卡中心 系统工程师：
分布式存储一般不建议配置跨集群同步，其本来就是采用网络IO的方式，如果配置跨集群同步，会导致IO过长，可能影响读写延迟，建议配置重要数据同步复制即可，可使用rsync之类的工具。
11、块存储与文件存储的对比？
【问题描述】我想请问一下块存储与文件存储的详细对比？比如说，块存储比文件更稳定，时延低，为什么？块协议比文件协议怎么稳定，体现在哪?文件协议开销大，体现在哪？
@宁泽阳 中信银行信用卡中心 系统工程师：
实际测试结果来看，块存储和文件存储的稳定性、时延并没有明显区别。块存储和文件存储的使用场景不一样，块存储主要用于提供VMware或者OpenStack做存储卷用，而文件系统存储主要用于文件在容器、虚拟机及物理机之间的文件共享存储。
12、在 Kubernetes 上用分布式的存储方案进行容器数据的存储，哪个分布式的存储系统可以直接部署起来使用？
@宁泽阳 中信银行信用卡中心 系统工程师：
GlusterFS、Ceph都可以直接使用
@zhuqibs Mcd 软件开发工程师：
使用GlanceFS、GFS或Ceph都可以，但是如果是用于数据库的话，不得不说，效率不高啊！ 就算使用flash disk，效率也基本上等于SAS盘的速度。
13、影像数据，如果是图像比较大的情况，一张图接近GB时，选择哪种开源产品比较合适？
@宁泽阳 中信银行信用卡中心 系统工程师：
可以使用Ceph对象存储协议来保存，建议单独建设一个资源池针对这种大图像来进行存储，可以通过增大对象条带大小的方式获得更好的读写性能。
@zhuqibs Mcd 软件开发工程师：
首先表个态，图像照片，特别是尺寸大的，是不太适合直接存放在数据库中的，但如果要存放，开源的数据库mysql就可以，其实就是放在clob字段中，clob字段是MySQL从Oracle继承过来的，Oracle8i的时候，就可以存放4g的二进制文件，所以，现在MySQL完全可以存放。
其次，正确的方法，是在数据库中存放一个链接，将图像照片存放在oss对象存储上，或干脆在磁盘上。存放在数据库中效率怎么都是不高的。
14、金融行业如何针对结构化与非结构化数据，进行分布式存储的选型？
【问题描述】金融行业如何针对结构化与非结构化数据，进行分布式存储的选型？尤其像客服中心语音数据与信贷类交易系统的影像文件等非结构化数据，如何既经济又安全地选择市场上高口碑和好评的分布式存储进行对接？
@宁泽阳 中信银行信用卡中心 系统工程师：
需要结合不同的使用场景进行POC测试，有些产品可能在特定的场景下比较合适，因此可针对非结构化数据存储和结构化数据存储分别进行POC测试。
@zhuqibs Mcd 软件开发工程师：
结构化数据的分布式存储，实际上就是分布式关系型数据库的存储，使用的2pc或3pc的提交模式。为了保证结构化数据的事物一致性，这类数据的分布式存储比较好的是选用raft架构。
非结构化数据，大都是非关系型数据库，只要保证数据的最终一致性，一致性的要求比较低，所以比较自由，HDFS、GFS都可以选择，最简单的就是Hive，你可以把它理解成为一个非结构化数据仓库，底层是对HDFS等分布式存储的的读写。
15、把现有影像系统的非结构化数据集中存贮到一起，供AI、BI等平台使用，使用对象存储是否合适？
@宁泽阳 中信银行信用卡中心 系统工程师：
特别合适，对象存储比较适合存储影像、语音等非结构化数据。
@zhuqibs Mcd 软件开发工程师：
对象存储的特点是， 你可以理解为是个大U盘，可以读，但不适合于写。放置只读不改的影像数据是合适的。事实上，对象存储通常也放置一些网站的图片，供网站加载时使用，只是没有CDN强。缺点是，安全性较差，你要确定你的影像数据无敏感数据，如果有对象存储中，可以有多种加密手段。
16、一套分布式存储节点规模在多少台合适？
@Hongke 灵犀联云 软件开发工程师：
开个玩笑：抛开需求谈规模都是耍流氓——有实际的业务场景，量化的数据、流量规模才有测试结论。
1、如果是采购三方系统，对于CAP中的原则问题不是在我们的考虑范围，对于节点的配置涉及分布式系统的底层设计：数据同步（分片）、数据备份、master选举等。我们要做的就只有一点：看配置文件说明，遵循官方的节点配置公式。比较经典的节点配置公式：2/n + 1 （n为节点数），也就是集群中需要保证有半数以上的节点正常，这样可以保证master的半数投票获得率，数据备份也是同理。所以一般为达到机器的较高利用率节点数一般是：3、5、7、9...，视规模变化。
2、如果是自己设计一套分布系统，那考虑的问题不只是CAP原则还有，还有应用程序的可伸缩性，弹性和可管理性等。[微软Azure应用设计原则]感觉是不错的指导，建议看看，从分布式开发者角度出发了解分布式应用。
@Garyy 某保险 系统工程师：
分布式存储理论上的是没有节点上线的，可以无限扩展。但是，现实的情况是，超过500台节点后，整个集群的性能并不会随着节点的增加而增加，并且可能会出现集群数据重构导致的集群不稳定。
按照实际使用的情况，一般分布式集群存储容量超过70%的可用容量时，集群扩容会对集群性能产生巨大的影响。所以，一般做POC的时候，建议先把集群数据写满，然后擦除40%，在存有60%数据的集群上做POC，这个结果比较靠谱。
17、集中式存储向分布式存储的转型，有哪些技术难点和运维管理困难？
转型前期、中期和后期都有哪些注意的要点，对于渠道类、账务类和数据报送类业务，如何合理、分批次进行转型？
@zhuqibs Mcd 软件开发工程师：
技术难度： io的读写，集中存储中数据只要写入一个磁阵就算成功了，分布式存储中是写入大部分的节点才算成功，如果写入全部节点IO性能有影响，写入少量节点即是写入失败。
运维困难：监控上，要采用分布式prometheus来采集各个节点的数据，节点多的时候，监控范围较大。出现故障时， 要判断节点与节点间的相互作用，诊断难度加大。
对不同类型的数据应采用不同的迁移方式：
（1）对渠道类数据通常是多而散，通常分批迁移；
（2）对于账务类数据，通常是实时数据，需要保证其关联性和事务性，需要择业务运维窗口迁移，同时做好新老数据同步工作
（3）对于数据报送类数据，通常是交易历史数据等，可以择时一次性迁移。
在迁移前期，会有数据不同步的现象，需要新老系统并存；在中期，需要进行必要的数据校验和压力测试(分布式存储读写性能很重要)，后期在校验同步基础上，进行迁移（转型）的演练，将少量应用的数据源切换到分布式存储，进行预生产发布。
@宁泽阳 中信银行信用卡中心 系统工程师：
可以先行保留存储访问协议不变，先将集中式存储转为分布式存储；然后在稳定运行一段时间后逐步将存储协议转换为适合分布式存储访问的对象存储协议。
18、分布式存储如何做好集群运维？
@he7yong Canway 研发工程师：
分布式存储做好集群的运维非常的关键，因为正常情况下一个分布式存储是运行一个节点挂掉，如果多个节点挂掉，将会导致分布式存储的灾难。
我的推荐如下：
1.保障性运维，关注在节点服务器的稳定运行，如机器，磁盘，SSD，RAID卡，电池等等，这些关键组件的状态监控；故障后及时的处理；
2.标准化故障处理、增加节点的流程；
3.建立存储服务交付，存储使用配额的管理等等。
@kw002007 存储架构师：
1、良好的架构设计 运维成功的一半；
3、及时处理小问题；
4、熟悉技术原理，避免小问题引发大的故障。如硬盘损坏导致集群整体性能问题。
19、集群规模控制在多少节点，即可以发挥分布式多节点IO的性能优势，又可以防止集群过大造成性能下降？
@宁泽阳 中信银行信用卡中心 系统工程师：
一般推荐的集群规模为20个节点至30个节点，超过30个节点后扩容及故障带来的数据重分布数据量会很大，耗时较长，增加了存储访问不稳定性。
20、如何防止单个磁盘访问缓慢影响整体集群性能？
@宁泽阳 中信银行信用卡中心 系统工程师：
可针对磁盘IO情况设置监控阈值，当磁盘读写IO延迟过大时将其自动标记为out状态，以避免使用该性能差的磁盘，但需注意标记为out的单集群内磁盘存在上线值，该操作只可以进行1次，以避免将多个副本同时标记为out或网络抖动导致大量磁盘被标记为out影响集群整体不可读写。同时，标记为out后续尽快进行更换硬盘及数据重分布操作，防止此时集群内出现第二块满盘而该功能不可用。
21、分布式存储是否需要备份？如果需要的话有哪些常用产品？
@niupengju 银行 研发工程师：
备份的需求是基于数据重要性和系统稳定性。正常来说是需要备份的，即使分布式存储拥有多副本，保证一定的数据可恢复性。但是为了安全期间，防止整个系统的宕机，还是要备份的。备份的选择，主要考虑两个方面，一是分布式存储系统自身支持的备份恢复及双活，可以保证应用系统的稳定性。二是选择第三方备份软件。
@宁泽阳 中信银行信用卡中心 系统工程师：
是否需要备份建议针对业务系统保存的数据重要性级别而定，如业务系统数据需进行本地、同城或异地备份，那么建议在应用端对需要备份的数据进行统一备份，存储端不进行备份，这样可保持整体备份架构统一性，避免备份大量无用数据造成备份设备容量浪费。应用端备份时可使用统一备份软件，如NBU、TSM等。
@anthonyhenry 系统架构师：
依然需要备份，分布式存储的副本或纠删码是防止存储部件损坏造成数据丢失或业务暂停，哪怕分布式存储启用快照功能，也是无法防止物理故障。备份的意义在于使用与存储完全隔离的故障域来保护数据，分离的存储操作系统，不同的物理设备，不同的物理区域，以防止物理故障，逻辑故障。
方式的话有：
1.备份软件+硬盘设备或磁带设备；
2.存储之间的复制；
3.以及现在新的存储至对象存储方式，其本质是存储自带备份小软件将属于备份到硬盘设备的方式。
22、分布式存储节点超过内部通信交换机端口上限后，如何扩展内部通信交换机？业务量大时交换机节点间通信是否会受阻？
@宁泽阳 中信银行信用卡中心 系统工程师：
需要扩容内部交换机，分布式存储的交换机扩展方式与业务交换机的扩展方式都是一致的，最好在网络架构规划时预留交换机在线扩展条件（包括交换机端口等），以避免停机扩容带来的存储不可用。
23、如何做包括元数据在内的数据迁移？
@zhuqibs Mcd 软件开发工程师：
打个比方，大数据的cloudera集群，由于是商业化产品，通常有高可用，namenode都是高可用的，所以，你如果要搬机房迁移的话，我们做过（这是一个悲剧，机房租用期到了），可以先迁移一个namenode，保证网络畅通（幸好是迁移到隔壁机房），再迁移另外一个，然后再迁移各个datanode，基本用户无感知。
@宁泽阳 中信银行信用卡中心 系统工程师：
还是需要结合当前元数据的存储方式和数据迁移的目的综合考虑。
24、AI训练或大数据分析是直接使用对象存储好，还是先把数据抽取到本地文件系统好？
@zhuqibs Mcd 软件开发工程师：
抽取到本地存储，这绝对不是一个好的主意，大数据平台的数据量十分庞大，所进行的操作涉及的数据，少则几个G，多达几十个T，如此多的数据，就算你本地存储够大，请问抽取传输要多少时间。
所以，必定是在计算节点进行分析，可以的话，可以调用有GPU的计算节点进行AI训练。至于对象存储，是可以的，现在aws上大数据分析，有的就是基于对象存储。
@宁泽阳 中信银行信用卡中心 系统工程师：
这个需要结合数据量的大小和本地文件系统和对象存储的访问性能来共同决定。如果数据量过大已经超出了本地文件系统的支持容量，那么就要使用对象存储。本地文件系统如果性能好很多，而数据又需要频繁读写，可以将数据预加载到本地以提升性能。
25、分布式存储场景中是否也可基于AIops进行一些智能运维？有什么建议？
在金融行业目前也有蛮多分布式存储集群案例，那基于存储所关心的集群存储服务故障自愈、磁盘故障的SMART预测是否也可以借鉴这套算法模型去设计？
cherrylook 中国人寿保险集团 软件架构设计师：
算法本身与数据是如何存储的并无直接关系，基于分布式存储的大数据平台正是机器学习、智能运维分析的奠基石，大量、丰富、有效的数据为算法分析提供了分析的可能。磁盘故障的分析需要首先观察磁盘历史数据的趋势及分布，选择相应算法可以实现有效的预测。故障自愈部分的建设需要结合专家建议，给出特定场景下故障自愈方案才可以落地实现。
26、从运维的角度看，分布式存储设计时要考虑哪些方面？运维管理中的监控告警、备份恢复与异地容灾等应该如何规划？
@zhuqibs Mcd 软件开发工程师：
结合流行的ceph分布式做解释：
（1）分布式存储监控: 搭建分布式存储的开源软件通常都是服务器，是以服务器自有磁盘来做存储的，所以监控可以在服务器的磁盘上设置，同时，我们同样可以用prometheus+grafana的方式进行监控，部署开源的ceph_exporter服务。
（2）备份和恢复：分布式存储是不需要备份的，因为故障本身就在其软件设计的计划中，比如ceph，设置2到3个mds+monitor，4~5个osd，坏了几个节点，可以从其他节点恢复。
（3）异地灾备：比如ceph的RBD快照技术，通过差量文件的方式定期将数据备份到灾备中心，当主数据中心发生故障时，从灾备中心恢复最近的备份数据并重启相应的虚拟机，最大程度降低灾难时的数据恢复时间。
@宁泽阳 中信银行信用卡中心 系统工程师：
在设计时应考虑到网络架构对性能的影响、监控内容的合理性、运维的便捷性等方面，监控告警主要为硬件类告警、操作系统告警、应用告警、性能容量告警几大类，针对备份恢复及异地容灾建议在应用客户端进行按需备份容灾。
27、如果选择基于开源软件的分布式存储技术路线，如何做好运维人才队伍建设？如何做好软件产品平滑迭代？如何构建企业基于开源分布式存储系统的业务生态？
@宁泽阳 中信银行信用卡中心 系统工程师：
对于人才建设：
1、找一两名在其他公司有实际落地经验的带头人，最好在社区比较活跃，负责项目规划
2、招聘几名应届实习生负责项目实施，这个过程一般会有新人脱颖而出
对于产品迭代：
只进行非常有必要的升级迭代，避免陷入无限升级的困境，同时在项目规划之初考虑升级迭代的方式，对于分布式系统，逐台升级一般不影响业务使用
对于构建业务生态：
由技术部架构选定场景，制定进相应技术规范中，并由开发、运维进行落实。
28、Ceph在海量小文件的环境下，稳定性和扩展性如何？
@Garyy 某保险 系统工程师：
海量小文件存储（简称LOSF，lots of small files）出现后，就一直是业界的难题，许多互联网公司也针对自己的具体场景研发了自己的存储方案，还有一些公司在现有开源项目基础上做针对性改造优化以满足业务存储需求；
一、通过对若干分布式存储系统的调研、测试与使用，与其它分布式系统相比，海量小文件存储更侧重于解决两个问题：
1、海量小文件的元数据信息组织与管理：对于百亿量级的数据，每个文件元信息按100B计算，元信息总数据量为1TB，远超过目前单机服务器内存大小；若使用本地持久化设备存储，须高效满足每次文件存取请求的元数据查询寻址(对于上层有cdn的业务场景，可能不存在明显的数据热点)，为了避免单点，还要有备用元数据节点；同时，单组元数据服务器也成为整个集群规模扩展的瓶颈；或者使用独立的存储集群存储管理元数据信息，当数据存储节点的状态发生变更时，应该及时通知相应元数据信息进行变更。
对此问题，各分布式存储系统主要采用以下对策：1）设计时就在文件名中包含了部分元数据信息，减小了元数据规模，元数据节点只负责管理粒度更大的分片结构信息；2）通过升级优化硬件，使用分布式元数据架构——多组(每组2台)IO性能更好的ssd服务器——存储集群的元数据信息，满足单次IO元数据查询的同时，也实现了元数据存储的扩展性；3）系统模块提供了图片逻辑卷到物理卷轴的映射存储与查询功能，通过cache集群来降低延时提高并发。
2、本地磁盘文件的存储与管理(本地存储引擎)：对于常见的Linux文件系统，读取一个文件通常需要三次磁盘IO(读取目录元数据到内存，把文件的inode节点装载到内存，最后读取实际的文件内容)；按目前主流2TB~4TB的sata盘，可存储2kw~4kw个100KB大小的文件，由于文件数太多，无法将所有目录及文件的inode信息缓存到内存，很难实现每个图片读取只需要一次磁盘IO的理想状态，而长尾现象使得热点缓存无明显效果；当请求寻址到具体的一块磁盘，如何减少文件存取的io次数，高效地响应请求(尤其是读)已成为必须解决的另一问题。
对此问题，有些系统采用了小文件合并存储+索引文件的优化方案，此方案有许多益处：a.合并后的合并大文件通常在64MB，甚至更大，单盘所存储的合并大文件数量远小于原小文件的数量，其inode等信息可以全部被cache到内存，减少了一次不必要的磁盘IO；b.索引文件通常数据量(通常只存储小文件所在的合并文件，及offset和size等关键信息)很小，可以全部加载到内存中，读取时先访问内存索引数据，再根据合并文件、offset和size访问实际文件数据，实现了一次磁盘IO的目的；c.单个小文件独立存储时，文件系统存储了其guid、属主、大小、创建日期、访问日期、访问权限及其它结构信息，有些信息可能不是业务所必需的，在合并存储时，可根据实际需要对文件元数据信息裁剪后在做合并，减少空间占用。除了合并方法外，还可以使用IO性能更好的SSD等设备，来实现高效响应本地io请求的目标。
当然，在合并存储优化方案中，删除或修改文件操作可能无法立即回收存储空间，对于存在大量删除修改的业务场景，需要再做相应的考量。
29、Ceph可以配置单副本吗？
【问题描述】采用Ceph搭建对象存储，用于小文件保存，几百TB的级别。但是大部分文件几乎不会被访问，有点儿像一个归档存储。如果使用两副本、三副本，硬盘数量太多了。如果在底层配置RAID组，把VD给Ceph，只做单副本，是否可行？
@吕作令 XSKY 资深解决方案专家：
不建议，建议硬盘直通进操作系统。做2-3副本保障数据安全。
1、如果在底层配置RAID组，把VD给Ceph，只做单副本相当于每个VD一个OSD。在VD出现问题后，由于数据是1副本，会数据丢失风险。
2、底层RAID在做数据恢复时，也会影响ceph集群异常
3、增加了集群运维难度，增大了集群风险点
@qsg0720 深圳杉岩 CTO：
建议采用纠删码（EC）来解决，可以得到70-85%的磁盘空间使用效率，不过性能比副本差一些。
@Garyy 某保险 系统工程师：：
不建议配置单副本，为了保证系统的可用性和可靠性，必须采用两副本或者三副本或者在原场地养老的模式
30、Ceph一个 OSD 应该分配多少内存？
【问题描述】一个OSD应该分配多少内存？最近在测试Ceph集群，发现OSD占用的内存随着写入的数据越来越多，占用的内存也越来越多，最终都把系统内存完了。
root 31383 28.2 8.3 2593676 920976 ? Ssl Mar01 332:07 /usr/local/hstor/ceph_dir/bin/ceph-osd -i 42 --pid-file /var/run/ceph/osd.42.pid -c /usr/local/hstor/ceph_dir/etc/ceph/ceph.conf --cluster ceph
root 32534 21.2 8.4 2591672 936432 ? Ssl Mar01 249:22 /usr/local/hstor/ceph_dir/bin/ceph-osd -i 44 --pid-file /var/run/ceph/osd.44.pid -c /usr/local/hstor/ceph_dir/etc/ceph/ceph.conf --clust
@吕作令 XSKY 资深解决方案专家：
现在分配了多少内存出现问题了呢？Ceph 集群出现异常比如数据重平衡会大量使用内存， OSD 内存消耗通常与系统中每个守护进程的 PG 数有关。内存问题需要多注意，内存不够会导致 osd 重启，集群异常。ceph.com 也给出了推荐的 OSD 内存配置，可以参考一下，建议3-5GB吧。
OSDs (ceph-osd)
By default, OSDs that use the BlueStore backend require 3-5 GB of RAM. You can adjust the amount of memory the OSD consumes with the osd_memory_target configuration option when BlueStore is in use. When using the legacy FileStore backend, the operating system page cache is used for caching data, so no tuning is normally needed, and the OSD memory consumption is generally related to the number of PGs per daemon in the system.
@冰河_C 北京东软 存储工程师：
按照官网给的建议，每TB数据分配1GB内存较为适中，当然如果内存越大越好，这样对于集群的数据均衡和高并发IO处理上，不会产生性能瓶颈。
@Garyy 某保险 系统工程师：
元数据服务器和监视器必须可以尽快地提供它们的数据，所以他们应该有足够的内存，至少每进程 1GB 。OSD 的日常运行不需要那么多内存（如每进程 500MB ）差不多了；然而在恢复期间它们占用内存比较大（如每进程每 TB 数据需要约 1GB 内存）。通常内存越多越好。
31、Ceph在激活OSD的时候提示没有权限？
【问题描述】KVM虚拟机，按照手册进行部署的，前面没有提示错误，最后激活OSD的时候提示没有权限。到OSD0，OSD1两台机器的/var/local/osd0和/var/local/osd1目录下看了一下，已经有文件存在了。不知道是哪的权限出了问题！还是说python2.7的问题？
@吕作令 XSKY 资深解决方案专家：
查看下ceph用户对于/var/local/osd0 /osd1 有没有用户权限， 可chown 下权限在尝试
@Garyy 某保险 系统工程师：
可以把具体的命令行贴出来看下，一般这种问题肯定是权限设置没有设置好导致的。
32、如何对Ceph集群进行配置，同时运行多个mds服务？
@Garyy 某保险 系统工程师：
cephfs多mds默认是动态负载均衡的，为了负载文件系统请求到多个mds。cephfs会根据每个mds计算一个热点值，热点高的mds缓存中的目录会往热点低的mds迁移，缓存中的目录在迁移的过程中是被锁定的，应用层的IO不能访问正在迁移的目录或文件，会导致部分IO访问中断几秒。于是用户就感觉卡了。
有2种方案，两种方案是独立使用的。
一，使用静态负载均衡，我们把业务绑定到mds，每次来业务我们根据mds性能监控报表，把业务绑定到负载低的mds上去，也叫手动负载均衡。操作过程如下：
1，把业务的根目录pin到mds上。
假设给用户a分配了目录/A ，用户b分配了目录/B，用户c分配了目录/C。那么我们把a用户分配到mds0，把b用户分配到mds1，把c用户分配到mds2。
setfattr -n ceph.dir.pin -v 0 /A
setfattr -n ceph.dir.pin -v 1 /B
setfattr -n ceph.dir.pin -v 2 /C
2, 设置cephfs的mds不迁移
只需要设置cephfs的mds不迁移，就能让子目录不迁移。
打开/etc/ceph/ceph.conf文件配置
mds_bal_min_rebalance=1000
每个mds都会产生一个热点值，这个热点值除以集群的总热点，然后和mds_bal_min_rebalance比较，超过mds_bal_min_rebalance就会迁移，但mds的热点值经过计算后怎么都不会超过1000的，所以只要配置mds_bal_min_rebalance=1000，多MDS之间就不会相互迁移缓存目录（不会产生负载均衡），既然不迁移，子目录就会跟着父母走，/A/AA会跟着父目录/A绑定到mds0上，而/A/AA/AAA会跟着父目录/A/AA绑定到mds0上。所以只要绑定了业务的根目录，并且设置了mds_bal_min_rebalance=1000，用户目录就被固定到了mds上。多个用户可以绑定到同一个mds上。
注意：只要使用这种模式，一定要绑定所有业务到mds上，否则业务会被默认分配到mds0上，造成mds0超载。
二，使用动态负载均衡。
依然采用默认的动态负载均衡，但是把迁移敏感度调小，让多mds之间迁移的粒度变小，而不是一下子迁移整个大目录，导致卡了很长时间。目录迁移的速度变快了，访问目录延迟的时间可以忽略不计。
1, 使多mds之间迁移粒度变小
mds_max_export_size = 20971520
2, 使mds之间热度的检测频繁变迟钝（根据场景适当调整）
mds_bal_interval = 10
mds_bal_sample_interval = 3.000000
这样既可以使用动态负载，也能避免负载均衡时候数据迁移导致的IO夯死。
33、Ceph在Windows下安装和在Linux安装有什么区别？
【问题描述】ceph-deploy install ceph-client这个命令在windows下安装的ceph能用吗？
@吕作令 XSKY 资深解决方案专家：
查询Ceph社区 （https://docs.ceph.com/） 目前ceph-deploy 仅支持；
Debian/Ubuntu
RHEL/CentOS
openSUSE
对于windows 还没有相关支持
@Garyy 某保险 系统工程师：
同上，一般集群都是采用Linux系统，安装部署会有专门的os版本；客户端一般采用普通windows或者Linux。
34、Ceph集群出现了故障，如何确切知道影响到了哪些文件？
【问题描述】Ceph向外提供文件系统，客户端mount到本地使用。如果集群健康状态不正常（比如某些对象丢失），此时如何知道哪些文件可用呢？
@Garyy 某保险 系统工程师：
Ceph同时提供对象存储、块存储、文件存储三种接口，但本质上其实是对象存储，也就是说一个rbd image实际上包含了多个对象（默认情况下是image_size/4M）。此处以块存储（RBD）为例进行演示，因为三种接口最终存储文件的操作单元都是对象，所以其他接口的方法类似：
前提：在bloc接口下有一个池：pool1,创建另一个volume（rbd image）：vol1。
因为这个vol1里其实包含了很多object，我们首先要查找object的位置：
1.查找volume(rbd image)的指纹信息
[root@controller-1 ~]#rbd info pool1/vol1
2.根据指纹找到这个volume的object
rados -p pool1 ls|grep bd85d5ffe883b
3.再根据object查找具体的存储位置
[root@controller-1 ~]# ceph osd map pool1 rbd_data.bd85d5ffe883b.00000000000004a7
进入到如下目录/Ceph/Data/Osd/osd-scsi-35000cca25e48d2e0/current，即可找到最终的存放文件夹5.1f_head
35、有哪些工具可以用来测试 Ceph 分布式文件系统的性能？
【问题描述】在 OSC 内部搭建了一套 Ceph 分布式文件系统，共 3 个节点。想对这个文件系统进行性能方面的测试，大家有什么好推荐呢？
@吕作令 XSKY 资深解决方案专家：
可以通过性能测试工具进行文件系统测试
如 VDBENCH、FIO 等
@Garyy 某保险 系统工程师：
比较常用的有fio，iozone，iometer。对于对象存储可以使用cosbench进行测试。
36、如何将块设备映像挂载到客户机？
用三台虚拟机手动部署了ceph集群，在集群上创建了一个test存储池和一个叫testimage的1000M大小的块设备映像，请问如何将块设备映像挂载到一个外部的客户机的/home/test目录下？
@zhuqibs Mcd 软件开发工程师：
rbd create test --size 1024 --pool test --p_w_picpath-format 2
rbd info test --pool test
rbd map test --pool test
rbd showmapped
mkfs.ext4 /dev/rbd0
mount /dev/rbd0 /mnt
@youki2008 广东溢达 系统架构师：
首先在ceph1管理节点上创建ceph块客户端用户名和认证密钥。
其次安装ceph客户端。
最后块设备的创建及映射。
ceph集群中默认创建的块设备会在rbd池中创建，但是使用deploy的安装方式部署的集群，rbd池默认不创建。
@山鸡 某保险：
客户端需要装ceph-common客户端吧， 而且客户端需要访问该存储池的秘钥， 当然，如果只是为了做实验的话，可直接用admin 。
只要能保证客户端能访问ceph集群，其余的就是块存储挂载的正常命令， 网上很多挂载的，参考下。
37、Ceph集群出现了故障，如何知道影响到了哪些文件？哪些文件还可用？
Ceph向外提供的是文件系统，客户端mount到本地使用。如果集群健康状态不正常（比如某些对象丢失），如何知道哪些文件可用？
@youki2008 广东溢达 系统架构师：
那就要看是逻辑层上的故障还是物理层的故障了，逻辑层面的话可以通过副本进行修复，物理层面的话就比较麻烦了。
@zhuqibs Mcd 软件开发工程师：
Ceph集群出现什么故障， 如果只是逻辑上问题，修复后，所有文档都不会损失；如果是物理层的故障，ceph有副本，只要不超过一定限度，仍然不会影响到数据和文件；如果损失的，这个是物理层的，基本上追不回来了，除非用底层的修复技术。
38、cinder与ceph osd的连接问题？
cinder的volume进程是否对每一个ceph osd都建立了一个TCP连接？cinder默认的文件描述符数是1024，那有很多osd的时候，是否要把这个参数调高？
@zhuqibs Mcd 软件开发工程师：
（1） ceph的少量的monitor组成的小规模集群，负责管理的Map。Cluster Map是整个RADOS系统的关键数据结构，包含集群中全部成员、关系、属性等信息以及管理数据的分发。ceph.conf文件中主要就是指定mon的节点的位置，所以cinder服务需要和ceph的monitor保持连接，但不一定是tcp啊，内部的应该是rpc连接。
（2）cinder的文件描述符是个逻辑概念，和后端的osd，没有必然联系，应该不需要调高。
@youki2008 广东溢达 系统架构师：
有很多osd的时候，有必要将默认的文件描述符数量调大，不然后边数量多起来超过1024的话会有报错。
39、Ceph的块设备存储有良好的读写性能，可以组成共享文件系统，但同时Ceph自身也有文件系统接口，请问两者有何区别？性能上孰高孰低？
@zhuqibs Mcd 软件开发工程师：
块存储读写快，不利于共享，文件存储读写慢，利于共享。能否弄一个读写快，利 于共享的出来呢。于是就有了对象存储。
所以，Ceph的块存储是可以组成文件系统的，提供共享服务的，但没有这个必要，因为服务器、网络以及NFS服务，你都要自行安排。除非一种情况，你对文件系统共享的速度，乃至对象存储的速度均不满意，但又想要共享功能时，你再可以考虑块设备存储组成共享文件系统的方案。
@youki2008 广东溢达 系统架构师：
特点是块存储读写快，但不利于共享，而文件存储读写慢，但有利于共享。在性能上，块存储的性能高于文件存储。
@荣重实 XSKY 技术总监：
CephFS最大的问题是社区并不推荐上生产，请自行评估数据安全性。
40、传统存储如何一键切换到分布式存储Ceph？
我们行现在用的存储是华为5800，架构是同城双活，假如采用分布式存储，如何升级迁移？
@zhuqibs Mcd 软件开发工程师：
（1）存储的形式基本上对用户的透明的，用户感知不到数据是在传统存储上，还是在分布式存储上；
（2）每个厂商对自己名下的数据迁移都有特定的解决方案。我感受最深的是emc的scaleio，确实好用，性能又好，原来有试用版的，现在不知道有没有。
@荣重实 XSKY 技术总监：
存储的切换，涉及应用和数据两个平面的工作。
首先数据层面，如何做好数据迁移是做一键切换的基础，那么至少要有数据在线迁移的方案或者工具来做支撑；其次在数据迁移之后，应用怎么平滑切换应用，也是要提前考虑的问题；所以并不是简单的存储替换问题，需要综合评估，各个平面的适应性，兼容性，可能发生的影响，以及回退方案。对于存储来说，如果有类似存储虚拟化或者存储纳管的功能，可能会让这个过程风险降低，趋于平滑。
@lhs0981101410 中银保信 系统运维工程师：
添加分布式存储的映射关系，然后做数据的迁移。
41、ceph对象存储osd分配不均匀，osd full？
200TB的集群，导入100来个T的数据就有osd full（95%）是什么情况？看osd状况，最大92%，最少58%，大部分在60-70%左右。CRUSH算法下为什么会分布不均呢？
@zhuqibs Mcd 软件开发工程师：
crush算法不是万能的啊！
（2）crush算法中，有两次映射，对象到PG的映射是通过哈希值取模，对象名是不可控的，因此只有在数据量大的情况，可以达到一个大致的均衡分布。再就是第二次映射，ceph会生成一系列的pg数目，包含了一些osd列表，它是一种伪随机算法，pg的数目也会影响数据均衡的效果，也会产生一些不稳定因素。
42、如何恢复Ceph的故障节点的硬盘上的数据？
假设集群的故障域为host，那么如果两个节点同时down掉，而且无法启动这两个节点，但是节点的硬盘数据可以正常读取。那么我该如何将这两个节点的数据导入到集群？导入会不会覆盖在节点down掉后写入到集群的对象呢？
@zhuqibs Mcd 软件开发工程师：
（1）如果真的是故障，故障磁盘重新加入集群，必先初始化，恢复不了；
（2）如果不是故障，restart，可以重启磁盘读取数据；
（3）故障磁盘没有必要去恢复，ceph都是有副本的。
@youki2008 广东溢达 系统架构师：
Ceph都是有副本数据的，如果是很严重的故障， 故障磁盘只能重新加入集群，必先初始化，恢复不了了。
43、目前企业Ceph 应用版本该如何抉择；采用ssd+sata 应用bulestore引擎？
1：目前企业应用ceph 的主流版本是哪个版本，目前ceph已经到o版了 ，那我现在部署的话建议部署哪个版本了？
2：采用ssd+sata 应用bulestore引擎 ，其中block.db 和block.wal 的大小该如何设置， 看过一些资料，建议block.db 是主设备 4%，那block.wal的大小建议如何设置了？是与block.db的大小一样吗？
@zhuqibs Mcd 软件开发工程师：
（1）一般LTS版本是当前年份往过去退2年左右，所以，现在的稳定版是M版mimic。
（2）wal 是 RocksDB 的write-ahead log, 相当于之前的 journal 数据，db 是 RocksDB 的metadata 信息。在磁盘选择原则是 block.wal > block.db > block。当然所有的数据也可以放到同一块盘上。
（3）默认情况下， wal 和 db 的大小分别是 512 MB 和 1GB， 官方建议调整block.db 是主设备 4% ，而block.wal分为6%左右，2个加起来10%左右。
@花花世界 系统架构师：
1、生产环境L版比较多。
2、一般 wal 分区大于 10G 就足够使用， Ceph 官方文档建议每个 db 分区不小于每个数据盘容量的 4%，比如：数据盘4T，db分区 180G，wal分区 60G。具体可根据SSD或者NVME盘容量灵活设置。
44、Ceph成熟的升级方案 j 版到 L？
目前公司项目中使用了J版本的ceph，在页面管理不能实现，只能升级后才能使用mgr，目前遇到问题是：
1 、ceph即是数据节点又是openstack计算节点
2 、业务中使用的数据大概20t
3 、共计节点数70个
有没有类似的升级方式可以参考？
@zhuqibs Mcd 软件开发工程师：
作为生产系统，有一个dashboard是很有必要的。
（1）建议滚动升级到L版
（2）寻求是否有其他第三方的dashboard可供J版使用；
（3）根据ceph api接口，自己开发一个dashboard
@花花世界 系统架构师：
1、为了一个所谓的dashboard去升级ceph，是不是有点得不偿失？
2、长远看自己写一个管理平台，可以兼容各种ceph版本收益更高，非得赖着官方的dashboard可能会导致管理模块和ceph版本紧耦合，不得不跟着官方天天升级，这就是从此折腾不断了。
3、官方的dashboard 重构了不知道多少次了， 最早的calamari时代 到现在的版本，来来回回的变，你要是贴着他们的版本，官方一旦弃坑就歇菜，这些都是老司机们之前吃过的亏。
45、使用ceph-ansible安装好一个ceph集群，怎么才能在安装完更改集群name呢？
@youki2008 广东溢达 系统架构师：
可以采用命令：ceph-deploy --cluster mydom new ceph-node
@zhuqibs Mcd 软件开发工程师：
文档中写了设置名字的命令
ceph-deploy --cluster mydom new ceph-node
但是同时，又写了没有必要去设置集群名字。
应该是原先是有这功能的，但后来被开发小组移除了，以下是移除该功能的公告，供参考：
http://lists.ceph.com/pipermail/ceph-users-ceph.com/2017-June/018497.html
@宁泽阳 中信银行信用卡中心 系统工程师：
建议在部署过程中修改配置文件进行集群name修改，部署完成后集群name配置较为分散，容易修改不完全，可能会导致集群访问异常。
觉得本文有用，请 转发、点赞 或点击 “在看” ，让更多同行看到
推荐收藏：
下载 twt 社区客户端 APP
或到应用商店搜索“twt”
以上是关于45 个分布式存储典型问题解读，看完成半个高手的主要内容，如果未能解决你的问题，请参考以下文章